{"text_format":"1","workbook":"xlsx","n_sheets":1,"sheets":["AgendaWithTdocAllocation_2019-1"],"not_rendered":{"charts":0,"images":0,"macros":1,"external_links":0,"defined_names":1,"comments":0,"pivot_tables":0},"unopened":[],"bounds":{"document_bytes":16777216,"sheet_cells":100000,"rows_first":2000,"rows_last":500,"rows_between":2000,"halvings":0,"cell_chars":16384,"cell_head_chars":4096},"cells_cut":0,"cells_raw":0,"read":"whole","date_system":"1900"}

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