Tdoc List

2019-04-09 14:58

Agenda Topic TDoc Title Source Type For Avail Treated Decision Wdrn Replaced-by Replaces
1 Opening of the meeting                      
2 Approval of Agenda and Meeting Objectives S3‑190600 Agenda WG Vice Chair agenda   Yes
YesRevised to correct editorial and add proposed schedule. Ericsson provided a welcome presentation. Chair reminded everyone of IT being a shared facility. Chair provided IPR policy and a reminder of the anti-trust issues.
revised No S3‑190921  
    S3‑190921 Agenda WG Vice Chair agenda - Yes
Yes
approved No   S3‑190600
3 IPR and Anti-Trust Law Reminder                      
4 Work Areas                      
4.1 Security Assurance Specification for 5G (SCAS_5G) (Rel-16)                      
4.1.1 NR Node B (gNB) (TS 33.511)                      
4.1.2 Access and Mobility Management Function (TS 33.512) S3‑190740 SCAS: AMF-specific adaptations of security functional requirements and related test cases Huawei, Hisilicon pCR Approval Yes
YesIt 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.
revised No S3‑190884  
    S3‑190884 SCAS: AMF-specific adaptations of security functional requirements and related test cases Huawei, Hisilicon pCR Approval Yes
Yes
approved No   S3‑190740
    S3‑190887 Draft TS 33.512 Deutsche Telekom draft TS Approval Yes
Yes
approved No    
4.1.3 User Plane Function (UPF) (TS 33.513) S3‑190741 Security Assurance Requirements and Test Case for UPF Huawei, Hisilicon pCR Approval Yes
YesIt 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.
revised No S3‑190885  
    S3‑190885 Security Assurance Requirements and Test Case for UPF Huawei, Hisilicon pCR Approval Yes
Yes
approved No   S3‑190741
    S3‑190886 ecurity Assurance Requirements and Test Case for UPF- Reference to 33.250 Huawei, Hisilicon pCR Approval Yes
Yes
approved No    
    S3‑190888 Draft TS 33.513 Samsung draft TS Approval Yes
Yes
approved No    
4.1.4 Unified Data Management (UDM) (TS 33.514)                      
4.1.5 Session Management Function (SMF) (TS 33.515) S3‑190743 Security Assurance Requirement and test cases for SMF Huawei, Hisilicon pCR Approval Yes
YesThere 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.
revised No S3‑190889  
    S3‑190889 Security Assurance Requirement and test cases for SMF Huawei, Hisilicon pCR Approval Yes
Yes
approved No   S3‑190743
    S3‑190890 draft TS 33.515 Huawei draft TS Approval Yes
Yes
approved No    
4.1.6 Authentication Server Function (AUSF) (TS 33.516)                      
4.1.7 Security Edge Protection Proxy (SEPP) (TS 33.517) S3‑190637 New Test Case: Error handling of malformed N32 signalling message sent between peer SEPPs NEC Europe Ltd pCR Approval Yes
YesNot 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
noted No    
    S3‑190728 Test Case: Connection-specific scope of IPX-provider cryptographic material Deutsche Telekom AG pCR Approval Yes
YesIt 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.
revised No S3‑190891  
    S3‑190891 Test Case: Connection-specific scope of IPX-provider cryptographic material Deutsche Telekom AG pCR Approval Yes
Yes
approved No   S3‑190728
    S3‑190780 SCAS SEPP: Serving PLMN ID Mismatch Nokia, Nokia Shanghai Bell pCR Approval Yes
YesIt 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.
revised No S3‑190892  
    S3‑190892 SCAS SEPP: Serving PLMN ID Mismatch Nokia, Nokia Shanghai Bell pCR Approval Yes
Yes
approved No   S3‑190780
    S3‑190893 Draft TS 33.517 Nokia draft TS Approval Yes
Yes
approved No    
4.1.8 Network Resource Function (NRF) (TS 33.518) S3‑190742 Security Assurance Requirement and Test for NRF Huawei, Hisilicon pCR Approval Yes
YesIt 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.
revised No S3‑190978  
    S3‑190978 Security Assurance Requirement and Test for NRF Huawei, Hisilicon pCR Approval Yes
YesNokia: 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.
noted No   S3‑190742
    S3‑190805 SCAS NRF: Scope Representation for Nnrf_AccessToken Service Nokia, Nokia Shanghai Bell pCR Approval Yes
YesIt 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.
noted No    
4.1.9 Network Exposure Function (NEF) (TS 33.519) S3‑190618 SCAS NEF Add test steps for authorization on northbound APIs ZTE Corporation pCR Approval Yes
YesThe 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.
revised No S3‑190894  
    S3‑190894 SCAS NEF Add test steps for authorization on northbound APIs ZTE Corporation pCR Approval Yes
Yes
approved No   S3‑190618
    S3‑190895 draft TS 33.519 ZTE draft TS Approval Yes
Yes
approved No    
4.1.10 Other issues S3‑190638 New Test Case: Error handling of malformed JSON object between two network products NEC Europe Ltd pCR Approval Yes
YesWhat is meant be malformed as if it general, then there could be a test for malformed JSON objects.
noted No    
    S3‑190672 Living Document: General SBA/SBI aspects in TS 33.117 Nokia, Nokia Shanghai Bell draftCR Approval Yes
Yes
revised No S3‑190897  
    S3‑190897 Living Document: General SBA/SBI aspects in TS 33.117 Nokia, Nokia Shanghai Bell draftCR Approval Yes
Yes
approved No   S3‑190672
    S3‑190749 The purpose and scope of SCAS Ericsson discussion Endorsement Yes
YesIt was commented 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.
revised No S3‑190883  
    S3‑190883 The purpose and scope of SCAS Ericsson discussion Endorsement Yes
Yes
endorsed No   S3‑190749
    S3‑190775 SCAS 5G: mutual authentication between NFs Nokia, Nokia Shanghai Bell draftCR Approval Yes
YesThe 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.
revised No S3‑190896  
    S3‑190896 SCAS 5G: mutual authentication between NFs Nokia, Nokia Shanghai Bell draftCR Approval Yes
Yes
approved No   S3‑190775
    S3‑190777 SCAS 5G: update to Access Token Verification Failure in non-roaming case Nokia, Nokia Shanghai Bell draftCR Approval Yes
Yes
approved No    
    S3‑190778 SCAS 5G: update to Access Token Verification Failure in roaming case Nokia, Nokia Shanghai Bell draftCR Approval Yes
Yes
approved No    
    S3‑190779 SCAS 5G: Search Result Handling for NF Discovery Nokia, Nokia Shanghai Bell draftCR Approval Yes
YesNo support for this contribution.
noted No    
5 Studies                      
5.1 Study on Security Aspects of the 5G Service Based Architecture (FS_SBA-Sec) (Rel-16) S3‑190744 New Key Issue: Support of a UP gateway function on the N9 interface Ericsson pCR Approval Yes
YesNokia: 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.
revised No S3‑190964  
    S3‑190964 New Key Issue: Support of a UP gateway function on the N9 interface Ericsson pCR Approval Yes
Yesadd EN: N9 requirements go into a separate clause.
approved No   S3‑190744
    S3‑190737 New KI: flexible protection of data exchange on N9 Huawei, Hisilicon pCR Approval Yes
YesJuniper: 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 …
revised No S3‑190965  
    S3‑190965 New KI: flexible protection of data exchange on N9 Huawei, Hisilicon,Nokia pCR Approval Yes
Yes
approved No   S3‑190737
    S3‑190876 Protection of N9 interface in Inter-PLMN scenario Nokia, Nokia Shanghai Bell pCR Approval Yes
YesJuniper: 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.
merged No S3‑190965  
    S3‑190869 Security aspects of Service Communication Proxy (SCP) Nokia, Nokia Shanghai Bell pCR Approval Yes
Yestogether with 726 , merged into 967 and 968
revised No S3‑190967  
    S3‑190967 Security aspects of Service Communication Proxy (SCP) Nokia, Nokia Shanghai Bell,Deutsche Telekom pCR Approval Yes
Yes
approved No   S3‑190869
    S3‑190726 Key Issue: Protection of SCP interfaces Deutsche Telekom AG pCR Approval Yes
Yes
merged No S3‑190967  
    S3‑190727 Key Issue: Secure message transport via the SCP Deutsche Telekom AG pCR Approval Yes
YesE//: need to merge these. Two issues. Requirements: system shall support. On 727: reference should be checked. not refer to NDS/IP
revised No S3‑190968  
    S3‑190968 Key Issue: Secure message transport via the SCP Deutsche Telekom AG pCR Approval Yes
Yes
approved No   S3‑190727
    S3‑190871 NF to NF authenticaton and authorization in Indirect communication mode Nokia, Nokia Shanghai Bell pCR Approval Yes
YesE//: could be merged to 727. bullet B may no longer be possible DCM: SCoP defines a trust domain. Keep open
revised No S3‑190981  
    S3‑190981 NF to NF authenticaton and authorization in Indirect communication mode Nokia, Nokia Shanghai Bell pCR Approval Yes
Yes
approved No   S3‑190871
    S3‑190872 Authorization of NF service access in SCP Nokia, Nokia Shanghai Bell pCR Approval Yes
YesDT: auth is in SA3 domain, remove second para. E//: check offline about authorization. Third paragraph depends on second para. Nokia: take this offline
revised No S3‑190980  
    S3‑190980 Authorization of NF service access in SCP Nokia, Nokia Shanghai Bell pCR Approval Yes
Yes
approved No   S3‑190872
    S3‑190874 Service access authorization within a NF Set or NF Service Set Nokia, Nokia Shanghai Bell pCR Approval Yes
YesE//: 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.
revised No S3‑190982  
    S3‑190982 Service access authorization within a NF Set or NF Service Set Nokia, Nokia Shanghai Bell pCR Approval Yes
Yes
approved No   S3‑190874
    S3‑190873 Indirect communication between NFs in roaming scenarios Nokia, Nokia Shanghai Bell pCR Approval Yes
YesE//: remove "something similar…", as it is solution. DCM: this is architecural requirement. Interoperability with R15.
revised No S3‑190983  
    S3‑190983 Indirect communication between NFs in roaming scenarios Nokia, Nokia Shanghai Bell pCR Approval Yes
Yes
approved No   S3‑190873
    S3‑190724 Draft LS on SCP security requirements Deutsche Telekom AG LS out Approval Yes
YesTNO: is the SCP already decided? DCM: SA2 decided
merged No S3‑190963  
    S3‑190725 Key Issue: Handling of invalid IPX patches Deutsche Telekom AG pCR Approval Yes
YesDCM: ed note: whether to really do per error cause and per N32 connection is FFS
revised No S3‑190984  
    S3‑190984 Key Issue: Handling of invalid IPX patches Deutsche Telekom AG pCR Approval Yes
Yes
approved No   S3‑190725
    S3‑190879 TLMSP, A Proxy Transport Layer Secure Protocol NCSC other Discussion Yes
Yescomments to be given offline
noted No    
    S3‑190966 LS on Clarification of flexibility of N9 protection Deutsche Telekom LS out Approval Yes
Yesask 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.
revised No S3‑191016  
    S3‑191016 LS on Clarification of flexibility of N9 protection Deutsche Telekom LS out Approval Yes
Yes
approved No   S3‑190966
    S3‑190961 LS on handling of Indirect communication across NF/NF Services S2-1902905 LS in Approval Yes
YesDCM: SCP bad acronym. May need two SCPs one for consumer and for producer DT: have proposal regarding visisbility in architecture
replied to No    
    S3‑190963 Reply LS on handling of Indirect communication across NF/NF Services Deutsche Telekom LS out Approval Yes
Yes
approved No    
    S3‑191031 Draft TR 33.855 Deutsche Telekom draft TR Approval Yes
Yes
approved No    
5.2 Study on Long Term Key Update Procedures (FS_LTKUP) (Rel-16)                      
5.3 Study on Supporting 256-bit Algorithms for 5G (FS_256-Algorithms) (Rel-16)                      
5.4 Security aspects of single radio voice continuity from 5G to UTRAN (FS_5G_UTRAN_SEC) (Rel-16)                      
5.5 Study on authentication and key management for applications based on 3GPP credential in 5G IoT (FS_AKMA) (Rel-16) S3‑190750 New KI: Interworking between AKMA and GBA Ericsson pCR Approval Yes
YesVdf: 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.
noted No    
    S3‑190922 New KI: Interworking between AKMA and GBA Ericsson pCR Approval No
Yes
withdrawn Yes    
    S3‑190640 Discussion on use of established keys for AKMA root key NEC Europe Ltd discussion Discussion Yes
YesVdf: 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.
noted No    
    S3‑190646 New KI on Synchronization of Keys when using established keys NEC Europe Ltd pCR Approval Yes
Yes
approved No    
    S3‑190702 Key issue on Key freshness in AKMA Huawei, Hisilicon pCR Approval Yes
Yes
revised No S3‑190924  
    S3‑190924 Key issue on Key freshness in AKMA Huawei, Hisilicon pCR Approval Yes
Yes
approved No   S3‑190702
    S3‑190824 Updates to KI #14 Ericsson pCR Approval Yes
YesQualcomm: 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.
revised No S3‑190925  
    S3‑190925 Updates to KI #14 Ericsson pCR Approval Yes
Yes
approved No   S3‑190824
    S3‑190613 New Solution: Battery efficient AKMA KPN N.V. pCR Approval Yes
YesIt 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.
revised No S3‑190926  
    S3‑190926 New Solution: Battery efficient AKMA KPN N.V. pCR Approval Yes
Yes
approved No   S3‑190613
    S3‑190632 Solution to KI#9 Key separation for AKMA AFs NEC Europe Ltd pCR Approval Yes
YesBT: Add an EN about further key separation to prevent key leakage causing an issue for other cases.
revised No S3‑190927  
    S3‑190927 Solution to KI#9 Key separation for AKMA AFs NEC Europe Ltd pCR Approval Yes
Yes
approved No   S3‑190632
    S3‑190801 pCR: Reusing KAUSF for AKMA Qualcomm Incorporated pCR Approval Yes
YesNEC: 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.
revised No S3‑190928 S3‑190385
    S3‑190928 pCR: Reusing KAUSF for AKMA Qualcomm Incorporated pCR Approval Yes
Yes
approved No   S3‑190801
    S3‑190639 Solution for Established Key Synchronization NEC Europe Ltd pCR Approval Yes
YesVdf: 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.
revised No S3‑190929  
    S3‑190929 Solution for Established Key Synchronization NEC Europe Ltd pCR Approval Yes
Yes
approved No   S3‑190639
    S3‑190642 Resolving Editor’s Notes in Solution #16 NEC Europe Ltd pCR Approval Yes
Yes
approved No    
    S3‑190641 Discussion on using KSEAF and/or KAUSF for AKMA in view of regulatory compliance NEC Europe Ltd discussion Discussion Yes
YesOrange: 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
noted No    
    S3‑190644 Updating solution #16 to include home network option NEC Europe Ltd pCR Approval Yes
YesDCM: 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.
revised No S3‑190930  
    S3‑190930 Updating solution #16 to include home network option NEC Europe Ltd pCR Approval Yes
Yes
approved No   S3‑190644
    S3‑190645 Creating a combined solution for usage of KSEAF and KAUSF NEC Europe Ltd pCR Approval Yes
YesKept open based on the discussion of S3-190930 -
revised No S3‑190996  
    S3‑190996 Creating a combined solution for usage of KSEAF and KAUSF NEC Europe Ltd pCR Approval Yes
Yes
approved No   S3‑190645
    S3‑190643 Solution for Roaming Architecture NEC Europe Ltd pCR Approval Yes
YesOrange: 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.
noted No    
    S3‑190688 improvement for AKMA architecture Huawei, HiSilicon pCR Approval Yes
YesGemalto: What is the rationale for the proxy
noted No    
    S3‑190703 Solution for Key freshness in AKMA Huawei, Hisilicon pCR Approval Yes
YesOrange: 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
revised No S3‑191005  
    S3‑191005 Solution for Key freshness in AKMA Huawei, Hisilicon pCR Approval Yes
Yes
approved No   S3‑190703
    S3‑190767 AKMA Architecture and procedures with the anchor function as NEF China Mobile Com. Corporation pCR   Yes
YesOrange: It is not clear what the solution is proposing. The reasons for co-locating the NEF and AApF are not justified
noted No    
    S3‑190774 Resolving Editor's notes in solution 6 China Mobile Com. Corporation pCR   Yes
YesE//: 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.
revised No S3‑190931  
    S3‑190931 Resolving Editor's notes in solution 6 China Mobile Com. Corporation pCR - Yes
Yes
approved No   S3‑190774
    S3‑190807 Protocol details for solution 3 Ericsson pCR Approval Yes
Yes
approved No    
    S3‑190821 Updates to Solution #14 Ericsson pCR Approval Yes
YesVF: 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.
noted No    
    S3‑190823 New Solution Key Lifetime Ericsson pCR Approval Yes
YesVF: 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.
noted No    
    S3‑190836 Modification of user identity in solution 2 and solution 3 ZTE Corporation, Nubia pCR Approval Yes
YesOrange: it is not user identity but SUPI, or potentially SUCI. Propose to note, consider this globally. QC: agree with Orange.
noted No    
    S3‑190842 Solution 15 editorials Ericsson pCR Approval Yes
YesQC: 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.
revised No S3‑190932  
    S3‑190932 Solution 15 editorials Ericsson pCR Approval Yes
Yes
approved No   S3‑190842
    S3‑190843 Solution 15 comment on the application keys Ericsson pCR Approval Yes
YesC: K should be K_NAF in GBA. VF: needs Englishification. TS describes. Discussed offline.
revised No S3‑190933  
    S3‑190933 Solution 15 comment on the application keys Ericsson pCR Approval Yes
Yes
approved No   S3‑190843
    S3‑190701 Evaluation of solution 4 Huawei, Hisilicon pCR Approval Yes
YesVF: 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
noted No    
    S3‑190806 Evaluation of solution 2 Ericsson pCR Approval Yes
YesVF: 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
noted No    
    S3‑190808 Evaluation of solution 3 Ericsson pCR Approval Yes
Yes
noted No    
    S3‑190822 Conclusion to Solution #14 Ericsson pCR Approval Yes
YesOrange: still ed notes in solution, so note
noted No    
    S3‑190844 Solution 15 evaluation Ericsson pCR Approval Yes
Yeschange 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. NEC supports keeping conclusion, Apple as well. VF: second para deleted due to preference for one option. Orange: last paragraph, remove last part.
revised No S3‑190935  
    S3‑190935 Solution 15 evaluation Ericsson pCR Approval Yes
Yes
approved No   S3‑190844
    S3‑190923 draft TR 33.835 China Mobile draft TR Approval Yes
Yes
approved No    
    S3‑190934 Way forward on evaluations for FS_AKMA ORANGE discussion Endorsement Yes
Yes
endorsed No    
5.6 Study on evolution of Cellular IoT security for the 5G System (FS_CIoT_sec_5G) (Rel-16) S3‑190611 Reply LS on authentication of group of IoT devices S1-190501 LS in   Yes
YesNot in scope of this meeting - postponed to next SA3 plenary
postponed No    
    S3‑190784 Acknowledging the multiple possible mobility solutions for CP small data Qualcomm Incorporated pCR Approval Yes
Yes
approved No    
    S3‑190815 Evaluation to Solution #3 ‘Security solution for MO SMS at AMF re-allocation’ Ericsson pCR Approval Yes
Yes
approved No    
    S3‑190816 Evaluation to Solution #4 ‘Security solution for UL small data transfer in RRC Suspend and Resume with early data transmission (EDT)’ Ericsson pCR Approval Yes
YesHuawei: There are RAN issues with EDT, so propose to note
noted No    
    S3‑190817 Evaluation to Solution #5 ‘Security solution for small data included in initial NAS signalling at mobility’ Ericsson pCR Approval Yes
Yes
approved No    
    S3‑190614 Update of Solution #6 – Use of UE Configuration Update KPN N.V. pCR Approval Yes
YesOrange: 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
noted No    
    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 pCR Approval Yes
YesOrange: If it is left for implementation, then how does your solution work. Need text like thresholds are supported, values are for configuarations.
revised No S3‑191025  
    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 pCR Approval Yes
YesCheck with orange and then approved without being further seen
approved No   S3‑190661
    S3‑190662 Delete the EN related to the “AttackInformationNotification” message Huawei, Hisilicon pCR Approval Yes
YesEricsson: Can one UE sabotage the context of another UE by replaying a message. The discussion related to evaluation and will be brought later
approved No    
    S3‑190792 Security protection of small data at idle mode mobility Qualcomm Incorporated pCR Approval Yes
Yes
approved No    
    S3‑190800 Adding an evaluation to solution #9 in TR 33.861 Qualcomm Incorporated pCR Approval Yes
YesHuawei: Add EN on whether small data goes in Reg Request
revised No S3‑191032  
    S3‑191032 Adding an evaluation to solution #9 in TR 33.861 Qualcomm Incorporated pCR Approval Yes
Yes
approved No   S3‑190800
    S3‑190785 Resolving the editor’s note in solution #10 in TR 33.861 Qualcomm Incorporated pCR Approval Yes
Yes
approved No    
    S3‑190786 Adding an evaluation to solution #10 in TR 33.861 Qualcomm Incorporated pCR Approval Yes
YesHuawei: Add EN on whether small data goes in Reg Request
revised No S3‑191033  
    S3‑191033 Adding an evaluation to solution #10 in TR 33.861 Qualcomm Incorporated pCR Approval Yes
Yes
approved No   S3‑190786
    S3‑190717 Update to solution#12"DDoS attack mitigation in CIoT" Huawei, Hisilicon pCR Approval Yes
Yes
approved No    
    S3‑190603 Solution proposal for FS_CIoT_sec_5G key issue #1 and #2 Philips International B.V. pCR Approval Yes
YesHuawei: 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.
revised No S3‑191027  
    S3‑191027 Solution proposal for FS_CIoT_sec_5G key issue #1 and #2 Philips International B.V. pCR Approval Yes
Yes
approved No   S3‑190603
    S3‑190704 Solution to identify misbehaving UEs Huawei, Hisilicon pCR Approval Yes
YesOrange: 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
revised No S3‑191028  
    S3‑191028 Solution to identify misbehaving UEs Huawei, Hisilicon pCR Approval Yes
Yes
approved No   S3‑190704
    S3‑190705 Solution to Migitate DDoS Attack based on RAN Huawei, Hisilicon pCR Approval Yes
YesEricsson: 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
revised No S3‑191029  
    S3‑191029 Solution to Migitate DDoS Attack based on RAN Huawei, Hisilicon pCR Approval Yes
Yes
approved No   S3‑190705
    S3‑190706 Conclusion for KDF negotiation for 5G System Security Huawei, Hisilicon pCR Approval No
Yes
revised No S3‑190723  
    S3‑191026 draft TR 33.861 Ericsson draft TR Approval Yes
Yes
approved No    
5.7 Study on the security of the Wireless and Wireline Convergence for the 5G system architecture (FS_5WWC_SEC) (Rel-16) S3‑190745 New KI: N3GPP Key Hierarchy Ericsson pCR Approval Yes
YesHuawei: 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
revised No S3‑191012  
    S3‑191012 New KI: N3GPP Key Hierarchy Ericsson pCR Approval Yes
Yes
approved No   S3‑190745
    S3‑190746 New Solution: New access type distinguisher for N3GPP Ericsson pCR Approval Yes
YesTIM: what is meant by optional.E//: evaluation can go away. Huawei: solution not needed
noted No    
    S3‑190747 New Solution: Key separation for untrusted and trusted access Ericsson pCR Approval Yes
YesSame 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.
revised No S3‑191030  
    S3‑191030 New Solution: Key separation for untrusted and trusted access Ericsson pCR Approval Yes
Yes
approved No   S3‑190747
    S3‑190748 New Solution: SUCI deconcealment for the FN-RG Ericsson pCR Approval Yes
YesHuawei: 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.
noted No    
    S3‑190877 Mobility between TNAPs within the Trusted Non-3GPP Access Network (TNAN) Nokia, Nokia Shanghai Bell pCR Approval Yes
YesZTE: 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
revised No S3‑191013  
    S3‑191013 Mobility between TNAPs within the Trusted Non-3GPP Access Network (TNAN) Nokia, Nokia Shanghai Bell pCR Approval Yes
Yes
approved No   S3‑190877
    S3‑190878 Mobility between TNGFs within the Trusted Non-3GPP Access Network (TNAN) Nokia, Nokia Shanghai Bell pCR Approval Yes
YesZTE: same question as 877, add same ed note. Orange: is this architecture agreed? Nokia: yes.
revised No S3‑191014  
    S3‑191014 Mobility between TNGFs within the Trusted Non-3GPP Access Network (TNAN) Nokia, Nokia Shanghai Bell pCR Approval Yes
Yes
approved No   S3‑190878
    S3‑190710 Add content to Introduction clause Huawei, Hisilicon pCR Approval Yes
YesNokia: editorials. Ed note: needs to be fixed. Orange: not in this shape. Issues with roaming. Take it next meeting.
noted No    
    S3‑190709 Add content to section 4 Huawei, Hisilicon pCR Approval Yes
YesOrange: same issues. Work for next meeting. Start email discussion on these topics.
noted No    
    S3‑190713 Delete EN for solution #3 Huawei, Hisilicon pCR Approval Yes
YesNokia: 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.
noted No    
    S3‑190714 Add evaluation to solution #3 Huawei, Hisilicon pCR Approval Yes
Yesrelated to previous, Huawei proposes to note this and the 715, 716 and 712
noted No    
    S3‑190715 Delete EN for solution 5 Huawei, Hisilicon pCR Approval Yes
Yes
withdrawn Yes    
    S3‑190716 Add evaluation to soluiton 5 Huawei, Hisilicon pCR Approval Yes
Yes
withdrawn Yes    
    S3‑190712 Conclusion on KI#1 Huawei, Hisilicon pCR Approval Yes
Yes
withdrawn Yes    
    S3‑190875 Removal of Editor’s Note in Solution#6 Lenovo, Motorola Mobility pCR Approval Yes
Yes
noted No    
    S3‑190711 Add content to section 4 Huawei, Hisilicon pCR Approval No
Yes
withdrawn Yes    
    S3‑191015 draft TR 33.807 Huawei draft TR Approval Yes
Yes
approved No    
5.8 Study on Security Aspects of PARLOS (FS_PARLOS_Sec) (Rel-16) S3‑190615 False base station key issue for RLOS P-CR SPRINT Corporation pCR Agreement Yes
YesOrange & QC: Don't feel that this key issue is appropriate - this may be brought back but would need requirements
noted No    
    S3‑190616 Reduced confidentiality protection key issue for RLOS P-CR SPRINT Corporation pCR Agreement Yes
YesEricsson: very similar key issue already. Orange: Not clear can be solved. QC: Not clear this is a suitable key issue.
noted No    
    S3‑190617 Fraud controls bypassed key issue for RLOS P-CR SPRINT Corporation pCR Agreement Yes
YesOrange: 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
noted No    
    S3‑190781 Proposed evaluation for Solution #1 AS and NAS security for RLOS services Qualcomm Incorporated pCR Approval Yes
YesAdd EN about further evaluation if further key issues. Remove emergencey calls .
revised No S3‑191010  
    S3‑191010 Proposed evaluation for Solution #1 AS and NAS security for RLOS services Qualcomm Incorporated pCR Approval Yes
Yes
approved No   S3‑190781
    S3‑190782 Proposed evaluation for Solution #2 AS and NAS security based on the emergency call procedures Qualcomm Incorporated pCR Approval Yes
YesThe were objections to the proposed text.
noted No    
    S3‑190783 Proposed update for Solution #2 AS and NAS security based on the emergency call procedures Qualcomm Incorporated pCR Approval Yes
YesChange a 'sh' to 'c'.
revised No S3‑191011  
    S3‑191011 Proposed update for Solution #2 AS and NAS security based on the emergency call procedures Qualcomm Incorporated,Lenovo pCR Approval Yes
Yes
approved No   S3‑190783
    S3‑190868 Solution Evaluations and Conclusion on KI#1 Lenovo, Motorola Mobility pCR Approval Yes
YesMerge the first clause into the S3-191010 - second part is not accepted - conclusion not accepted
merged No S3‑191011  
    S3‑191023 draft TR 33.815 Sprint draft TR Approval Yes
Yes
approved No    
5.9 Study on 5G security enhancement against false base stations (FS_5GFBS) (Rel-16) S3‑190669 New security requirement against tampering of RRCResumeRequest message Huawei, Hisilicon pCR Approval Yes
YesEricsson: 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.
revised No S3‑190936  
    S3‑190936 New security requirement against tampering of RRCResumeRequest message Huawei, Hisilicon pCR Approval Yes
Yes
merged No S3‑190997 S3‑190669
    S3‑190667 Protection of RRSResumeCause Huawei, Hisilicon pCR Approval Yes
Yes
noted No    
    S3‑190670 New security requirement against replay of RRCResumeRequest message Huawei, Hisilicon pCR Approval Yes
YesQualcomm: 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.
revised No S3‑190937  
    S3‑190937 New security requirement against replay of RRCResumeRequest message Huawei, Hisilicon pCR Approval Yes
Yes
revised No S3‑190997 S3‑190670
    S3‑190997 New security requirement against replay of RRCResumeRequest message Huawei, Hisilicon pCR Approval Yes
Yes
approved No   S3‑190937
    S3‑190668 RRCResume replay protection Huawei, Hisilicon pCR Approval Yes
YesVdf 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.
noted No    
    S3‑190829 KI#1 in TR 33.809 - new solution with netwrok controlled RRC Reject message Ericsson pCR Approval Yes
YesNEC: 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.
noted No    
    S3‑190834 Adding evaluation for Solution #1 Apple Computer Trading Co. Ltd pCR Approval Yes
YesOrange: 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. '
revised No S3‑190938  
    S3‑190938 Adding evaluation for Solution #1 Apple Computer Trading Co. Ltd pCR Approval Yes
Yes
approved No   S3‑190834
    S3‑190831 KI#2 in TR 33.809 – updated details (cleanup) Ericsson pCR Approval Yes
YesQualcomm: 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.
revised No S3‑190939  
    S3‑190939 KI#2 in TR 33.809 – updated details (cleanup) Ericsson pCR Approval Yes
Yes
approved No   S3‑190831
    S3‑190798 Changing the security requirement for KI #2 Qualcomm Incorporated pCR Approval Yes
YesSamsung: Add in all RRC states to the requirements. Ericsson: Change SIBs to SI.
revised No S3‑190940  
    S3‑190940 Changing the security requirement for KI #2 Qualcomm Incorporated pCR Approval Yes
Yes
approved No   S3‑190798
    S3‑190676 Cell Authenticated Access for fake base station detection Intel Mobile Communications pCR   Yes
YesQualcomm: 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.
noted No    
    S3‑190832 KI#2 in TR 33.809 – new solution for tamper resistant SI messages Ericsson pCR Approval Yes
YesOrange: 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.
revised No S3‑190941  
    S3‑190941 KI#2 in TR 33.809 – new solution for tamper resistant SI messages Ericsson pCR Approval Yes
Yes
approved No   S3‑190832
    S3‑190835 Adding evaluation for Solution #2 Apple Computer Trading Co. Ltd pCR Approval Yes
YesOrange: 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.
revised No S3‑190942  
    S3‑190942 Adding evaluation for Solution #2 Apple Computer Trading Co. Ltd pCR Approval Yes
Yes
approved No   S3‑190835
    S3‑190865 Evaluation of Solution #2 Samsung pCR   Yes
YesE//: need to resolve ed note first
noted No    
    S3‑190630 5GFBS-solution Using symmetric algorithm with assistance of USIM and home network ZTE Corporation pCR Approval Yes
YesOrange: 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.
noted No   S3‑190155
    S3‑190776 Certificate based solution against false base station Apple Computer Trading Co. Ltd pCR Approval Yes
YesOrange, Qualcomm and DT all felt that the solution needs to wait until the new 'Annex' on signature was done.
noted No    
    S3‑190833 ID based solution against false base station Apple Computer Trading Co. Ltd pCR Approval Yes
YesOrange, Qualcomm and DT all felt that the solution needs to wait until the new 'Annex' on signature was done.
noted No    
    S3‑190866 Solution for AS security during RRC Idle mode Samsung pCR   Yes
YesProposal to update the title and the introduction - this was agreed. Qualcomm: An EN on what happens at Location Update.
revised No S3‑190943  
    S3‑190943 Solution for AS security during RRC Idle mode Samsung pCR - Yes
Yes
approved No   S3‑190866
    S3‑190635 Updating Key issue #3 for Network detection of nearby false base station NEC Europe Ltd pCR Approval Yes
YesHuawei 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.
revised No S3‑190944  
    S3‑190944 Updating Key issue #3 for Network detection of nearby false base station NEC Europe Ltd pCR Approval Yes
Yes
approved No   S3‑190635
    S3‑190825 KI#3 in TR 33.809 - updates to updates to details and threats Ericsson pCR Approval Yes
YesHuawei supports the contribution.
approved No    
    S3‑190826 KI#3 in TR 33.809 - updates to requirements Ericsson pCR Approval Yes
YesThe proposal was changed to make it acceptable.
revised No S3‑190945  
    S3‑190945 KI#3 in TR 33.809 - updates to requirements Ericsson pCR Approval Yes
Yes
approved No   S3‑190826
    S3‑190828 KI#3 in TR 33.809 - conclusion on second requirement (reactive action) Ericsson pCR Approval Yes
YesNEC: 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.
noted No    
    S3‑190654 Notifying cell information to the network after authentication procedure failure NEC Europe Ltd pCR Approval Yes
YesInterdigital: 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.
revised No S3‑190998  
    S3‑190998 Notifying cell information to the network after authentication procedure failure NEC Europe Ltd pCR Approval Yes
YesIssue 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.
revised No S3‑191006 S3‑190654
    S3‑191006 Notifying cell information to the network after authentication procedure failure NEC Europe Ltd pCR Approval Yes
Yes
noted No   S3‑190998
    S3‑190674 Notifying cell information to the network when the UE determines that the network fails the authentication procedure NEC Europe Ltd pCR Approval Yes
Yes
withdrawn Yes    
    S3‑190660 Network detection of false base station from UE measurement reports Nokia pCR Approval Yes
YesHuawei: This can be done with current signalling. Orange: remove the evaulation - this was agreed. Pro-active and instructing the UE are removed.
revised No S3‑190946  
    S3‑190946 Network detection of false base station from UE measurement reports Nokia pCR Approval Yes
Yes
approved No   S3‑190660
    S3‑190665 Avoiding UE connecting to fake base station during HO Huawei, Hisilicon pCR Approval Yes
YesAn 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.
revised No S3‑190947  
    S3‑190947 Avoiding UE connecting to fake base station during HO Huawei, Hisilicon pCR Approval Yes
Yes
approved No   S3‑190665
    S3‑190666 Measurement report requirement for the case when the UE in RRC-IDLE & RRC-INACTIVE Huawei, Hisilicon pCR Approval Yes
Yes
merged No S3‑190985  
    S3‑190671 Measurement Report Requirement When UE in RRC-CONNECTED Huawei, Hisilicon pCR Approval Yes
Yes
merged No S3‑190985  
    S3‑190827 KI#3 in TR 33.809 - new solution for enriched measurement reports Ericsson pCR Approval Yes
YesOne EN on UE power consumption will be added and this is merged with S3-190671 and S3-190666
revised No S3‑190985  
    S3‑190985 KI#3 in TR 33.809 - new solution for enriched measurement reports Ericsson,Huawei pCR Approval Yes
Yes
approved No   S3‑190827
    S3‑190733 New requirment for Authentication relay attack Huawei, Hisilicon pCR Approval Yes
YesEricsson: 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".
revised No S3‑190986  
    S3‑190986 New requirment for Authentication relay attack Huawei, Hisilicon pCR Approval Yes
Yes
approved No   S3‑190733
    S3‑190837 Improvement to key issue #5 ZTE Corporation, Nubia pCR Approval Yes
YesBoth 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.
noted No    
    S3‑190655 Protection of UE configuration against false base station NEC Europe Ltd pCR Approval Yes
YesHuawei: 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
noted No    
    S3‑190673 Handling of UE configuration update by a fake base station NEC Europe Ltd pCR Approval Yes
Yes
withdrawn Yes    
    S3‑190734 New solution for Authentication relay attack Huawei, Hisilicon pCR Approval Yes
YesLenovo: 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.
revised No S3‑190987  
    S3‑190987 New solution for Authentication relay attack Huawei, Hisilicon pCR Approval Yes
Yes
approved No   S3‑190734
    S3‑190838 Detection of false relay base station by UE ZTE Corporation, Nubia pCR Approval Yes
YesThere was lost of discussion on whether the proposed solution work as described and it was also not clear how it fitted the key issue
noted No    
    S3‑190870 Solution on Authentication Relay Attack Lenovo, Motorola Mobility pCR Approval Yes
Yes
merged No S3‑190987  
    S3‑190663 Propose a new KI and security requirement for spoofing paging messages Huawei, Hisilicon pCR Approval Yes
YesNEC: 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
noted No    
    S3‑190664 Protection for Incoming Paging Message Based on Stored Security Context Huawei, Hisilicon pCR Approval Yes
YesRelated key issue was not accepted
noted No    
    S3‑190675 Key Issue for Fake Base Station Intel Mobile Communications pCR   Yes
YesIt was felt that the proposals in this key issue are already covered by another contribution
noted No    
    S3‑190793 Protection against Man-in-the-Middle false base station attacks Qualcomm Incorporated pCR Approval Yes
YesHuawei 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.
revised No S3‑190988 S3‑190381
    S3‑190988 Protection against Man-in-the-Middle false base station attacks Qualcomm Incorporated pCR Approval Yes
YesEricsson: 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.
revised No S3‑191021 S3‑190793
    S3‑191021 Protection against Man-in-the-Middle false base station attacks Qualcomm Incorporated pCR Approval Yes
Yes
approved No   S3‑190988
    S3‑190830 New annex in TR 33.809 - summary of PWS security study Ericsson pCR Approval Yes
YesThere was much dicsussion on whether to include the conclusion from PWS study in the FBS TR.
noted No    
    S3‑190636 Solution for preventing UE camping on false base station during Idle mode NEC Europe Ltd pCR Approval No
Yes
withdrawn Yes    
    S3‑190960 draft TR 33.809 Apple draft TR Approval Yes
Yes
approved No    
    S3‑190989 References to TR 33.809 BT pCR Approval Yes
YesThere 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.
approved No    
5.10 Study of KDF negotiation for 5G System Security (FS_5GS_KDF) (Rel-16) S3‑190723 Conclusion for KDF negotiation for 5G System Security Huawei, Hisilicon pCR Approval Yes
YesEricsson: remove 1st and 3rd sentence . NCSC 2nd sentence needs modification to remove SA3.
revised No S3‑190957 S3‑190706
    S3‑190957 Conclusion for KDF negotiation for 5G System Security Huawei, Hisilicon pCR Approval Yes
Yes
approved No   S3‑190723
    S3‑190958 draft TR 33.808 Huawei draft TR discussion Yes
Yes
approved No    
5.11 Study on Security aspects of Enhancement of Network Slicing (FS_eNS_SEC) (Rel-16) S3‑190609 Solution for Slice Specific Authentication and Authorization with multiple registrations in the same PLMN InterDigital, Inc. pCR Approval Yes
YesHuawei: 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
revised No S3‑191002  
    S3‑191002 Solution for Slice Specific Authentication and Authorization with multiple registrations in the same PLMN InterDigital, Inc. pCR Approval Yes
Yes
approved No   S3‑190609
    S3‑190697 Amendment to solution #2 Huawei, HiSilicon pCR Approval Yes
YesEricsson: 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.
noted No    
    S3‑190692 Discussions on solutions to AMF key separation Huawei, HiSilicon discussion Discussion Yes
YesDiscussion only - comments will be on solution proposals
noted No    
    S3‑190693 AMF key separation solution 1 Huawei, HiSilicon pCR Approval Yes
YesNokia: 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
noted No    
    S3‑190694 AMF key separation solution 2 Huawei, HiSilicon pCR Approval Yes
Yes
noted No    
    S3‑190695 AMF key separation solution 3 Huawei, HiSilicon pCR Approval Yes
Yes
noted No    
    S3‑190799 KAMF separation using a standalone SEAF Qualcomm Incorporated pCR Approval Yes
Yes
noted No    
    S3‑190814 Solution for key separation based on slice authentication keys Ericsson pCR Approval Yes
Yes
noted No    
    S3‑190696 Discussion on provisioning security features for a network slice Huawei, HiSilicon discussion Discussion Yes
YesMotivating solutions in other papers
noted No    
    S3‑190698 Amendment to solution #3 Huawei, HiSilicon pCR Approval Yes
YesNokia: 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.
revised No S3‑191007  
    S3‑191007 Amendment to solution #3 Huawei, HiSilicon pCR Approval Yes
Yes
approved No   S3‑190698
    S3‑190867 Privacy for Slice Authentication Lenovo, Motorola Mobility pCR Approval Yes
YesOrange: 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
revised No S3‑191017  
    S3‑191017 Privacy for Slice Authentication Lenovo, Motorola Mobility pCR Approval Yes
YesLenovo: 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.
revised No S3‑191034 S3‑190867
    S3‑191034 Privacy for Slice Authentication Lenovo, Motorola Mobility pCR Approval Yes
Yes
approved No   S3‑191017
    S3‑190738 Remove EN in 6.6.3 Huawei, Hisilicon pCR Approval Yes
YesOrange: Inconsistent to remove only one of the ENs as they refer to eachother. Huawei: Remove the first EN as well. It was agreed.
revised No S3‑191008  
    S3‑191008 Remove EN in 6.6.3 Huawei, Hisilicon pCR Approval Yes
Yes
approved No   S3‑190738
    S3‑190739 Solution for slice specific authorization Huawei, Hisilicon pCR Approval Yes
YesNokia: What is NSI-ID - a reference will be added to clarify this.
revised No S3‑191009  
    S3‑191009 Solution for slice specific authorization Huawei, Hisilicon pCR Approval Yes
Yes
approved No   S3‑190739
    S3‑190656 NSSAI protection during the RRC connection establishment procedure NEC Europe Ltd pCR Approval Yes
YesZTE: 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
noted No    
    S3‑190657 NSSAI protection during the RRC connection establishment procedure NEC Europe Ltd pCR Approval Yes
YesEricsson: 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.
noted No    
    S3‑190791 Proposed solution for protecting the S-NSSAI for transmission at the AS layer Qualcomm Incorporated pCR Approval Yes
YesOverall the reasons for S-NSSAIs were not clear
noted No    
    S3‑190699 Amendment to KI#6 Huawei, HiSilicon pCR Approval Yes
YesNEC: not sure the change is needed. Nokia: don’t believe change is needed. Orange, Ericsson and Qualcomm are not supportive of the changes.
noted No    
    S3‑190771 Key issue on Granularity of isolation for slice specific security LG Electronics pCR Approval Yes
YesRelated to key separation.
noted No    
    S3‑190948 draft TR 33.813 Nokia draft TR Approval Yes
Yes
approved No    
5.12 Study on Security of the enhancement to the 5GC location services (FS_eLCS_Sec) (Rel-16) S3‑190731 pCR to TR33.814 – Text for Clause Introduction CATT pCR Approval Yes
YesThe 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
revised No S3‑190898  
    S3‑190898 pCR to TR33.814 – Text for Clause Introduction CATT pCR Approval Yes
Yes
approved No   S3‑190731
    S3‑190732 Text for Clause 4 Security aspects of eLCS CATT pCR Approval Yes
YesThere 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.
revised No S3‑190899  
    S3‑190899 Text for Clause 4 Security aspects of eLCS CATT pCR Approval Yes
Yes
approved No   S3‑190732
    S3‑190729 pCR to TR33.814 - Key issue for positioning data confidentiality protection CATT pCR Approval Yes
YesThere 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.
revised No S3‑190900  
    S3‑190900 pCR to TR33.814 - Key issue for positioning data confidentiality protection CATT,Huawei pCR Approval Yes
Yes
approved No   S3‑190729
    S3‑190719 Key Issue for encryption and integrity protection of assistance data Huawei, Hisilicon pCR Approval Yes
YesIt was not clear what was missing from the Rel-15 security - this analysis would help the understanding of this key issue.
noted No    
    S3‑190720 Key Issue for encryption and integrity protection of location data Huawei, Hisilicon pCR Approval Yes
YesThis contribution overlaps with S3-190729 and will be merged into the revision of that document.
merged No S3‑190900  
    S3‑190730 pCR to TR33.814 - Solution for positioning data confidentiality protection CATT pCR Approval Yes
YesIt 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.
noted No    
    S3‑190721 Key Issue for privacy setting integrity between UE and homenetwork Huawei, Hisilicon pCR Approval Yes
YesThere 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 .
noted No    
    S3‑190772 Key issue on UE location privacy setting LG Electronics pCR Approval Yes
YesThe same disscusion as above document.
noted No    
    S3‑190755 New KI: Privacy control in LCS Ericsson pCR Approval Yes
YesThe 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.
revised No S3‑190902  
    S3‑190902 New KI: Privacy control in LCS Ericsson pCR Approval Yes
Yes
approved No   S3‑190755
    S3‑190881 Key Issue proposal on location measurement tampering for FS_eLCS_Sec Philips International B.V. pCR Approval Yes
YesCorrections 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.
revised No S3‑190903  
    S3‑190903 Key Issue proposal on location measurement tampering for FS_eLCS_Sec Philips International B.V. pCR Approval Yes
Yes
revised No S3‑190959 S3‑190881
    S3‑190959 Key Issue proposal on location measurement tampering for FS_eLCS_Sec Philips International B.V. pCR Approval Yes
Yes
approved No   S3‑190903
    S3‑190722 Solution on integrity protection of privacy setting between UE and UDM Huawei, Hisilicon pCR Approval Yes
Yes
noted No    
    S3‑190756 New solution: Effective privacy control in LCS Ericsson pCR Approval Yes
YesThere 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
revised No S3‑190904  
    S3‑190904 New solution: Effective privacy control in LCS Ericsson pCR Approval Yes
Yes
approved No   S3‑190756
    S3‑190751 New solution: WLAN measurements from UEs Ericsson pCR Approval Yes
YesIt 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.
revised No S3‑190905  
    S3‑190905 New solution: WLAN measurements from UEs Ericsson pCR Approval Yes
Yes
approved No   S3‑190751
    S3‑190752 New solution: Bluetooth measurements from UEs Ericsson pCR Approval Yes
Yessame comments as to 751, so same updates
revised No S3‑190906  
    S3‑190906 New solution: Bluetooth measurements from UEs Ericsson pCR Approval Yes
Yes
approved No   S3‑190752
    S3‑190753 Update KI: TBS positioning Ericsson pCR Approval Yes
Yes
approved No    
    S3‑190754 New solution: TBS measurements from UEs Ericsson pCR Approval Yes
YesVF: 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
revised No S3‑190907  
    S3‑190907 New solution: TBS measurements from UEs Ericsson pCR Approval Yes
Yes
approved No   S3‑190754
    S3‑190718 Solution for updating key to broadcast assitance data Huawei, Hisilicon pCR Approval Yes
Yes
noted No    
    S3‑190901 draft TR 33.814 CATT draft TR Approval Yes
Yes
approved No    
5.13 Study on security for 5G URLLC (FS_5G URLLC_SEC) (Rel-16) S3‑190681 overall introduction Huawei, HiSilicon pCR Approval Yes
Yes
approved No    
    S3‑190619 URLLC-KI UP security performance for low latency ZTE Corporation pCR Approval Yes
YesEricsson: 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.
revised No S3‑190969  
    S3‑190969 URLLC-KI UP security performance for low latency ZTE Corporation pCR Approval Yes
Yes
approved No   S3‑190619
    S3‑190620 URLLC-solution Enhancement of handover with Xn forwarding tunnel ZTE Corporation pCR Approval Yes
YesRelated to the key issue in S3-190969 and hence noted as no agreement to proceed on key issue.
noted No    
    S3‑190819 New solution for security for redundant data transmission using Dual Connectivity procedures Ericsson pCR Approval Yes
YesHuawei: 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.
revised No S3‑190970  
    S3‑190970 New solution for security for redundant data transmission using Dual Connectivity procedures Ericsson pCR Approval Yes
Yes
approved No   S3‑190819
    S3‑190631 Evaluation and text for resolving editor’s note for solution #5 in TR 33.825 NEC Europe Ltd pCR Approval Yes
YesAuthors 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.
merged No S3‑190971  
    S3‑190682 URLLC solution5 update Huawei, HiSilicon pCR Approval Yes
Yes
revised No S3‑190971  
    S3‑190971 URLLC solution5 update Huawei, HiSilicon,NEC pCR Approval Yes
Yes
approved No   S3‑190682
    S3‑190689 Dynamic UP security policy control solution for URLLC Huawei, HiSilicon pCR Approval Yes
YesErisscon: 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.
revised No S3‑190972  
    S3‑190972 Dynamic UP security policy control solution for URLLC Huawei, HiSilicon pCR Approval Yes
Yes
approved No   S3‑190689
    S3‑190818 Solution #Y: Security for redundant data transmission using Dual Connectivity Ericsson pCR Approval Yes
YesHuawei: 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.
revised No S3‑190973  
    S3‑190973 Solution #Y: Security for redundant data transmission using Dual Connectivity Ericsson pCR Approval Yes
Yes
approved No   S3‑190818
    S3‑190685 solution1 and evaluation update Huawei, HiSilicon pCR Approval Yes
YesEricsson: 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
revised No S3‑190974  
    S3‑190974 solution1 and evaluation update Huawei, HiSilicon pCR Approval Yes
Yes
approved No   S3‑190685
    S3‑190680 deleting the EN of solution3 Huawei, HiSilicon pCR Approval Yes
YesEricsson: convern that the UP security policy is changing. An EN on this will be added to the key issue details
revised No S3‑190975  
    S3‑190975 deleting the EN of solution3 Huawei, HiSilicon pCR Approval Yes
Yes
approved No   S3‑190680
    S3‑190820 Correction to solution #3 ‘Security policy handling for redundant data transmission’ Ericsson pCR Approval Yes
Yes
approved No    
    S3‑190683 evaluation of solution 3 Huawei, HiSilicon pCR Approval Yes
YesEricsson: 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.
revised No S3‑190976  
    S3‑190976 evaluation of solution 3 Huawei, HiSilicon pCR Approval Yes
Yes
approved No   S3‑190683
    S3‑190679 solution 2 clarification Huawei, HiSilicon pCR Approval Yes
YesEricsson: Add 'as described in TS 33.501 to end of new text. Evaluation text format to be corrected.
revised No S3‑190977  
    S3‑190977 solution 2 clarification Huawei, HiSilicon pCR Approval Yes
Yes
approved No   S3‑190679
    S3‑190678 conclusion for key issue 6 Huawei, HiSilicon pCR Approval Yes
Yes
approved No    
    S3‑190796 Conclusion on KI #6 for Study on the security for URLLC Qualcomm Incorporated pCR Approval Yes
Yes
noted No    
    S3‑190686 conclusion for key issue 1 Huawei, HiSilicon pCR Approval Yes
YesQC: 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.
noted No    
    S3‑190687 conclusion for key issue 2 Huawei, HiSilicon pCR Approval Yes
YesE//: 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.
noted No    
    S3‑190677 conclusion for key issue 3 Huawei, HiSilicon pCR Approval Yes
Yes
noted No    
    S3‑190794 Conclusion on KI #3 for Study on the security for URLLC Qualcomm Incorporated pCR Approval Yes
Yes
noted No    
    S3‑190684 conclusion for key issue 4 Huawei, HiSilicon pCR Approval Yes
Yes
noted No    
    S3‑190795 Conclusion on KI #4 for Study on the security for URLLC Qualcomm Incorporated pCR Approval Yes
Yes
noted No    
    S3‑190797 Conclusion on KI #8 for Study on the security for URLLC Qualcomm Incorporated pCR Approval Yes
YesHuawei: 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
approved No    
    S3‑190979 draft TR 33.825 Huawei draft TR Approval Yes
Yes
approved No    
5.14 Study on SECAM and SCAS for 3GPP virtualized network products (FS_VNP_SECAM_SCAS) (Rel-16) S3‑190757 Considerations on network product class when using NFV technology China Mobile Com. Corporation pCR   Yes
YesTaken offline to correct some editorials
revised No S3‑190951  
    S3‑190951 Considerations on network product class when using NFV technology China Mobile Com. Corporation pCR - Yes
Yes
approved No   S3‑190757
    S3‑190758 Considerations on SECAM of the virtualized network products China Mobile Com. Corporation pCR   Yes
Yes
revised No S3‑190952  
    S3‑190952 Considerations on SECAM of the virtualized network products China Mobile Com. Corporation pCR - Yes
YesAn EN was added
approved No   S3‑190758
    S3‑190950 draft TR 33.818 China Mobile draft TR Approval Yes
Yes
approved No    
5.15 Study on Security for 5GS Enhanced support of Vertical and LAN Services (FS_Vertical_LAN_SEC) (Rel-16) S3‑190862 Key issue on Alignment of the terms Private network and NPN Samsung pCR   Yes
YesPresented 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.
noted No    
    S3‑190700 Discussion on NPN authentication Huawei, HiSilicon discussion Endorsement Yes
Yes
revised No S3‑190962  
    S3‑190962 Discussion on NPN authentication Huawei, HiSilicon discussion Endorsement Yes
YesOrange: 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.
noted No   S3‑190700
    S3‑190787 Proposed solution to the key hierarchy for non-public networks Qualcomm Incorporated pCR Approval Yes
Yes
revised No S3‑190991  
    S3‑190991 Proposed solution to the key hierarchy for non-public networks Qualcomm Incorporated pCR Approval Yes
Yes
approved No   S3‑190787
    S3‑190788 Proposed addition to key issue#1.1 for standalone non-public networks Qualcomm Incorporated pCR Approval Yes
YesDCM: 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
revised No S3‑190992  
    S3‑190992 Proposed addition to key issue#1.1 for standalone non-public networks Qualcomm Incorporated pCR Approval Yes
Yes
approved No   S3‑190788
    S3‑190789 Adding network binding requirement to the keys issue #1.1 on standalone public networks Qualcomm Incorporated pCR Approval Yes
Yes
revised No S3‑190993  
    S3‑190993 Adding network binding requirement to the keys issue #1.1 on standalone public networks Qualcomm Incorporated pCR Approval Yes
Yes
approved No   S3‑190789
    S3‑190790 Proposed solution to key issue #1.1 in TR 33.819 Qualcomm Incorporated pCR Approval Yes
YesEricsson: Question whether it was addressing both the requirements proposed in S3-190789. Qualcomm: confirmed this.
approved No    
    S3‑190855 KI on credential storage for NPN-Ues Nokia, Nokia Shanghai Bell pCR Approval Yes
Yes
noted No    
    S3‑190858 Key issue on secure storage of SNPN access credentials Samsung, Intel pCR   Yes
YesSA3 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.
noted No    
    S3‑190859 Solution for secure storage of SNPN access credentials Samsung, Intel pCR   Yes
Yes
noted No    
    S3‑190860 Key issue on CAG access control in Non-standalone NPNs Samsung pCR   Yes
YesDCM: 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.
revised No S3‑190994  
    S3‑190994 Key issue on CAG access control in Non-standalone NPNs Samsung pCR - Yes
Yes
approved No   S3‑190860
    S3‑190861 New solution for CAG access control in Non-standalone NPNs Samsung pCR   Yes
YesOrange: 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.
revised No S3‑190995  
    S3‑190995 New solution for CAG access control in Non-standalone NPNs Samsung pCR - Yes
Yes
approved No   S3‑190861
    S3‑190845 Discussion on NPN Authentication Cablelabs, Nokia, Nokia Shanghai Bell discussion Endorsement Yes
YesPresented as introduction to the following documents
noted No    
    S3‑190856 KI on authentication and authorization of NPN subscribers by a 5G external entity Nokia, Nokia Shanghai Bell pCR Approval Yes
YesChair: 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.
revised No S3‑191000  
    S3‑191000 KI on authentication and authorization of NPN subscribers by a 5G external entity Nokia, Nokia Shanghai Bell pCR Approval Yes
Yes
approved No   S3‑190856
    S3‑190846 Deployment options for authentication in NPNs Cablelabs, Nokia, Nokia Shanghai Bell pCR Approval Yes
YesOrange: 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.
revised No S3‑191001  
    S3‑191001 Deployment options for authentication in NPNs Cablelabs, Nokia, Nokia Shanghai Bell pCR Approval Yes
Yes
approved No   S3‑190846
    S3‑190847 Evaluation of EAP-TTLS for non-certificate based UE authentication in SNPNs Cablelabs, Nokia, Nokia Shanghai Bell pCR Approval Yes
Yes
not treated No    
    S3‑190848 Solution on non-certificate based UE authentication in 5G NPN with AAA Cablelabs, Nokia, Nokia Shanghai Bell pCR Approval Yes
YesVdf: 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.
noted No    
    S3‑190849 Solution on non-certificate based UE authentication in 5G NPN without AAA Cablelabs, Nokia, Nokia Shanghai Bell pCR Approval Yes
YesNoted due to incomplete KI
noted No    
    S3‑190850 Discussion of security solutions for SNPN service access via PLMN and vice versa Nokia, Nokia Shanghai Bell discussion Endorsement Yes
Yes
not treated No    
    S3‑190851 Solution on SNPN service access via PLMN Nokia, Nokia Shanghai Bell pCR Approval Yes
Yes
not treated No    
    S3‑190852 Solution on PLMN service access via NPN Nokia, Nokia Shanghai Bell pCR Approval Yes
Yes
not treated No    
    S3‑190853 Discussion on Authentication of UE to PLMN integrated NPN Nokia, Nokia Shanghai Bell discussion Endorsement Yes
Yes
not treated No    
    S3‑190854 Solution for UE authentication to PLMN integrated NPN Nokia, Nokia Shanghai Bell pCR Approval Yes
Yes
not treated No    
    S3‑190857 Rapporteur correction to TR 33819 Nokia, Nokia Shanghai Bell pCR Approval Yes
Yes
approved No    
    S3‑190882 Issue of Alignment of the terms Private network and NPN SAMSUNG pCR Approval Yes
Yes
noted No    
    S3‑190990 NPN authentication way forward ORANGE discussion Endorsement Yes
YesNokia: 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.
revised No S3‑190999  
    S3‑191018 draft TR 33.819 Nokia draft TR Approval Yes
Yes
approved No    
    S3‑190999 NPN authentication way forward ORANGE discussion Endorsement Yes
YesQC: 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.
revised No S3‑191003 S3‑190990
    S3‑191003 NPN authentication way forward ORANGE discussion Endorsement Yes
Yes
endorsed No   S3‑190999
5.16 Study on LTKUP Detailed solutions (FS_LTKUP_Detail) (Rel-16) S3‑190768 pCR to 33935 - addition section 4.1 Overview VODAFONE Group Plc pCR Approval Yes
YesOrange: 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.
revised No S3‑190953  
    S3‑190953 pCR to 33935 - addition section 4.1 Overview VODAFONE Group Plc pCR Approval Yes
Yes
approved No   S3‑190768
    S3‑190773 pCR to 33935 - addition of detailed solution 4b VODAFONE Group Plc pCR Approval Yes
YesOrange: Add reference to SIM OTA - remove the two notes. Some changes 4.2.3 that were agreeable. Vdf: UICC should be changed to USIM.
revised No S3‑190954  
    S3‑190954 pCR to 33935 - addition of detailed solution 4b VODAFONE Group Plc pCR Approval Yes
Yes
approved No   S3‑190773
    S3‑190840 Detailed solution 5 in TR 33.935 Gemalto N.V. pCR Approval Yes
Yes
revised No S3‑190920  
    S3‑190920 Detailed solution 5 in TR 33.935 Gemalto N.V. pCR Approval Yes
YesOrange had some small changes to document that were agreeable. The reference to eSIM was removed as it about provisioning.
revised No S3‑190955 S3‑190840
    S3‑190955 Detailed solution 5 in TR 33.935 Gemalto N.V. pCR Approval Yes
Yes
approved No   S3‑190920
    S3‑190956 draft TR 33.935 Vodafone draft TR Approval Yes
Yes
approved No    
    S3‑191022 Draft skeleton document for TR 33.935 Vodafone draft TR Approval Yes
YesDelete the content of the introduction clause
revised No S3‑191024  
    S3‑191024 Draft skeleton document for TR 33.935 Vodafone draft TR Approval Yes
Yes
approved No   S3‑191022
5.17 Study on User Plane Integrity Protection (FS_UP_IP_Sec) (Rel-16) S3‑190605 Proposal for FS_UP_IP_Sec Key Issue #1.3: User plane integrity between UE and network Philips International B.V. pCR Approval Yes
YesNokia: 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.
noted No    
    S3‑190647 Editorial corrections in TR 33.853 v0.1.0 NEC Europe Ltd pCR Approval Yes
Yes
approved No    
    S3‑190648 Discussion on the need of UP IP solution for Rel.15 UEs NEC Europe Ltd, Lenovo, Motorola Mobility, Samsung discussion Discussion Yes
Yes
noted No    
    S3‑190649 New key issue on data rate limitation of integrity protection in UP DRB NEC Europe Ltd, Lenovo, Motorola Mobility, Samsung pCR Approval Yes
YesHuawei: 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.
revised No S3‑190911  
    S3‑190911 New key issue on data rate limitation of integrity protection in UP DRB NEC Europe Ltd, Lenovo, Motorola Mobility, Samsung pCR Approval Yes
YesModify requirement to refer to security threat clause
revised No S3‑191004 S3‑190649
    S3‑191004 New key issue on data rate limitation of integrity protection in UP DRB NEC Europe Ltd, Lenovo, Motorola Mobility, Samsung pCR Approval Yes
Yes
approved No   S3‑190911
    S3‑190650 New solution for data rate limitation of integrity protection in UP DRB NEC Europe Ltd, Lenovo, Motorola Mobility pCR Approval Yes
YesEricsson: 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.
noted No    
    S3‑190651 New solution for data rate limitation of integrity protection in UP DRB NEC Europe Ltd pCR Approval Yes
YesEricsson: 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.
noted No    
    S3‑190652 New key issue on integrity protection capability imbalance in MR-DC scenarios NEC Europe Ltd pCR Approval Yes
YesThis 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.
revised No S3‑190912  
    S3‑190912 New key issue on integrity protection capability imbalance in MR-DC scenarios NEC Europe Ltd pCR Approval Yes
YesDCM: ng-eNB is already like a solution.
revised No S3‑191019 S3‑190652
    S3‑191019 New key issue on integrity protection capability imbalance in MR-DC scenarios NEC Europe Ltd,Huawei pCR Approval Yes
Yes
approved No   S3‑190912
    S3‑190653 New solution for integrity protection capability imbalance in MR-DC scenarios NEC Europe Ltd pCR Approval Yes
YesRelates 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.
noted No    
    S3‑190707 Support UP_IP in option 7 Huawei, Hisilicon pCR Approval Yes
YesSee discussion on S3-190652. Merged into S3-190912.
merged No S3‑191019  
    S3‑190708 UP IP for Option 4 Huawei, Hisilicon pCR Approval Yes
YesSee discussion on S3-190652. Merged into S3-190912.
merged No S3‑191019  
    S3‑190802 pCR: New KI: Integrity Algorithm independence Qualcomm Incorporated pCR Approval Yes
YesVdf 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.
revised No S3‑190913 S3‑190388
    S3‑190913 pCR: New KI: Integrity Algorithm independence Qualcomm Incorporated pCR Approval Yes
YesOn further discussion, other companies had concerns and document is noted.
noted No   S3‑190802
    S3‑190803 pCR: New KI: Ability to prioritize certain PDCP packets on the UE uplink Qualcomm Incorporated pCR Approval Yes
YesVdf: 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.
revised No S3‑190914 S3‑190387
    S3‑190914 pCR: New KI: Ability to prioritize certain PDCP packets on the UE uplink Qualcomm Incorporated pCR Approval Yes
Yes
approved No   S3‑190803
    S3‑190804 pCR: New KI: Efficient handling of PDCP discardTimer expiry on the UE Uplink Qualcomm Incorporated pCR Approval Yes
YesHuawei: 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.
merged No S3‑190914 S3‑190386
    S3‑190880 (FS_UP_IP_Sec) Integrity protection of the User Plane -New key Issue - Reporting Integrity check failures to the network BT plc discussion Decision Yes
YesVdf: 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.
noted No    
    S3‑190910 draft TR33.853 Vodafone draft TR Approval Yes
Yes
approved No    
    S3‑190915 LS on Full date rate support for UP IP Qualcomm LS out Approval Yes
YesDCM: 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. Huawei: not include the details that were raised by QC. DCM: request from RAN2 why the limitation was in R15
revised No S3‑191020  
    S3‑191020 LS on Full date rate support for UP IP Qualcomm LS out Approval Yes
Yes
approved No   S3‑190915
5.18 Study on Security Impacts of Virtualisation (FS_SIV) (Rel-16) S3‑190610 Initialisation of Sensitive Functions in a Virtualised Environment ETSI TC CYBER LS in   Yes
Yes
noted No    
5.19 Study on authentication enhancements in 5GS (FS_AUTH_ENH) (Rel-16) S3‑190809 Skeleton for TR 33.846 Ericsson pCR Approval Yes
Yes
approved No    
    S3‑190810 Scope for TR 33.846 Ericsson pCR Approval Yes
Yes
approved No    
    S3‑190760 Key issue to ensure the security of session anchor keys China Mobile Com. Corporation pCR   Yes
Yes
noted No    
    S3‑190690 A key issue on the long-term key and its related anchor key leakage Huawei, HiSilicon pCR Approval Yes
Yes
noted No    
    S3‑190811 New KI: Leakage of long-term key Ericsson pCR Approval Yes
YesVF: 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.
noted No    
    S3‑190759 Key issue regarding the minimal computational cost when generating session anchor keys China Mobile Com. Corporation pCR   Yes
YesOrange: 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?
noted No    
    S3‑190626 eAUTH-Linkability KI exposure of cause value ZTE Corporation pCR Approval Yes
Yes
merged No S3‑190909  
    S3‑190735 Key issue on linkability attack Huawei, Hisilicon pCR Approval Yes
Yes
merged No S3‑190909  
    S3‑190762 Key issue to resist the linkability attacks China Mobile Com. Corporation pCR   Yes
YesVF: 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.
revised No S3‑190909  
    S3‑190909 Key issue to resist the linkability attacks China Mobile Com. Corporation,ZTE,Huawei pCR - Yes
Yes
approved No   S3‑190762
    S3‑190628 eAUTH-Linkability KI SQN exposure ZTE Corporation pCR Approval Yes
YesQC: 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.
merged No S3‑190909  
    S3‑190627 eAUTH-Linkability KI different length of response ZTE Corporation pCR Approval Yes
YesQC: 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
merged No S3‑190909  
    S3‑190621 eAUTH-SUCI KI Computing resource consuming ZTE Corporation pCR Approval Yes
YesVF: 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.
noted No    
    S3‑190761 Key issue to mitigate the DDoS attacks on the UDM China Mobile Com. Corporation pCR   Yes
YesNCSC: same as previous contribution, same applies? VF: same, or worse, this doesnt even say where the DDoS is coming from.
noted No    
    S3‑190622 eAUTH-SUCI KI congestion ZTE Corporation pCR Approval Yes
YesVF: 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.
noted No    
    S3‑190623 eAUTH-SUCI KI quantum computing ZTE Corporation pCR Approval Yes
YesVF: 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
noted No    
    S3‑190633 New KI on Fast re-authentication procedure for 5GS NEC Europe Ltd, Intel pCR Approval Yes
YesZTE: 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.
noted No    
    S3‑190813 Update on EAP-AKA´ PFS Ericsson pCR Approval Yes
YesNokia: what is status of IETF discussion? E//: ongoing email discussion.
noted No    
    S3‑190812 New solution: EAP-AKA´ PFS Ericsson pCR Approval Yes
Yes
noted No    
    S3‑190841 33.846: solution for anchor keys security Gemalto N.V. pCR Approval Yes
Yesno key issue for this
noted No    
    S3‑190658 Discussion paper on UE initiated EAP AKA' with PFS Nokia discussion Endorsement Yes
Yesno key issue for this
noted No    
    S3‑190659 UE Initiated EAP AKA' PFS solution Nokia pCR Approval Yes
Yesno key issue for this
noted No    
    S3‑190691 Solution Proposal based on DH between UE and AUSF Huawei, HiSilicon pCR Approval Yes
YesNCSC: no DH for SUPI protection, but ECDH. No key issue, noted
noted No    
    S3‑190763 Security enhancement for the key KSEAF based on the symmetric algorithm China Mobile Com. Corporation pCR   Yes
YesVF: long term key can be updated anyways in IoT. No key issue
noted No    
    S3‑190764 KSEAF enhancement for the EAP-AKA’ protocol China Mobile Com. Corporation pCR   Yes
YesVF: same as before
noted No    
    S3‑190839 New solution: Deriving session anchor keys with random number ZTE Corporation, Nubia pCR Approval Yes
Yesno key issue for this
noted No    
    S3‑190765 ECIES based security enhancement for the key KSEAF China Mobile Com. Corporation pCR   Yes
Yesno key issue for this
noted No    
    S3‑190766 KSEAF enhancement for 5G AKA protocol China Mobile Com. Corporation pCR   Yes
Yesno key issue for this
noted No    
    S3‑190629 eAUTH-Linkability solution encrypted session anchor key based solution ZTE Corporation pCR Approval Yes
Yesrelated 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.
noted No    
    S3‑190736 New solution for linkability attack Huawei, Hisilicon pCR Approval Yes
Yesrelated 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.
noted No    
    S3‑190625 eAUTH-SUCI solution mitigation of large SUCI attack ZTE Corporation pCR Approval Yes
Yesno key issue for this
noted No    
    S3‑190624 eAUTH-SUCI solution adding symmetric algorithm for SUPI protection scheme ZTE Corporation pCR Approval Yes
Yesno 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.
noted No    
    S3‑190634 Solution to support Fast Re-authentication in 5GS NEC Europe Ltd, Intel pCR Approval Yes
Yesno key issue for this
noted No    
    S3‑190908 Draft TR 33.846 Ericsson draft TR Approval Yes
Yes
approved No    
5.20 Study on Security for NR Integrated Access and Backhaul (FS_NR_IAB_Sec) S3‑190863 Draft TR 33.xxx - Skeleton TR on Security for NR Integrated Access and Backhaul Samsung other   Yes
Yes
approved No    
    S3‑190864 Scope for the study on security for NR Integrated Access and Backhaul Samsung other   Yes
Yes
revised No S3‑190916  
    S3‑190916 Scope for the study on security for NR Integrated Access and Backhaul Samsung other - Yes
Yes
approved No   S3‑190864
    S3‑190917 new draft TR 33.XYZ Samsung other Approval Yes
Yes
approved No    
5.21 Study on Security Aspects of 3GPP support for Advanced V2X Services (FS_eV2X_Sec) S3‑190601 New Key Issue for eV2X TR - privacy protection for unicast messages InterDigital, Inc. other Approval Yes
Yes
noted No    
    S3‑190602 New Key Issue for eV2X TR - privacy protection for multicast messages InterDigital, Inc. other Approval Yes
Yes
noted No    
    S3‑190604 New Key Issue for eV2X TR - security for unicast/multicast messages InterDigital, Inc. other Approval Yes
Yes
noted No    
    S3‑190606 New Key Issue for eV2X TR - Security of the UE service authorization and revocation InterDigital, Inc. other Approval Yes
Yes
noted No    
    S3‑190607 New Key Issue for eV2X TR - Security of the UE service provisioning InterDigital, Inc. other Approval Yes
Yes
noted No    
    S3‑190608 References InterDigital, Inc. other Approval Yes
Yes
noted No    
    S3‑190769 Skeleton of eV2X security study LG Electronics other Approval Yes
Yes
approved No    
    S3‑190770 Scope proposal for eV2X security study LG Electronics other Approval Yes
Yes3 small changes to align with drafting rules
revised No S3‑190918  
    S3‑190918 Scope proposal for eV2X security study LG Electronics other Approval Yes
Yes
approved No   S3‑190770
    S3‑190919 new draft TR 33.ABC LG other Approval Yes
Yes
approved No    
6 Any Other Business S3‑190612 Work Plan input from Rapporteurs WG Vice Chairs other   Yes
Yes
revised No S3‑191035  
    S3‑191035 Work Plan input from Rapporteurs WG Vice Chairs other - Yes
Yes
noted No   S3‑190612