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 |