Tdoc List

2019-10-22 10:41

TDoc Title Source Type For Agenda Avail Treated Decision Wdrn Replaced-by Replaces
S3‑193300 Agenda WG Chair agenda  
2Approval of Agenda and Meeting Objectives
 		Yes
Yes
 		revised No S3‑193681  
S3‑193301 TR 33.813 - update for solution #11 InterDigital Communications pCR Approval
5.6.2Study (FS_eNS_SEC)
 		Yes
Yes
 		approved No    
S3‑193302 TR 33.819 – update of DH based solution for CAG ID privacy InterDigital Communications pCR Approval
5.10.2Study (FS_Vertical_LAN_SEC)
 		Yes
Yes
 		approved No    
S3‑193303 TR 33.819 – update of Hash based solution for CAG ID privacy InterDigital Communications pCR Approval
5.10.2Study (FS_Vertical_LAN_SEC)
 		Yes
YesHuawei: what is sufficient length ofCAG ID, where is it defined IDCC: this is a suggested length Huawei: length of CAG needsd to be defined ed note. Nokia: fine as part of solution, because it says e.g. QC: text against FBS is not making claims against active attacks. IDCC: correct
 		approved No    
S3‑193304 33.836 - solution #1 update InterDigital Communications pCR Approval
5.16Study on Security Aspects of 3GPP support for Advanced V2X Services (FS_eV2X_Sec)
 		Yes
Yes
 		approved No    
S3‑193305 TR 33.836 - update for solution #2 InterDigital Communications pCR Approval
5.16Study on Security Aspects of 3GPP support for Advanced V2X Services (FS_eV2X_Sec)
 		Yes
YesLG: this doesn't adhere to SA2 TS, There only initiating UE sends TCR, here the responding also sends TCR QC: agree, but part of the solution, so put this into the evaluation. Add ed note don't add note
 		revised No S3‑193797  
S3‑193306 TR 33.836 - solution #3 update InterDigital Communications pCR Approval
5.16Study on Security Aspects of 3GPP support for Advanced V2X Services (FS_eV2X_Sec)
 		Yes
Yes
 		approved No    
S3‑193307 TR 33.836 solution #4 update InterDigital Communications pCR Approval
5.16Study on Security Aspects of 3GPP support for Advanced V2X Services (FS_eV2X_Sec)
 		Yes
Yes
 		approved No    
S3‑193308 TR 33.819 – review and comparative evaluation of solution for CAG ID privacy InterDigital Communications pCR Approval
5.10.2Study (FS_Vertical_LAN_SEC)
 		Yes
Yesneed to wait for SA2 IDCC: propose to note all of the CAG conclusions.
 		noted No    
S3‑193309 TR 33.813 - update for the evaluation for solution #11 InterDigital Communications pCR Approval
5.6.2Study (FS_eNS_SEC)
 		Yes
YesNokia: 3396 is related together with 3396 Nokia: remove word fully from evaluation in 309 QC: solution doesn't work well, so discuss this offline.
 		revised No S3‑193823  
S3‑193310 TR 33.819 – evaluation of DH based solution for CAG ID privacy InterDigital Communications pCR Approval
5.10.2Study (FS_Vertical_LAN_SEC)
 		Yes
YesQC: after a FBS runs DH, it can run passive attacks, IDCC that was not claimed E//: mention explicitly that it doesn't address active attacks QC: move that to first line IDCC: requirements don't say both QC: remove fully, add "against passive attacks..." to first sentence, combining last and first sentence agreed on last QC comment
 		revised No S3‑193826  
S3‑193311 TR 33.819 – evaluation of Hash based solution for CAG ID privacy InterDigital Communications pCR Approval
5.10.2Study (FS_Vertical_LAN_SEC)
 		Yes
YesQC: does this against a passive attack from a UE in the same CAG IDCC: insider attack QC: not insider, include comment from 310 DCM: this solution does not protect against passive attacks by members of the CAG QC changes and DCM comment agreed
 		revised No S3‑193827  
S3‑193312 33.836 – evaluation for the Solution #1 InterDigital Communications pCR Approval
5.16Study on Security Aspects of 3GPP support for Advanced V2X Services (FS_eV2X_Sec)
 		Yes
YesQC: SA2 link layer is two roundtrip, this is 3 roundtrips, analysis needs to be done IDCC: ed note how to address mismatch with SA?2 QC: ed note: securtiy comparison with SA2 solution for link layer update is FFS DCM: remove and/or ed note and and/or
 		revised No S3‑193795  
S3‑193313 Resolving EN in TR33.855 6.18 N9 NDS/IP Juniper Networks, NTT DoCoMo, Ericsson pCR Approval
5.1.2Study (FS_SBA-Sec)
 		Yes
YesHuawei: Mentions that network slice can have different security requirements - this is not clear Orange: Different security can be applied to different slices DCM: A better formulation is needed Juniper: Trying to resolve EN and it needs to be decided if some normative work needed.
 		revised No S3‑193728  
S3‑193314 TR 33.836 - evaluation for the solution #2 InterDigital Communications pCR Approval
5.16Study on Security Aspects of 3GPP support for Advanced V2X Services (FS_eV2X_Sec)
 		Yes
YesQC: ed note, similar to other IDCC contribition. "Justification for the difference to SA2 call flow is FFS" QC: remove last sentence ed note, remove last sentence
 		revised No S3‑193798  
S3‑193315 TR 33.836 - evaluation for the solution #3 InterDigital Communications pCR Approval
5.16Study on Security Aspects of 3GPP support for Advanced V2X Services (FS_eV2X_Sec)
 		Yes
Yes
 		approved No    
S3‑193316 TR 33.836 – evaluation of the solution #4 InterDigital Communications pCR Approval
5.16Study on Security Aspects of 3GPP support for Advanced V2X Services (FS_eV2X_Sec)
 		Yes
YesQC: this requires partial ciphering to direct SMC command, adds complexity: add editors note: compleity of adding partial ciphering to the direct security mode command compared to the benefit of the simultaneous updates is FFS. Ed note
 		revised No S3‑193796  
S3‑193317 TR 33.813 – review and comparative evaluation of solution for NSSAI privacy InterDigital Communications pCR Approval
5.6.2Study (FS_eNS_SEC)
 		Yes
Yes
 		noted No    
S3‑193318 FS_SIV TR 33.848 v030c BT plc pCR Agreement
5.13Study on Security Impacts of Virtualisation (FS_SIV)
 		Yes
YesThales: Why is there a reference to SCASS BT: Could be done by reference to specs inside 3GPP, specs outside 3GPP or by restricting the text cases Thales: But where are the solutions? BT: It is contribution driven and up to people to bring the solution for issue. Where it says 'inside SCASS' , it means that a text case in 3GPP is proposed outcome. Thales: Concerned about the terms used - DSE DCM: Propose reverting DSE chnage in 5.8.1 and adding an EN on generalising TPM/HSM and remove definition of DSE
 		revised No S3‑193749  
S3‑193319 33:846: mitigation against linkability attack THALES pCR Approval
5.14Study on authentication enhancements in 5GS (FS_AUTH_ENH)
 		Yes
YesBT: does this need a new USIM, or can this be done with OTA Thales: not OTA BT: document that this means change of USIM Orange: this solution requires change of the USIM Nokia: step 5, and step 7 are authentication procedures, how is the USIM to know that ti needs to resynch failure Thales: in case synch error, it will respond with a random, then the network wills start resynch procedure, USIM will know that is required Nokia: there may be new threats Thales: ok to add ed note Nokia: ed note threat analysis for authentication resynch will need to be done. Huawei: step 3 need a unified failure cause Thales: UICC will see different causes, but for network and ME it will not be detected Huawei: ed note: whether unified failure cause is FFS QC: if SUPI is known, this doesn't work against active attack. now this requires two passes for sync, after 3 failures the UE will block the network sentence in evaluation, ed note on threat, on unified failure cause, offline for QC attack
 		revised No S3‑193811  
S3‑193320 Proposal to solve ED notes in solution#4: Zero-overhead user plane integrity protection on the link layer Philips International B.V. pCR Approval
5.12Study on User Plane Integrity Protection (FS_UP_IP_Sec)
 		Yes
YesNok and DCM: Not clear what truncated encryption means - explanation would be good in the text Nok: First EN needs to be retained Philips: Explained in new text DCM: Replace EN1 as there is an impact by replacing hardware CRC with cryptgraphic function CMCC: Add sentence on the length of MAC compared to 32 bits QC: Security implications of just protecting the CRC needs to be further study needed
 		revised No S3‑193691  
S3‑193321 Adding evaluation to solution #7 Huawei, HiSilicon pCR Approval
5.16Study on Security Aspects of 3GPP support for Advanced V2X Services (FS_eV2X_Sec)
 		Yes
Yes
 		approved No    
S3‑193322 Editorial corrections for TR 33.819 Huawei, HiSilicon pCR Approval
5.10.2Study (FS_Vertical_LAN_SEC)
 		Yes
Yes
 		approved No    
S3‑193323 Conclsion to Key Issue #7 Huawei, HiSilicon pCR Approval
5.16Study on Security Aspects of 3GPP support for Advanced V2X Services (FS_eV2X_Sec)
 		Yes
Yes
 		approved No    
S3‑193324 New Key Issue on Security of broadcast eV2X messages over PC5 Huawei, HiSilicon pCR Approval
5.16Study on Security Aspects of 3GPP support for Advanced V2X Services (FS_eV2X_Sec)
 		Yes
YesE//: don't support this key issue LG: also doesn'T support this DCM: give reasoning, ok with no requirement BT: problem with not including it, integrity is important QC: on unicast the bearer may also be malicious QC: inlcude rationale from discussion document in conclusion offline whether required,
 		revised No S3‑193806  
S3‑193325 Evaluation of solutions addressing Key Issue #6.2 Huawei, HiSilicon pCR Approval
5.10.2Study (FS_Vertical_LAN_SEC)
 		Yes
Yes
 		noted No    
S3‑193326 Editorial corrections for eV2X TR 33.836 Huawei, HiSilicon pCR Approval
5.16Study on Security Aspects of 3GPP support for Advanced V2X Services (FS_eV2X_Sec)
 		Yes
YesNokia: sentence on broadcast is not editorial QC: agree to this sentence no changes
 		approved No    
S3‑193327 New solution to minimize the impact on the application layer communication Huawei, HiSilicon pCR Approval
5.16Study on Security Aspects of 3GPP support for Advanced V2X Services (FS_eV2X_Sec)
 		Yes
YesE//: how does it work while maintaining unicast connections Huawei: see figure no changes
 		approved No    
S3‑193328 TR 33.848 Scope Update BT plc pCR Agreement
5.13Study on Security Impacts of Virtualisation (FS_SIV)
 		Yes
YesDCM: Expand CNI abbreviation
 		revised No S3‑193751  
S3‑193329 Resolve EN on signaling details of how UE hands over to FBS Huawei, HiSilicon pCR Approval
5.55G security enhancement against false base stations (FS_5GFBS)
 		Yes
YesNokia: if FBS operates in same frequency, will it detect it? Huawei: this is not about solution, this is only background information Nokia: ok E//: disagree with solution, but this is ok.
 		approved No    
S3‑193330 Resolve second and third EN in Solution #6 Huawei, HiSilicon pCR Approval
5.55G security enhancement against false base stations (FS_5GFBS)
 		Yes
YesNokia: there is ed note on RAN2 feedback, Huawei: the LS was sent sone time ago Nokia: keep ed note until response is there. QC: same comment bring back 2nd ed note
 		revised No S3‑193757  
S3‑193331 Solution#4: resolving EN network verification of hashes of MIB/SIBs Huawei, HiSilicon pCR Approval
5.55G security enhancement against false base stations (FS_5GFBS)
 		Yes
YesQC: is thisi new solution? Huawei: existing, QC: sounds like different solution Huawei: not different, using OAM for sending additional information QC: not additional information Huawei: resolves ed notes E//: support this.
 		approved No    
S3‑193332 Solution#4: Resolving EN Impact on UE power consumption Huawei, HiSilicon pCR Approval
5.55G security enhancement against false base stations (FS_5GFBS)
 		Yes
YesQC: disagree, not only creating hash, wait for RAN reply E//: supoprt this contribution QC: evaluation not true, impact on poser consumption may be larger.
 		noted No    
S3‑193333 Solution #4: Details on hash algorithm used for MIB/SIB hashes. Huawei, HiSilicon pCR Approval
5.55G security enhancement against false base stations (FS_5GFBS)
 		Yes
Yes
 		revised No S3‑193679  
S3‑193334 Address EN in solution #1 Huawei, HiSilicon pCR Approval
5.55G security enhancement against false base stations (FS_5GFBS)
 		Yes
Yes
 		approved No    
S3‑193335 Enabling UE to detect FBS Huawei, HiSilicon pCR Approval
5.55G security enhancement against false base stations (FS_5GFBS)
 		Yes
YesE//: several problems: during handover, measurement is fast, but now SIB information needs to be collected, so introduces delay for handover, no problems are in connected mode, because no handover to FBS. Huawei: this verification is not before handover, this is after E//: how do you verify Huawei: collection is in preparation phase E//: still disagree.
 		noted No    
S3‑193336 preventing UE from reselecting to FBS Huawei, HiSilicon pCR Approval
5.55G security enhancement against false base stations (FS_5GFBS)
 		Yes
YesE//: no actions should be standarduzed, detection may not be 100% accurate, blacklisting creates new DoS, problems are with idle mode, not connected Ues. Huawei: remove actions or ed note E/: remove blacklisting QC: add several ed notes: Nokia: blacklisting in central, so nothing is left over
 		noted No    
S3‑193337 Avoiding UE from Suffering More MitM Attacks by Handover Huawei, HiSilicon pCR Approval
5.55G security enhancement against false base stations (FS_5GFBS)
 		Yes
YesE//: does this use blacklisting? Huawei: yes, gNB collects and then informs UE Nokia: how does network know the neighbors Huawei: is that the assumption QC: so what is different from normal handover? Huawei: nothing Nokia: what to do about man in the middle.
 		noted No    
S3‑193338 Evaluation of solution #6 Huawei, HiSilicon pCR Approval
5.55G security enhancement against false base stations (FS_5GFBS)
 		Yes
YesE//: add that this solution does not mitigate against radio repeater attacks QC: agree with E// add sentence QC add ed note further evaluation is ffs based on RAN2 feedback DCM: repeater is not only an attack., there are also operator deployed repeaters Nokia: but there could be a malicious repeater QC: not may require signalling overhead, make "requires".
 		revised No S3‑193759  
S3‑193339 Conclustion for Key issue #3 Huawei, HiSilicon pCR Approval
5.55G security enhancement against false base stations (FS_5GFBS)
 		Yes
Yes
 		noted No    
S3‑193340 Update of key issue #6 KPN pCR Approval
5.2.2Study (FS_AKMA)
 		Yes
YesEri: Similar to the previous document - application can derive the keys QC: Add a EN to capture the issue on whether the requirement can be left to application.
 		revised No S3‑193766  
S3‑193341 Conclusion to Key Issue #4 KPN pCR Approval
5.3.2Study (FS_CIoT_sec_5G)
 		Yes
YesSupport: cosigners Object: KPN, Huawei DCM: same as KPN conclusion, except for SA2 part, send LS to SA2 instead. Approved as LS has been sent.
 		noted No    
S3‑193342 Solution for privacy of link layer IDs in broadcast and groupcast Qualcomm Incorporated pCR Approval
5.16Study on Security Aspects of 3GPP support for Advanced V2X Services (FS_eV2X_Sec)
 		Yes
Yes
 		noted No    
S3‑193343 Conclusion on privacy for groupcast and broadcast Qualcomm Incorporated pCR Approval
5.16Study on Security Aspects of 3GPP support for Advanced V2X Services (FS_eV2X_Sec)
 		Yes
YesQC update to point to 522 soltuion Huawei: is privacy only based on source id only, make this specific add "for source layer 2 id"
 		revised No S3‑193803  
S3‑193344 Proposed conclusion of security for groupcast Qualcomm Incorporated pCR Approval
5.16Study on Security Aspects of 3GPP support for Advanced V2X Services (FS_eV2X_Sec)
 		Yes
YesHuawei: if there is a key issue groupcast, then there should also be a key issue for broadcast Lenovo: agree for broadcast, disagree with groupcast conclusion QC: who supports work on groupcast. Supporting no normative work for groupcast: QC, ZTE, LG, Huawei; objecting, Lenovo, IDCC conclusion only about broadcast, include rationale
 		revised No S3‑193805  
S3‑193345 Providing some analysis to solution #9 in TR 33.836 Qualcomm Incorporated pCR Approval
5.16Study on Security Aspects of 3GPP support for Advanced V2X Services (FS_eV2X_Sec)
 		Yes
YesIntel: disagree with all of the evaluation: no regulatory requirements, credential provsioning KMS is responsible, there are options available, what has privacy to do with credentials, can be achieved by changing session keys, credentials are never exposed.
 		noted No    
S3‑193346 Providing some analysis to solution #8 in TR 33.836 Qualcomm Incorporated pCR Approval
5.16Study on Security Aspects of 3GPP support for Advanced V2X Services (FS_eV2X_Sec)
 		Yes
YesIntel: new key issue related to this DCM: ed note (conditional: on accepting new key issue) evaluation regarding new key issue is FFS IDCC: simiultaneous changes are needed, so this is against SA2 QC: this can only happen when you change the certificate when trying to change ID, so disagree with this statement IDCC: editors note:conformance to SA2 TS23.287 clause 5.6.1.1 is FFS LG: no relationship. QC is correct IDCC: shouldn't be decoupled DCM add ed note, QC: privacy on two levels, application and on link. try to work offline on this as alternative to ed note conditional ed note, resolution or ed note, clause heading 6.8.3 conditional ed note not necessary based on outcome of 520
 		revised No S3‑193799  
S3‑193347 Resolving the editor’s note on RRC security establishment in solution #8 Qualcomm Incorporated pCR Approval
5.16Study on Security Aspects of 3GPP support for Advanced V2X Services (FS_eV2X_Sec)
 		Yes
YesIDCC: Why does PC5 use the same algorithms QC: because it has the same termination point IDCC: make this clear DCM: make note to shall QC: ok IDCC want reasoning QC: part of evaluation IDCC: keep as is. No changes
 		approved No    
S3‑193348 Resolving the editor’s note on operator knowledge of keys in solution #8 Qualcomm Incorporated pCR Approval
5.16Study on Security Aspects of 3GPP support for Advanced V2X Services (FS_eV2X_Sec)
 		Yes
YesIntel: doesn't resolve teh issue QC: if no confidentiality is provided, then LI is solved. No changes
 		approved No    
S3‑193349 Proposed solution for protecting the V2X PC5 traffic at the PDCP Qualcomm Incorporated pCR Approval
5.16Study on Security Aspects of 3GPP support for Advanced V2X Services (FS_eV2X_Sec)
 		Yes
YesLG: this is unicast, so is key ID required? QC: in Uu, handover is used, do break then make, here you can whange key in active communication no changes
 		approved No    
S3‑193350 Discussion for a response LS on NR V2X Security for user plane data and PDCP SN size Qualcomm Incorporated discussion Endorsement
5.16Study on Security Aspects of 3GPP support for Advanced V2X Services (FS_eV2X_Sec)
 		Yes
Yes
 		noted No    
S3‑193351 Solution for the activation of user plane security in NR PC5 unicast Qualcomm Incorporated pCR Approval
5.16Study on Security Aspects of 3GPP support for Advanced V2X Services (FS_eV2X_Sec)
 		Yes
YesHuawei: reuse activation, why define a different policy for UP ini PC5? QC: add editor's note: details on the user plane activation policy is FFS ed note
 		revised No S3‑193800  
S3‑193352 Discussion on protection of messages for V2X PC5 unicast Qualcomm Incorporated discussion Endorsement
5.16Study on Security Aspects of 3GPP support for Advanced V2X Services (FS_eV2X_Sec)
 		Yes
YesIDCC: support LS QC one or two LSs. Send LS based on the discussion paper
 		noted No    
S3‑193353 Some corrections/clarification for non-public networks annex Qualcomm Incorporated draftCR Endorsement
5.10.1Work Item (Vertical_LAN_SEC)
 		Yes
Yes
 		merged No S3‑193705  
S3‑193354 Resolving editor’s note on refreshing the parameter in solution #10 Qualcomm Incorporated pCR Approval
5.6.2Study (FS_eNS_SEC)
 		Yes
YesNokia: feels ed note is only partly addressed, but ok
 		approved No    
S3‑193355 Resolving editor’s note on relationship between S-NSSAI and the S-NSSAI identifiers in solution #10 Qualcomm Incorporated pCR Approval
5.6.2Study (FS_eNS_SEC)
 		Yes
YesIDCC: this is beoming more confusing, encrypted identifier is pseudonym that is shorter, so more elaboration on what is the pseudonym, ed note relationship between S-NSSAI and S-NSSAI identifier needs elaboration E//: are S-NSSAI idnetifier encrypted? QC: yes, that is what is described add ed note.
 		revised No S3‑193821  
S3‑193356 Using MACS to provide freshness for the protection of SQN during a re-synchronisation procedure in AKA Qualcomm Incorporated pCR Approval
5.14Study on authentication enhancements in 5GS (FS_AUTH_ENH)
 		Yes
YesOrange: add to evaluation that USIM needs to be changed, no impact of visited network Huawei:have to assume that MAC-S is trusted? QC: just one extra input to AK Thales: think solution is correct ZTE: there may be problem of performance Orange: no issue Nokia: how feasible is algorithm update over OTA Orange: added this sentence in eval eval: this solution requires changing the USIM
 		revised No S3‑193812 S3‑192921
S3‑193357 F1 security establishment Qualcomm Incorporated pCR Approval
5.15.2Study (FS_NR_IAB_Sec)
 		Yes
YesNokia: DU setup is basically is a wireline interface. Defined solution may not scale DCM: VPN is used in many corporates at scale QC: this is a solution proposal, so what is the problem Huawei: ed note what is the difference between wireless and wireline. Nokia: solution can go in, but need to capture in evaluation
 		approved No    
S3‑193358 Evaluation on Solution #3.1: F1 security context establishment Qualcomm Incorporated, Ericsson pCR Approval
5.15.2Study (FS_NR_IAB_Sec)
 		Yes
Yes
 		noted No    
S3‑193359 Conclusion on KI #4.1: F1 interface security Qualcomm Incorporated, Ericsson pCR Approval
5.15.2Study (FS_NR_IAB_Sec)
 		Yes
Yes
 		merged No S3‑193792  
S3‑193360 Evaluation of the shared key based MIB/SIB protection solution Qualcomm Incorporated pCR Approval
5.55G security enhancement against false base stations (FS_5GFBS)
 		Yes
YesApple: only agree with first two bullets Huawei: support QC, ed note: how to protect MIB and SIB if AS security is not active is FFS E//: not accept first statement, ecause requirement says should detect in all states QC: first two paragraphs need to be read together E//: disagree with last para QC: add that verifiaction of hash by gNB? Add ed note, remove last two paragraphs.
 		revised No S3‑193754 S3‑192938
S3‑193361 Shared key based MIB/SIBs integrity information provided by gNB Qualcomm Incorporated pCR Approval
5.55G security enhancement against false base stations (FS_5GFBS)
 		Yes
YesSamsung: what happens if message 8 is not received, what is UE behaviour? QC: not described, UE knows this. Samsung how does Ue know that? QC: UE identifies mismatch, in step 7, then if message 8 does not arrive, Samsung: without message 8, what does the UE do? incomplete solution QC add ed note: UE behaviour when message 8 is not received is FFS E//: disagree, doesn't cover UE in idle mode. Huawei: support QC Apple: note, because similar solution exists already QC: differnt place of verification
 		noted No   S3‑192936
S3‑193362 Evaluation against MitM false base station attacks Qualcomm Incorporated other Endorsement
5.55G security enhancement against false base stations (FS_5GFBS)
 		Yes
YesDCM: is there a clear definition of counts as MitM attack QC: stupid relay is not a relay, it s described in key issue 7 Apple: no requirements in key issue 7
 		noted No   S3‑192937
S3‑193363 Evaluation on UE behavior on detection of false signature Qualcomm Incorporated pCR Approval
5.55G security enhancement against false base stations (FS_5GFBS)
 		Yes
YesE//: not agreeing with bit flip attack. In second paragraph, alter attack is in controlled environment, using different PCI and frequency, with signature that could be avoided. Apple: first para should be moved into ky issue, second para is DoS, true for all MACs, disagree with third and fourth para as well QC: not move to key issue description.
 		noted No    
S3‑193364 Evaluation on signing key management Qualcomm Incorporated pCR Approval
5.55G security enhancement against false base stations (FS_5GFBS)
 		Yes
YesHuawei: stronly support last paragraph, because when moving to new TA, the UE can suffer from MiTM attack. E//: UE could get new keys before moving to new TA Samsung: disagree with second evaluation, first also doesn't hold Apple: also similar to Samsung QC: agree that all signing solutions will not be pursued further, as no evaluations are going in. Apple: problems where of technical nature.
 		noted No    
S3‑193365 Evaluation on Enriched MR Qualcomm Incorporated pCR Approval
5.55G security enhancement against false base stations (FS_5GFBS)
 		Yes
YesHuawei: disagree with evaluation, too subjective, limit to postmortem is not true, E//: disagree to many paragraphs, some ok with changes QC: discuss this offline.
 		noted No    
S3‑193366 Key Issue on UE capability protection for CP optimization only CIoT UE Qualcomm Incorporated pCR Approval
5.3.2Study (FS_CIoT_sec_5G)
 		Yes
Yes
 		merged No S3‑193704  
S3‑193367 LS on GUTI re-allocation Qualcomm Incorporated LS out Discussion
5.3.2Study (FS_CIoT_sec_5G)
 		Yes
YesNokia: Agree an important principle to maintain 5G-GUTI re-allocation Eri: Agree but want to delay response as incoming LS is out of scope There was general agreement on the principle that GUTI re-allocation should be supported. Chair: There will be an LS out of the meeting but will need discussion on the process to follow due to original LS not being part of meeting Result of discussion: send LS as new LS, not as reply.
 		noted No    
S3‑193368 Reply LS on SUCI computation from an NSI Qualcomm Incorporated LS out Approval
5.10.1Work Item (Vertical_LAN_SEC)
 		Yes
YesDCM doesn't answer the question QC: there are features that don't work Thales: disagree with QC, currently nothing prevents the two identities Orange: agree with LS, but need to add whether there are security concerns, Orange doesn't see any, respond from next meeting, but should be only one key. Nokia: two identifiers for UE is ok? Orange: yes, but need more time to study.
 		noted No    
S3‑193369 Proposed conclusion for 5G RAN connected to 5GC Qualcomm Incorporated pCR Approval
5.12Study on User Plane Integrity Protection (FS_UP_IP_Sec)
 		Yes
YesHuawei: Concern that there is a EN in solution so remove reference QC: Ok CMCC: Concern about the performance issues, e.g. some bearers may not require UP IP as performance is more important QC: Proposal is as for solution 2 that UP IP is optional to use CMCC: Propose to add a sentence on the performance QC: Does this mean re-evaulation of existing Rel-15 Apple: Propose to remove the note - this was agreed. DCM: Concerned about the impact on ng-eNB on this conclusion
 		revised No S3‑193698  
S3‑193370 Security aspects of RLOS Qualcomm Incorporated draftCR Endorsement
6Any Other Business
 		Yes
YesQC: should be for information DCM: out of scope
 		noted No    
S3‑193371 TR 33.848 Security Requirements for Key Issue 17 (resubmission of S3-192559) NCSC pCR Approval
5.13Study on Security Impacts of Virtualisation (FS_SIV)
 		Yes
Yes
 		merged No S3‑193741  
S3‑193372 TR 33.848 Security Threats and Requirements for Key Issue 16 (resubmission of S3-192558) NCSC pCR Approval
5.13Study on Security Impacts of Virtualisation (FS_SIV)
 		Yes
Yes
 		revised No S3‑193742  
S3‑193373 TR 33.848: Security Requirements for Key Issue 18 (resubmission of S3-192560) NCSC pCR Approval
5.13Study on Security Impacts of Virtualisation (FS_SIV)
 		Yes
Yes
 		noted No    
S3‑193374 TR 33.848 Security Requirements for Key Issue 19 (resubmission of S3-192561) NCSC pCR Approval
5.13Study on Security Impacts of Virtualisation (FS_SIV)
 		Yes
Yes
 		revised No S3‑193773  
S3‑193375 TR 33.848 Security Threats and Requirements for Key Issue 21 (resubmission of S3-192562) NCSC pCR Approval
5.13Study on Security Impacts of Virtualisation (FS_SIV)
 		Yes
Yes
 		merged No S3‑193775  
S3‑193376 TR 33.848 Annex – Virtualisation Security Questions (resubmission of S3-193089) NCSC pCR Approval
5.13Study on Security Impacts of Virtualisation (FS_SIV)
 		Yes
YesThales. Should not be a guideline that SA3 provides. Should be out of scope DCM: make this in format of evidence to a requirement BT: put this into document Orange: some are SCAS related, others are more NESAS related, prefer not to put this into TC cyber DCM: prefer to keep this here Orange: should ask GSMA if they will deal with virtualization, send LS Thales: ok to have this content, but this informative annex is the wrong way
 		noted No    
S3‑193377 Security for Wireline access to 5G - General Nokia, Nokia Shanghai Bell draftCR Endorsement
5.1.1Work Item (SBA_Sec)
 		No
Yes
 		withdrawn Yes    
S3‑193378 Authentication for 5G-RG Nokia, Nokia Shanghai Bell draftCR Endorsement
5.1.1Work Item (SBA_Sec)
 		No
Yes
 		withdrawn Yes    
S3‑193379 Security for Wireline access to 5G - General Nokia, Nokia Shanghai Bell draftCR Endorsement
5.4Security of the Wireless and Wireline Convergence for the 5G system architecture (5WWC_SEC)
 		Yes
YesOrange: no roaming, put in as Note. BT: GW owner and connected operator are same, for R17 something more practical is required. Orange: use note from TR, which is useful Nokia: should be covered in SA2 architecture Huawei: sentence is needed here. QC: Last sentence: remove "potential" Hauwei: remove last paragraph E//: remove reference to 33.501 E//: clarify FN-RG in third paragraph QC: reference in first paragraph is xx, add TS 23.whatever.
 		revised No S3‑193686  
S3‑193380 Authentication for 5G-RG Nokia, Nokia Shanghai Bell draftCR Endorsement
5.4Security of the Wireless and Wireline Convergence for the 5G system architecture (5WWC_SEC)
 		Yes
YesThales: add concealing the SUPI.
 		merged No S3‑193687  
S3‑193381 Authentication for FN-RG Nokia, Nokia Shanghai Bell draftCR Endorsement
5.4Security of the Wireless and Wireline Convergence for the 5G system architecture (5WWC_SEC)
 		Yes
Yes
 		merged No S3‑193688  
S3‑193382 Authentication for the UE behind the RG Nokia, Nokia Shanghai Bell draftCR Endorsement
5.4Security of the Wireless and Wireline Convergence for the 5G system architecture (5WWC_SEC)
 		Yes
Yes
 		approved No    
S3‑193383 Security of the interface between W-5GAN and 5GC Nokia, Nokia Shanghai Bell draftCR Endorsement
5.4Security of the Wireless and Wireline Convergence for the 5G system architecture (5WWC_SEC)
 		Yes
YesEri: list formatting Eri: clarify of the N2 interface.
 		revised No S3‑193689  
S3‑193384 Security for trusted non-3GPP access – General Nokia, Nokia Shanghai Bell draftCR Endorsement
5.4Security of the Wireless and Wireline Convergence for the 5G system architecture (5WWC_SEC)
 		Yes
YesLenovo: overlaps with 3550, merge general clause QC: clarify that sentence 2 is about EAP 5G Orange: nothing on 5G AKA in Lenovo contribution. E//: last paragraph of Nokia is not needed, it is a comparison. Call flow is copied, so put ed note on step 8 that this needs more work (authentication) ed note: stating details of key hierarchy are FFS. Huawei: second ed note not needed now.
 		merged No S3‑193685  
S3‑193385 Security procedure for trusted non-3GPP access Nokia, Nokia Shanghai Bell draftCR Endorsement
5.4Security of the Wireless and Wireline Convergence for the 5G system architecture (5WWC_SEC)
 		Yes
YesOrange: remove text from living document, remove stuff from Living document, iti is pCR to living document.
 		merged No S3‑193685  
S3‑193386 Update to 5G_eSBA WID Nokia, Nokia Shanghai Bell draftCR Endorsement
5.1.1Work Item (SBA_Sec)
 		Yes
YesThere is a related WID in S3-193672 where there is some discussion on splitting of the work items Needs to be re-submitted to Reno meeting.
 		approved No    
S3‑193387 Security requirements for SeCoP Nokia, Nokia Shanghai Bell draftCR Endorsement
5.1.1Work Item (SBA_Sec)
 		Yes
YesHuawei: Typo in title of 5.9.2.4 compared to abbreviations It was agreed to use the same name as SA2 but different abbreviations Huawei: What internal interface and why is it mentioned DCM: For service mesh type deployment there will be internal interfaces - could EN be made into normative text. Eri: Prefer to remove EN or re-word it. DCM: Leave EN in now and deal with it at the next meeting Eri: have other comments on the NOTE.
 		revised No S3‑193719  
S3‑193388 Authentication and authorization between SeCoP and network functions Nokia, Nokia Shanghai Bell draftCR Endorsement
5.1.1Work Item (SBA_Sec)
 		Yes
YesEri: last paragraph could be shortened DCM: Concerned that it sounds like an option in that case Huawei: There is no authorisation aspects in clause yet an EN should capture this
 		revised No S3‑193721  
S3‑193389 Authentication and authorization between SeCoPs Nokia, Nokia Shanghai Bell draftCR Endorsement
5.1.1Work Item (SBA_Sec)
 		Yes
YesEri: formating of bullets Huawei: Authorisation EN is needed
 		revised No S3‑193722  
S3‑193390 Hash based UE capability protection for CP optimization only CIoT UE Qualcomm Incorporated pCR Approval
5.3.2Study (FS_CIoT_sec_5G)
 		Yes
Yes
 		noted No    
S3‑193391 AMF verification of the UE radio capabilities for CP optimization only CIoT UE Qualcomm Incorporated pCR Approval
5.3.2Study (FS_CIoT_sec_5G)
 		Yes
Yes
 		noted No    
S3‑193392 CIoT_ Modifications to draft CR Nokia, Nokia Shanghai Bell, Ericsson other Approval
5.3.1Work Item (CIoT_sec_5G)
 		Yes
YesHuawei: will provide definition next time Nokia: slightly different title in 6.x.1 DCM: give different title to 6.x.1.
 		revised No S3‑193717  
S3‑193393 Proposed Solution for key issue #6 Qualcomm Incorporated pCR Approval
5.12Study on User Plane Integrity Protection (FS_UP_IP_Sec)
 		Yes
YesHuawei: Why only affects only ng-eNB QC: Clarify that this is only for 5G core and not EPC - change the title to make this clear Apple: 2nd paragraph in solution descirprion is not clear QC: OK to remove that paragraph
 		revised No S3‑193692  
S3‑193394 draft CR for Security procedures for Network Slices Nokia, Nokia Shanghai Bell other Agreement
5.6.1Work Item (eNS_SEC)
 		Yes
YesBT: is there going to be confusion if there is slice specific secondary authentication E//: there is no such thing Huawei: comments on structure and have own proposal, x.x.1 and x.x.2 are confusing, together with 401 discussion captured under 401
 		revised No S3‑193738  
S3‑193395 eNS_Addition to evaluation of solution 10 Nokia, Nokia Shanghai Bell, Ericsson pCR Approval
5.6.2Study (FS_eNS_SEC)
 		Yes
YesQC: don't need to maintain the all this context, only maintain NSSAI identifier to NSSAI mapping, disagree DCM: state that the NSSAI space is then reduced IDCC: problem to understand the solution E//: share Nokias concerns.
 		revised No S3‑193822  
S3‑193396 eNS_Addition of evaluation to solution 11 Nokia, Nokia Shanghai Bell, Ericsson pCR Approval
5.6.2Study (FS_eNS_SEC)
 		Yes
YesIDCC: on ed note: based on existing NGAP procedure, so should be clear enough. No per UE context required in RAN. All other parts of ed note also to be refuted E//: support Nokia's ed note Nokia: UE identity in AS layer, how is it learned IDCC: from S-TMSI
 		revised No S3‑193824  
S3‑193397 KI#7 Revocation of rejected NSSAI Nokia, Nokia Shanghai Bell pCR Approval
5.6.2Study (FS_eNS_SEC)
 		Yes
YesLenovo: cannot leave it to OAM Huawei: this would be too restrictive Nokia: there is no restriction on the mechanism E//: in overload situation it is marked as pending, not as failed Nokia: if a fraction of NSSAI attaches failes, then it should be possible to reauthenticate without primary auth Lenovo: problem is only external AAA knows when to retry. IDCC: Agree that problem is possible, but not for this group DCM: how does the UE know the reason, load or OAM? Nokia: error code QC: agree with IDCC
 		merged No S3‑193737  
S3‑193398 Solution for KI#7 revocation of rejected NSSAI Nokia, Nokia Shanghai Bell pCR Approval
5.6.2Study (FS_eNS_SEC)
 		Yes
Yes
 		noted No    
S3‑193399 Threats and Requirements for Key Issue #8 Nokia, Nokia Shanghai Bell pCR Approval
5.13Study on Security Impacts of Virtualisation (FS_SIV)
 		Yes
Yes
 		revised No S3‑193739  
S3‑193400 Threats and Requirements for Key Issue #13 Nokia, Nokia Shanghai Bell pCR Approval
5.13Study on Security Impacts of Virtualisation (FS_SIV)
 		Yes
Yes
 		revised No S3‑193740  
S3‑193401 Skeloton for eNS Huawei, HiSilicon draftCR Agreement
5.6.1Work Item (eNS_SEC)
 		Yes
YesNokia: needs an overall clause before coming to slice specific authenticaiton E//: prefer Nokia skeleton IDCC: prefer Nokia BT: agree to general topic heading. QC: agree DCM: are there all three types of authentication possible Nokia: no QC: in principle, it is possible, but secondary auth is orthogonal Nokia: remove authentication from title of x.x.2 TIM: if there is authorization in both, what is the difference? QC: agree, remove authorization from x.x.3, make it security procedures for... discussion on general clause captured under 402. discussion on x.x.2 Huawei: problem with content, very confusing orange: wording needs to be fixed, because it is on authorization. QC: need to have prerequisite to access network, information coming down from UDM, some slices are automaticly authorized Nokia: make this editor's note QC: try in this meeting to get this done. Chair: prefer to close QC: ok, add editor's note: the content of this clause is to be reformulated to capture 3 aspects -> taken offline.
 		noted No    
S3‑193402 Introduction to slice-specific authentication Huawei, HiSilicon draftCR Agreement
5.6.1Work Item (eNS_SEC)
 		Yes
YesNokia: merge this, not all is valid DCM: reproduce text given by QC. Nokia: this tdoc is for third para of 3394, so unrelated QC: make this ed note, remove second sentence Huawei: remove third sentence as well Nokia: what is problem with second sentence Thales: it is unclear which authenticatino is meant, so delete for now. QC: ed note: relationship netween teh different types of authentication procedures need to be provided comments on text of 402 E//: align terminology, mention AAA proxy, baseline ok, room for improvement Nokia: specific updates to individual sentences Nokia: not as separate subclause, but in beginning of x.x.3, remove last two sentences, reformulate last sentence of second paragraph: multiple methods are possible.
 		merged No S3‑193738  
S3‑193403 EAP based slice-specific authentication procedure Huawei, HiSilicon draftCR Agreement
5.6.1Work Item (eNS_SEC)
 		Yes
YesNokia: each step descriptiion is different so merge is difficult E//: even call flow is different IDCC: missing the multiplie access, which has been added by SA2 Nokia: Nokia contribution is more correct Huawei: multiple access is in text Nokia: merge in offlien session Huawei: in pleanry, how to handle AUSF: Nokia: that depends on SA reply -> use call flow of Nokia contribution as baseline, work offline E//: step 13, and 14 don't work in 394 Huawei: last two paragraphs of 394 should go away
 		merged No S3‑193738  
S3‑193404 EAP method negotiation Huawei, HiSilicon draftCR Agreement
5.6.1Work Item (eNS_SEC)
 		Yes
YesNokia: disagree, UE says what it can and will do
 		noted No    
S3‑193405 Add Evaluation to solution 3 Huawei, HiSilicon pCR Approval
5.6.2Study (FS_eNS_SEC)
 		Yes
YesNok: revise the sentence for clarity
 		revised No S3‑193731  
S3‑193406 Conclusion to KI#3 Huawei, HiSilicon pCR Approval
5.6.2Study (FS_eNS_SEC)
 		Yes
YesNok: Not clear that this require normative work Hua: Needs to be started that this data can be configured Eri: Agree with Nokia that there is no need for normative work QC: Leaning to agree with Nokia Huawei: Should write an LS to SA5 to get feedback on the inclusion.
 		noted No    
S3‑193407 Security features for NSaaS Huawei, HiSilicon draftCR Agreement
5.6.1Work Item (eNS_SEC)
 		Yes
Yes
 		noted No    
S3‑193408 Addressing EN in solution 6 Huawei, HiSilicon pCR Approval
5.6.2Study (FS_eNS_SEC)
 		Yes
YesQC: replace new text by: "if user ID privacy is required, it is protected by the EAP method" Huawei: this solution assumes privacy is required Orange: the requirement is not there, yet.
 		revised No S3‑193734  
S3‑193409 Evaluating solution 6 Huawei, HiSilicon pCR Approval
5.6.2Study (FS_eNS_SEC)
 		Yes
YesNokia: needs to be reworded to capture what is said in previous tdoc. Reformulate middle sentence: This solution relies on ID privacy protection by EAP framework. Delete third sentence Huawei: third sentence is correct, just evaluation QC: should be EAP method, not framework.
 		revised No S3‑193735  
S3‑193410 Concluding KI#4 Huawei, HiSilicon pCR Approval
5.6.2Study (FS_eNS_SEC)
 		Yes
YesQC: not ready to accept yet, but say that EAP method should provide privacy Nokia: none of the solutions requires normative work, so that should be the conclusion Huawei: because some EAP methods don't provide privacy Nokia: then it is a deployment issue Orange: agree, it is a deployment issue, non ormative work is needed. QC: need to make point that slice owner needs to pick the right EAP method. Huawei: yes, specify note, activate NAS and AS security Orange: is this just a Note Huawei: but where to put note It was agreed: There will be a Note in 33.501 adressing the user ID privacy for the slice specific authentication procedure. Orange: change conclusion to "no normative work is needed".
 		revised No S3‑193736  
S3‑193411 On service request in solution 8 Huawei, HiSilicon pCR Approval
5.6.2Study (FS_eNS_SEC)
 		Yes
YesNokia: four solutions in the next documents, a lot of overhead in all of them , all are complicated, maybe have an offline for those four documents Huawei: agree DCM: make the proposed text as real text and not NOTE Nok: Need to add EN on idle mode mobility Huawei: This is not ralted to resolution of EN.
 		revised No S3‑193819  
S3‑193412 On Ng-RAN node change in solution 8 Huawei, HiSilicon pCR Approval
5.6.2Study (FS_eNS_SEC)
 		Yes
YesID: Isn't it a burden to have to give the whole set of UE specific T-S-NSSAIs Huawei: There are different options It was agreed to take the first EN from S3-193675 in the revision of this document.
 		revised No S3‑193820  
S3‑193413 Conclusions to KI #6 Huawei, HiSilicon pCR Approval
5.6.2Study (FS_eNS_SEC)
 		Yes
Yes
 		noted No    
S3‑193414 New key issue on PFS Huawei, HiSilicon pCR Approval
5.14Study on authentication enhancements in 5GS (FS_AUTH_ENH)
 		Yes
YesE//: similar proposal in 601 together with 601
 		noted No    
S3‑193415 Discussion for EAP method negotiation Huawei, HiSilicon discussion Endorsement
5.6.1Work Item (eNS_SEC)
 		Yes
YesQC: why is this needed, identity defines EAP method Nokia: agree with QC E//: agree with Nokia Huawei: reference is required Nokia: in primary it is known, so similar
 		noted No    
S3‑193416 Overall evaluation of solutions addressing KI#4 Huawei, HiSilicon pCR Approval
5.6.2Study (FS_eNS_SEC)
 		Yes
YesOrange: good discussion, but not include in TR. Huawei: what is the problem, to show what the rationale was QC: adds no value, go straight to conclusion.
 		noted No    
S3‑193417 Overall evaluation of solutions addressing KI#6 Huawei, HiSilicon pCR Approval
5.6.2Study (FS_eNS_SEC)
 		Yes
Yes
 		noted No    
S3‑193418 Threats and Requirements for Key Issue #17 Nokia, Nokia Shanghai Bell pCR Approval
5.13Study on Security Impacts of Virtualisation (FS_SIV)
 		Yes
Yes
 		revised No S3‑193741  
S3‑193419 Threats and Requirements for Key Issue #18 Nokia, Nokia Shanghai Bell pCR Approval
5.13Study on Security Impacts of Virtualisation (FS_SIV)
 		Yes
Yes
 		revised No S3‑193743  
S3‑193420 Threats and Requirements for Key Issue #20 Nokia, Nokia Shanghai Bell pCR Approval
5.13Study on Security Impacts of Virtualisation (FS_SIV)
 		Yes
Yes
 		revised No S3‑193774  
S3‑193421 Threats and Requirements for Key Issue #21 Nokia, Nokia Shanghai Bell pCR Approval
5.13Study on Security Impacts of Virtualisation (FS_SIV)
 		Yes
Yes
 		revised No S3‑193775  
S3‑193422 Threats and Requirements for Key Issue #22 Nokia, Nokia Shanghai Bell pCR Approval
5.13Study on Security Impacts of Virtualisation (FS_SIV)
 		Yes
Yes
 		approved No    
S3‑193423 Protection of N9 interface in Inter-PLMN scenario Nokia, Nokia Shanghai Bell, Juniper draftCR Endorsement
5.1.1Work Item (SBA_Sec)
 		Yes
YesNokia presents Eri: Concerned that this includes N32 when it does not mean to Agreed does not include N32 and taken offline for formulation.
 		revised No S3‑193723  
S3‑193424 Threats and Requirements for Key Issue #23 Nokia, Nokia Shanghai Bell pCR Approval
5.13Study on Security Impacts of Virtualisation (FS_SIV)
 		Yes
Yes
 		revised No S3‑193776  
S3‑193425 Threats and Requirements for Key Issue #24 Nokia, Nokia Shanghai Bell pCR Approval
5.13Study on Security Impacts of Virtualisation (FS_SIV)
 		Yes
Yes
 		revised No S3‑193777  
S3‑193426 [draft] reply LS on NR V2X Security for user plane data and PDCP SN size LG Electronics France LS out  
5.16Study on Security Aspects of 3GPP support for Advanced V2X Services (FS_eV2X_Sec)
 		Yes
Yes
 		revised No S3‑193778  
S3‑193427 Discussion on Categorization of the Key Issues Nokia, Nokia Shanghai Bell pCR Endorsement
5.13Study on Security Impacts of Virtualisation (FS_SIV)
 		Yes
Yes
 		noted No    
S3‑193428 Security requirements for UP Gateway Function Nokia, Nokia Shanghai Bell draftCR Endorsement
5.1.1Work Item (SBA_Sec)
 		Yes
YesThere were some offline revisions suggested - first line of NOTE moving to the top of the clause Eri: proxy requirement come from SA2 - does SA3 need to say DCM: UPGF acts a a transparent function Huawei: Remove last sentence of NOTE as not security related
 		revised No S3‑193720  
S3‑193429 Resolution of Editors notes for Key issue 1 and 8 LG Electronics France pCR  
5.16Study on Security Aspects of 3GPP support for Advanced V2X Services (FS_eV2X_Sec)
 		Yes
Yes
 		approved No    
S3‑193430 Resolution of Editors notes for Key issue 6 LG Electronics France pCR  
5.16Study on Security Aspects of 3GPP support for Advanced V2X Services (FS_eV2X_Sec)
 		Yes
Yes
 		approved No    
S3‑193431 Conclusion for Key issue 10 LG Electronics France pCR  
5.16Study on Security Aspects of 3GPP support for Advanced V2X Services (FS_eV2X_Sec)
 		Yes
Yes
 		revised No S3‑193779  
S3‑193432 Discussion on Security of Multi-CU-UP connectivity CATT discussion Decision
4Incoming LS
 		Yes
Yes
 		withdrawn Yes    
S3‑193433 LS reply to RAN WG3 LS on security for multi-CU-UP connectivity CATT LS out Approval
4Incoming LS
 		Yes
Yes
 		withdrawn Yes    
S3‑193434 Draft CR-living doucment for 5G_eLCS CATT draftCR Approval
5.7Security of the enhancement to the 5GC location services (eLCS_Sec)
 		Yes
YesMerged into S3-193702 Nok: Is feature optional to use by network or UE
 		merged No S3‑193702  
S3‑193435 Discussion on security context handling in fast RRC release LG Electronics discussion  
5.3.1Work Item (CIoT_sec_5G)
 		Yes
YesIntel: SA2 have not agreed to fast release, so should we discuss this here QC: Not clear what the securiyt issue is LG: Possible NCC mismatch Nok: Agree with Intel that fast release is not yet standardiszed Eri: Not clear that observation 1 is correct so maybe no security issue.
 		noted No    
S3‑193436 Minimizing dependency on application layer security Intel pCR  
5.16Study on Security Aspects of 3GPP support for Advanced V2X Services (FS_eV2X_Sec)
 		Yes
YesQC: privacy requirements will be driven by application E//: supporting QC
 		noted No    
S3‑193437 Protection of UE capability transfer for UEs without AS security Intel pCR  
5.3.2Study (FS_CIoT_sec_5G)
 		Yes
YesNo comments on the key issue and threats part of the documents.
 		revised No S3‑193704  
S3‑193438 Security solution for UE Capability Transfer for UE with no AS security. Intel pCR  
5.3.2Study (FS_CIoT_sec_5G)
 		Yes
YesE//: key issue not approved yet.
 		noted No    
S3‑193439 Security solution for UE to avoid connecting to the false base station during a handover procedure Intel pCR  
5.55G security enhancement against false base stations (FS_5GFBS)
 		Yes
YesQC: contention free RA is already supported, then why not use that rather than new solution intel: first time handover still succeeds is step 6. E//: attacker can play number 5 preambel as well Intel: This is in evaluation.
 		noted No    
S3‑193440 Conclusions on Key Issue #3 Intel pCR  
5.55G security enhancement against false base stations (FS_5GFBS)
 		Yes
YesE//: ok with detection, but not for handover Huawei: ok, decide the rest after RAN2 feedback QC: wait for RAN2 feedback and further evaluation ZTE: wait for RAN2 feedback for all DCM: wait for RAN2 feedback for detection, handover, no normative work QC: support DCM Orange: support DCM Huawei: too early. DCM: what are waiting for on handover, what would be the best outcome to supprt handover to FBS prevention E//: LS is only about detection.
 		noted No    
S3‑193441 AKMA: Resolving the EN in AKMA push Huawei, Hisilicon pCR Approval
5.2.2Study (FS_AKMA)
 		Yes
YesEri: need to go the UDM and not clear on what is meant by security context Huawei: Will chck on UDR or UDM and change security context to K_AUSF.
 		revised No S3‑193761  
S3‑193442 AKMA: adding the evaluation of solution #24 Huawei, Hisilicon pCR Approval
5.2.2Study (FS_AKMA)
 		Yes
YesEri: Evaluation not in template QC: When you have a K_AUSF then UE can connnect so need evaluation on why need to use PUSH for this case - also why do we need AKMA PUSH when GBA PUSH already exists Huawei: AKMA is a new feature and needs its own PUSH CMCC: Do we need an editor's note for the second point? Huawei: Confirmed that the scope of GBA PUSH enhancements is network interfaces QC: Important that understand if we need more than PUSH solution QC: Don't want to have two solutions for PUSH?.
 		revised No S3‑193763  
S3‑193443 AKMA: add conclusion on KI #17 Huawei, Hisilicon pCR Approval
5.2.2Study (FS_AKMA)
 		Yes
Yes
 		noted No    
S3‑193444 eSBA: add conclusion on KI #5 Huawei, Hisilicon pCR Approval
5.1.2Study (FS_SBA-Sec)
 		Yes
YesThere is a competing conclusion in S3-193444.
 		noted No    
S3‑193445 eSBA: add conclusion on KI #24 Huawei, Hisilicon pCR Approval
5.1.2Study (FS_SBA-Sec)
 		Yes
YesEricsson: Feel that response from SA2 is needed Huawei: Feel that it can go forward with EN Nok: Can go forward with EN There is a competing conclusion in S3-193618.
 		noted No    
S3‑193446 eSBA: add conclusion on KI #28 Huawei, Hisilicon pCR Approval
5.1.2Study (FS_SBA-Sec)
 		Yes
YesThis is a competing concusion in S3-193621 Hua: There is missing verification of the call-back and hence the solution. Eri: No way that this can be verified.
 		noted No    
S3‑193447 Update on solution#15 in TR 33.855 Huawei, Hisilicon pCR Approval
5.1.2Study (FS_SBA-Sec)
 		Yes
YesEri: evaluation does not contain disadvantages Hua: Last paragraph contains impact Taken for offline discussion of evaluation clause.
 		revised No S3‑193730  
S3‑193448 Resolving the ENs in solution #5 Huawei, Hisilicon, Lenovo, Motorola Mobility pCR Approval
5.55G security enhancement against false base stations (FS_5GFBS)
 		Yes
YesE//: not sure this attack works, as it is possible to mimic the environment DCM: should be part of evaluation E//: ed note: how the solution is resilient against GPS spoofing and falsifying location related radio environment is FFS QC: second ed note was not addressed Orange: prefer not to have last paragraph of evaluation Apple: in 6.5.2 location granularity whould be as accurate as possible, add ed ntoe what kind of granularity is sufficient. Huawei: location using here is TAI, no other granularity is required, regarding second ed note: solved in first para, because procedure will fail. DCM: unclear how consent is solved.
 		revised No S3‑193835  
S3‑193449 Conclusion on KI#5 of TR 33.809 Huawei, Hisilicon, Lenovo, Motorola Mobility pCR Approval
5.55G security enhancement against false base stations (FS_5GFBS)
 		Yes
Yes
 		noted No    
S3‑193450 New solution for linkability attack Huawei, Hisilicon pCR Approval
5.14Study on authentication enhancements in 5GS (FS_AUTH_ENH)
 		Yes
YesOrange: add two sentences: visited network is impacted, and not R15 compatible to evaluation E//: needs public key, another UE could impersonate the response, so not clear where failure message is coming from, unclear whether ME or USIM do calculation, impact of MAC failure message size is FFS: add ed note regarding this BT: if SUCI protection is not there, then there is dependency Thales: solution relies on availability of key for SUCI, add ed note. sentence in evaluation, (Orange, Thales), 3 ed notes (E//)
 		revised No S3‑193813  
S3‑193451 Resolving the ENs in KI#3.1 Huawei, Hisilicon pCR Approval
5.14Study on authentication enhancements in 5GS (FS_AUTH_ENH)
 		Yes
YesE//: still not aligned with the study Huawei: explained in the paper E//: this is not part of the objectives Huawei: then keep first ed note E//: ok DCM: needs editorial rewrite Nokia: when UE is deregistered, UE context is not cleaned up, is this the problem. Huawei: could be a problem Nokia : clean up on next deregistration, when there is error, there should be clean up in error case QC: similar to Nokia, are we trying to route NAS traffic through teh home network E//: more details on attack, bring back ed note QC: couldn't the AMF not launch the same attack by overbilling Nokia: add editor's note TIM: too many additional editor's note being added, bring another proposal
 		noted No    
S3‑193452 New solution for removing the authentication result from the UDM Huawei, Hisilicon pCR Approval
5.14Study on authentication enhancements in 5GS (FS_AUTH_ENH)
 		Yes
Yes
 		noted No    
S3‑193453 New solution for UP security policy handling for PC5 and Uu interface Huawei, Hisilicon pCR Approval
5.16Study on Security Aspects of 3GPP support for Advanced V2X Services (FS_eV2X_Sec)
 		Yes
YesQC: policy for PC5 and Uu should be sufficient, local policy should be enough. Huawei: SA6 has defined a procedure for switching. IDCC: path switching is part of 5G ProSe, wait for 5G ProSe Huawei: TR is just study, so put it here as key issue, and study next meeting LG: include ed note to say we wait for SA2 Nokia: prefer to postpone this and wait for SA2 to define this. Huawei: ok with ed note.
 		noted No    
S3‑193454 New solution for PC5 layer key derivation using the 5G network keys Huawei, Hisilicon pCR Approval
5.16Study on Security Aspects of 3GPP support for Advanced V2X Services (FS_eV2X_Sec)
 		Yes
YesQC: how does the application derive the PC5 link key? Huawei: several assumptions: UE is connected to network, has key to derive, not out of coverage Intel: agree wirth QC QC: accept the limitiation, why do this if there is a solution for out of coverage.Ed note: what happens on UE out of coverage? Huawei: 6.8.2 gives this.limitation, and also the benefit af allowing the operator QC: ed note: how the UE establishes PC5 security when out of coverage is FFS, what happens when the UEs are on different PLMNs Huawei: described in step 2 QC, only one ed note is ok, then QC: step 7, how is senidng the PC5 key securedin case of different PLMNs ed note on out of coverage
 		revised No S3‑193801  
S3‑193455 New SID: Study on Security Aspects of Enhancement of Support for Edge Computing in 5GC China Unicom, CAICT, China Telecom, Huawei, Hisilicon, ZTE SID new Approval
6Any Other Business
 		Yes
YesOrange: simplify objective by pointing to SA2 work, Samsung: split this into two Thales: don't know for UICC QC: this is release 17, so not really for endorsement CMCC: are there objections QC: process needs to be adhered Nokia: too early to start on this, wait more for SA2 progress QC: have similar comment feedback given, to be noted
 		noted No    
S3‑193456 Adding the evaluation of solution #15 Huawei, Hisilicon pCR Approval
5.10.2Study (FS_Vertical_LAN_SEC)
 		Yes
YesE//: support this Nokia: it is modifying the message on the radio interface Huawei: wait for RAN2 response on that Nokia: this comment can come back next time
 		approved No    
S3‑193457 Adding conclusion on KI #6.2 Huawei, Hisilicon pCR Approval
5.10.2Study (FS_Vertical_LAN_SEC)
 		Yes
Yes
 		noted No    
S3‑193458 Discussion on potential solutions to security handling of AMF reallocation Huawei, Hisilicon discussion Endorsement
6Any Other Business
 		Yes
YesDCM: not in scope Nokia: waitinig for reply LS from SA2 Huawei: decision is to do nothing in SA2
 		noted No    
S3‑193459 solution on AUTS derivation to protect SQN Huawei, Hisilicon pCR Approval
5.14Study on authentication enhancements in 5GS (FS_AUTH_ENH)
 		Yes
YesQC: there is no non-malleable block cipher for 48 bit, Orange: impact on Milenage and TUAK TIM: also new UICCs needs to be written QC: no arrow down form AK in diagram replace eval text, solution requires a major change of auth algorithms, and the examples defined in 3GPP (Milenage and TUAK), solution requires change of USIM
 		revised No S3‑193815  
S3‑193460 Address the EN and add evaluation in solution 2.3 Huawei, Hisilicon pCR Approval
5.14Study on authentication enhancements in 5GS (FS_AUTH_ENH)
 		Yes
YesE//: ed note in evalution: NAS procedure impact is FFS Orange: statement: this solution impact the visisted network ed note on NAS preocedure, sentence on visited network impact
 		revised No S3‑193814  
S3‑193461 A solution to protect MIB/SIBs Huawei, Hisilicon pCR Approval
5.55G security enhancement against false base stations (FS_5GFBS)
 		Yes
YesE//: incomplete, doesn't support UE in Idle mode, disagree Huawei: if NAS security is available, then use NAS security in IDLE QC: E// comment is about evaluation Apple, similar to previous, solution not needed. Samsung: hash 2 details are missing Huawei: key issue is not concluded, this is only for TR.
 		noted No    
S3‑193462 Discussion on binding between USIM/UICC and IAB-node Huawei, Hisilicon pCR Discussion
5.15.2Study (FS_NR_IAB_Sec)
 		Yes
Yes
 		noted No    
S3‑193463 Key issue on removal of UICC card in IAB node Huawei, Hisilicon pCR Approval
5.15.2Study (FS_NR_IAB_Sec)
 		Yes
YesNokia: agree with first requirement, but second requirement assumes removable UICC, should go away BT: support second requirement staying, to remove Huawei: competing 654 together with 654
 		revised No S3‑193793  
S3‑193464 Evaluation of solution#2.1 Huawei, Hisilicon pCR Approval
5.15.2Study (FS_NR_IAB_Sec)
 		Yes
YesE//: ast sentence should go, looks like solution.
 		merged No S3‑193789  
S3‑193465 Solution for protection of time synchronization Huawei, Hisilicon pCR Approval
5.10.2Study (FS_Vertical_LAN_SEC)
 		Yes
YesNokia: need more details, ed note details in line with SA2 specs is FFS
 		revised No S3‑193709  
S3‑193466 Conclusion on protection of time synchronization Huawei, Hisilicon pCR Approval
5.10.2Study (FS_Vertical_LAN_SEC)
 		Yes
YesNokia: postpone to next meeting.
 		noted No    
S3‑193467 Remove the EN and add evaluation to solution 6 Huawei, Hisilicon pCR Approval
5.10.2Study (FS_Vertical_LAN_SEC)
 		Yes
Yes
 		approved No    
S3‑193468 Propose AKMA architecture Huawei, Hisilicon pCR Approval
5.2.1Work Item (AKMA)
 		Yes
YesThere are competing proposals in S3-193584 and S3-193599 BT: Like S3-19599 as it looks more service based Orange: We are defining a service that provides keys for use in an application KPN: Why have the UDM in the picture? Huawei: Need to make the high levl descision, e.g. local of anchor function, so issue with Ericsson's text on where a key is derived - prefer S3-193584 as the baseline for merger Orange: No point having non-SBA interfaces as the core network is now servive based Huwaei: Need UDM in picture Orange: Do not see the point of not using a service based representation as that is now the normal CMCC: Both representations are equivalent Orange: Will object to non-service based version Agreed to use UE and AF boxes - also AAnF will be the name of the AKMA anchor function Orange: It is more complicated than the pictures shows as an AF outside 3GPP network may need to use an NEF to access AAnF? Merged into 771.
 		merged No S3‑193771  
S3‑193469 Propose AKMA key hierarchy Huawei, Hisilicon pCR Approval
5.2.1Work Item (AKMA)
 		Yes
YesOrange: Name of functions changes to AAnF and other fucntion to AF - key name should also change.
 		merged No S3‑193772  
S3‑193470 Conclusion on 7.3 Huawei, Hisilicon pCR Approval
5.2.2Study (FS_AKMA)
 		Yes
YesEri: maybe not possibel to conclude on this CMCC: No been decided whether anchor function is standalone KPN: Come a bit of out of the blue and not related to a solution - not ready to conclude.
 		noted No    
S3‑193471 Conclusion on 7.4 Huawei, Hisilicon pCR Approval
5.2.2Study (FS_AKMA)
 		Yes
YesThere is an alternative conclusion in S3-193586 QC: not ready to make this conclusion as there are alternatives - hence need more analysis on how this should be done.
 		merged No S3‑193768  
S3‑193472 Propose new conlusion section Huawei, Hisilicon pCR Approval
5.2.2Study (FS_AKMA)
 		Yes
YesEri: there is already a place for this conclusion CMCC: Agree with ericsson.
 		noted No    
S3‑193473 Evaluation for solution4 Huawei, Hisilicon pCR Approval
5.2.2Study (FS_AKMA)
 		Yes
YesThis was missed for earlier implementation of the TR.
 		approved No    
S3‑193474 Evaluation for solution22 Huawei, Hisilicon pCR Approval
5.2.2Study (FS_AKMA)
 		Yes
YesEri: Does not fit the template for evaluations QC: Think first sentence should go away.
 		revised No S3‑193764  
S3‑193475 Implicite AKMA authenticaiton procedure Huawei, Hisilicon pCR Approval
5.2.2Study (FS_AKMA)
 		Yes
YesEricsson: this solution changes primary authentication and not sure if this is acceptable QC: Do not understand why we are having an new solution. Huawei: Can it derive the K_AKMA? Eri: Changes the Registrations Accept QC: do not understand why a different solution is needed when we have agreed solution.
 		noted No    
S3‑193476 draftCR for URLLC Huawei, Hisilicon draftCR Approval
5.8Security for 5G URLLC (5G_URLLC_SEC)
 		Yes
YesLiving document from last time
 		revised No S3‑193699  
S3‑193477 change introduction to align with URLLC architect Huawei, Hisilicon draftCR Approval
5.8Security for 5G URLLC (5G_URLLC_SEC)
 		Yes
YesEri: Propose that could move text out of dual connectivity Huawei: Only one line on redundant bearer in SA2 QC: typo in wording Nokia: Is two path mandatory? Huwaei: It is not manadatory DCM: Language should not be normative where it is SA2 described procedures.
 		revised No S3‑193700  
S3‑193478 clarification on security policy handling Huawei, Hisilicon draftCR Approval
5.8Security for 5G URLLC (5G_URLLC_SEC)
 		Yes
YesQC: Baseline text is wrong - first sentence of third paragraph is not needed Eri: Have a similar concern
 		merged No S3‑193701  
S3‑193479 living doc for 5WWC Huawei, Hisilicon draftCR Approval
5.4Security of the Wireless and Wireline Convergence for the 5G system architecture (5WWC_SEC)
 		Yes
Yes
 		revised No S3‑193684  
S3‑193480 Authentication for 5G-RG Huawei, Hisilicon draftCR Approval
5.4Security of the Wireless and Wireline Convergence for the 5G system architecture (5WWC_SEC)
 		Yes
YesBT: equipped with UICC, prevent removal and replacement Huawei: not part of study, need requirement in study for next meeting E//: remove Ipsec in step 12.
 		revised No S3‑193687  
S3‑193481 Authentication for FN-RG Huawei, Hisilicon draftCR Approval
5.4Security of the Wireless and Wireline Convergence for the 5G system architecture (5WWC_SEC)
 		Yes
YesQC: duplicate steps 6 in call flow E//: AUSF skips authentication - doesn't perform auth DCM: lack of shalls E//: clarify that FN-RG is legacy Huawei: this is already in general clause QC: title should be about security procedures, because this is more general.
 		revised No S3‑193688  
S3‑193482 Conclusion for Key Issue #4 Huawei, Hisilicon pCR Approval
5.3.2Study (FS_CIoT_sec_5G)
 		Yes
Yes
 		noted No    
S3‑193483 CR for DDoS mitigation caused by misbehaving CIoT UEs Huawei, Hisilicon draftCR Approval
5.3.1Work Item (CIoT_sec_5G)
 		Yes
YesNok: don't need this QC: agree with Nokia.
 		noted No    
S3‑193484 Security handling for RRCConnectionRe-establishment Procedure for Control Plane Optimization for 5GS CIoT Huawei, Hisilicon draftCR Approval
5.3.1Work Item (CIoT_sec_5G)
 		Yes
YesAwaiting SA2 descion on truncating S-TMSI.
 		noted No    
S3‑193485 Security handling in Control Plane User Datafor Control Plane Optimization for 5GS CIoT Huawei, Hisilicon draftCR Approval
5.3.1Work Item (CIoT_sec_5G)
 		Yes
YesSpelling corrections and addition of EN from S3-193558 Nokia: An EN on FFS to clarify the encoding on CP optimisated messages.
 		revised No S3‑193818  
S3‑193486 Merged Solution for RRC Reject Protection Huawei, Hisilicon, Samsung pCR Approval
5.55G security enhancement against false base stations (FS_5GFBS)
 		Yes
YesEri: Have concerns with the solution QC: Also have concerns with this solution.
 		noted No    
S3‑193487 Conclusion for Key Issue #1 for RRC Reject Huawei, Hisilicon, Samsung pCR Approval
5.55G security enhancement against false base stations (FS_5GFBS)
 		Yes
YesEri: no normative work needed QC: Agree with Ericsson.
 		noted No    
S3‑193488 Update on Protection of RRC Resume Request message Huawei, Hisilicon pCR Approval
5.55G security enhancement against false base stations (FS_5GFBS)
 		Yes
YesEri: Simpler solution is available as needs to be updated as message content changes Apple: This could be merged with Ericsson solution.
 		approved No    
S3‑193489 Conclusion for Key Issue #1 for RRC Resume Request Protection Huawei, Hisilicon pCR Approval
5.55G security enhancement against false base stations (FS_5GFBS)
 		Yes
YesE//: competing solution Huawei, then postpone.
 		noted No    
S3‑193490 Conclusion for Key Issue #2 Huawei, Hisilicon pCR Approval
5.55G security enhancement against false base stations (FS_5GFBS)
 		Yes
YesOrange: disagree to have different soultions for NPN and for public network.
 		noted No    
S3‑193491 Solution for Avoiding UE connecting to False Base Station during Conditional Handover Huawei, Hisilicon pCR Approval
5.55G security enhancement against false base stations (FS_5GFBS)
 		Yes
YesE//: same comments as previous, overhead, malicious radio repeater, sentence in evaluation DCM: does it make sense to document when we know we are not doing anything about it? E//: evaluation is there already, so doesn't need to be touched again QC: same things from previous contribution DCM: there is sentence about neww signalling overhead QC: copy sentence from previous contribution Huawei: change sentence to ivnolves overhead sentence: about radio repeaters, include ed note, say requires overhead.
 		revised No S3‑193760  
S3‑193492 LS to RAN1 on Clarification for parameters used to avoid UE connecting to the FBS Huawei, Hisilicon LS out Approval
5.55G security enhancement against false base stations (FS_5GFBS)
 		Yes
Yes
 		withdrawn Yes    
S3‑193493 Address EN in solution 23 Huawei, Hisilicon pCR Approval
5.3.2Study (FS_CIoT_sec_5G)
 		Yes
YesNok: It seems strange to add the load to the surrounding base stations Huawei: by sending mis-behaving UE ID to other base stations so the other base stations know about mis-behaving Ues Eri: Update is OK but concerned about the use of the list in general Nok: Making the update optional would improve the situation DCM: RAN should be made to eNB/gNBs probably throughout the whole solution.
 		noted No    
S3‑193494 Conclusion of KI#5 Huawei, Hisilicon pCR Approval
5.3.2Study (FS_CIoT_sec_5G)
 		Yes
Yes
 		noted No    
S3‑193495 New solution on KI #9 minimizing the impact of privacy protection mechanism in the application layer communication Huawei, Hisilicon pCR Approval
5.16Study on Security Aspects of 3GPP support for Advanced V2X Services (FS_eV2X_Sec)
 		Yes
Yes
 		withdrawn Yes    
S3‑193496 Conclusion on KI#6 Ericsson, Nokia, Nokia Shanghai Bell pCR Approval
5.6.2Study (FS_eNS_SEC)
 		Yes
YesNokia: propose to have call before next meeting on NSSAI privacy.
 		noted No    
S3‑193497 New KI: Preventing mismatch for EDT with fast release LG Electronics France discussion  
5.3.2Study (FS_CIoT_sec_5G)
 		Yes
YesNok: Need to wait for SA2 work Eri: Agree to wait for SA2 but still a key issue open on this topic DCM: Concern that we need to wait for SA2 in all cases.
 		noted No    
S3‑193498 Conclusin of key issue#2 Apple pCR Approval
5.55G security enhancement against false base stations (FS_5GFBS)
 		Yes
YesQC: disagree, provide evaluation for each of the options, first evaluations need to be completed. Orange: there are still some open security issues, type of paper is like discussion paper. E// support Apple DCM: not conclude this before provisioning is defined Huawei: same comment.
 		noted No    
S3‑193499 Update for Solution#7 Apple pCR Approval
5.55G security enhancement against false base stations (FS_5GFBS)
 		Yes
YesQC: disagree, should be noted. Huawei: support QC, when UE moves to new area, it is possible to connect to FBS wthout the UE noticing, that is a technical problem
 		noted No    
S3‑193500 Evaluation for solution#14 Apple pCR Approval
5.55G security enhancement against false base stations (FS_5GFBS)
 		Yes
YesQC: disagree E//: support apple Huawei: support QC.
 		noted No    
S3‑193501 Update of Solution#11 Apple pCR Approval
5.55G security enhancement against false base stations (FS_5GFBS)
 		Yes
YesOrange: major problem is provisioning, therefore it is not viable orange: not linking the SUCI scheme DCM: provisioning is essential BT: not link to SUCI scheme to not make it more difficult to SUCI off the ground
 		noted No    
S3‑193502 Protection of UeapabilityInformation Apple pCR Approval
5.55G security enhancement against false base stations (FS_5GFBS)
 		Yes
YesOrange: this is concluded already? Huawei: agree with Orange.
 		noted No    
S3‑193503 5G paging security issue caused by false base station Apple pCR Approval
5.55G security enhancement against false base stations (FS_5GFBS)
 		Yes
YesOrange: is this DoS or ID request attack? Not required a new threat not clear what is leaked QC: paging identifiers are realloceted every time, so not needed Apple: attacker could guess the 5GS TMSI Nokia: all 5G S-TMSI can be discovered after 45h, DCM: bigger problem are cross layer attacks, this is too small a problem to solve.
 		noted No    
S3‑193504 solution for new key issue of 5G paging security issue caused by false base station Apple pCR Approval
5.55G security enhancement against false base stations (FS_5GFBS)
 		Yes
Yes
 		noted No    
S3‑193505 Discussion on 5G UE privacy when connecting to EPC Apple discussion Agreement
6Any Other Business
 		Yes
YesDCM: if this is proposal for a new study item, the in scope, technically it will be very difficult Nokia: will be very difficult to do this in all networks QC: in 5G study, we looked at this in detail, but didn't get a working solution Huawei: agree
 		noted No    
S3‑193506 Meeting minutes of 5GFBS July conference call on July 18th Apple discussion Information
5.55G security enhancement against false base stations (FS_5GFBS)
 		Yes
Yes
 		noted No    
S3‑193507 Meeting minutes of 5GFBS August conference call on August 8th Apple discussion Information
5.55G security enhancement against false base stations (FS_5GFBS)
 		Yes
Yes
 		noted No    
S3‑193508 Evaluation for Solution#5 in UP IP Apple pCR Approval
5.12Study on User Plane Integrity Protection (FS_UP_IP_Sec)
 		Yes
YesCMMC: Do not agree with the figures given in evaluation Apple: Point is that this solution cannot protect all the data packets when limited to 64 kbps
 		merged No S3‑193696  
S3‑193509 Solution to key issue#5 in UP IP Apple pCR Approval
5.12Study on User Plane Integrity Protection (FS_UP_IP_Sec)
 		Yes
YesQC: Does not address attack - issue raised at the last meeting not resolved DCM: Not sure that this works well as padding is at the end Apple: Padding is not only at the end but also at the start CMCC: Solution does not work without encryption DCM: needs to adding padding to both beginning and end Nok: Agree with the weaknesses of this proposal and the gain is too small Taken offline for discussion
 		revised No S3‑193694  
S3‑193510 EAP-AKA privacy enhancement in non-3GPP access to EPS Apple SID new Approval
6Any Other Business
 		No
Yes
 		revised No S3‑193629  
S3‑193511 Conclusion of CAG ID Privacy ZTE Corporation pCR Approval
5.10.2Study (FS_Vertical_LAN_SEC)
 		Yes
Yes
 		noted No    
S3‑193512 CAG ID Privacy for non-public networks ZTE Corporation draftCR Approval
5.10.1Work Item (Vertical_LAN_SEC)
 		Yes
YesNokia: depends on study item.
 		noted No    
S3‑193513 User identity privacy for GBA in 5GC ZTE Corporation pCR Approval
5.2.2Study (FS_AKMA)
 		Yes
YesCMCC: Don't have the GBA content in the TR Eri: Maybe in scope of the other SID Orange: Agree that could be treated in 5G GBA SID.
 		noted No    
S3‑193514 Assessment and evaluation of solution #9 ZTE Corporation pCR Approval
5.55G security enhancement against false base stations (FS_5GFBS)
 		Yes
YesE//: SIB/MIB is matter of serving network, so shouldn't involve home network. Orange: agree. BT: support that, not using home public key.
 		noted No    
S3‑193515 Structure RAND for authentication ZTE Corporation pCR Approval
5.14Study on authentication enhancements in 5GS (FS_AUTH_ENH)
 		Yes
YesE//: as instances come and go in virtual environment start-up time is FFS Orange: don't understand what are threats and requirements to be covered, so not include the solution DCM: how does home network know that ME is capable of this solution ZTE: doesn't know.
 		noted No    
S3‑193516 Conclusion on linkability issues ZTE Corporation pCR Approval
5.14Study on authentication enhancements in 5GS (FS_AUTH_ENH)
 		Yes
YesThales: too early for conclusions
 		noted No    
S3‑193517 Resolving ENs of solution #12 ZTE Corporation pCR Approval
5.6.2Study (FS_eNS_SEC)
 		Yes
YesE//: keep first editor's note Nokia: 676 is comments together with 676 ZTE: this solution has similar to Huawei solution, why not only one ed note Nokia: more ed notes are more helpful, but also ok to say solve idle mode mobillity bring back first ed note, ed note on idle mode mobility to be added
 		revised No S3‑193825  
S3‑193518 Evaluation of solution #12 ZTE Corporation pCR Approval
5.6.2Study (FS_eNS_SEC)
 		Yes
YesNokia: to early to add evaluation without idle mode mobility.
 		noted No    
S3‑193519 New key issue on protection against Man-in-the-Middle false IAB node attacks ZTE Corporation pCR Approval
5.15.2Study (FS_NR_IAB_Sec)
 		Yes
YesHuawei: merge with 793 E//: not related, one has to break F1 security Nokia: disagree with tdoc QC: disagree with tdoc
 		noted No    
S3‑193520 New key issue on security for multi-USIM communication over UU and PC5 ZTE Corporation pCR Approval
5.16Study on Security Aspects of 3GPP support for Advanced V2X Services (FS_eV2X_Sec)
 		Yes
YesIDCC: there is no security component, not SA3 issue, threats missing Nokia: this is not scope in our group QC: not in scope here
 		noted No    
S3‑193521 Editorial correction to TR 33.824 ZTE Corporation pCR Approval
5.15.2Study (FS_NR_IAB_Sec)
 		Yes
Yes
 		approved No    
S3‑193522 A solution against V2X UE tracking based on PC5 identifiers Ericsson LM pCR Approval
5.16Study on Security Aspects of 3GPP support for Advanced V2X Services (FS_eV2X_Sec)
 		Yes
YesLenovo: this is about L2 destiantion Ids? QC: source Ids QC: ok to approve this, and note 342 IDCC: what about privacy of groupcast? Put ed note, privacy of gorupcast is FFS QC: that is attempted to solve in Lenovo contribution IDCC: but that doesn't change the group ID Lenovo: it does no changes
 		approved No    
S3‑193523 TR 33.819 update Nokia, Nokia Shanghai Bell pCR Approval
5.10.2Study (FS_Vertical_LAN_SEC)
 		Yes
YesIDCC: don't waste time on CAG ID privacy, wait for SA2 progress.
 		approved No    
S3‑193524 Status of TR Nokia, Nokia Shanghai Bell discussion Discussion
5.10.2Study (FS_Vertical_LAN_SEC)
 		Yes
Yes
 		noted No    
S3‑193525 CAG ID privacy solution considering RAN optimization Nokia, Nokia Shanghai Bell pCR Approval
5.10.2Study (FS_Vertical_LAN_SEC)
 		Yes
Yes
 		approved No    
S3‑193526 CAG ID privacy conclusion -v1 Nokia, Nokia Shanghai Bell pCR Approval
5.10.2Study (FS_Vertical_LAN_SEC)
 		Yes
Yes
 		noted No    
S3‑193527 CR CAG ID privacy Nokia, Nokia Shanghai Bell draftCR Agreement
5.10.1Work Item (Vertical_LAN_SEC)
 		Yes
Yesit depends on study item.
 		noted No    
S3‑193528 Removal of ed.note on conformance tests Nokia, Nokia Shanghai Bell draftCR Agreement
5.10.1Work Item (Vertical_LAN_SEC)
 		Yes
Yes
 		approved No    
S3‑193529 Editorial correction of format Nokia, Nokia Shanghai Bell draftCR Agreement
5.10.1Work Item (Vertical_LAN_SEC)
 		Yes
Yes
 		revised No S3‑193705  
S3‑193530 Conclusion to key issue 2.3 Nokia, Nokia Shanghai Bell pCR Approval
5.10.2Study (FS_Vertical_LAN_SEC)
 		Yes
YesOrange: no conclusion for this one, noted BT is this related to multiple subscriptions
 		noted No    
S3‑193531 CR Interworking between NPN and PLMN Nokia, Nokia Shanghai Bell draftCR Agreement
5.10.1Work Item (Vertical_LAN_SEC)
 		Yes
YesE//: depends on result of study Nokia: document in Annex, in SA2, or subclause somewhere else QC: document separate fromm NPN DCM: not in SA2 QC: clarify this is about secondary authentication tdoc name of revision had to be changed to reflect content
 		revised No S3‑193706  
S3‑193532 CR Annex 5GLAN Nokia, Nokia Shanghai Bell draftCR Agreement
5.10.1Work Item (Vertical_LAN_SEC)
 		Yes
Yes
 		revised No S3‑193707  
S3‑193533 CR Annex TSC Nokia, Nokia Shanghai Bell draftCR Agreement
5.10.1Work Item (Vertical_LAN_SEC)
 		Yes
YesOrange: nothing required in our TS. Huawei: change NPN to SNPN Thales: prefer not to add anything now. Orange: also nothing is required for integrated NPNs. Title should be(to reflect content of contribution): CR Interworking between NPN and PLMN
 		noted No    
S3‑193534 KI on Protection of authentication subscription data stored in UDR Nokia, Nokia Shanghai Bell other Approval
5.17Study on storage and transport of the security parameters in a 5GC, that are used by the ARPF for Authentication (FS_5GC_sec_storage_transport)
 		Yes
YesKPN: Key issue is above transport and storage - better to split this into two key issues as only last sentence is about transfer Thales: modifcation of data need to authorised as well DCM: Needs security threat on confidentiality of data and also a threat on copying data to another subcription plus associated requirement TI: Need to understand what is the sensitive data and subscription authentication data KPN: Mention of transfer should also be deleted Vdf: Support DCM new threat
 		noted No    
S3‑193535 KI on Separation of authentication subscription data from subscription data Nokia, Nokia Shanghai Bell other Approval
5.17Study on storage and transport of the security parameters in a 5GC, that are used by the ARPF for Authentication (FS_5GC_sec_storage_transport)
 		Yes
YesCMCC: More of an implementation issue rather than a security issue as too difficult to separate them KPN: Support this key issue BT: support this key issue - modify to make it "stored and managed" separately CMMC: Feel that separtion is a soluiton and not a requirement BT: Biggest threat is people who are runnung the the network should not get access to the more sensitive data ID: Separate treatment of data is common DCM: Reformulate the requirement to compartmentalize the the data rather than store it separately TI: Propose EN that the used terms need to be defined Hua: Support CMCC comments
 		revised No S3‑193747  
S3‑193536 CIOT: Update of KI#12 description Ericsson pCR Approval
5.3.2Study (FS_CIoT_sec_5G)
 		Yes
YesQC: Why key issue needed as initial NAS Security covers them? BT: Thought we had agreement on protecting IEs by default Nok: don’t feel they are a privacy threat QC: don't need a key issue There was general agreement that initial NAS security should be used to protect these IEs but it was not clear in the meeting that the tex in TS 33.401 covered this.
 		noted No    
S3‑193537 CIOT: update to the evaluation of solution #24 Ericsson, Qualcomm Incorporated pCR Approval
5.3.2Study (FS_CIoT_sec_5G)
 		Yes
Yes
 		approved No    
S3‑193538 CIOT: recommendation to support solution #24 to solve KI #11 Ericsson, Qualcomm Incorporated pCR Approval
5.3.2Study (FS_CIoT_sec_5G)
 		Yes
Yes
 		approved No    
S3‑193539 CIOT: Conclusion on KI #4 Ericsson, Nokia, Nokia Shanghai Bell, Qualcomm Incorporated, Samsung pCR Approval
5.3.2Study (FS_CIoT_sec_5G)
 		Yes
YesSupport: cosigners Object: KPN, Huawei DCM: same as KPN conclusion, except for SA2 part, send LS to SA2 instead. Approved as LS has been sent
 		approved No    
S3‑193540 CIOT: Conclusion on KI #5 Ericsson Nokia, Nokia Shanghai Bell, Qualcomm Incorporated, Samsung pCR Approval
5.3.2Study (FS_CIoT_sec_5G)
 		Yes
YesNokia: solution 23 spreads load to other base stations Huawei: NWDAF to gNB interface is missing Huawei: remove first paragraph DCM: if NWDAF doesnt provide the information, then this needs to be added to LS Huawei: delete the sentence,
 		revised No S3‑193711  
S3‑193541 CIOT: Discussion on DDoS solutions for KI#4 and KI#5 Ericsson, Qualcomm Incorporated, Samsung pCR Approval
5.3.2Study (FS_CIoT_sec_5G)
 		Yes
Yes
 		noted No    
S3‑193542 CIOT: Title correction solution 13 Ericsson pCR Approval
5.3.2Study (FS_CIoT_sec_5G)
 		Yes
Yes
 		approved No    
S3‑193543 CIOT: Proposed conclusion to KI#10 Ericsson pCR Approval
5.3.2Study (FS_CIoT_sec_5G)
 		Yes
Yes
 		approved No    
S3‑193544 CIOT: Proposed conclusion to KI#7 Ericsson pCR Approval
5.3.2Study (FS_CIoT_sec_5G)
 		Yes
YesLenovo: add that stationary UE need more attention DCM: don't understand that limitation, keep E// contribution offline what to add for this.
 		revised No S3‑193712  
S3‑193545 CIOT: Proposed clarifications to KI#6 Ericsson pCR Approval
5.3.2Study (FS_CIoT_sec_5G)
 		Yes
Yes
 		approved No    
S3‑193546 CIOT: Proposed_conclusion_KI_8 Ericsson pCR Approval
5.3.2Study (FS_CIoT_sec_5G)
 		Yes
YesDCM: delete last sentence.
 		revised No S3‑193713  
S3‑193547 CIOT: Proposed_conclusion_KI_6 Ericsson pCR Approval
5.3.2Study (FS_CIoT_sec_5G)
 		Yes
Yes
 		approved No    
S3‑193548 CIOT: Update of Solution #14 Ericsson pCR Approval
5.3.2Study (FS_CIoT_sec_5G)
 		Yes
Yes
 		noted No    
S3‑193549 CIOT: Conclusion for KI#12 Ericsson pCR Approval
5.3.2Study (FS_CIoT_sec_5G)
 		Yes
YesE// presents, propose to say: no normative work is required.
 		revised No S3‑193714  
S3‑193550 Solution for trusted non-3GPP access Lenovo, Motorola Mobility draftCR Approval
5.4Security of the Wireless and Wireline Convergence for the 5G system architecture (5WWC_SEC)
 		Yes
Yes
 		revised No S3‑193685  
S3‑193551 Solution on 5GC access from WLAN UEs that do not support NAS Lenovo, Motorola Mobility draftCR Approval
5.4Security of the Wireless and Wireline Convergence for the 5G system architecture (5WWC_SEC)
 		Yes
YesOrange: questions whether the text is needed as they don't support authentication Len: There are some inter-working functions Orange: would like to see text that shows what is different to general authentication Len: will work offline to produce that text Thales: do not understand why use the term 'devices' Len: usage follows 23.502.
 		revised No S3‑193690  
S3‑193552 Conclusion on Key Issue#7 Lenovo, Motorola Mobility pCR Approval
5.3.2Study (FS_CIoT_sec_5G)
 		Yes
YesNokia: explain "missing freedom of key derivation" Lenovo: because there is only NCC in key derivation, the attacker can assume that NCC is incremented each time.
 		merged No S3‑193712  
S3‑193553 Clarification on cancellation of rejected S-NSSAIs Lenovo, Motorola Mobility pCR Approval
5.6.2Study (FS_eNS_SEC)
 		Yes
YesNokia: next tdoc, on same clauses.
 		revised No S3‑193737  
S3‑193554 Solution on Cancellation of rejected S-NSSAIs Lenovo, Motorola Mobility pCR Approval
5.6.2Study (FS_eNS_SEC)
 		Yes
Yes
 		noted No    
S3‑193555 Update of Solution #15 Lenovo, Motorola Mobility pCR Approval
5.55G security enhancement against false base stations (FS_5GFBS)
 		Yes
YesE//: how is this working reagrding NAS keys and serving network name E//: NAS SMC integrity failure could be because of radio failure Lenovo: that can't happen on NAS, maybe in PDCP E//: ed note: whether NAS layer integrity protection could fail due to radio conditions E//: ed note: are NAS SMC failures only due to causes mentioned in this solution are FFS QC: similar comment, second ed note has not been addressed Lenovo: ok QC:add ed note further evaluation is FFS 1 ed note: NAS failures, bring back ed note on error handling, ednote in evaluation further evaluation is ffs.
 		revised No S3‑193836  
S3‑193556 Update of solution #6 Lenovo, Motorola Mobility pCR Approval
5.16Study on Security Aspects of 3GPP support for Advanced V2X Services (FS_eV2X_Sec)
 		Yes
Yes
 		noted No    
S3‑193557 Identifier conversion in groupcast communication Lenovo, Motorola Mobility pCR Approval
5.16Study on Security Aspects of 3GPP support for Advanced V2X Services (FS_eV2X_Sec)
 		Yes
YesHuawei: second last sentence first para, why in oder not to signal Lenovo: so in order not to update Huawei: so interval dT is fixed.problem with time synchronization QC: remove evaluation line, basically application layer manages time interval IDCC: use time for synchronization, use unprotected SIB or unprotected time source. add ed note on how to deal with spoofed time source is ffs DCM: changing of group id may identify group members BT: how to deal with impact on availability is ffs remove evaluation, ednote from IDCC and BT
 		revised No S3‑193804  
S3‑193558 DraftCR – Control Plane optimized solution Ericsson other Approval
5.3.1Work Item (CIoT_sec_5G)
 		Yes
YesEditor's note from this document should be merged into S3-193818 (update of S3-193485).
 		merged No S3‑193818  
S3‑193559 DraftCR – RRC Connection Re-Establishment for the control plane for NB-IoT connected to 5GC Ericsson other Approval
5.3.1Work Item (CIoT_sec_5G)
 		Yes
YesAwaiting SA2 descion on truncating S-TMSI.
 		noted No    
S3‑193560 DraftCR – Control Plane optimized solution Ericsson other Approval
5.3.1Work Item (CIoT_sec_5G)
 		No
Yes
 		withdrawn Yes    
S3‑193561 DraftCR – NAS based redirection between 5GS and EPC Ericsson other Approval
5.3.1Work Item (CIoT_sec_5G)
 		Yes
Yes
 		approved No    
S3‑193562 DraftCR - Proposed skeleton for supporting 5G CIoT [Living Document] Ericsson other Approval
5.3.1Work Item (CIoT_sec_5G)
 		Yes
Yes
 		revised No S3‑193716  
S3‑193563 Draft CR as a living baseline for 5GS LCS normative work Ericsson LM draftCR Approval
5.7Security of the enhancement to the 5GC location services (eLCS_Sec)
 		Yes
YesHuawei: Prefer S3-193563 over S3-193434 - add an EN about bluetooth public name and public address is FFS and one about connection to false access point is FFS BT: EN should be about corrupting data collection DCM: Need an EN on linking names to network Interdigital: If the data is collected without vefirication, then it has no value as it could be be faked to provide an attack. QC: Text should be a new Annex.
 		revised No S3‑193702  
S3‑193564 [Draft CR]Solution for IAB Architecture Samsung draftCR  
5.15.1Work Item (NR_IAB_Sec)
 		Yes
YesBT: the IAB node needs to be protected like a gNB Samsung: add in next meeting together with 611
 		revised No S3‑193808  
S3‑193565 Updates to Solution #2.1 on MT functionality Samsung pCR  
5.15.2Study (FS_NR_IAB_Sec)
 		Yes
YesE//: is this copy paste from SA2 Samsung: yes Huawei: Note how the IAB node… within UICC is not used, Thales: why is the note there at all Nokia: in 23.501, IoB node has gNB functionality, could be many platforms QC: comment on paragraph above node, bacuse with EPC, there is no EAP support. should be treated as UE in 33.501. prefer the defined primary authentication methods. Samsung: may be true for one kind of implementation DCM: stick to existing authentication mechanisms Nokia: need to be flexible, Huawei: maybe treat IAB as NPN UE Samsung: restrict option for EPC.
 		revised No S3‑193788  
S3‑193566 Draft TR 33.845 Storage of sensitive credentials in 5G systems v0.0.0 VODAFONE Group Plc draft TR Approval
5.17Study on storage and transport of the security parameters in a 5GC, that are used by the ARPF for Authentication (FS_5GC_sec_storage_transport)
 		Yes
YesIntroduction removed Duplicate clauses removed
 		revised No S3‑193744  
S3‑193567 Evaluation of solution #2.1 Samsung pCR  
5.15.2Study (FS_NR_IAB_Sec)
 		Yes
YesDCM: ok, problem is only whether we restrict further
 		revised No S3‑193789  
S3‑193568 Conclusion to Key Issue#2.1 on authentication and authorization of the IAB Node (MT) Samsung pCR  
5.15.2Study (FS_NR_IAB_Sec)
 		Yes
YesQC: solution 2.1 is open DCM: be more specific what will be normative Nokia: fine with the contribution as is Chair only Note and para above is open of 2.1 Thales: same problem, keep open
 		revised No S3‑193790  
S3‑193569 CIOT: Discussion paper on ngKSI for NB-IoT in 5G-CIoT. Ericsson discussion Endorsement
5.3.1Work Item (CIoT_sec_5G)
 		Yes
Yes
 		noted No    
S3‑193570 CIOT: Discussion paper on short MAC-I for NB-IoT in 5G-CIoT. Ericsson discussion Endorsement
5.3.1Work Item (CIoT_sec_5G)
 		Yes
Yes
 		noted No    
S3‑193571 Draft LS reply on LS on short MAC-I and ngKSI for 5G-CIoT Ericsson LS out Approval
5.3.1Work Item (CIoT_sec_5G)
 		Yes
YesQC: first answer: make it shorter, not a security issue DCM: if inteintegrity protection fails, then there is possibility of mismatch and of attack QC: there can't be a mismatch on CPSR message offline QC: second question: shorter, simply say no. agree to not reduce reduced size MAC.
 		revised No S3‑193715  
S3‑193572 Evaluation of solution #3.1 Samsung pCR  
5.15.2Study (FS_NR_IAB_Sec)
 		Yes
YesQC: unclear where the requirement comes from. E//: support QC, interface security should look the same for wireless and wireline Nokia: prefer 572 QC: why one credential, how do you attach to management server.
 		noted No    
S3‑193573 Conclusion to Key Issue#2.1 on authentication and authorization of the IAB Node (gNB-DU) Samsung pCR  
5.15.2Study (FS_NR_IAB_Sec)
 		Yes
YesDCM: think about platform security keys Samsung: IAB has gNB requirements, so no platform security
 		revised No S3‑193792  
S3‑193574 Solution for Resumecause protection Samsung pCR  
5.55G security enhancement against false base stations (FS_5GFBS)
 		Yes
YesEri: Solution is not needed Sam: In case of conjestion, then short-MAC-I may not be checked Huawei: Disagree with this solution.
 		noted No    
S3‑193575 Evaluation of solution#14 in TR 33.809 Samsung pCR  
5.55G security enhancement against false base stations (FS_5GFBS)
 		Yes
YesQC: disagree, first statement is false, because step 1 is only after AS security set up, it is to protect SIB messages, not against fake base stations Apple: support Samsung E//: same comment Huawei: support QC Orange: support QC.
 		noted No    
S3‑193576 Updates to Solution#7 on obtaining accurate clock information Samsung pCR  
5.55G security enhancement against false base stations (FS_5GFBS)
 		Yes
Yes
 		approved No    
S3‑193577 Deletion of EN on Location update reject in Solution#7 Samsung pCR  
5.55G security enhancement against false base stations (FS_5GFBS)
 		Yes
YesHuawei: whem UE sends reg req message, this is not integrity protected. Add ed note or note this Samsung: not part of solution, QC: keep ed note and note this, as it doesn't explain E//: support, but ok to note to make progress
 		noted No    
S3‑193578 Delete the Evaluation for Solution 5 in TR 33.853 China Mobile pCR Approval
5.12Study on User Plane Integrity Protection (FS_UP_IP_Sec)
 		Yes
YesQC: PDCP is not aware whether traffic is IP or not IP but agree the sentence is not correct
 		approved No    
S3‑193579 Resolving Editor’s Note in Solution #1 Samsung pCR  
5.12Study on User Plane Integrity Protection (FS_UP_IP_Sec)
 		Yes
YesQC: Do not agree to delete EN as there are other attacks and also SIP signalling not a good example as this has its own protection BT: Needs to consider all control plane protections and other sensitive traffic not just the listed ones DCM: Need to clarify that all the protected data is less than 64Kbits QC: OK if we note other data not protected Nok: is this new capability Samsung: exisiting capability
 		revised No S3‑193695  
S3‑193580 Add the Evaluation to Solution 5 in TR 33.853 China Mobile pCR  
5.12Study on User Plane Integrity Protection (FS_UP_IP_Sec)
 		Yes
YesQC: All the parts of the evaluation need to be re-written Nok: Need to detremoine if just header or the whole packets needs to be protected QC: Agree with this but that there are many other issues as well
 		revised No S3‑193696  
S3‑193581 Conclusion to Key Issue #5 Samsung pCR  
5.12Study on User Plane Integrity Protection (FS_UP_IP_Sec)
 		Yes
YesQC: does not agree with the conclusion.
 		noted No    
S3‑193582 skeleton of AKMA TS China Mobile, Nokia, Nokia Shanghai Bell draft TS Approval
5.2.1Work Item (AKMA)
 		Yes
YesHuawei: Prefer CMCC version QC: OK to merge but think that there are good sections in Ericsson which should be kept.
 		revised No S3‑193769  
S3‑193583 scope of AKMA TS China Mobile, Nokia, Nokia Shanghai Bell pCR Approval
5.2.1Work Item (AKMA)
 		Yes
YesQC: Remove 3GPP and change to subscription credentials. Orange: Reference the subscription credentials in TS 33.501 - align terminology with study. QC: Remove the bullet list paragraph Orange: Remove the 2nd sentence of first paragraph.
 		revised No S3‑193770  
S3‑193584 draft CR of AKMA architecture China Mobile, Nokia, Nokia Shanghai Bell pCR Approval
5.2.1Work Item (AKMA)
 		Yes
Yes
 		revised No S3‑193771  
S3‑193585 conclusion on key issue #2 China Mobile pCR Approval
5.2.2Study (FS_AKMA)
 		Yes
YesEri: Key issue does not security theats or requirements - which messages are used CMCC: To use NAS procedures between UE and 5GC QC: Also struggle to see what the conclusion means.
 		revised No S3‑193767  
S3‑193586 Conclusion on key issue #5 China Mobile pCR Approval
5.2.2Study (FS_AKMA)
 		Yes
YesHuawei: Two conclusions are not competing QC: Can make a conclusion on deriving identifier for K_AUSF Huawei: In the TR there is a temporary identifier.
 		revised No S3‑193768  
S3‑193587 Conclusion on key issue #6 China Mobile, KPN pCR Approval
5.2.2Study (FS_AKMA)
 		Yes
YesEri: Do not agree with conclusion as this could be left applications QC: Agree with ericsson comment BT: Conclude on this issue now but either need it done properly or not at all CMMC: This is a customer requirement QC: This is in the scope of the application ZTE: Think that this is an important requirement.
 		noted No    
S3‑193588 Conclusion on key issue #13 China Mobile pCR Approval
5.2.2Study (FS_AKMA)
 		Yes
YesQC: OK but do you expect changes to UE/UICC or keep it open CMCC: keep it open.
 		approved No    
S3‑193589 Editorial Changes to TR 33.835 China Mobile pCR Approval
5.2.2Study (FS_AKMA)
 		Yes
YesQC: Editorial - think that the Voids can be removed as not under change control.
 		approved No    
S3‑193590 Individual Evaluation of solution #6 China Mobile pCR Approval
5.2.2Study (FS_AKMA)
 		Yes
Yes
 		approved No    
S3‑193591 Evaluation of solution#1 China Mobile pCR Approval
5.2.2Study (FS_AKMA)
 		Yes
YesEricsson: Solution addresses a problem that is not actually for AKMA.
 		approved No    
S3‑193592 Evaluations of solution #7- #12 China Mobile pCR Approval
5.2.2Study (FS_AKMA)
 		Yes
Yes
 		approved No    
S3‑193593 Udpate to Solution #3 Samsung pCR  
5.10.2Study (FS_Vertical_LAN_SEC)
 		Yes
YesNokia: what are various factors? Samsung remove "based on various factors", add ed note that factors should be listed Nokia: better come back next time. Samsung: give a few factors in this meeting BT: concerned about dynamic factors in UDM.
 		noted No    
S3‑193594 Key Issue #6.1 conclusion Samsung pCR  
5.10.2Study (FS_Vertical_LAN_SEC)
 		Yes
Yes
 		noted No    
S3‑193595 Solution Key lifetimes Ericsson pCR Approval
5.2.2Study (FS_AKMA)
 		Yes
YesQC: OK with proposal and analysis. Normative text on requirements in evaluation should go away.
 		revised No S3‑193765  
S3‑193596 Skeleton of clause 4 and selected content for AKMA normative work Ericsson pCR Approval
5.2.1Work Item (AKMA)
 		Yes
Yes
 		merged No S3‑193769  
S3‑193597 Solution #15 evaluation removal of EN Ericsson pCR Approval
5.2.2Study (FS_AKMA)
 		Yes
Yes
 		approved No    
S3‑193598 Conclusions on Key management Ericsson pCR Approval
5.2.2Study (FS_AKMA)
 		Yes
YesBT: This is important that application key outlives the root anchor. Supports the evaluation.
 		approved No    
S3‑193599 AKMA architecture reference model Ericsson pCR Approval
5.2.1Work Item (AKMA)
 		Yes
Yes
 		merged No S3‑193771  
S3‑193600 AKMA Key hierarchy Ericsson pCR Approval
5.2.1Work Item (AKMA)
 		Yes
YesThere is a competing proposal in S3-193469 Orange: Correct names based on agreements- text in S3-193469 is not correct as it talks about AKMA authentication QC: Just show the derivation of K_AUSF and reference TS 33.401 for the rest of the derivations.
 		revised No S3‑193772  
S3‑193601 Existing authentication procedure lacking PFS property Ericsson pCR Approval
5.14Study on authentication enhancements in 5GS (FS_AUTH_ENH)
 		Yes
YesOrange: what is the problem E//: PFS is the problem CMCC: agree with E//, enhance the authentication, solve the issue if long term key is leaked, could revise auth protocol, or do something else to prevent long term key leakage BT: balance between prevention, detection and response Huawei: support E// paper, in security requirerment remove "if", or say provide forward security DCM: need to see whether this is worth it considering the data is only protected over the air Thales: decision already some meetings ago not to study BT: need to document whether or not it is worth it. Show of hands who supports this key issue: CMCC, BT, Aple, E//, Huawei, ZTE, Nokia; objects: Thales, Orange
 		noted No    
S3‑193602 Correction of conclusion for Key Issue #1 Ericsson pCR Approval
5.55G security enhancement against false base stations (FS_5GFBS)
 		Yes
Yes
 		approved No    
S3‑193603 New Solution: Protection of the whole RRCResumeRequest message Ericsson pCR Approval
5.55G security enhancement against false base stations (FS_5GFBS)
 		Yes
YesApple: support this solution Huawei: missing disadvantage, like increase in length, or processing E//: put in a ednote? Huawei: straight forward: disadvantage: increase of processing timei DCM: make this an ed note, because it is not clear that copying IEs adn running hash over a shorter message has overhead of copying QC: mixed deployments between R15 and R16 in network and with UEs. Ed Note: the impact of working with legacy UEs and base stations are ffs Orange: not have evaluation this time, because of ed notes. remove evaluation, add ed note in solution details.
 		revised No S3‑193753  
S3‑193604 Way forward for KI#1 against tampering of RRCResumeRequest messages Ericsson pCR Approval
5.55G security enhancement against false base stations (FS_5GFBS)
 		Yes
Yes
 		noted No    
S3‑193605 Way forward for KI#3 with respect to handover to a False basestation Ericsson pCR Approval
5.55G security enhancement against false base stations (FS_5GFBS)
 		Yes
Yes
 		noted No    
S3‑193606 Way forward for KI#4 on protection against SON poisoning Ericsson discussion Endorsement
5.55G security enhancement against false base stations (FS_5GFBS)
 		Yes
YesApple: support this way forward E//: could send an LS to SA5 that measurements could be untrustworthy Orange: not from this meeting, need to discuss internally QC: we previously discussed about measurements reports, make it generic, not only false base station Futurewei: what do we expect SA5 to do with this E//: take this into account Futurewei: how should they know that the report was falsified Orange: it may be more generic than false base station, look more closely before deciding on what and whether to send QC: keep LS generic if sent from next meeting, the 2nd proposal in presentation was to have no normative work E//: not put in that proposal because of what SA5 could respond Apple: can there be an agreement to send an LS, so bring LS directly, so we can focus on content.
 		noted No    
S3‑193607 Way forward for KI#5 mitigation against authentication relay. Ericsson pCR Approval
5.55G security enhancement against false base stations (FS_5GFBS)
 		Yes
Yes
 		noted No    
S3‑193608 Way forward for KI#6 about the resistance to radio jamming Ericsson pCR Approval
5.55G security enhancement against false base stations (FS_5GFBS)
 		Yes
YesQC: add because it can't be addressed by SA3, include reason no objections to the conclusion, just add the reason.
 		revised No S3‑193837  
S3‑193609 Way forward for KI#7 about the protection against Man-in-the-Middle false basestation attacks Ericsson pCR Approval
5.55G security enhancement against false base stations (FS_5GFBS)
 		Yes
YesQC: need to evaluate solutions for this one
 		noted No    
S3‑193610 New solution (SERSI – SERving network controlled SI signatures). Ericsson pCR Approval
5.55G security enhancement against false base stations (FS_5GFBS)
 		Yes
YesQC: this is just duplicating existing solution, so note Apple: support solution Samsung: key difference is including PCI and freq in signature, therefore merge into exisiting solution QC: fine in principle, but bring this to next meeting chaiir: try to avoid in next meeting QC: ok make into pCR of solution 7, figure and explanation Orange: what changes in the evalution QC: keep evaluation out. E//. then agree on somtething for next meeting DCM: make pcr adding PCI and DLfreq are input to signature in solution details of solution 7, add ed note to evaluation that impact of new inputs is ffs. this is agreed.
 		revised No S3‑193755  
S3‑193611 DraftCR –Security handling for IAB Ericsson draftCR Approval
5.15.1Work Item (NR_IAB_Sec)
 		Yes
YesQC: prefer Samsung proposal Nokia: need some merger, start with Samsung proposal Nokia: there is no IAB network, it is an IAB node QC: diagram shows IAB architecture, not security architecture QC: approach is model after SNPN, disagree with that approach, prefer the main clauses of 501 and 401 offline, merge into 808 Todor: no coontent from was taken from 611 Samsung: correct
 		merged No S3‑193808  
S3‑193612 Clarification on identities in TLS and token-based authorization Ericsson discussion Endorsement
5.1.2Study (FS_SBA-Sec)
 		Yes
YesHuawei: Does not agree with proposal - need to know how to allocate instnace Id and certificate first DCM: How would this work for scenario D? Does SECOP have NF instance IDs that it would use as transport IDs Eri: Do you mean that SECOP case is not covered?
 		noted No    
S3‑193613 Clarification on delegated subscribe-notify Ericsson discussion Endorsement
5.1.2Study (FS_SBA-Sec)
 		Yes
Yes
 		noted No    
S3‑193614 LS on token-based authorization for indirect communication with delegated discovery (Scenario D) Ericsson LS out Approval
5.1.2Study (FS_SBA-Sec)
 		Yes
YesSome comments given in offline e-mail discussion Nok: Update the question to SA2 and additional questions needed.
 		revised No S3‑193724  
S3‑193615 Implementation of agreed change from SA3#96 Ericsson pCR Approval
5.1.2Study (FS_SBA-Sec)
 		Yes
Yesit is missing implementation from the last meeting.
 		approved No    
S3‑193616 Update to conclusion on Key issue #22: Authorization of NF service access in indirect communication Ericsson pCR Approval
5.1.2Study (FS_SBA-Sec)
 		Yes
YesWait for SA2 response LS to S3-193724 before progress can be made.
 		noted No    
S3‑193617 Update to conclusion on Key issue #23: NF to NF authentication and authorization in Indirect communication Ericsson pCR Approval
5.1.2Study (FS_SBA-Sec)
 		Yes
YesKept open for offline discussions DCM: authorization may not be so static.
 		noted No    
S3‑193618 Conclusion of Key Issue #24 Service access authorization within a NF Set or a NF Service Set Ericsson pCR Approval
5.1.2Study (FS_SBA-Sec)
 		Yes
YesDCM: support this as a conclusion.
 		noted No    
S3‑193619 New solution for Key Issue #25 "Indirect communication in roaming scenarios" Ericsson pCR Approval
5.1.2Study (FS_SBA-Sec)
 		Yes
YesNokia: Sentence in intro about 'authentication between NFs in different networks is implicit by ….' Huawei: Telescopic FQDN use requires an EN. DCM: Got confused that SECOP is split across PLMNs - make it clear that SECOP does not span multiple PLMNs by adding a sentence. Huwaei: Clarification needed in roaming scenarion that interface between SECOP and SEPP is a PLMN.
 		revised No S3‑193725  
S3‑193620 Conclusion for Key Issue #25 "Indirect communication in roaming scenarios" Ericsson pCR Approval
5.1.2Study (FS_SBA-Sec)
 		Yes
YesHuawei: Postpone due to EN on telescopic FQDN Nok: OK to make progress even with that EN DCM: Agree with Nokia and propose EN is added to conclusion - this was agreeable to meeting.
 		revised No S3‑193726  
S3‑193621 Conclusion of Key Issue #28: Service access authorization in the delegated "Subscribe-Notify" scenarios Ericsson pCR Approval
5.1.2Study (FS_SBA-Sec)
 		Yes
Yes
 		noted No    
S3‑193622 Resource Level Authorization using Access Tokens Ericsson draftCR Approval
5.1.1Work Item (SBA_Sec)
 		Yes
YesHuawei: Concened that there may be SA2 impacts and would like to postpone document. Eri: How is the UDR impacted. Huawei: EN on SA2 impact and UDR study may affect this. Nok: Solution is overloading scope DCM: Not clear on what is being mandated.
 		noted No    
S3‑193623 TLS certificates for SBA: profile and provisioning Ericsson discussion Endorsement
6Any Other Business
 		Yes
YesCMCC: not to include provisioning in study Huawei: without provisioning, the solution is already in eSBA QC: is this also for RAN, or only core? E//: this is core netowrk only QC: useful to include gNB in scope for certificate enrolment Nokia: profile needs to be defined, especially in virtual environment, profile in R16, provisioning in R17 BT: revocation and deprovisioning needs to included
 		noted No    
S3‑193624 Authorization using Access Tokens based on NF-Subtype Ericsson draftCR Approval
5.1.1Work Item (SBA_Sec)
 		Yes
YesNok: No key issue so should not have a solution until this is agreed Huawei: Concerns raised for S3-193622 apply here.
 		noted No    
S3‑193625 Conclusion for Key Issue #5 "NF-NF Authorization" Ericsson pCR Approval
5.1.2Study (FS_SBA-Sec)
 		Yes
Yes
 		noted No    
S3‑193626 Evaluation update for Solution #25 Ericsson pCR Approval
5.1.2Study (FS_SBA-Sec)
 		Yes
YesHuawei: Do not agree with the proposed evaluation
 		noted No    
S3‑193627 Draft CR: UP security policy for URLLC Ericsson draftCR Approval
5.8Security for 5G URLLC (5G_URLLC_SEC)
 		Yes
YesHuawei: OK with 2nd modification - 1st modification adds redundant text Nok: Agree with Huawei DCM: consider the normative language in the document
 		revised No S3‑193701  
S3‑193628 Discussion Paper for Security of Performance Measurement Function Protocol Apple Computer Trading Co. Ltd discussion Agreement
4Incoming LS
 		Yes
YesNokia: all UP is integrity protected between UE and BS, so do we need more protection Apple: UP IP protection is good to have, but discussion is about whether, not how Nokia: protocol needs protection, but no further protectino is required. It is already protected. But no reply is required in this meeting Noamen: this was flagged as urgent QC: no additional security required. disagree with Apple discussion paper Apple: UP IP is optional. CT1 is only asking about problems, not about solution QC: LS should say we don't need additional security Huawei: no additional security is required DCM: respond: UP IP will be sufficitent E//: agree with QC that IP will not address all problems. Apple: PMF protocol needs to be protected
 		noted No    
S3‑193629 New SID on EPS AKA and EAP-AKA privacy enhancement in EPS Apple, Google, AT&T, Verizon UK Ltd, Accuris Networks, Charter Communications, Cablelabs, Article19, Sprint, Comcast, Broadcom SID new Approval
6Any Other Business
 		Yes
YesCMCC: does not support this QC: is for R17, was already studied in R15, so why should be possible now Nokia: shouldn't be started because it would waste time BT: explicitly look at migration strategy and bid down prevention Orange: in places talking about authentication method, talk about the access, from where to where should the IMSI be concealed.
 		noted No   S3‑193510
S3‑193630 ARPF Deployment models Ericsson pCR Approval
5.17Study on storage and transport of the security parameters in a 5GC, that are used by the ARPF for Authentication (FS_5GC_sec_storage_transport)
 		Yes
YesNok: Do not think that the level of detail is needed for this TR BT: Think it is useful so suggets putting in an Annex KPN: Agree that is should go there TI: Some content should go in but does not fit with skeleton
 		noted No    
S3‑193631 Trusted access key hierarchy Ericsson draftCR Approval
5.4Security of the Wireless and Wireline Convergence for the 5G system architecture (5WWC_SEC)
 		Yes
YesHuawei: this is not the agreement in TR, additional argument is required why is this required. E//: makes mobility easier Lenovo: what kind of mobility E//: between TNAPs. BT: What are TNAP keys for: different devices, or different versions (updates) of keys in the same ME.
 		noted No    
S3‑193632 Trusted access key derivation Ericsson draftCR Approval
5.4Security of the Wireless and Wireline Convergence for the 5G system architecture (5WWC_SEC)
 		Yes
YesHuawei: related to 631 offline discussions, to be taken back next time.
 		noted No    
S3‑193633 Subscriber privacy for wireline access Ericsson draftCR Approval
5.4Security of the Wireless and Wireline Convergence for the 5G system architecture (5WWC_SEC)
 		Yes
Yes
 		approved No    
S3‑193634 Security Parameter Storage Ericsson pCR Approval
5.17Study on storage and transport of the security parameters in a 5GC, that are used by the ARPF for Authentication (FS_5GC_sec_storage_transport)
 		Yes
YesKPN: Confused about the limiting the storage in this contribution - move text in scenario C to model B and remove text about model A as out of scope TI: realtionship between the various parameters need to be clarified Nok: Clause 4.2.1 should not be included as it is the wrong part of TR DCM: Part of 4.2.1 is wrong
 		noted No    
S3‑193635 Clarification to the usage of Kausf for solution #2.2 in TR 33.846 China Mobile pCR Approval
5.14Study on authentication enhancements in 5GS (FS_AUTH_ENH)
 		Yes
YesNokia: how can KAUSF work on the failed procedure. Orange: if there is no previous KAUSF, then there is no protection, add ed note: security of using KAUSF=0 is FFS
 		noted No    
S3‑193636 Discussion on the SUPI guessing attack China Mobile discussion Discussion
5.14Study on authentication enhancements in 5GS (FS_AUTH_ENH)
 		Yes
Yes
 		noted No    
S3‑193637 Key issue to mitigate the SUCI guessing attacks in TR 33.846 China Mobile pCR Approval
5.14Study on authentication enhancements in 5GS (FS_AUTH_ENH)
 		Yes
YesDCM: how to deal with threats that we decided to be not relevant Orange: agree, maybe remove threats and requirements E//: same problem, keep threat, add editor's note Nokia: can'T determine on individual SUPI DCM: ed note: impact of threat is FFS Orange: have threat: the attacker is able to determine whether a SUPI belongs to a given network, + ed note ed note, Orange's sentence on threat, remove requirements - FFS
 		revised No S3‑193810  
S3‑193638 Clarifying GVNP model of type 2 China Mobile pCR Approval
5.9Study on SECAM and SCAS for 3GPP virtualized network products (FS_VNP_SECAM_SCAS)
 		Yes
Yes
 		approved No    
S3‑193639 Adding description for Generic virtualized network product model of type 3 China Mobile pCR Approval
5.9Study on SECAM and SCAS for 3GPP virtualized network products (FS_VNP_SECAM_SCAS)
 		Yes
YesBT: in hardware sectino, hardware is not necessarily COTS, maybe in telecoms it is remove that sentence E//: add the same editors note as on type 1 and 2., add ed note which ETSI specifications are being referred to Nokia: on hardware change description of picture: "hardware layer in addition to 3GPP", following sentence:VNF -> VNFC, add word "layer" in hardware. Remove last sentence in clause x.4, ed note under teh diagram, and ed note for reference, + Nokia changes. Nokia: more comments offline.
 		revised No S3‑193786  
S3‑193640 Adding Generic assets and threats of GVNP for type 1 into clause 5.2.3.b China Mobile pCR Approval
5.9Study on SECAM and SCAS for 3GPP virtualized network products (FS_VNP_SECAM_SCAS)
 		Yes
YesNokia: ed ntoe about moving this to 900 series TR CMCC: need to finalize this first, then move over Nokia: ok BT: .b.2.3: say that there are two "relevant" interfaces, because more are defined; b.2.10, list identical to no virtual system, virtualization layer threats need to added, add editor's note keep open for offline
 		revised No S3‑193787  
S3‑193641 Adding Generic assets and threats of GVNP for type 2 into clause 5.2.3.c China Mobile pCR Approval
5.9Study on SECAM and SCAS for 3GPP virtualized network products (FS_VNP_SECAM_SCAS)
 		Yes
YesBT: this needs more work to defferentiate from nomral scas, but ok to put in. E//: reference etc. as for 640 goes offline
 		revised No S3‑193831  
S3‑193642 Adding Generic assets and threats of GVNP for type 3 into clause 5.2.3.d China Mobile pCR Approval
5.9Study on SECAM and SCAS for 3GPP virtualized network products (FS_VNP_SECAM_SCAS)
 		Yes
Yes
 		revised No S3‑193832  
S3‑193643 Adding security requirements into clause 5.2.4 China Mobile pCR Approval
5.9Study on SECAM and SCAS for 3GPP virtualized network products (FS_VNP_SECAM_SCAS)
 		Yes
YesNokia: in diagram, ETSI defines GR, GS not TR, TS; in 5.2.4.2. not define a new catalogue, but have it as extension CMCC: can't change figure now, ed ntoe instead BT: replace specified in 5.2.4.2 for identified, as TR doesn't specify ed note to revise figure to change TR and TS to GR and GS for; rephrase first para of 5.2.4.2 to make it into extension instead of addition
 		revised No S3‑193833  
S3‑193644 applying TR33.818 with new 3GPP_TS-TR_Template China Mobile draft TR Approval
5.9Study on SECAM and SCAS for 3GPP virtualized network products (FS_VNP_SECAM_SCAS)
 		Yes
Yes
 		approved No    
S3‑193645 Meeting minutes of VNP_SECAM_SCAS conference call on 25th September China Mobile discussion Information
5.9Study on SECAM and SCAS for 3GPP virtualized network products (FS_VNP_SECAM_SCAS)
 		Yes
Yes
 		noted No    
S3‑193646 UPIP: update of solution #7 and addition of evaluation Ericsson pCR  
5.12Study on User Plane Integrity Protection (FS_UP_IP_Sec)
 		Yes
YesQC: Please the impacted elements to the evaluation and also an EN on consideration of mixed deployments where some elements are upgraded Nok: Why do we need an indication if this mandatory for Rel-16 Ues QC: There are multiple ways of indicating this capability of which this is one
 		revised No S3‑193697  
S3‑193647 Privacy Aspects of ARPF deployment Ericsson pCR Approval
5.17Study on storage and transport of the security parameters in a 5GC, that are used by the ARPF for Authentication (FS_5GC_sec_storage_transport)
 		Yes
YesNok: remove last paragraph and shift 3rd paragraph to become 2nd paragraph
 		revised No S3‑193748  
S3‑193648 draft LS to SA2 on the procedure of Secondary authentication China Mobile Com. Corporation LS out  
5.6.1Work Item (eNS_SEC)
 		Yes
Yes
 		withdrawn Yes    
S3‑193649 Add Clarifications to the Scope of Accreditation for 3GPP VNPs Nokia, Nokia Shanghai Bell pCR Approval
5.9Study on SECAM and SCAS for 3GPP virtualized network products (FS_VNP_SECAM_SCAS)
 		Yes
YesCMCC: About EN, do we need to send an LS to the GSMA - maybe from next meeting Eri: Why accreditation process does not need to be used Nok: If consenus, then not needed as previously agreed Huawei: Can remove accreditatio process part Nok: Sentence the same in current SECAM specifications Eri: GSMA is saying that ISO accreditation in needed Taken offline to discuss that part only. Nokia: ok to delete the added sentence in Scope Sentence is to be removed "The same applies ... Desires".
 		revised No S3‑193849  
S3‑193650 Add Clarifications to Ultimate Output of SECAM Evaluation Nokia, Nokia Shanghai Bell pCR Approval
5.9Study on SECAM and SCAS for 3GPP virtualized network products (FS_VNP_SECAM_SCAS)
 		Yes
YesCMCC: Concerned specifications not known Hua: Agree with concern Hua: Believe the evidence is required and sentence on no evidence should not be added BT: Thought that the idea was for vendor to get their equipment checked CMCC: There are two ways that SECAM can work two ways DCM: Agree that sentence should not be added
 		revised No S3‑193780  
S3‑193651 Add Clarifications to 3GPP virtualized network product evaluation process Nokia, Nokia Shanghai Bell pCR Approval
5.9Study on SECAM and SCAS for 3GPP virtualized network products (FS_VNP_SECAM_SCAS)
 		Yes
YesBT: May want to consider this as a certification scheme due to Cybersecurity act - propose to change the sentence on 'out of scope of SECAM'. Hua: first change change to may makes it optional which not sure is correct
 		revised No S3‑193782  
S3‑193652 Add Clarifications to Roles in SECAM for 3GPP virtualized network products Nokia, Nokia Shanghai Bell pCR Approval
5.9Study on SECAM and SCAS for 3GPP virtualized network products (FS_VNP_SECAM_SCAS)
 		Yes
YesHuawei: oshould say other SDO than applicable in diagram Nokia: discussion with CMCC: leave out other SDO DCM: why remove other SDOs? CMCC: other SDOs will provide requirements to 3GPP to integrate into SCAS agreement: only change diagram. E//: why is the half sentence added. Nokia: complete sentence, GSMA is curerntly SECAM accreditation body.
 		revised No S3‑193783  
S3‑193653 Add Clarifications to SECAM Assurance Level for 3GPP VNPs Nokia, Nokia Shanghai Bell pCR Approval
5.9Study on SECAM and SCAS for 3GPP virtualized network products (FS_VNP_SECAM_SCAS)
 		Yes
YesNokia: offline discussion with CMCC: SECAM assutance level completely differnt from ETSI NFV levels. Remove sentence in ed note. BT: decide on a mapping, rather than on which level. BT: the editor's note needs to be deleted or braought back. mapping is not possible, because NFV assumes starting from bottom (hardware), but SECAM doesn't do that. so delete references to NFV assurance levels. second paragraph on clause 4.8.1 removed, delete editor's note in 4.8.2
 		revised No S3‑193784  
S3‑193654 UICC removal from IAB-node THALES pCR Approval
5.15.2Study (FS_NR_IAB_Sec)
 		Yes
YesDCM: a bit like a solution, but threats are valid QC: question whether threats exist in case same key is used E//: first sentence sounds like IAB always conatins UICC DCM: if no UICC is used, then key could be stolen in a different way offline try to merge into 793
 		merged No S3‑193793  
S3‑193655 Add Clarifications to Security Baseline for 3GPP VNPs Nokia, Nokia Shanghai Bell pCR Approval
5.9Study on SECAM and SCAS for 3GPP virtualized network products (FS_VNP_SECAM_SCAS)
 		Yes
Yes
 		approved No    
S3‑193656 Add Clarifications to SCAS documents structure and content Nokia, Nokia Shanghai Bell pCR Approval
5.9Study on SECAM and SCAS for 3GPP virtualized network products (FS_VNP_SECAM_SCAS)
 		Yes
YesBT: if the direction is to reduce the testing to teh virtual product, then this decision is too early. Huawei: currently prefer to work directly in 33.926. Nokia: the decision is not made BT: but then they are identical for teh NFs to the self contained products. DCM: note document? CMCC: remove the contentious paragraph in 5.1 remove added paragraph in 5.1
 		revised No S3‑193785  
S3‑193657 Add Clarifications to generic virtualized network product model description Nokia, Nokia Shanghai Bell pCR Approval
5.9Study on SECAM and SCAS for 3GPP virtualized network products (FS_VNP_SECAM_SCAS)
 		Yes
YesCMCC: what is the reference [x]? Nokia: will include missing reference CMCC: name of local logical interface, change to execution interface Nokia: maybe rename to execution environment interface DCM: please provide definitino for next time
 		revised No S3‑193834  
S3‑193658 Nokia comments on CT1 LS C1-195199 Nokia, Nokia Shanghai Bell discussion Endorsement
5.3.1Work Item (CIoT_sec_5G)
 		Yes
Yes
 		noted No    
S3‑193659 pCR to TR33.853 on Migration paths for network deployment NTT DOCOMO INC. pCR Approval
5.12Study on User Plane Integrity Protection (FS_UP_IP_Sec)
 		Yes
YesApple: Don't believe the key issue is in scope of the TR DCM: Ignoring this will mean that we will end up with something that will not be deployed Nokia: Second point in particular had architectural impacts DCM: Proposed text is an 'or' as there are multiple ways to do this Huawei: Requirements are very solution specific - is it possible to reword them BT: Supportive of this contribution as it covers the network constraints Orange: Also supportive of this proposal Apple: Are these really criteria for evaluation of each solution DCM: The threats are raising security concerns QC: Don't understand the requirements Chair asked for who objects to the key issue: Phillips, Ericsson, Nokia & Huawei Chair asked for who supports the key issue: Orange, BT, DCM & KPN.
 		noted No    
S3‑193660 LS on short MAC-I and ngKSI for 5G-CIoT C1-195199 LS in  
5.3.1Work Item (CIoT_sec_5G)
 		Yes
Yes
 		replied to No    
S3‑193661 LS on 5GS Enhanced support of OTA mechanism for UICC configuration parameter update C4-193790 LS in  
4Incoming LS
 		Yes
YesNokia: no special security required DCM: agree Orange: if OTA keys go into new platform or stay in OTA platform. Put this in reply LS Thales: keys should stay in OTA platform, only authorized NFs should be able to use this interface. Nokia: noone wants to move the keys. Orange: for operators without OTA gateways, where are the keys.
 		replied to No    
S3‑193662 LS on SUCI computation from an NSI CP-192262 LS in  
5.10.1Work Item (Vertical_LAN_SEC)
 		Yes
Yes
 		postponed No    
S3‑193663 PEI for FN-RG Recommendation BBF LS in  
5.4Security of the Wireless and Wireline Convergence for the 5G system architecture (5WWC_SEC)
 		Yes
Yes
 		noted No    
S3‑193664 General Status of Work BBF LS in  
5.4Security of the Wireless and Wireline Convergence for the 5G system architecture (5WWC_SEC)
 		Yes
Yes
 		noted No    
S3‑193665 LS on NR V2X Security for user plane data and PDCP SN size R2-1911681 LS in  
5.16Study on Security Aspects of 3GPP support for Advanced V2X Services (FS_eV2X_Sec)
 		Yes
Yes
 		replied to No    
S3‑193666 Reply to LS on Impersonation Attacks in 4G Networks R2-1911819 LS in  
5.12Study on User Plane Integrity Protection (FS_UP_IP_Sec)
 		Yes
YesNok: should full rate by supported from Rel-16 QC: Full-rate can be supported for Rel-15 UEs Samsung: Need non-full rate in Rel-16 for some Ues QC: It is a product and not a standards issue Orange: Need to specify full rate
 		noted No    
S3‑193667 Reply LS on protection of PC5-RRC messages for sidelink unicast communication R2-1911863 LS in  
5.16Study on Security Aspects of 3GPP support for Advanced V2X Services (FS_eV2X_Sec)
 		Yes
Yes
 		noted No    
S3‑193668 Reply LS on LTE-M identification in 5GC R3-194748 LS in  
5.3.1Work Item (CIoT_sec_5G)
 		Yes
Yes
 		noted No    
S3‑193669 LS on the IAB-indication to core network R3-194787 LS in  
5.15.1Work Item (NR_IAB_Sec)
 		Yes
Yes
 		noted No    
S3‑193670 N9HR Regulatory Obligations S3i190548 LS in  
4Incoming LS
 		Yes
Yes
 		postponed No    
S3‑193671 New WID: Security Aspects of PARLOS SPRINT Corporation WID new Discussion
6Any Other Business
 		Yes
Yesorange: normative or informative Sprint: no decision in the WID, but in TR agreement: whether this is captured in an informative or normative annex is FFS. E//: also wants to support, comment acronym Supporting: E//; Samsung, T-Mobile
 		endorsed No    
S3‑193672 New WID for User Plane Gateway Function for the Inter-PLMN Security Juniper Networks WID new Agreement
6Any Other Business
 		Yes
YesThere was discussion on the location of the UPF, i.e whether it is co-located etc. DCM: had discussion previously and concluded that it was different function as it doe not terminate the interface - coloaction is then a deployment option Chair: ask if anyone is against the split BT: would rather keep them together Chair: explained that it was due to part of the work following SA2 and UP gateway part being standalone Juniper: It is a clean separation of the work item It is generally agreed that should be a split Taken offline for discussion of an objective
 		revised No S3‑193718  
S3‑193673 Comments to Draft for ‘proposed structure for network slice security procedures’ in S3-193394 InterDigital Communications other Approval
5.6.1Work Item (eNS_SEC)
 		Yes
Yespart of offline discussion Nokia: is anybody objecting these clarification E//: prefers to start with normal flow before looking at optimization for offline discussion Nokia: only up to step 5 has been discussed, see 738, so no decision on the steps in this doc.
 		noted No    
S3‑193674 Comments to Evaluation for Solution 11 in S3-193396 InterDigital Communications other Approval
5.6.2Study (FS_eNS_SEC)
 		Yes
Yes
 		noted No    
S3‑193675 Nokia comments on S3-193412 Nokia, Nokia Shanghai Bell pCR Approval
5.6.2Study (FS_eNS_SEC)
 		Yes
YesHuawei does not agree with proposed Ens Eri: OK with solution update and ENs going forward Agreed to take only the first EN.
 		noted No    
S3‑193676 Nokia comments on S3-193517 Nokia, Nokia Shanghai Bell pCR Approval
5.6.2Study (FS_eNS_SEC)
 		Yes
Yes
 		noted No    
S3‑193677 Nokia comments on S3-193417 Nokia, Nokia Shanghai Bell pCR Approval
5.6.2Study (FS_eNS_SEC)
 		Yes
YesNokia: prefer 417 Huawei: no time to work on this offline at this meeting, but agree with nokias comments IDCC: some solutions need more details to be evaluated
 		noted No    
S3‑193678 Update to conclusion on Key issue #22: Authorization of NF service access in indirect communication Nokia, Nokia Shanghai Bell pCR Approval
5.1.2Study (FS_SBA-Sec)
 		Yes
YesWait for SA2 response LS to S3-193724 before progress can be made.
 		noted No    
S3‑193679 Solution #4: Details on hash algorithm used for MIB/SIB hashes. Huawei, HiSilicon pCR Approval
5.55G security enhancement against false base stations (FS_5GFBS)
 		Yes
YesQC: why use HMAC when not using key DCM: use SHA 256 E//: ok rewrite to use SHA256.
 		revised No S3‑193756 S3‑193333
S3‑193680 LS on security consideration of performance measurement function protocol C1-196940 LS in discussion
4Incoming LS
 		Yes
Yes
 		postponed No    
S3‑193681 Agenda WG Chair agenda -
2Approval of Agenda and Meeting Objectives
 		Yes
Yes
 		approved No   S3‑193300
S3‑193682 Reply to: LS on 5GS Enhanced support of OTA mechanism for UICC configuration parameter update Nokia LS out approval
4Incoming LS
 		Yes
Yes
 		approved No    
S3‑193683 LS on security consideration of performance measurement function protocol ZTE Corporation LS out Approval
4Incoming LS
 		Yes
YesApple: UP IP is required, should be included in LS CMCC: consensus is need integrity protection, does not mention other things, no other security mechanism is needed DCM: no new mechanism is required but including integrity protection is required.
 		revised No S3‑193816  
S3‑193684 living doc for 5WWC Huawei, Hisilicon draftCR Approval
5.4Security of the Wireless and Wireline Convergence for the 5G system architecture (5WWC_SEC)
 		Yes
Yes
 		approved No   S3‑193479
S3‑193685 Solution for trusted non-3GPP access Lenovo, Motorola Mobility draftCR Approval
5.4Security of the Wireless and Wireline Convergence for the 5G system architecture (5WWC_SEC)
 		Yes
YesEN added for figure to be changed next time
 		approved No   S3‑193550
S3‑193686 Security for Wireline access to 5G - General Nokia, Nokia Shanghai Bell draftCR Endorsement
5.4Security of the Wireless and Wireline Convergence for the 5G system architecture (5WWC_SEC)
 		Yes
Yes
 		approved No   S3‑193379
S3‑193687 Authentication for 5G-RG Huawei, Hisilicon draftCR Approval
5.4Security of the Wireless and Wireline Convergence for the 5G system architecture (5WWC_SEC)
 		Yes
Yes
 		approved No   S3‑193480
S3‑193688 Authentication for FN-RG Huawei, Hisilicon draftCR Approval
5.4Security of the Wireless and Wireline Convergence for the 5G system architecture (5WWC_SEC)
 		Yes
Yes
 		approved No   S3‑193481
S3‑193689 Security of the interface between W-5GAN and 5GC Nokia, Nokia Shanghai Bell draftCR Endorsement
5.4Security of the Wireless and Wireline Convergence for the 5G system architecture (5WWC_SEC)
 		Yes
Yes
 		approved No   S3‑193383
S3‑193690 Solution on 5GC access from WLAN UEs that do not support NAS Lenovo, Motorola Mobility draftCR Approval
5.4Security of the Wireless and Wireline Convergence for the 5G system architecture (5WWC_SEC)
 		Yes
Yes
 		approved No   S3‑193551
S3‑193691 Proposal to solve ED notes in solution#4: Zero-overhead user plane integrity protection on the link layer Philips International B.V. pCR Approval
5.12Study on User Plane Integrity Protection (FS_UP_IP_Sec)
 		Yes
Yes
 		approved No   S3‑193320
S3‑193692 Proposed Solution for key issue #6 Qualcomm Incorporated pCR Approval
5.12Study on User Plane Integrity Protection (FS_UP_IP_Sec)
 		Yes
Yes
 		approved No   S3‑193393
S3‑193693 Draft TR 33.853 NTT DOCOMO INC. draft TR Approval
5.12Study on User Plane Integrity Protection (FS_UP_IP_Sec)
 		Yes
Yes
 		approved No    
S3‑193694 Solution to key issue#5 in UP IP Apple pCR Approval
5.12Study on User Plane Integrity Protection (FS_UP_IP_Sec)
 		Yes
Yes
 		approved No   S3‑193509
S3‑193695 Resolving Editor’s Note in Solution #1 Samsung pCR -
5.12Study on User Plane Integrity Protection (FS_UP_IP_Sec)
 		Yes
Yes
 		approved No   S3‑193579
S3‑193696 Add the Evaluation to Solution 5 in TR 33.853 China Mobile pCR -
5.12Study on User Plane Integrity Protection (FS_UP_IP_Sec)
 		Yes
Yes
 		approved No   S3‑193580
S3‑193697 UPIP: update of solution #7 and addition of evaluation Ericsson pCR -
5.12Study on User Plane Integrity Protection (FS_UP_IP_Sec)
 		Yes
Yes
 		approved No   S3‑193646
S3‑193698 Proposed conclusion for 5G RAN connected to 5GC Qualcomm Incorporated pCR Approval
5.12Study on User Plane Integrity Protection (FS_UP_IP_Sec)
 		Yes
Yes
 		approved No   S3‑193369
S3‑193699 draftCR for URLLC Huawei, Hisilicon draftCR Approval
5.8Security for 5G URLLC (5G_URLLC_SEC)
 		Yes
Yes
 		approved No   S3‑193476
S3‑193700 change introduction to align with URLLC architect Huawei, Hisilicon draftCR Approval
5.8Security for 5G URLLC (5G_URLLC_SEC)
 		Yes
Yes
 		approved No   S3‑193477
S3‑193701 Draft CR: UP security policy for URLLC Ericsson draftCR Approval
5.8Security for 5G URLLC (5G_URLLC_SEC)
 		Yes
YesNokia: disagree with preconfiguration, nonode should be preconfigured Huawei: not agree with first change, this has a new comment by Nokia, prefer to note this time Nokia: align with SA2, no point in putting some random statement, policy comes from SMF E//: ed note to check with RAN2 internaly revert back to plenary agreements
 		revised No S3‑193848 S3‑193627
S3‑193702 Draft CR as a living baseline for 5GS LCS normative work Ericsson LM draftCR Approval
5.7Security of the enhancement to the 5GC location services (eLCS_Sec)
 		Yes
YesDCM: copy last two ed notes inito WLAN as well.
 		revised No S3‑193847 S3‑193563
S3‑193703 draft TR 33.861 Ericsson draft TR Approval
5.3.2Study (FS_CIoT_sec_5G)
 		Yes
Yes
 		left for email approval No    
S3‑193704 Protection of UE capability transfer for UEs without AS security Intel pCR -
5.3.2Study (FS_CIoT_sec_5G)
 		Yes
YesE//: disagree with security requirements QC: what is the proposal E//: more about persistance of capabilities QC: then it is a security problem Nokia: agree with E//, so security is not as strong as other devices.
 		revised No S3‑193843 S3‑193437
S3‑193705 Editorial correction of format Nokia, Nokia Shanghai Bell draftCR Agreement
5.10.1Work Item (Vertical_LAN_SEC)
 		Yes
Yes
 		approved No   S3‑193529
S3‑193706 CR Interworking between NPN and PLMN Nokia, Nokia Shanghai Bell draftCR Agreement
5.10.1Work Item (Vertical_LAN_SEC)
 		Yes
Yes
 		approved No   S3‑193531
S3‑193707 CR Annex 5GLAN Nokia, Nokia Shanghai Bell draftCR Agreement
5.10.1Work Item (Vertical_LAN_SEC)
 		Yes
YesHuawei: what is the authentication mechanisms DCM: shall be used, not are Huawei: formatting, should this be under same Annex Nokia: no, same study: different topic Huawei: ed note: which authentication mechanism QC: not only auth mechanism, but also SMC, etc.ed note about all security procedures. Nokia: delete second paragraph, DCM: acronyms need to be added, refernce to IEEE TSN to be added tdoc name of revision had to be changed to reflect content
 		approved No   S3‑193532
S3‑193708 draft TR 33.819 Nokia draft TR Approval
5.10.2Study (FS_Vertical_LAN_SEC)
 		Yes
Yes
 		approved No    
S3‑193709 Solution for protection of time synchronization Huawei, Hisilicon pCR Approval
5.10.2Study (FS_Vertical_LAN_SEC)
 		Yes
Yes
 		approved No   S3‑193465
S3‑193710 LS on Signalling overload due to malicious Applications on UE KPN LS out Approval
5.3.2Study (FS_CIoT_sec_5G)
 		Yes
YesBT: include security concerns and tracking E//: no reference to the solutions in our TR QC: remove the reference about normative texts Huawei: it is no normative work *in SA3*.
 		revised No S3‑193844  
S3‑193711 CIOT: Conclusion on KI #5 Ericsson Nokia, Nokia Shanghai Bell, Qualcomm Incorporated, Samsung pCR Approval
5.3.2Study (FS_CIoT_sec_5G)
 		Yes
Yes
 		approved No   S3‑193540
S3‑193712 CIOT: Proposed conclusion to KI#7 Ericsson pCR Approval
5.3.2Study (FS_CIoT_sec_5G)
 		Yes
Yes
 		approved No   S3‑193544
S3‑193713 CIOT: Proposed_conclusion_KI_8 Ericsson pCR Approval
5.3.2Study (FS_CIoT_sec_5G)
 		Yes
Yes
 		approved No   S3‑193546
S3‑193714 CIOT: Conclusion for KI#12 Ericsson pCR Approval
5.3.2Study (FS_CIoT_sec_5G)
 		Yes
Yes
 		approved No   S3‑193549
S3‑193715 Reply to: LS on short MAC-I and ngKSI for 5G-CIoT Ericsson LS out approval
5.3.1Work Item (CIoT_sec_5G)
 		Yes
Yes
 		approved No    
S3‑193716 DraftCR - Proposed skeleton for supporting 5G CIoT [Living Document] Ericsson other Approval
5.3.1Work Item (CIoT_sec_5G)
 		Yes
Yes
 		approved No   S3‑193562
S3‑193717 CIoT_ Modifications to draft CR Nokia, Nokia Shanghai Bell, Ericsson other Approval
5.3.1Work Item (CIoT_sec_5G)
 		Yes
Yes
 		approved No   S3‑193392
S3‑193718 New WID for User Plane Gateway Function for the Inter-PLMN Security Juniper Networks WID new Agreement
6Any Other Business
 		Yes
YesNeeds to be re-submitted fro agreement in Reno meeting
 		endorsed No   S3‑193672
S3‑193719 Security requirements for SeCoP Nokia, Nokia Shanghai Bell draftCR Endorsement
5.1.1Work Item (SBA_Sec)
 		Yes
Yes
 		approved No   S3‑193387
S3‑193720 Security requirements for UP Gateway Function Nokia, Nokia Shanghai Bell draftCR Endorsement
5.1.1Work Item (SBA_Sec)
 		Yes
Yes
 		approved No   S3‑193428
S3‑193721 Authentication and authorization between SeCoP and network functions Nokia, Nokia Shanghai Bell draftCR Endorsement
5.1.1Work Item (SBA_Sec)
 		Yes
Yes
 		approved No   S3‑193388
S3‑193722 Authentication and authorization between SeCoPs Nokia, Nokia Shanghai Bell draftCR Endorsement
5.1.1Work Item (SBA_Sec)
 		Yes
Yes
 		approved No   S3‑193389
S3‑193723 Protection of N9 interface in Inter-PLMN scenario Nokia, Nokia Shanghai Bell, Juniper draftCR Endorsement
5.1.1Work Item (SBA_Sec)
 		Yes
Yes
 		approved No   S3‑193423
S3‑193724 LS on token-based authorization for indirect communication with delegated discovery (Scenario D) Ericsson LS out Approval
5.1.2Study (FS_SBA-Sec)
 		Yes
Yes
 		approved No   S3‑193614
S3‑193725 New solution for Key Issue #25 "Indirect communication in roaming scenarios" Ericsson pCR Approval
5.1.2Study (FS_SBA-Sec)
 		Yes
Yes
 		approved No   S3‑193619
S3‑193726 Conclusion for Key Issue #25 "Indirect communication in roaming scenarios" Ericsson pCR Approval
5.1.2Study (FS_SBA-Sec)
 		Yes
Yes
 		approved No   S3‑193620
S3‑193727 eSBA: add conclusion on KI #24 Huawei, Hisilicon pCR Approval
5.1.2Study (FS_SBA-Sec)
 		No
Yes
 		withdrawn Yes    
S3‑193728 Resolving EN in TR33.855 6.18 N9 NDS/IP Juniper Networks, NTT DoCoMo, Ericsson pCR Approval
5.1.2Study (FS_SBA-Sec)
 		Yes
Yes
 		approved No   S3‑193313
S3‑193729 Draft TR 33.855 Ericsson draft TR Approval
5.1.2Study (FS_SBA-Sec)
 		No
Yes
 		left for email approval No    
S3‑193730 Update on solution#15 in TR 33.855 Huawei, Hisilicon pCR Approval
5.1.2Study (FS_SBA-Sec)
 		Yes
Yes
 		approved No   S3‑193447
S3‑193731 Add Evaluation to solution 3 Huawei, HiSilicon pCR Approval
5.6.2Study (FS_eNS_SEC)
 		Yes
Yes
 		approved No   S3‑193405
S3‑193732 draft TR 33.813 Nokia draft TR Approval
5.6.2Study (FS_eNS_SEC)
 		No
Yes
 		left for email approval No    
S3‑193733 LS on configuaration of security policy for NSaaS Huawei LS out Approval
5.6.2Study (FS_eNS_SEC)
 		Yes
YesOrange: no reason to send it. Nokia: in SA2, there are many policy configuration mechanisms, let's not include yet another mechanism.
 		noted No    
S3‑193734 Addressing EN in solution 6 Huawei, HiSilicon pCR Approval
5.6.2Study (FS_eNS_SEC)
 		Yes
Yes
 		approved No   S3‑193408
S3‑193735 Evaluating solution 6 Huawei, HiSilicon pCR Approval
5.6.2Study (FS_eNS_SEC)
 		Yes
Yes
 		approved No   S3‑193409
S3‑193736 Concluding KI#4 Huawei, HiSilicon pCR Approval
5.6.2Study (FS_eNS_SEC)
 		Yes
Yes
 		approved No   S3‑193410
S3‑193737 Clarification on cancellation of rejected S-NSSAIs Lenovo, Motorola Mobility pCR Approval
5.6.2Study (FS_eNS_SEC)
 		Yes
YesNokia disagree with this interpretation of key issue, should be dynamic subscription re-enablement, so beyond the study item. Lenovo: CT1 already added ed note. Huawei: Nokia proposal seems agreeable
 		noted No   S3‑193553
S3‑193738 draft CR for Security procedures for Network Slices Nokia, Nokia Shanghai Bell other Agreement
5.6.1Work Item (eNS_SEC)
 		Yes
YesIDCC: the steps added in 12 and 13 in 673 are copied from SA2 Nokia: start with the non-conditional cases, there is no disagreement on 673 yet Huawei: only keep first sentence of ed note. BT: authorization should be removed from x.x.3 QC: baseline needs a lot of improvement, not agree this as working baseline, not endorse as living CR, agree on the skeleton Nokia keep baseline up to ed note QC: make clear that this is just a living document.
 		revised No S3‑193857 S3‑193394
S3‑193739 Threats and Requirements for Key Issue #8 Nokia, Nokia Shanghai Bell pCR Approval
5.13Study on Security Impacts of Virtualisation (FS_SIV)
 		Yes
Yes
 		approved No   S3‑193399
S3‑193740 Threats and Requirements for Key Issue #13 Nokia, Nokia Shanghai Bell pCR Approval
5.13Study on Security Impacts of Virtualisation (FS_SIV)
 		Yes
Yes
 		approved No   S3‑193400
S3‑193741 Threats and Requirements for Key Issue #17 Nokia, Nokia Shanghai Bell pCR Approval
5.13Study on Security Impacts of Virtualisation (FS_SIV)
 		Yes
YesOrange: avoid requirements on actor's, requirements on parts of infrastructure BT: replace by 3GPP network Orange: ok DCM: still unclear BT: then delete first requirement, remove "by the operator" from third requirement Nokia: add catalogue to third requirement remove fist req, add catalogue to third, remove by the operator.
 		revised No S3‑193828 S3‑193418
S3‑193742 TR 33.848 Security Threats and Requirements for Key Issue 16 (resubmission of S3-192558) NCSC pCR Approval
5.13Study on Security Impacts of Virtualisation (FS_SIV)
 		No
Yes
 		approved No   S3‑193372
S3‑193743 Threats and Requirements for Key Issue #18 Nokia, Nokia Shanghai Bell pCR Approval
5.13Study on Security Impacts of Virtualisation (FS_SIV)
 		Yes
Yes
 		approved No   S3‑193419
S3‑193744 Draft TR 33.845 Storage of sensitive credentials in 5G systems v0.0.0 VODAFONE Group Plc draft TR Approval
5.17Study on storage and transport of the security parameters in a 5GC, that are used by the ARPF for Authentication (FS_5GC_sec_storage_transport)
 		Yes
Yes
 		approved No   S3‑193566
S3‑193746 KI on Protection of authentication subscription data stored in UDR Nokia, Nokia Shanghai Bell other Approval
5.17Study on storage and transport of the security parameters in a 5GC, that are used by the ARPF for Authentication (FS_5GC_sec_storage_transport)
 		No
Yes
 		withdrawn Yes    
S3‑193747 KI on Separation of authentication subscription data from subscription data Nokia, Nokia Shanghai Bell other Approval
5.17Study on storage and transport of the security parameters in a 5GC, that are used by the ARPF for Authentication (FS_5GC_sec_storage_transport)
 		Yes
Yes
 		approved No   S3‑193535
S3‑193748 Privacy Aspects of ARPF deployment Ericsson pCR Approval
5.17Study on storage and transport of the security parameters in a 5GC, that are used by the ARPF for Authentication (FS_5GC_sec_storage_transport)
 		Yes
Yes
 		approved No   S3‑193647
S3‑193749 FS_SIV TR 33.848 v030c BT plc pCR Agreement
5.13Study on Security Impacts of Virtualisation (FS_SIV)
 		Yes
Yes
 		approved No   S3‑193318
S3‑193750 Draft TR 33.848 BT draft TR Approval
5.13Study on Security Impacts of Virtualisation (FS_SIV)
 		Yes
Yes
 		approved No    
S3‑193751 TR 33.848 Scope Update BT plc pCR Agreement
5.13Study on Security Impacts of Virtualisation (FS_SIV)
 		Yes
Yes
 		approved No   S3‑193328
S3‑193752 Draft TR 33.809 Apple draft TR Approval
5.55G security enhancement against false base stations (FS_5GFBS)
 		No
Yes
 		left for email approval No    
S3‑193753 New Solution: Protection of the whole RRCResumeRequest message Ericsson pCR Approval
5.55G security enhancement against false base stations (FS_5GFBS)
 		Yes
Yes
 		approved No   S3‑193603
S3‑193754 Evaluation of the shared key based MIB/SIB protection solution Qualcomm Incorporated pCR Approval
5.55G security enhancement against false base stations (FS_5GFBS)
 		Yes
Yes
 		approved No   S3‑193360
S3‑193755 New solution (SERSI – SERving network controlled SI signatures). Ericsson pCR Approval
5.55G security enhancement against false base stations (FS_5GFBS)
 		Yes
YesQC: add ed note that evaluation for soultion is FFS or move evaluation ed note to clause above Orange: add FFS to evaluation
 		revised No S3‑193845 S3‑193610
S3‑193756 Solution #4: Details on hash algorithm used for MIB/SIB hashes. Huawei, HiSilicon pCR Approval
5.55G security enhancement against false base stations (FS_5GFBS)
 		Yes
Yes
 		approved No   S3‑193679
S3‑193757 Resolve second and third EN in Solution #6 Huawei, HiSilicon pCR Approval
5.55G security enhancement against false base stations (FS_5GFBS)
 		Yes
Yes
 		approved No   S3‑193330
S3‑193758 preventing UE from reselecting to FBS Huawei, HiSilicon pCR Approval
5.55G security enhancement against false base stations (FS_5GFBS)
 		No
Yes
 		withdrawn Yes    
S3‑193759 Evaluation of solution #6 Huawei, HiSilicon pCR Approval
5.55G security enhancement against false base stations (FS_5GFBS)
 		Yes
Yes
 		approved No   S3‑193338
S3‑193760 Solution for Avoiding UE connecting to False Base Station during Conditional Handover Huawei, Hisilicon pCR Approval
5.55G security enhancement against false base stations (FS_5GFBS)
 		Yes
Yes
 		approved No   S3‑193491
S3‑193761 AKMA: Resolving the EN in AKMA push Huawei, Hisilicon pCR Approval
5.2.2Study (FS_AKMA)
 		Yes
Yes
 		approved No   S3‑193441
S3‑193762 draft TR 33.835 China Mobile draft TR Approval
5.2.2Study (FS_AKMA)
 		No
Yes
 		left for email approval No    
S3‑193763 AKMA: adding the evaluation of solution #24 Huawei, Hisilicon pCR Approval
5.2.2Study (FS_AKMA)
 		Yes
Yes
 		approved No   S3‑193442
S3‑193764 Evaluation for solution22 Huawei, Hisilicon pCR Approval
5.2.2Study (FS_AKMA)
 		Yes
YesOrange: don't agree with last two sentences QC: conclusions made, doesn't matter agreed as it is.
 		approved No   S3‑193474
S3‑193765 Solution Key lifetimes Ericsson pCR Approval
5.2.2Study (FS_AKMA)
 		Yes
Yes
 		approved No   S3‑193595
S3‑193766 Update of key issue #6 KPN pCR Approval
5.2.2Study (FS_AKMA)
 		No
Yes
 		approved No   S3‑193340
S3‑193767 conclusion on key issue #2 China Mobile pCR Approval
5.2.2Study (FS_AKMA)
 		Yes
YesOrange: AKMA application functino will be named to application function E//: not consistent in the TR? Orange: Note: AKMA application function is now application function in normative work.
 		revised No S3‑193842 S3‑193585
S3‑193768 Conclusion on key issue #5 China Mobile pCR Approval
5.2.2Study (FS_AKMA)
 		Yes
Yes
 		approved No   S3‑193586
S3‑193769 skeleton of AKMA TS China Mobile, Nokia, Nokia Shanghai Bell,Ericsson draft TS Approval
5.2.1Work Item (AKMA)
 		Yes
Yes
 		approved No   S3‑193582
S3‑193770 scope of AKMA TS China Mobile, Nokia, Nokia Shanghai Bell pCR Approval
5.2.1Work Item (AKMA)
 		Yes
Yes
 		approved No   S3‑193583
S3‑193771 draft CR of AKMA architecture China Mobile, Nokia, Nokia Shanghai Bell pCR Approval
5.2.1Work Item (AKMA)
 		Yes
YesOrange: disagree with ed note, object to collocation of AAnF with NEF CMCC: was there before QC: remove in parantheses? Orange: no.
 		revised No S3‑193841 S3‑193584
S3‑193772 AKMA Key hierarchy Ericsson pCR Approval
5.2.1Work Item (AKMA)
 		Yes
Yes
 		approved No   S3‑193600
S3‑193773 TR 33.848 Security Requirements for Key Issue 19 (resubmission of S3-192561) NCSC pCR Approval
5.13Study on Security Impacts of Virtualisation (FS_SIV)
 		Yes
Yes
 		noted No   S3‑193374
S3‑193774 Threats and Requirements for Key Issue #20 Nokia, Nokia Shanghai Bell pCR Approval
5.13Study on Security Impacts of Virtualisation (FS_SIV)
 		Yes
YesDCM: protected by operators doesn't work Orange: remove "by operator's" in requirement, no requirement on actors update requirement
 		revised No S3‑193829 S3‑193420
S3‑193775 Threats and Requirements for Key Issue #21 Nokia, Nokia Shanghai Bell pCR Approval
5.13Study on Security Impacts of Virtualisation (FS_SIV)
 		Yes
Yes
 		approved No   S3‑193421
S3‑193776 Threats and Requirements for Key Issue #23 Nokia, Nokia Shanghai Bell pCR Approval
5.13Study on Security Impacts of Virtualisation (FS_SIV)
 		Yes
Yes
 		approved No   S3‑193424
S3‑193777 Threats and Requirements for Key Issue #24 Nokia, Nokia Shanghai Bell pCR Approval
5.13Study on Security Impacts of Virtualisation (FS_SIV)
 		Yes
Yes
 		approved No   S3‑193425
S3‑193778 [draft] reply LS on NR V2X Security for user plane data and PDCP SN size LG Electronics France LS out -
5.16Study on Security Aspects of 3GPP support for Advanced V2X Services (FS_eV2X_Sec)
 		Yes
YesQC: include key ID, confirm LCID are input to keystreams, in Q2, add key ID, 12 bit requires faster rekeying.
 		revised No S3‑193854 S3‑193426
S3‑193779 Conclusion for Key issue 10 LG Electronics France pCR -
5.16Study on Security Aspects of 3GPP support for Advanced V2X Services (FS_eV2X_Sec)
 		Yes
YesHuawei: postpone to next meeting, SA still has some concern, also procedure defined in SA6
 		noted No   S3‑193431
S3‑193780 Add Clarifications to Ultimate Output of SECAM Evaluation Nokia, Nokia Shanghai Bell pCR Approval
5.9Study on SECAM and SCAS for 3GPP virtualized network products (FS_VNP_SECAM_SCAS)
 		Yes
Yes
 		approved No   S3‑193650
S3‑193781 Draft TR 33.818 China Mobile draft TR Approval
5.9Study on SECAM and SCAS for 3GPP virtualized network products (FS_VNP_SECAM_SCAS)
 		Yes
Yes
 		left for email approval No    
S3‑193782 Add Clarifications to 3GPP virtualized network product evaluation process Nokia, Nokia Shanghai Bell pCR Approval
5.9Study on SECAM and SCAS for 3GPP virtualized network products (FS_VNP_SECAM_SCAS)
 		Yes
Yes
 		approved No   S3‑193651
S3‑193783 Add Clarifications to Roles in SECAM for 3GPP virtualized network products Nokia, Nokia Shanghai Bell pCR Approval
5.9Study on SECAM and SCAS for 3GPP virtualized network products (FS_VNP_SECAM_SCAS)
 		Yes
Yes
 		approved No   S3‑193652
S3‑193784 Add Clarifications to SECAM Assurance Level for 3GPP VNPs Nokia, Nokia Shanghai Bell pCR Approval
5.9Study on SECAM and SCAS for 3GPP virtualized network products (FS_VNP_SECAM_SCAS)
 		Yes
Yes
 		approved No   S3‑193653
S3‑193785 Add Clarifications to SCAS documents structure and content Nokia, Nokia Shanghai Bell pCR Approval
5.9Study on SECAM and SCAS for 3GPP virtualized network products (FS_VNP_SECAM_SCAS)
 		Yes
Yes
 		approved No   S3‑193656
S3‑193786 Adding description for Generic virtualized network product model of type 3 China Mobile pCR Approval
5.9Study on SECAM and SCAS for 3GPP virtualized network products (FS_VNP_SECAM_SCAS)
 		Yes
Yes
 		approved No   S3‑193639
S3‑193787 Adding Generic assets and threats of GVNP for type 1 into clause 5.2.3.b China Mobile pCR Approval
5.9Study on SECAM and SCAS for 3GPP virtualized network products (FS_VNP_SECAM_SCAS)
 		Yes
Yes
 		approved No   S3‑193640
S3‑193788 Updates to Solution #2.1 on MT functionality Samsung pCR -
5.15.2Study (FS_NR_IAB_Sec)
 		Yes
YesThales: remove the note, sentence above should be removed, if it is a PLMN, it should AKA Samsung ok with removing note E//: but keep EAP TLS above Orange: against supporting the note and para above: Nokia, E//, Huawei, Samsung; objecting: BT, Thales, Orange Orange: removed text also related to teh discussion
 		revised No S3‑193851 S3‑193565
S3‑193789 Evaluation of solution #2.1 Samsung pCR -
5.15.2Study (FS_NR_IAB_Sec)
 		Yes
Yes
 		noted No   S3‑193567
S3‑193790 Conclusion to Key Issue#2.1 on authentication and authorization of the IAB Node (MT) Samsung pCR -
5.15.2Study (FS_NR_IAB_Sec)
 		Yes
Yes
 		noted No   S3‑193568
S3‑193791 Evaluation on Solution #3.1: F1 security context establishment Qualcomm Incorporated, Ericsson pCR Approval
5.15.2Study (FS_NR_IAB_Sec)
 		No
Yes
 		withdrawn Yes    
S3‑193792 Conclusion to Key Issue#2.1 on authentication and authorization of the IAB Node (gNB-DU) Samsung pCR -
5.15.2Study (FS_NR_IAB_Sec)
 		Yes
Yesorange: from where to where IPsec is established QC: delete last three sentences
 		revised No S3‑193856 S3‑193573
S3‑193793 Key issue on removal of UICC card in IAB node Huawei, Hisilicon pCR Approval
5.15.2Study (FS_NR_IAB_Sec)
 		Yes
YesBT: agrees Orange: don't include primary authenticaiton
 		revised No S3‑193852 S3‑193463
S3‑193794 new draft TR 33.836 LG draft TR Approval
5.16Study on Security Aspects of 3GPP support for Advanced V2X Services (FS_eV2X_Sec)
 		No
Yes
 		left for email approval No    
S3‑193795 33.836 – evaluation for the Solution #1 InterDigital Communications pCR Approval
5.16Study on Security Aspects of 3GPP support for Advanced V2X Services (FS_eV2X_Sec)
 		Yes
Yes
 		approved No   S3‑193312
S3‑193796 TR 33.836 – evaluation of the solution #4 InterDigital Communications pCR Approval
5.16Study on Security Aspects of 3GPP support for Advanced V2X Services (FS_eV2X_Sec)
 		Yes
Yes
 		approved No   S3‑193316
S3‑193797 TR 33.836 - update for solution #2 InterDigital Communications pCR Approval
5.16Study on Security Aspects of 3GPP support for Advanced V2X Services (FS_eV2X_Sec)
 		Yes
Yes
 		approved No   S3‑193305
S3‑193798 TR 33.836 - evaluation for the solution #2 InterDigital Communications pCR Approval
5.16Study on Security Aspects of 3GPP support for Advanced V2X Services (FS_eV2X_Sec)
 		Yes
Yes
 		approved No   S3‑193314
S3‑193799 Providing some analysis to solution #8 in TR 33.836 Qualcomm Incorporated pCR Approval
5.16Study on Security Aspects of 3GPP support for Advanced V2X Services (FS_eV2X_Sec)
 		Yes
Yes
 		approved No   S3‑193346
S3‑193800 Solution for the activation of user plane security in NR PC5 unicast Qualcomm Incorporated pCR Approval
5.16Study on Security Aspects of 3GPP support for Advanced V2X Services (FS_eV2X_Sec)
 		Yes
Yes
 		approved No   S3‑193351
S3‑193801 New solution for PC5 layer key derivation using the 5G network keys Huawei, Hisilicon pCR Approval
5.16Study on Security Aspects of 3GPP support for Advanced V2X Services (FS_eV2X_Sec)
 		Yes
Yes
 		approved No   S3‑193454
S3‑193802 LS on PC5S and PC5 RRC unicast message protection Qualcomm LS out Approval
5.16Study on Security Aspects of 3GPP support for Advanced V2X Services (FS_eV2X_Sec)
 		Yes
Yes
 		approved No    
S3‑193803 Conclusion on privacy for groupcast and broadcast Qualcomm Incorporated pCR Approval
5.16Study on Security Aspects of 3GPP support for Advanced V2X Services (FS_eV2X_Sec)
 		Yes
Yes
 		approved No   S3‑193343
S3‑193804 Identifier conversion in groupcast communication Lenovo, Motorola Mobility pCR Approval
5.16Study on Security Aspects of 3GPP support for Advanced V2X Services (FS_eV2X_Sec)
 		Yes
Yes
 		approved No   S3‑193557
S3‑193805 Proposed conclusion of security for groupcast Qualcomm Incorporated pCR Approval
5.16Study on Security Aspects of 3GPP support for Advanced V2X Services (FS_eV2X_Sec)
 		Yes
YesQC: keep both group and broadcast., there is a new split key issue on groupcast and broadcast Huawei: no normative work for groupcast *for R16* Huawei: change title to include broadcast
 		revised No S3‑193853 S3‑193344
S3‑193806 New Key Issue on Security of broadcast eV2X messages over PC5 Huawei, HiSilicon pCR Approval
5.16Study on Security Aspects of 3GPP support for Advanced V2X Services (FS_eV2X_Sec)
 		Yes
Yes
 		approved No   S3‑193324
S3‑193807 draft TR 33.824 Samsung draft TR Approval
5.15.2Study (FS_NR_IAB_Sec)
 		No
Yes
 		left for email approval No    
S3‑193808 [Draft CR]Solution for IAB Architecture Samsung draftCR -
5.15.1Work Item (NR_IAB_Sec)
 		Yes
Yeswill be living document for next meeting Orange: needs to remain as skeleton only
 		approved No   S3‑193564
S3‑193809 Notes from evening session on eNSI Qualcomm report Information
5.6.2Study (FS_eNS_SEC)
 		Yes
Yes
 		noted No    
S3‑193810 Key issue to mitigate the SUCI guessing attacks in TR 33.846 China Mobile pCR Approval
5.14Study on authentication enhancements in 5GS (FS_AUTH_ENH)
 		Yes
Yes
 		approved No   S3‑193637
S3‑193811 33:846: mitigation against linkability attack THALES pCR Approval
5.14Study on authentication enhancements in 5GS (FS_AUTH_ENH)
 		Yes
Yes
 		approved No   S3‑193319
S3‑193812 Using MACS to provide freshness for the protection of SQN during a re-synchronisation procedure in AKA Qualcomm Incorporated pCR Approval
5.14Study on authentication enhancements in 5GS (FS_AUTH_ENH)
 		Yes
Yes
 		approved No   S3‑193356
S3‑193813 New solution for linkability attack Huawei, Hisilicon pCR Approval
5.14Study on authentication enhancements in 5GS (FS_AUTH_ENH)
 		Yes
Yes
 		approved No   S3‑193450
S3‑193814 Address the EN and add evaluation in solution 2.3 Huawei, Hisilicon pCR Approval
5.14Study on authentication enhancements in 5GS (FS_AUTH_ENH)
 		Yes
Yes
 		approved No   S3‑193460
S3‑193815 solution on AUTS derivation to protect SQN Huawei, Hisilicon pCR Approval
5.14Study on authentication enhancements in 5GS (FS_AUTH_ENH)
 		Yes
Yes
 		approved No   S3‑193459
S3‑193816 LS on security consideration of performance measurement function protocol ZTE Corporation LS out Approval
4Incoming LS
 		Yes
YesNo agreement on whether to include that exisiting mecchnaisms are sufficient
 		noted No   S3‑193683
S3‑193817 Draft TS 33.535 China Mobile draft TS Approval
5.2.1Work Item (AKMA)
 		No
Yes
 		left for email approval No    
S3‑193818 Security handling in Control Plane User Datafor Control Plane Optimization for 5GS CIoT Huawei, Hisilicon draftCR Approval
5.3.1Work Item (CIoT_sec_5G)
 		Yes
Yes
 		approved No   S3‑193485
S3‑193819 On service request in solution 8 Huawei, HiSilicon pCR Approval
5.6.2Study (FS_eNS_SEC)
 		Yes
Yes
 		approved No   S3‑193411
S3‑193820 On Ng-RAN node change in solution 8 Huawei, HiSilicon pCR Approval
5.6.2Study (FS_eNS_SEC)
 		Yes
Yes
 		approved No   S3‑193412
S3‑193821 Resolving editor’s note on relationship between S-NSSAI and the S-NSSAI identifiers in solution #10 Qualcomm Incorporated pCR Approval
5.6.2Study (FS_eNS_SEC)
 		Yes
Yes
 		approved No   S3‑193355
S3‑193822 eNS_Addition to evaluation of solution 10 Nokia, Nokia Shanghai Bell, Ericsson pCR Approval
5.6.2Study (FS_eNS_SEC)
 		Yes
Yes
 		approved No   S3‑193395
S3‑193823 TR 33.813 - update for the evaluation for solution #11 InterDigital Communications pCR Approval
5.6.2Study (FS_eNS_SEC)
 		Yes
Yes
 		approved No   S3‑193309
S3‑193824 eNS_Addition of evaluation to solution 11 Nokia, Nokia Shanghai Bell, Ericsson pCR Approval
5.6.2Study (FS_eNS_SEC)
 		No
Yes
 		approved No   S3‑193396
S3‑193825 Resolving ENs of solution #12 ZTE Corporation pCR Approval
5.6.2Study (FS_eNS_SEC)
 		Yes
Yes
 		approved No   S3‑193517
S3‑193826 TR 33.819 – evaluation of DH based solution for CAG ID privacy InterDigital Communications pCR Approval
5.10.2Study (FS_Vertical_LAN_SEC)
 		Yes
Yes
 		approved No   S3‑193310
S3‑193827 TR 33.819 – evaluation of Hash based solution for CAG ID privacy InterDigital Communications pCR Approval
5.10.2Study (FS_Vertical_LAN_SEC)
 		Yes
Yes
 		approved No   S3‑193311
S3‑193828 Threats and Requirements for Key Issue #17 Nokia, Nokia Shanghai Bell pCR Approval
5.13Study on Security Impacts of Virtualisation (FS_SIV)
 		Yes
Yes
 		approved No   S3‑193741
S3‑193829 Threats and Requirements for Key Issue #20 Nokia, Nokia Shanghai Bell pCR Approval
5.13Study on Security Impacts of Virtualisation (FS_SIV)
 		Yes
Yes
 		approved No   S3‑193774
S3‑193830 LS on virtualization security assurance Orange LS out Approval
5.13Study on Security Impacts of Virtualisation (FS_SIV)
 		Yes
Yes
 		approved No    
S3‑193831 Adding Generic assets and threats of GVNP for type 2 into clause 5.2.3.c China Mobile pCR Approval
5.9Study on SECAM and SCAS for 3GPP virtualized network products (FS_VNP_SECAM_SCAS)
 		Yes
Yes
 		approved No   S3‑193641
S3‑193832 Adding Generic assets and threats of GVNP for type 3 into clause 5.2.3.d China Mobile pCR Approval
5.9Study on SECAM and SCAS for 3GPP virtualized network products (FS_VNP_SECAM_SCAS)
 		Yes
Yes
 		approved No   S3‑193642
S3‑193833 Adding security requirements into clause 5.2.4 China Mobile pCR Approval
5.9Study on SECAM and SCAS for 3GPP virtualized network products (FS_VNP_SECAM_SCAS)
 		Yes
Yes
 		approved No   S3‑193643
S3‑193834 Add Clarifications to generic virtualized network product model description Nokia, Nokia Shanghai Bell pCR Approval
5.9Study on SECAM and SCAS for 3GPP virtualized network products (FS_VNP_SECAM_SCAS)
 		Yes
Yes
 		approved No   S3‑193657
S3‑193835 Resolving the ENs in solution #5 Huawei, Hisilicon, Lenovo, Motorola Mobility pCR Approval
5.55G security enhancement against false base stations (FS_5GFBS)
 		Yes
YesDCM bring back privacy ed note Orange ed note: further evaluation is needed.
 		revised No S3‑193846 S3‑193448
S3‑193836 Update of Solution #15 Lenovo, Motorola Mobility pCR Approval
5.55G security enhancement against false base stations (FS_5GFBS)
 		Yes
Yes
 		approved No   S3‑193555
S3‑193837 Way forward for KI#6 about the resistance to radio jamming Ericsson pCR Approval
5.55G security enhancement against false base stations (FS_5GFBS)
 		Yes
Yes
 		approved No   S3‑193608
S3‑193838 LS on GUTI re-allocation Qualcomm LS out Approval
5.3.2Study (FS_CIoT_sec_5G)
 		Yes
Yes
 		approved No    
S3‑193839 SA3 meeting calendar WG Chair other Information
6Any Other Business
 		Yes
YesIDCC: SA#100 cadjacent to independence day weekend
 		noted No    
S3‑193840 draft agenda SA3#97 WG Chair other Information
6Any Other Business
 		Yes
Yes
 		noted No    
S3‑193841 draft CR of AKMA architecture China Mobile, Nokia, Nokia Shanghai Bell pCR Approval
5.2.1Work Item (AKMA)
 		Yes
Yes
 		approved No   S3‑193771
S3‑193842 conclusion on key issue #2 China Mobile pCR Approval
5.2.2Study (FS_AKMA)
 		Yes
Yes
 		approved No   S3‑193767
S3‑193843 Protection of UE capability transfer for UEs without AS security Intel pCR -
5.3.2Study (FS_CIoT_sec_5G)
 		Yes
Yes
 		approved No   S3‑193704
S3‑193844 LS on Signalling overload due to malicious Applications on UE KPN LS out Approval
5.3.2Study (FS_CIoT_sec_5G)
 		Yes
Yes
 		approved No   S3‑193710
S3‑193845 New solution (SERSI – SERving network controlled SI signatures). Ericsson pCR Approval
5.55G security enhancement against false base stations (FS_5GFBS)
 		Yes
Yes
 		approved No   S3‑193755
S3‑193846 Resolving the ENs in solution #5 Huawei, Hisilicon, Lenovo, Motorola Mobility pCR Approval
5.55G security enhancement against false base stations (FS_5GFBS)
 		Yes
Yes
 		approved No   S3‑193835
S3‑193847 Draft CR as a living baseline for 5GS LCS normative work Ericsson LM draftCR Approval
5.7Security of the enhancement to the 5GC location services (eLCS_Sec)
 		Yes
Yes
 		approved No   S3‑193702
S3‑193848 Draft CR: UP security policy for URLLC Ericsson draftCR Approval
5.8Security for 5G URLLC (5G_URLLC_SEC)
 		Yes
Yes
 		approved No   S3‑193701
S3‑193849 Add Clarifications to the Scope of Accreditation for 3GPP VNPs Nokia, Nokia Shanghai Bell pCR Approval
5.9Study on SECAM and SCAS for 3GPP virtualized network products (FS_VNP_SECAM_SCAS)
 		Yes
Yes
 		approved No   S3‑193649
S3‑193850 draft TR 33.846 Ericsson draft TR Approval
5.14Study on authentication enhancements in 5GS (FS_AUTH_ENH)
 		No
Yes
 		left for email approval No    
S3‑193851 Updates to Solution #2.1 on MT functionality Samsung pCR -
5.15.2Study (FS_NR_IAB_Sec)
 		Yes
YesBT: without Note, it is ok QC: ok with this, but add *subscription* credential in yellow marked text.
 		revised No S3‑193855 S3‑193788
S3‑193852 Key issue on removal of UICC card in IAB node Huawei, Hisilicon pCR Approval
5.15.2Study (FS_NR_IAB_Sec)
 		Yes
Yes
 		noted No   S3‑193793
S3‑193853 Proposed conclusion of security for groupcast Qualcomm Incorporated pCR Approval
5.16Study on Security Aspects of 3GPP support for Advanced V2X Services (FS_eV2X_Sec)
 		Yes
Yes
 		approved No   S3‑193805
S3‑193854 Reply to: LS on NR V2X Security for user plane data and PDCP SN size LG LS out approval
5.16Study on Security Aspects of 3GPP support for Advanced V2X Services (FS_eV2X_Sec)
 		Yes
Yes
 		approved No    
S3‑193855 Updates to Solution #2.1 on MT functionality Samsung pCR -
5.15.2Study (FS_NR_IAB_Sec)
 		Yes
Yes
 		noted No   S3‑193851
S3‑193856 Conclusion to Key Issue#2.1 on authentication and authorization of the IAB Node (gNB-DU) Samsung pCR -
5.15.2Study (FS_NR_IAB_Sec)
 		Yes
YesE//: not ok
 		noted No   S3‑193792
S3‑193857 draft CR for Security procedures for Network Slices Nokia, Nokia Shanghai Bell other Agreement
5.6.1Work Item (eNS_SEC)
 		Yes
Yesthe group agrees that all text in clause x.x.3 may need to be revised.
 		approved No   S3‑193738