{"text_format":"1","workbook":"xlsx","n_sheets":3,"sheets":["TDoc_List","CR_Packs_List","Parameters"],"not_rendered":{"charts":0,"images":0,"macros":1,"external_links":0,"defined_names":6,"comments":1,"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":"TDoc_List","index":0,"n_rows":438,"n_cols":31,"rows_kept":438,"cut":false,"hidden":false,"merged":[]}
["TDoc","Title","Source","Contact","Contact ID","Type","For","Abstract","Secretary Remarks","Agenda item sort order","Agenda item","Agenda item description","TDoc sort order within agenda item","TDoc Status","Reservation date","Uploaded","Is revision of","Revised to","Release","Spec","Version","Related WIs","CR","CR revision","CR category","TSG CR Pack","Reply to","To","Cc","Original LS","Reply in"]
["S3-190600","Agenda","WG Vice Chair","Mirko Cano Soveri",41957,"agenda",null,null,"Revised to correct editorial and add proposed schedule. Ericsson provided a welcome presentation. Chair reminded everyone of IT being a shared facility. Chaired provided IPR policy and a reminder of the anti-trust issues. ",null,"2","Approval of Agenda and Meeting Objectives",6000,"Revised","2019-02-19T11:02:14.143","2019-02-19T11:04:23.473",null,"S3-190921"]
["S3-190921","Agenda","WG Vice Chair","Mirko Cano Soveri",41957,"agenda",null,null,"Agenda items with few documents - remove IoT from AKMA",null,"2","Approval of Agenda and Meeting Objectives",6000,"approved",null,null,"S3-190600"]
["S3-190638","New Test Case: Error handling of malformed JSON object between two network products","NEC Europe Ltd","Taka Yoshizawa",40702,"pCR","Approval","This contribution proposes to add a generalized security requirement and test case related for discarding the malformed JSON object sent between two network products.","What is meant be malformed as if it general, then there could be a test for malformed JSON objects. ",null,"4.1.10","Other issues",6380,"noted","2019-03-03T08:35:39.037","2019-03-04T13:35:51.937",null,null,"Rel-16","33.517","0.2.0","SCAS_5G"]
["S3-190672","Living Document: General SBA/SBI aspects in TS 33.117","Nokia, Nokia Shanghai Bell","Wei Lu",79335,"draftCR","Approval","This is a living document for capturing general SBA/SBI aspects in TS 33.117 for NF-specific SCAS documents to reference.",null,null,"4.1.10","Other issues",6720,"Revised","2019-03-04T03:09:14.803","2019-03-04T03:16:51.350",null,"S3-190897","Rel-16","33.117","16.0.0","SCAS_5G"]
["S3-190897","Living Document: General SBA/SBI aspects in TS 33.117","Nokia, Nokia Shanghai Bell","Wei Lu",79335,"draftCR","Approval","This is a living document for capturing general SBA/SBI aspects in TS 33.117 for NF-specific SCAS documents to reference.",null,null,"4.1.10","Other issues",6720,"approved",null,null,"S3-190672",null,"Rel-16","33.117","16.0.0","SCAS_5G"]
["S3-190749","The purpose and scope of SCAS","Ericsson","Christine Jost",49662,"discussion","Endorsement",null,"It was commment that test cases should not define new requirements - modify proposal 2 by adding \"and where the requirement is documented in a 3GPP TS or TR\" This was agreeable. Proposal 1 require the rapporteur to bring in the relevent text for their TS",null,"4.1.10","Other issues",7490,"Revised","2019-03-04T09:48:40.557","2019-03-04T14:10:37.457",null,"S3-190883","Rel-16",null,null,"SCAS_5G"]
["S3-190883","The purpose and scope of SCAS","Ericsson","Christine Jost",49662,"discussion","Endorsement",null,"Endorsed without being seen ",null,"4.1.10","Other issues",7490,"endorsed",null,null,"S3-190749",null,"Rel-16",null,null,"SCAS_5G"]
["S3-190775","SCAS 5G: mutual authentication between NFs","Nokia, Nokia Shanghai Bell","Wei Lu",79335,"draftCR","Approval","This paper proposes a new sub-clause under 4.2.2.1 for one general baseline requirement and its corresponding test case applicable to all NFs utilizing SBI, which is mutual authentication between NFs.","The proposed test case adds more requirement to an existing test case, so rather than add a new test case it was agreed to work offline to update an exisiting test cases. The EN \"Security objectives and threat need to be added with reference to TS 33.926\" was also needed. ",null,"4.1.10","Other issues",7750,"Revised","2019-03-04T11:14:23.227","2019-03-04T12:09:38.610",null,"S3-190896","Rel-16","33.117","16.0.0","SCAS_5G"]
["S3-190896","SCAS 5G: mutual authentication between NFs","Nokia, Nokia Shanghai Bell","Wei Lu",79335,"draftCR","Approval","This paper proposes a new sub-clause under 4.2.2.1 for one general baseline requirement and its corresponding test case applicable to all NFs utilizing SBI, which is mutual authentication between NFs.",null,null,"4.1.10","Other issues",7750,"approved",null,null,"S3-190775",null,"Rel-16","33.117","16.0.0","SCAS_5G"]
["S3-190777","SCAS 5G: update to Access Token Verification Failure in non-roaming case","Nokia, Nokia Shanghai Bell","Wei Lu",79335,"draftCR","Approval","This paper proposes some updates to one of the test cases, which is authorization failure handling of NF service access within the same PLMN.",null,null,"4.1.10","Other issues",7770,"approved","2019-03-04T11:16:41.650","2019-03-04T12:09:38.623",null,null,"Rel-16","33.117","16.0.0","SCAS_5G"]
["S3-190778","SCAS 5G: update to Access Token Verification Failure in roaming case","Nokia, Nokia Shanghai Bell","Wei Lu",79335,"draftCR","Approval","This paper proposes some updates to one of the test cases, which is authorization failure handling of NF service access in roaming scenario.","No comments",null,"4.1.10","Other issues",7780,"approved","2019-03-04T11:19:57.933","2019-03-04T12:09:38.640",null,null,"Rel-16","33.117","16.0.0","SCAS_5G"]
["S3-190779","SCAS 5G: Search Result Handling for NF Discovery","Nokia, Nokia Shanghai Bell","Wei Lu",79335,"draftCR","Approval","This paper proposes a new sub-clause under 4.2.2.1 for search result handling applicable to all NFs for NF discovery. The sub-clause contains two test case: \n-\tone is the correct handling by a NF service consumer when receiving search result validity peri","No support for this contribution",null,"4.1.10","Other issues",7790,"noted","2019-03-04T11:24:36.977","2019-03-04T12:09:38.640",null,null,"Rel-16","33.117","16.0.0","SCAS_5G"]
["S3-190740","SCAS: AMF-specific adaptations of security functional requirements and related test cases","Huawei, Hisilicon","Bo Zhang",49401,"pCR","Approval",null,"It was questioned whether the test case in 4.2.2.1.X.1 was needed - it was agreed that this was not needed. For 4.2.2.Y.1 test case,  an EN \"Security objectives and threat need to be added with reference to TS 33.926\" was agreed to be added. The expected result of 4.2.2.Y.1 was taken offline. Same EN for 4.2.2.Y.2, 4.2.2.Z.1 and 4.2.2.Z.2 was agreed. Taken offline whether 4.2.2.Y.2 needs to consider handovers. No other changes for 4.2.2.Z.1.  4.2.2.Z.2 taken offline to see if it can be merged with 4.2.2.Z.1.",null,"4.1.2","Access and Mobility Management Function (TS 33.512)",7400,"Revised","2019-03-04T09:32:21.537","2019-03-04T10:21:44.847",null,"S3-190884","Rel-16","33.512","0.5.0","SCAS_5G"]
["S3-190884","SCAS: AMF-specific adaptations of security functional requirements and related test cases","Huawei, Hisilicon","Bo Zhang",49401,"pCR","Approval",null,"Ericsson is against logging for these test cases. DCM: : bring CR to 33. 501 to clarify requirement on logging",null,"4.1.2","Access and Mobility Management Function (TS 33.512)",7400,"approved",null,null,"S3-190740",null,"Rel-16","33.512","0.5.0","SCAS_5G"]
["S3-190887","New draft TS 33.512","Deutsche Telekom AG",null,null,"draft TS","Approval",null,null,null,"4.1.2","Access and Mobility Management Function (TS 33.512)",7400,"approved"]
["S3-190741","Security Assurance Requirements and Test Case for UPF","Huawei, Hisilicon","Bo Zhang",49401,"pCR","Approval",null,"It was questioned whether confidentiality and integrity need to be separate test cases - it was agreed to merge them. It was questioned whether the test cases are needed at all as the general test case already exists in TS 33.117. The Pre-Condition should not refer to a PLMN as it is always in a test lab - proposal to remove \"if ..\" and make the test manadatory was agreed. EN \"Security objectives and threat need to be added with reference to TS 33.926\" was agreed to be added. It was proposed to remove Y2 to Y5 test cases as it was not clear that this directly apply. Discussion taken offline on this. The revision of this document (S3-190885) will only consider X1 and Y1. Revision of Y2 to Y5 will be in S3-190886. ",null,"4.1.3","User Plane Function (UPF) (TS 33.513)",7410,"Revised","2019-03-04T09:32:21.537","2019-03-04T10:21:44.863",null,"S3-190885","Rel-16","33.513","0.2.0","SCAS_5G"]
["S3-190885","Security Assurance Requirements and Test Case for UPF","Huawei, Hisilicon","Bo Zhang",49401,"pCR","Approval",null,null,null,"4.1.3","User Plane Function (UPF) (TS 33.513)",7410,"approved",null,null,"S3-190741",null,"Rel-16","33.513","0.2.0","SCAS_5G"]
["S3-190886","Security Assurance Requirements and Test Case for UPF - references to TS 33.250","Huawei, Hisilicon",null,null,"pCR","Approval",null,null,null,"4.1.3","User Plane Function (UPF) (TS 33.513)",7410,"approved",null,null,null,null,"Rel-16","33.513","0.2.0","SCAS_5G"]
["S3-190888","New draft TS 33.513","Samsung",null,null,"draft TS","Approval",null,null,null,"4.1.3","User Plane Function (UPF) (TS 33.513)",7410,"approved"]
["S3-190743","Security Assurance Requirement and test cases for SMF","Huawei, Hisilicon","Bo Zhang",49401,"pCR","Approval",null,"There was no support and several people against including the first test case - this will not be included. Test 2 will be included with \"The tester captures the N1 initial context setup message.\" clarified that this on N2 interface and EN \"Security objectives and threat need to be added with reference to TS 33.926\". There was no support and several people against including the third and fourth test cases - these will not be included. Change 5 needs to be aligned with the remaing test case.",null,"4.1.5","Session Management Function (SMF) (TS 33.515)",7430,"Revised","2019-03-04T09:32:21.567","2019-03-04T10:21:44.863",null,"S3-190889","Rel-16","33.515","0.1.0","SCAS_5G"]
["S3-190889","Security Assurance Requirement and test cases for SMF","Huawei, Hisilicon","Bo Zhang",49401,"pCR","Approval",null,null,null,"4.1.5","Session Management Function (SMF) (TS 33.515)",7430,"approved",null,null,"S3-190743",null,"Rel-16","33.515","0.1.0","SCAS_5G"]
["S3-190890","New draft TS 33.515","Huawei",null,null,"draft TS","Approval",null,null,null,"4.1.5","Session Management Function (SMF) (TS 33.515)",7430,"approved"]
["S3-190637","New Test Case: Error handling of malformed N32 signalling message sent between peer SEPPs","NEC Europe Ltd","Taka Yoshizawa",40702,"pCR","Approval","This contribution proposes to add SEPP security requirement and test case related for discarding the malformed N32 signalling message sent between two peer SEPPs.","Not security related but generic - some suggestion. that this should go into TS 33.117. This was taken offline to work on what parts need to go into TS 33.117",null,"4.1.7","Security Edge Protection Proxy (SEPP) (TS 33.517)",6370,"noted","2019-03-03T08:32:49.757","2019-03-04T13:35:51.937",null,null,"Rel-16","33.517","0.2.0","SCAS_5G"]
["S3-190728","Test Case: Connection-specific scope of IPX-provider cryptographic material","Deutsche Telekom AG","Hans Christian Rudolph",72672,"pCR","Approval",null,"It was agreed that  EN \"Security objectives and threat need to be added with reference to TS 33.926\" and another EN that the requirements need to be TS 33.501.",null,"4.1.7","Security Edge Protection Proxy (SEPP) (TS 33.517)",7280,"Revised","2019-03-04T08:44:37.710","2019-03-04T09:29:06.250",null,"S3-190891","Rel-16","33.517","0.2.0","SCAS_5G"]
["S3-190891","Test Case: Connection-specific scope of IPX-provider cryptographic material","Deutsche Telekom AG","Hans Christian Rudolph",72672,"pCR","Approval",null,"Approved without  being seen. ",null,"4.1.7","Security Edge Protection Proxy (SEPP) (TS 33.517)",7280,"approved",null,null,"S3-190728",null,"Rel-16","33.517","0.2.0","SCAS_5G"]
["S3-190780","SCAS SEPP: Serving PLMN ID Mismatch","Nokia, Nokia Shanghai Bell","Wei Lu",79335,"pCR","Approval","Based on the current version of TS 33.517, this paper proposes the test case for correct handling by SEPP when identifying the mismatch between the PLMN-ID contained in the incoming N32-f message and the PLMN-ID in the related N32-f context.","It was felt that the threats were not clearly defined. The discussion of the threat description was taken offline. The needs for 'consumer' and 'producer' in the test was questioned - this will be taken offline. The private key should be the test private key. The second expected result is not in TS 33.501 so can not be added currently. ",null,"4.1.7","Security Edge Protection Proxy (SEPP) (TS 33.517)",7800,"Revised","2019-03-04T11:30:13.417","2019-03-04T12:09:38.657",null,"S3-190892","Rel-16","33.517","0.2.0","SCAS_5G"]
["S3-190892","SCAS SEPP: Serving PLMN ID Mismatch","Nokia, Nokia Shanghai Bell","Wei Lu",79335,"pCR","Approval","Based on the current version of TS 33.517, this paper proposes the test case for correct handling by SEPP when identifying the mismatch between the PLMN-ID contained in the incoming N32-f message and the PLMN-ID in the related N32-f context.",null,null,"4.1.7","Security Edge Protection Proxy (SEPP) (TS 33.517)",7800,"approved",null,null,"S3-190780",null,"Rel-16","33.517","0.2.0","SCAS_5G"]
["S3-190893","New draft TS 33.517","Nokia",null,null,"draft TS","Approval",null,null,null,"4.1.7","Security Edge Protection Proxy (SEPP) (TS 33.517)",7800,"approved"]
["S3-190742","Security Assurance Requirement and Test for NRF","Huawei, Hisilicon","Bo Zhang",49401,"pCR","Approval",null,"It was questioned whether the first test is needed as it is not a security test. This discussion will be taken offline. The second tests seem to check whether the authorisation feature is implemented (i.e. checking functionality) - does this need to be covered. Something needs to be clarified - this will be taken offline. Similar concerns were raised for test case 3. ",null,"4.1.8","Network Resource Function (NRF) (TS 33.518)",7420,"Revised","2019-03-04T09:32:21.553","2019-03-04T10:21:44.863",null,"S3-190978","Rel-16","33.518","0.2.0","SCAS_5G"]
["S3-190978","Security Assurance Requirement and Test for NRF","Huawei, Hisilicon","Bo Zhang",49401,"pCR","Approval",null,"Nokia: why incorrect operation leads to so many threats? E//: not clear what are the threats. Come back with threats for next meeting. Huawei: ok, threat discussion. ",null,"4.1.8","Network Resource Function (NRF) (TS 33.518)",7420,"noted",null,null,"S3-190742",null,"Rel-16","33.518","0.2.0","SCAS_5G"]
["S3-190805","SCAS NRF: Scope Representation for Nnrf_AccessToken Service","Nokia, Nokia Shanghai Bell","Wei Lu",79335,"pCR","Approval","Based on the current version of TS 33.518, this paper proposes two new test cases for scope representation for Nnrf_AccessToken Service, which are NRF-specific security requirements derived from 29.510.","It was also questioned whether this is really just testing functionality and what is the secrity rationale for the test case. There was no support for inclusion of these cases.",null,"4.1.8","Network Resource Function (NRF) (TS 33.518)",8050,"noted","2019-03-04T11:39:40.710","2019-03-04T12:09:38.640",null,null,"Rel-16","33.518","0.2.0","SCAS_5G"]
["S3-190618","SCAS NEF Add test steps for authorization on northbound APIs","ZTE Corporation","Zhenhua Xie",38520,"pCR","Approval",null,"The security rationale of the proposed test case was questioned. If with a faked token, the AMF responds then there is a security problem was the response. This was taken offline to fix the execution steps. ",null,"4.1.9","Network Exposure Function (NEF) (TS 33.519)",6180,"Revised","2019-03-02T01:27:58.937","2019-03-04T10:10:54.343",null,"S3-190894","Rel-16","33.519","0.3.0","SCAS_5G"]
["S3-190894","SCAS NEF Add test steps for authorization on northbound APIs","ZTE Corporation","Zhenhua Xie",38520,"pCR","Approval",null,null,null,"4.1.9","Network Exposure Function (NEF) (TS 33.519)",6180,"approved",null,null,"S3-190618",null,"Rel-16","33.519","0.3.0","SCAS_5G"]
["S3-190895","New draft TS 33.519","ZTE",null,null,"draft TS","Approval",null,null,null,"4.1.9","Network Exposure Function (NEF) (TS 33.519)",6180,"approved"]
["S3-190744","New Key Issue: Support of a UP gateway function on the N9 interface","Ericsson","Christine Jost",49662,"pCR","Approval",null,"Nokia: move to separate subclause in 5.5 of 501 to have separate requirement for N9, shouldn' stay in TR. DT: should say inform the SEPP. E//: should be on new interface, whatever it is. NEC: why we need that interface to UPF, or if the box is transparent. add new bullet point solution needs to motivate the need for new interface. Juniper: the ? in the figure refer to control plane interface. E//: could update figure. Nokia: have section for N9 requirements in TR. ",null,"5.1","Study on Security Aspects of the 5G Service Based Architecture (FS_SBA-Sec) (Rel-16)",7240,"Revised","2019-03-04T09:48:40.447","2019-03-04T14:10:37.457",null,"S3-190744","Rel-16","33.855","1.3.0","FS_SBA_Sec"]
["S3-190964","New Key Issue: Support of a UP gateway function on the N9 interface","Ericsson","Christine Jost",49662,"pCR","Approval",null,"add EN: N9 requirements go into a seperate clause.",null,"5.1","Study on Security Aspects of the 5G Service Based Architecture (FS_SBA-Sec) (Rel-16)",7240,"approved","2019-03-04T09:48:40.447","2019-03-04T14:10:37.457","S3-190744",null,"Rel-16","33.855","1.3.0","FS_SBA_Sec"]
["S3-190737","New KI: flexible protection of data exchange on N9","Huawei, Hisilicon","Bo Zhang",49401,"pCR","Approval",null,"Juniper: not invent a new protocol for this. E//: need to clarify flexibility. BT: this is about user plane, not about protecting core network, which should be the real reason for this. E//: Huawei: this is a GSMA requirement NCSC: is SEPP-U something decided. DCM: problem with flexibility, when it is about dynamic flexibility. EN: what does flexibility mean. NCSC: first requirement: the system ...",null,"5.1","Study on Security Aspects of the 5G Service Based Architecture (FS_SBA-Sec) (Rel-16)",7250,"Revised","2019-03-04T09:32:21.520","2019-03-04T10:21:44.833",null,"S3-190965","Rel-16","33.819","0.2.0","FS_Vertical_LAN_SEC"]
["S3-190965","New KI: flexible protection of data exchange on N9","Huawei, Hisilicon","Bo Zhang",49401,"pCR","Approval",null,null,null,"5.1","Study on Security Aspects of the 5G Service Based Architecture (FS_SBA-Sec) (Rel-16)",7250,"approved","2019-03-04T09:32:21.520","2019-03-04T10:21:44.833","S3-190737",null,"Rel-16","33.819","0.2.0","FS_Vertical_LAN_SEC"]
["S3-190966","Clarification of flexibility of N9 protection","Deutsche Telekom AG","Hans Christian Rudolph",null,"LS out","Approval",null,"ask whether 33.210 flexibility is sufficient. DCM: inlcude that there is cost to flexibility. Nokia: granularity clear enough. Telia: what kind of configuration and what is automatic. NCSC: rephrase q1: .., could GSMA 5GJA report on any planned requirements for flexible requirements.",null,"5.1","Study on Security Aspects of the 5G Service Based Architecture (FS_SBA-Sec) (Rel-16)",7260,"Revised",null,null,null,"S3-191016"]
["S3-190876","Protection of N9 interface in Inter-PLMN scenario","Nokia, Nokia Shanghai Bell","Nagendra Bykampadi",69265,"pCR","Approval","Protection of N9 interface in Inter-PLMN scenario","Juniper: replace the previous contribution. BT: support this. Huawei: issue with lack of flexibility. E//: change requirement to systerm shall support. Juniper: say according to 33.210. NCSC: why 5GJA wanted flexibility. DCM: send LS to GSMA. Huawei: LS from GSMA was clear already. DCM: unclear if 33.210 is sufficient Nokia: need clarification. E//: add EN from previous contribution, then the prevoius contribution is captured as well. Nokia: agree. ",null,"5.1","Study on Security Aspects of the 5G Service Based Architecture (FS_SBA-Sec) (Rel-16)",7260,"merged","2019-03-04T14:09:24.510","2019-03-04T14:19:16.483",null,"S3-190965","Rel-16","33.855","1.3.0","FS_SBA_Sec"]
["S3-191016","Clarification of flexibility of N9 protection","Deutsche Telekom AG","Hans Christian Rudolph",null,"LS out","Approval",null,null,null,"5.1","Study on Security Aspects of the 5G Service Based Architecture (FS_SBA-Sec) (Rel-16)",7260,"approved",null,null,"S3-190966"]
["S3-190869","Security aspects of Service Communication Proxy (SCP)","Nokia, Nokia Shanghai Bell","Nagendra Bykampadi",69265,"pCR","Approval","SRel-16 5GC supports indirect communication via an SCP. Security aspects of SCP must be studied in detail to ensure that there is no loss in security with the introduction of SCP between two NFs","together with 726 , merged into 967 and 968",null,"5.1","Study on Security Aspects of the 5G Service Based Architecture (FS_SBA-Sec) (Rel-16)",7270,"merged","2019-03-04T13:51:36.007","2019-03-04T14:19:16.500",null,"S3-190967","Rel-16","33.855","1.3.0","FS_SBA_Sec"]
["S3-190726","Key Issue: Protection of SCP interfaces","Deutsche Telekom AG","Hans Christian Rudolph",72672,"pCR","Approval",null,"together with 727",null,"5.1","Study on Security Aspects of the 5G Service Based Architecture (FS_SBA-Sec) (Rel-16)",7370,"Revised","2019-03-04T08:41:13.920","2019-03-04T09:29:06.237",null,"S3-190967","Rel-16","33.855","1.3.0","FS_SBA_Sec"]
["S3-190967","Key Issue: Protection of SCP interfaces","Deutsche Telekom AG","Hans Christian Rudolph",72672,"pCR","Approval",null,null,null,"5.1","Study on Security Aspects of the 5G Service Based Architecture (FS_SBA-Sec) (Rel-16)",7370,"approved","2019-03-04T08:41:13.920","2019-03-04T09:29:06.237","S3-190726",null,"Rel-16","33.855","1.3.0","FS_SBA_Sec"]
["S3-190727","Key Issue: Secure message transport via the SCP","Deutsche Telekom AG","Hans Christian Rudolph",72672,"pCR","Approval",null,"E//: need to merge these. Two issues. Requirements: system shall support. On 727: reference should be checked. not refer to NDS/IP",null,"5.1","Study on Security Aspects of the 5G Service Based Architecture (FS_SBA-Sec) (Rel-16)",7440,"Revised","2019-03-04T08:42:08.757","2019-03-04T09:29:06.250",null,"S3-190968","Rel-16","33.855","1.3.0","FS_SBA_Sec"]
["S3-190968","Key Issue: Secure message transport via the SCP","Deutsche Telekom AG","Hans Christian Rudolph",72672,"pCR","Approval",null,null,null,"5.1","Study on Security Aspects of the 5G Service Based Architecture (FS_SBA-Sec) (Rel-16)",7440,"approved","2019-03-04T08:42:08.757","2019-03-04T09:29:06.250","S3-190727",null,"Rel-16","33.855","1.3.0","FS_SBA_Sec"]
["S3-190871","NF to NF authenticaton and authorization in Indirect communication mode","Nokia, Nokia Shanghai Bell","Nagendra Bykampadi",69265,"pCR","Approval","This key issue addresses how NF to NF authentication and authorization works in Indirect communication mode.","E//: could be merged to 727. bullet B may no longer be possible DCM: SCoP defines a trust domain. Keep open",null,"5.1","Study on Security Aspects of the 5G Service Based Architecture (FS_SBA-Sec) (Rel-16)",8690,"Revised","2019-03-04T13:56:16.987","2019-03-04T14:19:16.517",null,"S3-190981","Rel-16","33.855","1.3.0","FS_SBA_Sec"]
["S3-190981","NF to NF authenticaton and authorization in Indirect communication mode","Nokia, Nokia Shanghai Bell","Nagendra Bykampadi",69265,"pCR","Approval","This key issue addresses how NF to NF authentication and authorization works in Indirect communication mode.",null,null,"5.1","Study on Security Aspects of the 5G Service Based Architecture (FS_SBA-Sec) (Rel-16)",8690,"approved",null,null,"S3-190871",null,"Rel-16","33.855","1.3.0","FS_SBA_Sec"]
["S3-190872","Authorization of NF service access in SCP","Nokia, Nokia Shanghai Bell","Nagendra Bykampadi",69265,"pCR","Approval","In Rel-16, the SCP is expected to support the functionality of OAuth 2.0 based service access authorization of NF service consumer.","DT: auth is in SA3 domain, remove second para. E//: check offline about authorization. Third paragraph depends on second para. Nokia: take this offline",null,"5.1","Study on Security Aspects of the 5G Service Based Architecture (FS_SBA-Sec) (Rel-16)",8710,"Revised","2019-03-04T13:59:15.860","2019-03-04T14:19:16.517",null,"S3-190980","Rel-16","33.855","1.3.0","FS_SBA_Sec"]
["S3-190980","Authorization of NF service access in SCP","Nokia, Nokia Shanghai Bell","Nagendra Bykampadi",69265,"pCR","Approval","In Rel-16, the SCP is expected to support the functionality of OAuth 2.0 based service access authorization of NF service consumer.",null,null,"5.1","Study on Security Aspects of the 5G Service Based Architecture (FS_SBA-Sec) (Rel-16)",8710,"approved",null,null,"S3-190872",null,"Rel-16","33.855","1.3.0","FS_SBA_Sec"]
["S3-190874","Service access authorization within a NF Set or NF Service Set","Nokia, Nokia Shanghai Bell","Nagendra Bykampadi",69265,"pCR","Approval","Study the impact of instance Set introduced by SA2, on OAuth 2.0 based Service access authorization.","E//: looks like solution. Requirement: the 5G system shall support token based authentication NF sets and NF service sets DCM: ist.io may replace oauth based authentication. Leave req as tbd. Accept with tbd, requirements for next meeting. QC: remove SA2, and reference to CR, should be reference to TS. DCM: EN: change to specification after acceptance of CR. Further formatting comments.",null,"5.1","Study on Security Aspects of the 5G Service Based Architecture (FS_SBA-Sec) (Rel-16)",8720,"Revised","2019-03-04T14:06:42.487","2019-03-04T14:19:16.483",null,"S3-190982","Rel-16","33.855","1.3.0","FS_SBA_Sec"]
["S3-190982","Service access authorization within a NF Set or NF Service Set","Nokia, Nokia Shanghai Bell","Nagendra Bykampadi",69265,"pCR","Approval","Study the impact of instance Set introduced by SA2, on OAuth 2.0 based Service access authorization.",null,null,"5.1","Study on Security Aspects of the 5G Service Based Architecture (FS_SBA-Sec) (Rel-16)",8720,"approved",null,null,"S3-190874",null,"Rel-16","33.855","1.3.0","FS_SBA_Sec"]
["S3-190873","Indirect communication between NFs in roaming scenarios","Nokia, Nokia Shanghai Bell","Nagendra Bykampadi",69265,"pCR","Approval","This key issue studies the use of SCP on the consumer and/or producer side in roaming scenarios and security aspects when indirect communication is used between two NFs in such scenarios","E//: remove \"something similar…\", as it is solution. DCM: this is architecural requirement. Interoperability with R15.",null,"5.1","Study on Security Aspects of the 5G Service Based Architecture (FS_SBA-Sec) (Rel-16)",8730,"Revised","2019-03-04T14:03:30.243","2019-03-04T14:19:16.467",null,"S3-190983","Rel-16","33.855","1.3.0","FS_SBA_Sec"]
["S3-190983","Indirect communication between NFs in roaming scenarios","Nokia, Nokia Shanghai Bell","Nagendra Bykampadi",69265,"pCR","Approval","This key issue studies the use of SCP on the consumer and/or producer side in roaming scenarios and security aspects when indirect communication is used between two NFs in such scenarios",null,null,"5.1","Study on Security Aspects of the 5G Service Based Architecture (FS_SBA-Sec) (Rel-16)",8730,"approved",null,null,"S3-190873",null,"Rel-16","33.855","1.3.0","FS_SBA_Sec"]
["S3-190724","Draft LS on SCP security requirements","Deutsche Telekom AG","Hans Christian Rudolph",72672,"LS out","Approval",null,"TNO: is the SCP already decided? DCM: SA2 decided",null,"5.1","Study on Security Aspects of the 5G Service Based Architecture (FS_SBA-Sec) (Rel-16)",8740,"merged","2019-03-04T08:38:12.737","2019-03-04T09:29:06.250",null,"S3-190963","Rel-16",null,null,"FS_SBA_Sec",null,null,null,null,null,"SA2"]
["S3-190725","Key Issue: Handling of invalid IPX patches","Deutsche Telekom AG","Hans Christian Rudolph",72672,"pCR","Approval",null,"DCM: ed note: whether to really do per error cause and per N32 connection is FFS",null,"5.1","Study on Security Aspects of the 5G Service Based Architecture (FS_SBA-Sec) (Rel-16)",8760,"Revised","2019-03-04T08:40:06.013","2019-03-04T09:29:06.237",null,"S3-190984","Rel-16","33.855","1.3.0","FS_SBA_Sec"]
["S3-190984","Key Issue: Handling of invalid IPX patches","Deutsche Telekom AG","Hans Christian Rudolph",72672,"pCR","Approval",null,null,null,"5.1","Study on Security Aspects of the 5G Service Based Architecture (FS_SBA-Sec) (Rel-16)",8760,"approved",null,null,"S3-190725",null,"Rel-16","33.855","1.3.0","FS_SBA_Sec"]
["S3-190879","TLMSP, A Proxy Transport Layer Secure Protocol","NCSC","Colin Whorlow",70257,"other","Discussion","This document is submitted on behalf of ETSI TC Cyber.  It provides information on TLMSP, a proxy transport layer secure protocol.  TLMSP has similarities to application layer security for N32 and fulfils similar requirements.","comments to be given offline",null,"5.1","Study on Security Aspects of the 5G Service Based Architecture (FS_SBA-Sec) (Rel-16)",8790,"noted","2019-03-04T14:49:02.340","2019-03-04T14:57:25.657",null,null,"Rel-16"]
["S3-190961","LS on handling of Indirect communication across NF/NF Services",null,null,null,"LS in",null,null,null,null,"5.1",null,null,"Revised",null,null,null,"S3-190963"]
["S3-190963","reply LS on handling of Indirect communication across NF/NF Services","Deutsche Telekom AG","Hans Christian Rudolph",null,"LS out",null,null,"DCM: SCP bad acronym. May need two SCPs one for consumer and for producer DT: have proposal regarding visisbility in architecture",null,"5.1",null,null,"approved",null,null,null,null,null,null,null,null,null,null,null,null,"S3-190961"]
["S3-191031","draft TR 33.855","Deutsche Telekom AG","Hans Christian Rudolph",null,"draft TR","Approval",null,null,null,"5.1",null,null,"approved"]
["S3-190723","Conclusion for KDF negotiation for 5G System Security","Huawei, Hisilicon","Longhua Guo",80179,"pCR","Approval",null,"Ericsson: remove 1st and 3rd sentence . NCSC 2nd sentence needs modification to remove SA3.",null,"5.10","Study of KDF negotiation for 5G System Security (FS_5GS_KDF) (Rel-16)",7230,"Revised","2019-03-04T08:22:46.323","2019-03-04T12:30:02.507","S3-190706","S3-190957","Rel-16","33.808","0.2.0","FS_5GS_KDF"]
["S3-190957","Conclusion for KDF negotiation for 5G System Security","Huawei, Hisilicon","Longhua Guo",80179,"pCR","Approval",null,null,null,"5.10","Study of KDF negotiation for 5G System Security (FS_5GS_KDF) (Rel-16)",7230,"approved",null,null,"S3-190723",null,"Rel-16","33.808","0.2.0","FS_5GS_KDF"]
["S3-190958","new draft TR 33.808","Huawei","Ahmad",null,null,null,null,null,null,"5.10","Study of KDF negotiation for 5G System Security (FS_5GS_KDF) (Rel-16)",7230,"approved"]
["S3-190609","Solution for Slice Specific Authentication and Authorization with multiple registrations in the same PLMN","InterDigital, Inc.","Samir Ferdi",72165,"pCR","Approval","A new solution for Slice Specific Authentication and Authorization when UE is registering in the same AMF in the same serving PLMN over both 3GPP and non-3GPP accesses","Huawei: regarding Slice authentications, you want to check whether this has been done on 3GPP or non-3GPP. Interdigital: We have opened up security details of the SA2 solution. Nokia: SA2 do not differentiate between accesses but you do. Interdigital: We assume that UE may register on both access types. Nokia: That scenario is already covered. Ericsson: Further information is needed on why there is a dependency on different accesses captured agreed for EN. Nokia: Another EN on aligning call flow and terminology with SA2. NEC: we have agreed to use slice or slice-speciifc authentication",null,"5.11","Study on Security aspects of Enhancement of Network Slicing (FS_eNS_SEC) (Rel-16)",6090,"Revised","2019-02-21T15:08:55.930","2019-03-02T15:42:02.570",null,"S3-191002","Rel-16","33.813","0.2.0","FS_eNS_SEC"]
["S3-191002","Solution for Slice Specific Authentication and Authorization with multiple registrations in the same PLMN","InterDigital, Inc.","Samir Ferdi",72165,"pCR","Approval","A new solution for Slice Specific Authentication and Authorization when UE is registering in the same AMF in the same serving PLMN over both 3GPP and non-3GPP accesses",null,null,"5.11","Study on Security aspects of Enhancement of Network Slicing (FS_eNS_SEC) (Rel-16)",6090,"approved",null,null,"S3-190609",null,"Rel-16","33.813","0.2.0","FS_eNS_SEC"]
["S3-190697","Amendment to solution #2","Huawei, HiSilicon","Zander (Zhongding) Lei",66556,"pCR","Approval",null,"Ericsson: What is the role of the SAF - this is not part of the SA2 solution. Huawei: Proposing to change SAF to AAA proxy. NEC: Steps we are adding are incorrect. Nokia The open issue on nesting needs to be solved by SA2 and CT1. NEC: Agree with Nokia - as it is not aligned with SA2 and hence broken. Huawei: It is not broken. Nokia, QC and NEC say it should not go in. ",null,"5.11","Study on Security aspects of Enhancement of Network Slicing (FS_eNS_SEC) (Rel-16)",6560,"noted","2019-03-04T06:36:15.277","2019-03-04T11:21:26.450",null,null,"Rel-16","33.813","0.2.0","FS_eNS_SEC"]
["S3-190692","Discussions on solutions to AMF key separation","Huawei, HiSilicon","Zander (Zhongding) Lei",66556,"discussion","Discussion",null,"Discussion only - comments will be on solution proposals",null,"5.11","Study on Security aspects of Enhancement of Network Slicing (FS_eNS_SEC) (Rel-16)",6570,"noted","2019-03-04T06:36:15.120","2019-03-04T11:21:26.437",null,null,"Rel-16","33.813"]
["S3-190693","AMF key separation solution 1","Huawei, HiSilicon","Zander (Zhongding) Lei",66556,"pCR","Approval",null,"Nokia: Fast re-authentication has been discussed previously. An EN will be added to note this. Ericsson: this still involves of going to the HPLMN so an EN on what are the advantages. NEC: Mutually exclusive slices did not conclude in Rel-16 - there will be an offline check on whether we need an LS to get official confirmation",null,"5.11","Study on Security aspects of Enhancement of Network Slicing (FS_eNS_SEC) (Rel-16)",6920,"noted","2019-03-04T06:36:15.153","2019-03-04T11:21:26.437",null,null,"Rel-16","33.813","0.2.0","FS_eNS_SEC"]
["S3-190694","AMF key separation solution 2","Huawei, HiSilicon","Zander (Zhongding) Lei",66556,"pCR","Approval",null,null,null,"5.11","Study on Security aspects of Enhancement of Network Slicing (FS_eNS_SEC) (Rel-16)",6930,"noted","2019-03-04T06:36:15.200","2019-03-04T11:21:26.437",null,null,"Rel-16","33.813","0.2.0","FS_eNS_SEC"]
["S3-190695","AMF key separation solution 3","Huawei, HiSilicon","Zander (Zhongding) Lei",66556,"pCR","Approval",null,null,null,"5.11","Study on Security aspects of Enhancement of Network Slicing (FS_eNS_SEC) (Rel-16)",6940,"noted","2019-03-04T06:36:15.230","2019-03-04T11:21:26.450",null,null,"Rel-16","33.813","0.2.0","FS_eNS_SEC"]
["S3-190799","KAMF separation using a standalone SEAF","Qualcomm Incorporated","Adrian Escott",24089,"pCR","Approval",null,null,null,"5.11","Study on Security aspects of Enhancement of Network Slicing (FS_eNS_SEC) (Rel-16)",6950,"noted","2019-03-04T11:30:16.553","2019-03-04T14:20:18.480",null,null,"Rel-16","33.813","0.2.0","FS_eNS_SEC"]
["S3-190814","Solution for key separation based on slice authentication keys","Ericsson","Noamen Ben Henda",63310,"pCR","Approval",null,null,null,"5.11","Study on Security aspects of Enhancement of Network Slicing (FS_eNS_SEC) (Rel-16)",6960,"noted","2019-03-04T11:52:14.083","2019-03-04T14:01:11.460",null,null,"Rel-16","33.813","0.3.0","FS_eNS_SEC"]
["S3-190696","Discussion on provisioning security features for a network slice","Huawei, HiSilicon","Zander (Zhongding) Lei",66556,"discussion","Discussion",null,"Motivating solutions in other papers",null,"5.11","Study on Security aspects of Enhancement of Network Slicing (FS_eNS_SEC) (Rel-16)",6970,"noted","2019-03-04T06:36:15.260","2019-03-04T11:21:26.450",null,null,"Rel-16","33.813"]
["S3-190698","Amendment to solution #3","Huawei, HiSilicon","Zander (Zhongding) Lei",66556,"pCR","Approval",null,"Nokia: Policy can be configured in the SMF. Huawei: Configuring a slice has all the possibilites but just want to have a small set of things that can be configured. This is done through management plane. Nokia: These details should be provided  in the solution. ZTE: Why is there secondary authentication for a slice. Huawei: You have a choice to use this at PDU session set-up. TI: Does not understand the link between secondary and slice authentication. BT: Clarity needed on what can be done dynamically and what is fixed in the network. The slices needs to have something unque about them, otherwise what is the point. Offline discussion concluded on revision of a sentence.",null,"5.11","Study on Security aspects of Enhancement of Network Slicing (FS_eNS_SEC) (Rel-16)",6980,"Revised","2019-03-04T06:36:15.293","2019-03-04T11:21:26.467",null,"S3-191007","Rel-16","33.813","0.2.0","FS_eNS_SEC"]
["S3-191007","Amendment to solution #3","Huawei, HiSilicon","Zander (Zhongding) Lei",66556,"pCR","Approval",null,null,null,"5.11","Study on Security aspects of Enhancement of Network Slicing (FS_eNS_SEC) (Rel-16)",6980,"approved",null,null,"S3-190698",null,"Rel-16","33.813","0.2.0","FS_eNS_SEC"]
["S3-190867","Privacy for Slice Authentication","Lenovo, Motorola Mobility","Andreas Kunz",72589,"pCR","Approval","This paper introduces a solution on Key Issue #4: Security and privacy aspects related to the solution for Network Slice specific access authentication and authorization.","Orange: Concerned about the binding between the S-NSSAI and public leaks informatio about the networks deployment. It was agreed to remove that binding. QC: Privacy is EAP method specific and hence there is no reason to have the solution. Lenovo: There is a key issue for this so we should study for solutions. If someone believes that the key issue is no longer valid., the they should propose removing it. Huawei: Support including the solution. Ericsson: Does this chage EAP. Lenovo: Some impact on decrypting identity",null,"5.11","Study on Security aspects of Enhancement of Network Slicing (FS_eNS_SEC) (Rel-16)",6990,"Revised","2019-03-04T13:48:25.153","2019-03-04T14:29:22.950",null,"S3-191017","Rel-16","33.813","0.2.0","FS_eNS_SEC"]
["S3-191017","Privacy for Slice Authentication","Lenovo, Motorola Mobility","Andreas Kunz",72589,"pCR","Approval","This paper introduces a solution on Key Issue #4: Security and privacy aspects related to the solution for Network Slice specific access authentication and authorization.","Lenovo: Think that this a workable solution. QC raied 3 EN - identity for slice auth is in scope, problem with public key and secondary auth uses EAP. ",null,"5.11","Study on Security aspects of Enhancement of Network Slicing (FS_eNS_SEC) (Rel-16)",6990,"Revised",null,null,"S3-190867","S3-191034","Rel-16","33.813","0.2.0","FS_eNS_SEC"]
["S3-191034","Privacy for Slice Authentication","Lenovo, Motorola Mobility","Andreas Kunz",72589,"pCR","Approval","This paper introduces a solution on Key Issue #4: Security and privacy aspects related to the solution for Network Slice specific access authentication and authorization.",null,null,"5.11","Study on Security aspects of Enhancement of Network Slicing (FS_eNS_SEC) (Rel-16)",6990,"approved",null,null,"S3-191017",null,"Rel-16","33.813","0.2.0","FS_eNS_SEC"]
["S3-190738","Remove EN in 6.6.3","Huawei, Hisilicon","Bo Zhang",49401,"pCR","Approval",null,"Orange: Inconsistent to remove only one of the ENs as they refer to eachother. Huawei: Remove the first EN as well. It was agreed.",null,"5.11","Study on Security aspects of Enhancement of Network Slicing (FS_eNS_SEC) (Rel-16)",7380,"Revised","2019-03-04T09:32:21.520","2019-03-04T10:21:44.847",null,"S3-191008","Rel-16","33.813","0.2.0","FS_eNS_SEC"]
["S3-191008","Remove EN in 6.6.3","Huawei, Hisilicon","Bo Zhang",49401,"pCR","Approval",null,"Approved without being seen",null,"5.11","Study on Security aspects of Enhancement of Network Slicing (FS_eNS_SEC) (Rel-16)",7380,"approved",null,null,"S3-190738",null,"Rel-16","33.813","0.2.0","FS_eNS_SEC"]
["S3-190739","Solution for slice specific authorization","Huawei, Hisilicon","Bo Zhang",49401,"pCR","Approval",null,"Nokia: What is NSI-ID - a reference will be added  to clarify this. ",null,"5.11","Study on Security aspects of Enhancement of Network Slicing (FS_eNS_SEC) (Rel-16)",7390,"Revised","2019-03-04T09:32:21.537","2019-03-04T10:21:44.847",null,"S3-191009","Rel-16","33.813","0.2.0","FS_eNS_SEC"]
["S3-191009","Solution for slice specific authorization","Huawei, Hisilicon","Bo Zhang",49401,"pCR","Approval",null,"Approved after check with Suresh",null,"5.11","Study on Security aspects of Enhancement of Network Slicing (FS_eNS_SEC) (Rel-16)",7390,"Approved",null,null,"S3-190739",null,"Rel-16","33.813","0.2.0","FS_eNS_SEC"]
["S3-190656","NSSAI protection during the RRC connection establishment procedure","NEC Europe Ltd","Taka Yoshizawa",40702,"pCR","Approval","This contribution proposes a new solution.","ZTE: It is not clear how the security context is found. Add EN about finding the source gNB. Nokia: UE has NAS context so AMF already known, so what is actually being protected. NEC: The S-NSSAI are protected during the Service Request procedure. Huawei: Agree with Nokia. NEC: S-NSSAI is used not only for routing but also AS procedure. Qualcomm: concern about keeping state in idle and should note. The were other companies concerned about storage of state in RRC-inactive",null,"5.11","Study on Security aspects of Enhancement of Network Slicing (FS_eNS_SEC) (Rel-16)",7710,"noted","2019-03-03T09:19:33.103","2019-03-04T13:35:51.903",null,null,"Rel-16","33.813","0.2.0","FS_eNS_SEC"]
["S3-190657","NSSAI protection during the RRC connection establishment procedure","NEC Europe Ltd","Taka Yoshizawa",40702,"pCR","Approval","This contribution proposes a new solution.","Ericsson: Issue is that the routing to an AMF is already done and doesn't this defeat the purpose of procedure. NEC: S-NSSAIs are needed for more than just AMF selection. Qualcomm: How is AMF found? NEC: with GUTI. Ericsson & Nokia: Not clear what the problem is and the why the solution is needed. NEC: Key and not AS security context is provided to the gNB. Ericsson: Not clear why the RAN needs S-NSSAI other than for AMF selection. Gematlo: Have a similar connection. NEC: S-NSSAI is contained in RRC message for purposes other than AMF selection. ",null,"5.11","Study on Security aspects of Enhancement of Network Slicing (FS_eNS_SEC) (Rel-16)",7910,"noted","2019-03-03T09:21:15.737","2019-03-04T13:35:51.903",null,null,"Rel-16","33.813","0.2.0","FS_eNS_SEC"]
["S3-190791","Proposed solution for protecting the S-NSSAI for transmission at the AS layer","Qualcomm Incorporated","Adrian Escott",24089,"pCR","Approval",null,"Overall teh reasons for S-NSSAIs was not clear",null,"5.11","Study on Security aspects of Enhancement of Network Slicing (FS_eNS_SEC) (Rel-16)",7990,"noted","2019-03-04T11:30:16.303","2019-03-04T14:20:18.497",null,null,"Rel-16","33.813","0.2.0","FS_eNS_SEC"]
["S3-190699","Amendment to KI#6","Huawei, HiSilicon","Zander (Zhongding) Lei",66556,"pCR","Approval",null,"NEC: not sure the change is needed. Nokia: don’t believe change is needed. Orange, Ericsson and Qualcomm are not supportive of the changes.",null,"5.11","Study on Security aspects of Enhancement of Network Slicing (FS_eNS_SEC) (Rel-16)",8140,"noted","2019-03-04T06:36:15.307","2019-03-04T11:21:26.467",null,"S3-190949","Rel-16","33.813","0.2.0","FS_eNS_SEC"]
["S3-190949","Require for sending S-NSSAI for RRCSet-up procedure","NEC","Kundan Tiwari",null,"LS out","Approval",null,null,null,"5.11","Study on Security aspects of Enhancement of Network Slicing (FS_eNS_SEC) (Rel-16)",8140,"withdrawn",null,null,null,null,null,null,null,null,null,null,null,null,null,"RAN2"]
["S3-190771","Key issue on Granularity of isolation for slice specific security","LG Electronics","Joonwoong Kim",66512,"pCR","Approval",null,"Related to key separation ",null,"5.11","Study on Security aspects of Enhancement of Network Slicing (FS_eNS_SEC) (Rel-16)",8670,"noted","2019-03-04T11:08:33.387","2019-03-04T11:18:06.330",null,null,"Rel-16","33.813","0.2.0","FS_eNS_SEC"]
["S3-190948","new draft TR 33.813","Nokia","Suresh Nair",null,"draft TR","Approval",null,null,null,"5.11","Study on Security aspects of Enhancement of Network Slicing (FS_eNS_SEC) (Rel-16)",8670,"approved"]
["S3-190731","pCR to TR33.814 – Text for Clause Introduction","CATT","Wei Zhou",61782,"pCR","Approval",null,"The difference between regulatory and commercial location services was not clear and not needed in the introducation - the document will be revised to remove these terms",null,"5.12","Study on Security of the enhancement to the 5GC location services (FS_eLCS_Sec) (Rel-16)",7180,"Revised","2019-03-04T08:58:30.910","2019-03-04T09:10:18.530",null,"S3-190898","Rel-16","33.814","0.2.0","FS_eLCS_Sec"]
["S3-190898","pCR to TR33.814 – Text for Clause Introduction","CATT","Wei Zhou",61782,"pCR","Approval",null,null,null,"5.12","Study on Security of the enhancement to the 5GC location services (FS_eLCS_Sec) (Rel-16)",7180,"Approved",null,null,"S3-190731",null,"Rel-16","33.814","0.2.0","FS_eLCS_Sec"]
["S3-190732","Text for Clause 4 Security aspects of eLCS","CATT","Wei Zhou",61782,"pCR","Approval",null,"There was discussion on commercial location not being fully specified in Rel-15 and needs to be enhanced in Rel-16. This leads to a need to re-word 4.1 to account for this. It was agreed to remove 4.2.",null,"5.12","Study on Security of the enhancement to the 5GC location services (FS_eLCS_Sec) (Rel-16)",7190,"Revised","2019-03-04T09:04:45.257","2019-03-04T09:10:18.530",null,"S3-190899","Rel-16","33.814","0.2.0","FS_eLCS_Sec"]
["S3-190899","Text for Clause 4 Security aspects of eLCS","CATT","Wei Zhou",61782,"pCR","Approval",null,null,null,"5.12","Study on Security of the enhancement to the 5GC location services (FS_eLCS_Sec) (Rel-16)",7190,"approved",null,null,"S3-190732",null,"Rel-16","33.814","0.2.0","FS_eLCS_Sec"]
["S3-190729","pCR to TR33.814 - Key issue for positioning data confidentiality protection","CATT","Wei Zhou",61782,"pCR","Approval",null,"There was general agreement on this but will be will taken offline for re-wording - the revision of this will contain an EN to agree that there will be no mechanism to protect individual NAS IEs.",null,"5.12","Study on Security of the enhancement to the 5GC location services (FS_eLCS_Sec) (Rel-16)",7200,"Revised","2019-03-04T08:49:41.480","2019-03-04T09:10:18.513",null,"S3-190900","Rel-16","33.814","0.2.0","FS_eLCS_Sec"]
["S3-190900","pCR to TR33.814 - Key issue for positioning data confidentiality protection","CATT","Wei Zhou",61782,"pCR","Approval",null,null,null,"5.12","Study on Security of the enhancement to the 5GC location services (FS_eLCS_Sec) (Rel-16)",7200,"approved",null,null,"S3-190729",null,"Rel-16","33.814","0.2.0","FS_eLCS_Sec"]
["S3-190719","Key Issue for encryption and integrity protection of assistance data","Huawei, Hisilicon","Longhua Guo",80179,"pCR","Approval",null,"It was not clear what was missing from the Rel-15 security - this analysis would help the understanding of this key issue",null,"5.12","Study on Security of the enhancement to the 5GC location services (FS_eLCS_Sec) (Rel-16)",7210,"noted","2019-03-04T08:08:52.140","2019-03-04T12:30:02.477",null,null,"Rel-16","33.814","0.2.0","FS_eLCS_Sec"]
["S3-190720","Key Issue for encryption and integrity protection of location data","Huawei, Hisilicon","Longhua Guo",80179,"pCR","Approval",null,"This contribution overlaps with S3-190729 and will be merged into the revision of that document. ",null,"5.12","Study on Security of the enhancement to the 5GC location services (FS_eLCS_Sec) (Rel-16)",7220,"merged","2019-03-04T08:08:52.203","2019-03-04T12:30:02.490",null,null,"Rel-16","33.814","0.2.0","FS_eLCS_Sec"]
["S3-190730","pCR to TR33.814 - Solution for positioning data confidentiality protection","CATT","Wei Zhou",61782,"pCR","Approval",null,"It was felt too early to conclude on this solution as there is no key issue for this yet, i.e. need to resolve whether there needs to be protection of NAS IEs when NAS security is not activated. The meeting agreed that there should not be a mechanism to protect individual NAS IEs- this will be captured by an EN in S3-190900.",null,"5.12","Study on Security of the enhancement to the 5GC location services (FS_eLCS_Sec) (Rel-16)",7290,"noted","2019-03-04T08:53:24.753","2019-03-04T09:10:18.530",null,null,"Rel-16","33.814","0.2.0","FS_eLCS_Sec"]
["S3-190721","Key Issue for privacy setting integrity between UE and homenetwork","Huawei, Hisilicon","Longhua Guo",80179,"pCR","Approval",null,"There was much discussion on whether this is a legitimate key issue. It was felt that the serving network can already determine the UE's location and hence it is not possible to prevent a serving network fro using the UE's locations. Mechanisms outside the scope of standards could be useful here. A NOTE will be added to S3-190900 to try to capture this discussion - otherwise an EN wil be added . ",null,"5.12","Study on Security of the enhancement to the 5GC location services (FS_eLCS_Sec) (Rel-16)",7300,"noted","2019-03-04T08:08:52.263","2019-03-04T12:30:02.490",null,null,"Rel-16","33.814","0.2.0","FS_eLCS_Sec"]
["S3-190772","Key issue on UE location privacy setting","LG Electronics","Joonwoong Kim",66512,"pCR","Approval",null,"The same disscusion as above document.",null,"5.12","Study on Security of the enhancement to the 5GC location services (FS_eLCS_Sec) (Rel-16)",7310,"noted","2019-03-04T11:08:33.403","2019-03-04T11:18:06.330",null,null,"Rel-16","33.814","0.2.0","FS_eLCS_Sec"]
["S3-190755","New KI: Privacy control in LCS","Ericsson","Prajwol Kumar Nakarmi",76183,"pCR","Approval",null,"The word ' effective' was removed from the requirement as it is not easy to assess what is effective. 'System' was changed to '5G system' in the requirement. An EN is added to capture the open issue of who enforces the privacy.",null,"5.12","Study on Security of the enhancement to the 5GC location services (FS_eLCS_Sec) (Rel-16)",7320,"Revised","2019-03-04T10:03:56.237","2019-03-04T13:08:56.320",null,"S3-190902","Rel-16","33.814","0.2.0","FS_eLCS_Sec"]
["S3-190902","New KI: Privacy control in LCS","Ericsson","Prajwol Kumar Nakarmi",76183,"pCR","Approval",null,"Approved without being seen",null,"5.12","Study on Security of the enhancement to the 5GC location services (FS_eLCS_Sec) (Rel-16)",7320,"approved",null,null,"S3-190755",null,"Rel-16","33.814","0.2.0","FS_eLCS_Sec"]
["S3-190881","Key Issue proposal on location measurement tampering for FS_eLCS_Sec","Philips International B.V.","John Bernsen",35096,"pCR","Approval","In several 3GPP location services, the UE of which the location is to be determined performs measurements itself and sends these measurements to the network so the network can determine its location. Examples are\n•\tOTDOA (Observed Time Difference Of Arriv","Corrections were needed to the fomatting. 5.X.2 needs to be removed as that is not used for key issues in this topic. The 'etc.' is removed from security threats. It was felt that the threats could be re-written to make it clear that the ME is lying about location related data and also to include threats when location can be monitized in some way, e.g. cheaper calls from home. It was agreed to remove the requirements. ",null,"5.12","Study on Security of the enhancement to the 5GC location services (FS_eLCS_Sec) (Rel-16)",7510,"Revised","2019-03-06T09:22:02.077","2019-03-06T09:31:26.730",null,"S3-190903","Rel-16","33.814","0.2.0","FS_eLCS_Sec"]
["S3-190903","Key Issue proposal on location measurement tampering for FS_eLCS_Sec","Philips International B.V.","John Bernsen",35096,"pCR","Approval","In several 3GPP location services, the UE of which the location is to be determined performs measurements itself and sends these measurements to the network so the network can determine its location. Examples are\n•\tOTDOA (Observed Time Difference Of Arriv","Remove changes over changes",null,"5.12","Study on Security of the enhancement to the 5GC location services (FS_eLCS_Sec) (Rel-16)",7510,"Revised",null,null,"S3-190881","S3-190959","Rel-16","33.814","0.2.0","FS_eLCS_Sec"]
["S3-190959","Key Issue proposal on location measurement tampering for FS_eLCS_Sec","Philips International B.V.","John Bernsen",35096,"pCR","Approval","In several 3GPP location services, the UE of which the location is to be determined performs measurements itself and sends these measurements to the network so the network can determine its location. Examples are\n•\tOTDOA (Observed Time Difference Of Arriv","Approved without being seen",null,"5.12","Study on Security of the enhancement to the 5GC location services (FS_eLCS_Sec) (Rel-16)",7510,"approved",null,null,"S3-190903",null,"Rel-16","33.814","0.2.0","FS_eLCS_Sec"]
["S3-190722","Solution on integrity protection of privacy setting between UE and UDM","Huawei, Hisilicon","Longhua Guo",80179,"pCR","Approval",null,null,null,"5.12","Study on Security of the enhancement to the 5GC location services (FS_eLCS_Sec) (Rel-16)",7520,"noted","2019-03-04T08:08:52.343","2019-03-04T12:30:02.507",null,null,"Rel-16","33.814","0.2.0","FS_eLCS_Sec"]
["S3-190756","New solution: Effective privacy control in LCS","Ericsson","Prajwol Kumar Nakarmi",76183,"pCR","Approval",null,"There were several changes agreed for this contribution, namely remove effective and replace with enhanced, add sentence on steps and clarify the measurements are related to location measurements ",null,"5.12","Study on Security of the enhancement to the 5GC location services (FS_eLCS_Sec) (Rel-16)",7530,"Revised","2019-03-04T10:03:56.253","2019-03-04T13:08:56.320",null,"S3-190904","Rel-16","33.814","0.2.0","FS_eLCS_Sec"]
["S3-190904","New solution: Effective privacy control in LCS","Ericsson","Prajwol Kumar Nakarmi",76183,"pCR","Approval",null,"Approved with being seen",null,"5.12","Study on Security of the enhancement to the 5GC location services (FS_eLCS_Sec) (Rel-16)",7530,"approved",null,null,"S3-190756",null,"Rel-16","33.814","0.2.0","FS_eLCS_Sec"]
["S3-190751","New solution: WLAN measurements from UEs","Ericsson","Prajwol Kumar Nakarmi",76183,"pCR","Approval",null,"It was commented that the WLAN identities can be spoofed, then there would be a lack of confidence in the data. It was agreed to add a sentence of the contribution. Editorially it is needed to decide UE or UEs in many places. Clarification on the serving network and the fact that it is for managed WLAN documents. Some of the wording will be checked offline. ",null,"5.12","Study on Security of the enhancement to the 5GC location services (FS_eLCS_Sec) (Rel-16)",7540,"Revised","2019-03-04T10:03:55.987","2019-03-04T13:08:56.273",null,"S3-190905","Rel-16","33.814","0.2.0","FS_eLCS_Sec"]
["S3-190905","New solution: WLAN measurements from UEs","Ericsson","Prajwol Kumar Nakarmi",76183,"pCR","Approval",null,null,null,"5.12","Study on Security of the enhancement to the 5GC location services (FS_eLCS_Sec) (Rel-16)",7540,"approved",null,null,"S3-190751",null,"Rel-16","33.814","0.2.0","FS_eLCS_Sec"]
["S3-190752","New solution: Bluetooth measurements from UEs","Ericsson","Prajwol Kumar Nakarmi",76183,"pCR","Approval",null,"same comments as to 751, so same updates",null,"5.12","Study on Security of the enhancement to the 5GC location services (FS_eLCS_Sec) (Rel-16)",7550,"Revised","2019-03-04T10:03:56.003","2019-03-04T13:08:56.287",null,"S3-190906","Rel-16","33.814","0.2.0","FS_eLCS_Sec"]
["S3-190906","New solution: Bluetooth measurements from UEs","Ericsson","Prajwol Kumar Nakarmi",76183,"pCR","Approval",null,null,null,"5.12","Study on Security of the enhancement to the 5GC location services (FS_eLCS_Sec) (Rel-16)",7550,"approved",null,null,"S3-190752",null,"Rel-16","33.814","0.2.0","FS_eLCS_Sec"]
["S3-190753","Update KI: TBS positioning","Ericsson","Prajwol Kumar Nakarmi",76183,"pCR","Approval",null,"no comments",null,"5.12","Study on Security of the enhancement to the 5GC location services (FS_eLCS_Sec) (Rel-16)",7560,"approved","2019-03-04T10:03:56.017","2019-03-04T13:08:56.287",null,null,"Rel-16","33.814","0.2.0","FS_eLCS_Sec"]
["S3-190754","New solution: TBS measurements from UEs","Ericsson","Prajwol Kumar Nakarmi",76183,"pCR","Approval",null,"VF: how to reconciliate the non-commercial nature of R15 with the statement that R15 solution is sufficient. E//: Add sentence that R15 is sufficient also for commercial LCS BT: spoofing of SSIDs is easy, similar sentence to 751 ",null,"5.12","Study on Security of the enhancement to the 5GC location services (FS_eLCS_Sec) (Rel-16)",7720,"Revised","2019-03-04T10:03:56.017","2019-03-04T13:08:56.303",null,"S3-190907","Rel-16","33.814","0.2.0","FS_eLCS_Sec"]
["S3-190907","New solution: TBS measurements from UEs","Ericsson","Prajwol Kumar Nakarmi",76183,"pCR","Approval",null,null,null,"5.12","Study on Security of the enhancement to the 5GC location services (FS_eLCS_Sec) (Rel-16)",7720,"approved",null,null,"S3-190754",null,"Rel-16","33.814","0.2.0","FS_eLCS_Sec"]
["S3-190718","Solution for updating key to broadcast assitance data","Huawei, Hisilicon","Longhua Guo",80179,"pCR","Approval",null,null,null,"5.12","Study on Security of the enhancement to the 5GC location services (FS_eLCS_Sec) (Rel-16)",8810,"noted","2019-03-04T08:08:52.077","2019-03-04T12:30:02.477",null,null,"Rel-16","33.814","0.2.0","FS_eLCS_Sec"]
["S3-190901","New draft TR 33.814","CATT",null,null,"draft TR","Approval",null,null,null,"5.12","Study on Security of the enhancement to the 5GC location services (FS_eLCS_Sec) (Rel-16)",8810,"approved"]
["S3-190681","overall introduction","Huawei, HiSilicon","Zander (Zhongding) Lei",66556,"pCR","Approval",null,"After discussion, there were no changes requested",null,"5.13","Study on security for 5G URLLC (FS_5G URLLC_SEC) (Rel-16)",6190,"approved","2019-03-04T06:36:14.917","2019-03-04T11:21:26.497",null,null,"Rel-16","33.825","0.3.0","FS_5G_URLLC_SEC"]
["S3-190619","URLLC-KI UP security performance for low latency","ZTE Corporation","Zhenhua Xie",38520,"pCR","Approval",null,"Ericsson: Does not seem to be enough evidence from the key issue details to justify the requirement. ZTE: Details for IPsec are only example and the can be a ways to optimise performance. NEC: Does not understand the issue and support Ericsson view. Ericsson proposal to add EN to key issue details to say that further justification is required before SA3 proceeds with this key issue needed and delete the threat and requirements. Nokia: Remove the last sentence in key issue details. This proposal was accepted.",null,"5.13","Study on security for 5G URLLC (FS_5G URLLC_SEC) (Rel-16)",6200,"Revised","2019-03-02T01:47:49.027","2019-03-04T10:10:54.343",null,"S3-190969","Rel-16","33.825","0.3.0","FS_5G_URLLC_SEC"]
["S3-190969","URLLC-KI UP security performance for low latency","ZTE Corporation","Zhenhua Xie",38520,"pCR","Approval",null,null,null,"5.13","Study on security for 5G URLLC (FS_5G URLLC_SEC) (Rel-16)",6200,"Approved",null,null,"S3-190619",null,"Rel-16","33.825","0.3.0","FS_5G_URLLC_SEC"]
["S3-190620","URLLC-solution Enhancement of handover with Xn forwarding tunnel","ZTE Corporation","Zhenhua Xie",38520,"pCR","Approval",null,"Related to the key issue in S3-190969 and hence noted as no agreemnt to proceed on key issue.",null,"5.13","Study on security for 5G URLLC (FS_5G URLLC_SEC) (Rel-16)",6310,"Noted","2019-03-02T01:47:49.293","2019-03-04T10:10:54.343",null,null,"Rel-16","33.825","0.3.0","FS_5G_URLLC_SEC"]
["S3-190819","New solution for security for redundant data transmission using Dual Connectivity procedures","Ericsson","Noamen Ben Henda",63310,"pCR","Approval",null,"Huawei: There are other contributions addressing similar solutions. Ericsson: why not have two solutions. Huawei: Concern on the details of handling of UP security policy - remove 'or other solution' to make it clear that solution #1 is used. This was agreeable. Huawei: is this an update of solution #1. Ericsson: That is a different problem to the one addressed here which is about the keys and traffic protection. Qualcomm: reference numbers are not correct - this will be corrected in revision.",null,"5.13","Study on security for 5G URLLC (FS_5G URLLC_SEC) (Rel-16)",6770,"Revised","2019-03-04T11:52:14.193","2019-03-04T14:01:11.477",null,"S3-190970","Rel-16","33.825","0.2.0","FS_5G_URLLC_SEC"]
["S3-190970","New solution for security for redundant data transmission using Dual Connectivity procedures","Ericsson","Noamen Ben Henda",63310,"pCR","Approval",null,"Approved without being seen",null,"5.13","Study on security for 5G URLLC (FS_5G URLLC_SEC) (Rel-16)",6770,"Approved",null,null,"S3-190819",null,"Rel-16","33.825","0.2.0","FS_5G_URLLC_SEC"]
["S3-190631","Evaluation and text for resolving editor’s note for solution #5 in TR 33.825","NEC Europe Ltd","Taka Yoshizawa",40702,"pCR","Approval","This contribution proposes solution evaluation and text for resolving editor’s note for solution #5 in TR 33.825.","Authors agreed to merge S3-190631 and S3-190682. Ericsson: More justifcation fo the change in keying as this is a major change to the architecture. Qualcomm: Concern that more security analysis is needed as the security model has changed. Huawei: this is a new service so we can use new solution. NEC: Concerned that the key issue is being interpreted in different ways. Ok to merge the documents with the EN on further evaluation is needed and an EN on justification for the use of new key. ",null,"5.13","Study on security for 5G URLLC (FS_5G URLLC_SEC) (Rel-16)",6780,"merged","2019-03-03T08:12:25.783","2019-03-04T13:35:51.920",null,null,"Rel-16","33.825","0.3.0","FS_5G_URLLC_SEC"]
["S3-190682","URLLC solution5 update","Huawei, HiSilicon","Zander (Zhongding) Lei",66556,"pCR","Approval",null,"See discussion on S3-190682",null,"5.13","Study on security for 5G URLLC (FS_5G URLLC_SEC) (Rel-16)",6790,"Revised","2019-03-04T06:36:14.933","2019-03-04T11:21:26.513",null,"S3-190971","Rel-16","33.825","0.3.0","FS_5G_URLLC_SEC"]
["S3-190971","URLLC solution5 update","Huawei, HiSilicon","Zander (Zhongding) Lei",66556,"pCR","Approval",null,null,null,"5.13","Study on security for 5G URLLC (FS_5G URLLC_SEC) (Rel-16)",6790,"Approved",null,null,"S3-190682",null,"Rel-16","33.825","0.3.0","FS_5G_URLLC_SEC"]
["S3-190689","Dynamic UP security policy control solution for URLLC","Huawei, HiSilicon","Zander (Zhongding) Lei",66556,"pCR","Approval",null,"Erisscon: What's new compared to now as there is some mention of dynamic. Not clear how you solve using the same policy on each leg. Huawei: the new issue is that SMF can get something from PCF. An EN saying further information on how this solution manages redundant policy.",null,"5.13","Study on security for 5G URLLC (FS_5G URLLC_SEC) (Rel-16)",6800,"Revised","2019-03-04T06:36:15.073","2019-03-04T13:56:15.740",null,"S3-190972","Rel-16","33.825","0.3.0","FS_UP_IP_Sec, FS_5G_URLLC_SEC"]
["S3-190972","Dynamic UP security policy control solution for URLLC","Huawei, HiSilicon","Zander (Zhongding) Lei",66556,"pCR","Approval",null,"Approved without being seen",null,"5.13","Study on security for 5G URLLC (FS_5G URLLC_SEC) (Rel-16)",6800,"Approved",null,null,"S3-190689",null,"Rel-16","33.825","0.3.0","FS_UP_IP_Sec, FS_5G_URLLC_SEC"]
["S3-190818","Solution #Y: Security for redundant data transmission using Dual Connectivity","Ericsson","Noamen Ben Henda",63310,"pCR","Approval",null,"Huawei: For solution details, more details are needed on the handling of the solution for issue #1. For issue #2, selection of SN might depend on capabailities. For issue #1, it was agreed to have an EN on the need for more details. For solution #2, the discussion was taken offline. Qualcomm: How does this relate to solution #1. Ericsson: it is an alternative to solution #1.",null,"5.13","Study on security for 5G URLLC (FS_5G URLLC_SEC) (Rel-16)",6810,"Revised","2019-03-04T11:52:14.163","2019-03-04T14:01:11.477",null,"S3-190973","Rel-16","33.825","0.2.0","FS_5G_URLLC_SEC"]
["S3-190973","Solution #Y: Security for redundant data transmission using Dual Connectivity","Ericsson","Noamen Ben Henda",63310,"pCR","Approval",null,null,null,"5.13","Study on security for 5G URLLC (FS_5G URLLC_SEC) (Rel-16)",6810,"Approved",null,null,"S3-190818",null,"Rel-16","33.825","0.2.0","FS_5G_URLLC_SEC"]
["S3-190685","solution1 and evaluation update","Huawei, HiSilicon","Zander (Zhongding) Lei",66556,"pCR","Approval",null,"Ericsson: Are concerned that the text actaully goes against the original proposal in the solution. It is taken offline to consider the changes and how they could be adapted to be inline with the current solution",null,"5.13","Study on security for 5G URLLC (FS_5G URLLC_SEC) (Rel-16)",6820,"Revised","2019-03-04T06:36:14.997","2019-03-04T11:21:26.530",null,"S3-190974","Rel-16","33.825","0.3.0","FS_5G_URLLC_SEC"]
["S3-190974","solution1 and evaluation update","Huawei, HiSilicon","Zander (Zhongding) Lei",66556,"pCR","Approval",null,null,null,"5.13","Study on security for 5G URLLC (FS_5G URLLC_SEC) (Rel-16)",6820,"Approved",null,null,"S3-190685",null,"Rel-16","33.825","0.3.0","FS_5G_URLLC_SEC"]
["S3-190680","deleting the EN of solution3","Huawei, HiSilicon","Zander (Zhongding) Lei",66556,"pCR","Approval",null,"Ericsson: convern that the UP security policy is changing. An EN on this will be added to the key issue details",null,"5.13","Study on security for 5G URLLC (FS_5G URLLC_SEC) (Rel-16)",6830,"Revised","2019-03-04T06:36:14.903","2019-03-04T11:21:26.497",null,"S3-190975","Rel-16","33.825","0.3.0","FS_5G_URLLC_SEC"]
["S3-190975","deleting the EN of solution3","Huawei, HiSilicon","Zander (Zhongding) Lei",66556,"pCR","Approval",null,"Approved without being seen",null,"5.13","Study on security for 5G URLLC (FS_5G URLLC_SEC) (Rel-16)",6830,"Approved",null,null,"S3-190680",null,"Rel-16","33.825","0.3.0","FS_5G_URLLC_SEC"]
["S3-190820","Correction to solution #3 ‘Security policy handling for redundant data transmission’","Ericsson","Noamen Ben Henda",63310,"pCR","Approval",null,"No commnets",null,"5.13","Study on security for 5G URLLC (FS_5G URLLC_SEC) (Rel-16)",6840,"Approved","2019-03-04T11:52:14.210","2019-03-04T14:01:11.477",null,null,"Rel-16","33.825","0.2.0","FS_5G_URLLC_SEC"]
["S3-190683","evaluation of solution 3","Huawei, HiSilicon","Zander (Zhongding) Lei",66556,"pCR","Approval",null,"Ericsson: EN has been added to the solution in an earlier document. Second sentence of evaluation was removed. Orange: Modify the exisiitng note to make it read that further evaluation is still needed. LI EN will be removed.",null,"5.13","Study on security for 5G URLLC (FS_5G URLLC_SEC) (Rel-16)",6850,"Revised","2019-03-04T06:36:14.950","2019-03-04T11:21:26.513",null,"S3-190976","Rel-16","33.825","0.3.0","FS_5G_URLLC_SEC"]
["S3-190976","evaluation of solution 3","Huawei, HiSilicon","Zander (Zhongding) Lei",66556,"pCR","Approval",null,null,null,"5.13","Study on security for 5G URLLC (FS_5G URLLC_SEC) (Rel-16)",6850,"Approved",null,null,"S3-190683",null,"Rel-16","33.825","0.3.0","FS_5G_URLLC_SEC"]
["S3-190679","solution 2 clarification","Huawei, HiSilicon","Zander (Zhongding) Lei",66556,"pCR","Approval",null,"Ericsson: Add 'as described in TS 33.501 to end of new text. Evaluation text format to be corrected.",null,"5.13","Study on security for 5G URLLC (FS_5G URLLC_SEC) (Rel-16)",6860,"Revised","2019-03-04T06:36:14.870","2019-03-04T11:21:26.483",null,"S3-190977","Rel-16","33.825","0.3.0","FS_5G_URLLC_SEC"]
["S3-190977","solution 2 clarification","Huawei, HiSilicon","Zander (Zhongding) Lei",66556,"pCR","Approval",null,"Approved without being seen.",null,"5.13","Study on security for 5G URLLC (FS_5G URLLC_SEC) (Rel-16)",6860,"Approved",null,null,"S3-190679",null,"Rel-16","33.825","0.3.0","FS_5G_URLLC_SEC"]
["S3-190678","conclusion for key issue 6","Huawei, HiSilicon","Zander (Zhongding) Lei",66556,"pCR","Approval",null,null,null,"5.13","Study on security for 5G URLLC (FS_5G URLLC_SEC) (Rel-16)",6870,"approved","2019-03-04T06:36:14.857","2019-03-04T11:21:26.483",null,null,"Rel-16","33.825","0.3.0","FS_5G_URLLC_SEC"]
["S3-190796","Conclusion on KI #6 for Study on the security for URLLC","Qualcomm Incorporated","Adrian Escott",24089,"pCR","Approval",null,"Same content as S3-190678 which was approved",null,"5.13","Study on security for 5G URLLC (FS_5G URLLC_SEC) (Rel-16)",6890,"noted","2019-03-04T11:30:16.490","2019-03-04T14:20:18.463",null,null,"Rel-16","33.825","0.3.0","FS_5G_URLLC_SEC"]
["S3-190979","draft TR 33.825",null,null,null,null,null,null,null,null,"5.13","Study on SECAM and SCAS for 3GPP virtualized network products (FS_VNP_SECAM_SCAS) (Rel-16)",7570,"approved"]
["S3-190686","conclusion for key issue 1","Huawei, HiSilicon","Zander (Zhongding) Lei",66556,"pCR","Approval",null,"QC: not ready to make comclusion on key issue 1 for solution 5. need to resolve ed not first. Also issue with other solution. Huawei: why note? Chair: no other support, no further comments. Orange: remove all conclusions on solution 5. Huawei: get straight what means cryptographic separation. E//: note this conclusion for now. there is a new solution on key issue 1.",null,"5.13","Study on security for 5G URLLC (FS_5G URLLC_SEC) (Rel-16)",7940,"noted","2019-03-04T06:36:15.010","2019-03-04T11:21:26.530",null,null,"Rel-16","33.825","0.3.0","FS_5G_URLLC_SEC"]
["S3-190687","conclusion for key issue 2","Huawei, HiSilicon","Zander (Zhongding) Lei",66556,"pCR","Approval",null,"E//: key issue 1 conclusion will decide what to do for all the other conclusions. Huawei: this is the question. E//: cryptographic separation discussion needs to be resolved. For these key issues not necessary in this meeting. Orange: then more contributions can eb noted. E//: other contributions will also have the same issue. E//: treat next meeting, work offline before.",null,"5.13","Study on security for 5G URLLC (FS_5G URLLC_SEC) (Rel-16)",7950,"noted","2019-03-04T06:36:15.027","2019-03-04T11:21:26.403",null,null,"Rel-16","33.825","0.3.0","FS_5G_URLLC_SEC"]
["S3-190677","conclusion for key issue 3","Huawei, HiSilicon","Zander (Zhongding) Lei",66556,"pCR","Approval",null,"same issue as 687, ",null,"5.13","Study on security for 5G URLLC (FS_5G URLLC_SEC) (Rel-16)",7960,"noted","2019-03-04T06:36:14.810","2019-03-04T11:21:26.483",null,null,"Rel-16","33.825","0.3.0","FS_5G_URLLC_SEC"]
["S3-190794","Conclusion on KI #3 for Study on the security for URLLC","Qualcomm Incorporated","Adrian Escott",24089,"pCR","Approval",null,"same issue as 687, ",null,"5.13","Study on security for 5G URLLC (FS_5G URLLC_SEC) (Rel-16)",7970,"noted","2019-03-04T11:30:16.443","2019-03-04T14:20:18.450",null,null,"Rel-16","33.825","0.3.0","FS_5G_URLLC_SEC"]
["S3-190684","conclusion for key issue 4","Huawei, HiSilicon","Zander (Zhongding) Lei",66556,"pCR","Approval",null,"same issue as 687, ",null,"5.13","Study on security for 5G URLLC (FS_5G URLLC_SEC) (Rel-16)",8180,"noted","2019-03-04T06:36:14.967","2019-03-04T11:21:26.513",null,null,"Rel-16","33.825","0.3.0","FS_5G_URLLC_SEC"]
["S3-190795","Conclusion on KI #4 for Study on the security for URLLC","Qualcomm Incorporated","Adrian Escott",24089,"pCR","Approval",null,"no discussion",null,"5.13","Study on security for 5G URLLC (FS_5G URLLC_SEC) (Rel-16)",8190,"noted","2019-03-04T11:30:16.460","2019-03-04T14:20:18.450",null,null,"Rel-16","33.825","0.3.0","FS_5G_URLLC_SEC"]
["S3-190797","Conclusion on KI #8 for Study on the security for URLLC","Qualcomm Incorporated","Adrian Escott",24089,"pCR","Approval",null,"Huawei: support this contribution. E//: fine with this. Editor's note in key issue. KI needs to be aligned. BT: support this. Difficult to position this, to avoid username and password ",null,"5.13","Study on security for 5G URLLC (FS_5G URLLC_SEC) (Rel-16)",8200,"approved","2019-03-04T11:30:16.507","2019-03-04T14:20:18.463",null,null,"Rel-16","33.825","0.3.0","FS_5G_URLLC_SEC"]
["S3-190757","Considerations on network product class when using NFV technology","China Mobile Com. Corporation","Xiaoting Huang",78337,"pCR","Approval",null,"Taken offline to correct some editorials",null,"5.14","Study on SECAM and SCAS for 3GPP virtualized network products (FS_VNP_SECAM_SCAS) (Rel-16)",7570,"Revised","2019-03-04T10:33:40.283","2019-03-04T12:14:03.817",null,"S3-190951","Rel-16","33.818","0.1.0","FS_VNP_SECAM_SCAS"]
["S3-190951","Considerations on network product class when using NFV technology","China Mobile Com. Corporation","Xiaoting Huang",78337,"pCR","Approval",null,null,null,"5.14","Study on SECAM and SCAS for 3GPP virtualized network products (FS_VNP_SECAM_SCAS) (Rel-16)",7570,"approved",null,null,"S3-190757",null,"Rel-16","33.818","0.1.0","FS_VNP_SECAM_SCAS"]
["S3-190758","Considerations on SECAM of the virtualized network products","China Mobile Com. Corporation","Xiaoting Huang",78337,"pCR","Approval",null,"An EN was added ",null,"5.14","Study on SECAM and SCAS for 3GPP virtualized network products (FS_VNP_SECAM_SCAS) (Rel-16)",7580,"Revised","2019-03-04T10:36:40.217","2019-03-04T12:14:03.783",null,"S3-190952","Rel-16","33.818","0.1.0","FS_VNP_SECAM_SCAS"]
["S3-190952","Considerations on SECAM of the virtualized network products","China Mobile Com. Corporation","Xiaoting Huang",78337,"pCR","Approval",null,null,null,"5.14","Study on SECAM and SCAS for 3GPP virtualized network products (FS_VNP_SECAM_SCAS) (Rel-16)",7580,"approved",null,null,"S3-190758",null,"Rel-16","33.818","0.1.0","FS_VNP_SECAM_SCAS"]
["S3-190950","new draft TR 33.818",null,null,null,"draft TR","Approval",null,null,null,"5.14","Study on SECAM and SCAS for 3GPP virtualized network products (FS_VNP_SECAM_SCAS) (Rel-16)",7585,"approved"]
["S3-190862","Key issue on Alignment of the terms Private network and NPN","Samsung","Rajavelsamy Rajadurai",33521,"pCR",null,null,"Presented and then S3-190882 opened. Orange: OK to change term in TS 33.501. SA3 agreed that the terms private network and non-public network need to be aligned with TS 22.261.",null,"5.15","Study on Security for 5GS Enhanced support of Vertical and LAN Services (FS_Vertical_LAN_SEC) (Rel-16)",7000,"noted","2019-03-04T13:31:07.337","2019-03-04T14:03:46.420",null,null,"Rel-16","33.819","0.2.0","FS_Vertical_LAN_SEC"]
["S3-190700","Discussion on NPN authentication","Huawei, HiSilicon","Zander (Zhongding) Lei",66556,"discussion","Endorsement",null,null,null,"5.15","Study on Security for 5GS Enhanced support of Vertical and LAN Services (FS_Vertical_LAN_SEC) (Rel-16)",7870,"Revised","2019-03-04T06:36:15.323","2019-03-04T11:21:26.467",null,"S3-190962","Rel-16","33.819"]
["S3-190962","Discussion on NPN authentication","Huawei, HiSilicon","Zander (Zhongding) Lei",66556,"discussion","Endorsement",null,"Orange: Did not agree with any of the options. Huawei: Are worried that we are currently going round in circles. Orange: Prefer an option E where nothing is specified. Several other companies support this view. Qualcomm: Concerned that the scope of what we are trying to agree is not clear.",null,"5.15","Study on Security for 5GS Enhanced support of Vertical and LAN Services (FS_Vertical_LAN_SEC) (Rel-16)",7870,"noted","2019-03-04T06:36:15.323","2019-03-04T11:21:26.467","S3-190700",null,"Rel-16","33.819"]
["S3-190990","NPN authentication way forward","Orange","Todor ",null,null,"Approval",null,"Nokia: NPN authentication should be addressed in a new clause in 33.501. Orange: disagree. TI, Gemalto supported Orange proposal. Sony and Samsung support a Nokia proposal. QC suggested adding an extra sentence to say that the existing method could refer to the exisiting methods. Huawei: NPN operators can chose the authentication method they want.  DT: Agree on this but don'y want to specify all deals. TI: There are already authentication methods for private newtorks in TS 33.501.  Samsung: raised some concerns on support of methods in NPN.",null,"5.15","Study on Security for 5GS Enhanced support of Vertical and LAN Services (FS_Vertical_LAN_SEC) (Rel-16)",7870,"Revised",null,null,null,"S3-190999"]
["S3-190999","NPN authentication way forward","Orange","Todor ",null,null,"Approval",null,"QC: support for algorithm in NPN is not automatically inherited Orange: not for isolated deployments - wordsmithing taken offline. Discussion on modification of SA1 requirenet - this wasn't agreed - copy/paste text from Annex B was proposed.",null,"5.15","Study on Security for 5GS Enhanced support of Vertical and LAN Services (FS_Vertical_LAN_SEC) (Rel-16)",7870,"Revised",null,null,"S3-190990","S3-191003"]
["S3-191003","NPN authentication way forward","Orange,  Telecom Italia, Huawei","Todor ",null,null,"Endorsement",null,null,null,"5.15","Study on Security for 5GS Enhanced support of Vertical and LAN Services (FS_Vertical_LAN_SEC) (Rel-16)",7870,"endorsed",null,null,"S3-190999"]
["S3-190787","Proposed solution to the key hierarchy for non-public networks","Qualcomm Incorporated","Adrian Escott",24089,"pCR","Approval",null,null,null,"5.15","Study on Security for 5GS Enhanced support of Vertical and LAN Services (FS_Vertical_LAN_SEC) (Rel-16)",7880,"Revised","2019-03-04T11:30:16.193","2019-03-04T14:19:41.960",null,"S3-190991","Rel-16","33.819","0.2.0","FS_Vertical_LAN_SEC"]
["S3-190991","Proposed solution to the key hierarchy for non-public networks","Qualcomm Incorporated","Adrian Escott",24089,"pCR","Approval",null,null,null,"5.15","Study on Security for 5GS Enhanced support of Vertical and LAN Services (FS_Vertical_LAN_SEC) (Rel-16)",7880,"approved",null,null,"S3-190787",null,"Rel-16","33.819","0.2.0","FS_Vertical_LAN_SEC"]
["S3-190788","Proposed addition to key issue#1.1 for standalone non-public networks","Qualcomm Incorporated","Adrian Escott",24089,"pCR","Approval",null,"DCM: What to turn this into architectural reference by removing security threats and changing title of the clause to architectural. Samsung: Add EN on review after progress in stage 3",null,"5.15","Study on Security for 5GS Enhanced support of Vertical and LAN Services (FS_Vertical_LAN_SEC) (Rel-16)",7890,"Revised","2019-03-04T11:30:16.227","2019-03-04T14:19:41.960",null,"S3-190992","Rel-16","33.819","0.2.0","FS_Vertical_LAN_SEC"]
["S3-190992","Proposed addition to key issue#1.1 for standalone non-public networks","Qualcomm Incorporated","Adrian Escott",24089,"pCR","Approval",null,null,null,"5.15","Study on Security for 5GS Enhanced support of Vertical and LAN Services (FS_Vertical_LAN_SEC) (Rel-16)",7890,"approved",null,null,"S3-190788",null,"Rel-16","33.819","0.2.0","FS_Vertical_LAN_SEC"]
["S3-190789","Adding network binding requirement to the keys issue #1.1 on standalone public networks","Qualcomm Incorporated","Adrian Escott",24089,"pCR","Approval",null,null,null,"5.15","Study on Security for 5GS Enhanced support of Vertical and LAN Services (FS_Vertical_LAN_SEC) (Rel-16)",7900,"Revised","2019-03-04T11:30:16.257","2019-03-04T14:21:29.073",null,"S3-190993","Rel-16","33.819","0.2.0","FS_Vertical_LAN_SEC"]
["S3-190993","Adding network binding requirement to the keys issue #1.1 on standalone public networks","Qualcomm Incorporated","Adrian Escott",24089,"pCR","Approval",null,null,null,"5.15","Study on Security for 5GS Enhanced support of Vertical and LAN Services (FS_Vertical_LAN_SEC) (Rel-16)",7900,"approved",null,null,"S3-190789",null,"Rel-16","33.819","0.2.0","FS_Vertical_LAN_SEC"]
["S3-190790","Proposed solution to key issue #1.1 in TR 33.819","Qualcomm Incorporated","Adrian Escott",24089,"pCR","Approval",null,"Ericsson: Question whether it was addressing both the requirements proposed in S3-190789. Qualcomm: confirmed this.",null,"5.15","Study on Security for 5GS Enhanced support of Vertical and LAN Services (FS_Vertical_LAN_SEC) (Rel-16)",8450,"approved","2019-03-04T11:30:16.270","2019-03-04T14:20:18.497",null,null,"Rel-16","33.819","0.2.0","FS_Vertical_LAN_SEC"]
["S3-190855","KI on credential storage for NPN-Ues","Nokia, Nokia Shanghai Bell","Anja Jerichow",68341,"pCR","Approval",null,"Partially covered by S3-190858",null,"5.15","Study on Security for 5GS Enhanced support of Vertical and LAN Services (FS_Vertical_LAN_SEC) (Rel-16)",8460,"Noted","2019-03-04T13:25:21.693","2019-03-04T14:50:44.117",null,null,"Rel-16","33.819","16.2.0","FS_Vertical_LAN_SEC"]
["S3-190858","Key issue on secure storage of SNPN access credentials","Samsung, Intel","Rajavelsamy Rajadurai",33521,"pCR",null,null,"SA3 agrees to the following: storage of non-3GPP credentials for standalone NPN will not be addressed. This won't stop us from mentioning that they are in the UE.",null,"5.15","Study on Security for 5GS Enhanced support of Vertical and LAN Services (FS_Vertical_LAN_SEC) (Rel-16)",8470,"Noted","2019-03-04T13:25:46.373","2019-03-04T14:03:46.403",null,null,"Rel-16","33.819","0.2.0","FS_Vertical_LAN_SEC"]
["S3-190859","Solution for secure storage of SNPN access credentials","Samsung, Intel","Rajavelsamy Rajadurai",33521,"pCR",null,null,"see 858",null,"5.15","Study on Security for 5GS Enhanced support of Vertical and LAN Services (FS_Vertical_LAN_SEC) (Rel-16)",8480,"Noted","2019-03-04T13:27:33.720","2019-03-04T14:03:46.403",null,null,"Rel-16","33.819","0.2.0","FS_Vertical_LAN_SEC"]
["S3-190860","Key issue on CAG access control in Non-standalone NPNs","Samsung","Rajavelsamy Rajadurai",33521,"pCR",null,null,"DCM: Change minimise into mitigate. Ericsson: Checking on the authorisation of the UE to a PLMN. Orange: Title should be aligned with the details of the keys issue.",null,"5.15","Study on Security for 5GS Enhanced support of Vertical and LAN Services (FS_Vertical_LAN_SEC) (Rel-16)",8490,"Revised","2019-03-04T13:28:50.677","2019-03-04T14:03:46.403",null,"S3-190994","Rel-16","33.819","0.2.0","FS_Vertical_LAN_SEC"]
["S3-190994","Key issue on CAG access control in Non-standalone NPNs","Samsung","Rajavelsamy Rajadurai",33521,"pCR",null,null,null,null,"5.15","Study on Security for 5GS Enhanced support of Vertical and LAN Services (FS_Vertical_LAN_SEC) (Rel-16)",8490,"Approved",null,null,"S3-190860",null,"Rel-16","33.819","0.2.0","FS_Vertical_LAN_SEC"]
["S3-190861","New solution for CAG access control in Non-standalone NPNs","Samsung","Rajavelsamy Rajadurai",33521,"pCR",null,null,"Orange: It is FF whether this mechanism protects against DOS attack. Interdigitial: Have privacy concerns on the sending the CAG identity. An editor's notes on privacy of CAG was added. Title will be aligned with the change to the key issue. ",null,"5.15","Study on Security for 5GS Enhanced support of Vertical and LAN Services (FS_Vertical_LAN_SEC) (Rel-16)",8500,"Revised","2019-03-04T13:29:52.890","2019-03-04T14:03:46.420",null,"S3-190995","Rel-16","33.819","0.2.0","FS_Vertical_LAN_SEC"]
["S3-190995","New solution for CAG access control in Non-standalone NPNs","Samsung","Rajavelsamy Rajadurai",33521,"pCR",null,null,null,null,"5.15","Study on Security for 5GS Enhanced support of Vertical and LAN Services (FS_Vertical_LAN_SEC) (Rel-16)",8500,"Approved",null,null,"S3-190861",null,"Rel-16","33.819","0.2.0","FS_Vertical_LAN_SEC"]
["S3-190845","Discussion on NPN Authentication","Cablelabs, Nokia, Nokia Shanghai Bell","Anja Jerichow",68341,"discussion","Endorsement",null,"Presented as introduction to the following documents",null,"5.15","Study on Security for 5GS Enhanced support of Vertical and LAN Services (FS_Vertical_LAN_SEC) (Rel-16)",8510,"noted","2019-03-04T13:25:21.600","2019-03-04T14:50:44.133",null,null,"Rel-16","33.819",null,"FS_Vertical_LAN_SEC"]
["S3-190856","KI on authentication and authorization of NPN subscribers by a 5G external entity","Nokia, Nokia Shanghai Bell","Anja Jerichow",68341,"pCR","Approval",null,"Chair: Is this related to S3-190990 discussion. Orange: Will object to this document whether it is or not. It was questioned who is the 3rd party is in this case. Nokia: It is interface bewteen the AUSF and AAA. Ericsson: Suport a re-work of the Key issue to tackle the possible location of the AAA. It was taken offline for further work.",null,"5.15","Study on Security for 5GS Enhanced support of Vertical and LAN Services (FS_Vertical_LAN_SEC) (Rel-16)",8520,"Revised","2019-03-04T13:25:21.693","2019-03-04T14:50:44.133",null,"S3-191000","Rel-16","33.819","16.2.0","FS_Vertical_LAN_SEC"]
["S3-191000","KI on authentication and authorization of NPN subscribers by a 5G external entity","Nokia, Nokia Shanghai Bell, Ericsson, Cable Labs","Anja Jerichow",68341,"pCR","Approval",null,null,null,"5.15","Study on Security for 5GS Enhanced support of Vertical and LAN Services (FS_Vertical_LAN_SEC) (Rel-16)",8520,"Approved",null,null,"S3-190856",null,"Rel-16","33.819","16.2.0","FS_Vertical_LAN_SEC"]
["S3-191018","new draft TR 33.819","Nokia","Anja Jerichow",null,"draft TR","Approval",null,"For e-mail approved",null,"5.15","Study on Security for 5GS Enhanced support of Vertical and LAN Services (FS_Vertical_LAN_SEC) (Rel-16)",8520,"not concluded"]
["S3-190846","Deployment options for authentication in NPNs","Cablelabs, Nokia, Nokia Shanghai Bell","Anja Jerichow",68341,"pCR","Approval",null,"Orange: Do not want the accept the contribution. Vdf: OK for inclusion. Sony, Huwaei & Interdigital support the inclusion. Qualcomm: delete the use of MSK. Gemalto: Want to clarify that these are just example of the possible deployments. Orange: What is the difference between the key issue and the Annex. Ericsson: It is possible to refer to the Annex. Orange: Key Issue will refer to the Annex and also wonders why that is helpful. Idemia: Concern about Key Iusse referring to Annex. Ercisson: Include Annex and maybe use some of the content in the Key Issue.",null,"5.15","Study on Security for 5GS Enhanced support of Vertical and LAN Services (FS_Vertical_LAN_SEC) (Rel-16)",8530,"Revised","2019-03-04T13:25:21.633","2019-03-04T14:50:44.133",null,"S3-191001","Rel-16","33.819","16.2.0","FS_Vertical_LAN_SEC"]
["S3-191001","Deployment options for authentication in NPNs","Cablelabs, Nokia, Nokia Shanghai Bell","Anja Jerichow",68341,"pCR","Approval",null,null,null,"5.15","Study on Security for 5GS Enhanced support of Vertical and LAN Services (FS_Vertical_LAN_SEC) (Rel-16)",8530,"Approved",null,null,"S3-190846",null,"Rel-16","33.819","16.2.0","FS_Vertical_LAN_SEC"]
["S3-190847","Evaluation of EAP-TTLS for non-certificate based UE authentication in SNPNs","Cablelabs, Nokia, Nokia Shanghai Bell","Anja Jerichow",68341,"pCR","Approval",null,"Left to treat other docs",null,"5.15","Study on Security for 5GS Enhanced support of Vertical and LAN Services (FS_Vertical_LAN_SEC) (Rel-16)",8540,"not treated","2019-03-04T13:25:21.633","2019-03-04T15:11:51.527",null,null,"Rel-16","33.819","16.2.0","FS_Vertical_LAN_SEC"]
["S3-190848","Solution on non-certificate based UE authentication in 5G NPN with AAA","Cablelabs, Nokia, Nokia Shanghai Bell","Anja Jerichow",68341,"pCR","Approval",null,"Vdf: Like to see an EN to say \"Impact of KH is FFS\" as it is not clear whether there is any impact. Orange would like an EN as the KI is not complete. TI: It should be noted as the Key Issue is not complete, Gemalto and Idemia support TI. Ericsson raised concerns about the Phase 2. ",null,"5.15","Study on Security for 5GS Enhanced support of Vertical and LAN Services (FS_Vertical_LAN_SEC) (Rel-16)",8550,"noted","2019-03-04T13:25:21.633","2019-03-04T14:50:44.147",null,null,"Rel-16","33.819","16.2.0","FS_Vertical_LAN_SEC"]
["S3-190849","Solution on non-certificate based UE authentication in 5G NPN without AAA","Cablelabs, Nokia, Nokia Shanghai Bell","Anja Jerichow",68341,"pCR","Approval",null,"Noted due to incomplete KI",null,"5.15","Study on Security for 5GS Enhanced support of Vertical and LAN Services (FS_Vertical_LAN_SEC) (Rel-16)",8560,"noted","2019-03-04T13:25:21.647","2019-03-04T14:50:44.147",null,null,"Rel-16","33.819","16.2.0","FS_Vertical_LAN_SEC"]
["S3-190850","Discussion of security solutions for SNPN service access via PLMN and vice versa","Nokia, Nokia Shanghai Bell","Anja Jerichow",68341,"discussion","Endorsement",null,null,null,"5.15","Study on Security for 5GS Enhanced support of Vertical and LAN Services (FS_Vertical_LAN_SEC) (Rel-16)",8570,"not treated","2019-03-04T13:25:21.647","2019-03-04T14:50:44.147",null,null,"Rel-16","33.819",null,"FS_Vertical_LAN_SEC"]
["S3-190851","Solution on SNPN service access via PLMN","Nokia, Nokia Shanghai Bell","Anja Jerichow",68341,"pCR","Approval",null,null,null,"5.15","Study on Security for 5GS Enhanced support of Vertical and LAN Services (FS_Vertical_LAN_SEC) (Rel-16)",8580,"not treated","2019-03-04T13:25:21.663","2019-03-04T14:50:44.163",null,null,"Rel-16","33.819","16.2.0","FS_Vertical_LAN_SEC"]
["S3-190852","Solution on PLMN service access via NPN","Nokia, Nokia Shanghai Bell","Anja Jerichow",68341,"pCR","Approval",null,null,null,"5.15","Study on Security for 5GS Enhanced support of Vertical and LAN Services (FS_Vertical_LAN_SEC) (Rel-16)",8590,"not treated","2019-03-04T13:25:21.663","2019-03-04T14:50:44.163",null,null,"Rel-16","33.819","16.2.0","FS_Vertical_LAN_SEC"]
["S3-190853","Discussion on Authentication of UE to PLMN integrated NPN","Nokia, Nokia Shanghai Bell","Anja Jerichow",68341,"discussion","Endorsement",null,null,null,"5.15","Study on Security for 5GS Enhanced support of Vertical and LAN Services (FS_Vertical_LAN_SEC) (Rel-16)",8600,"not treated","2019-03-04T13:25:21.677","2019-03-04T14:50:44.163",null,null,"Rel-16","33.819",null,"FS_Vertical_LAN_SEC"]
["S3-190854","Solution for UE authentication to PLMN integrated NPN","Nokia, Nokia Shanghai Bell","Anja Jerichow",68341,"pCR","Approval",null,null,null,"5.15","Study on Security for 5GS Enhanced support of Vertical and LAN Services (FS_Vertical_LAN_SEC) (Rel-16)",8610,"not treated","2019-03-04T13:25:21.677","2019-03-04T14:50:44.117",null,null,"Rel-16","33.819","16.2.0","FS_Vertical_LAN_SEC"]
["S3-190857","Rapporteur correction to TR 33819","Nokia, Nokia Shanghai Bell","Anja Jerichow",68341,"pCR","Approval",null,"No comments",null,"5.15","Study on Security for 5GS Enhanced support of Vertical and LAN Services (FS_Vertical_LAN_SEC) (Rel-16)",8620,"approved","2019-03-04T13:25:21.710","2019-03-04T14:50:44.133",null,null,"Rel-16","33.819","16.2.0","FS_Vertical_LAN_SEC"]
["S3-190882","Issue of Alignment of the terms Private network and NPN","SAMSUNG","Narendranath Durga Tangudu",73161,"pCR","Approval",null,null,null,"5.15","Study on Security for 5GS Enhanced support of Vertical and LAN Services (FS_Vertical_LAN_SEC) (Rel-16)",8820,"noted","2019-03-07T09:34:16.710","2019-03-07T09:39:16.690",null,null,"Rel-16","33.819","0.2.0","FS_Vertical_LAN_SEC"]
["S3-190768","pCR to 33935 - addition section 4.1 Overview","VODAFONE Group Plc","Tim P. Evans",24416,"pCR","Approval",null,"Orange: Modify to SIM/USIM. Gemalto asked to check the solution number. There is a need to modify 2G/3G/4G as these terms not used in specs.",null,"5.16","Study on LTKUP Detailed solutions (FS_LTKUP_Detail) (Rel-16)",7680,"Revised","2019-03-04T11:07:21.173","2019-03-04T14:34:46.750",null,"S3-190953","Rel-16","33.935","0.1.0","FS_LTKUP_Detail"]
["S3-190953","pCR to 33935 - addition section 4.1 Overview","VODAFONE Group Plc","Tim P. Evans",24416,"pCR","Approval",null,"Approved without beeing seen",null,"5.16","Study on LTKUP Detailed solutions (FS_LTKUP_Detail) (Rel-16)",7680,"approved",null,null,"S3-190768",null,"Rel-16","33.935","0.1.0","FS_LTKUP_Detail"]
["S3-191022","Draft skelton document for TR 33.935","VODAFONE Group Plc","Tim P. Evans",null,"pCR","Approval",null,"Delete the content of the introduction clause",null,"5.16","Study on LTKUP Detailed solutions (FS_LTKUP_Detail) (Rel-16)",7680,"Revised",null,null,null,"S3-191024"]
["S3-191024","Draft skelton document for TR 33.935","VODAFONE Group Plc","Tim P. Evans",null,"pCR","Approval",null,"Approved without being seen",null,"5.16","Study on LTKUP Detailed solutions (FS_LTKUP_Detail) (Rel-16)",7680,"approved",null,null,"S3-191022"]
["S3-190773","pCR to 33935 - addition of detailed solution 4b","VODAFONE Group Plc","Tim P. Evans",24416,"pCR","Approval",null,"Orange: Add reference to SIM OTA - remove the two notes. Some changes 4.2.3 that were agreeable. Vdf: UICC should be changed to USIM.",null,"5.16","Study on LTKUP Detailed solutions (FS_LTKUP_Detail) (Rel-16)",7730,"Revised","2019-03-04T11:09:37.523","2019-03-04T15:01:31.737",null,"S3-190954","Rel-16","33.935","0.1.0","FS_LTKUP_Detail"]
["S3-190954","pCR to 33935 - addition of detailed solution 4b","VODAFONE Group Plc","Tim P. Evans",24416,"pCR","Approval",null,null,null,"5.16","Study on LTKUP Detailed solutions (FS_LTKUP_Detail) (Rel-16)",7730,"approved",null,null,"S3-190773",null,"Rel-16","33.935","0.1.0","FS_LTKUP_Detail"]
["S3-190840","Detailed solution 5 in TR 33.935","Gemalto N.V.","Mireille Pauliac",23516,"pCR","Approval","Addition of detailed solution 5 in 3GPP TR 33.935",null,null,"5.16","Study on LTKUP Detailed solutions (FS_LTKUP_Detail) (Rel-16)",8400,"Revised","2019-03-04T12:23:53.027","2019-03-04T14:48:14.727",null,"S3-190920","Rel-16","33.935","0.0.1","FS_LTKUP_Detail"]
["S3-190920","Detailed solution 5 in TR 33.935","Gemalto N.V.","Mireille Pauliac",23516,"pCR","Approval","Addition of detailed solution 5 in 3GPP TR 33.935","Orange had some small changes to document that were agreeable. The reference to eSIM was removed as it about provisioning. ",null,"5.16","Study on LTKUP Detailed solutions (FS_LTKUP_Detail) (Rel-16)",8400,"Revised",null,null,"S3-190840","S3-190955","Rel-16","33.935","0.0.1","FS_LTKUP_Detail"]
["S3-190955","Detailed solution 5 in TR 33.935","Gemalto N.V.","Mireille Pauliac",23516,"pCR","Approval","Addition of detailed solution 5 in 3GPP TR 33.935",null,null,"5.16","Study on LTKUP Detailed solutions (FS_LTKUP_Detail) (Rel-16)",8400,"approved",null,null,"S3-190920",null,"Rel-16","33.935","0.0.1","FS_LTKUP_Detail"]
["S3-190956","new draft TR 33.935","VODAFONE Group Plc","Tim P. Evans",null,"draft TR","Approval",null,null,null,"5.16","Study on LTKUP Detailed solutions (FS_LTKUP_Detail) (Rel-16)",8400,"approved"]
["S3-190605","Proposal for FS_UP_IP_Sec Key Issue #1.3: User plane integrity between UE and network","Philips International B.V.","John Bernsen",35096,"pCR","Approval","Proposal for zero overhead user plane integrity protection by using cryptographic CRCs in Transport Blocks and Code Blocks. The error behavior of the UE-eNodeB link due to noise is unaffected by this integrity protection.","Nokia: impact is at phy layer. Not reliable ZTE: PDCP is multiplexed into transport block, how is policy in case of multiplexed being taken care of. Huawei: solution is not within the scope of this TR. Should adopt PDCP from 5G. BT: CRC should be for natural errors, can't distinguish between security and transmission errors. VF: add this solution and then point out all of the problems in evaluation. DT: creative solution, should go in. E//: why is integrity not provided at PDCP layer. Philips: this is zero overhead solution. VF: prefer as two tdocs, with key issue. E//: description of key issue is too global. DCM: not put in key issue. put in solution and then put in evalution. VF: put in solution and give evaluation. Huawei: this study was understood that it is only about user plane integrity protection at PDCP layer. IDCC: add key issue of overhead QC: support IDCC and Huawei proposal. QC: need agreement that solution should not have impact on physical layer. NEC: note for now. Lot of support for noting it.",null,"5.17","Study on User Plane Integrity Protection (FS_UP_IP_Sec) (Rel-16)",6050,"noted","2019-02-20T12:37:46.080","2019-02-20T13:35:45.647",null,null,"Rel-16","33.853","0.1.0","FS_UP_IP_Sec"]
["S3-190647","Editorial corrections in TR 33.853 v0.1.0","NEC Europe Ltd","Taka Yoshizawa",40702,"pCR","Approval","Editorial changes to TR 33.853.","VF: ok as rapporteur.",null,"5.17","Study on User Plane Integrity Protection (FS_UP_IP_Sec) (Rel-16)",6470,"approved","2019-03-03T09:00:36.753","2019-03-04T13:35:51.997",null,null,"Rel-16","33.853","0.1.0","FS_UP_IP_Sec"]
["S3-190648","Discussion on the need of UP IP solution for Rel.15 UEs","NEC Europe Ltd, Lenovo, Motorola Mobility, Samsung","Taka Yoshizawa",40702,"discussion","Discussion","This contribution discusses the motivation of a new key issue.",null,null,"5.17","Study on User Plane Integrity Protection (FS_UP_IP_Sec) (Rel-16)",6480,"noted","2019-03-03T09:02:46.113","2019-03-04T13:35:51.857",null,null,"Rel-16","33.853"]
["S3-190649","New key issue on data rate limitation of integrity protection in UP DRB","NEC Europe Ltd, Lenovo, Motorola Mobility, Samsung","Taka Yoshizawa",40702,"pCR","Approval","This contribution introduces a new key issue.","Huawei: only support one solution. If operator decides to turn off, then what can one do. VF: not clear that this is serving network decision, so need to be more clear about operators. NEC: if only 64kbit/sec is possible then how can IP be used. Nokia: if IP is turned off, then what can be done? policy needs to be removed. NEC: remove first requirement. how does the user know that there is IP? VF: service level agreement. NEC: support for second part is there. Huawei: when UE doesn't support full data rate, then do something else. E//: what is the key issue we are trying to solve. QC: if no IP protection is enabled, how can the user be protected. VF: if the home operator promises IP, but the serving network doesn't support it, then how could IP be provided. BT: mismatch between the users preference and policy of network. Samsung: differentiate user and protocol perspective VF: whether worth it depends on user expectation. E//: solution targeting R15 UEs, but target solutions that defend if IP is not supported. need to be clarified.  ",null,"5.17","Study on User Plane Integrity Protection (FS_UP_IP_Sec) (Rel-16)",6490,"Revised","2019-03-03T09:04:50.933","2019-03-04T13:35:51.873",null,"S3-190911","Rel-16","33.853","0.1.0","FS_UP_IP_Sec"]
["S3-190911","New key issue on data rate limitation of integrity protection in UP DRB","NEC Europe Ltd, Lenovo, Motorola Mobility, Samsung","Rajvel ",40702,"pCR","Approval","This contribution introduces a new key issue.","Modify requirement to refer to security threat clause ",null,"5.17","Study on User Plane Integrity Protection (FS_UP_IP_Sec) (Rel-16)",6490,"Revised",null,null,"S3-190649","S3-191004","Rel-16","33.853","0.1.0","FS_UP_IP_Sec"]
["S3-191004","New key issue on data rate limitation of integrity protection in UP DRB","NEC Europe Ltd, Lenovo, Motorola Mobility, Samsung","Rajvel ",40702,"pCR","Approval","This contribution introduces a new key issue.",null,null,"5.17","Study on User Plane Integrity Protection (FS_UP_IP_Sec) (Rel-16)",6490,"approved",null,null,"S3-190911","S3-191019","Rel-16","33.853","0.1.0","FS_UP_IP_Sec"]
["S3-190650","New solution for data rate limitation of integrity protection in UP DRB","NEC Europe Ltd, Lenovo, Motorola Mobility","Taka Yoshizawa",40702,"pCR","Approval","This contribution introduces a new solution.","Ericsson: concerned that it does not address discussed key issue. NEC: aims for Rel-15 UEs. DT: not keen on such solution but if pursued keep as simple as possible and always protect header. Huawei: Maybe a moving window would be better and concern that this needs to be more studied and maybe fooling ourselves that there is integrity protection. QC: think if integrity protection is done, it should be done on full packet. ZTE: Not keen on approach.",null,"5.17","Study on User Plane Integrity Protection (FS_UP_IP_Sec) (Rel-16)",6500,"noted","2019-03-03T09:06:53.847","2019-03-04T13:35:51.873",null,null,"Rel-16","33.853","0.1.0","FS_UP_IP_Sec"]
["S3-190651","New solution for data rate limitation of integrity protection in UP DRB","NEC Europe Ltd","Taka Yoshizawa",40702,"pCR","Approval","This contribution introduces a new solution.","Ericsson: This a new cryptographic algorithm and we are not doing that in SA3. Huawei: Also concern that this is a new approach to calculating a MAC and needs more justification.",null,"5.17","Study on User Plane Integrity Protection (FS_UP_IP_Sec) (Rel-16)",6510,"noted","2019-03-03T09:09:40.617","2019-03-04T13:35:51.873",null,null,"Rel-16","33.853","0.1.0","FS_UP_IP_Sec"]
["S3-190652","New key issue on integrity protection capability imbalance in MR-DC scenarios","NEC Europe Ltd","Taka Yoshizawa",40702,"pCR","Approval","This contribution introduces a new key issue.","This was discussed along with S3-190707 and S3-190708. Authors of the various documents agree that it would be possible to merge the docs provided there are requirement for individual options. Huawei: Concern on some of the details of S3-190652. Ericsson think there is no need for the key issue as the issue is whether a ng-eNB supports UP IP. Vdf think that we just need keys issues on the UE being able to support UP IP at full rate. NEC think there are solutions that do not require ng-eNB to support integrity protection. Vdf: The KIs in the current TR are about secure negotiation and activation of the UP IP in EPS. QC proposes that the contributions are merged into one key issue. This work will happen in some offline manner.",null,"5.17","Study on User Plane Integrity Protection (FS_UP_IP_Sec) (Rel-16)",6520,"Revised","2019-03-03T09:12:13.767","2019-03-04T13:35:51.887",null,"S3-190912","Rel-16","33.853","0.1.0","FS_UP_IP_Sec"]
["S3-190912","New key issue on integrity protection capability imbalance in MR-DC scenarios","NEC Europe Ltd","Taka Yoshizawa",40702,"pCR","Approval","This contribution introduces a new key issue.","DCM: ng-eNB is already like a solution.",null,"5.17","Study on User Plane Integrity Protection (FS_UP_IP_Sec) (Rel-16)",6520,"Revised",null,null,"S3-190652","S3-191019","Rel-16","33.853","0.1.0","FS_UP_IP_Sec"]
["S3-191019","New key issue on integrity protection capability imbalance in MR-DC scenarios","NEC Europe Ltd","Taka Yoshizawa",40702,"pCR","Approval","This contribution introduces a new key issue.",null,null,"5.17","Study on User Plane Integrity Protection (FS_UP_IP_Sec) (Rel-16)",6520,"approved",null,null,"S3-190912",null,"Rel-16","33.853","0.1.0","FS_UP_IP_Sec"]
["S3-190653","New solution for integrity protection capability imbalance in MR-DC scenarios","NEC Europe Ltd","Taka Yoshizawa",40702,"pCR","Approval","This contribution introduces a new solution.","Relates to the open key issue resulting from S3-190652. Huawei did not want UP terminating somewhere other than eNB. Vdf propose that the solution is added and the issue are documented. QC raised concern about no IP layer in eNB and non-IP traffic.",null,"5.17","Study on User Plane Integrity Protection (FS_UP_IP_Sec) (Rel-16)",6530,"noted","2019-03-03T09:13:51.970","2019-03-04T13:35:51.887",null,null,"Rel-16","33.853","0.1.0","FS_UP_IP_Sec"]
["S3-190707","Support UP_IP in option 7","Huawei, Hisilicon","Longhua Guo",80179,"pCR","Approval",null,"See discussion on S3-190652. Merged into S3-190912.",null,"5.17","Study on User Plane Integrity Protection (FS_UP_IP_Sec) (Rel-16)",7070,"merged","2019-03-04T08:08:51.453","2019-03-04T12:30:02.537",null,null,"Rel-16","33.853","0.1.0","FS_UP_IP_Sec"]
["S3-190708","UP IP for Option 4","Huawei, Hisilicon","Longhua Guo",80179,"pCR","Approval",null,"See discussion on S3-190652. Merged into S3-190912.",null,"5.17","Study on User Plane Integrity Protection (FS_UP_IP_Sec) (Rel-16)",7080,"merged","2019-03-04T08:08:51.530","2019-03-04T12:30:02.553",null,null,"Rel-16","33.853","0.1.0","FS_UP_IP_Sec"]
["S3-190802","pCR: New KI: Integrity Algorithm independence","Qualcomm Incorporated","Adrian Escott",24089,"pCR","Approval",null,"Vdf wanted clarification that new algorithms should also be considered. DCM: It should only be 4G and 5G algorithms. Orange: Does this apply for optional algorithms as well. QC: Yes as it needs to apply to all algorithms. Ericsson: Does not feel that this key but more of an evaluation criteria. QC: important it applies to all algorithms as UE will report its lowest data rate among all of its supported algorithms. ",null,"5.17","Study on User Plane Integrity Protection (FS_UP_IP_Sec) (Rel-16)",8020,"Revised","2019-03-04T11:30:16.757","2019-03-04T14:20:18.480","S3-190388","S3-190913","Rel-16","33.853","0.1.0","FS_UP_IP_Sec"]
["S3-190913","pCR: New KI: Integrity Algorithm independence","Qualcomm Incorporated","Anand",24089,"pCR","Approval",null,"On further discussion, other companies had concerns and doc ument is noted.",null,"5.17","Study on User Plane Integrity Protection (FS_UP_IP_Sec) (Rel-16)",8020,"noted",null,null,"S3-190802",null,"Rel-16","33.853","0.1.0","FS_UP_IP_Sec"]
["S3-190803","pCR: New KI: Ability to prioritize certain PDCP packets on the UE uplink","Qualcomm Incorporated","Adrian Escott",24089,"pCR","Approval",null,"Vdf: Would like to qualify that the requirement shall not break the UP IP. This was agreeable. Nokia: Concern about latency. Huawei: Think that this a RAN issue rather than a security issue. Ericsson: Also think that this not a security requirement. DT and Vdf support having a KI on this. Ericsson: Do not believe that this group can look at these layers. Samsung think that this is RAN issue. DCM believe that there is a security issue. Vdf had a proposal to reverse the way the requirement was written.  ",null,"5.17","Study on User Plane Integrity Protection (FS_UP_IP_Sec) (Rel-16)",8030,"Revised","2019-03-04T11:30:16.817","2019-03-04T14:20:18.497","S3-190387","S3-190914","Rel-16","33.853","0.1.0","FS_UP_IP_Sec"]
["S3-190914","pCR: New KI: Ability to prioritize certain PDCP packets on the UE uplink","Qualcomm Incorporated","Anand",24089,"pCR","Approval",null,null,null,"5.17","Study on User Plane Integrity Protection (FS_UP_IP_Sec) (Rel-16)",8030,"approved",null,null,"S3-190803",null,"Rel-16","33.853","0.1.0","FS_UP_IP_Sec"]
["S3-190804","pCR: New KI: Efficient handling of PDCP discardTimer expiry on the UE Uplink","Qualcomm Incorporated","Adrian Escott",24089,"pCR","Approval",null,"Huawei: Do not believe that this a security issue. Ericsson: Agree that this is not a security issue. QC: Issue of re-use of PDCP counter for multiple uses. DT: Believe that there is a security issue and we shoud start the work in SA3. Intel think that there should be an LS to RAN2 from this meeting. Samsung agree with Intel's proposal. QC are OK to involve in RAN2. Vdf: There is a security issue as there are not full rate UEs. Huawei proposal to merge the key issues in S3-910803 and S3-190804 in one Key Issue that relates to supporting UP IP at full rate. In parallel, there should be an LS to RAN2 to get feedback on the issues that limit the suport of full rate UP IP. Apple: Proposal to add key issue details later, but OK to keep requirement. The Key issue details will contains that there was an issue raised by RAN2 and not the specific details.",null,"5.17","Study on User Plane Integrity Protection (FS_UP_IP_Sec) (Rel-16)",8040,"merged","2019-03-04T11:30:16.880","2019-03-04T14:20:18.497","S3-190386",null,"Rel-16","33.853","0.1.0","FS_UP_IP_Sec"]
["S3-190915","LS on Full date rate support for UP IP ","Qualcomm Incorporated",null,null,"LS out","Approval",null,"DCM: requirements strange wording Huawei: delete supported, remove two bullets.E//: support Huawei DCM: remove bullets, ask RAN2 for technical details for R15 decision. QC: ok, some other rewording.Huawei: remove references in question 1 to above.",null,"5.17","Study on User Plane Integrity Protection (FS_UP_IP_Sec) (Rel-16)",8040,"Revised",null,null,"Huawei: not include the details that were raised by QC. DCM: request from RAN2 why the limitation was in R15","S3-191020",null,null,null,null,null,null,null,null,null,"RAN2","RAN3, RAN1, RAN"]
["S3-191020","LS on Full date rate support for UP IP ","Qualcomm Incorporated",null,null,"LS out","Approval",null,null,null,"5.17","Study on User Plane Integrity Protection (FS_UP_IP_Sec) (Rel-16)",8040,"approved",null,null,"S3-190915",null,null,null,null,null,null,null,null,null,null,"RAN2","RAN3, RAN1, RAN"]
["S3-190880","(FS_UP_IP_Sec) Integrity protection of the User Plane -New key Issue - Reporting Integrity check failures to the network","BT plc","Colin Blanchard",71421,"discussion","Decision","It is proposed to add a key issue to TR33.853 [3] concerning operation  1) during normal handover between eNB’s and 2) when redundant transmission in the user plane is used to support Ultra Reliable Low Latency Communication   URLLC\nAnd add the following","Vdf: Editorial formatting is not good. DT: Not sure about this when it was first discssued and it is not clear what the operator would do with the information. QC: do not support the requirement. Samsung: support including this key issue. Huawei: Support the keys issue. Ericsson and Nokia: Don't think that this is in scope of the work of this study item. SA3 think that this a topic that should be studied, but the correct place to study this is FFS. ",null,"5.17","Study on User Plane Integrity Protection (FS_UP_IP_Sec) (Rel-16)",8800,"noted","2019-03-04T14:51:25.927","2019-03-04T15:24:20.717",null,null,null,"33.853"]
["S3-190910","draft TR33.853","VODAFONE Group Plc","Tim P. Evans",null,"draft TR","Approval",null,null,null,"5.17","Study on User Plane Integrity Protection (FS_UP_IP_Sec) (Rel-16)",8800,"approved"]
["S3-190610","Initialisation of Sensitive Functions in a Virtualised Environment","ETSI TC CYBER","Mirko Cano Soveri",41957,"LS in",null,null,null,null,"5.18","Study on Security Impacts of Virtualisation (FS_SIV) (Rel-16)",6100,"noted","2019-02-25T01:57:45.473","2019-02-25T02:09:04.790"]
["S3-190809","Skeleton for TR 33.846","Ericsson","Noamen Ben Henda",63310,"pCR","Approval",null,"no comments",null,"5.19","Study on authentication enhancements in 5GS (FS_AUTH_ENH) (Rel-16)",6210,"approved","2019-03-04T11:52:13.977","2019-03-04T14:01:11.430",null,null,"Rel-16","33.846","0.0.0","FS_AUTH_ENH"]
["S3-190810","Scope for TR 33.846","Ericsson","Noamen Ben Henda",63310,"pCR","Approval",null,null,null,"5.19","Study on authentication enhancements in 5GS (FS_AUTH_ENH) (Rel-16)",6220,"approved","2019-03-04T11:52:14.007","2019-03-04T14:01:11.430",null,null,"Rel-16","33.846","0.0.0","FS_AUTH_ENH"]
["S3-190760","Key issue to ensure the security of session anchor keys","China Mobile Com. Corporation","Xiaoting Huang",78337,"pCR",null,null,"together with 690",null,"5.19","Study on authentication enhancements in 5GS (FS_AUTH_ENH) (Rel-16)",6230,"noted","2019-03-04T10:42:03.303","2019-03-04T12:14:03.817",null,null,"Rel-16","33.846","0.0.0","FS_AUTH_ENH"]
["S3-190690","A key issue on the long-term key and its related anchor key leakage","Huawei, HiSilicon","Zander (Zhongding) Lei",66556,"pCR","Approval",null,"together with 811",null,"5.19","Study on authentication enhancements in 5GS (FS_AUTH_ENH) (Rel-16)",6240,"noted","2019-03-04T06:36:15.090","2019-03-04T11:21:26.420",null,null,"Rel-16","33.846","0.1.0","FS_AUTH_ENH"]
["S3-190811","New KI: Leakage of long-term key","Ericsson","Noamen Ben Henda",63310,"pCR","Approval",null,"VF: what is the relation to LTKUP, BT: this is about mitigation, the other is about prevention, seems to be duplicating the response mechanism. E//: unrelated to LTKUP, this is about perfect forward secrecy. E//: solutions also include active attacks, E// only wants to address passive attacks. VF: this was already discussed in several studies. Orange: agree with VF. BT: solution out of this would be to stop a man in the middle. VF: already in solution 4b and 6 out of LTKUP. E//: we had the discussion before. Todor: between agreeing the study item and now, the 9 series TR was discussed. Telenor: assumption of key comrpomise during production should be out of scope. Orange: this should eventually become a focussed study to update 9 series TR from LTKUP. NEC: agree that assumption of root key compromise is tenacious, but this is about PFS. ",null,"5.19","Study on authentication enhancements in 5GS (FS_AUTH_ENH) (Rel-16)",6250,"noted","2019-03-04T11:52:14.023","2019-03-04T14:01:11.447",null,null,"Rel-16","33.846","0.0.0","FS_AUTH_ENH"]
["S3-190759","Key issue regarding the minimal computational cost when generating session anchor keys","China Mobile Com. Corporation","Xiaoting Huang",78337,"pCR",null,null,"Orange: how was the evaluation done that the current state is not optimal. IDCC: it is not implied that current auth schemes are not effective or efficient. Orange: why is the current authentication from computational perspective not optimal? VF: similar to 256 discussion, difficult to quantify performance, agree with spirit of contribution, but not possible to evaluate against. BT: in IoT space, many and competing performance requirements. Lowest common denominatoris only password? NEC: similar to discussion on KDF. Huawei: different, this is on efficiency. IDCC: \"may\" not fulfil?",null,"5.19","Study on authentication enhancements in 5GS (FS_AUTH_ENH) (Rel-16)",6260,"noted","2019-03-04T10:39:40.760","2019-03-04T12:14:03.800",null,null,"Rel-16","33.846","0.0.0","FS_AUTH_ENH"]
["S3-190626","eAUTH-Linkability KI exposure of cause value","ZTE Corporation","Zhenhua Xie",38520,"pCR","Approval",null,"together with 735",null,"5.19","Study on authentication enhancements in 5GS (FS_AUTH_ENH) (Rel-16)",6270,"merged","2019-03-02T01:47:49.340","2019-03-04T10:10:54.390",null,"S3-190909","Rel-16","33.846","0.3.0","FS_AUTH_ENH"]
["S3-190735","Key issue on linkability attack","Huawei, Hisilicon","Bo Zhang",49401,"pCR","Approval",null,"together with 762",null,"5.19","Study on authentication enhancements in 5GS (FS_AUTH_ENH) (Rel-16)",6280,"merged","2019-03-04T09:32:21.507","2019-03-04T10:21:44.833",null,"S3-190909","Rel-16","33.846","0.0.0","FS_AUTH_ENH"]
["S3-190762","Key issue to resist the linkability attacks","China Mobile Com. Corporation","Xiaoting Huang",78337,"pCR",null,null,"VF: this is only in case of rare auth failures. DCM: fake base station replaying a auth vector. NEC: UE will not camp on cell after two auth failures. Huawei: this allows a DoS. E//: only barred for 5min. ZTE: attacker can change cell ID. VF: should be in FBS study. Huawei: this attack needs to be studied because it is a published attack. VF: support this in this study, but close FBS? E//: referencing the wrong paper. Adrian: needs to be documented here or in FBS. Proposal to merge and then decide to put into FBS or eAUTH TR. NCSC: avoid saying \"the linkability attack\".  E//: leave requirements blank for now.",null,"5.19","Study on authentication enhancements in 5GS (FS_AUTH_ENH) (Rel-16)",6290,"Revised","2019-03-04T10:45:45.780","2019-03-04T12:14:03.817",null,"S3-190909","Rel-16","33.846","0.0.0","FS_AUTH_ENH"]
["S3-190909","Key issue to resist the linkability attacks","China Mobile Com. Corporation","Xiaoting Huang",78337,"pCR",null,null,null,null,"5.19","Study on authentication enhancements in 5GS (FS_AUTH_ENH) (Rel-16)",6290,"approved",null,null,"S3-190762",null,"Rel-16","33.846","0.0.0","FS_AUTH_ENH"]
["S3-190628","eAUTH-Linkability KI SQN exposure","ZTE Corporation","Zhenhua Xie",38520,"pCR","Approval",null,"QC: keep it open for now, until CR by QC has been decided, then add if not agreed in May meeting. ZTE: this is different key issue. Gemalto: support QC proposal. NEC: also. BT: support, need a list of known attacks. VF: Normal network operator procedures of SQN buckets could be used to prevent this attack. Merge first requirement into 909, second requirement will be reconsidered after the May meeting discussions.  ",null,"5.19","Study on authentication enhancements in 5GS (FS_AUTH_ENH) (Rel-16)",6330,"merged","2019-03-02T01:47:49.357","2019-03-04T10:10:54.390",null,"S3-190909","Rel-16","33.846","0.3.0","FS_AUTH_ENH"]
["S3-190627","eAUTH-Linkability KI different length of response","ZTE Corporation","Zhenhua Xie",38520,"pCR","Approval",null,"QC: the message needs to be protected, not the length. ZTE: even if encrapted, teh length will leak which type it is. QC: key issue is assuming that there is a specific solution. IDCC: replace length of response by indistinguishable responses. Orange, VF: support IDCC phrasing NCSC: if this is not about length, then it fits in with 909. Merge to 909",null,"5.19","Study on authentication enhancements in 5GS (FS_AUTH_ENH) (Rel-16)",6340,"merged","2019-03-02T01:47:49.357","2019-03-04T10:10:54.390",null,"S3-190909","Rel-16","33.846","0.3.0","FS_AUTH_ENH"]
["S3-190621","eAUTH-SUCI KI Computing resource consuming","ZTE Corporation","Zhenhua Xie",38520,"pCR","Approval",null,"VF: should be \"a\" privacy mechanism, not \"the\", can already be done, nothing new required. IDCC: key is not to asymmetric algorithm. VF: are we really worried about DoS attack on computation resource because we have virtual scalable servers. BT: ECC was chosen to avoid performance issues IDCC: right choice, but in case of DDoS attack, there is a problem. support the issue, but not the focus on asymmetric. E//: because UE is limited, and needs to do more work than UDM. TIM: new issue jsut came up after 6 month - is this to legitimate a new option? NEC: not do this. QC also. DT: also. ",null,"5.19","Study on authentication enhancements in 5GS (FS_AUTH_ENH) (Rel-16)",6580,"noted","2019-03-02T01:47:49.310","2019-03-04T10:10:54.357",null,null,"Rel-16","33.846","0.3.0","FS_AUTH_ENH"]
["S3-190761","Key issue to mitigate the DDoS attacks on the UDM","China Mobile Com. Corporation","Xiaoting Huang",78337,"pCR",null,null,"NCSC: same as previous contribution, same applies? VF: same, or worse, this doesnt even say where the DDoS is coming from.",null,"5.19","Study on authentication enhancements in 5GS (FS_AUTH_ENH) (Rel-16)",6590,"noted","2019-03-04T10:43:53.783","2019-03-04T12:14:03.800",null,null,"Rel-16","33.846","0.0.0","FS_AUTH_ENH"]
["S3-190622","eAUTH-SUCI KI congestion","ZTE Corporation","Zhenhua Xie",38520,"pCR","Approval",null,"VF: in case of proprietary mechanism, UDM is scoped accordingly. BT: this was already agreed with CT, so not an issue. NEC: how can a UE produce false output? E//: already dealt with in 33.501 by rejection of long SUCIs. ",null,"5.19","Study on authentication enhancements in 5GS (FS_AUTH_ENH) (Rel-16)",6900,"noted","2019-03-02T01:47:49.310","2019-03-04T10:10:54.357",null,null,"Rel-16","33.846","0.3.0","FS_AUTH_ENH"]
["S3-190623","eAUTH-SUCI KI quantum computing","ZTE Corporation","Zhenhua Xie",38520,"pCR","Approval",null,"VF: there is indication which mechanism is being used. NCSC: only relevant in 20years time. IDCC: extend to whole scope of authentication, not only SUCI concealment. Orange: quantum study already gave timeline.  Juniper: agree. QC: agree. Noted",null,"5.19","Study on authentication enhancements in 5GS (FS_AUTH_ENH) (Rel-16)",6910,"noted","2019-03-02T01:47:49.323","2019-03-04T10:10:54.357",null,null,"Rel-16","33.846","0.3.0","FS_AUTH_ENH"]
["S3-190633","New KI on Fast re-authentication procedure for 5GS","NEC Europe Ltd, Intel","Taka Yoshizawa",40702,"pCR","Approval","This pCR proposes a key issue for study item on security for authentication enhancements in 5GS (TR 33.846).","ZTE: not covered by scope of SID. NEC: because DoS is in scope, so it should be in scope: QC: not in scope, E//: not in scope, BT: support this contribution. QC: because of horizontal and vertical key handover, auth is rare, currently not a problem. NEC: for as long as staying in the same access, then few authentications, not when changing access. Huawei: with virtualization, you can throw more resources at it. NEC: this is AuC. BT: should be in URLLC work item. ZTE: note it. Normal authentication can be used.",null,"5.19","Study on authentication enhancements in 5GS (FS_AUTH_ENH) (Rel-16)",7350,"noted","2019-03-03T08:18:00.007","2019-03-04T13:35:51.920",null,null,"Rel-16","33.846","0.0.0","FS_AUTH_ENH"]
["S3-190813","Update on EAP-AKA´ PFS","Ericsson","Noamen Ben Henda",63310,"pCR","Approval",null,"Nokia: what is status of IETF discussion? E//: ongoing email discussion.",null,"5.19","Study on authentication enhancements in 5GS (FS_AUTH_ENH) (Rel-16)",7360,"noted","2019-03-04T11:52:14.067","2019-03-04T14:01:11.447",null,null,"Rel-16","33.846","0.0.0","FS_AUTH_ENH"]
["S3-190812","New solution: EAP-AKA´ PFS","Ericsson","Noamen Ben Henda",63310,"pCR","Approval",null,null,null,"5.19","Study on authentication enhancements in 5GS (FS_AUTH_ENH) (Rel-16)",7590,"noted","2019-03-04T11:52:14.037","2019-03-04T14:01:11.447",null,null,"Rel-16","33.846","0.0.0","FS_AUTH_ENH"]
["S3-190841","33.846: solution for anchor keys security","Gemalto N.V.","Mireille Pauliac",23516,"pCR","Approval","Solution for anchor keys security in 3GPP TR 33.846","no key issue for this",null,"5.19","Study on authentication enhancements in 5GS (FS_AUTH_ENH) (Rel-16)",7600,"noted","2019-03-04T12:33:10.710","2019-03-04T14:57:33.220",null,null,"Rel-16","33.846","0.0.1","FS_AUTH_ENH"]
["S3-190658","Discussion paper on UE initiated EAP AKA' with PFS","Nokia","Suresh Nair",70166,"discussion","Endorsement",null,"no key issue for this",null,"5.19","Study on authentication enhancements in 5GS (FS_AUTH_ENH) (Rel-16)",7610,"noted","2019-03-03T21:24:51.357","2019-03-04T14:15:53.430"]
["S3-190659","UE Initiated EAP AKA' PFS solution","Nokia","Suresh Nair",70166,"other","Approval","This contribution proposes a UE initiated option for EAP AKA with PFS","no key issue for this",null,"5.19","Study on authentication enhancements in 5GS (FS_AUTH_ENH) (Rel-16)",7620,"noted","2019-03-03T21:37:05.683","2019-03-04T14:15:53.430",null,null,null,"33.846",null,"FS_AUTH_ENH"]
["S3-190691","Solution Proposal based on DH between UE and AUSF","Huawei, HiSilicon","Zander (Zhongding) Lei",66556,"pCR","Approval",null,"NCSC: no DH for SUPI protection, but ECDH. No key issue, noted",null,"5.19","Study on authentication enhancements in 5GS (FS_AUTH_ENH) (Rel-16)",7630,"noted","2019-03-04T06:36:15.120","2019-03-04T11:21:26.420",null,null,"Rel-16","33.846","0.1.0","FS_AUTH_ENH"]
["S3-190763","Security enhancement for the key KSEAF based on the symmetric algorithm","China Mobile Com. Corporation","Xiaoting Huang",78337,"pCR",null,null,"VF: long term key can be updated anyways in IoT. No key issue",null,"5.19","Study on authentication enhancements in 5GS (FS_AUTH_ENH) (Rel-16)",7640,"noted","2019-03-04T10:47:33.237","2019-03-04T12:14:03.817",null,null,"Rel-16","33.846","0.0.0","FS_AUTH_ENH"]
["S3-190764","KSEAF enhancement for the EAP-AKA’ protocol","China Mobile Com. Corporation","Xiaoting Huang",78337,"pCR",null,null,"VF: same as before",null,"5.19","Study on authentication enhancements in 5GS (FS_AUTH_ENH) (Rel-16)",7650,"noted","2019-03-04T10:52:24.900","2019-03-04T12:14:03.830",null,null,"Rel-16","33.846","0.0.0","FS_AUTH_ENH"]
["S3-190839","New solution: Deriving session anchor keys with random number","ZTE Corporation, Nubia","Jin PENG",49548,"pCR","Approval",null,"no key issue for this",null,"5.19","Study on authentication enhancements in 5GS (FS_AUTH_ENH) (Rel-16)",7660,"noted","2019-03-04T12:18:46.293","2019-03-04T12:28:24.053",null,null,"Rel-16","33.846","0.0.0","FS_AUTH_ENH"]
["S3-190765","ECIES based security enhancement for the key KSEAF","China Mobile Com. Corporation","Xiaoting Huang",78337,"pCR",null,null,"no key issue for this",null,"5.19","Study on authentication enhancements in 5GS (FS_AUTH_ENH) (Rel-16)",8090,"noted","2019-03-04T10:55:57.113","2019-03-04T12:14:03.830",null,null,"Rel-16","33.846","0.0.0","FS_AUTH_ENH"]
["S3-190766","KSEAF enhancement for 5G AKA protocol","China Mobile Com. Corporation","Xiaoting Huang",78337,"pCR",null,null,"no key issue for this",null,"5.19","Study on authentication enhancements in 5GS (FS_AUTH_ENH) (Rel-16)",8100,"noted","2019-03-04T11:01:40.570","2019-03-04T12:14:03.830",null,null,"Rel-16","33.846","0.0.0","FS_AUTH_ENH"]
["S3-190629","eAUTH-Linkability solution encrypted session anchor key based solution","ZTE Corporation","Zhenhua Xie",38520,"pCR","Approval",null,"related to 909 discussion E//: related to linkability, VF: is this backwards compatible ZTE: yes - closed temporaily until requirement was approved. QC: step 7 - how does the AMF verify the response. ZTE: Provide a response. NEC: Using keys for an authentication is a fundamental change. QC: this is no longer AKA. Nokia: Man in the middle attack seems to be still possible. ",null,"5.19","Study on authentication enhancements in 5GS (FS_AUTH_ENH) (Rel-16)",8110,"noted","2019-03-02T01:47:49.370","2019-03-04T10:10:54.407",null,null,"Rel-16","33.846","0.3.0","FS_AUTH_ENH"]
["S3-190736","New solution for linkability attack","Huawei, Hisilicon","Bo Zhang",49401,"pCR","Approval",null,"related to 90 discussion. QC: how does it work for NULL scheme. DCM: if no SUPI privacy, then the UE gives SUPI. Ericsson: Only seems to work for initial authentication - add an EN/text to show its works for re-authentication. QC: add EN on how this works with a Rel-15 USIM. Orange: SIDF has the private key and is the enity tha can decrypt the response. NEC: Add an EN on Impacts on UDM is FFS. QC: Unclear how the UDM know which UE is failing its authentication. Huawei: Needs some keep alive. Nokia: The solution need mor expansion as there are so many questions. ",null,"5.19","Study on authentication enhancements in 5GS (FS_AUTH_ENH) (Rel-16)",8120,"noted","2019-03-04T09:32:21.507","2019-03-04T10:21:44.833",null,null,"Rel-16","33.846","0.0.0","FS_AUTH_ENH"]
["S3-190625","eAUTH-SUCI solution mitigation of large SUCI attack","ZTE Corporation","Zhenhua Xie",38520,"pCR","Approval",null,"no key issue for this",null,"5.19","Study on authentication enhancements in 5GS (FS_AUTH_ENH) (Rel-16)",8130,"noted","2019-03-02T01:47:49.340","2019-03-04T10:10:54.373",null,null,"Rel-16","33.846","0.3.0","FS_AUTH_ENH"]
["S3-190624","eAUTH-SUCI solution adding symmetric algorithm for SUPI protection scheme","ZTE Corporation","Zhenhua Xie",38520,"pCR","Approval",null,"no key issue for this VF: secret key shall not leave the USIM, otherwise makes no sense. Exactly as specified in 33.501. secret key shared across a batch of USIMs.",null,"5.19","Study on authentication enhancements in 5GS (FS_AUTH_ENH) (Rel-16)",8390,"noted","2019-03-02T01:47:49.323","2019-03-04T10:10:54.373",null,null,"Rel-16","33.846","0.3.0","FS_AUTH_ENH"]
["S3-190634","Solution to support Fast Re-authentication in 5GS","NEC Europe Ltd, Intel","Taka Yoshizawa",40702,"pCR","Approval","This pCR proposes a solution to support fast re-authentication to study item on authentication enhancements in 5GS (TR 33.846).","no key issue for this",null,"5.19","Study on authentication enhancements in 5GS (FS_AUTH_ENH) (Rel-16)",8410,"noted","2019-03-03T08:21:56.757","2019-03-04T13:35:51.920",null,null,"Rel-16","33.846","0.0.0","FS_AUTH_ENH"]
["S3-190908","Draft TR 33.846 enhanced authentication","Ericsson","Noamen Ben Henda",null,"draft TR","approval",null,null,null,"5.19","Study on authentication enhancements in 5GS (FS_AUTH_ENH) (Rel-16)",8410,"approved"]
["S3-190863","Draft TR 33.xxx - Skeleton TR on Security for NR Integrated Access and Backhaul","Samsung","Rajavelsamy Rajadurai",33521,"other",null,null,"No comments",null,"5.20","Study on Security for NR Integrated Access and Backhaul (FS_NR_IAB_Sec)",8630,"approved","2019-03-04T13:34:38.333","2019-03-04T14:03:46.437"]
["S3-190864","Scope for the study on security for NR Integrated Access and Backhaul","Samsung","Rajavelsamy Rajadurai",33521,"other",null,null,"First bullet needs to be revised to meet drafting requirements.",null,"5.20","Study on Security for NR Integrated Access and Backhaul (FS_NR_IAB_Sec)",8640,"Revised","2019-03-04T13:35:43.213","2019-03-04T14:03:46.437",null,"S3-190916"]
["S3-190916","Scope for the study on security for NR Integrated Access and Backhaul","Samsung","Rajavelsamy Rajadurai",33521,"other",null,null,null,null,"5.20","Study on Security for NR Integrated Access and Backhaul (FS_NR_IAB_Sec)",8640,"approved",null,null,"S3-190864"]
["S3-190917","new draft TR 33.XYZ","Samsung",null,null,"draft TR","Approval",null,null,null,"5.20","Study on Security for NR Integrated Access and Backhaul (FS_NR_IAB_Sec)",8640,"approved"]
["S3-190601","New Key Issue for eV2X TR - privacy protection for unicast messages","InterDigital, Inc.","Alec Brusilovsky",72017,"other","Approval","This contribution proposes a new KI for eV2X TR.","Opened for comments",null,"5.21","Study on Security Aspects of 3GPP support for Advanced V2X Services (FS_eV2X_Sec)",6010,"noted","2019-02-19T13:51:16.347","2019-03-02T16:05:32.877"]
["S3-190602","New Key Issue for eV2X TR - privacy protection for multicast messages","InterDigital, Inc.","Alec Brusilovsky",72017,"other","Approval","This contribution proposes a new KI for eV2X TR.","Opened for comments",null,"5.21","Study on Security Aspects of 3GPP support for Advanced V2X Services (FS_eV2X_Sec)",6020,"noted","2019-02-19T13:57:11.440","2019-03-02T16:05:32.907"]
["S3-190604","New Key Issue for eV2X TR - security for unicast/multicast messages","InterDigital, Inc.","Alec Brusilovsky",72017,"other","Approval","This contribution proposes a new KI for eV2X TR.","Opened for comments",null,"5.21","Study on Security Aspects of 3GPP support for Advanced V2X Services (FS_eV2X_Sec)",6040,"noted","2019-02-19T18:09:37.960","2019-03-02T16:05:32.907"]
["S3-190606","New Key Issue for eV2X TR - Security of the UE service authorization and revocation","InterDigital, Inc.","Alec Brusilovsky",72017,"other","Approval","This contribution proposes a new KI for eV2X TR.","Opened for comments",null,"5.21","Study on Security Aspects of 3GPP support for Advanced V2X Services (FS_eV2X_Sec)",6060,"noted","2019-02-20T15:43:12.563","2019-03-02T16:05:32.890"]
["S3-190607","New Key Issue for eV2X TR - Security of the UE service provisioning","InterDigital, Inc.","Alec Brusilovsky",72017,"other","Approval","This contribution proposes a new KI for eV2X TR.","Opened for comments",null,"5.21","Study on Security Aspects of 3GPP support for Advanced V2X Services (FS_eV2X_Sec)",6070,"noted","2019-02-20T15:47:39.690","2019-03-02T16:05:32.890"]
["S3-190608","References","InterDigital, Inc.","Alec Brusilovsky",72017,"other","Approval","This contribution proposes References Section for eV2X TR.","Opened for comments",null,"5.21","Study on Security Aspects of 3GPP support for Advanced V2X Services (FS_eV2X_Sec)",6080,"noted","2019-02-20T16:13:18.313","2019-03-02T16:05:32.890"]
["S3-190769","Skeleton of eV2X security study","LG Electronics","Joonwoong Kim",66512,"other","Approval",null,"No comments",null,"5.21","Study on Security Aspects of 3GPP support for Advanced V2X Services (FS_eV2X_Sec)",7690,"approved","2019-03-04T11:08:33.373","2019-03-04T11:18:06.313",null,null,"Rel-16"]
["S3-190770","Scope proposal for eV2X security study","LG Electronics","Joonwoong Kim",66512,"other","Approval",null,"3 small changes to align with drafting rules",null,"5.21","Study on Security Aspects of 3GPP support for Advanced V2X Services (FS_eV2X_Sec)",7700,"Revised","2019-03-04T11:08:33.387","2019-03-04T11:18:06.330",null,"S3-190918","Rel-16"]
["S3-190918","Scope proposal for eV2X security study","LG Electronics","Joonwoong Kim",66512,"other","Approval",null,"Approved without being seen ",null,"5.21","Study on Security Aspects of 3GPP support for Advanced V2X Services (FS_eV2X_Sec)",7700,"approved",null,null,"S3-190770",null,"Rel-16"]
["S3-190919","new draft TR 33.ABC","LG Electronics","Joonwoong Kim",null,"draft TR","Approval",null,null,null,"5.21","Study on Security Aspects of 3GPP support for Advanced V2X Services (FS_eV2X_Sec)",7700,"approved"]
["S3-190750","New KI: Interworking between AKMA and GBA","Ericsson","Henrik Andreas Normann",77974,"pCR","Approval","Re-submission of S3-190326 which was not treated in Kochi.\nInvestigate if interworking between AKMA and GBA introduces any new security concerns.","Vdf: Can KI cover the case for interworking between GBA and AKMA so do not need two systems. Ericsson: That was intention. Vdf: proposed scenario for inclusion. Huawei: Agree with VDF point and want backwards compatibility with GBA - a new sentence perhaps. Nokia: Generalise the title would help make it clear what the key issue is addressing. TI: Concerned that is not clear what all the use cases are as SA3 are not doing thsi based on SA1 requirements. Vdf: Perhaps additions to clasue 4 would help. An EN will be added to capture this need. Interdigital: Is this in scope of study. BT: Need interworking to protect operators investment - good to add a securiyt requirement on this - taken offline. Vdf: Work is in scope as the evolution of GBA. ",null,"5.5","Study on authentication and key management for applications based on 3GPP credential in 5G IoT (FS_AKMA) \n(Rel-16)",6130,"Revised","2019-03-04T09:58:12.263","2019-03-04T13:06:59.087",null,"S3-190922","Rel-16","33.835","0.3.0","FS_AKMA"]
["S3-190922","New KI: Interworking between AKMA and GBA","Ericsson","Henrik Andreas Normann",77974,"pCR","Approval","Re-submission of S3-190326 which was not treated in Kochi.\nInvestigate if interworking between AKMA and GBA introduces any new security concerns.",null,null,"5.5","Study on authentication and key management for applications based on 3GPP credential in 5G IoT (FS_AKMA) \n(Rel-16)",6130,"withdrawn",null,null,"S3-190750",null,"Rel-16","33.835","0.3.0","FS_AKMA"]
["S3-190640","Discussion on use of established keys for AKMA root key","NEC Europe Ltd","Taka Yoshizawa",40702,"discussion","Discussion","This contribution discusses the issue of out-of-sync keys and propose the solution approach.","Vdf: OK to trust VPLMN not to be malicious in this case. Huawei: Why change the AUSF based on the AKMA study. Vdf: Moving the storage of K_AUSF may cause backwards compatiabliity to exisiting kit - this should be studied. ",null,"5.5","Study on authentication and key management for applications based on 3GPP credential in 5G IoT (FS_AKMA) \n(Rel-16)",6320,"noted","2019-03-03T08:42:30.280","2019-03-04T13:35:51.950",null,null,"Rel-16","33.835",null,"FS_AKMA"]
["S3-190646","New KI on Synchronization of Keys when using established keys","NEC Europe Ltd","Taka Yoshizawa",40702,"pCR","Approval","This contribution introduces a new KI.","Ericsson: would a solution be needed if TS 33.501 has the keys aligned. NEC: solution would be simple in this case  - just refer to TS 33.501.",null,"5.5","Study on authentication and key management for applications based on 3GPP credential in 5G IoT (FS_AKMA) \n(Rel-16)",6390,"approved","2019-03-03T08:55:10.347","2019-03-04T13:35:51.980",null,null,"Rel-16","33.835","0.3.0","FS_AKMA"]
["S3-190702","Key issue on Key freshness in AKMA","Huawei, Hisilicon","Longhua Guo",80179,"pCR","Approval",null,"Ericsson: need an Editor's note - not agreed. QC: Need to be generalised to be clear on the requirement. Orange: Want to see revised version",null,"5.5","Study on authentication and key management for applications based on 3GPP credential in 5G IoT (FS_AKMA) \n(Rel-16)",6400,"Revised","2019-03-04T08:08:51.093","2019-03-04T12:30:02.523",null,"S3-190924","Rel-16","33.835","0.3.0","FS_AKMA"]
["S3-190924","Key issue on Key freshness in AKMA","Huawei, Hisilicon","Longhua Guo",80179,"pCR","Approval",null,null,null,"5.5","Study on authentication and key management for applications based on 3GPP credential in 5G IoT (FS_AKMA) \n(Rel-16)",6400,"approved",null,null,"S3-190702",null,"Rel-16","33.835","0.3.0","FS_AKMA"]
["S3-190824","Updates to KI #14","Ericsson","Noamen Ben Henda",63310,"pCR","Approval",null,"Qualcomm: Why does the UE need to revoke the key? Agreed to not have requirement change. Also change the last EN to make it refer to UE only. BT and Vdf raised scenarios where the key may not be usable in the UE.",null,"5.5","Study on authentication and key management for applications based on 3GPP credential in 5G IoT (FS_AKMA) \n(Rel-16)",6410,"Revised","2019-03-04T11:52:14.287","2019-03-04T14:01:11.507",null,"S3-190925","Rel-16","33.835","0.3.0","FS_AKMA"]
["S3-190925","Updates to KI #14","Ericsson","Noamen Ben Henda",63310,"pCR","Approval",null,"Approved without being seen",null,"5.5","Study on authentication and key management for applications based on 3GPP credential in 5G IoT (FS_AKMA) \n(Rel-16)",6410,"approved",null,null,"S3-190824",null,"Rel-16","33.835","0.3.0","FS_AKMA"]
["S3-190613","New Solution: Battery efficient AKMA","KPN N.V.","Iko Keesmaat",33148,"pCR","Approval","This solution proposes procedures, signalling, and a key hierarchy to obtain AKMA functionality for battery contrained UEs.","It was proposed that the references to BEST were removed. This was agreed. QC: How are the user identity and enterprise id protected, hoes does this work with EAP method and how is this battery efficient. An editor's note of each of these issues was requeted. Vdf: Concern about any claim about bettery efficiency - would rather remove any mention of battery efficiency claims. There was support for this view. ",null,"5.5","Study on authentication and key management for applications based on 3GPP credential in 5G IoT (FS_AKMA) \n(Rel-16)",6420,"Revised","2019-02-28T13:35:49.663","2019-03-04T13:12:20.537",null,"S3-190926","Rel-16","33.835","0.3.0","FS_AKMA"]
["S3-190926","New Solution: Battery efficient AKMA","KPN N.V.","Iko Keesmaat",33148,"pCR","Approval","This solution proposes procedures, signalling, and a key hierarchy to obtain AKMA functionality for battery contrained UEs.",null,null,"5.5","Study on authentication and key management for applications based on 3GPP credential in 5G IoT (FS_AKMA) \n(Rel-16)",6420,"approved",null,null,"S3-190613",null,"Rel-16","33.835","0.3.0","FS_AKMA"]
["S3-190632","Solution to KI#9 Key separation for AKMA AFs","NEC Europe Ltd","Taka Yoshizawa",40702,"pCR","Approval","This pCR proposes a solution for Key issue #9 specified in study item on AKMA.","BT: Add an EN about further key separation to prevent key leakage causing an issue for other cases.",null,"5.5","Study on authentication and key management for applications based on 3GPP credential in 5G IoT (FS_AKMA) \n(Rel-16)",6430,"Revised","2019-03-03T08:15:02.987","2019-03-04T13:35:51.920",null,"S3-190927","Rel-16","33.835","0.3.0","FS_AKMA"]
["S3-190927","Solution to KI#9 Key separation for AKMA AFs","NEC Europe Ltd","Taka Yoshizawa",40702,"pCR","Approval","This pCR proposes a solution for Key issue #9 specified in study item on AKMA.","Approved without being seen",null,"5.5","Study on authentication and key management for applications based on 3GPP credential in 5G IoT (FS_AKMA) \n(Rel-16)",6430,"approved",null,null,"S3-190632",null,"Rel-16","33.835","0.3.0","FS_AKMA"]
["S3-190801","pCR: Reusing KAUSF for AKMA","Qualcomm Incorporated","Adrian Escott",24089,"pCR","Approval",null,"NEC: Key idenifier does not provide proof of possession. An EN will be enhanced to capture this. Some editorial corrections were pointed out. There was some discission on LI, but no changes were need at this meeting.",null,"5.5","Study on authentication and key management for applications based on 3GPP credential in 5G IoT (FS_AKMA) \n(Rel-16)",6440,"Revised","2019-03-04T11:30:16.630","2019-03-04T14:20:18.480","S3-190385","S3-190928","Rel-16","33.835","0.3.0","FS_AKMA"]
["S3-190928","pCR: Reusing KAUSF for AKMA","Qualcomm Incorporated","Anand",24089,"pCR","Approval",null,"Approved without being seen",null,"5.5","Study on authentication and key management for applications based on 3GPP credential in 5G IoT (FS_AKMA) \n(Rel-16)",6440,"approved",null,null,"S3-190801",null,"Rel-16","33.835","0.3.0","FS_AKMA"]
["S3-190639","Solution for Established Key Synchronization","NEC Europe Ltd","Taka Yoshizawa",40702,"pCR","Approval","This contribution introduces a new solution for implicit boostrapping key sychronization.","Vdf: Change of title to make it Key synchronisation for implicit bootstrapping. Ericsson: Will this work/be needed if this is covered by TS 33.501. NEC: Would not need a new solution if TS 33.501 provides a solution. Qualcomm: Propose an EN on the use of ngKSI for AKMA key identification and use identification rather than synchronisation in title.",null,"5.5","Study on authentication and key management for applications based on 3GPP credential in 5G IoT (FS_AKMA) \n(Rel-16)",6450,"Revised","2019-03-03T08:37:57.290","2019-03-04T13:35:51.950",null,"S3-190929","Rel-16","33.835","0.3.0","FS_AKMA"]
["S3-190929","Solution for Established Key Synchronization","NEC Europe Ltd","Taka Yoshizawa",40702,"pCR","Approval","This contribution introduces a new solution for implicit boostrapping key sychronization.","Approved without being seen",null,"5.5","Study on authentication and key management for applications based on 3GPP credential in 5G IoT (FS_AKMA) \n(Rel-16)",6450,"approved",null,null,"S3-190639",null,"Rel-16","33.835","0.3.0","FS_AKMA"]
["S3-190642","Resolving Editor’s Notes in Solution #16","NEC Europe Ltd","Taka Yoshizawa",40702,"pCR","Approval","This contribution resolves an existing EN.",null,null,"5.5","Study on authentication and key management for applications based on 3GPP credential in 5G IoT (FS_AKMA) \n(Rel-16)",6460,"approved","2019-03-03T08:47:04.927","2019-03-04T13:35:51.967",null,null,"Rel-16","33.835","0.3.0","FS_AKMA"]
["S3-190641","Discussion on using KSEAF and/or KAUSF for AKMA in view of regulatory compliance","NEC Europe Ltd","Taka Yoshizawa",40702,"discussion","Discussion","This contribution discusses how and why to use KAUSF and/or KSEAF.","Orange: Quetsioning the conclusion on supplying the key to the serving networks - this is not aligned with BEST. DCM: Concerned that there is a large change of trust model as the home operator should be in control of the authenitcation ",null,"5.5","Study on authentication and key management for applications based on 3GPP credential in 5G IoT (FS_AKMA) \n(Rel-16)",6880,"noted","2019-03-03T08:45:19.933","2019-03-04T13:35:51.967",null,null,"Rel-16","33.835",null,"FS_AKMA"]
["S3-190644","Updating solution #16 to include home network option","NEC Europe Ltd","Taka Yoshizawa",40702,"pCR","Approval","This contribution updates existing solution #16.","DCM: Proposal to add an EN in evaulation to cover concern about providing keys to serving networks. Qualcomm proposed that AKMA authentication based from a key known to the serving network loses home network control. Orange and DCM were supportive of such a sentence. This was taken offline.",null,"5.5","Study on authentication and key management for applications based on 3GPP credential in 5G IoT (FS_AKMA) \n(Rel-16)",7010,"Revised","2019-03-03T08:51:08.183","2019-03-04T13:35:51.967",null,"S3-190930","Rel-16","33.835","0.3.0","FS_AKMA"]
["S3-190930","Updating solution #16 to include home network option","NEC Europe Ltd","Taka Yoshizawa",40702,"pCR","Approval","This contribution updates existing solution #16.",null,null,"5.5","Study on authentication and key management for applications based on 3GPP credential in 5G IoT (FS_AKMA) \n(Rel-16)",7010,"approved",null,null,"S3-190644",null,"Rel-16","33.835","0.3.0","FS_AKMA"]
["S3-190645","Creating a combined solution for usage of KSEAF and KAUSF","NEC Europe Ltd","Taka Yoshizawa",40702,"pCR","Approval","This contribution introduces a new solution.","Kept open based on the discussion of S3-190930 - ",null,"5.5","Study on authentication and key management for applications based on 3GPP credential in 5G IoT (FS_AKMA) \n(Rel-16)",7020,"Revised","2019-03-03T08:52:48.853","2019-03-04T13:35:51.980",null,"S3-190996","Rel-16","33.835","0.3.0","FS_AKMA"]
["S3-190996","Creating a combined solution for usage of KSEAF and KAUSF","NEC Europe Ltd","Taka Yoshizawa",40702,"pCR","Approval","This contribution introduces a new solution.",null,null,"5.5","Study on authentication and key management for applications based on 3GPP credential in 5G IoT (FS_AKMA) \n(Rel-16)",7020,"approved",null,null,"S3-190645",null,"Rel-16","33.835","0.3.0","FS_AKMA"]
["S3-190643","Solution for Roaming Architecture","NEC Europe Ltd","Taka Yoshizawa",40702,"pCR","Approval","This contribution introduces a new solution.","Orange: what is the rationale for this proposal. NEC: Similar to GBA to have a proxy in the serving network. Qualcomm: Agree that motivation for proxy is not clear, i.e. is it a routing issue.",null,"5.5","Study on authentication and key management for applications based on 3GPP credential in 5G IoT (FS_AKMA) \n(Rel-16)",7030,"noted","2019-03-03T08:49:04.143","2019-03-04T13:35:51.967",null,null,"Rel-16","33.835","0.3.0","FS_AKMA"]
["S3-190688","improvement for AKMA architecture","Huawei, HiSilicon","Zander (Zhongding) Lei",66556,"pCR","Approval",null,"Gemalto: What is the rationale for the proxy",null,"5.5","Study on authentication and key management for applications based on 3GPP credential in 5G IoT (FS_AKMA) \n(Rel-16)",7500,"noted","2019-03-04T06:36:15.057","2019-03-04T11:21:26.420",null,null,"Rel-16","33.835","0.3.0","FS_AKMA"]
["S3-190703","Solution for Key freshness in AKMA","Huawei, Hisilicon","Longhua Guo",80179,"pCR","Approval",null,"Orange: This relates to S3-190924 - this was closed for while until the key issue was approved. Ericsson: EN asking for clarification on application key generation. Orange: Key lifetime check is not optional ",null,"5.5","Study on authentication and key management for applications based on 3GPP credential in 5G IoT (FS_AKMA) \n(Rel-16)",7670,"Revised","2019-03-04T08:08:51.173","2019-03-04T12:30:02.523",null,"S3-191005","Rel-16","33.835","0.3.0","FS_AKMA"]
["S3-191005","Solution for Key freshness in AKMA","Huawei, Hisilicon","Longhua Guo",80179,"pCR","Approval",null,null,null,"5.5","Study on authentication and key management for applications based on 3GPP credential in 5G IoT (FS_AKMA) \n(Rel-16)",7670,"Approved",null,null,"S3-190703",null,"Rel-16","33.835","0.3.0","FS_AKMA"]
["S3-190767","AKMA Architecture and procedures with the anchor function as NEF","China Mobile Com. Corporation","Xiaoting Huang",78337,"pCR",null,null,"Orange: It is not clear what the solution is proposing. The reasons for co-locating the NEF and AApF are not justified",null,"5.5","Study on authentication and key management for applications based on 3GPP credential in 5G IoT (FS_AKMA) \n(Rel-16)",7740,"noted","2019-03-04T11:05:04.203","2019-03-04T13:51:16.867",null,null,"Rel-16","33.835","0.3.0","FS_AKMA"]
["S3-190774","Resolving Editor's notes in solution 6","China Mobile Com. Corporation","Xiaoting Huang",78337,"pCR",null,null,"E//: protocol is run on ME.  CMCC: yes. E//: add to evaluation EN: it is FFS how a non 3GPP UE implementing COAP, MQTT, etc. can interface to 3GPP network. Orange: what does E// want to study, non 3GPP UE is out of scope. E//: how is COAP and MQTT used to transport 5G protocols. Nokia: there will be a gateway. Orange: instead put an EN on how the protocol stack works. VF: is the author of the previous contribution happy with htis substantial change? remove evaluation. CMCC: remove evaluation. VF: not the right process to change other peoples solutions. DCM: contributions can change other peoples solutions, but if the group decides t not to accept this, or prefers a new solution, then this will be decided. ",null,"5.5","Study on authentication and key management for applications based on 3GPP credential in 5G IoT (FS_AKMA) \n(Rel-16)",8010,"Revised","2019-03-04T11:09:52.247","2019-03-04T13:51:16.850",null,"S3-190931","Rel-16","33.835","0.3.0","FS_AKMA"]
["S3-190931","Resolving Editor's notes in solution 6","China Mobile Com. Corporation","Xiaoting Huang",78337,"pCR",null,null,null,null,"5.5","Study on authentication and key management for applications based on 3GPP credential in 5G IoT (FS_AKMA) \n(Rel-16)",8010,"approved","2019-03-04T11:09:52.247","2019-03-04T13:51:16.850","S3-190774",null,"Rel-16","33.835","0.3.0","FS_AKMA"]
["S3-190807","Protocol details for solution 3","Ericsson","Noamen Ben Henda",63310,"pCR","Approval",null,"no comments",null,"5.5","Study on authentication and key management for applications based on 3GPP credential in 5G IoT (FS_AKMA) \n(Rel-16)",8060,"approved","2019-03-04T11:52:13.927","2019-03-04T14:01:11.413",null,null,"Rel-16","33.835","0.3.0","FS_AKMA"]
["S3-190821","Updates to Solution #14","Ericsson","Noamen Ben Henda",63310,"pCR","Approval",null,"VF: out of scope. Lifetime of keys irrelevant to 3GPP. Mechanism to renegotiate a key is in scope E//: key negotiation by revocation. QC: delete all proposed text in 6.14.2.2, replace by text how revocation in UE is out of scope. E//: previous contribution had ed note UE revocation is FFS. QC: ok leave out all this text for now.  6.14.2.2, 6.14.2.3, 6.14.2.3. Nokia: redo all to make it network specific. NEC: if key is revoked, what does it mean? E//: deletion, but there is something between deletion and existing sessions.NEC: needs to be only for new sessions. VF: this should be out of scope, unfortunately allowed last meeting. delete everything related to key revocation. BT: if mobile operator cancels key, there may be problem with relying services. QC: note complete document, remove revocation in next meeting. ",null,"5.5","Study on authentication and key management for applications based on 3GPP credential in 5G IoT (FS_AKMA) \n(Rel-16)",8070,"noted","2019-03-04T11:52:14.223","2019-03-04T14:01:11.493",null,null,"Rel-16","33.835","0.3.0","FS_AKMA"]
["S3-190823","New Solution Key Lifetime","Ericsson","Noamen Ben Henda",63310,"pCR","Approval",null,"VF: who or what is derivng the subkeys. Should be up to application. E//: need to have different keys for applications. E//: applicaitons are per application functions. VF: then only option 1 is sensible. Because key is going to change. BT: seperate keys for applications, with individual lifetime. VF: out of scope, note it. we don't know how keys are being used. Nokia: come back to this when solution is decided, so there is no terminology confusion. QC: req. of derived keys shall not exceed anchor key lifetime. decision for option 1 is there, so note.",null,"5.5","Study on authentication and key management for applications based on 3GPP credential in 5G IoT (FS_AKMA) \n(Rel-16)",8080,"noted","2019-03-04T11:52:14.270","2019-03-04T14:01:11.493",null,null,"Rel-16","33.835","0.3.0","FS_AKMA"]
["S3-190836","Modification of user identity in solution 2 and solution 3","ZTE Corporation, Nubia","Jin PENG",49548,"pCR","Approval",null,"Orange: it is not user identity but SUPI, or potentially SUCI. Propose to note, consider this globally. QC: agree with Orange.",null,"5.5","Study on authentication and key management for applications based on 3GPP credential in 5G IoT (FS_AKMA) \n(Rel-16)",8210,"noted","2019-03-04T12:18:46.247","2019-03-04T12:28:24.053",null,null,"Rel-16","33.835","0.3.0","FS_AKMA"]
["S3-190842","Solution 15 editorials","Ericsson","Vlasios Tsiatsis",76181,"pCR","Approval",null,"QC: least significant 256 bits. EMSK is potentially reused. May be revealed. EN: it is FFS whether a derived key is to be used. DCM: KAKMA derived from EMSK, EN: how to derive KAKMA is FFS.",null,"5.5","Study on authentication and key management for applications based on 3GPP credential in 5G IoT (FS_AKMA) \n(Rel-16)",8220,"Revised","2019-03-04T13:09:21.437","2019-03-04T13:51:26.913",null,"S3-190932","Rel-16","33.835","0.3.0","FS_AKMA"]
["S3-190932","Solution 15 editorials","Ericsson","Vlasios Tsiatsis",76181,"pCR","Approval",null,null,null,"5.5","Study on authentication and key management for applications based on 3GPP credential in 5G IoT (FS_AKMA) \n(Rel-16)",8220,"approved","2019-03-04T13:09:21.437","2019-03-04T13:51:26.913","S3-190842",null,"Rel-16","33.835","0.3.0","FS_AKMA"]
["S3-190843","Solution 15 comment on the application keys","Ericsson","Vlasios Tsiatsis",76181,"pCR","Approval",null,"QC: K should be K_NAF in GBA. VF: needs Englishification. TS describes. Discussed offline.",null,"5.5","Study on authentication and key management for applications based on 3GPP credential in 5G IoT (FS_AKMA) \n(Rel-16)",8230,"Revised","2019-03-04T13:09:21.543","2019-03-04T13:51:26.913",null,"S3-190933","Rel-16","33.835","0.3.0","FS_AKMA"]
["S3-190933","Solution 15 comment on the application keys","Ericsson","Vlasios Tsiatsis",76181,"pCR","Approval",null,null,null,"5.5","Study on authentication and key management for applications based on 3GPP credential in 5G IoT (FS_AKMA) \n(Rel-16)",8230,"approved","2019-03-04T13:09:21.543","2019-03-04T13:51:26.913","S3-190843",null,"Rel-16","33.835","0.3.0","FS_AKMA"]
["S3-190701","Evaluation of solution 4","Huawei, Hisilicon","Longhua Guo",80179,"pCR","Approval",null,"VF: need more evidence to accept the evaluation. Orange: not ready, not it. VF: note all the evaluations. E//:  how should this be done. Orange: solutions are not ready, there are still Ens. To early for evaluation. VF: evaluation is not proper. E//: ok with this comment, but need to establish way of working. VF: when there are fewer key issues added, then is the right time. Chair: need more technical details to achieve the evaluation. TNO: is there a place to look for good examples. VF: example LTKUP",null,"5.5","Study on authentication and key management for applications based on 3GPP credential in 5G IoT (FS_AKMA) \n(Rel-16)",8240,"noted","2019-03-04T08:08:50.767","2019-03-04T12:30:02.507",null,null,"Rel-16","33.835","0.3.0","FS_AKMA"]
["S3-190806","Evaluation of solution 2","Ericsson","Noamen Ben Henda",63310,"pCR","Approval",null,"VF: not addressing all key issues NEC: this was not trying to full solution, so acceptable except for small items. QC: impact of PANA is quite big. Load on network authentication. No comparison on overhead. EAP AKA' has to be supported at home operator, so this needs to be added. VF: if we put this in, then the rest might not get done. Nokia: this is solution specific, so not the summary, need to define evaluation criteria. Orange: EN: this evaluation is not complete, add points by QC. VF: not enough content in section 4, hard to identify what to evaluate against. VF: object to whole document. QC: also note, come back at next meeting. Orange: remove advantages, be more neutral. BT: no supporting this paragraph. E//: wnat technical argument against second paragraph. QC: solution doesn't describe impact of PANA, so difficult to see impact. E//: how to improve. note",null,"5.5","Study on authentication and key management for applications based on 3GPP credential in 5G IoT (FS_AKMA) \n(Rel-16)",8360,"noted","2019-03-04T11:52:13.897","2019-03-04T14:01:11.413",null,null,"Rel-16","33.835","0.3.0","FS_AKMA"]
["S3-190808","Evaluation of solution 3","Ericsson","Noamen Ben Henda",63310,"pCR","Approval",null,null,null,"5.5","Study on authentication and key management for applications based on 3GPP credential in 5G IoT (FS_AKMA) \n(Rel-16)",8420,"noted","2019-03-04T11:52:13.960","2019-03-04T14:01:11.430",null,null,"Rel-16","33.835","0.3.0","FS_AKMA"]
["S3-190822","Conclusion to Solution #14","Ericsson","Noamen Ben Henda",63310,"pCR","Approval",null,"Orange: still ed notes in solution, so note",null,"5.5","Study on authentication and key management for applications based on 3GPP credential in 5G IoT (FS_AKMA) \n(Rel-16)",8430,"noted","2019-03-04T11:52:14.240","2019-03-04T14:01:11.493",null,null,"Rel-16","33.835","0.3.0","FS_AKMA"]
["S3-190844","Solution 15 evaluation","Ericsson","Vlasios Tsiatsis",76181,"pCR","Approval",null,"change to figure ok, VF: remove second sentence after ed note. VF: oppose evaluation section inclusion. BT: support the last paragraph of evaluation section. VF: evaluation criteria are not there yet. Orange: evaluation criteria are required only for final evalution. VF: against what use cases. section 4 is missing. Orange: would be ok if evaluation criteria are available in the beginning. Nokia: solution specific evaluation should be focussed on key issue only. CMCC: keep evaluation here, and do overall evaluation in section 7. Orange: need to deal with partial solutions. DCM: show which issues are solved and why. Keep comparisons to other solutions out. NEC: mssing impact. Orange: add impact and advantages. Orange: need a way forward discussion. \nNEC supports keeping conclusion, Apple as well. VF: second para deleted due to preference for one option.  Orange: last paragraph, remove last part. ",null,"5.5","Study on authentication and key management for applications based on 3GPP credential in 5G IoT (FS_AKMA) \n(Rel-16)",8440,"Revised","2019-03-04T13:09:21.607","2019-03-04T13:51:26.930",null,"S3-190935","Rel-16","33.835","0.3.0","FS_AKMA"]
["S3-190935","Solution 15 evaluation","Ericsson","Vlasios Tsiatsis",76181,"pCR","Approval",null,null,null,"5.5","Study on authentication and key management for applications based on 3GPP credential in 5G IoT (FS_AKMA) \n(Rel-16)",8440,"approved","2019-03-04T13:09:21.607","2019-03-04T13:51:26.930","S3-190844",null,"Rel-16","33.835","0.3.0","FS_AKMA"]
["S3-190923","new draft TR 33.835","China Mobile Com. Corporation","Xiaoting Huang",null,"draft TR","Approval",null,null,null,"5.5","Study on authentication and key management for applications based on 3GPP credential in 5G IoT (FS_AKMA) \n(Rel-16)",8440,"approved"]
["S3-190934","Way forward on evaluations for FS_AKMA","Orange","Todor ",null,"discussion","Endorsement",null,"No comments",null,"5.5",null,null,"endorsed"]
["S3-190611","Reply LS on authentication of group of IoT devices","S1-190501","Mirko Cano Soveri",41957,"LS in",null,null,"Not in scope of this meeting - postponed to next SA3 plenary",null,"5.6","Study on evolution of Cellular IoT security for the 5G System (FS_CIoT_sec_5G) (Rel-16)",6030,"postponed","2019-02-25T02:02:33.200","2019-02-25T02:09:04.800"]
["S3-190784","Acknowledging the multiple possible mobility solutions for CP small data","Qualcomm Incorporated","Adrian Escott",24089,"pCR","Approval",null,null,null,"5.6","Study on evolution of Cellular IoT security for the 5G System (FS_CIoT_sec_5G) (Rel-16)",6110,"approved","2019-03-04T11:30:16.083","2019-03-04T14:19:41.977",null,null,"Rel-16","33.861","0.3.0","FS_CIoT_sec_5G"]
["S3-190815","Evaluation to Solution #3 ‘Security solution for MO SMS at AMF re-allocation’","Ericsson","Noamen Ben Henda",63310,"pCR","Approval",null,null,null,"5.6","Study on evolution of Cellular IoT security for the 5G System (FS_CIoT_sec_5G) (Rel-16)",6140,"approved","2019-03-04T11:52:14.100","2019-03-04T14:01:11.460",null,null,"Rel-16","33.861","0.4.0","FS_CIoT_sec_5G"]
["S3-190816","Evaluation to Solution #4 ‘Security solution for UL small data transfer in RRC Suspend and Resume with early data transmission (EDT)’","Ericsson","Noamen Ben Henda",63310,"pCR","Approval",null,"Huawei: There are RAN issues with EDT, so propose to note",null,"5.6","Study on evolution of Cellular IoT security for the 5G System (FS_CIoT_sec_5G) (Rel-16)",6610,"Noted","2019-03-04T11:52:14.130","2019-03-04T14:01:11.460",null,null,"Rel-16","33.861","0.4.0","FS_CIoT_sec_5G"]
["S3-190817","Evaluation to Solution #5 ‘Security solution for small data included in initial NAS signalling at mobility’","Ericsson","Noamen Ben Henda",63310,"pCR","Approval",null,null,null,"5.6","Study on evolution of Cellular IoT security for the 5G System (FS_CIoT_sec_5G) (Rel-16)",6620,"approved","2019-03-04T11:52:14.147","2019-03-04T14:01:11.477",null,null,"Rel-16","33.861","0.4.0","FS_CIoT_sec_5G"]
["S3-190614","Update of Solution #6 – Use of UE Configuration Update","KPN N.V.","Iko Keesmaat",33148,"pCR","Approval","This contribution provides an update of Solution #6 Detecting and handling signalling overload due to Malicious Applications on the UE.","Orange: MT should be used instead of UESF. EN of further evaluation needed  QC: How do you provide filters for applications as they are not standardised - add an EN of this. Gemalto: Issue with the figure of UE - taken offline to address the terminolgy ",null,"5.6","Study on evolution of Cellular IoT security for the 5G System (FS_CIoT_sec_5G) (Rel-16)",7040,"Noted","2019-02-28T13:38:08.460","2019-03-04T13:11:03.367",null,null,"Rel-16","33.861","0.4.0","FS_CIoT_sec_5G"]
["S3-190661","Deleting EN on the usage of per-gNB and per-UE counters for solution #7 “protecting gNB from RRC DoS attack”","Huawei, Hisilicon","Longhua Guo",80179,"pCR","Approval",null,"Orange: If it is left for implementation, then how does your solution work. Need text like thresholds are supported, values are for configuarations. ",null,"5.6","Study on evolution of Cellular IoT security for the 5G System (FS_CIoT_sec_5G) (Rel-16)",7050,"Revised","2019-03-04T02:43:14.513","2019-03-04T12:33:33.753",null,"S3-191025","Rel-16","33.861","0.4.0","FS_CIoT_sec_5G"]
["S3-191025","Deleting EN on the usage of per-gNB and per-UE counters for solution #7 “protecting gNB from RRC DoS attack”","Huawei, Hisilicon","Longhua Guo",80179,"pCR","Approval",null,"Check with orange and then approved without being further seen",null,"5.6","Study on evolution of Cellular IoT security for the 5G System (FS_CIoT_sec_5G) (Rel-16)",7050,"approved",null,null,"S3-190661",null,"Rel-16","33.861","0.4.0","FS_CIoT_sec_5G"]
["S3-190662","Delete the EN related to the “AttackInformationNotification” message","Huawei, Hisilicon","Longhua Guo",80179,"pCR","Approval",null,"Ericsson: Can one UE sabotage the context of another UE by replaying a message. The discussion related to evaluation and will be brought later",null,"5.6","Study on evolution of Cellular IoT security for the 5G System (FS_CIoT_sec_5G) (Rel-16)",7060,"approved","2019-03-04T02:43:14.797","2019-03-04T12:33:33.753",null,null,"Rel-16","33.861","0.4.0","FS_CIoT_sec_5G"]
["S3-190792","Security protection of small data at idle mode mobility","Qualcomm Incorporated","Adrian Escott",24089,"pCR","Approval",null,null,null,"5.6","Study on evolution of Cellular IoT security for the 5G System (FS_CIoT_sec_5G) (Rel-16)",7170,"approved","2019-03-04T11:30:16.350","2019-03-04T14:20:18.433",null,null,"Rel-16","33.861","0.3.0","FS_CIoT_sec_5G"]
["S3-190800","Adding an evaluation to solution #9 in TR 33.861","Qualcomm Incorporated","Adrian Escott",24089,"pCR","Approval",null,"Huawei: Add EN on whether small data goes in Reg Request",null,"5.6","Study on evolution of Cellular IoT security for the 5G System (FS_CIoT_sec_5G) (Rel-16)",7840,"Revised","2019-03-04T11:30:16.583","2019-03-04T14:20:18.480",null,"S3-191032","Rel-16","33.861","0.3.0","FS_CIoT_sec_5G"]
["S3-191032","Adding an evaluation to solution #9 in TR 33.861","Qualcomm Incorporated","Adrian Escott",24089,"pCR","Approval",null,null,null,"5.6","Study on evolution of Cellular IoT security for the 5G System (FS_CIoT_sec_5G) (Rel-16)",7840,"approved",null,null,"S3-190800",null,"Rel-16","33.861","0.3.0","FS_CIoT_sec_5G"]
["S3-190785","Resolving the editor’s note in solution #10 in TR 33.861","Qualcomm Incorporated","Adrian Escott",24089,"pCR","Approval",null,null,null,"5.6","Study on evolution of Cellular IoT security for the 5G System (FS_CIoT_sec_5G) (Rel-16)",7850,"Approved","2019-03-04T11:30:16.117","2019-03-04T14:19:41.977",null,null,"Rel-16","33.861","0.3.0","FS_CIoT_sec_5G"]
["S3-190786","Adding an evaluation to solution #10 in TR 33.861","Qualcomm Incorporated","Adrian Escott",24089,"pCR","Approval",null,"Huawei: Add EN on whether small data goes in Reg Request",null,"5.6","Study on evolution of Cellular IoT security for the 5G System (FS_CIoT_sec_5G) (Rel-16)",7860,"Revised","2019-03-04T11:30:16.147","2019-03-04T14:19:41.943",null,"S3-191033","Rel-16","33.861","0.3.0","FS_CIoT_sec_5G"]
["S3-191033","Adding an evaluation to solution #10 in TR 33.861","Qualcomm Incorporated","Adrian Escott",24089,"pCR","Approval",null,null,null,"5.6","Study on evolution of Cellular IoT security for the 5G System (FS_CIoT_sec_5G) (Rel-16)",7860,"approved",null,null,"S3-190786",null,"Rel-16","33.861","0.3.0","FS_CIoT_sec_5G"]
["S3-190717","Update to solution#12\"DDoS attack mitigation in CIoT\"","Huawei, Hisilicon","Longhua Guo",80179,"pCR","Approval",null,"No comments",null,"5.6","Study on evolution of Cellular IoT security for the 5G System (FS_CIoT_sec_5G) (Rel-16)",7920,"approved","2019-03-04T08:08:52","2019-03-04T12:30:02.477",null,null,"Rel-16","33.861","0.4.0","FS_CIoT_sec_5G"]
["S3-190603","Solution proposal for FS_CIoT_sec_5G key issue #1 and #2","Philips International B.V.","John Bernsen",35096,"pCR","Approval",null,"Huawei: Cryptographic strength of the method need evalution - agreed to remove evaluation and add EN of strength evaluations. Ericsson: Buffering of data at receiver is needed. EN added on this.",null,"5.6","Study on evolution of Cellular IoT security for the 5G System (FS_CIoT_sec_5G) (Rel-16)",8000,"Revised","2019-02-19T15:18:01.397","2019-02-20T12:27:33.387",null,"S3-191027","Rel-16","33.861","0.4.0","FS_CIoT_sec_5G"]
["S3-191027","Solution proposal for FS_CIoT_sec_5G key issue #1 and #2","Philips International B.V.","John Bernsen",35096,"pCR","Approval",null,null,null,"5.6","Study on evolution of Cellular IoT security for the 5G System (FS_CIoT_sec_5G) (Rel-16)",8000,"approved",null,null,"S3-190603",null,"Rel-16","33.861","0.4.0","FS_CIoT_sec_5G"]
["S3-190704","Solution to identify misbehaving UEs","Huawei, Hisilicon","Longhua Guo",80179,"pCR","Approval",null,"Orange: Add EN on what kind of UE behaviour information is collected. Huawei: think it is more in scope of SA2. Ericsson: EN on privacy of collecting information ",null,"5.6","Study on evolution of Cellular IoT security for the 5G System (FS_CIoT_sec_5G) (Rel-16)",8150,"Revised","2019-03-04T08:08:51.233","2019-03-04T12:30:02.523",null,"S3-191028","Rel-16","33.861","0.4.0","FS_CIoT_sec_5G"]
["S3-191028","Solution to identify misbehaving UEs","Huawei, Hisilicon","Longhua Guo",80179,"pCR","Approval",null,null,null,"5.6","Study on evolution of Cellular IoT security for the 5G System (FS_CIoT_sec_5G) (Rel-16)",8150,"approved",null,null,"S3-190704",null,"Rel-16","33.861","0.4.0","FS_CIoT_sec_5G"]
["S3-190705","Solution to Migitate DDoS Attack based on RAN","Huawei, Hisilicon","Longhua Guo",80179,"pCR","Approval",null,"Ericsson: Can UE send random junk effect the analysis but posioning the blacklist. Huawei: UEs not added immediately. QC :Add EN - how to identify the UE is FFS - was proposed and accepted. Vdf: Blacklist detection report must not classify a non-mis-behaving UE as mis-behaving - also how to you get off blacklist. Huawei: SF create the list - Vdf: two ENs one on removal and on GUTI re-use. Ericsson: EN on privacy",null,"5.6","Study on evolution of Cellular IoT security for the 5G System (FS_CIoT_sec_5G) (Rel-16)",8160,"Revised","2019-03-04T08:08:51.313","2019-03-04T12:30:02.537",null,"S3-191029","Rel-16","33.861","0.4.0","FS_CIoT_sec_5G"]
["S3-191026","new draft TR 33.861","Ericsson","Noamen Ben Henda",null,"draft TR","Approval",null,null,null,"5.6","Study on evolution of Cellular IoT security for the 5G System (FS_CIoT_sec_5G) (Rel-16)",8160,"approved"]
["S3-191029","Solution to Migitate DDoS Attack based on RAN","Huawei, Hisilicon","Longhua Guo",80179,"pCR","Approval",null,null,null,"5.6","Study on evolution of Cellular IoT security for the 5G System (FS_CIoT_sec_5G) (Rel-16)",8160,"approved",null,null,"S3-190705",null,"Rel-16","33.861","0.4.0","FS_CIoT_sec_5G"]
["S3-190706","Conclusion for KDF negotiation for 5G System Security","Huawei, Hisilicon","Longhua Guo",80179,"pCR","Approval",null,null,null,"5.6","Study on evolution of Cellular IoT security for the 5G System (FS_CIoT_sec_5G) (Rel-16)",8170,"revised","2019-03-04T08:08:51.377",null,null,"S3-190723","Rel-16","33.808","0.2.0","FS_5GS_KDF"]
["S3-190745","New KI: N3GPP Key Hierarchy","Ericsson","Christine Jost",49662,"pCR","Approval",null,"Huawei: not needed, no new access type defined in SA2. E//: problem should be studied. ZTE: TNAP is out of scope for 3GPP, so why study it. Nokia: support this requirement, but some parts too solution specific. Huawei: needs to be more generalized, delete solution specifics. Orange: requirement is strange. add EN: req needs to be reworded. ZTE: description for key separation seems to be for authentication, why is it needed? Nokia: for encryption. ZTE: ed note to req section. Huawei: new ed note to threat: purpose needs to be clarified. TIM comment on title, is key separation. on security threat: not self contained. on requirements: it is already like this. BT support this. TIM: prefer to keep this out until it is phrased properly. E//: have note on scope of this issue - taken offline",null,"5.7","Study on the security of the Wireless and Wireline Convergence for the 5G system architecture (FS_5WWC_SEC) \n(Rel-16)",7090,"Revised","2019-03-04T09:48:40.510","2019-03-04T14:10:37.473",null,"S3-191012","Rel-16","33.807","0.3.0","FS_5WWC_SEC"]
["S3-191012","New KI: N3GPP Key Hierarchy","Ericsson","Christine Jost",49662,"pCR","Approval",null,null,null,"5.7","Study on the security of the Wireless and Wireline Convergence for the 5G system architecture (FS_5WWC_SEC) \n(Rel-16)",7090,"approved",null,null,"S3-190745",null,"Rel-16","33.807","0.3.0","FS_5WWC_SEC"]
["S3-190746","New Solution: New access type distinguisher for N3GPP","Ericsson","Christine Jost",49662,"pCR","Approval",null,"TIM: what is meant by optional.E//: evaluation can go away. Huawei: solution not needed",null,"5.7","Study on the security of the Wireless and Wireline Convergence for the 5G system architecture (FS_5WWC_SEC) \n(Rel-16)",7100,"noted","2019-03-04T09:48:40.523","2019-03-04T14:10:37.473",null,null,"Rel-16","33.807","0.3.0","FS_5WWC_SEC"]
["S3-190747","New Solution: Key separation for untrusted and trusted access","Ericsson","Christine Jost",49662,"pCR","Approval",null,"Same issue as 746 at initial proposal. Re-discussed one key issue in S3-191012 was approved. BT: some keys need to be inclued. ZTE: Add EN on whether TNAP is in scope. Huawei: Add EN on whether this addresses KI is FFS. In figure remove all except trusted.",null,"5.7","Study on the security of the Wireless and Wireline Convergence for the 5G system architecture (FS_5WWC_SEC) \n(Rel-16)",7110,"Revised","2019-03-04T09:48:40.540","2019-03-04T14:10:37.443",null,"S3-191030","Rel-16","33.807","0.3.0","FS_5WWC_SEC"]
["S3-191030","New Solution: Key separation for untrusted and trusted access","Ericsson","Christine Jost",49662,"pCR","Approval",null,null,null,"5.7","Study on the security of the Wireless and Wireline Convergence for the 5G system architecture (FS_5WWC_SEC) \n(Rel-16)",7110,"approved",null,null,"S3-190747",null,"Rel-16","33.807","0.3.0","FS_5WWC_SEC"]
["S3-190748","New Solution: SUCI deconcealment for the FN-RG","Ericsson","Christine Jost",49662,"pCR","Approval",null,"Huawei: key issue 11 and 12 have no requirements, so what is the solution about. Nokia: NAS SMC in step 8. Gateway needs to support some sort of NAS. E//: yes. Huawei: note, because no requirements. TIM: first requirements, then solution. Note.",null,"5.7","Study on the security of the Wireless and Wireline Convergence for the 5G system architecture (FS_5WWC_SEC) \n(Rel-16)",7120,"noted","2019-03-04T09:48:40.540","2019-03-04T14:10:37.457",null,null,"Rel-16","33.807","0.3.0","FS_5WWC_SEC"]
["S3-190877","Mobility between TNAPs within the Trusted Non-3GPP Access Network (TNAN)","Nokia, Nokia Shanghai Bell","Nagendra Bykampadi",69265,"pCR","Approval","Mobility between TNAPs within the Trusted Non-3GPP Access Network (TNAN)","ZTE: out of scope for SA3. Nokia: SA2 has a note in 7.1.3.5.1 of SA2. Huawei: add ed note: whether this in scope of R16. Huawei: key hierarchy in issue details is like solution. Generalize. TIM: threats are missing. E//: may lead to architectural or service requirements. Nokia: make it architectural requirement, no threats",null,"5.7","Study on the security of the Wireless and Wireline Convergence for the 5G system architecture (FS_5WWC_SEC) \n(Rel-16)",7130,"Revised","2019-03-04T14:11:34.260","2019-03-04T14:19:16.500",null,"S3-191013","Rel-16","33.807","0.3.0","FS_5WWC_SEC"]
["S3-191013","Mobility between TNAPs within the Trusted Non-3GPP Access Network (TNAN)","Nokia, Nokia Shanghai Bell","Nagendra Bykampadi",69265,"pCR","Approval","Mobility between TNAPs within the Trusted Non-3GPP Access Network (TNAN)",null,null,"5.7","Study on the security of the Wireless and Wireline Convergence for the 5G system architecture (FS_5WWC_SEC) \n(Rel-16)",7130,"Approved",null,null,"S3-190877",null,"Rel-16","33.807","0.3.0","FS_5WWC_SEC"]
["S3-190878","Mobility between TNGFs within the Trusted Non-3GPP Access Network (TNAN)","Nokia, Nokia Shanghai Bell","Nagendra Bykampadi",69265,"pCR","Approval","Mobility between TNGFs within the Trusted Non-3GPP Access Network (TNAN)","ZTE: same question as 877, add same ed note. Orange: is this architecture agreed? Nokia: yes. ",null,"5.7","Study on the security of the Wireless and Wireline Convergence for the 5G system architecture (FS_5WWC_SEC) \n(Rel-16)",7140,"Revised","2019-03-04T14:13:24.180","2019-03-04T14:19:16.500",null,"S3-191014","Rel-16","33.807","0.3.0","FS_5WWC_SEC"]
["S3-191014","Mobility between TNGFs within the Trusted Non-3GPP Access Network (TNAN)","Nokia, Nokia Shanghai Bell","Nagendra Bykampadi",69265,"pCR","Approval","Mobility between TNGFs within the Trusted Non-3GPP Access Network (TNAN)","ZTE will check, approved without being seen.",null,"5.7","Study on the security of the Wireless and Wireline Convergence for the 5G system architecture (FS_5WWC_SEC) \n(Rel-16)",7140,"approved",null,null,"S3-190878",null,"Rel-16","33.807","0.3.0","FS_5WWC_SEC"]
["S3-190710","Add content to Introduction clause","Huawei, Hisilicon","Longhua Guo",80179,"pCR","Approval",null,"Nokia: editorials. Ed note: needs to be fixed. Orange: not in this shape. Issues with roaming. Take it next meeting.",null,"5.7","Study on the security of the Wireless and Wireline Convergence for the 5G system architecture (FS_5WWC_SEC) \n(Rel-16)",7150,"noted","2019-03-04T08:08:51.610","2019-03-04T12:30:02.553",null,null,"Rel-16","33.807","0.3.0","FS_5WWC_SEC"]
["S3-190709","Add content to section 4","Huawei, Hisilicon","Longhua Guo",80179,"pCR","Approval",null,"Orange: same issues. Work for next meeting. Start email discussion on these topics.",null,"5.7","Study on the security of the Wireless and Wireline Convergence for the 5G system architecture (FS_5WWC_SEC) \n(Rel-16)",7160,"noted","2019-03-04T08:08:51.577","2019-03-04T12:30:02.553",null,null,"Rel-16","33.807","0.3.0","FS_5WWC_SEC"]
["S3-190713","Delete EN for solution #3","Huawei, Hisilicon","Longhua Guo",80179,"pCR","Approval",null,"Nokia: first change: shall-> may? Huawei: bullet 1 and 2 had ed notes, but we don't know how it could be addressed. Orange: relates to authentciation, keep shall. Nokia: as well. E//: why conclude this to normative, still time to do this in study phase. Huawei: SA2 has not concluded yet. E//: may be bring this for next meeting. Orange: note this contribution. TIM: also suggest to note, there is not clear there is a normative phase.",null,"5.7","Study on the security of the Wireless and Wireline Convergence for the 5G system architecture (FS_5WWC_SEC) \n(Rel-16)",7450,"noted","2019-03-04T08:08:51.733","2019-03-04T12:30:02.443",null,null,"Rel-16","33.807","0.3.0","FS_5WWC_SEC"]
["S3-190714","Add evaluation to solution #3","Huawei, Hisilicon","Longhua Guo",80179,"pCR","Approval",null,"related to previous, Huawei proposes to note this and the 715, 716 and 712",null,"5.7","Study on the security of the Wireless and Wireline Convergence for the 5G system architecture (FS_5WWC_SEC) \n(Rel-16)",7460,"noted","2019-03-04T08:08:51.797","2019-03-04T12:30:02.443",null,null,"Rel-16","33.807","0.3.0","FS_5WWC_SEC"]
["S3-190715","Delete EN for solution 5","Huawei, Hisilicon","Longhua Guo",80179,"pCR","Approval",null,null,null,"5.7","Study on the security of the Wireless and Wireline Convergence for the 5G system architecture (FS_5WWC_SEC) \n(Rel-16)",7470,"withdrawn","2019-03-04T08:08:51.857","2019-03-04T12:30:02.443",null,null,"Rel-16","33.807","0.3.0","FS_5WWC_SEC"]
["S3-190716","Add evaluation to soluiton 5","Huawei, Hisilicon","Longhua Guo",80179,"pCR","Approval",null,null,null,"5.7","Study on the security of the Wireless and Wireline Convergence for the 5G system architecture (FS_5WWC_SEC) \n(Rel-16)",7480,"withdrawn","2019-03-04T08:08:51.920","2019-03-04T12:30:02.460",null,null,"Rel-16","33.807","0.3.0","FS_5WWC_SEC"]
["S3-190712","Conclusion on KI#1","Huawei, Hisilicon","Longhua Guo",80179,"pCR","Approval",null,null,null,"5.7","Study on the security of the Wireless and Wireline Convergence for the 5G system architecture (FS_5WWC_SEC) \n(Rel-16)",8750,"withdrawn","2019-03-04T08:08:51.703","2019-03-04T12:30:02.430",null,null,"Rel-16","33.807","0.3.0","FS_5WWC_SEC"]
["S3-190875","Removal of Editor’s Note in Solution#6","Lenovo, Motorola Mobility","Andreas Kunz",72589,"pCR","Approval","This document proposes to resolve the Editor’s Note in Solution#6","Orange: is this use case still valid SA2? Keep ed note. Lenovo: not possible to to this procedure. Nokia: will be resolved in next meetings. E//: same. ",null,"5.7","Study on the security of the Wireless and Wireline Convergence for the 5G system architecture (FS_5WWC_SEC) \n(Rel-16)",8770,"noted","2019-03-04T14:08:44.417","2019-03-04T14:29:22.980",null,null,"Rel-16","33.807","0.3.0","FS_5WWC_SEC"]
["S3-190711","Add content to section 4","Huawei, Hisilicon","Longhua Guo",80179,"pCR","Approval",null,null,null,"5.7","Study on the security of the Wireless and Wireline Convergence for the 5G system architecture (FS_5WWC_SEC) \n(Rel-16)",8780,"withdrawn","2019-03-04T08:08:51.657",null,null,null,"Rel-16","33.807","0.3.0","FS_5WWC_SEC"]
["S3-191015","new draft TR 33.807",null,null,null,null,null,null,null,null,"5.7","Study on the security of the Wireless and Wireline Convergence for the 5G system architecture (FS_5WWC_SEC) \n(Rel-16)",8780,"approved"]
["S3-190615","False base station key issue for RLOS P-CR","SPRINT Corporation","Greg Schumacher",35113,"pCR","Agreement",null,"Orange & QC: Don't feel that this key issue is appropriate - this may be brought back but would need requirements",null,"5.8","Study on Security Aspects of PARLOS (FS_PARLOS_Sec) (Rel-16)",6150,"Noted","2019-03-01T04:55:25.380","2019-03-01T05:05:33.827",null,null,"Rel-16","33.815","0.3.0","FS_PARLOS_Sec"]
["S3-190616","Reduced confidentiality protection key issue for RLOS P-CR","SPRINT Corporation","Greg Schumacher",35113,"pCR","Agreement",null,"Ericsson: very similar key issue already. Orange: Not clear can be solved. QC: Not clear this is a suitable key issue.",null,"5.8","Study on Security Aspects of PARLOS (FS_PARLOS_Sec) (Rel-16)",6160,"Noted","2019-03-01T04:59:10.247","2019-03-01T05:05:33.827",null,null,"Rel-16","33.815","0.3.0","FS_PARLOS_Sec"]
["S3-190617","Fraud controls bypassed key issue for RLOS P-CR","SPRINT Corporation","Greg Schumacher",35113,"pCR","Agreement",null,"Orange: IMEI is not an idnetifier of the UE. Ericsson: Why is this a different to normal use cases. Sprint: Maybe not clear what we are trying to achieve. BT: Support this going forward. QC: Fraud control mechanism is not standardised. Sprint: These were all brought up in SA3 so have been submitted for discussion. Orange: proposal to remove the 2nd sentence as there is no concept of HPLMN. Vdf: The IMEI can not be checked in the normal way. QC: Disputed that the IMEI can not be checked in the normal way. Ericsson: Need to be careful about having a list of attacks. This may be brought back but would need requirements",null,"5.8","Study on Security Aspects of PARLOS (FS_PARLOS_Sec) (Rel-16)",6170,"noted","2019-03-01T05:03:40.147","2019-03-01T05:05:33.813",null,null,"Rel-16","33.815","0.3.0","FS_PARLOS_Sec"]
["S3-190781","Proposed evaluation for Solution #1 AS and NAS security for RLOS services","Qualcomm Incorporated","Adrian Escott",24089,"pCR","Approval",null,"Add EN about further evaluation if further key issues. Remove emergencey calls . ",null,"5.8","Study on Security Aspects of PARLOS (FS_PARLOS_Sec) (Rel-16)",7810,"Revised","2019-03-04T11:30:15.977","2019-03-04T14:19:41.960",null,"S3-191010","Rel-16","33.815","0.3.0","FS_PARLOS_Sec"]
["S3-191010","Proposed evaluation for Solution #1 AS and NAS security for RLOS services","Qualcomm Incorporated","Adrian Escott",24089,"pCR","Approval",null,null,null,"5.8","Study on Security Aspects of PARLOS (FS_PARLOS_Sec) (Rel-16)",7810,"approved",null,null,"S3-190781",null,"Rel-16","33.815","0.3.0","FS_PARLOS_Sec"]
["S3-190782","Proposed evaluation for Solution #2 AS and NAS security based on the emergency call procedures","Qualcomm Incorporated","Adrian Escott",24089,"pCR","Approval",null,"The were objections to the proposed text. ",null,"5.8","Study on Security Aspects of PARLOS (FS_PARLOS_Sec) (Rel-16)",7820,"noted","2019-03-04T11:30:16.023","2019-03-04T14:19:41.977",null,null,"Rel-16","33.815","0.3.0","FS_PARLOS_Sec"]
["S3-190783","Proposed update for Solution #2 AS and NAS security based on the emergency call procedures","Qualcomm Incorporated","Adrian Escott",24089,"pCR","Approval",null,"Change a 'sh' to 'c'",null,"5.8","Study on Security Aspects of PARLOS (FS_PARLOS_Sec) (Rel-16)",7830,"Revised","2019-03-04T11:30:16.053","2019-03-04T14:19:41.977",null,"S3-191011","Rel-16","33.815","0.3.0","FS_PARLOS_Sec"]
["S3-191011","Proposed update for Solution #2 AS and NAS security based on the emergency call procedures","Qualcomm Incorporated","Adrian Escott",24089,"pCR","Approval",null,"Approved without being seen",null,"5.8","Study on Security Aspects of PARLOS (FS_PARLOS_Sec) (Rel-16)",7830,"approved",null,null,"S3-190783",null,"Rel-16","33.815","0.3.0","FS_PARLOS_Sec"]
["S3-190868","Solution Evaluations and Conclusion on KI#1","Lenovo, Motorola Mobility","Andreas Kunz",72589,"pCR","Approval","This document provides the evaluations to the solutions and a conclusion for KI#1.","Merge the first clause into the S3-191010 - second part is not accepted - conclusion not accepted",null,"5.8","Study on Security Aspects of PARLOS (FS_PARLOS_Sec) (Rel-16)",8680,"merged","2019-03-04T13:50:16.540","2019-03-04T14:29:22.967",null,null,"Rel-16","33.815","0.3.0","FS_PARLOS_Sec"]
["S3-191023","new draft TR 33.815","SPRINT Corporation","Greg Schumacher",null,"draft TR","Approval",null,null,null,"5.8","Study on Security Aspects of PARLOS (FS_PARLOS_Sec) (Rel-16)",8680,"approved"]
["S3-190669","New security requirement against tampering of RRCResumeRequest message","Huawei, Hisilicon","Longhua Guo",80179,"pCR","Approval",null,"Ericsson: Why do we need to protect this? Huawei: There is the chance to protect this message. NEC and Samsung were supportive of the requirement. Ericsson and QC are not clear that the threats are sufficient to require a change. It was agreed to add an EN to capture that the security threats are not clear. The changes to the key issue details were agreed. The addition of the requirement was taken offline.  ",null,"5.9","Study on 5G security enhancement against false base stations (FS_5GFBS) (Rel-16)",6300,"Revised","2019-03-04T02:43:14.873","2019-03-04T12:33:33.737",null,"S3-190936","Rel-16","33.809","0.2.0","FS_5GFBS"]
["S3-190936","New security requirement against tampering of RRCResumeRequest message","Huawei, Hisilicon","Longhua Guo",80179,"pCR","Approval",null,"merged into S3-190997.",null,"5.9","Study on 5G security enhancement against false base stations (FS_5GFBS) (Rel-16)",6300,"merged",null,null,"S3-190669",null,"Rel-16","33.809","0.2.0","FS_5GFBS"]
["S3-190667","Protection of RRSResumeCause","Huawei, Hisilicon","Longhua Guo",80179,"pCR","Approval",null,"depends on S3-190997 - noted as no agreed final requirement",null,"5.9","Study on 5G security enhancement against false base stations (FS_5GFBS) (Rel-16)",6350,"Noted","2019-03-04T02:43:14.857","2019-03-04T12:33:33.720",null,null,"Rel-16","33.809","0.2.0","FS_5GFBS"]
["S3-190670","New security requirement against replay of RRCResumeRequest message","Huawei, Hisilicon","Longhua Guo",80179,"pCR","Approval",null,"Qualcomm: It is not clear that the requirement belongs to the false base station. Huawei: It will be treated under one agenda item or another. Ericsson: Wanted the requirement to have the addition of not putting the UE out of sync with the network. Qualcomm: concern that this does not fit into the false base station work. It was taken offline to decide which study item that this work can be placed under. EN on alignment of threat and requirement.",null,"5.9","Study on 5G security enhancement against false base stations (FS_5GFBS) (Rel-16)",6360,"Revised","2019-03-04T02:43:14.890","2019-03-04T12:33:33.737",null,"S3-190937","Rel-16","33.809","0.2.0","FS_5GFBS"]
["S3-190937","New security requirement against replay of RRCResumeRequest message","Huawei, Hisilicon","Longhua Guo",80179,"pCR","Approval",null,null,null,"5.9","Study on 5G security enhancement against false base stations (FS_5GFBS) (Rel-16)",6360,"Revised",null,null,"S3-190670","S3-190997","Rel-16","33.809","0.2.0","FS_5GFBS"]
["S3-190997","New security requirement against replay of RRCResumeRequest message","Huawei, Hisilicon","Longhua Guo",80179,"pCR","Approval",null,null,null,"5.9","Study on 5G security enhancement against false base stations (FS_5GFBS) (Rel-16)",6360,"approved",null,null,"S3-190937",null,"Rel-16","33.809","0.2.0","FS_5GFBS"]
["S3-190668","RRCResume replay protection","Huawei, Hisilicon","Longhua Guo",80179,"pCR","Approval",null,"Vdf wanted a EN on backwards compatibility issues for both UE and network - this was agreed. Ericsson raised a concern with the solution that it does not work. NEC and Qualcomm also feel that the solution does not satisfy the requirement. ",null,"5.9","Study on 5G security enhancement against false base stations (FS_5GFBS) (Rel-16)",6540,"noted","2019-03-04T02:43:14.873","2019-03-04T12:33:33.720",null,null,"Rel-16","33.809","0.2.0","FS_5GFBS"]
["S3-190829","KI#1 in TR 33.809 - new solution with netwrok controlled RRC Reject message","Ericsson","Prajwol Kumar Nakarmi",76183,"pCR","Approval",null,"NEC: What is the impact of the unprotected RRCReject? NEC were also not convinced the solution work. BT: Did not understand why some networks did not need RRCReject. Huawei: Feel that ths solution is a violation of RAN procedures. Qualcomm: Not clear on the RAN impacts. Orange: RAN impact is RRCReject can nit be sent as it is never sent after security activation. ",null,"5.9","Study on 5G security enhancement against false base stations (FS_5GFBS) (Rel-16)",6550,"noted","2019-03-04T11:59:10.130","2019-03-04T13:10:00.730",null,null,"Rel-16","33.809","0.2.0","FS_5GFBS"]
["S3-190834","Adding evaluation for Solution #1","Apple Computer Trading Co. Ltd","Shu Guo",76339,"pCR","Approval",null,"Orange: This solution can be done with the current specification as a configuration of the network. It was not clear to Ericsson that this was only a configuration from the description of the solution. An editor's note along the following lines will be added 'The above text needs to be modified to be clarify that the above solution is a network configuration. '",null,"5.9","Study on 5G security enhancement against false base stations (FS_5GFBS) (Rel-16)",6600,"Revised","2019-03-04T12:04:33.357","2019-03-04T12:23:41.390",null,"S3-190938","Rel-16","33.809","0.2.0","FS_5GFBS"]
["S3-190938","Adding evaluation for Solution #1","Apple Computer Trading Co. Ltd","Shu Guo",76339,"pCR","Approval",null,null,null,"5.9","Study on 5G security enhancement against false base stations (FS_5GFBS) (Rel-16)",6600,"approved",null,null,"S3-190834",null,"Rel-16","33.809","0.2.0","FS_5GFBS"]
["S3-190831","KI#2 in TR 33.809 – updated details (cleanup)","Ericsson","Prajwol Kumar Nakarmi",76183,"pCR","Approval",null,"Qualcomm: Do not understand why non-public networks are mentions. Orange: Do not want the inclusion on the text for non-public network. It was agreed to remove the non-public network text and this results in a couple of new proposed references being not added.",null,"5.9","Study on 5G security enhancement against false base stations (FS_5GFBS) (Rel-16)",6630,"Revised","2019-03-04T11:59:10.147","2019-03-04T13:10:00.747",null,"S3-190939","Rel-16","33.809","0.2.0","FS_5GFBS"]
["S3-190939","KI#2 in TR 33.809 – updated details (cleanup)","Ericsson","Prajwol Kumar Nakarmi",76183,"pCR","Approval",null,"Approved without being seen",null,"5.9","Study on 5G security enhancement against false base stations (FS_5GFBS) (Rel-16)",6630,"approved",null,null,"S3-190831",null,"Rel-16","33.809","0.2.0","FS_5GFBS"]
["S3-190798","Changing the security requirement for KI #2","Qualcomm Incorporated","Adrian Escott",24089,"pCR","Approval",null,"Samsung: Add in all RRC states to the requirements. Ericsson: Change SIBs to SI.",null,"5.9","Study on 5G security enhancement against false base stations (FS_5GFBS) (Rel-16)",6640,"Revised","2019-03-04T11:30:16.520","2019-03-04T14:20:18.463",null,"S3-190940","Rel-16","33.809","0.2.0","FS_5GFBS"]
["S3-190940","Changing the security requirement for KI #2","Qualcomm Incorporated","Adrian Escott",24089,"pCR","Approval",null,"Approved without being seen",null,"5.9","Study on 5G security enhancement against false base stations (FS_5GFBS) (Rel-16)",6640,"approved",null,null,"S3-190798",null,"Rel-16","33.809","0.2.0","FS_5GFBS"]
["S3-190676","Cell Authenticated Access for fake base station detection","Intel Mobile Communications","Abhijeet Kolekar",66157,"pCR",null,null,"Qualcomm: What does a UE do before it has connected the network. Intel: Add an Editor's note to capture this. ZTE: Why is the private key sent to the UE. Intel: This is a mistake and should be removed. Qualcomm: Does ths solution require sharing a private key accross all elements in the network. An editor's note was added related to this. Orange: It is not clear how all the needed keys get provisioned - this is fundamental to the solution. BT:  Won't this introduce a false base station to prevent the UE attaching to real base station by sending broadcast messages with a wrong signature. Orange, DT and Qualcomm felt that  there were too many important issues that are unclear with the solution to accept tht solution at this time.",null,"5.9","Study on 5G security enhancement against false base stations (FS_5GFBS) (Rel-16)",6650,"noted","2019-03-04T06:31:15.640","2019-03-04T11:31:18.923",null,null,"Rel-16","33.809","0.2.0","FS_5GFBS"]
["S3-190832","KI#2 in TR 33.809 – new solution for tamper resistant SI messages","Ericsson","Prajwol Kumar Nakarmi",76183,"pCR","Approval",null,"Orange: Feels that this proposal is similar to the previous one in details. Ericsson: use this solution as a way of gathering the issues on signing message. Intel, Samsung, Interdigital and Apple support the inclusion of contribution. There was discussion on whether there could be a way of capturing the impact of signed SI. There was general agreement that capturing the general issue of signing SIs would provide a mechanism to make progress on the false base station study. A revision was allocated for the creation (probably of an Annex) that will enable studying the impacts of signing broadcats messages. ",null,"5.9","Study on 5G security enhancement against false base stations (FS_5GFBS) (Rel-16)",6660,"Revised","2019-03-04T11:59:10.177","2019-03-04T13:10:00.747",null,"S3-190941","Rel-16","33.809","0.2.0","FS_5GFBS"]
["S3-190941","KI#2 in TR 33.809 – new solution for tamper resistant SI messages","Ericsson","Prajwol Kumar Nakarmi",76183,"pCR","Approval",null,null,null,"5.9","Study on 5G security enhancement against false base stations (FS_5GFBS) (Rel-16)",6660,"approved",null,null,"S3-190832",null,"Rel-16","33.809","0.2.0","FS_5GFBS"]
["S3-190835","Adding evaluation for Solution #2","Apple Computer Trading Co. Ltd","Shu Guo",76339,"pCR","Approval",null,"Orange: this is not a disadvantage as the solution does not claim to solve this issue. Samsung suports this. Ericsson and Apple believe that the disadvantage should be kept. It was proposed to not have an evaluation at this time as there is still a fundamental. The other changes were agreed. ",null,"5.9","Study on 5G security enhancement against false base stations (FS_5GFBS) (Rel-16)",6670,"Revised","2019-03-04T12:06:48.517","2019-03-04T12:23:41.373",null,"S3-190942","Rel-16","33.809","0.2.0","FS_5GFBS"]
["S3-190942","Adding evaluation for Solution #2","Apple Computer Trading Co. Ltd","Shu Guo",76339,"pCR","Approval",null,"Approved without being seen",null,"5.9","Study on 5G security enhancement against false base stations (FS_5GFBS) (Rel-16)",6670,"approved",null,null,"S3-190835",null,"Rel-16","33.809","0.2.0","FS_5GFBS"]
["S3-190865","Evaluation of Solution #2","Samsung","Rajavelsamy Rajadurai",33521,"pCR",null,null,"E//: need to resolve ed note first",null,"5.9","Study on 5G security enhancement against false base stations (FS_5GFBS) (Rel-16)",6680,"noted","2019-03-04T13:38:08.407","2019-03-04T14:03:46.437",null,null,"Rel-16","33.809","0.2.0","FS_5GFBS"]
["S3-190630","5GFBS-solution Using symmetric algorithm with assistance of USIM and home network","ZTE Corporation","Zhenhua Xie",38520,"pCR","Approval",null,"Orange: Which entity is the one who provisions the USIM. ZTE: Visited network provision the USIM. Orange: No way. ZTE: The provisioning procedure can be run be the home netwrok. Interdigital: The initial provisioning well not work.",null,"5.9","Study on 5G security enhancement against false base stations (FS_5GFBS) (Rel-16)",6690,"noted","2019-03-02T01:47:49.370","2019-03-04T11:52:42.023","S3-190155",null,"Rel-16","33.809","0.2.0","FS_5GFBS"]
["S3-190776","Certificate based solution against false base station","Apple Computer Trading Co. Ltd","Shu Guo",76339,"pCR","Approval",null,"Orange, Qualcomm and DT all felt that the solution needs to wait until the new 'Annex' on signature was done.",null,"5.9","Study on 5G security enhancement against false base stations (FS_5GFBS) (Rel-16)",6700,"noted","2019-03-04T11:16:37.237","2019-03-04T12:23:41.407",null,null,"Rel-16","33.809","0.2.0","FS_5GFBS"]
["S3-190833","ID based solution against false base station","Apple Computer Trading Co. Ltd","Shu Guo",76339,"pCR","Approval",null,"Orange, Qualcomm and DT all felt that the solution needs to wait until the new 'Annex' on signature was done.",null,"5.9","Study on 5G security enhancement against false base stations (FS_5GFBS) (Rel-16)",6710,"noted","2019-03-04T12:01:54.810","2019-03-04T12:23:41.373",null,null,"Rel-16","33.809","0.2.0","FS_5GFBS"]
["S3-190866","Solution for AS security during RRC Idle mode","Samsung","Rajavelsamy Rajadurai",33521,"pCR",null,null,"Proposal to update the title and the introduction - this was agreed. Qualcomm: An EN on what happens at Location Update ",null,"5.9","Study on 5G security enhancement against false base stations (FS_5GFBS) (Rel-16)",6730,"Revised","2019-03-04T13:39:13.507","2019-03-04T14:03:46.450",null,"S3-190943","Rel-16","33.809","0.2.0","FS_5GFBS"]
["S3-190943","Solution for AS security during RRC Idle mode","Samsung","Rajavelsamy Rajadurai",33521,"pCR",null,null,null,null,"5.9","Study on 5G security enhancement against false base stations (FS_5GFBS) (Rel-16)",6730,"approved",null,null,"S3-190866",null,"Rel-16","33.809","0.2.0","FS_5GFBS"]
["S3-190635","Updating Key issue #3 for Network detection of nearby false base station","NEC Europe Ltd","Taka Yoshizawa",40702,"pCR","Approval","This contribution proposes an update to key issue #3 in TR 33.809.","Huawei supports the contribution. Ericsson and Qualcomm think that the text is altready covered by KI#4. Some of the proposed text was not included to remove overlap.",null,"5.9","Study on 5G security enhancement against false base stations (FS_5GFBS) (Rel-16)",6740,"Revised","2019-03-03T08:26:35.380","2019-03-04T13:35:51.937",null,"S3-190944","Rel-16","33.809","0.2.0","FS_5GFBS"]
["S3-190944","Updating Key issue #3 for Network detection of nearby false base station","NEC Europe Ltd","Taka Yoshizawa",40702,"pCR","Approval","This contribution proposes an update to key issue #3 in TR 33.809.","Approved without being seen",null,"5.9","Study on 5G security enhancement against false base stations (FS_5GFBS) (Rel-16)",6740,"approved",null,null,"S3-190635",null,"Rel-16","33.809","0.2.0","FS_5GFBS"]
["S3-190825","KI#3 in TR 33.809 - updates to updates to details and threats","Ericsson","Prajwol Kumar Nakarmi",76183,"pCR","Approval",null,"Huawei supports the contribution. ",null,"5.9","Study on 5G security enhancement against false base stations (FS_5GFBS) (Rel-16)",6750,"approved","2019-03-04T11:59:10.100","2019-03-04T13:10:00.717",null,null,"Rel-16","33.809","0.2.0","FS_5GFBS"]
["S3-190826","KI#3 in TR 33.809 - updates to requirements","Ericsson","Prajwol Kumar Nakarmi",76183,"pCR","Approval",null,"The proposal was changed to make it acceptable. ",null,"5.9","Study on 5G security enhancement against false base stations (FS_5GFBS) (Rel-16)",6760,"Revised","2019-03-04T11:59:10.117","2019-03-04T13:10:00.717",null,"S3-190945","Rel-16","33.809","0.2.0","FS_5GFBS"]
["S3-190945","KI#3 in TR 33.809 - updates to requirements","Ericsson","Prajwol Kumar Nakarmi",76183,"pCR","Approval",null,null,null,"5.9","Study on 5G security enhancement against false base stations (FS_5GFBS) (Rel-16)",6760,"approved",null,null,"S3-190826",null,"Rel-16","33.809","0.2.0","FS_5GFBS"]
["S3-190828","KI#3 in TR 33.809 - conclusion on second requirement (reactive action)","Ericsson","Prajwol Kumar Nakarmi",76183,"pCR","Approval",null,"NEC: Not clear why the informtaion can not be supplied to UE - overall too early to introduce. Huawei also believe it is too early to introduce the conclusions.",null,"5.9","Study on 5G security enhancement against false base stations (FS_5GFBS) (Rel-16)",7330,"noted","2019-03-04T11:59:10.130","2019-03-04T13:10:00.730",null,null,"Rel-16","33.809","0.2.0","FS_5GFBS"]
["S3-190654","Notifying cell information to the network after authentication procedure failure","NEC Europe Ltd","Taka Yoshizawa",40702,"pCR","Approval","This contribution proposes a new solution.","Interdigital: Feel that this is an attack scenario on the UE and an EN should be added to include this. Qualcomm: Two Ens are proposed - it is ffs whether cell re-selection finds a cell of the same PLMN and what happens if authentication failure happens in re-selected cell.  Huawei: Would like an EN about step 8 - this was agreed. There were concerns that this signalling does not work as it seems to require new signalling to the home network.",null,"5.9","Study on 5G security enhancement against false base stations (FS_5GFBS) (Rel-16)",7340,"Revised","2019-03-03T09:16:12.387","2019-03-04T13:35:51.887",null,"S3-190998","Rel-16","33.809","0.2.0","FS_5GFBS"]
["S3-190998","Notifying cell information to the network after authentication procedure failure","NEC Europe Ltd","Taka Yoshizawa",40702,"pCR","Approval","This contribution proposes a new solution.","Issue about HPLMN is not resolved. QC: Network based detection so far has been in the serving network. NEC: Will make the solution only apply for the non-roaming case.",null,"5.9","Study on 5G security enhancement against false base stations (FS_5GFBS) (Rel-16)",7340,"Revised",null,null,"S3-190654","S3-191006","Rel-16","33.809","0.2.0","FS_5GFBS"]
["S3-191006","Notifying cell information to the network after authentication procedure failure","NEC Europe Ltd","Taka Yoshizawa",40702,"pCR","Approval","This contribution proposes a new solution.",null,null,"5.9","Study on 5G security enhancement against false base stations (FS_5GFBS) (Rel-16)",7340,"Noted",null,null,"S3-190998",null,"Rel-16","33.809","0.2.0","FS_5GFBS"]
["S3-190674","Notifying cell information to the network when the UE determines that the network fails the authentication procedure","NEC Europe Ltd","Kundan Tiwari",75778,"pCR","Approval","Reporting false base station to the network.",null,null,"5.9","Study on 5G security enhancement against false base stations (FS_5GFBS) (Rel-16)",7760,"withdrawn","2019-03-04T05:18:57.620","2019-03-04T05:28:59.657",null,null,"Rel-16","33.809","0.2.0","FS_5GFBS"]
["S3-190660","Network detection of false base station from UE measurement reports","Nokia","Suresh Nair",70166,"pCR","Approval",null,"Huawei: This can be done with current signalling. Orange: remove the evaulation - this was agreed. Pro-active and instructing the UE are removed. ",null,"5.9","Study on 5G security enhancement against false base stations (FS_5GFBS) (Rel-16)",7930,"Revised","2019-03-03T21:40:13.713","2019-03-04T14:15:53.413",null,"S3-190946","Rel-16","33.809","0.2.0","FS_5GFBS"]
["S3-190946","Network detection of false base station from UE measurement reports","Nokia","Suresh Nair",70166,"pCR","Approval",null,"Approved without beeing seen",null,"5.9","Study on 5G security enhancement against false base stations (FS_5GFBS) (Rel-16)",7930,"approved",null,null,"S3-190660",null,"Rel-16","33.809","0.2.0","FS_5GFBS"]
["S3-190665","Avoiding UE connecting to fake base station during HO","Huawei, Hisilicon","Longhua Guo",80179,"pCR","Approval",null,"An EN saying roughly \"the details of how the UE hands over to the false base station need to be clarified\". It was agreed to delete the evaluation.",null,"5.9","Study on 5G security enhancement against false base stations (FS_5GFBS) (Rel-16)",7980,"Revised","2019-03-04T02:43:14.843","2019-03-04T12:33:33.767",null,"S3-190947","Rel-16","33.809","0.2.0","FS_5GFBS"]
["S3-190947","Avoiding UE connecting to fake base station during HO","Huawei, Hisilicon","Longhua Guo",80179,"pCR","Approval",null,null,null,"5.9","Study on 5G security enhancement against false base stations (FS_5GFBS) (Rel-16)",7980,"approved",null,null,"S3-190665",null,"Rel-16","33.809","0.2.0","FS_5GFBS"]
["S3-190666","Measurement report requirement for the case when the UE in RRC-IDLE & RRC-INACTIVE","Huawei, Hisilicon","Longhua Guo",80179,"pCR","Approval",null,"Merged into S3-190985",null,"5.9","Study on 5G security enhancement against false base stations (FS_5GFBS) (Rel-16)",8250,"merged","2019-03-04T02:43:14.843","2019-03-04T12:33:33.783",null,null,"Rel-16","33.809","0.2.0","FS_5GFBS"]
["S3-190671","Measurement Report Requirement When UE in RRC-CONNECTED","Huawei, Hisilicon","Longhua Guo",80179,"pCR","Approval",null,"Merged into S3-190985",null,"5.9","Study on 5G security enhancement against false base stations (FS_5GFBS) (Rel-16)",8260,"merged","2019-03-04T02:43:14.890","2019-03-04T12:33:33.737",null,null,"Rel-16","33.809","0.2.0","FS_5GFBS"]
["S3-190827","KI#3 in TR 33.809 - new solution for enriched measurement reports","Ericsson","Prajwol Kumar Nakarmi",76183,"pCR","Approval",null,"One EN on UE power consumption will be added and this is merged with S3-190671 and S3-190666",null,"5.9","Study on 5G security enhancement against false base stations (FS_5GFBS) (Rel-16)",8270,"Revised","2019-03-04T11:59:10.117","2019-03-04T13:10:00.730",null,"S3-190985","Rel-16","33.809","0.2.0","FS_5GFBS"]
["S3-190985","KI#3 in TR 33.809 - new solution for enriched measurement reports","Ericsson","Prajwol Kumar Nakarmi",76183,"pCR","Approval",null,null,null,"5.9","Study on 5G security enhancement against false base stations (FS_5GFBS) (Rel-16)",8270,"approved",null,null,"S3-190827",null,"Rel-16","33.809","0.2.0","FS_5GFBS"]
["S3-190733","New requirment for Authentication relay attack","Huawei, Hisilicon","Bo Zhang",49401,"pCR","Approval",null,"Ericsson: Concern that the attack is not so serious and the requirement is too strongly worded. Orange: Proposal for EN - \"There should be means to mitigate the auth realy attack caused by a false base station\".",null,"5.9","Study on 5G security enhancement against false base stations (FS_5GFBS) (Rel-16)",8280,"Revised","2019-03-04T09:32:21.473","2019-03-05T01:21:27.193",null,"S3-190986","Rel-16","33.809","0.2.0","FS_5GFBS"]
["S3-190986","New requirment for Authentication relay attack","Huawei, Hisilicon","Bo Zhang",49401,"pCR","Approval",null,"Approved without being seen",null,"5.9","Study on 5G security enhancement against false base stations (FS_5GFBS) (Rel-16)",8280,"approved",null,null,"S3-190733",null,"Rel-16","33.809","0.2.0","FS_5GFBS"]
["S3-190837","Improvement to key issue #5","ZTE Corporation, Nubia","Jin PENG",49548,"pCR","Approval",null,"Both Orange and Huawei felt that the text was not related to this key issue and hence should not be includeded here. It was possible that there may a different key issue proposed by the text.",null,"5.9","Study on 5G security enhancement against false base stations (FS_5GFBS) (Rel-16)",8290,"noted","2019-03-04T12:18:46.277","2019-03-04T12:28:24.067",null,null,"Rel-16","33.809","0.2.0","FS_5GFBS"]
["S3-190655","Protection of UE configuration against false base station","NEC Europe Ltd","Taka Yoshizawa",40702,"pCR","Approval","This contribution proposes a new solution.","Huawei: UE is attaching to a newtwork for an unauthenticated emergency call and hence does not trust the network. Apple: Needs a key issue to be included. Qualcomm: It is a solution",null,"5.9","Study on 5G security enhancement against false base stations (FS_5GFBS) (Rel-16)",8300,"noted","2019-03-03T09:17:46.583","2019-03-04T13:35:51.903",null,null,"Rel-16","33.809","0.2.0","FS_5GFBS"]
["S3-190673","Handling of UE configuration update by a fake base station","NEC Europe Ltd","Kundan Tiwari",75778,"pCR","Approval","Protecting UE configuration from false base station.",null,null,"5.9","Study on 5G security enhancement against false base stations (FS_5GFBS) (Rel-16)",8310,"withdrawn","2019-03-04T05:13:19.653","2019-03-04T05:28:59.657",null,null,"Rel-16","33.809","0.2.0","FS_5GFBS"]
["S3-190734","New solution for Authentication relay attack","Huawei, Hisilicon","Bo Zhang",49401,"pCR","Approval",null,"Lenovo: Victum UE and malicious UE need to be in the same PLMN. Ericsson and Samsung: Proposed EN \"Details of how UE location info is used and granularity and secured from false base station attack . Samsung: EN proposal \"How the UE obtains the location is FFS\".  \"Qualcomm: Proposal for EN \"How the solution addresses already registered UE is FFS\" . BT: Need to take privacy aspects into account - an EN was added. ",null,"5.9","Study on 5G security enhancement against false base stations (FS_5GFBS) (Rel-16)",8320,"Revised","2019-03-04T09:32:21.490","2019-03-04T10:21:44.817",null,"S3-190987","Rel-16","33.809","0.2.0","FS_5GFBS"]
["S3-190987","New solution for Authentication relay attack","Huawei, Hisilicon","Bo Zhang",49401,"pCR","Approval",null,null,null,"5.9","Study on 5G security enhancement against false base stations (FS_5GFBS) (Rel-16)",8320,"approved",null,null,"S3-190734",null,"Rel-16","33.809","0.2.0","FS_5GFBS"]
["S3-190838","Detection of false relay base station by UE","ZTE Corporation, Nubia","Jin PENG",49548,"pCR","Approval",null,"There was lost of discussion on whether the proposed solution work as described and it was also not clear how it fitted the key issue",null,"5.9","Study on 5G security enhancement against false base stations (FS_5GFBS) (Rel-16)",8330,"noted","2019-03-04T12:18:46.277","2019-03-04T12:28:24.067",null,null,"Rel-16","33.809","0.2.0","FS_5GFBS"]
["S3-190870","Solution on Authentication Relay Attack","Lenovo, Motorola Mobility","Andreas Kunz",72589,"pCR","Approval","This paper provides a solution on key issue Key Issue #5: Mitigation against the authentication relay attack.","This was merged into S3-190987",null,"5.9","Study on 5G security enhancement against false base stations (FS_5GFBS) (Rel-16)",8340,"merged","2019-03-04T13:52:07.583","2019-03-04T14:29:22.967",null,null,"Rel-16","33.809","0.2.0","FS_5GFBS"]
["S3-190663","Propose a new KI and security requirement for spoofing paging messages","Huawei, Hisilicon","Longhua Guo",80179,"pCR","Approval",null,"NEC: Do not feel that there is a legitimate security threat here. Ericsson: Have sympathy for the NEC view. Orange: do not agree with key issue being accepted",null,"5.9","Study on 5G security enhancement against false base stations (FS_5GFBS) (Rel-16)",8350,"noted","2019-03-04T02:43:14.810","2019-03-04T12:33:33.767",null,null,"Rel-16","33.809","0.2.0","FS_5GFBS"]
["S3-190664","Protection for Incoming Paging Message Based on Stored Security Context","Huawei, Hisilicon","Longhua Guo",80179,"pCR","Approval",null,"Related key issue was not accepted ",null,"5.9","Study on 5G security enhancement against false base stations (FS_5GFBS) (Rel-16)",8370,"noted","2019-03-04T02:43:14.827","2019-03-04T12:33:33.767",null,null,"Rel-16","33.809","0.2.0","FS_5GFBS"]
["S3-190675","Key Issue for Fake Base Station","Intel Mobile Communications","Abhijeet Kolekar",66157,"pCR",null,null,"It was felt that the proposals in this key issue are already covered by another contribution",null,"5.9","Study on 5G security enhancement against false base stations (FS_5GFBS) (Rel-16)",8380,"noted","2019-03-04T06:28:21.697","2019-03-04T11:31:18.907",null,null,"Rel-16","33.809","0.2.0","FS_5GFBS"]
["S3-190793","Protection against Man-in-the-Middle false base station attacks","Qualcomm Incorporated","Adrian Escott",24089,"pCR","Approval",null,"Huwaei proposed to make the requirement a should - this was not accepted. Ericsson: Do not want to accept the requirement. This view was support by Samsung and NEC. The key issue details and security requirements were not challenged. Discussion on the requirement was taken offline.",null,"5.9","Study on 5G security enhancement against false base stations (FS_5GFBS) (Rel-16)",8650,"Revised","2019-03-04T11:30:16.367","2019-03-04T14:20:18.450","S3-190381","S3-190988","Rel-16","33.809","0.2.0","FS_5GFBS"]
["S3-190988","Protection against Man-in-the-Middle false base station attacks","Qualcomm Incorporated","Adrian Escott",24089,"pCR","Approval",null,"Ericsson: want to note the document as it is an evaluation contribution. Orange: Support the contribution. The discussion was concluded by agreeing to have no security requirement as this meeting. ",null,"5.9","Study on 5G security enhancement against false base stations (FS_5GFBS) (Rel-16)",8650,"Revised",null,null,"S3-190793","S3-191021","Rel-16","33.809","0.2.0","FS_5GFBS"]
["S3-191021","Protection against Man-in-the-Middle false base station attacks","Qualcomm Incorporated","Adrian Escott",24089,"pCR","Approval",null,"Approved without being seen",null,"5.9","Study on 5G security enhancement against false base stations (FS_5GFBS) (Rel-16)",8650,"Approved",null,null,"S3-190988",null,"Rel-16","33.809","0.2.0","FS_5GFBS"]
["S3-190830","New annex in TR 33.809 - summary of PWS security study","Ericsson","Prajwol Kumar Nakarmi",76183,"pCR","Approval",null,"There was much dicsussion on whether to include the conclusion from PWS study in the FBS TR. ",null,"5.9","Study on 5G security enhancement against false base stations (FS_5GFBS) (Rel-16)",8660,"Noted","2019-03-04T11:59:10.130","2019-03-04T13:10:00.747",null,null,"Rel-16","33.809","0.2.0","FS_5GFBS"]
["S3-190989","References to TR 33.809","BT","Colin",null,"pCR","Approval",null,"There will be reference to the previous work in the introduction. Orange was objecting to the approval of the document but this was sufficient support for approval.",null,"5.9","Study on 5G security enhancement against false base stations (FS_5GFBS) (Rel-16)",8660,"approved"]
["S3-190636","Solution for preventing UE camping on false base station during Idle mode","NEC Europe Ltd","Taka Yoshizawa",40702,"pCR","Approval","This contribution proposes a solution for preventing UE from camping on false base station.",null,null,"5.9","Study on 5G security enhancement against false base stations (FS_5GFBS) (Rel-16)",8700,"withdrawn","2019-03-03T08:29:45.457",null,null,null,"Rel-16","33.809","0.2.0","FS_5GFBS"]
["S3-190960","new draft TR 33.809","Apple Computer Trading Co. Ltd",null,null,"draft TR","Approval",null,"For e-mail approval",null,"5.9","Study on 5G security enhancement against false base stations (FS_5GFBS) (Rel-16)",8700,"not concluded"]
["S3-190612","Work Plan input from Rapporteurs","WG Vice Chairs","Mirko Cano Soveri",41957,"other",null,null,null,null,"6","Any Other Business",6120,"Revised","2019-02-25T02:19:43.087","2019-02-25T02:21:44.167",null,"S3-191035"]
["S3-191035","Work Plan input from Rapporteurs","WG Vice Chairs","Mirko Cano Soveri",41957,"other",null,null,null,null,"6","Any Other Business",6120,"approved",null,null,"S3-190612"]
[null,null,null,null,null,null,null,null,"email approval -> doc available 4pm CET 18th March -> comments by 4pm CET 20th March -> final version by 4pm CET 21st March -> approval by 4pm CET 22nd March "]

{"sheet":"CR_Packs_List","index":1,"n_rows":1,"n_cols":11,"rows_kept":1,"cut":false,"hidden":false,"merged":[]}
["CR Pack TDoc","WG Tdoc","WG TDoc decision","CR Individual TSG decision","Spec","CR","CR revision","CR category","Release","Version","CR title"]

{"sheet":"Parameters","index":2,"n_rows":25,"n_cols":4,"rows_kept":25,"cut":false,"hidden":true,"merged":[]}
["Types of Tdocs","Possible statuses of Tdocs","Categories"]
[]
["agenda","reserved","A","Decision"]
["Work Plan","available","B","Agreement"]
["LS in","revised","C","Approval"]
["LS out","agreed","D","Information"]
["pCR","conditionally agreed","E","Discussion"]
["draftCR","approved","F","Action"]
["CR","conditionally approved",null,"Endorsement"]
["CR pack","partially approved",null,"Presentation"]
["ToR","treated"]
["WID new","endorsed"]
["WID revised","replied to"]
["SID new","merged"]
["SID revised","not pursued"]
["WI status report","postponed"]
["WI exception request","noted"]
["TS or TR cover","not concluded"]
["draft TS","withdrawn"]
["draft TR","reissued"]
["report","not treated"]
["discussion"]
["response"]
["other"]
["WI summary"]