Tdoc List
2019-08-30 17:50
TDoc | Title | Source | Type | For | Agenda | Avail | Treated | Decision | Wdrn | Replaced-by | Replaces |
---|---|---|---|---|---|---|---|---|---|---|---|
S3‑192500 | Agenda | WG Chairman | agenda |
2Approval of Agenda and Meeting Objectives
| Yes |
Yes
| revised | No | S3‑192978 | ||
S3‑192501 | Report from last SA3 meeting/s | MCC | report |
4.1Approval of the report from previous SA3 meeting(s)
| Yes |
Yes
| approved | No | |||
S3‑192502 | SA3 Work Plan | MCC | Work Plan |
9.1Review of work plan
| Yes |
Yes
| noted | No | |||
S3‑192503 | SA3 meeting calendar | MCC | other |
10Future Meeting Dates and Venues
| Yes |
Yes
| revised | No | S3‑193199 | ||
S3‑192504 | Work Plan input from Rapporteurs | MCC | other |
9.2Rapporteur input on status of WID or SID
| Yes |
Yes
| revised | No | S3‑193202 | ||
S3‑192505 | Wireline Access Security requirements | BBF | LS in |
6.10Other Groups
| Yes |
YesVodafone: mention what 33.501 is relevant to and not what is not relevant to.
Alf (NTT-Docomo): errors in the attached document. E.g. it's 256 bits and not bytes.
| replied to | No | |||
S3‑192506 | LS on Broadcast of Location Assistance Data for NR | S2-1908104 | LS in |
6.13GPP Working Groups
| Yes |
Yes
| noted | No | |||
S3‑192507 | Reply LS to Reply LS on protection of PC5-RRC messages for sidelink unicast communication | S2-1908229 | LS in |
8.18Study on Security Aspects of 3GPP support for Advanced V2X Services (FS_eV2X_Sec)
| Yes |
Yes
| noted | No | |||
S3‑192508 | Reply LS on RRC Connection Re-Establishment for CP for NB-IoT connected to 5GC | S2-1908553 | LS in |
7.8Security of Cellular IoT for 5GS (CIoT_sec_5G) (Rel-16)
| Yes |
Yes
| noted | No | |||
S3‑192509 | Reply LS on DL-only UE-based positioning | S2-1908624 | LS in |
6.13GPP Working Groups
| Yes |
Yes
| noted | No | |||
S3‑192510 | Reply LS on Mobile-terminated Early Data Transmission | S2-1908629 | LS in |
7.11.10Security Aspects of Narrowband IOT (CIoT)
| Yes |
YesSecurity issues: Huawei didnt think there were any.
It was then discussed whether to acknowledge the security issues and just say that it would require additional work.This was agreed.
| replied to | No | |||
S3‑192511 | Reply LS on authentication of group of IoT devices | S2-1908632 | LS in |
7.8Security of Cellular IoT for 5GS (CIoT_sec_5G) (Rel-16)
| Yes |
Yes
| noted | No | |||
S3‑192512 | LS on withdrawal of TS 103 383 Smart Cards; Embedded UICC; Requirements Specification | ETSI TC SCP | LS in |
6.10Other Groups
| Yes |
YesOrange brought 4 CRs for this meeting to address this issue; these were in another agenda item and agreed.
| replied to | No | |||
S3‑192513 | LS on SG11 activities related to improvement of the SS7 security including for digital financial services | ITU-T SG11 | LS in |
6.10Other Groups
| Yes |
YesBT recommended the group to read the attached documents as there were some points of interest for operators.
| noted | No | |||
S3‑192514 | Reply LS on Nudr Sensitive Data Protection | SP-190581 | LS in |
7.1.1UDR
| Yes |
YesVodafone: we had an extended discussion on this LS and we have CRs for this meeting. We can note it.
Other companies argued that a reply may be needed, so it was kept open.
| noted | No | |||
S3‑192515 | draftTR33.xxx Storage of sensitive credentials in 5G systems v0.0.1 | Vodafone Espaρa SA | discussion |
8.20New study item proposals
| Yes |
Yes
| noted | No | |||
S3‑192516 | Reply LS on ETSI Plugtest standards issues | S6-191525 | LS in |
7.11.8Mission Critical (MCPTT, MCSec, eMCSec, MONASTERY_SEC)
| Yes |
Yes
| noted | No | |||
S3‑192517 | Issues with encryption of satellite backhaul | TNO, Avanti, iDirect, University of Surrey, SES | discussion | Discussion |
8.20New study item proposals
| Yes |
YesNokia: which 3GPP node has an impact?
TNO: the backhaul is confidentially protected according to our specs; this would be a similar case to the SEPPs when connecting different networks, so that would impact our requirement.
Nokia: but there is no impact on 3GPP nodes then.
NTT-Docomo: profiling PEP for use in NDS? Not much else to do and not really a high priority. TNO: this is intended for Release 17.
Interdigital: redesign Ipsec here is the motivation? We are not the right place to change it.
Qualcomm: you can use any technology to confidentiality protect the satellite link, not Ipsec necessarily. Not clear to me what we need to study.
| noted | No | ||
S3‑192518 | Conclusion for KI#4 | KPN, Huawei, Hisilicon | pCR | Approval |
8.4Study on evolution of Cellular IoT security for the 5G System (FS_CIoT_sec_5G) (Rel-16)
| Yes |
Yes
| noted | No | ||
S3‑192519 | Clarifications for Protected MCData | Airbus DS SLC | CR | Agreement |
7.3eMCSec R16 security (MCXSec) (Rel-16)
| Yes |
YesMotorola: this is not needed. NCSC agreed.
Samsung: too many stage 3 parameters. This is not needed.
| revised | No | S3‑193021 | |
S3‑192520 | TCG progress report | InterDigital Communications | report | Information |
6.5TCG
| Yes |
Yes1. TCG Highlights
Publication of new or revised deliverables (incremental changes from the status reported at SA3#95-BIS)
TCG RIV: Network Equipment Remote Attestation public review June 2019 http://www.trustedcomputinggroup.org/specifications-public-review/
TCG Trusted Attestation Protocol (TAP) Info Model publication August 2019
TCG Trusted Attestation Protocol (TAP) Use Cases public review August 2019 http://www.trustedcomputinggroup.org/specifications-public-review/
TCG Mobile Device Runtime Integrity Preservation public review August 2019 http://www.trustedcomputinggroup.org/specifications-public-review/
TCG TPM 2.0 Auto Thin Profile publication August 2019
TCG TSS 2.0 Enhanced System Level API (ESAPI) publication August 2019
TCG TSS 2.0 System Level API (SAPI) publication August 2019
TCG TSS 2.0 TPM Command Transmission Interface (TCTI) public review July 2019 http://www.trustedcomputinggroup.org/specifications-public-review/
TCG Storage: Configurable Namespace Locking Examples public review July 2019 http://www.trustedcomputinggroup.org/specifications-public-review/
TCG Storage: PYRITE public review in June 2019 http://www.trustedcomputinggroup.org/specifications-public-review/
TCG Storage: RUBY public review in June 2019 http://www.trustedcomputinggroup.org/specifications-public-review/
TCG Storage: OPAL Shadow MBR for Multiple Namespaces public review June 2019 http://www.trustedcomputinggroup.org/specifications-public-review/
TCG TPM 2.0 r1.55 X.509 Certs & Attached Components public review May 2019 http://www.trustedcomputinggroup.org/specifications-public-review/
TCG TPM 2.0 Auto Thin Protection Profile published February 2019
TCG PC Client Device Driver Design Principles for TPM 2.0 public review February 2019 http://www.trustedcomputinggroup.org/specifications-public-review/
IETF Remote ATtestation ProcedureS (RATS) WG in IETF Security Area
About: https://datatracker.ietf.org/wg/rats/about/
Charter: https://datatracker.ietf.org/doc/charter-ietf-rats/
Documents: https://datatracker.ietf.org/wg/rats/documents/
draft-ietf-rats-eat-01 The Entity Attestation Token (EAT)
draft-birkholz-rats-basic-yang-module-01 YANG Module for Basic Challenge-Response-based Remote Attestation Procedures
draft-birkholz-rats-information-model-00 An Information Model for Assertions used in RATS
draft-birkholz-rats-reference-interaction-model-01 Reference Interaction Model for Challenge-Response-based Remote Attestation
draft-birkholz-rats-tuda-00 Time-Based Uni-Directional Attestation
draft-fedorkow-rats-network-device-attestation-00 Network Device Attestation Workflow
draft-richardson-rats-usecases-04 Use cases for Remote Attestation common encodings
draft-tschofenig-rats-psa-token-02 Arm's Platform Security Architecture (PSA) Attestation Token
2. Meetings
TCG Annual Members Meeting in Toronto, Canada - 15-17 October 2019
TCG Members Meeting in Miami, Florida USA 10-13 February 2020
MPWG meets every Thursday at 10-11 ET
TMS WG meets every Monday and Friday at 12-13 ET
CyRes WG meets every Wednesday at 11-12:30 ET
3. Conclusion
It is proposed to add the contents of this contribution in the appropriate section, similar to Reports and Liaisons from other Groups TCG of SA3#96 meeting report.
| noted | No | ||
S3‑192521 | Corrections for TR 33.835 | InterDigital Communications | pCR | Approval |
8.3Study on authentication and key management for applications based on 3GPP credential in 5G IoT (FS_AKMA)(Rel-16)
| Yes |
Yes
| approved | No | ||
S3‑192522 | 33.836 - solution #1 update | InterDigital Communications | pCR | Approval |
8.18Study on Security Aspects of 3GPP support for Advanced V2X Services (FS_eV2X_Sec)
| Yes |
YesEricsson proposed adding an editor's note on which messages are integrity protected and trackability problem.The second editor's note was brought back instead.
| revised | No | S3‑193154 | |
S3‑192523 | TR 33.836 - update for solution #2 | InterDigital Communications | pCR | Approval |
8.18Study on Security Aspects of 3GPP support for Advanced V2X Services (FS_eV2X_Sec)
| Yes |
YesLG: the first editor's note should stay, as we need additional clarifiation. Is there Prose architecture for NR implied? Interdigital said so, and LG replied that there was no ProSe architecture in release 16. A note should be added.
| revised | No | S3‑193155 | |
S3‑192524 | TR 33.836 - solution #3 update | InterDigital Communications | pCR | Approval |
8.18Study on Security Aspects of 3GPP support for Advanced V2X Services (FS_eV2X_Sec)
| Yes |
YesSame case as previous contribution, and the same editor's note was added as suggested by LG.
Ericsson proposed to highlight the difference between this and solution 2.
| revised | No | S3‑193157 | |
S3‑192525 | TR 33.836 solution #4 update | InterDigital Communications | pCR | Approval |
8.18Study on Security Aspects of 3GPP support for Advanced V2X Services (FS_eV2X_Sec)
| Yes |
Yes
| revised | No | S3‑193158 | |
S3‑192526 | TR 33.819 - DH based solution for CAG ID privacy | InterDigital Communications | pCR | Approval |
8.12Study on Security for 5GS Enhanced support of Vertical and LAN Services (FS_Vertical_LAN_SEC) (Rel-16)
| Yes |
YesEricsson: effectiveness of the solution against false base stations needs to be evaluated as well. This was added in an editor's note.
Qualcomm: Adding Diffie Hellman undermines the security of broadcast.
CableLabs: best if you send a hash of CAG ID.
NCSC reminded that using Diffie Hellman is not quantum safe.
It was revised in order to add a number of editor's notes to address all comments.
| revised | No | S3‑193135 | |
S3‑192527 | TR 33.819 - hash based solution for CAG ID privacy | InterDigital Communications | pCR | Approval |
8.12Study on Security for 5GS Enhanced support of Vertical and LAN Services (FS_Vertical_LAN_SEC) (Rel-16)
| Yes |
Yes
| revised | No | S3‑193136 | |
S3‑192528 | TR 33.813 - update for solution #11 | InterDigital Communications | pCR | Approval |
8.8Study on Security aspects of Enhancement of Network Slicing (FS_eNS_SEC) (Rel-16)
| Yes |
YesHuawei: third paragraph not OK.
Nokia:in the solution part. all base stations under one AMF need to know all these hash values for routing the NAS messages to a particular AMF. Interdigital replied that it was by an update in the provisioning. It was decided to add an editor's note under step 5.
Qualcom proposed to remove the first paragraph.
| revised | No | S3‑193124 | |
S3‑192529 | TR 33.819 - Update for solution 9 | InterDigital Communications | pCR | Approval |
8.12Study on Security for 5GS Enhanced support of Vertical and LAN Services (FS_Vertical_LAN_SEC) (Rel-16)
| Yes |
Yes
| approved | No | ||
S3‑192530 | Corrections for Definitions and Abbreviations clauses | AT&T, Interdigital, Nokia | CR | Approval |
7.1.3Other 5G security aspects
| Yes |
YesOrange: SE is not the adequate abbreviation.
Ericsson didn't find the definition precise enough. Qualcomm didn't find the change needed.
China Mobile didnt agree with having it as a logical identity, since it could be a physical protection. Gemalto supported this.
Nokia: the term is used 22 times and it is part of the UDM/UDR discussion.
Orange commented that the term secure environment was self-explanatory.
| not pursued | No | ||
S3‑192531 | Resolving EN in 33855 6.18 N9 NDS/IP | Juniper Networks | pCR | Agreement |
8.1Study on Security Aspects of the 5G Service Based Architecture (FS_SBA-Sec) (Rel-15)
| Yes |
Yes
| withdrawn | Yes | ||
S3‑192532 | New KI for TR 33.835 - roaming environment | InterDigital Communications | pCR | Approval |
8.3Study on authentication and key management for applications based on 3GPP credential in 5G IoT (FS_AKMA)(Rel-16)
| Yes |
YesEricsson: Anchor is in home network; is the roaming meaningful here? Also, remove second requirement.
Qualcomm: we just concluded the architecture we are going to use, and this is not the architecture we agreed to conclude. I question the whole key issue but we can look at this in the normative work.
Colin (BT) didnt find it necessary. There is still home control.
Orange was happy with the requirements and they could go to general requirements clause so they didnt depend on the solution. They were useful for the normative work.
It was commented that the requirements still needed work.
| noted | No | ||
S3‑192533 | LS from TC SmartM2M STF547 to 3GPP SA1 Cc SA3 | ETSI TC SmartM2M | LS in |
6.10Other Groups
| Yes |
Yes
| noted | No | |||
S3‑192534 | LS on the call for proposals for an internationally agreed Vehicular Multimedia Architecture | ITU-T FG-VM | LS in |
8.18Study on Security Aspects of 3GPP support for Advanced V2X Services (FS_eV2X_Sec)
| Yes |
Yes
| noted | No | |||
S3‑192535 | 256 bit radio interface algorithm performance | ETSI SAGE | LS in |
6.3ETSI SAGE
| Yes |
YesVodafone commented that proper feedback was needed, from as many companies as possible.
Nokia: single/multiple core is for UE or network side? Vodafone: both.
Nokia: Multi-CPU for the core side should be assumed.
| postponed | No | |||
S3‑192536 | Proposal to solve ED notes in solution#4: Zero-overhead user plane integrity protection on the link layer | Philips International B.V. | pCR | Approval |
8.14Study on User Plane Integrity Protection (FS_UP_IP_Sec) (Rel-16)
| Yes |
YesQualcomm disagreed with the document and opted for having it noted.
Samsung had similar issues with this document.
| noted | No | ||
S3‑192537 | New KI for TR 33.835 environments where a UICC, or a SIM card, is not available to subscribers | InterDigital Communications | pCR | Approval |
8.3Study on authentication and key management for applications based on 3GPP credential in 5G IoT (FS_AKMA)(Rel-16)
| Yes |
YesOrange, Vodafone objected to this contribution.
Nokia supported it.
| noted | No | ||
S3‑192538 | Proposal for editor's note in FS_CIoT_sec_5G solution #15 | Philips International B.V. | pCR | Approval |
8.4Study on evolution of Cellular IoT security for the 5G System (FS_CIoT_sec_5G) (Rel-16)
| Yes |
Yes
| approved | No | ||
S3‑192539 | New KI for TR 33.835 browser environment | InterDigital Communications | pCR | Approval |
8.3Study on authentication and key management for applications based on 3GPP credential in 5G IoT (FS_AKMA)(Rel-16)
| Yes |
YesQualcomm: AKMA is designed to use with any application, we dont need to specify the browser in particular.
| noted | No | ||
S3‑192540 | Correction of text on access authentication for untrusted access | BlackBerry UK Limited | CR | Agreement |
7.1.3Other 5G security aspects
| Yes |
YesTreated as item for early consideration.
Lenovo: the WLAN part is out of scope for us. We dont want to see this.
Nokia didnt agree either, although the reference correction should be left.
Tao (CableLabs) supported the above companies.
Blackberry commented that in CT1 they needed to define a procedure to select ANI, but they couldn't since this SA3 specification didnt have a requirement for that.
Huawei: you can fall back to Release 8 and use LTE security.
| revised | No | S3‑192979 | |
S3‑192541 | TR 33.848 Annex - Administration of Virtualisation | NCSC | pCR | Approval |
8.15Study on Security Impacts of Virtualisation (FS_SIV) (Rel-16)
| Yes |
Yes
| revised | No | S3‑193088 | |
S3‑192542 | TR 33.848 Annex - Virtualisation Security Questions | NCSC | pCR | Approval |
8.15Study on Security Impacts of Virtualisation (FS_SIV) (Rel-16)
| Yes |
Yes
| revised | No | S3‑193089 | |
S3‑192543 | TR 33.848 Clarifications for Section 4 | NCSC | pCR | Approval |
8.15Study on Security Impacts of Virtualisation (FS_SIV) (Rel-16)
| Yes |
Yes
| noted | No | ||
S3‑192544 | TR 33.848 Security Threats and Requirements for Key Issue 1 | NCSC | pCR | Approval |
8.15Study on Security Impacts of Virtualisation (FS_SIV) (Rel-16)
| Yes |
Yes
| revised | No | S3‑193090 | |
S3‑192545 | TR 33.848 Security Requirements for Key Issue 3 | NCSC,Nokia | pCR | Approval |
8.15Study on Security Impacts of Virtualisation (FS_SIV) (Rel-16)
| Yes |
Yes
| merged | No | S3‑193092 | |
S3‑192546 | TR 33.848 Security Threats and Requirements for Key Issue 4 | NCSC | pCR | Approval |
8.15Study on Security Impacts of Virtualisation (FS_SIV) (Rel-16)
| Yes |
Yes
| revised | No | S3‑193093 | |
S3‑192547 | TR 33.848 Security Threats and Requirements for Key Issue 5 | NCSC | pCR | Approval |
8.15Study on Security Impacts of Virtualisation (FS_SIV) (Rel-16)
| Yes |
Yes
| merged | No | S3‑193094 | |
S3‑192548 | TR 33.848 Security Threats and Requirements for Key Issue 6 | NCSC | pCR | Approval |
8.15Study on Security Impacts of Virtualisation (FS_SIV) (Rel-16)
| Yes |
Yes
| noted | No | ||
S3‑192549 | TR 33.848 Security Threats and Requirements for Key Issue 7 | NCSC | pCR | Approval |
8.15Study on Security Impacts of Virtualisation (FS_SIV) (Rel-16)
| Yes |
Yes
| noted | No | ||
S3‑192550 | TR 33.848 Security Threats and Requirements for Key Issue 8 | NCSC | pCR | Approval |
8.15Study on Security Impacts of Virtualisation (FS_SIV) (Rel-16)
| Yes |
Yes
| noted | No | ||
S3‑192551 | TR 33.848 Security Threats and Requirements for Key Issue 9 | NCSC | pCR | Approval |
8.15Study on Security Impacts of Virtualisation (FS_SIV) (Rel-16)
| Yes |
Yes
| not treated | No | ||
S3‑192552 | TR 33.848 Security Threats and Requirements for Key Issue 10 | NCSC | pCR | Approval |
8.15Study on Security Impacts of Virtualisation (FS_SIV) (Rel-16)
| Yes |
Yes
| not treated | No | ||
S3‑192553 | TR 33.848 Security Threats and Requirements for Key Issue 11 | NCSC | pCR | Approval |
8.15Study on Security Impacts of Virtualisation (FS_SIV) (Rel-16)
| Yes |
Yes
| not treated | No | ||
S3‑192554 | TR 33.848 Security Threats and Requirements for Key Issue 12 | NCSC | pCR | Approval |
8.15Study on Security Impacts of Virtualisation (FS_SIV) (Rel-16)
| Yes |
Yes
| not treated | No | ||
S3‑192555 | TR 33.848 Security Threats and Requirements for Key Issue 13 | NCSC | pCR | Approval |
8.15Study on Security Impacts of Virtualisation (FS_SIV) (Rel-16)
| Yes |
Yes
| not treated | No | ||
S3‑192556 | TR 33.848 Security Threats and Requirements for Key Issue 14 | NCSC | pCR | Approval |
8.15Study on Security Impacts of Virtualisation (FS_SIV) (Rel-16)
| Yes |
Yes
| not treated | No | ||
S3‑192557 | TR 33.848 Security Threats and Requirements for Key Issue 15 | NCSC | pCR | Approval |
8.15Study on Security Impacts of Virtualisation (FS_SIV) (Rel-16)
| Yes |
Yes
| not treated | No | ||
S3‑192558 | TR 33.848 Security Threats and Requirements for Key Issue 16 | NCSC | pCR | Approval |
8.15Study on Security Impacts of Virtualisation (FS_SIV) (Rel-16)
| Yes |
Yes
| not treated | No | ||
S3‑192559 | TR 33.848 Security Requirements for Key Issue 17 | NCSC | pCR | Approval |
8.15Study on Security Impacts of Virtualisation (FS_SIV) (Rel-16)
| Yes |
Yes
| not treated | No | ||
S3‑192560 | TR 33.848 Security Requirements for Key Issue 18 | NCSC | pCR | Approval |
8.15Study on Security Impacts of Virtualisation (FS_SIV) (Rel-16)
| Yes |
Yes
| not treated | No | ||
S3‑192561 | TR 33.848 Security Requirements for Key Issue 19 | NCSC | pCR | Approval |
8.15Study on Security Impacts of Virtualisation (FS_SIV) (Rel-16)
| Yes |
Yes
| not treated | No | ||
S3‑192562 | TR 33.848 Security Threats and Requirements for Key Issue 21 | NCSC | pCR | Approval |
8.15Study on Security Impacts of Virtualisation (FS_SIV) (Rel-16)
| Yes |
Yes
| not treated | No | ||
S3‑192563 | NAS Count values in the mapped EPS security context in 5GS to EPS change | Qualcomm Incorporated | CR | Agreement |
7.1.3Other 5G security aspects
| Yes |
Yes
| agreed | No | S3‑191917 | |
S3‑192564 | Resolving Editors Notes and adding conclusion to solution #20 | NEC Corporation | pCR | Approval |
8.3Study on authentication and key management for applications based on 3GPP credential in 5G IoT (FS_AKMA)(Rel-16)
| Yes |
Yes
| approved | No | ||
S3‑192565 | conclusion for KI #9 | NEC Corporation | pCR | Approval |
8.3Study on authentication and key management for applications based on 3GPP credential in 5G IoT (FS_AKMA)(Rel-16)
| Yes |
Yes
| noted | No | ||
S3‑192566 | conclusion for KI #15 | NEC Corporation | pCR | Approval |
8.3Study on authentication and key management for applications based on 3GPP credential in 5G IoT (FS_AKMA)(Rel-16)
| Yes |
YesQualcomm and Nokia didnt agree with the text.
| noted | No | ||
S3‑192567 | Editorial corrections for eV2X SI TR 33.836 v0.3.0 | NEC Corporation | pCR | Approval |
8.18Study on Security Aspects of 3GPP support for Advanced V2X Services (FS_eV2X_Sec)
| Yes |
YesMCC commented that the existent text: "However no IE has been defined for the for the cross-RAT PC5 control authorization indication. It has been decided that SA3 shall make a decision on this matter " needed re-wording.
| approved | No | ||
S3‑192568 | terminology alignment on groupcast | NEC Corporation | pCR | Approval |
8.18Study on Security Aspects of 3GPP support for Advanced V2X Services (FS_eV2X_Sec)
| Yes |
Yes
| revised | No | S3‑193167 | |
S3‑192569 | new KI on privacy protection for broadcast | NEC Corporation | pCR | Approval |
8.18Study on Security Aspects of 3GPP support for Advanced V2X Services (FS_eV2X_Sec)
| Yes |
Yes
| revised | No | S3‑193162 | |
S3‑192570 | new solution on privacy protection for broadcast and groupcast | NEC Corporation | pCR | Approval |
8.18Study on Security Aspects of 3GPP support for Advanced V2X Services (FS_eV2X_Sec)
| Yes |
YesLG: No requirement to justify 6.Y.2.1 in 3GPP for Unicast. Remove the whole clause. Qualcomm didnt understand why introducing PC5 signalling; besides, according to SA2's agreements on broadcast and groupcast this solution is not needed.
| noted | No | ||
S3‑192571 | new solution on privacy protection for unicast | NEC Corporation | pCR | Approval |
8.18Study on Security Aspects of 3GPP support for Advanced V2X Services (FS_eV2X_Sec)
| Yes |
YesLG was not happy about NOTE 2 and proposed to remove it. Interdigital added that the solution didnt consider the trackability and linkability of identities.Qualcomm considered the point as valid and an editor's note was added.
| revised | No | S3‑193159 | |
S3‑192572 | new KI on increasing robustness and reliability in L2 ID update procedure | NEC Corporation | pCR | Approval |
8.18Study on Security Aspects of 3GPP support for Advanced V2X Services (FS_eV2X_Sec)
| Yes |
Yes
| noted | No | ||
S3‑192573 | new solution on increasing robustness and reliability in L2 ID update procedure | NEC Corporation | pCR | Approval |
8.18Study on Security Aspects of 3GPP support for Advanced V2X Services (FS_eV2X_Sec)
| Yes |
Yes
| noted | No | ||
S3‑192574 | new KI on minimizing the impact of privacy protection mechanism in the application layer communication | NEC Corporation | pCR | Approval |
8.18Study on Security Aspects of 3GPP support for Advanced V2X Services (FS_eV2X_Sec)
| Yes |
Yes
| revised | No | S3‑193164 | |
S3‑192575 | new solution on minimizing the impact of privacy protection mechanism in the application layer communication | NEC Corporation | pCR | Approval |
8.18Study on Security Aspects of 3GPP support for Advanced V2X Services (FS_eV2X_Sec)
| Yes |
YesLG: revise the figure to address the unicast case.
The evaluation was also removed.
| revised | No | S3‑193165 | |
S3‑192576 | Editorial corrections for SCAS UDM TS 33.514 v0.5.0 | NEC Corporation | pCR | Approval |
7.2.4Unified Data Management (UDM) (TS 33.514)
| Yes |
Yes
| approved | No | ||
S3‑192577 | Security for non-public networks | Qualcomm Incorporated, Nokia, Nokia Shanghai Bell | CR |
7.7Security for 5GS Enhanced support of Vertical and LAN Services (Vertical_LAN_SEC) (Rel-16)
| Yes |
Yes
| revised | No | S3‑193051 | ||
S3‑192578 | General NDS/IP SEG support for non-SBA interfaces | Juniper Networks | CR |
7.11.3Network Domain Security (NDS)
| Yes |
Yes
| revised | No | S3‑193000 | ||
S3‑192579 | Minor corrections to 33163 | Juniper Networks | CR | Approval |
7.11.15Battery Efficient Security for very low Throughput Machine Type Communication Devices (BEST_MTC_Sec) (Rel-15)
| Yes |
Yes
| revised | No | S3‑193061 | |
S3‑192580 | Minor corrections to 33163 | Juniper Networks | CR | Approval |
7.11.15Battery Efficient Security for very low Throughput Machine Type Communication Devices (BEST_MTC_Sec) (Rel-15)
| Yes |
Yes
| revised | No | S3‑193062 | |
S3‑192581 | Add a new Annex for the authentication of non-5GC NAS capable devices in WWC | CableLabs, Charter Communications, Nokia, Nokia Shanghai Bell, Lenovo, Motorola Mobility, Ericsson, Comcast, Rogers Communications | draftCR | Agreement |
7.9Security of the Wireless and Wireline Convergence for the 5G system architecture (5WWC_SEC) (Rel-16)
| Yes |
YesOrange: this procedure will not be mandated, so the annex should be informative.
Deutsche Telekom: you need to add the acronym and definition of W-AGF.
Telecom Italia queried whether this was for the study, then the CR would not be valid. It was clarified that this was a draft CR for the normative work item.
Finally it was agreed to merge this into the living document/ draft CR that would introduce all 5WWC changes.
There was some discussion about the term "N5GC device": Orange warned that there were two terms for the devices in SA2 and that in SA3 they had to be more specific and use only one.It was proposed to use "Non 5GC device" and this was agreed.
Interdigital questioned using a flow diagram from SA2 that would have to be updated every time it was changed in that WG.
| revised | No | S3‑193054 | |
S3‑192582 | Discussion paper on MT EDT LS from SA2 | Nokia, Nokia Shangahi Bell | discussion | Endorsement |
7.11.10Security Aspects of Narrowband IOT (CIoT)
| Yes |
Yes
| noted | No | ||
S3‑192583 | Addressing EN in PARLOS Evaluation clause 7.2.3 | Nokia, Nokia Shangahi Bell | pCR | Approval |
8.6Study on Security Aspects of PARLOS (FS_PARLOS_Sec) (Rel-16)
| Yes |
Yes
| revised | No | S3‑193118 | |
S3‑192584 | Update to Solution 8 protecting NSSAI in AS layer | Nokia, Nokia Shanghai Bell, Ericsson | pCR | Approval |
8.8Study on Security aspects of Enhancement of Network Slicing (FS_eNS_SEC) (Rel-16)
| Yes |
YesHuawei only agreed with the first paragraph. This was kept in the revision.
| revised | No | S3‑193122 | |
S3‑192585 | FBS add text to evaluation clause 6.7.3 | Nokia, Nokia Shanghai Bell | pCR | Approval |
8.7Study on 5G security enhancement against false base stations (FS_5GFBS) (Rel-16)
| Yes |
Yes
| not treated | No | ||
S3‑192586 | Summary of updates to S3-192276 from last meeting | Nokia, Nokia Shanghai Bell | discussion | Endorsement |
7.1.1UDR
| Yes |
Yes
| noted | No | ||
S3‑192587 | Definition of authentication subscription data and update to UDM requirement | Nokia, Nokia Shanghai Bell | CR | Agreement |
7.1.1UDR
| Yes |
YesOrange and Vodafone had some specific comments that were taken offline (specifically on clause 5.8).
Vodafone: we were told that security had to be unespecified in release 15 so as not to interfere with CT.This is not necessary.
| revised | No | S3‑192987 | S3‑191986 |
S3‑192588 | Requirement on UDR | Nokia, Nokia Shanghai Bell | CR | Agreement |
7.1.1UDR
| Yes |
YesVodafone had issues with adding this in Release 15.
Orange: in one document you say it is left for implementation and in the other you are defining requirements.There is no time to work on this in Release 15. Let's not address this in Release 15 as pointed out to us by SA.
| not pursued | No | S3‑192053 | |
S3‑192589 | Missing UDR description in alignment with 29.505 | Nokia, Nokia Shanghai Bell | CR | Agreement |
7.1.1UDR
| Yes |
YesVodafone,NTT-Docomo and Orange didnt agree with this.Only the change in the abbreviation update was agreed. Orange added that they didnt see the consequences in stage 3 if the word "authentication" wasn't added to subscription data in the new text. Leave to CT4 to decide which kind of subscription data is stored.
NTT-Docomo replied that CT4 needed a separate place to store authentication method. Vodafone replied that this wasn't what was agreed during joint discussions with CT4.
NTT-Docomo added that the abbreviation change was only kept if used in the CRs or specification.
Orange: HSM is not used in the text.
| revised | No | S3‑192988 | S3‑192054 |
S3‑192590 | Update on ARPF | Nokia, Nokia Shanghai Bell | CR | Agreement |
7.1.1UDR
| Yes |
YesAlf (NTT-Docomo): the ARPF just stores the long-term key,"may" is not necessary. Gemalto agreed with this.
Vodafone pointed out that no standardization had to be done in Release 15 as agreed with SA.Alex (BT): this asssumes that the only attack is decrypting the data in UDR. You can also replace whatever is in the UDR. Let's do it properly in Release 16, including all possible attacks.
| revised | No | S3‑192989 | S3‑192055 |
S3‑192591 | Adding Nudr service | Nokia, Nokia Shanghai Bell | CR | Agreement |
7.1.1UDR
| Yes |
YesNokia added that this coud be done in Release 16 and proposed to not pursue it.
| not pursued | No | S3‑192056 | |
S3‑192592 | Security for non-public networks - update to S3-192453 | Qualcomm, Nokia, Nokia Shanghai Bell | draftCR | Agreement |
7.7Security for 5GS Enhanced support of Vertical and LAN Services (Vertical_LAN_SEC) (Rel-16)
| Yes |
YesThe note on Z.2.2 was reworded as Orange had issues with it. There was an agreement on non-3GPP credentials from a previous meeting and this had to be checked offline. There was also an added clarification for the use of non AKA EAP methods.
Telecom Italia: Non AKA could be confusing, it could also be TLS. Public networks non standalone are also considered here? Nokia replied that these were also considered apart and discussed offline and done in TS 33.501. Telecom Italia commented that in that case the annex was incomplete without his scenario. Orange agreed to add an editor's note on this part (security aspects for other NPN issues including integrated non public networks are FFS).
Interdigital: non-AKA should be defined here. It doesnt stand for a generic AKA but for a specific AKA. Orange preferred not to go for a definition for this term,but replace it with the specific 5G-AKA or EAP-AKA' where it corresponds. It was argued that non-AKA implied both and nothing was needed to be done for the sake of legibility of the text.
| revised | No | S3‑193049 | |
S3‑192593 | Endorsement of CR on Non-public network security | Qualcomm, Nokia, Nokia Shanghai Bell | discussion | Agreement |
7.7Security for 5GS Enhanced support of Vertical and LAN Services (Vertical_LAN_SEC) (Rel-16)
| Yes |
Yes
| noted | No | ||
S3‑192594 | TR33.819 update as baseline - editorial | Nokia, Nokia Shanghai Bell | pCR | Approval |
8.12Study on Security for 5GS Enhanced support of Vertical and LAN Services (FS_Vertical_LAN_SEC) (Rel-16)
| Yes |
Yes
| approved | No | ||
S3‑192595 | Adding intro to 33.819 | Nokia, Nokia Shanghai Bell | pCR | Approval |
8.12Study on Security for 5GS Enhanced support of Vertical and LAN Services (FS_Vertical_LAN_SEC) (Rel-16)
| Yes |
YesThe introducion needed rewording.
| noted | No | ||
S3‑192596 | TSC update | Nokia, Nokia Shanghai Bell | pCR | Approval |
8.12Study on Security for 5GS Enhanced support of Vertical and LAN Services (FS_Vertical_LAN_SEC) (Rel-16)
| Yes |
Yes
| approved | No | ||
S3‑192597 | TSC key issue on time synchronization | Nokia, Nokia Shanghai Bell | pCR | Approval |
8.12Study on Security for 5GS Enhanced support of Vertical and LAN Services (FS_Vertical_LAN_SEC) (Rel-16)
| Yes |
YesBT: what is confidentiality protection doing here if it is not plain text? It's not doing much.
| revised | No | S3‑193133 | |
S3‑192598 | Secure device identity creation for UEs in SNPNs | Nokia, Nokia Shanghai Bell, Perspecta Labs, Interdigital | pCR | Approval |
8.12Study on Security for 5GS Enhanced support of Vertical and LAN Services (FS_Vertical_LAN_SEC) (Rel-16)
| Yes |
Yes
| noted | No | ||
S3‑192599 | Key issue on Secure device identity creation for constrained devices | Nokia, Nokia Shanghai Bell, Perspecta Labs, Interdigital | pCR | Approval |
8.12Study on Security for 5GS Enhanced support of Vertical and LAN Services (FS_Vertical_LAN_SEC) (Rel-16)
| Yes |
YesOrange: secure somethng we dont know the nature of. Not keen on having this key issue.
Gemalto: key issue details are solution specific and I support Orange.
Other comments: Non-3GPP identities, difficult to define them. Not known about the identity, we cannot state how to secure it.
There were 4 companies objecting, 5 companies supporting.
This was taken offline.
| revised | No | S3‑193193 | |
S3‑192600 | Way forward on CVD and research | CableLabs, BT, Nokia | discussion | Endorsement |
6.9CVDs and Research
| Yes |
YesVodafone wasnt comfortable to having a closed group when everything done in SA3 public. On the other hand, there were weaknesses and failures that may need to be treated not publicly, so both worlds had to live together somehow.
CableLabs commented that this discussion was intended for public research papers. Vodafone commented that SA3 still needed a place to discuss sensitive issues in private. Alf (NTT-Docomo) commented that this could be done away from the SA3 process, any comments or discussions could be done privately between companies any time. 3GPP papers and work were public and companies could have their own discussions outside the 3GPP environment.
The Chair commented that there was no need to have a formal process for this in 3GPP and it should be done outside SA3's official involvement. Alex (BT) clarified that any intent to have a closed group in SA3 could be violating 3GPP working procedures. Orange and Huawei supported this.The general that this was the way to go and no closed groups should be set up.
Alf (NTT-Docomo): we may be missing a statement in the 3GPP website clarifying to researchers the way to bring in papers that fix standard security issues, by doing it via a 3GPP member company.
Apple: create an agenda item for research papers.
China Mobile: this is usually done by companies already. They can always bring CRs to fix the security issues and that should be treated as a response.
Several companies argued that there were other agenda items where this could be done.
T-Mobile: not our job to review research papers, this is done internally in our own companies. We can bring contributions to the appropriate agenda items after internal consideration.
| noted | No | S3‑191623 | |
S3‑192601 | Living Document: General SBA/SBI aspects in TS 33.117 | Nokia, Nokia Shanghai Bell | draftCR | Decision |
7.2.10Other 5G SCAS aspects
| Yes |
Yes
| approved | No | ||
S3‑192602 | Living Document: New Annex for the SEPP in TR 33.926 | Nokia, Nokia Shanghai Bell | draftCR | Approval |
7.2.7Security Edge Protection Proxy (SEPP) (TS 33.517)
| Yes |
Yes
| revised | No | S3‑193138 | |
S3‑192603 | Living Document: New Annex for the NRF in TR 33.926 | Nokia, Nokia Shanghai Bell | draftCR | Decision |
7.2.8Network Resource Function (NRF) (TS 33.518)
| Yes |
Yes
| approved | No | ||
S3‑192604 | Reply LS on Wireline Access Security Requirements | CableLabs | LS out | Approval |
8.5Study on the security of the Wireless and Wireline Convergence for the 5G system architecture (FS_5WWC_SEC) (Rel-16)
| Yes |
YesEricsson: there is a typo in BBF's LS, as they refer to security requirements in 23.501.
CableLabs clarified that they were an organization with several operators as members.
Colin (BT): we have to add requirements ourselves for this.
| revised | No | S3‑192981 | |
S3‑192605 | New WID on Security aspects of enhancements to the Service-Based 5G System Architecture | Nokia, Nokia Shanghai Bell | WID new | Agreement |
7.12New Work Item proposals
| Yes |
YesIt was pointed out that there were open items in the study that shouldn't be included in the objectives yet (e.g. N9).
NCSC preferred to have N9 interface included in the objectives.
Nokia commented that if not decided for the study, a CR could cover all the N9 issues separately. The Chair clarified that even for that CR a WID would be needed as recently pointed out by SA (new features to be covered with new WIDs and not TEI16 CRs).
Ericsson had issues with the objectives.
This was taken offline and awating for the end of the discussions in the study.
| revised | No | S3‑193055 | |
S3‑192606 | eSBA: pCR to update Solution #21 | Nokia, Nokia Shanghai Bell | pCR | Approval |
8.1Study on Security Aspects of the 5G Service Based Architecture (FS_SBA-Sec) (Rel-15)
| Yes |
YesHuawei: no need for stateful for this scenario.
| approved | No | ||
S3‑192607 | eSBA: pCR to update Evaluation of Solution #21 | Nokia, Nokia Shanghai Bell | pCR | Approval |
8.1Study on Security Aspects of the 5G Service Based Architecture (FS_SBA-Sec) (Rel-15)
| Yes |
Yes
| approved | No | ||
S3‑192608 | eSBA: pCR to update Evaluation of Solution #26 | Nokia, Nokia Shanghai Bell | pCR | Approval |
8.1Study on Security Aspects of the 5G Service Based Architecture (FS_SBA-Sec) (Rel-15)
| Yes |
Yes
| approved | No | ||
S3‑192609 | eSBA: pCR to update Evaluation of Solution #16 | Nokia, Nokia Shanghai Bell | pCR | Approval |
8.1Study on Security Aspects of the 5G Service Based Architecture (FS_SBA-Sec) (Rel-15)
| Yes |
Yes
| revised | No | S3‑193064 | |
S3‑192610 | eSBA: Add conclusion on KI #20 | Nokia, Nokia Shanghai Bell | pCR | Approval |
8.1Study on Security Aspects of the 5G Service Based Architecture (FS_SBA-Sec) (Rel-15)
| Yes |
Yes
| revised | No | S3‑193077 | |
S3‑192611 | eSBA: Add conclusion on KI #26 | Nokia, Nokia Shanghai Bell | pCR | Approval |
8.1Study on Security Aspects of the 5G Service Based Architecture (FS_SBA-Sec) (Rel-15)
| Yes |
YesChina Mobile: no difference between this and the current requirement in 33.501.
Nokia: we need to make changes to cover this interface. China Mobile disagreed and added that it was already covered.
Juniper: its written somewhere else that we need to rewrite the requirement.
Ericsson: better clarify that this applies to the roaming interface.
| revised | No | S3‑193081 | |
S3‑192612 | eSBA: Add conclusion on KI #22 | Nokia, Nokia Shanghai Bell | pCR | Approval |
8.1Study on Security Aspects of the 5G Service Based Architecture (FS_SBA-Sec) (Rel-15)
| Yes |
YesEricsson and Nokia disagreed with the conclusions for scenario D. Conflict with the following contirbution.
| merged | No | S3‑193070 | |
S3‑192613 | eSBA: Add conclusion on KI #29 | Nokia, Nokia Shanghai Bell | pCR | Approval |
8.1Study on Security Aspects of the 5G Service Based Architecture (FS_SBA-Sec) (Rel-15)
| Yes |
Yes
| revised | No | S3‑193099 | |
S3‑192614 | eSBA: Add conclusion on KI #23 | Nokia, Nokia Shanghai Bell | pCR | Approval |
8.1Study on Security Aspects of the 5G Service Based Architecture (FS_SBA-Sec) (Rel-15)
| Yes |
Yes
| revised | No | S3‑193174 | |
S3‑192615 | Discussion on registration with AMF re-allocation | ZTE Corporation | discussion | Discussion |
7.1.3Other 5G security aspects
| Yes |
Yes
| noted | No | ||
S3‑192616 | Discussion on Identity Request with AMF re-allocation | ZTE Corporation | discussion | Discussion |
7.1.3Other 5G security aspects
| Yes |
Yes
| noted | No | ||
S3‑192617 | Security for registration with AMF re-allocation | ZTE Corporation | CR | Agreement |
7.1.3Other 5G security aspects
| Yes |
YesNokia didn't believe that this was solving the issue. Huawei agreed.
| not pursued | No | ||
S3‑192618 | LS on registration and identity request issues with AMF re-allocation | ZTE Corporation | LS out | Approval |
7.1.3Other 5G security aspects
| Yes |
Yes
| noted | No | ||
S3‑192619 | Security solution for CAG | ZTE Corporation | pCR | Approval |
8.12Study on Security for 5GS Enhanced support of Vertical and LAN Services (FS_Vertical_LAN_SEC) (Rel-16)
| Yes |
Yes
| approved | No | ||
S3‑192620 | Assessment and evaluation of solution #9 | ZTE Corporation | pCR | Approval |
8.7Study on 5G security enhancement against false base stations (FS_5GFBS) (Rel-16)
| Yes |
Yes
| not treated | No | ||
S3‑192621 | Structure RAND for authentication | ZTE Corporation | pCR | Approval |
8.16Study on authentication enhancements in 5GS (FS_AUTH_ENH) (Rel-16)
| Yes |
Yes
| not treated | No | ||
S3‑192622 | Handling of Sync failure | ZTE Corporation | pCR | Approval |
8.16Study on authentication enhancements in 5GS (FS_AUTH_ENH) (Rel-16)
| Yes |
YesThales: replace ME with UE.
Orange: remove the evaluation.
Vodafone: key issues are oddly numbered throughout the document. Can we give an action to the Rapporteur to fix the skeleton and clause numbering?
Apple: security risk of using a fixed key is FFS.
| revised | No | S3‑193189 | |
S3‑192623 | Conclusion on linkability issues | ZTE Corporation | pCR | Approval |
8.16Study on authentication enhancements in 5GS (FS_AUTH_ENH) (Rel-16)
| Yes |
Yes
| not treated | No | ||
S3‑192624 | Correcting references | ZTE Corporation | CR | Agreement |
7.1.3Other 5G security aspects
| Yes |
YesEricsson: second change refer directly to TS 33.210 instead.
| revised | No | S3‑192990 | |
S3‑192625 | Removing editor notes | ZTE Corporation | CR | Agreement |
7.1.3Other 5G security aspects
| Yes |
YesAlf (NTT-Docomo): the reasons for change are not clear.
Some additional typos were suggested to be fixed in the text of the specification.
| revised | No | S3‑192991 | |
S3‑192626 | Adding abbreviation | ZTE Corporation | pCR | Approval |
7.2.9Network Exposure Function (NEF) (TS 33.519)
| Yes |
Yes
| revised | No | S3‑193025 | |
S3‑192627 | Solution on privacy protection of NSSAI | ZTE Corporation | pCR | Approval |
8.8Study on Security aspects of Enhancement of Network Slicing (FS_eNS_SEC) (Rel-16)
| Yes |
YesOrange: add editor's notes on Home network control performance, how allocation of T-NSSAI is made.
Interdigital: editor's note on effectiveness with idle mobility.
| revised | No | S3‑193125 | |
S3‑192628 | eSBA: Add conclusion on KI #24 | Nokia, Nokia Shanghai Bell | pCR | Approval |
8.1Study on Security Aspects of the 5G Service Based Architecture (FS_SBA-Sec) (Rel-15)
| Yes |
YesIt was concluded that info from SA2 was needed, hence no conclusion was to be obtained during the present meeting.
| noted | No | ||
S3‑192629 | eSBA: Add conclusion on KI #27 | Nokia, Nokia Shanghai Bell | pCR | Approval |
8.1Study on Security Aspects of the 5G Service Based Architecture (FS_SBA-Sec) (Rel-15)
| Yes |
YesChina Mobile: too early for this conclusion. We need to check with sA2.
Alex (BT): SA asked to finish this in release 15 and it's delaying deployments.
Christine (Ericsson) suggested to add abullet list in the conclusion. This was revised to introduce these changes.
Alf (NTT-Docomo): conclude now and send an LS to SA2. This is not normative.
China Mobile: I dont think this solution is solving the problem.
Deutsche Telekom: We need a solution and we have several of them available. It's not for SA3 to decide alone and we can get feedback from SA2 on the available solutions.
A number was given for a possible LS to SA2 and this was taken offline.
| revised | No | S3‑193095 | |
S3‑192630 | Discussion on the handling of native non-current 5G NAS security context after an inter-system change from S1 mode to N1 mode in idle mode | Intel Deutschland GmbH | discussion | Decision |
7.1.3Other 5G security aspects
| Yes |
Yes
| endorsed | No | ||
S3‑192631 | Correction of handling of 5G security contexts during EPS to 5GS idle mode mobility | Intel Deutschland GmbH | CR | Agreement |
7.1.3Other 5G security aspects
| Yes |
YesHuawei: remove the word "current" from the new text.
Samsung: this is not aligned with the discussion paper. They suggested some rewording for that.
Qualcomm had a similar CR in the next contribution.
| revised | No | S3‑192997 | |
S3‑192632 | Add missing message flow for Procedure for steering of UE | Intel Deutschland GmbH | CR | Agreement |
7.11.14PLMN RAT selection (Steering of Roaming) (Rel-15)
| Yes |
YesVodafone: the bullet points now dont reflect the change in the figure.
Ericsson: is this a correction? Intel replied that this was aligned with SA2. On the other hand, this didnt have to updated according to Release 16 changes since there was no significant impact.
| revised | No | S3‑193060 | |
S3‑192633 | Security solution for UE to avoid connecting to the false base station during a handover procedure | Intel Deutschland GmbH | pCR | Approval |
8.7Study on 5G security enhancement against false base stations (FS_5GFBS) (Rel-16)
| Yes |
Yes
| not treated | No | ||
S3‑192634 | eV2X: New solution for Security for eV2X unicast messages over PC5 | Intel Deutschland GmbH | pCR | Approval |
8.18Study on Security Aspects of 3GPP support for Advanced V2X Services (FS_eV2X_Sec)
| Yes |
Yes
| revised | No | S3‑193160 | |
S3‑192635 | Categorization of the test cases and other editorial corrections | Nokia, Nokia Shanghai Bell | CR | Approval |
7.2.1NR Node B (gNB) (TS 33.511)
| Yes |
YesMCC commented that it was not possible to renumber the clauses in an approved specification.
Huawei commented that there were CRs from the last meeting correcting editorial errors in these clauses. Possible conflicts had to be checked offline.
| revised | No | S3‑193003 | |
S3‑192636 | WID of 5GFBS | Apple | WID new | Approval |
7.12New Work Item proposals
| Yes |
YesOrange: there is no conclusion in the study that allows us to go for normative work. No objection to normative work for false base station, only for starting the normative work now.Qualcomm and BT were of the same opinion. NTT-Docomo proposed to postpone this until the study was finished.
Qualcomm: we should focus on studying solutions and evaluating them before starting the normative work.
CableLabs: lot of research papers on this, important to start normative work.
| revised | No | S3‑192994 | |
S3‑192637 | Conclusin of key issue#2 | Apple | pCR | Approval |
8.7Study on 5G security enhancement against false base stations (FS_5GFBS) (Rel-16)
| Yes |
YesCompeting with 791 and 866. Qualcomm asked to have a better description of the solutions in order to decide better, not a rushed conclusion should be done. Orange: specially if the solution chosen has security issues.
The Chair asked for a show of hands for the support of this document:
CableLabs, Apple,BT,Ericsson,Philips.
Then the Chair asked for another show of hands:
No support of concluding now key issue #2: Orange, Qualcomm, Huawei. NTT-Docomo,Nokia, Vodafone, Deutsche Telekom.
Who wants to conclude key issue #2: ZTE, Samsung,Ericsson, Apple, Intel.
| noted | No | ||
S3‑192638 | Update for Solution#7 | Apple | pCR | Approval |
8.7Study on 5G security enhancement against false base stations (FS_5GFBS) (Rel-16)
| Yes |
Yes
| not treated | No | ||
S3‑192639 | Evaluation for solution#14 | Apple | pCR | Approval |
8.7Study on 5G security enhancement against false base stations (FS_5GFBS) (Rel-16)
| Yes |
Yes
| not treated | No | ||
S3‑192640 | 5G paging security issue caused by false base station | Apple | pCR | Approval |
8.7Study on 5G security enhancement against false base stations (FS_5GFBS) (Rel-16)
| Yes |
Yes
| not treated | No | ||
S3‑192641 | solution for new key issue of 5G paging security issue caused by false base station | Apple | pCR | Approval |
8.7Study on 5G security enhancement against false base stations (FS_5GFBS) (Rel-16)
| Yes |
Yes
| not treated | No | ||
S3‑192642 | Protection of UeapabilityInformation | Apple | pCR | Approval |
8.7Study on 5G security enhancement against false base stations (FS_5GFBS) (Rel-16)
| Yes |
Yes
| not treated | No | ||
S3‑192643 | Update of Solution#11 | Apple | pCR | Approval |
8.7Study on 5G security enhancement against false base stations (FS_5GFBS) (Rel-16)
| Yes |
Yes
| not treated | No | ||
S3‑192644 | Meeting minutes of 5GFBS July conference call on July 18th | Apple | discussion | Information |
8.7Study on 5G security enhancement against false base stations (FS_5GFBS) (Rel-16)
| Yes |
Yes
| not treated | No | ||
S3‑192645 | Meeting minutes of 5GFBS August conference call on August 8th | Apple | discussion | Information |
8.7Study on 5G security enhancement against false base stations (FS_5GFBS) (Rel-16)
| Yes |
Yes
| not treated | No | ||
S3‑192646 | Discussion on 5G UE privacy when connecting to EPC | Apple | discussion | Agreement |
8.19Other study areas
| Yes |
Yes
| not treated | No | ||
S3‑192647 | Update to Key issue#5 in UP IP | Apple | pCR | Approval |
8.14Study on User Plane Integrity Protection (FS_UP_IP_Sec) (Rel-16)
| Yes |
YesNokia: impact on the PDCP protocol? Apple answered that she thought so.
Suresh (Nokia): the impact is not captured here.
| revised | No | S3‑193143 | |
S3‑192648 | Solution to key issue#5 in UP IP | Apple | pCR | Approval |
8.14Study on User Plane Integrity Protection (FS_UP_IP_Sec) (Rel-16)
| Yes |
YesQualcomm: the attacker could still attack the data part of the packet. I dont think this solution works.
Deutsche Telekom: this doesn't solve the problem.
Vodafone didn't find this solution workable either.
| noted | No | ||
S3‑192649 | Update to Key issue#5 in eV2X | Apple | pCR | Approval |
8.18Study on Security Aspects of 3GPP support for Advanced V2X Services (FS_eV2X_Sec)
| Yes |
YesInterdigital: this requirement is not enough.
| noted | No | ||
S3‑192650 | EAP-AKA privacy enhancement in non-3GPP access to EPS | Apple | SID new | Approval |
8.20New study item proposals
| Yes |
YesOrange: handle 3GPP and non-3GPP access. Rewrite to handle the privacy aspects EPS over 3GPP and non-3GPP accesses.
Nokia: this would increase greatly the work, and there is no time.
CableLabs supported the study.
China Mobile agreed with Nokia, the scope would be too wide if extending to 3GPP access.
Qualcomm: an attack can use a false base station, no value restricting to non 3GPP access. We had a look at this already, no need to have this SID. Operators can always move to 5G core.
Vodafone: potential solutions seem to be changing features in 3GPP due to the non 3GPP side issues, when the latter should be the ones addressing them.
Alex(BT) supported Orange and had sympathy for Qualcomm. No objection for the study, but it should be done properly by increasing the scope.
Apple clarified that the release could be 17 if necessary.
Vodafone warned that there were several companies that didnt attend SA3 as supporters. There was a reminder that the signing companies committed to contribute and participate in the study work actively.
| revised | No | S3‑192995 | |
S3‑192651 | Proposal for Key Issue#1 Conclusion | Philips International B.V. | pCR | Approval |
8.4Study on evolution of Cellular IoT security for the 5G System (FS_CIoT_sec_5G) (Rel-16)
| Yes |
YesEricsson: Change in PDCP makes it complicated. We dont support this.
| noted | No | ||
S3‑192652 | Additional Critical Assets and Threats to PGW Annex R16 | Nokia, Nokia Shanghai Bell | CR | Approval |
7.11.9Security Assurance Specifications (SCAS-SA3, SCAS_PGW, SCAS_eNB)
| Yes |
Yes
| revised | No | S3‑193033 | |
S3‑192653 | Additional Critical Assets and Threats to PGW Annex R15 | Nokia, Nokia Shanghai Bell | CR | Approval |
7.11.9Security Assurance Specifications (SCAS-SA3, SCAS_PGW, SCAS_eNB)
| Yes |
YesIt was clarified that the CR should be cat-F.
| revised | No | S3‑193031 | |
S3‑192654 | Adding Threat References to PGW Test Cases R15 | Nokia, Nokia Shanghai Bell | CR | Approval |
7.11.9Security Assurance Specifications (SCAS-SA3, SCAS_PGW, SCAS_eNB)
| Yes |
YesChanged the category to A and creating a new CR to do the correction in release 14.
| revised | No | S3‑193035 | |
S3‑192655 | Discussion Document on how to use BEST as a bearer for services and as a means to provide multiple secure channels over 1 bearer | Vodafone Espaρa SA | discussion | Discussion |
7.11.15Battery Efficient Security for very low Throughput Machine Type Communication Devices (BEST_MTC_Sec) (Rel-15)
| Yes |
Yes
| noted | No | ||
S3‑192656 | pCR to TR33.935 - Addition of Diffie - Helman Key agreements section | Vodafone Espaρa SA | pCR | Agreement |
8.13Study on LTKUP Detailed solutions (FS_LTKUP_Detail) (Rel-16)
| Yes |
Yes
| withdrawn | Yes | ||
S3‑192657 | Threat analysis on misplacement of encrypted IE in JSON object by IPX | Nokia, Nokia Shanghai Bell | draftCR | Approval |
7.2.7Security Edge Protection Proxy (SEPP) (TS 33.517)
| Yes |
YesHuawei: this is not needed. There are no threats.
Nokia: we have described an attack, of course there are threats.
| revised | No | S3‑193085 | |
S3‑192658 | Test Case: No misplacement of encrypted IE in JSON object by IPX | Nokia, Nokia Shanghai Bell | pCR | Approval |
7.2.7Security Edge Protection Proxy (SEPP) (TS 33.517)
| Yes |
Yes
| revised | No | S3‑193086 | |
S3‑192659 | pCR to 33.853 - addition of solution for LTE | Vodafone Espaρa SA | pCR | Agreement |
8.14Study on User Plane Integrity Protection (FS_UP_IP_Sec) (Rel-16)
| Yes |
YesNEC: this introduces more complexity. They didnt agree with the contribution.
Deutsche Telekom: one thing is deployment and another is technical viability. We cannot discard it just because we think it will not be deployed. BT and CableLabs agreed.
Qualcomm: first two options should go and some more technical details on the others need to be added.
Vodafone asked for support in order to create an EPC version of this paper for next meeting.
| revised | No | S3‑193144 | |
S3‑192660 | Add the missing expected format of evidence | Nokia, Nokia Shanghai Bell | pCR | Approval |
7.2.7Security Edge Protection Proxy (SEPP) (TS 33.517)
| Yes |
Yes
| approved | No | ||
S3‑192661 | WID for LTE normative work for UPIP | Vodafone Espaρa SA | WID new | Agreement |
7.12New Work Item proposals
| Yes |
YesVodafone: the SID presented for this meeting has too many changes to have the WID as it is now. Qualcomm suggested to note it since it was better to wait for the study. Vodafone commented that they would bring it for the next meeting.
| noted | No | ||
S3‑192662 | CR to 33.401 - Addition of User Plane Integrity Protection | Vodafone Espaρa SA | draftCR | Agreement |
8.14Study on User Plane Integrity Protection (FS_UP_IP_Sec) (Rel-16)
| No |
Yes
| withdrawn | Yes | ||
S3‑192663 | 33.846: mitigation against linkability attack | THALES | pCR | Approval |
8.16Study on authentication enhancements in 5GS (FS_AUTH_ENH) (Rel-16)
| Yes |
Yes
| not treated | No | ||
S3‑192664 | Discussion on the conclusion of AKMA architecture and authentication procedures | China Mobile M2M Company Ltd. | discussion | Endorsement |
8.3Study on authentication and key management for applications based on 3GPP credential in 5G IoT (FS_AKMA)(Rel-16)
| No |
Yes
| withdrawn | Yes | ||
S3‑192665 | IAB-node: terminology change | THALES, ORANGE | pCR | Approval |
8.17Study on Security for NR Integrated Access and Backhaul (FS_NR_IAB_Sec)
| Yes |
YesZte: A change more intended for a TS than for a TR.
Orange: everything we write in SA3 is about the UE and not the MT. MT is a radio concept, but we go beyond the radio part in SA3.
Ericsson: SA2 also uses MT.
| revised | No | S3‑193148 | |
S3‑192666 | Update to TR33.xxx Storage of Secure Parameters in a 5G system - addition of content to section 4 | Vodafone Espaρa SA | discussion | Decision |
8.19Other study areas
| No |
Yes
| withdrawn | Yes | ||
S3‑192667 | Update to TR33.xxx Storage of Secure Parameters in a 5G system - addition of content to section 5 | Vodafone Espaρa SA | discussion | Decision |
8.19Other study areas
| No |
Yes
| withdrawn | Yes | ||
S3‑192668 | Removing references of TS 103 383 in TS 35.231 | Orange | CR | Approval |
7.11.16Other work items
| Yes |
Yes
| revised | No | S3‑192982 | |
S3‑192669 | Removing references of TS 103 383 in TS 35.231 | Orange | CR | Approval |
7.11.16Other work items
| Yes |
Yes
| revised | No | S3‑192983 | |
S3‑192670 | Update to TR33.xxx Storage of Secure Parameters in a 5G system - addition of KI - Long term key leakage | Vodafone Espaρa SA | discussion |
8.19Other study areas
| No |
Yes
| withdrawn | Yes | |||
S3‑192671 | Removing references of TS 103 383 in TS 35.231 | Orange | CR | Approval |
7.11.16Other work items
| Yes |
Yes
| revised | No | S3‑192984 | |
S3‑192672 | Removing references of TS 103 383 in TS 35.231 | Orange | CR | Approval |
7.11.16Other work items
| Yes |
Yes
| revised | No | S3‑192985 | |
S3‑192673 | Update to TR33.xxx Storage of Secure Parameters in a 5G system - addition of KI - discovery of correct privacy service | Vodafone Espaρa SA | discussion | Decision |
8.19Other study areas
| No |
Yes
| withdrawn | Yes | ||
S3‑192674 | Conclusion on AKMA architecture and authentication procedure | China Mobile M2M Company Ltd. | pCR | Approval |
8.3Study on authentication and key management for applications based on 3GPP credential in 5G IoT (FS_AKMA)(Rel-16)
| No |
Yes
| withdrawn | Yes | ||
S3‑192675 | Discussion on the conclusion of AKMA architecture and authentication procedures | China Mobile, Nokia, Nokia Shanghai Bell | discussion | Endorsement |
8.3Study on authentication and key management for applications based on 3GPP credential in 5G IoT (FS_AKMA)(Rel-16)
| Yes |
Yes
| noted | No | ||
S3‑192676 | Complete the Evaluation for Solution #4 | Nokia, Nokia Shanghai Bell | pCR | Approval |
8.9Study on Security of the enhancement to the 5GC location services (FS_eLCS_Sec) (Rel-16)
| Yes |
YesVodafone: not clear if you are recommending it or rejecting it.
| revised | No | S3‑193127 | |
S3‑192677 | Conclusion on AKMA architecture and authentication procedure | China Mobile, Nokia, Nokia Shanghai Bell | pCR | Approval |
8.3Study on authentication and key management for applications based on 3GPP credential in 5G IoT (FS_AKMA)(Rel-16)
| Yes |
YesCompeting solution with 886.
The Chair asked for a show of hands:
- Reusing KAUSF based solution: KPN, Orange, Samsung, Qualcomm, Nokia, China Mobile,Huawei,BT (tdoc 677) --> 9 companies.
- Not reusing KAUSF (tdoc 886): Vodafone, Ericsson, CableLabs. --> 3
It was agreed to remove solution 2.
Huawei had a solution overlapping with this contribution. Qualcomm proposed to focus on this for the next meeting.
| revised | No | S3‑193170 | |
S3‑192678 | Conclusion on Key Issue #4 | Nokia, Nokia Shanghai Bell | pCR | Approval |
8.9Study on Security of the enhancement to the 5GC location services (FS_eLCS_Sec) (Rel-16)
| Yes |
Yes
| approved | No | ||
S3‑192679 | Key issue to mitigate the SUPI guessing attacks | China Mobile | pCR | Approval |
8.16Study on authentication enhancements in 5GS (FS_AUTH_ENH) (Rel-16)
| No |
Yes
| withdrawn | Yes | ||
S3‑192680 | Key issue to mitigate the SUPI guessing attacks | China Mobile | pCR | Approval |
8.16Study on authentication enhancements in 5GS (FS_AUTH_ENH) (Rel-16)
| Yes |
YesOrange: more details on the attack are needed. Bring a discussion paper for this for the next meeting.
Ericsson: I dont see the relation of this with the objectives of the study.
| noted | No | ||
S3‑192681 | A Solution for Key Isssue#2.1 and key issue #4.1 in TR 33.846 | China Mobile | pCR | Approval |
8.16Study on authentication enhancements in 5GS (FS_AUTH_ENH) (Rel-16)
| Yes |
Yes
| revised | No | S3‑193190 | |
S3‑192682 | Description of issue of security context transfer following the handover from EPS to 5GS | Huawei, Hisilicon | discussion | Discussion |
7.1.3Other 5G security aspects
| Yes |
YesEricsson: this is a valid problem.
| noted | No | ||
S3‑192683 | Security context transfer following the handover from EPS to 5GS | Huawei, Hisilicon | CR | Approval |
7.1.3Other 5G security aspects
| Yes |
YesQualcomm: this is pure network behaviour (not UICC and ME impacted). They also wanted to precise timing conditions for stage 3 for the target AMF mapping the new 5G security context.
NTT-Docomo: operators will need some implementation options for this configuration. They later withdrew this comment after offline discussions.
| revised | No | S3‑192998 | |
S3‑192684 | New solution for linkability attack | Huawei, Hisilicon | pCR | Approval |
8.16Study on authentication enhancements in 5GS (FS_AUTH_ENH) (Rel-16)
| Yes |
Yes
| not treated | No | ||
S3‑192685 | Resolving the ENs in solution #5 | Huawei, Hisilicon, Lenovo, Motorola Mobility | pCR | Approval |
8.7Study on 5G security enhancement against false base stations (FS_5GFBS) (Rel-16)
| Yes |
Yes
| not treated | No | ||
S3‑192686 | Conclusion on KI#5 of TR 33.809 | Huawei, Hisilicon | pCR | Approval |
8.7Study on 5G security enhancement against false base stations (FS_5GFBS) (Rel-16)
| Yes |
Yes
| not treated | No | ||
S3‑192687 | Update of solution #15 in TR 33.855 | Huawei, Hisilicon | pCR | Approval |
8.1Study on Security Aspects of the 5G Service Based Architecture (FS_SBA-Sec) (Rel-15)
| Yes |
YesEricsson: the evaluation needs to show the disadvantages of the solution as well.
This was taken offline.
| revised | No | S3‑193097 | |
S3‑192688 | Dealing with the EN of solution #19 in TR33.855 | Huawei, Hisilicon | pCR | Approval |
8.1Study on Security Aspects of the 5G Service Based Architecture (FS_SBA-Sec) (Rel-15)
| Yes |
Yes
| approved | No | ||
S3‑192689 | New solution for authorization within a NF Set in the roaming scenario | Huawei, Hisilicon | pCR | Approval |
8.1Study on Security Aspects of the 5G Service Based Architecture (FS_SBA-Sec) (Rel-15)
| Yes |
Yes
| approved | No | ||
S3‑192690 | Solution for CAG ID protection | Huawei, Hisilicon | pCR | Approval |
8.12Study on Security for 5GS Enhanced support of Vertical and LAN Services (FS_Vertical_LAN_SEC) (Rel-16)
| Yes |
YesInterdigital: not sure if this is compatible with existing SA2 procedures. An editor's note was added for this.
| revised | No | S3‑193141 | |
S3‑192691 | Resolving the EN in AKMA push, and adding the evaluation | Huawei, Hisilicon | pCR | Approval |
8.3Study on authentication and key management for applications based on 3GPP credential in 5G IoT (FS_AKMA)(Rel-16)
| Yes |
Yes
| not treated | No | ||
S3‑192692 | Key issue on the authenticaiton result storage in the UDM | Huawei, Hisilicon | pCR | Approval |
8.16Study on authentication enhancements in 5GS (FS_AUTH_ENH) (Rel-16)
| Yes |
YesEricsson: out of scope of the objectives of the study.
Vodafone: the title is the solution, not the key issue.
Huawei commented that last meeting SA3 decided to bring this key issue. Deutsche Telekom: the wording of the key issue is too focused on the solution already.
Orange: editor's note on the improvement of the key issue details. Remove threats and requirements.
Ericsson: link it better with the study objectives.
| revised | No | S3‑193187 | |
S3‑192693 | Resolving the ENs in Solution #25 | Huawei, Hisilicon | pCR | Approval |
8.1Study on Security Aspects of the 5G Service Based Architecture (FS_SBA-Sec) (Rel-15)
| Yes |
YesEricsson: benefit to the existing solution should be clarified in the evaluation.
| revised | No | S3‑193100 | |
S3‑192694 | eSBA: new solution for NF service consumer verification during service access authorization in indirect communication scenario | Huawei, Hisilicon | pCR | Approval |
8.1Study on Security Aspects of the 5G Service Based Architecture (FS_SBA-Sec) (Rel-15)
| Yes |
YesNTT-Docomo: the solution doesn't have any value for scenarios where there are multiple SeCoPs. Nokia supported this.
Ericsson: list all the disadvantages in the evaluation, otherwise we won't agree on this. An editor's note was added to address the scenarios where the solution didnt work.
| revised | No | S3‑193069 | |
S3‑192695 | New KI: Key issue on UP security policy handling for PC5 and Uu interface | Huawei, Hisilicon | pCR | Approval |
8.18Study on Security Aspects of 3GPP support for Advanced V2X Services (FS_eV2X_Sec)
| Yes |
Yes
| revised | No | S3‑193166 | |
S3‑192696 | UDM critical assets and threats to TR 33.926 | Huawei, Hisilicon | CR | Approval |
7.2.4Unified Data Management (UDM) (TS 33.514)
| Yes |
YesHuawei:the reference clause doesn't match the current baseline of 33.926. MCC added that the references were not used in the text,so the new references had to be removed.
| revised | No | S3‑193008 | |
S3‑192697 | Editorial change on TS 33.514 | Huawei, Hisilicon | pCR | Approval |
7.2.4Unified Data Management (UDM) (TS 33.514)
| Yes |
Yes
| approved | No | ||
S3‑192698 | AUSF critical assets and threats to TR 33.926 | Huawei, Hisilicon | CR | Approval |
7.2.6Authentication Server Function (AUSF) (TS 33.516)
| Yes |
Yes
| revised | No | S3‑193016 | |
S3‑192699 | Editorial change on TS 33.516 | Huawei, Hisilicon | pCR | Approval |
7.2.6Authentication Server Function (AUSF) (TS 33.516)
| Yes |
Yes
| approved | No | ||
S3‑192700 | Editorial changes on SEPP critical assets and threats to TR 33.926 | Huawei, Hisilicon | CR | Approval |
7.2.7Security Edge Protection Proxy (SEPP) (TS 33.517)
| Yes |
YesThis is converting the living document into a CR, but Nokia commented that there was still some input for the lviing documents so this was kept open.
| revised | No | S3‑193139 | |
S3‑192701 | Editorial change on TS 33.517 | Huawei, Hisilicon | pCR | Approval |
7.2.7Security Edge Protection Proxy (SEPP) (TS 33.517)
| Yes |
Yes
| approved | No | ||
S3‑192702 | Adding NRF critical assets and threats to TR 33.926 | Huawei, Hisilicon | CR | Approval |
7.2.8Network Resource Function (NRF) (TS 33.518)
| Yes |
YesThis is converting the living document into a CR.
| revised | No | S3‑193020 | |
S3‑192703 | Editorial change on TS 33.518 | Huawei, Hisilicon | pCR | Approval |
7.2.8Network Resource Function (NRF) (TS 33.518)
| Yes |
Yes
| approved | No | ||
S3‑192704 | Adding NEF critical assets and threats to TR 33.926 | Huawei, Hisilicon | CR | Approval |
7.2.9Network Exposure Function (NEF) (TS 33.519)
| Yes |
Yes
| revised | No | S3‑193027 | |
S3‑192705 | Adding critical assets and threats for general NFs to TR 33.926 | Huawei, Hisilicon | CR | Approval |
7.2.10Other 5G SCAS aspects
| Yes |
YesEricsson: the title of the annex is not descriptive of the network product class. This was revised to change the title.
| revised | No | S3‑193030 | |
S3‑192706 | Update of living Document: General SBA/SBI aspects in TS 33.117 | Huawei, Hisilicon | CR | Approval |
7.2.10Other 5G SCAS aspects
| Yes |
Yes
| revised | No | S3‑193029 | |
S3‑192707 | Clarification on test cases in TR 33.117 | Huawei, Hisilicon | CR | Approval |
7.11.9Security Assurance Specifications (SCAS-SA3, SCAS_PGW, SCAS_eNB)
| Yes |
YesDeutsche Telekom objected to deleting the last two bullets in the second change.
It was noted that the cover sheet referred to the wrong release and it had the wrong categroy.
| revised | No | S3‑193036 | |
S3‑192708 | Clarification on the topology hiding in SBI | Huawei, Hisilicon | CR | Approval |
7.1.3Other 5G security aspects
| Yes |
YesNokia: this is too long and confusing.
Ericsson: CT4 has decided to do this in Release 16. Let's not interfere with them.
China Mobile also wondered why this was needed in Release 15 and it should be a new feature in Release 16.
This was taken offline.
| not pursued | No | ||
S3‑192709 | Claification on UE context transfer in registration with AMF reallocation via direct NAS reroute | Huawei, Hisilicon | CR | Approval |
7.1.3Other 5G security aspects
| Yes |
YesQualcomm: the UE is not impacted, but the cover page says the same. The last sentence refers to the UE's behaviour which also implies UE impact.
This was left offline.
| revised | No | S3‑193058 | |
S3‑192710 | Solving registration failure in registration procedure with AMF reallocation | Huawei, Hisilicon, CAICT | CR | Approval |
7.1.3Other 5G security aspects
| Yes |
YesEricsson: we disagree with having the UE accepting protected messages.
This had to be taken offline.
| not pursued | No | ||
S3‑192711 | Discussing registration failure in registration procedure with AMF reallocation | Huawei, Hisilicon, CAICT | discussion | Endorsement |
7.1.3Other 5G security aspects
| Yes |
Yes
| noted | No | ||
S3‑192712 | Adding SMF critical assets and threats to TS 33.926 | Huawei, Hisilicon | CR | Approval |
7.2.5Session Management Function (SMF) (TS 33.515)
| Yes |
Yes
| revised | No | S3‑193012 | |
S3‑192713 | Editorial change on TS 33.515 | Huawei, Hisilicon | pCR | Approval |
7.2.5Session Management Function (SMF) (TS 33.515)
| Yes |
Yes
| revised | No | S3‑193013 | |
S3‑192714 | Adding AMF critical assets and threats to TS 33.926 | Huawei, Hisilicon | CR | Approval |
7.2.2Access and Mobility Management Function (TS 33.512)
| Yes |
YesDraft CR agreed in the last meeting changed to a CR.
Ericsson: N26 interface AMF to MME should be added here in critical assets.
| revised | No | S3‑193005 | |
S3‑192715 | Adding UPF critical assets and threats to TS 33.926 | Huawei, Hisilicon | CR | Approval |
7.2.3User Plane Function (UPF) (TS 33.513)
| Yes |
Yes
| revised | No | S3‑193006 | |
S3‑192716 | Editorial change on TS 33.513 | Huawei, Hisilicon | pCR | Approval |
7.2.3User Plane Function (UPF) (TS 33.513)
| Yes |
Yes
| approved | No | ||
S3‑192717 | Changes on handover from 5GS to EPS over N26 | Huawei, Hisilicon | CR | Approval |
7.1.3Other 5G security aspects
| Yes |
YesEricsson: this should be done in 8.6.2. It was commented that this was done already somewhere else.
Qualcomm:sentence above 8.3.2 is not needed. Remove as editorial.
| revised | No | S3‑192999 | |
S3‑192718 | Adding evalution to solution 3 | Huawei, HiSilicon | pCR | Approval |
8.8Study on Security aspects of Enhancement of Network Slicing (FS_eNS_SEC) (Rel-16)
| Yes |
YesNokia: slice specific authentication doesnt depend on NSaaS.
| noted | No | ||
S3‑192719 | Conclusions to KI #3 | Huawei, HiSilicon | pCR | Approval |
8.8Study on Security aspects of Enhancement of Network Slicing (FS_eNS_SEC) (Rel-16)
| Yes |
Yes
| noted | No | ||
S3‑192720 | Addressing EN in solution 6 | Huawei, HiSilicon | pCR | Approval |
8.8Study on Security aspects of Enhancement of Network Slicing (FS_eNS_SEC) (Rel-16)
| Yes |
YesNokia didnt agree with the removal of the editor's note.
Orange commented that there was a mismatch between the editor's note and the justification.No mechanism can be defined without an interface defined in 3GPP.
Potential additional text to help resolving the editor's note was taken offline.
| revised | No | S3‑193120 | |
S3‑192721 | Adding evalution to solution 6 | Huawei, HiSilicon | pCR | Approval |
8.8Study on Security aspects of Enhancement of Network Slicing (FS_eNS_SEC) (Rel-16)
| Yes |
Yes
| noted | No | ||
S3‑192722 | Addressing ENs in solution 8 | Huawei, HiSilicon | pCR | Approval |
8.8Study on Security aspects of Enhancement of Network Slicing (FS_eNS_SEC) (Rel-16)
| Yes |
Yes
| noted | No | ||
S3‑192723 | Conclusions to KI #6 | Huawei, HiSilicon | pCR | Approval |
8.8Study on Security aspects of Enhancement of Network Slicing (FS_eNS_SEC) (Rel-16)
| Yes |
Yes
| noted | No | ||
S3‑192724 | Amendment to eNS WID | Huawei, HiSilicon | pCR | Approval |
8.8Study on Security aspects of Enhancement of Network Slicing (FS_eNS_SEC) (Rel-16)
| Yes |
YesZander(Huawei) commented that key issue 3,4 and 6 were to be removed. This was intended to conclude the WID. The vice chair (NTT-Docomo) commented that this seemed to be content for the WID summary input hat is usually sent to plenary to describe work items. No need to update the WID after the work has been done.
It was clarified that this was an update of the WID agreed in Sapporo and that it hadn't been seen in SA plenary yet.
Orange: why the key issues in a WID? We never do this.
Vodafone: reject this document, we have a WID already.
| noted | No | ||
S3‑192725 | Conclusions to KI #4 | Huawei, HiSilicon | pCR | Approval |
8.8Study on Security aspects of Enhancement of Network Slicing (FS_eNS_SEC) (Rel-16)
| Yes |
Yes
| noted | No | ||
S3‑192726 | Slice-specific authentication | Huawei, HiSilicon | draftCR | Agreement |
7.10Security aspects of Enhanced Network Slicing (eNS_SEC) (Rel-16)
| Yes |
YesNokia: postpone this for next meeting.
Vodafone: how is the network going to agree with what methods are going to be used? We need a framework, there are lot of options.
Telecom Italia: the slice is internal by definition, not be confused with secondary autentication.
Huawei conceded and promised to bring contributions to address all concerns.
| noted | No | ||
S3‑192727 | Solution on Cross-RAT PC5 control authorization indication | Huawei, HiSilicon | pCR | Approval |
8.18Study on Security Aspects of 3GPP support for Advanced V2X Services (FS_eV2X_Sec)
| Yes |
Yes
| approved | No | ||
S3‑192728 | Resolving the Editor's note for Solution 5 in TR 33.853 | China Mobile | pCR | Approval |
8.14Study on User Plane Integrity Protection (FS_UP_IP_Sec) (Rel-16)
| Yes |
YesQualcomm: I don't believe this is true, but maybe we could send an LS to a RAN group to ask for their opinion. The editor's note should stay.
Colin (BT):
| revised | No | S3‑193145 | |
S3‑192729 | Resolve EN "signaling details of how the UE hands over to false base station | Huawei, HiSilicon | pCR | Approval |
8.7Study on 5G security enhancement against false base stations (FS_5GFBS) (Rel-16)
| Yes |
Yes
| not treated | No | ||
S3‑192730 | Resolve the second and third EN in Solution #6 | Huawei, HiSilicon | pCR | Approval |
8.7Study on 5G security enhancement against false base stations (FS_5GFBS) (Rel-16)
| Yes |
Yes
| not treated | No | ||
S3‑192731 | Solution#4: resolving EN network verification of the hashes of MIB/SIBs | Huawei, HiSilicon | pCR | Approval |
8.7Study on 5G security enhancement against false base stations (FS_5GFBS) (Rel-16)
| Yes |
Yes
| not treated | No | ||
S3‑192732 | Solution#4: Resolving EN Impact on UE power consumption | Huawei, HiSilicon | pCR | Approval |
8.7Study on 5G security enhancement against false base stations (FS_5GFBS) (Rel-16)
| Yes |
Yes
| not treated | No | ||
S3‑192733 | Solution #4: Details on the hash algorithm used for MIB/SIB hashes. | Huawei, HiSilicon | pCR | Approval |
8.7Study on 5G security enhancement against false base stations (FS_5GFBS) (Rel-16)
| Yes |
Yes
| not treated | No | ||
S3‑192734 | Address EN in solution #1 | Huawei, HiSilicon | pCR | Approval |
8.7Study on 5G security enhancement against false base stations (FS_5GFBS) (Rel-16)
| Yes |
Yes
| not treated | No | ||
S3‑192735 | Enabling UE to detect FBS | Huawei, HiSilicon | pCR | Approval |
8.7Study on 5G security enhancement against false base stations (FS_5GFBS) (Rel-16)
| Yes |
Yes
| not treated | No | ||
S3‑192736 | preventing the UE from reselecting to the false base station | Huawei, HiSilicon | pCR | Approval |
8.7Study on 5G security enhancement against false base stations (FS_5GFBS) (Rel-16)
| Yes |
Yes
| not treated | No | ||
S3‑192737 | Avoiding UE from Suffering More MitM Attacks by Handover | Huawei, HiSilicon | pCR | Approval |
8.7Study on 5G security enhancement against false base stations (FS_5GFBS) (Rel-16)
| Yes |
Yes
| not treated | No | ||
S3‑192738 | Evaluation of solution #6 | Huawei, HiSilicon | pCR | Approval |
8.7Study on 5G security enhancement against false base stations (FS_5GFBS) (Rel-16)
| Yes |
Yes
| not treated | No | ||
S3‑192739 | LS to RAN2 on FBS detection | Huawei, HiSilicon | LS out | Approval |
8.7Study on 5G security enhancement against false base stations (FS_5GFBS) (Rel-16)
| Yes |
YesNTT-Docomo found this OK.
Huawei clarified that the two solutions would be attached to the LS.
Orange: study not finished, make it clear that more solutions may be available and these are not the final options.
Qualcomm: are we asking RAN2 to evaluate the solutions? Huawei replied that this was not a security issue. Qualcomm replied that no questions were asked but an evaluation was being asked. The Chair commented that this had been done in the past.
| revised | No | S3‑193175 | |
S3‑192740 | Conclustion for Key issue #3 | Huawei, HiSilicon | pCR | Approval |
8.7Study on 5G security enhancement against false base stations (FS_5GFBS) (Rel-16)
| Yes |
Yes
| not treated | No | ||
S3‑192741 | V2X Group Key Provisioning | Lenovo, Motorola Mobility | pCR | Approval |
8.18Study on Security Aspects of 3GPP support for Advanced V2X Services (FS_eV2X_Sec)
| Yes |
YesInterdigital proposed an editor's note on the solution working our of coverage. This was agreed.
An additional editor's note on SA2's decision on the group management was also added.
| revised | No | S3‑193163 | |
S3‑192742 | Removal of Editors Notes of solution #5 | Lenovo, Motorola Mobility | pCR | Approval |
8.8Study on Security aspects of Enhancement of Network Slicing (FS_eNS_SEC) (Rel-16)
| Yes |
YesNokia: no solutions are offered but editor's notes are gone.
Orange: keep the editor's notes.
Ericsson: the serving network is trusted, that's the asssumption. Keep the first editor's note at least.
Qualcomm preferred to keep the editor's notes.
| noted | No | ||
S3‑192743 | Update of Solution #15 | Lenovo, Motorola Mobility | pCR | Approval |
8.7Study on 5G security enhancement against false base stations (FS_5GFBS) (Rel-16)
| Yes |
Yes
| not treated | No | ||
S3‑192744 | New Key Issue on Rejected S-NSSAI Revokation | Lenovo, Motorola Mobility | pCR | Approval |
8.8Study on Security aspects of Enhancement of Network Slicing (FS_eNS_SEC) (Rel-16)
| Yes |
YesZander (Huawei): it's about cancelation not revocation. This is misleading.
Nokia: no standardised procedure when the primary authentication is cancelled, why do we have it here?
Vodafone favoured having this key issue, whereas Interdigital had some concerns.
Ericsson: if this is stage 3 issue as Lenovo said, why is this being treated here? Lenovo replied that it touched authentication issues.
Nokia: we cannot mandate a particular behaviour in this scenario.
It was taken offline to see if it was possible to add an editor's note to reach an agreement.
| revised | No | S3‑193201 | |
S3‑192745 | Solution on Slice Authentication Revokation | Lenovo, Motorola Mobility | pCR | Approval |
8.8Study on Security aspects of Enhancement of Network Slicing (FS_eNS_SEC) (Rel-16)
| Yes |
Yes
| noted | No | ||
S3‑192746 | User ID privacy | Lenovo, Motorola Mobility, Huawei | discussion | Approval |
8.8Study on Security aspects of Enhancement of Network Slicing (FS_eNS_SEC) (Rel-16)
| Yes |
Yes
| noted | No | ||
S3‑192747 | Clarification in Solution 12 | Huawei, Hisilicon | pCR | Approval |
8.6Study on Security Aspects of PARLOS (FS_PARLOS_Sec) (Rel-16)
| Yes |
Yes
| revised | No | S3‑192967 | |
S3‑192748 | The solution to protect MIB/SIB information | Huawei, Hisilicon | pCR | Approval |
8.9Study on Security of the enhancement to the 5GC location services (FS_eLCS_Sec) (Rel-16)
| Yes |
Yes
| revised | No | S3‑192968 | |
S3‑192749 | Key issue on removal of USIM card in IAB node | Huawei, Hisilicon | pCR | Approval |
8.20New study item proposals
| Yes |
Yes
| revised | No | S3‑192969 | |
S3‑192750 | Proposed solution on protecting the SQN during a re-synchronisation procedure in AKA | Huawei, Hisilicon | pCR | Approval |
8.19Other study areas
| Yes |
Yes
| revised | No | S3‑192970 | |
S3‑192751 | conclusion on KI#4 | Huawei, Hisilicon | pCR | Approval |
8.12Study on Security for 5GS Enhanced support of Vertical and LAN Services (FS_Vertical_LAN_SEC) (Rel-16)
| Yes |
Yes
| revised | No | S3‑192971 | |
S3‑192752 | mitigate the linkability attack | Huawei, Hisilicon | pCR | Approval |
8.19Other study areas
| Yes |
Yes
| revised | No | S3‑192972 | |
S3‑192753 | Implicite AKMA authenticaiton procedure | Huawei, Hisilicon | pCR | Approval |
8.3Study on authentication and key management for applications based on 3GPP credential in 5G IoT (FS_AKMA)(Rel-16)
| Yes |
Yes
| not treated | No | ||
S3‑192754 | Address two Editors Note of solution 4 | Huawei, Hisilicon | pCR | Approval |
8.5Study on the security of the Wireless and Wireline Convergence for the 5G system architecture (FS_5WWC_SEC) (Rel-16)
| Yes |
YesTelecom Italia: Is W-5GAN something other than a network element? Where is the calculation described performed?
Huawei: We agreed last meeting that W-5GAN will construct the SUCI. It is defined in SA2 as a network element.
Ericsson: this is not exactly the agreement we had. Just remove the editor's note and dont add new text since it is covered somewhere else.
| revised | No | S3‑193109 | |
S3‑192755 | Address two Editors Note of solution 6 | Huawei, Hisilicon | pCR | Approval |
8.5Study on the security of the Wireless and Wireline Convergence for the 5G system architecture (FS_5WWC_SEC) (Rel-16)
| Yes |
Yes
| approved | No | ||
S3‑192756 | Address an Editors Note and add evaluation for solution 7 | Huawei, Hisilicon | pCR | Approval |
8.5Study on the security of the Wireless and Wireline Convergence for the 5G system architecture (FS_5WWC_SEC) (Rel-16)
| Yes |
YesEricsson: you need keys and integrity protection.
| noted | No | ||
S3‑192757 | Add evaluation for solution 8 | Huawei, Hisilicon | pCR | Approval |
8.5Study on the security of the Wireless and Wireline Convergence for the 5G system architecture (FS_5WWC_SEC) (Rel-16)
| Yes |
YesEricsson: DTLS is also used.
Huawei:it's part of the NDS/IP in the same clause as 33.501.
Nokia: what is the evaluation if it is only stating what's in the solution?
Huawei: this wording is used everywhere else in the TR.
| approved | No | ||
S3‑192758 | Add conclusion for KI#2 | Huawei, Hisilicon | pCR | Approval |
8.5Study on the security of the Wireless and Wireline Convergence for the 5G system architecture (FS_5WWC_SEC) (Rel-16)
| Yes |
Yes
| revised | No | S3‑193112 | |
S3‑192759 | completing TR 33807 | Huawei, Hisilicon | pCR | Approval |
8.5Study on the security of the Wireless and Wireline Convergence for the 5G system architecture (FS_5WWC_SEC) (Rel-16)
| Yes |
Yes
| approved | No | ||
S3‑192760 | skeleton of 5WWC | Huawei, Hisilicon | other | Approval |
7.9Security of the Wireless and Wireline Convergence for the 5G system architecture (5WWC_SEC) (Rel-16)
| Yes |
YesEricsson: better to add another subclause than renaming existing ones. Nokia agreed with this.MCC commented that it was better to add subclauses for the wireline access and the non-3GPP access: 7a and 7b.
| revised | No | S3‑193053 | |
S3‑192761 | Update testcase of 4.2.4.1.1.2 and 4.2.4.1.1.3 | Huawei, Hisilicon | CR | Approval |
7.11.9Security Assurance Specifications (SCAS-SA3, SCAS_PGW, SCAS_eNB)
| Yes |
Yes
| agreed | No | ||
S3‑192762 | Update test cases for 4.3.2.3,4.3.2.4, and 4.3.2.5 | Huawei, Hisilicon | CR | Approval |
7.11.9Security Assurance Specifications (SCAS-SA3, SCAS_PGW, SCAS_eNB)
| Yes |
YesDeutsche Telekom wasn't fine with this.
| not pursued | No | ||
S3‑192763 | Update requirements and test cases for gNB SCAS | Huawei, Hisilicon | CR | Approval |
7.2.1NR Node B (gNB) (TS 33.511)
| Yes |
YesNokia: in 33.117 this was already conditional. Not sure that this test case is needed.
MCC: The new clause has the wrong numbering, and there seems to be missing clauses from the baseline and a hangning paragraph.
| revised | No | S3‑193004 | |
S3‑192764 | Update requirements and test cases for eNB SCAS | Huawei, Hisilicon | CR | Approval |
7.11.9Security Assurance Specifications (SCAS-SA3, SCAS_PGW, SCAS_eNB)
| Yes |
Yes
| revised | No | S3‑193041 | |
S3‑192765 | Completing 33825 | Huawei, Hisilicon | pCR | Approval |
8.10Study on security for 5G URLLC (FS_5G URLLC_SEC) (Rel-16)
| Yes |
YesTelecom Italia: why is the editor's note converted into a note? Huawei replied that there was no conclusion about that in the study.
Colin (BT): low latency specific work hasnt been done in this document.
| approved | No | ||
S3‑192766 | draftCR for URLLC | Huawei, Hisilicon | draftCR | Approval |
7.6Security of URLLC for 5GS (5G_URLLC_SEC) (Rel-16)
| Yes |
YesEricsson preferred to move content to an annex instead of deleting the text.
| revised | No | S3‑193048 | |
S3‑192767 | Discussion on security of MSG2 MT-EDT solution | Huawei, Hisilicon | discussion | Decision |
7.11.10Security Aspects of Narrowband IOT (CIoT)
| Yes |
Yes
| noted | No | ||
S3‑192768 | Reply LS on Security of MT-EDT | Huawei, Hisilicon | LS out | Approval |
7.11.10Security Aspects of Narrowband IOT (CIoT)
| Yes |
Yes
| noted | No | ||
S3‑192769 | Address EN in key issue 13 and solution 20 | Huawei, Hisilicon | pCR | Approval |
8.4Study on evolution of Cellular IoT security for the 5G System (FS_CIoT_sec_5G) (Rel-16)
| Yes |
YesMCC commented that the change still had the same meaning as an editor's note.
Ericsson commented that the first editor's note should stay in order to follow SA2's work.
NTT-Docomo also wanted to keep it since it was an outstanding issue that needed to be addressed.
| revised | No | S3‑193102 | |
S3‑192770 | Conclusion for Key Issue #13 | Huawei, Hisilicon | pCR | Approval |
8.4Study on evolution of Cellular IoT security for the 5G System (FS_CIoT_sec_5G) (Rel-16)
| Yes |
YesQualcomm: remove the second paragraph.
| revised | No | S3‑193108 | |
S3‑192771 | Address EN in solution 21 | Huawei, Hisilicon | pCR | Approval |
8.4Study on evolution of Cellular IoT security for the 5G System (FS_CIoT_sec_5G) (Rel-16)
| Yes |
Yes
| approved | No | ||
S3‑192772 | Conclusion for Key Issue #11 | Huawei, Hisilicon | pCR | Approval |
8.4Study on evolution of Cellular IoT security for the 5G System (FS_CIoT_sec_5G) (Rel-16)
| Yes |
YesEricsson preferred to wait for the next meeting since they had a competing solution.
| noted | No | ||
S3‑192773 | Address EN in solution 19 | Huawei, Hisilicon | pCR | Approval |
8.4Study on evolution of Cellular IoT security for the 5G System (FS_CIoT_sec_5G) (Rel-16)
| Yes |
YesEricssson: add statement in the efficiency part about the solution based on this.
| revised | No | S3‑193105 | |
S3‑192774 | Discussion on Mitigation of DDoS attack | Huawei, Hisilicon | discussion | Endorsement |
8.4Study on evolution of Cellular IoT security for the 5G System (FS_CIoT_sec_5G) (Rel-16)
| Yes |
Yes
| noted | No | ||
S3‑192775 | Security handling in Control Plane User Data for Control Plane Optimization for 5GS CIoT | Huawei, Hisilicon | other | Approval |
7.8Security of Cellular IoT for 5GS (CIoT_sec_5G) (Rel-16)
| Yes |
YesNokia: security for the control plane hasn't been handled yet in the study. This can be addressed in the next meeting.
Qualcomm: no need to rush, the second paragraph is still being discussed in CT1. Martin (AT&T) commented that no assumptions could be done in the control plane since there were still numerous discussions in CT1.
This topic was postponed for the next meeting.
| noted | No | ||
S3‑192776 | Protection of Non-IP Data Delivery (NIDD) interfaces | Huawei, Hisilicon | other | Approval |
7.8Security of Cellular IoT for 5GS (CIoT_sec_5G) (Rel-16)
| Yes |
Yes
| approved | No | ||
S3‑192777 | Clarification for Secondary Authentication | Huawei, Hisilicon | CR | Approval |
7.1.3Other 5G security aspects
| Yes |
Yes
| revised | No | S3‑192993 | |
S3‑192778 | Wayforward for TR 33.809 | Huawei, Hisilicon | discussion | Discussion |
8.7Study on 5G security enhancement against false base stations (FS_5GFBS) (Rel-16)
| Yes |
Yes
| noted | No | ||
S3‑192779 | Discussion on Conclusion for Protection of RRC Reject message | Huawei, Hisilicon | discussion | Decision |
8.7Study on 5G security enhancement against false base stations (FS_5GFBS) (Rel-16)
| Yes |
Yes
| noted | No | ||
S3‑192780 | Address EN in solution 16 | Huawei, Hisilicon | pCR | Approval |
8.7Study on 5G security enhancement against false base stations (FS_5GFBS) (Rel-16)
| Yes |
Yes
| not treated | No | ||
S3‑192781 | Conclusion for Key Issue #1 for RRC Reject | Huawei, Hisilicon | pCR | Approval |
8.7Study on 5G security enhancement against false base stations (FS_5GFBS) (Rel-16)
| Yes |
Yes
| noted | No | ||
S3‑192782 | LS to RAN2 on Protection of RRC Reject Message | Huawei, Hisilicon | LS out | Approval |
8.7Study on 5G security enhancement against false base stations (FS_5GFBS) (Rel-16)
| Yes |
Yes
| not treated | No | ||
S3‑192783 | Update on Protection of RRC Resume Request message | Huawei, Hisilicon | pCR | Approval |
8.7Study on 5G security enhancement against false base stations (FS_5GFBS) (Rel-16)
| Yes |
YesApple didn't agree with the solution.
| noted | No | ||
S3‑192784 | Conclusion for Key Issue #1 for RRC Resume Request Protection | Huawei, Hisilicon | pCR | Approval |
8.7Study on 5G security enhancement against false base stations (FS_5GFBS) (Rel-16)
| Yes |
Yes
| noted | No | ||
S3‑192785 | Solution for Protection of NAS Reject Message | Huawei, Hisilicon | pCR | Approval |
8.7Study on 5G security enhancement against false base stations (FS_5GFBS) (Rel-16)
| Yes |
YesEricsson and Qualcomm didn't agree: NAS messages from the serving network is a bit weird.
| noted | No | ||
S3‑192786 | Conclusion for Key Issue #1 for NAS Reject | Huawei, Hisilicon | pCR | Approval |
8.7Study on 5G security enhancement against false base stations (FS_5GFBS) (Rel-16)
| Yes |
Yes
| noted | No | ||
S3‑192787 | Solution for Avoiding UE connecting to False Base Station during Conditional Handover | Huawei, Hisilicon | pCR | Approval |
8.7Study on 5G security enhancement against false base stations (FS_5GFBS) (Rel-16)
| Yes |
Yes
| not treated | No | ||
S3‑192788 | Resovle Editor's notes in Solution for Key freshness in AKMA | Huawei, Hisilicon | pCR | Approval |
8.3Study on authentication and key management for applications based on 3GPP credential in 5G IoT (FS_AKMA)(Rel-16)
| Yes |
YesEricsson: why using RAND? This was removed.
| revised | No | S3‑193171 | |
S3‑192789 | Mitigate DDoS Attack on RAN based on RAN coordination | Huawei, Hisilicon | pCR | Approval |
8.4Study on evolution of Cellular IoT security for the 5G System (FS_CIoT_sec_5G) (Rel-16)
| Yes |
YesEricsson: editor's note on synchronising the list in RAN.
| revised | No | S3‑193106 | |
S3‑192790 | conclusion on KI#5 | Huawei, Hisilicon | pCR | Approval |
8.4Study on evolution of Cellular IoT security for the 5G System (FS_CIoT_sec_5G) (Rel-16)
| Yes |
Yes
| noted | No | ||
S3‑192791 | conclusion on KI#2 | Huawei, Hisilicon | pCR | Approval |
8.7Study on 5G security enhancement against false base stations (FS_5GFBS) (Rel-16)
| Yes |
Yes
| noted | No | ||
S3‑192792 | Discussion on the procedure of secondary authentication | China Mobile | discussion | Discussion |
7.1.3Other 5G security aspects
| Yes |
YesHuawei: this point has been clarified already in SA2 already.Just one clarification is needed in step 8.
Nokia: Exchange of MAC and IP will happen later than step 8.
China Mobile: this may impact SA2 specifications so we need to know if they accept this kind of change.
Ericsson was OK with this approach.
| not pursued | No | ||
S3‑192793 | Modification of the message name in the key derivation during handover | CATT | CR | Agreement |
7.1.3Other 5G security aspects
| Yes |
YesEricsson: not a FASMO change. This is not needed.
Alf (NTT-Docomo): this is being used in SA2 and we have a chance of aligning stage 3 with SA2.
| not pursued | No | ||
S3‑192794 | Adjust the proceudure of GPSI and IP/MAC notification | China Mobile | CR | Approval |
7.1.3Other 5G security aspects
| Yes |
YesHuawei: call flow needs to be updated.
Qualcomm: the baseline is wrong, showing only some steps.
| revised | No | S3‑192992 | |
S3‑192795 | Conclusion for KI#7 and KI#8 | Ericsson | pCR | Approval |
8.5Study on the security of the Wireless and Wireline Convergence for the 5G system architecture (FS_5WWC_SEC) (Rel-16)
| Yes |
Yes
| approved | No | ||
S3‑192796 | Removal of EN in Solution #7 | Ericsson | pCR | Approval |
8.5Study on the security of the Wireless and Wireline Convergence for the 5G system architecture (FS_5WWC_SEC) (Rel-16)
| Yes |
Yes
| approved | No | ||
S3‑192797 | Conclusion on KI#15 | Ericsson | pCR | Approval |
8.5Study on the security of the Wireless and Wireline Convergence for the 5G system architecture (FS_5WWC_SEC) (Rel-16)
| Yes |
Yes
| revised | No | S3‑193192 | |
S3‑192798 | Conclusion on KI#9 | Ericsson | pCR | Approval |
8.5Study on the security of the Wireless and Wireline Convergence for the 5G system architecture (FS_5WWC_SEC) (Rel-16)
| Yes |
Yes
| approved | No | ||
S3‑192799 | Editorial changes to Solution #7 | Ericsson | pCR | Approval |
8.5Study on the security of the Wireless and Wireline Convergence for the 5G system architecture (FS_5WWC_SEC) (Rel-16)
| Yes |
Yes
| approved | No | ||
S3‑192800 | Evaluation of Solution #7 | Ericsson | pCR | Approval |
8.5Study on the security of the Wireless and Wireline Convergence for the 5G system architecture (FS_5WWC_SEC) (Rel-16)
| Yes |
Yes
| approved | No | ||
S3‑192801 | New Solution for a UE connected to 5GC indicating its support of UP IP over eUTRA | Ericsson | pCR | Approval |
8.14Study on User Plane Integrity Protection (FS_UP_IP_Sec) (Rel-16)
| Yes |
Yes
| revised | No | S3‑193146 | |
S3‑192802 | Update of Solution #23 (Token-based authorization for Scenario D using stateless SeCoP) | Ericsson | pCR | Approval |
8.1Study on Security Aspects of the 5G Service Based Architecture (FS_SBA-Sec) (Rel-15)
| Yes |
YesHuawei: make sure that this is aligned with release 15.
Nokia: in deployments where there are hierarchical NRFs you have to rely on an implicit trust model. In those scenarios the trust model relies on delegated trust.
| approved | No | ||
S3‑192803 | Update of Solution #24 (Token-based authorization for Scenario C using stateless SeCoP) | Ericsson | pCR | Approval |
8.1Study on Security Aspects of the 5G Service Based Architecture (FS_SBA-Sec) (Rel-15)
| Yes |
Yes
| revised | No | S3‑193067 | |
S3‑192804 | Evaluation for Solution #23 (Token-based authorization for Scenario D using stateless SeCoP) | Ericsson | pCR | Approval |
8.1Study on Security Aspects of the 5G Service Based Architecture (FS_SBA-Sec) (Rel-15)
| Yes |
Yes
| revised | No | S3‑193066 | |
S3‑192805 | Evaluation for Solution #24 (Token-based authorization for Scenario C using stateless SeCoP) | Ericsson | pCR | Approval |
8.1Study on Security Aspects of the 5G Service Based Architecture (FS_SBA-Sec) (Rel-15)
| Yes |
Yes
| revised | No | S3‑193068 | |
S3‑192806 | Conclusion of Key Issue #22 (Authorization of NF service access in indirect communication) | Ericsson | pCR | Approval |
8.1Study on Security Aspects of the 5G Service Based Architecture (FS_SBA-Sec) (Rel-15)
| Yes |
Yes
| revised | No | S3‑193070 | |
S3‑192807 | New solution: Telescopic FQDN for the SeCoP | Ericsson | pCR | Approval |
8.1Study on Security Aspects of the 5G Service Based Architecture (FS_SBA-Sec) (Rel-15)
| Yes |
YesIt was agreed to send an editor's note about the stage 3 solution for routing. The evaluation was also removed.
| revised | No | S3‑193075 | |
S3‑192808 | New solution: Token-based authorization for NF Sets / NF Service Sets by existing methods | Ericsson | pCR | Approval |
8.1Study on Security Aspects of the 5G Service Based Architecture (FS_SBA-Sec) (Rel-15)
| Yes |
Yes
| revised | No | S3‑193079 | |
S3‑192809 | Conclusion of Key Issue #24 (Service access authorization within a NF Set or a NF Service Set) | Ericsson | pCR | Approval |
8.1Study on Security Aspects of the 5G Service Based Architecture (FS_SBA-Sec) (Rel-15)
| Yes |
Yes
| noted | No | ||
S3‑192810 | Conclusion of Key Issue #26: Protection of N9 interface | Ericsson | pCR | Approval |
8.1Study on Security Aspects of the 5G Service Based Architecture (FS_SBA-Sec) (Rel-15)
| Yes |
Yes
| merged | No | S3‑193081 | |
S3‑192811 | Update of Key issue #26: Protection of N9 interface | Ericsson | pCR | Approval |
8.1Study on Security Aspects of the 5G Service Based Architecture (FS_SBA-Sec) (Rel-15)
| Yes |
YesJuniper,China Mobile supported this. There was no clear requirement.
| approved | No | ||
S3‑192812 | Conclusion of Key Issue #28: Service access authorization in the delegated "Subscribe-Notify" scenarios | Ericsson | pCR | Approval |
8.1Study on Security Aspects of the 5G Service Based Architecture (FS_SBA-Sec) (Rel-15)
| Yes |
YesHuawei and Nokia didnt agree with the conclusion.
| noted | No | ||
S3‑192813 | Conclusion of Key Issue #20: Protection of SeCoP interfaces | Ericsson | pCR | Approval |
8.1Study on Security Aspects of the 5G Service Based Architecture (FS_SBA-Sec) (Rel-15)
| Yes |
Yes
| noted | No | ||
S3‑192814 | Conclusion of Key Issue #21: Secure message transport via the SeCoP | Ericsson | pCR | Approval |
8.1Study on Security Aspects of the 5G Service Based Architecture (FS_SBA-Sec) (Rel-15)
| Yes |
Yes
| revised | No | S3‑193078 | |
S3‑192815 | New solution: Authorization between Network Functions in Scenario D | Ericsson | pCR | Approval |
8.1Study on Security Aspects of the 5G Service Based Architecture (FS_SBA-Sec) (Rel-15)
| Yes |
Yes
| approved | No | ||
S3‑192816 | Conclusion of Key Issue #23: NF to NF authentication and authorization in Indirect communication | Ericsson | pCR | Approval |
8.1Study on Security Aspects of the 5G Service Based Architecture (FS_SBA-Sec) (Rel-15)
| Yes |
Yes
| merged | No | S3‑193174 | |
S3‑192817 | New Solution: resource level authorization using access tokens | Ericsson | pCR | Approval |
8.1Study on Security Aspects of the 5G Service Based Architecture (FS_SBA-Sec) (Rel-15)
| Yes |
Yes
| revised | No | S3‑193098 | |
S3‑192818 | UP Gateway deployments | Ericsson | pCR | Approval |
8.1Study on Security Aspects of the 5G Service Based Architecture (FS_SBA-Sec) (Rel-15)
| Yes |
YesHuawei: we need feedback from SA2 for the deployment options and see if there are any security concerns in them.
Deustche Telekom supported querying SA2. China Mobile as well.
Revised to add some editor's notes.
| revised | No | S3‑193082 | |
S3‑192819 | ARPF Deployment models | Ericsson | discussion | Discussion |
8.19Other study areas
| Yes |
Yes
| not treated | No | ||
S3‑192820 | Security Parameter Storage | Ericsson | discussion | Discussion |
8.19Other study areas
| Yes |
Yes
| not treated | No | ||
S3‑192821 | Privacy Aspects of ARPF deployment | Ericsson | discussion | Discussion |
8.19Other study areas
| Yes |
Yes
| not treated | No | ||
S3‑192822 | Draft CR as a living baseline for 5GS LCS normative work | Ericsson | draftCR | Approval |
8.9Study on Security of the enhancement to the 5GC location services (FS_eLCS_Sec) (Rel-16)
| Yes |
YesIt was clarified that this was merely for information.
Qualcomm commented that a separate specification may be needed instead and that the level of details for stage 3 parameters was too high.
The vice Chair (NTT-Docomo) clarified that there was a WID for the current meeting and this could be a possible output for that WID.
| noted | No | ||
S3‑192823 | Test cases referring to TS 33.117 | Ericsson | CR | Agreement |
7.2.1NR Node B (gNB) (TS 33.511)
| Yes |
YesHuawei suggested to handle these test cases for the next meeting in order to introduce modifications and not to remove them. Nokia agreed with Ericsson; no need to modify, but remove them.
Reformulate or convert them to negative tests: Steffan (Deutsche Telekom)
There was an agreement that the relevant test cases have a problem that needed to be addressed for the next meeting.
.
| not pursued | No | S3‑193001 | |
S3‑192824 | Test cases referring to TS 33.117 | Ericsson | pCR | Approval |
7.2.2Access and Mobility Management Function (TS 33.512)
| Yes |
Yes
| approved | No | ||
S3‑192825 | IAB: Assumptions related to key hierarchy in IAB architecture in 5G | Ericsson | pCR | Approval |
8.17Study on Security for NR Integrated Access and Backhaul (FS_NR_IAB_Sec)
| Yes |
Yes
| revised | No | S3‑193150 | |
S3‑192826 | KI #2.3: security threats and potential requirements | Ericsson | pCR | Approval |
8.17Study on Security for NR Integrated Access and Backhaul (FS_NR_IAB_Sec)
| Yes |
YesQualcomm and Huawei disagreed with the security requirement. This was gone.
Nokia: add an editor's note on additional threat parameters that could be included here.
| revised | No | S3‑193153 | |
S3‑192827 | New solution: secure recovery from backhaul-RLF | Ericsson | pCR | Approval |
8.17Study on Security for NR Integrated Access and Backhaul (FS_NR_IAB_Sec)
| Yes |
YesQualcomm had numerous comments and preferred to have it noted. Huawei had the same opinion.
| noted | No | ||
S3‑192828 | New WID on security of the enhancement to the 5GC location services | CATT | WID new | Agreement |
7.12New Work Item proposals
| Yes |
YesVodafone: I would like to see these features as optional for the supervision of these measurements. This may have privacy issues.
AT&T commented that this was not the case of a third party making use of this data. This was not a concern for this group and that would take privacy too far. Rules and regulations of a specific country were not part of this study.
Colin (BT): it needs to be optional because the results can be corrupted or forged.
Alf(NTT-Docomo: add privacy as an objective.
Christine (Ericsson): make clear that if data is collected, that data should not be sent. Nokia replied that the UE would collect only if configured for that. It would be a deployment choice, optional.
The Chair asked if there were any objections to this WID and Vodafone reiterated his comment on the privacy issue and the optionality.
Marcus (Huawei): if they say in SA2 that this feature is optional, our work in here would be optional as well.
Alex agreed with Vodafone, given the controversy of the topic. They didnt mind these capabilities but not having any restrictions wouldn't be very clever.
This was taken offline.
| revised | No | S3‑193056 | |
S3‑192829 | Modification of solution#1 | China Mobile | pCR | Approval |
8.8Study on Security aspects of Enhancement of Network Slicing (FS_eNS_SEC) (Rel-16)
| Yes |
YesThis scenarion was not covered earlier. No need to address it right now.
Interdigital: SA1 is covering this now in a WID (LUCIA).
Orange: this is going beyond slices, and some part of this may be covered by SA5. SA2 will handle LUCIA in their own WID and then SA3 will create a WID based on what SA2 is doing.
| noted | No | ||
S3‑192830 | New WID on security aspect of network analytic services | China Mobile M2M Company Ltd. | WID new | Approval |
7.12New Work Item proposals
| Yes |
YesVodafone: normally we should have a discussion paper presenting this or a previous study item. They saw no rush for not having a discussion paper first.
Nokia: a study is not needed for this. It's about security between two network functions defined in TS 33.501.
Ericsson: agree with being an usual network domain security.
China Mobile: no study item needed, just small requirements and in that case we wouldn't be able to reach the release 16 deadline and we would have no security solution in this release for this issue.
It was clarified that the WID could be brought to plenary together with the necessary CRs in one go in case there were timing problems.
The Chair asked if any offline discussion would help. Vodafone still found problematic not being able to discuss with a paper first.
| noted | No | ||
S3‑192831 | Discussion on study on user plane security termination point in 5GC | CATT | discussion | Endorsement |
8.20New study item proposals
| Yes |
Yes
| withdrawn | Yes | ||
S3‑192832 | Adding gap analysis into clause 4.3.1 | China Mobile | pCR | Approval |
8.11Study on SECAM and SCAS for 3GPP virtualized network products (FS_VNP_SECAM_SCAS) (Rel-16)
| Yes |
Yes
| approved | No | ||
S3‑192833 | Correction to test case requirement reference | L.M. Ericsson Limited | CR | Agreement |
7.2.1NR Node B (gNB) (TS 33.511)
| Yes |
Yes
| agreed | No | ||
S3‑192834 | Adding contents into clause 4.4 | China Mobile | pCR | Approval |
8.11Study on SECAM and SCAS for 3GPP virtualized network products (FS_VNP_SECAM_SCAS) (Rel-16)
| Yes |
Yes
| approved | No | ||
S3‑192835 | Adding contents into clause 4.5 | China Mobile | pCR | Approval |
8.11Study on SECAM and SCAS for 3GPP virtualized network products (FS_VNP_SECAM_SCAS) (Rel-16)
| Yes |
Yes
| approved | No | ||
S3‑192836 | Resolving editors note and adding example of role instantiation into clause 4.6 | China Mobile | pCR | Approval |
8.11Study on SECAM and SCAS for 3GPP virtualized network products (FS_VNP_SECAM_SCAS) (Rel-16)
| Yes |
Yes
| approved | No | ||
S3‑192837 | Adding contents into clause 4.7 | China Mobile | pCR | Approval |
8.11Study on SECAM and SCAS for 3GPP virtualized network products (FS_VNP_SECAM_SCAS) (Rel-16)
| Yes |
Yes
| approved | No | ||
S3‑192838 | Adding contents into clause 4.8 | China Mobile | pCR | Approval |
8.11Study on SECAM and SCAS for 3GPP virtualized network products (FS_VNP_SECAM_SCAS) (Rel-16)
| Yes |
Yes
| revised | No | S3‑193181 | |
S3‑192839 | Adding contents into clause 4.8 | China Mobile M2M Company Ltd. | pCR | Approval |
8.11Study on SECAM and SCAS for 3GPP virtualized network products (FS_VNP_SECAM_SCAS) (Rel-16)
| Yes |
Yes
| approved | No | ||
S3‑192840 | Adding writing process overview into clause 5.1 | China Mobile M2M Company Ltd. | pCR | Approval |
8.11Study on SECAM and SCAS for 3GPP virtualized network products (FS_VNP_SECAM_SCAS) (Rel-16)
| Yes |
Yes
| approved | No | ||
S3‑192841 | Adding the description of the parts in SCAS documents and ToE into clause 5.2.1 and 5.2.2 | China Mobile M2M Company Ltd. | pCR |
8.11Study on SECAM and SCAS for 3GPP virtualized network products (FS_VNP_SECAM_SCAS) (Rel-16)
| Yes |
Yes
| revised | No | S3‑193182 | ||
S3‑192842 | Adding the description of Generic Vitualized Network Product model of type 1 | China Mobile | pCR | Approval |
8.11Study on SECAM and SCAS for 3GPP virtualized network products (FS_VNP_SECAM_SCAS) (Rel-16)
| Yes |
YesFuturewei suggested to update the figure in the future for more accuracy, and this was added in an editor's note.
Nokia: FFS how ETSI defined interfaces are mapped to 3GPP interfaces.
CableLabs: add references where the ETSI interfaces are explained.
| revised | No | S3‑193183 | |
S3‑192843 | Adding the description for generic virtualized network product model of type 2 | China Mobile M2M Company Ltd. | pCR | Approval |
8.11Study on SECAM and SCAS for 3GPP virtualized network products (FS_VNP_SECAM_SCAS) (Rel-16)
| Yes |
Yes
| revised | No | S3‑193184 | |
S3‑192844 | Adding the description for generic virtualized network product model of type 3 | China Mobile | pCR | Approval |
8.11Study on SECAM and SCAS for 3GPP virtualized network products (FS_VNP_SECAM_SCAS) (Rel-16)
| Yes |
Yes
| not treated | No | ||
S3‑192845 | Adding SPD for virtualized network products into clause 5.2.3 | China Mobile M2M Company Ltd. | pCR | Approval |
8.11Study on SECAM and SCAS for 3GPP virtualized network products (FS_VNP_SECAM_SCAS) (Rel-16)
| Yes |
Yes
| not treated | No | ||
S3‑192846 | Adding Generic assets and threats of GVNP for type 2 into clause 5.2.3.3 | China Mobile | pCR | Approval |
8.11Study on SECAM and SCAS for 3GPP virtualized network products (FS_VNP_SECAM_SCAS) (Rel-16)
| Yes |
Yes
| not treated | No | ||
S3‑192847 | Adding Generic assets and threats of GVNP for type 3 into clause 5.2.3.4 | China Mobile | pCR | Approval |
8.11Study on SECAM and SCAS for 3GPP virtualized network products (FS_VNP_SECAM_SCAS) (Rel-16)
| Yes |
Yes
| not treated | No | ||
S3‑192848 | Adding evaluation to Solution 7 | Ericsson | pCR | Approval |
8.8Study on Security aspects of Enhancement of Network Slicing (FS_eNS_SEC) (Rel-16)
| Yes |
Yes
| revised | No | S3‑193121 | |
S3‑192849 | Discussion on AUSF role | Ericsson | discussion | Endorsement |
8.8Study on Security aspects of Enhancement of Network Slicing (FS_eNS_SEC) (Rel-16)
| Yes |
YesQualcomm: this is not a security issue.
Ericsson: we agreed to use something and SA2 has agreed to use something else.
Nokia checked with SA2 colleagues and they replied that they did it for the routing in roaming situations.
Lenovo agreed with Ericsson.
| noted | No | ||
S3‑192850 | Draft LS on AUSF role | Ericsson | LS out | Approval |
8.8Study on Security aspects of Enhancement of Network Slicing (FS_eNS_SEC) (Rel-16)
| Yes |
YesZander (Huawei): I agree that there is no security reason behind having the AUSF. Qualcomm added that there was no security either with including it.
Marcus (Futurewei): the AUSF could introduce security problems, we dont know.
This had to be taken offline; there was disagreement on the possibility of security issues due to introducing the AUSF.
| revised | No | S3‑193126 | |
S3‑192851 | Conclusion on KI#6 | Ericsson, Nokia | pCR | Approval |
8.8Study on Security aspects of Enhancement of Network Slicing (FS_eNS_SEC) (Rel-16)
| Yes |
Yes
| noted | No | ||
S3‑192852 | Reference syntax updates | Ericsson | pCR | Approval |
8.8Study on Security aspects of Enhancement of Network Slicing (FS_eNS_SEC) (Rel-16)
| Yes |
Yes
| approved | No | ||
S3‑192853 | Conclusion on key issue #2 | China Mobile | pCR | Approval |
8.3Study on authentication and key management for applications based on 3GPP credential in 5G IoT (FS_AKMA)(Rel-16)
| Yes |
Yes
| not treated | No | ||
S3‑192854 | Evaluation of solution #6 | China Mobile M2M Company Ltd. | pCR | Approval |
8.3Study on authentication and key management for applications based on 3GPP credential in 5G IoT (FS_AKMA)(Rel-16)
| Yes |
Yes
| not treated | No | ||
S3‑192855 | Evaluation of solution#1 | China Mobile M2M Company Ltd. | pCR | Approval |
8.3Study on authentication and key management for applications based on 3GPP credential in 5G IoT (FS_AKMA)(Rel-16)
| Yes |
Yes
| not treated | No | ||
S3‑192856 | Evaluations of solution #7- #12 | China Mobile | pCR | Approval |
8.3Study on authentication and key management for applications based on 3GPP credential in 5G IoT (FS_AKMA)(Rel-16)
| Yes |
Yes
| not treated | No | ||
S3‑192857 | [DRAFT] Reply LS on Mobile-terminated Early Data Transmission | Ericsson | LS out |
7.11.10Security Aspects of Narrowband IOT (CIoT)
| Yes |
Yes
| noted | No | |||
S3‑192858 | Disucssion on security of MT-EDT | Ericsson | discussion |
7.11.10Security Aspects of Narrowband IOT (CIoT)
| Yes |
YesQualcomm, Intel: no need for message 4 solution.
Nokia: we should answer both message 2 and 4 solutions.
| noted | No | |||
S3‑192859 | New WID on Authentication and Key Management for Applications based on 3GPP credential in 5G | China Mobile | WID new | Approval |
7.12New Work Item proposals
| Yes |
YesOrange: why involving SA2?
China Mobile: for architecture issues. This was taken offline.
| revised | No | S3‑193178 | |
S3‑192860 | Resolving EN in 33855 6.18 N9 NDS/IP | Juniper Networks | pCR | Agreement |
8.1Study on Security Aspects of the 5G Service Based Architecture (FS_SBA-Sec) (Rel-15)
| Yes |
Yes
| noted | No | ||
S3‑192861 | Security of RRC UE capability transfer procedure in EPS | Ericsson | CR | Agreement |
7.11.1SAE/LTE Security
| Yes |
YesNokia: not only control optimization UEs but applicable for all UEs.
NTT-Docomo: if the UE does not AES security this is not going to work.This doesnt provide security for control optimized Ues/ CIoT. They wanted to create an action item/editor's note to provide the missing part in the future; an additional problem that needed to be fixed.
It was commented that this was enoug to respond to the LS but the CIoT scenario needed to be considered as well in the future.
The Chair commented that a quick answer was needed since this affected release 15; if the new problem was in release 15, this would need to be told to other WGs.
This was taken offline.
| revised | No | S3‑193074 | |
S3‑192862 | Security of RRC UE capability transfer procedure in 5GS | Ericsson | CR | Agreement |
7.1.3Other 5G security aspects
| Yes |
YesQualcomm: this wont work with CIoT Ues that dont support AES security.it's probably OK to release 15 (we dont support CIoT optimizations there) but not for the other releases.
| agreed | No | ||
S3‑192863 | Way forward - KI#1 Proposal#1 UE caps | Ericsson, Nokia, Vodafone, Deutsche Telekom AG, CableLabs, LG Electronics, Samsung, Apple | pCR | Approval |
8.7Study on 5G security enhancement against false base stations (FS_5GFBS) (Rel-16)
| Yes |
YesIt was clarified that no additonal normative work is needed since this had been taken care of in a CR for TS 33.501. This was introduced in the conclusion.
| revised | No | S3‑193173 | |
S3‑192864 | Way forward - KI#1 Proposal#2 RRC reject | Ericsson, Nokia, Vodafone, Deutsche Telekom AG, CableLabs, LG Electronics, Apple | pCR | Approval |
8.7Study on 5G security enhancement against false base stations (FS_5GFBS) (Rel-16)
| Yes |
YesSamsung preferred to keep this open until the next meeting. They didn't agree with the evaluation. Qualcomm: put the evaluation in the solution, it's not part of the text now.
Qualcomm: the point is to add the reason why we got to this conclusion with a proper evaluation, especially for external readers who may come with additional papers in the future.They were OK with the conclusion but just wanted to add some more text into the conclusion part from the analysis.
Huawei didnt agree with this contribution.
| noted | No | ||
S3‑192865 | Way forward - KI#1 Proposal#3 RRC Resume | Ericsson, Nokia, Vodafone, Deutsche Telekom AG, CableLabs, LG Electronics, Apple | pCR | Approval |
8.7Study on 5G security enhancement against false base stations (FS_5GFBS) (Rel-16)
| Yes |
YesQualcomm: we dont have a solution for this way forward. I agree with this conclusion, but the solution was removed. Orange agreed.
| noted | No | ||
S3‑192866 | Way forward - KI#2 Proposal#4 SI protection | Ericsson, Nokia, Vodafone, Deutsche Telekom AG, CableLabs, AT&T, NIST, CATT, China Unicom, Apple, Samsung | pCR | Approval |
8.7Study on 5G security enhancement against false base stations (FS_5GFBS) (Rel-16)
| Yes |
YesQualcomm: we cannot reach a conclusion now, it's premature. We like the Huawei approach, but this needs further analysis.
Orange: in this case we have several several solutions with advantages and disadvantages, its not like the AKMA situation.
| noted | No | ||
S3‑192867 | Way forward - KI#3 Proposal#5 False RBS detection | Ericsson, Nokia, Vodafone, Deutsche Telekom AG, CableLabs, LG Electronics | pCR | Approval |
8.7Study on 5G security enhancement against false base stations (FS_5GFBS) (Rel-16)
| Yes |
YesNTT-Docomo: not a conclusion Just send the LS and then write the conclusion.
Qualcomm: we already have an informative annex in 33.501. What's the value of this here without an evaluation? UE-based approaches, network-based approaches in the market already, we need to be more informative about this.
Qualcomm: RAN will not give us an useful answer for an LS.
A draft LS was available in tdoc 739.
| noted | No | ||
S3‑192868 | Way forward - KI#3 Proposal#6 False RBS handover | Ericsson, Nokia, Vodafone, Deutsche Telekom AG, CableLabs, LG Electronics, Samsung | pCR | Approval |
8.7Study on 5G security enhancement against false base stations (FS_5GFBS) (Rel-16)
| Yes |
Yes
| not treated | No | ||
S3‑192869 | Way forward - KI#4 Proposal#7 SON poisoining | Ericsson, Nokia, Vodafone, Deutsche Telekom AG, CableLabs, LG Electronics | pCR | Approval |
8.7Study on 5G security enhancement against false base stations (FS_5GFBS) (Rel-16)
| Yes |
Yes
| not treated | No | ||
S3‑192870 | Way forward - KI#5 Proposal#8 Auth replay | Ericsson, Nokia, Vodafone, Deutsche Telekom AG, CableLabs, LG Electronics, Samsung, Apple | pCR | Approval |
8.7Study on 5G security enhancement against false base stations (FS_5GFBS) (Rel-16)
| Yes |
Yes
| not treated | No | ||
S3‑192871 | Way forward - KI#6 Proposal#9 radio jamming | Ericsson, Nokia, Vodafone, Deutsche Telekom AG, CableLabs, LG Electronics, Apple, Samsung | pCR | Approval |
8.7Study on 5G security enhancement against false base stations (FS_5GFBS) (Rel-16)
| Yes |
Yes
| not treated | No | ||
S3‑192872 | Way forward - KI#7 Proposal#10 MitM | Ericsson, Nokia, Vodafone, Deutsche Telekom AG, CableLabs, LG Electronics, Samsung | pCR | Approval |
8.7Study on 5G security enhancement against false base stations (FS_5GFBS) (Rel-16)
| Yes |
Yes
| not treated | No | ||
S3‑192873 | Introduction to URLLC services | Ericsson | draftCR | Approval |
7.6Security of URLLC for 5GS (5G_URLLC_SEC) (Rel-16)
| Yes |
Yes
| merged | No | S3‑193048 | |
S3‑192874 | Retaining AS security keys for redundant data transmission in user plane | Ericsson | draftCR | Approval |
7.6Security of URLLC for 5GS (5G_URLLC_SEC) (Rel-16)
| Yes |
YesQualcomm: there is nothing new here, what is the reference for?
| noted | No | ||
S3‑192875 | Redundant paths using Dual Connectivity for URLLC services - introduction | Ericsson | draftCR | Approval |
7.6Security of URLLC for 5GS (5G_URLLC_SEC) (Rel-16)
| Yes |
Yes
| merged | No | S3‑193048 | |
S3‑192876 | Redundant paths using Dual Connectivity for URLLC services security keys derivation | Ericsson | draftCR | Approval |
7.6Security of URLLC for 5GS (5G_URLLC_SEC) (Rel-16)
| Yes |
YesQualcomm: this clause is not needed. Huawei agreed, but the content could be added to the introduction. This was agreed.
| merged | No | S3‑193048 | |
S3‑192877 | Redundant paths using Dual Connectivity for URLLC services - security policy aspects | Ericsson | draftCR | Approval |
7.6Security of URLLC for 5GS (5G_URLLC_SEC) (Rel-16)
| Yes |
YesThe use of "should" in the second paragraph had to be removed given that Qualcomm argued that this had to be a "shall" and there was no agreement.
| merged | No | S3‑193048 | |
S3‑192878 | Redundant paths using Dual Connectivity for URLLC services UP security activation status | Ericsson | draftCR | Approval |
7.6Security of URLLC for 5GS (5G_URLLC_SEC) (Rel-16)
| Yes |
Yes
| merged | No | S3‑193048 | |
S3‑192879 | New KI: Security of session anchor keys in case the long-term key is leaked | Ericsson | pCR | Approval |
8.16Study on authentication enhancements in 5GS (FS_AUTH_ENH) (Rel-16)
| Yes |
YesVodafone objected to this key issue. Orange wasn't happy with this either.
Thales didn't support this either and commented that this had been brought several times before and rejected.
Vodafone: this needs to be updated with the discussions we've had before: rewording the key issue especially.
Ericsson decided to keep discussing this offline and bring an update for the next meeting.
| noted | No | ||
S3‑192880 | New Solution:EAP-AKA΄ PFS | Ericsson | pCR | Approval |
8.16Study on authentication enhancements in 5GS (FS_AUTH_ENH) (Rel-16)
| Yes |
Yes
| noted | No | ||
S3‑192881 | New solution: Integrating GBA to 5GC | Ericsson, Vodafone | pCR | Approval |
8.3Study on authentication and key management for applications based on 3GPP credential in 5G IoT (FS_AKMA)(Rel-16)
| Yes |
Yes
| not treated | No | ||
S3‑192882 | New conclusions for GBA in 5GC | Ericsson, Vodafone | pCR | Approval |
8.3Study on authentication and key management for applications based on 3GPP credential in 5G IoT (FS_AKMA)(Rel-16)
| Yes |
Yes
| not treated | No | ||
S3‑192883 | Work item on integrating GBA to 5GC | Ericsson, Vodafone | WID new | Approval |
7.12New Work Item proposals
| Yes |
YesQualcomm: this is a good idea and should be kept separate from the AKMA work item.
We dont know about the impact on the ME and UICC.
Vodafone: this is changing GBA specs and the AKMA WID is changing TS 33.501, so that's why they have to be separate.
Huawei: no study item for this, and there are GBA functions that need consideration when treated in a service based architecture. We would need to consult SA2 about this. Ericsson replied that SA2 had looked at this and it was concluded that a Service Based Interface was needed.
Vodafone clarified that this was coming from the results from the AKMA study.
Nokia commented that GBA was a standalone specification in LTE. Martin (AT&T) replied that GBA would not be the same case in 5G.
Qualcomm argued that the deadlines were too tight and that the WID should enter into the release 17 timeline.
| revised | No | S3‑193200 | |
S3‑192884 | Evaluation of solution 13 | Ericsson | pCR | Approval |
8.3Study on authentication and key management for applications based on 3GPP credential in 5G IoT (FS_AKMA)(Rel-16)
| Yes |
Yes
| approved | No | ||
S3‑192885 | Solution #15 updates including evaluation update | Ericsson | pCR | Approval |
8.3Study on authentication and key management for applications based on 3GPP credential in 5G IoT (FS_AKMA)(Rel-16)
| Yes |
YesVodafone: nowhere it's said whether the solution is good or bad. No advantages or disadvantages. Added an editor's note for this.
| revised | No | S3‑193169 | |
S3‑192886 | Conclusion for AKMA architecture and authentication | Ericsson | pCR | Approval |
8.3Study on authentication and key management for applications based on 3GPP credential in 5G IoT (FS_AKMA)(Rel-16)
| Yes |
Yes
| noted | No | ||
S3‑192887 | Discussion about AMF re-allocation and slicing | Ericsson | discussion | Approval |
7.1.3Other 5G security aspects
| Yes |
YesHuawei just supported number 7. China Mobile didnt support proposal 2.
Ericsson commented that the purpose was to send an LS on the agreed proposals after offline discussion (tdoc 889 was the baseline for that LS).
Huawei: the term default AMF is not adequate, since it's an SA2 term. Ericsson replied that SA3 could ask them to re-adapt that term to SA3's conclusions.
This was taken offline.
| noted | No | ||
S3‑192888 | AMF re-allocation and slicing | Ericsson | CR | Approval |
7.1.3Other 5G security aspects
| Yes |
YesNokia: no need to have a new clause on this.
This was left offline together with the related documents.
| not pursued | No | ||
S3‑192889 | LS on AMF reallocation between Network Slices | Ericsson | LS out | Approval |
7.1.3Other 5G security aspects
| Yes |
Yes
| noted | No | ||
S3‑192890 | Threats and Requirements for Key Issue #2 | Nokia, Nokia Shanghai Bell | pCR | Approval |
8.15Study on Security Impacts of Virtualisation (FS_SIV) (Rel-16)
| Yes |
Yes
| revised | No | S3‑193091 | |
S3‑192891 | Threats and Requirements for Key Issue #3 | Nokia, Nokia Shanghai Bell | pCR | Approval |
8.15Study on Security Impacts of Virtualisation (FS_SIV) (Rel-16)
| Yes |
Yes
| revised | No | S3‑193092 | |
S3‑192892 | Threats and Requirements for Key Issue #4 | Nokia, Nokia Shanghai Bell | pCR | Approval |
8.15Study on Security Impacts of Virtualisation (FS_SIV) (Rel-16)
| Yes |
Yes
| merged | No | S3‑193093 | |
S3‑192893 | Conclusion on KI#5 | Ericsson, Qualcomm Incorporated | pCR | Approval |
8.4Study on evolution of Cellular IoT security for the 5G System (FS_CIoT_sec_5G) (Rel-16)
| Yes |
YesNokia supported this conclusion.
| noted | No | ||
S3‑192894 | Conclusion on KI#4 | Ericsson, Qualcomm Incorporated | pCR | Approval |
8.4Study on evolution of Cellular IoT security for the 5G System (FS_CIoT_sec_5G) (Rel-16)
| Yes |
Yes
| noted | No | ||
S3‑192895 | Evaluation to Sol#4 | Ericsson, Intel | pCR | Approval |
8.4Study on evolution of Cellular IoT security for the 5G System (FS_CIoT_sec_5G) (Rel-16)
| Yes |
YesQualcomm suggested some rewording in the last paragraph.
| revised | No | S3‑193104 | |
S3‑192896 | Conclusion on KI#2 | Ericsson, Qualcomm Incorporated, Intel | pCR | Approval |
8.4Study on evolution of Cellular IoT security for the 5G System (FS_CIoT_sec_5G) (Rel-16)
| Yes |
YesMCC commented that the text read like an editor's note, but it was fine as long as this was updated once the study in 33.853 was concluded as the text said.
| approved | No | ||
S3‑192897 | CIOT: New solution for UP IP in PDCP to protect UL EDT data in Msg3 | Ericsson, Qualcomm Incorporated,Intel | pCR | Approval |
8.4Study on evolution of Cellular IoT security for the 5G System (FS_CIoT_sec_5G) (Rel-16)
| Yes |
Yes
| approved | No | ||
S3‑192898 | CIOT: New solution for protection of NAS Redirection message | Ericsson | pCR | Approval |
8.4Study on evolution of Cellular IoT security for the 5G System (FS_CIoT_sec_5G) (Rel-16)
| Yes |
YesHuawei: editor's note on signalling overhead.
| revised | No | S3‑193107 | |
S3‑192899 | Threats and Requirements for Key Issue #5 | Nokia, Nokia Shanghai Bell | pCR | Approval |
8.15Study on Security Impacts of Virtualisation (FS_SIV) (Rel-16)
| Yes |
Yes
| revised | No | S3‑193094 | |
S3‑192900 | Threats and Requirements for Key Issue #8 | Nokia, Nokia Shanghai Bell | pCR | Approval |
8.15Study on Security Impacts of Virtualisation (FS_SIV) (Rel-16)
| Yes |
Yes
| not treated | No | ||
S3‑192901 | Threats and Requirements for Key Issue #13 | Nokia, Nokia Shanghai Bell | pCR | Approval |
8.15Study on Security Impacts of Virtualisation (FS_SIV) (Rel-16)
| Yes |
Yes
| not treated | No | ||
S3‑192902 | Resolving Editors Note in Solution #1 | Samsung | pCR | Approval |
8.14Study on User Plane Integrity Protection (FS_UP_IP_Sec) (Rel-16)
| Yes |
YesQualcomm didnt agree with this analysis.
Nokia didnt agree with the new sentence.
There was no support for this paper.
| noted | No | ||
S3‑192903 | SID on Rel16 onwards Storage of Secure Parameters in a 5G system | Vodafone Espaρa SA | SID new | Agreement |
8.20New study item proposals
| Yes |
YesCableLabs supported this SID.
Deutsche Telekom: what is a secure parameter? It's about parameters to be secured. Vodafone: This is a section in CT4 identifying what parameters need to be secure.
Nokia objected to this SID. Looking at security parameters could be done without a SID, business as usual. There are no objectives here, just have an understanding of the parameters which is part of the ongoing work with CT4.
The objectives discussion had to be taken offline.
MCC commented that there was no need to have release 16 in the title or acronym since it would apply to release 16 anyway.
NTT-Docomo: not so simple to have everything done in Release 16.
Nokia: the LS from CT4 asked us to consider, they didnt request us.
| revised | No | S3‑193057 | |
S3‑192904 | Threats and Requirements for Key Issue #17 | Nokia, Nokia Shanghai Bell | pCR | Approval |
8.15Study on Security Impacts of Virtualisation (FS_SIV) (Rel-16)
| Yes |
Yes
| not treated | No | ||
S3‑192905 | Conclusion to Key Issue #5 | Samsung | pCR |
8.14Study on User Plane Integrity Protection (FS_UP_IP_Sec) (Rel-16)
| Yes |
Yes
| noted | No | |||
S3‑192906 | Threats and Requirements for Key Issue #18 | Nokia, Nokia Shanghai Bell | pCR | Approval |
8.15Study on Security Impacts of Virtualisation (FS_SIV) (Rel-16)
| Yes |
Yes
| not treated | No | ||
S3‑192907 | New WID on Security aspects of SEAL | Samsung | WID new | Approval |
7.12New Work Item proposals
| Yes |
YesNokia: is this part of Release 16?
Samsung: it's part of Release 16 in SA6 and CT.
Vodafone: no discussion documents to support this. Why is it important to agree on this WID now if we have no documents discussing this?
AT&T supported this WID and commented that the work was complete in SA6 and there was a request to do the security part.
Colin (BT): representatives of vertical industries in SA6? It's hard to understand their requirements if they dont attend 3GPP meetings. We would need their input. Samsung replied that they were there and had requirements on the security aspects.
Vodafone: where is the security evaluation to be done in SA3?
Nokia: ideally we would need an LS from SA6 at least to make an assesment on the security implications.
Qualcomm: objectives are too broad.
This had to be taken offline.
| revised | No | S3‑193071 | |
S3‑192908 | Threats and Requirements for Key Issue #20 | Nokia, Nokia Shanghai Bell | pCR | Approval |
8.15Study on Security Impacts of Virtualisation (FS_SIV) (Rel-16)
| Yes |
Yes
| not treated | No | ||
S3‑192909 | New WID on Security for NR Integrated Access and Backhaul | Samsung | WID new |
7.12New Work Item proposals
| Yes |
Yes
| revised | No | S3‑193073 | ||
S3‑192910 | Threats and Requirements for Key Issue #21 | Nokia, Nokia Shanghai Bell | pCR | Approval |
8.15Study on Security Impacts of Virtualisation (FS_SIV) (Rel-16)
| Yes |
Yes
| not treated | No | ||
S3‑192911 | Requirement on authorization of IAB Node | Samsung | pCR | Approval |
8.17Study on Security for NR Integrated Access and Backhaul (FS_NR_IAB_Sec)
| Yes |
YesQualcomm: what does "evaluated" mean in the requirement? This was reworded.
| revised | No | S3‑193151 | |
S3‑192912 | Solution for authorization of IAB Node | Samsung | pCR | Approval |
8.17Study on Security for NR Integrated Access and Backhaul (FS_NR_IAB_Sec)
| Yes |
YesQualcomm: the description is incomplete.
| revised | No | S3‑193152 | |
S3‑192913 | P-CR: Editorial cleanup of editor's notes | Sprint Corporation | pCR | Agreement |
8.6Study on Security Aspects of PARLOS (FS_PARLOS_Sec) (Rel-16)
| Yes |
Yes
| approved | No | ||
S3‑192914 | Evaluation of solution #2.1 | Samsung | pCR | Approval |
8.17Study on Security for NR Integrated Access and Backhaul (FS_NR_IAB_Sec)
| Yes |
YesOrange: the solution is not clear. I cannot evaluate this.
| noted | No | ||
S3‑192915 | Evaluation of solution #3.1 | Samsung | pCR | Approval |
8.17Study on Security for NR Integrated Access and Backhaul (FS_NR_IAB_Sec)
| Yes |
YesQualcomm opposed to having this. This was noted.
| noted | No | ||
S3‑192916 | New KI: Botnet threats caused from improper CIOT device usage | NIST, ATT, SPRINT, CABLE LABS, CISCO | pCR | Approval |
8.4Study on evolution of Cellular IoT security for the 5G System (FS_CIoT_sec_5G) (Rel-16)
| Yes |
YesHuawei: no need for the key issue and the requirement is too solution-specific.
This is conflicting/overlapping with key issue 4.
Colin (BT): how are devices identified?
CableLabs: this is additional info on the device. Identification is not an issue here.
Qualcomm: this is not specific to 3GPP access, not sure if this is in scope. We need something to establish trust between device and capabilities otherwise it can be compromised.
| revised | No | S3‑193101 | |
S3‑192917 | Conclusion to Key Issue#2.1 on authentication and authorization of the IAB Node | Samsung | pCR | Approval |
8.17Study on Security for NR Integrated Access and Backhaul (FS_NR_IAB_Sec)
| Yes |
Yes
| noted | No | ||
S3‑192918 | Adding K5GSRVCC as a possible input key to derive IKSRVCC and CKSRVCC | Qualcomm Incorporated | CR | Agreement |
7.4Security aspects of single radio voice continuity from 5GS to UTRAN (5GS_UTRAN_SEC) (Rel-16)
| Yes |
Yes
| revised | No | S3‑193047 | S3‑192338 |
S3‑192919 | Update of Authentication Enhancements SID | Qualcomm Incorporated | SID revised | Agreement |
8.16Study on authentication enhancements in 5GS (FS_AUTH_ENH) (Rel-16)
| Yes |
Yes
| revised | No | S3‑193186 | |
S3‑192920 | Proposed re-wording of the requirement in key issue #4.1 in TR 33.846 | Qualcomm Incorporated | pCR | Approval |
8.16Study on authentication enhancements in 5GS (FS_AUTH_ENH) (Rel-16)
| Yes |
Yes
| approved | No | ||
S3‑192921 | Using MACS to provide freshness for the protection of SQN during a re-synchronisation procedure in AKA | Qualcomm Incorporated | pCR | Approval |
8.16Study on authentication enhancements in 5GS (FS_AUTH_ENH) (Rel-16)
| Yes |
Yes
| not treated | No | S3‑191908 | |
S3‑192922 | Draft CR for SRVCC 5G to UTRAN | China Unicom, Qualcomm Incoporated | draftCR | Approval |
7.4Security aspects of single radio voice continuity from 5GS to UTRAN (5GS_UTRAN_SEC) (Rel-16)
| Yes |
YesIt was argued whether the CR could be ready for the current meeting to finalise the work for once and all, but the Rapporteur needed to be consulted since she was absent.
| revised | No | S3‑193045 | S3‑192335 |
S3‑192923 | Correction to figure in draft CR for 5G to UTRAN CS SRVCC | Qualcomm Incorporated, China Unicom | other | Approval |
7.4Security aspects of single radio voice continuity from 5GS to UTRAN (5GS_UTRAN_SEC) (Rel-16)
| Yes |
Yes
| revised | No | S3‑193044 | |
S3‑192924 | Some proposed editorial changes to NPN draft CR | Qualcomm Incorporated, Nokia, Nokia Shanghai Bell | other | Approval |
7.7Security for 5GS Enhanced support of Vertical and LAN Services (Vertical_LAN_SEC) (Rel-16)
| Yes |
Yes
| approved | No | ||
S3‑192925 | Proposed conclusion to key issue 6.3 on modifying the CAG list | Qualcomm Incorporated | pCR | Approval |
8.12Study on Security for 5GS Enhanced support of Vertical and LAN Services (FS_Vertical_LAN_SEC) (Rel-16)
| Yes |
Yes
| approved | No | ||
S3‑192926 | Adding modification of CAG list security to the draft CR | Qualcomm Incorporated | other | Approval |
8.12Study on Security for 5GS Enhanced support of Vertical and LAN Services (FS_Vertical_LAN_SEC) (Rel-16)
| Yes |
Yes
| approved | No | ||
S3‑192927 | SUCI privacy for SNPN | Qualcomm Incorporated, Nokia, Nokia Shanghai Bell | other | Approval |
7.7Security for 5GS Enhanced support of Vertical and LAN Services (Vertical_LAN_SEC) (Rel-16)
| Yes |
YesGemalto and IDEMIA argued that the first sentence was preventing the storage in the USIM and that wasn't true.
Alf (NTT-Docomo) pointed out that privacy was needed and offerend to rephrase the first sentence to address Gemalto's comments.
Orange asked if the privacy topic mentioned here would go any further, and Qualcomm replied that this was enough.
Alf (NTT-Docomo): add a requirement on SUPI privacy shall protect the privacy of the SUCI. Orange didn't agree with this since it would not be clear where and how this would happen.
Qualcomm: privacy may happen outside the USIM.
Orange: don't mandate it in the ME.
It was also agreed to change the title of the clause to address the SUPI instead of the SUCI.
This was taken offline.
| revised | No | S3‑193050 | |
S3‑192928 | Solution for the privacy protection of CAG ID using NAS signalling | Qualcomm Incorporated | pCR | Approval |
8.12Study on Security for 5GS Enhanced support of Vertical and LAN Services (FS_Vertical_LAN_SEC) (Rel-16)
| Yes |
YesQualcomm wanted to send an LS to SA2 so they could check the solution. It was too early for this for Samsung.
| approved | No | ||
S3‑192929 | Discussion on leaving AMF relocation solutions to after Rel-15 | Qualcomm Incorporated | discussion | Endorsement |
7.1.3Other 5G security aspects
| Yes |
YesZTE supported the proposal.Huawei didnt since they had an alternative in another document. They commented that it wasn't a decision for SA3 but for SA2. Nokia pointed out that SA2 had been already consulted with an LS, so the decision could be postponed until their response.
Nokia supported Qualcomm for this proposal.
China Mobile didnt agree and considered this needed in Release 15.
| noted | No | ||
S3‑192930 | Discussion on possible solutions to AMF relocation issues | Qualcomm Incorporated | discussion | Discussion |
7.1.3Other 5G security aspects
| Yes |
YesThis discussion was taken offline.
| noted | No | S3‑191911 | |
S3‑192931 | Resolving editors notes on solution #10 in TR 33.813 | Qualcomm Incorporated | pCR | Approval |
8.8Study on Security aspects of Enhancement of Network Slicing (FS_eNS_SEC) (Rel-16)
| Yes |
YesOn the yellow text; Ericsson commented that management will be very complex.
| revised | No | S3‑193123 | |
S3‑192932 | Proposed solution for deriving PC5 layer keys based on higher layer keys | Qualcomm Incorporated | pCR | Approval |
8.18Study on Security Aspects of 3GPP support for Advanced V2X Services (FS_eV2X_Sec)
| Yes |
Yes
| revised | No | S3‑193161 | |
S3‑192933 | Minutes of SA3/CT4 call on Nudr sensitive data protection | SA3 Vice-chair (Qualcomm Incorporated) | other | Information |
7.1.1UDR
| Yes |
Yes
| noted | No | ||
S3‑192934 | Discusson on SA2 LS for MT EDT | Qualcomm Incorporated | discussion | Endorsement |
7.11.10Security Aspects of Narrowband IOT (CIoT)
| Yes |
YesEricsson: no need to take RAN considerations here.
Huawei supported this.
| noted | No | ||
S3‑192935 | Reply LS on MT EDT | Qualcomm Incorporated | LS out | Approval |
7.11.10Security Aspects of Narrowband IOT (CIoT)
| Yes |
Yes
| noted | No | ||
S3‑192936 | Alternative shared key based MIB/SIB protection | Qualcomm Incorporated | pCR | Approval |
8.7Study on 5G security enhancement against false base stations (FS_5GFBS) (Rel-16)
| Yes |
Yes
| not treated | No | ||
S3‑192937 | Evaluation against MitM false base station attacks | Qualcomm Incorporated | discussion | Endorsement |
8.7Study on 5G security enhancement against false base stations (FS_5GFBS) (Rel-16)
| Yes |
Yes
| not treated | No | ||
S3‑192938 | Evaluation of the shared key based MIB/SIB protection | Qualcomm Incorporated | pCR | Approval |
8.7Study on 5G security enhancement against false base stations (FS_5GFBS) (Rel-16)
| Yes |
Yes
| not treated | No | S3‑191922 | |
S3‑192939 | Evaluation of Solution 20: RRC Reestablishment in RLF | Qualcomm Incorporated | pCR | Approval |
8.4Study on evolution of Cellular IoT security for the 5G System (FS_CIoT_sec_5G) (Rel-16)
| Yes |
Yes
| approved | No | ||
S3‑192940 | Issues of resetting NAS COUNT values in 5G to 4G mobility | Qualcomm Incorporated | discussion | Endorsement |
7.1.3Other 5G security aspects
| Yes |
YesThere seemed to be an agreement on having an issue here. Qualcomm solution brought some sympathies like from Ericsson, but it required some more discussions since Huawei wasn't convinced at all.
Nokia: KNodeB needs to be addressed.
| noted | No | S3‑191916 | |
S3‑192941 | NAS Count values in the mapped EPS security context in 5GS to EPS change | Qualcomm Incorporated | CR | Agreement |
7.1.3Other 5G security aspects
| Yes |
YesIntel didnt agree with the notes.The first part was agreed and incorporated into the revision of Intel's document.
Nokia: the notes should be made normative text.
Qualcomm: CT1 can develop their solution based on this note. Alf (NTT-Docomo) clarified that SA3 was doing stage 2. Ericsson replied that stage 3 needs to know when this procedure is triggered.
| merged | No | ||
S3‑192942 | Skeleton of URLLC | Qualcomm Incorporated | draftCR | Agreement |
7.6Security of URLLC for 5GS (5G_URLLC_SEC) (Rel-16)
| Yes |
Yes
| merged | No | S3‑193048 | |
S3‑192943 | A solution to providing some network authorisation in PARLOS | Qualcomm Incorporated | pCR | Approval |
8.6Study on Security Aspects of PARLOS (FS_PARLOS_Sec) (Rel-16)
| Yes |
YesVodafone: we need some kind of warning to the user about the service.
NTT-Docomo: we can warn the customers by other means (like recommending them to remove the USIM).
| revised | No | S3‑193114 | |
S3‑192944 | Proposed conclusion on providing some network authorisation in PARLOS | Qualcomm Incorporated | pCR | Approval |
8.6Study on Security Aspects of PARLOS (FS_PARLOS_Sec) (Rel-16)
| Yes |
Yes
| revised | No | S3‑193116 | |
S3‑192945 | Security aspects of RLOS | Qualcomm Incorporated | other | Discussion |
8.6Study on Security Aspects of PARLOS (FS_PARLOS_Sec) (Rel-16)
| Yes |
Yes
| noted | No | ||
S3‑192946 | On the requirements for 256-bit algorithms | Qualcomm Incorporated | other | Endorsement |
6.3ETSI SAGE
| Yes |
YesErisson: reuse hardware or optimizations?
Vodafone: it can be any of those.
NTT-Docomo: exluding here AD modes that may be more efficient.
CATT supported this proposal.
Ericsson: we dont want to have new hardware for these but to reuse what is available.
Huawei: Bottleneck in the UE not in the network.
Vodafone: send an LS back to SAGE or we will be stalling their work on 256-bit algorithms. This was agreed.
| noted | No | ||
S3‑192947 | Aligning KAUSF storage at the UE with SoR and UPU procedures | Qualcomm Incorporated | CR | Agreement |
7.1.3Other 5G security aspects
| Yes |
Yes
| agreed | No | ||
S3‑192948 | New Solution for botnet threats caused by improper CIOT device usage | NIST, ATT, SPRINT, CABLE LABS, CISCO | pCR | Approval |
7.8Security of Cellular IoT for 5GS (CIoT_sec_5G) (Rel-16)
| Yes |
Yes
| revised | No | S3‑192960 | |
S3‑192949 | Resolving EN on New and Last serving gNB interactions | Samsung | pCR | Approval |
8.7Study on 5G security enhancement against false base stations (FS_5GFBS) (Rel-16)
| Yes |
YesApple: we need more time to evaluate the solution.
| noted | No | ||
S3‑192950 | Solution for Resumecause protection | Samsung | pCR | Approval |
8.7Study on 5G security enhancement against false base stations (FS_5GFBS) (Rel-16)
| Yes |
Yes
| not treated | No | ||
S3‑192951 | Updates to Solution#7 on obtaining accurate clock information | Samsung | pCR | Approval |
8.7Study on 5G security enhancement against false base stations (FS_5GFBS) (Rel-16)
| Yes |
Yes
| not treated | No | ||
S3‑192952 | Deletion of EN on Location update reject in Solution#7 | Samsung | pCR | Approval |
8.7Study on 5G security enhancement against false base stations (FS_5GFBS) (Rel-16)
| Yes |
Yes
| not treated | No | ||
S3‑192953 | Conclusion to Key Issue #6.1 | Samsung | pCR | Approval |
8.12Study on Security for 5GS Enhanced support of Vertical and LAN Services (FS_Vertical_LAN_SEC) (Rel-16)
| Yes |
YesInterdigital: too early for this conclusion. Ericsson agreed about the conclusion.
| revised | No | S3‑193134 | |
S3‑192954 | New solution for CAG ID privacy | Samsung,Intel | pCR | Approval |
8.12Study on Security for 5GS Enhanced support of Vertical and LAN Services (FS_Vertical_LAN_SEC) (Rel-16)
| Yes |
YesIntel supported this contribution.
| approved | No | ||
S3‑192955 | Security procedures for CAPIF-7/7e reference points | Samsung | CR | Agreement |
7.5Enhancements for Security aspects of Common API Framework for 3GPP Northbound APIs (eCAPIF) (Rel-16)
| Yes |
Yes
| agreed | No | ||
S3‑192956 | Security procedures for CAPIF-3e/4e/5e reference points | Samsung | CR | Agreement |
7.5Enhancements for Security aspects of Common API Framework for 3GPP Northbound APIs (eCAPIF) (Rel-16)
| Yes |
YesNokia had doubts about referencing both 210 and 310. This was taken offline.
| agreed | No | ||
S3‑192957 | Manufacture Usage Description Discussion | NIST, ATT, SPRINT, CABLE LABS, CISCO | discussion | Discussion |
8.4Study on evolution of Cellular IoT security for the 5G System (FS_CIoT_sec_5G) (Rel-16)
| Yes |
Yes
| noted | No | ||
S3‑192958 | Categorization of the Key Issues | Nokia, Nokia Shanghai Bell | discussion | Endorsement |
8.15Study on Security Impacts of Virtualisation (FS_SIV) (Rel-16)
| Yes |
Yes
| not treated | No | ||
S3‑192959 | DraftCR - Proposed skeleton for supporting 5G CIoT | Ericsson, Nokia | draftCR |
7.8Security of Cellular IoT for 5GS (CIoT_sec_5G) (Rel-16)
| Yes |
YesThe definition was controversial, as Huawei didnt agree with it. The definition was removed.
Vodafone pointed out that several other clauses could be affected and not only under 6. This was agreed to be checked for the next meeting.
An editor's note was added on the alignment with SA2 and RAN.
| revised | No | S3‑193052 | ||
S3‑192960 | New Solution for botnet threats caused by improper CIOT device usage | NIST, ATT, Sprint, Cable Labs, Cisco | pCR | Approval |
8.4Study on evolution of Cellular IoT security for the 5G System (FS_CIoT_sec_5G) (Rel-16)
| Yes |
Yes
| noted | No | S3‑192948 | |
S3‑192961 | DraftCR-Control Plane Optimization for CIoT in 5G | Ericsson | draftCR |
7.8Security of Cellular IoT for 5GS (CIoT_sec_5G) (Rel-16)
| Yes |
YesNokia: not part of the study and even in LTE we didnt do this.
Huawei: not sure if this is aligned with SA2 and RAN either on the gNodeB.
Nokia commented that this needed more study and proposed to postpone this part.
| noted | No | |||
S3‑192962 | P-CR: Proposed conclusion for PARLOS | Sprint Corporation | pCR | Agreement |
8.6Study on Security Aspects of PARLOS (FS_PARLOS_Sec) (Rel-16)
| Yes |
Yes
| merged | No | S3‑193116 | |
S3‑192963 | Algorithm Negotiation | Samsung | CR | Agreement |
7.3eMCSec R16 security (MCXSec) (Rel-16)
| Yes |
YesNCSC preferred to follow the way of not changing the algorithms but the key length of the algorithms.
The contribution was taken offline.
| not pursued | No | ||
S3‑192964 | P-CR: Proposed recommendations for PARLOS | Sprint Corporation | pCR | Agreement |
8.6Study on Security Aspects of PARLOS (FS_PARLOS_Sec) (Rel-16)
| Yes |
Yes
| merged | No | S3‑193116 | |
S3‑192965 | pCR to 33.815 clarifying requirements on Parlos | DOCOMO Communications Lab. | pCR | Approval |
8.6Study on Security Aspects of PARLOS (FS_PARLOS_Sec) (Rel-16)
| Yes |
YesSprint: leave it to the regulator to block it or not.
NTT-Docomo: we cannot leave it to regulators from the IMSI side.
Change It so you dont mention a particular country.
| revised | No | S3‑193115 | |
S3‑192966 | Proposed presentation cover sheet for PARLOS 33.815 | Sprint Corporation | TS or TR cover | Agreement |
8.6Study on Security Aspects of PARLOS (FS_PARLOS_Sec) (Rel-16)
| Yes |
Yes
| approved | No | ||
S3‑192967 | Clarification in Solution 12 | Huawei, Hisilicon | pCR | Approval |
8.4Study on evolution of Cellular IoT security for the 5G System (FS_CIoT_sec_5G) (Rel-16)
| Yes |
Yes
| approved | No | S3‑192747 | |
S3‑192968 | The solution to protect MIB/SIB information | Huawei, Hisilicon | pCR | Approval |
8.7Study on 5G security enhancement against false base stations (FS_5GFBS) (Rel-16)
| Yes |
Yes
| not treated | No | S3‑192748 | |
S3‑192969 | Key issue on removal of USIM card in IAB node | Huawei, Hisilicon | pCR | Approval |
8.17Study on Security for NR Integrated Access and Backhaul (FS_NR_IAB_Sec)
| Yes |
YesOrange: I don't understand the key issue.
Nokia: this is a deployment issue.
Qualcomm didnt agree either. There was no support for this key issue.
| noted | No | S3‑192749 | |
S3‑192970 | Proposed solution on protecting the SQN during a re-synchronisation procedure in AKA | Huawei, Hisilicon | pCR | Approval |
8.16Study on authentication enhancements in 5GS (FS_AUTH_ENH) (Rel-16)
| Yes |
Yes
| not treated | No | S3‑192750 | |
S3‑192971 | conclusion on KI#4 | Huawei, Hisilicon | pCR | Approval |
8.9Study on Security of the enhancement to the 5GC location services (FS_eLCS_Sec) (Rel-16)
| Yes |
Yes
| noted | No | S3‑192751 | |
S3‑192972 | mitigate the linkability attack | Huawei, Hisilicon | pCR | Approval |
8.16Study on authentication enhancements in 5GS (FS_AUTH_ENH) (Rel-16)
| Yes |
YesQualcomm: remove changes from scope.
Ericsson wanted some more details in the description of the solution.
| revised | No | S3‑193191 | S3‑192752 |
S3‑192973 | Virtualisation Study Key Issue 22 was S3-191857 | BT plc | pCR | Approval |
8.15Study on Security Impacts of Virtualisation (FS_SIV) (Rel-16)
| Yes |
Yes
| not treated | No | ||
S3‑192974 | Virtualisation Study Key Issue 23 was S3-191858 | BT plc | pCR | Approval |
8.15Study on Security Impacts of Virtualisation (FS_SIV) (Rel-16)
| Yes |
Yes
| not treated | No | ||
S3‑192975 | Virtualisation Study Key Issue 24 was S3-191859 | BT plc | pCR | Approval |
8.15Study on Security Impacts of Virtualisation (FS_SIV) (Rel-16)
| Yes |
Yes
| not treated | No | ||
S3‑192976 | Comments on S3-192824 | Huawei Technologies Co. Ltd. | discussion | Approval |
7.2.2Access and Mobility Management Function (TS 33.512)
| Yes |
Yes
| noted | No | ||
S3‑192977 | Reply LS on authentication of group of IoT devices | S1-192816 | LS in | discussion |
7.8Security of Cellular IoT for 5GS (CIoT_sec_5G) (Rel-16)
| Yes |
Yes
| noted | No | ||
S3‑192978 | Agenda | WG Chairman | agenda | - |
2Approval of Agenda and Meeting Objectives
| Yes |
Yes
| approved | No | S3‑192500 | |
S3‑192979 | Correction of text on access authentication for untrusted access | BlackBerry UK Limited | CR | Agreement |
7.1.3Other 5G security aspects
| Yes |
Yes
| agreed | No | S3‑192540 | |
S3‑192980 | Reply to: 256 bit radio interface algorithm performance | Qualcomm | LS out | approval |
6.3ETSI SAGE
| Yes |
Yes
| noted | No | ||
S3‑192981 | Reply LS on Wireline Access Security Requirements | CableLabs | LS out | Approval |
8.5Study on the security of the Wireless and Wireline Convergence for the 5G system architecture (FS_5WWC_SEC) (Rel-16)
| Yes |
Yes
| approved | No | S3‑192604 | |
S3‑192982 | Removing references of TS 103 383 in TS 35.231 | Orange | CR | Approval |
7.11.16Other work items
| Yes |
Yes
| agreed | No | S3‑192668 | |
S3‑192983 | Removing references of TS 103 383 in TS 35.231 | Orange | CR | Approval |
7.11.16Other work items
| Yes |
Yes
| agreed | No | S3‑192669 | |
S3‑192984 | Removing references of TS 103 383 in TS 35.231 | Orange | CR | Approval |
7.11.16Other work items
| Yes |
Yes
| agreed | No | S3‑192671 | |
S3‑192985 | Removing references of TS 103 383 in TS 35.231 | Orange | CR | Approval |
7.11.16Other work items
| Yes |
Yes
| agreed | No | S3‑192672 | |
S3‑192986 | Reply to: LS on withdrawal of TS 103 383 Smart Cards; Embedded UICC; Requirements Specification | Orange | LS out | approval |
6.10Other Groups
| Yes |
Yes
| approved | No | ||
S3‑192987 | Definition of authentication subscription data and update to UDM requirement | Nokia, Nokia Shanghai Bell | CR | Agreement |
7.1.1UDR
| Yes |
Yes
| agreed | No | S3‑192587 | |
S3‑192988 | Missing UDR description in alignment with 29.505 | Nokia, Nokia Shanghai Bell | CR | Agreement |
7.1.1UDR
| Yes |
Yes
| agreed | No | S3‑192589 | |
S3‑192989 | Update on ARPF | Nokia, Nokia Shanghai Bell | CR | Agreement |
7.1.1UDR
| Yes |
Yes
| agreed | No | S3‑192590 | |
S3‑192990 | Correcting references | ZTE Corporation | CR | Agreement |
7.1.3Other 5G security aspects
| Yes |
Yes
| agreed | No | S3‑192624 | |
S3‑192991 | Removing editor notes | ZTE Corporation | CR | Agreement |
7.1.3Other 5G security aspects
| Yes |
Yes
| agreed | No | S3‑192625 | |
S3‑192992 | Adjust the proceudure of GPSI and IP/MAC notification | China Mobile | CR | Approval |
7.1.3Other 5G security aspects
| Yes |
Yes
| agreed | No | S3‑192794 | |
S3‑192993 | Clarification for Secondary Authentication | Huawei, Hisilicon | CR | Approval |
7.1.3Other 5G security aspects
| Yes |
Yes
| agreed | No | S3‑192777 | |
S3‑192994 | WID of 5GFBS | Apple | WID new | Approval |
7.12New Work Item proposals
| Yes |
Yes
| noted | No | S3‑192636 | |
S3‑192995 | EAP-AKA privacy enhancement in non-3GPP access to EPS | Apple | SID new | Agreement |
8.20New study item proposals
| Yes |
Yes
| noted | No | S3‑192650 | |
S3‑192996 | Notes of the offline session on AMF relocation | NTT-Docomo | report | Information |
7.1.3Other 5G security aspects
| Yes |
Yes
| noted | No | ||
S3‑192997 | Correction of handling of 5G security contexts during EPS to 5GS idle mode mobility | Intel Deutschland GmbH,Qualcomm | CR | Agreement |
7.1.3Other 5G security aspects
| Yes |
Yes
| agreed | No | S3‑192631 | |
S3‑192998 | Security context transfer following the handover from EPS to 5GS | Huawei, Hisilicon | CR | Approval |
7.1.3Other 5G security aspects
| Yes |
Yes
| agreed | No | S3‑192683 | |
S3‑192999 | Changes on handover from 5GS to EPS over N26 | Huawei, Hisilicon | CR | Approval |
7.1.3Other 5G security aspects
| Yes |
Yes
| agreed | No | S3‑192717 | |
S3‑193000 | General NDS/IP SEG support for non-SBA interfaces | Juniper Networks | CR | - |
7.11.3Network Domain Security (NDS)
| Yes |
YesRevised given that the document could not be opened by some (including MCC).
| agreed | No | S3‑192578 | |
S3‑193001 | Test cases referring to TS 33.117 | Ericsson | CR | Agreement |
7.2.1NR Node B (gNB) (TS 33.511)
| No |
Yes
| withdrawn | Yes | S3‑192823 | |
S3‑193002 | Test cases referring to TS 33.117 | Ericsson | pCR | Approval |
7.2.2Access and Mobility Management Function (TS 33.512)
| No |
Yes
| withdrawn | Yes | ||
S3‑193003 | Editorial corrections on the threat references of some test cases | Nokia, Nokia Shanghai Bell | CR | Approval |
7.2.1NR Node B (gNB) (TS 33.511)
| Yes |
YesKeeping only editorials.
| agreed | No | S3‑192635 | |
S3‑193004 | Update requirements and test cases for gNB SCAS | Huawei, Hisilicon | CR | Approval |
7.2.1NR Node B (gNB) (TS 33.511)
| Yes |
Yes
| agreed | No | S3‑192763 | |
S3‑193005 | Adding AMF critical assets and threats to TS 33.926 | Huawei, Hisilicon | CR | Approval |
7.2.2Access and Mobility Management Function (TS 33.512)
| Yes |
Yes
| agreed | No | S3‑192714 | |
S3‑193006 | Adding UPF critical assets and threats to TS 33.926 | Huawei, Hisilicon | CR | Approval |
7.2.3User Plane Function (UPF) (TS 33.513)
| Yes |
YesMCC pointed out that the introduction clause in the annex was referring to the whole document and not the specific annex, so this had to be reworded.
| agreed | No | S3‑192715 | |
S3‑193007 | Draft TS 33.514 | NEC | draft TS | Approval |
7.2.4Unified Data Management (UDM) (TS 33.514)
| Yes |
Yes
| approved | No | ||
S3‑193008 | UDM critical assets and threats to TR 33.926 | Huawei, Hisilicon | CR | Approval |
7.2.4Unified Data Management (UDM) (TS 33.514)
| Yes |
Yes
| agreed | No | S3‑192696 | |
S3‑193009 | Cover sheet TS 33.512 for approval | Huawei | TS or TR cover | Approval |
7.2.3User Plane Function (UPF) (TS 33.513)
| Yes |
Yes
| approved | No | ||
S3‑193010 | Cover sheet TS 33.513 for approval | Samsung | TS or TR cover | Approval |
7.2.3User Plane Function (UPF) (TS 33.513)
| Yes |
Yes
| approved | No | ||
S3‑193011 | Cover sheet TS 33.514 for approval | NEC | TS or TR cover | Approval |
7.2.4Unified Data Management (UDM) (TS 33.514)
| Yes |
Yes
| approved | No | ||
S3‑193012 | Adding SMF critical assets and threats to TS 33.926 | Huawei, Hisilicon | CR | Approval |
7.2.5Session Management Function (SMF) (TS 33.515)
| Yes |
YesIssue with the introduction of the annex as the previous documents.
| agreed | No | S3‑192712 | |
S3‑193013 | Editorial change on TS 33.515 | Huawei, Hisilicon | pCR | Approval |
7.2.5Session Management Function (SMF) (TS 33.515)
| Yes |
YesExecutions steps in 4.2.2.1.3 had to be checked.
| approved | No | S3‑192713 | |
S3‑193014 | Draft TS 33.515 | Huawei | draft TS | Approval |
7.2.5Session Management Function (SMF) (TS 33.515)
| Yes |
Yes
| approved | No | ||
S3‑193015 | Cover sheet TS 33.515 for approval | Huawei | TS or TR cover | Approval |
7.2.5Session Management Function (SMF) (TS 33.515)
| Yes |
Yes
| approved | No | ||
S3‑193016 | AUSF critical assets and threats to TR 33.926 | Huawei, Hisilicon | CR | Approval |
7.2.6Authentication Server Function (AUSF) (TS 33.516)
| Yes |
Yes
| agreed | No | S3‑192698 | |
S3‑193017 | Draft TS 33.516 | Ericsson | draft TS | Approval |
7.2.6Authentication Server Function (AUSF) (TS 33.516)
| Yes |
YesMCC warned that the document didnt have any definitions and abbreviations. Ericsson commented that they would bring a CR for the next meeting to finish these clauses.
| approved | No | ||
S3‑193018 | Cover sheet TS 33.516 for approval | Ericsson | TS or TR cover | Approval |
7.2.6Authentication Server Function (AUSF) (TS 33.516)
| Yes |
Yes
| approved | No | ||
S3‑193019 | Draft TS 33.517 | Nokia | draft TS | Approval |
7.2.7Security Edge Protection Proxy (SEPP) (TS 33.517)
| Yes |
YesMCC urged the Rapporteurs to add acronyms to the specifications, especially TS since most of them were not present in TR 21.905.
| approved | No | ||
S3‑193020 | Adding NRF critical assets and threats to TR 33.926 | Huawei, Hisilicon | CR | Approval |
7.2.8Network Resource Function (NRF) (TS 33.518)
| Yes |
YesIt removes the new changes and it maintains the original changes from the living document.
| agreed | No | S3‑192702 | |
S3‑193021 | Clarifications for Protected MCData | Airbus DS SLC | CR | Agreement |
7.3eMCSec R16 security (MCXSec) (Rel-16)
| Yes |
Yes
| not pursued | No | S3‑192519 | |
S3‑193022 | Draft TS 33.518 | Nokia | draft TS | Approval |
7.2.8Network Resource Function (NRF) (TS 33.518)
| Yes |
YesMCC pointed out that all SCAS specs needed a note explaining why 33.501 release 15 was being referenced instead of the same release as the current TS, if there would be backward compatibility problems if this wasn't done, etc.. It was agreed that Rapporteurs brought CRs for the same meeting to add such note. It was also noted that "v15" was not correct and "release 15" should be written instead.
| approved | No | ||
S3‑193023 | Cover sheet draft TS 33.518 for approval | Nokia | TS or TR cover | Approval |
7.2.8Network Resource Function (NRF) (TS 33.518)
| Yes |
YesMCC commented that unfinished work should appear in "outstanding issues": e.g. definitions, abbreviations and test cases that needed to be brought.
| approved | No | ||
S3‑193024 | Draft TS 33.513 | Samsung | draft TS | Approval |
7.2.3User Plane Function (UPF) (TS 33.513)
| Yes |
Yes
| approved | No | ||
S3‑193025 | Adding abbreviation | ZTE Corporation | pCR | Approval |
7.2.9Network Exposure Function (NEF) (TS 33.519)
| Yes |
Yes
| approved | No | S3‑192626 | |
S3‑193026 | Draft TS 33.519 | ZTE | draft TS | Approval |
7.2.9Network Exposure Function (NEF) (TS 33.519)
| Yes |
Yes
| approved | No | ||
S3‑193027 | Adding NEF critical assets and threats to TR 33.926 | Huawei, Hisilicon | CR | Approval |
7.2.9Network Exposure Function (NEF) (TS 33.519)
| Yes |
YesRewording the Introduction to refer to the annex and not the whole document, and fixing editorials as suggested as Ericsson.
| agreed | No | S3‑192704 | |
S3‑193028 | Cover sheet TS 33.519 for approval | ZTE | TS or TR cover | Approval |
7.2.10Other 5G SCAS aspects
| Yes |
Yes
| approved | No | ||
S3‑193029 | Addition of general SBA/SBI aspects in TS 33.117 | Huawei, Hisilicon,Nokia | CR | Approval |
7.2.10Other 5G SCAS aspects
| Yes |
YesComments on the clause numbering provided by MCC. The spec baseline had to be checked.
| agreed | No | S3‑192706 | |
S3‑193030 | Adding critical assets and threats for general NFs to TR 33.926 | Huawei, Hisilicon | CR | Approval |
7.2.10Other 5G SCAS aspects
| Yes |
Yes
| agreed | No | S3‑192705 | |
S3‑193031 | Additional Critical Assets and Threats to PGW Annex R15 | Nokia, Nokia Shanghai Bell | CR | Approval |
7.11.9Security Assurance Specifications (SCAS-SA3, SCAS_PGW, SCAS_eNB)
| Yes |
Yes
| agreed | No | S3‑192653 | |
S3‑193032 | Additional Critical Assets and Threats to PGW Annex R14 | Nokia | CR | Agreement |
7.11.9Security Assurance Specifications (SCAS-SA3, SCAS_PGW, SCAS_eNB)
| Yes |
Yes
| agreed | No | ||
S3‑193033 | Additional Critical Assets and Threats to PGW Annex R16 | Nokia, Nokia Shanghai Bell | CR | Approval |
7.11.9Security Assurance Specifications (SCAS-SA3, SCAS_PGW, SCAS_eNB)
| Yes |
Yes
| agreed | No | S3‑192652 | |
S3‑193034 | Adding Threat References to PGW Test Cases R14 | Nokia | CR | Agreement |
7.11.9Security Assurance Specifications (SCAS-SA3, SCAS_PGW, SCAS_eNB)
| Yes |
Yes
| agreed | No | ||
S3‑193035 | Adding Threat References to PGW Test Cases R15 | Nokia, Nokia Shanghai Bell | CR | Approval |
7.11.9Security Assurance Specifications (SCAS-SA3, SCAS_PGW, SCAS_eNB)
| Yes |
Yes
| agreed | No | S3‑192654 | |
S3‑193036 | Clarification on test cases in TR 33.117 | Huawei, Hisilicon | CR | Approval |
7.11.9Security Assurance Specifications (SCAS-SA3, SCAS_PGW, SCAS_eNB)
| Yes |
Yes
| agreed | No | S3‑192707 | |
S3‑193037 | Clarification on test cases in TS 33.117 | Huawei | CR | Agreement |
7.11.9Security Assurance Specifications (SCAS-SA3, SCAS_PGW, SCAS_eNB)
| Yes |
Yes
| agreed | No | ||
S3‑193038 | Clarification on test cases in TS 33.117 | Huawei | CR | Agreement |
7.11.9Security Assurance Specifications (SCAS-SA3, SCAS_PGW, SCAS_eNB)
| Yes |
Yes
| agreed | No | ||
S3‑193039 | Update testcase of 4.2.4.1.1.2 and 4.2.4.1.1.3 | Huawei | CR | Agreement |
7.11.9Security Assurance Specifications (SCAS-SA3, SCAS_PGW, SCAS_eNB)
| Yes |
Yes
| agreed | No | ||
S3‑193040 | Update testcase of 4.2.4.1.1.2 and 4.2.4.1.1.3 | Huawei | CR | Agreement |
7.11.9Security Assurance Specifications (SCAS-SA3, SCAS_PGW, SCAS_eNB)
| Yes |
Yes
| agreed | No | ||
S3‑193041 | Update requirements and test cases for eNB SCAS | Huawei, Hisilicon | CR | Approval |
7.11.9Security Assurance Specifications (SCAS-SA3, SCAS_PGW, SCAS_eNB)
| Yes |
Yes
| agreed | No | S3‑192764 | |
S3‑193042 | Update requirements and test cases for eNB SCAS | Huawei | CR | Agreement |
7.11.9Security Assurance Specifications (SCAS-SA3, SCAS_PGW, SCAS_eNB)
| Yes |
Yes
| agreed | No | ||
S3‑193043 | Algorithm Negotiation | Samsung | CR | Agreement |
7.3eMCSec R16 security (MCXSec) (Rel-16)
| No |
Yes
| withdrawn | Yes | ||
S3‑193044 | Correction to figure in draft CR for 5G to UTRAN CS SRVCC | Qualcomm Incorporated, China Unicom | other | Approval |
7.4Security aspects of single radio voice continuity from 5GS to UTRAN (5GS_UTRAN_SEC) (Rel-16)
| Yes |
Yes
| approved | No | S3‑192923 | |
S3‑193045 | Draft CR for SRVCC 5G to UTRAN | China Unicom, Qualcomm Incoporated | draftCR | Approval |
7.4Security aspects of single radio voice continuity from 5GS to UTRAN (5GS_UTRAN_SEC) (Rel-16)
| Yes |
Yes
| approved | No | S3‑192922 | |
S3‑193046 | Security for SRVCC 5G to UTRAN CS | Qualcomm,China Unicom | CR | Agreement |
7.4Security aspects of single radio voice continuity from 5GS to UTRAN (5GS_UTRAN_SEC) (Rel-16)
| Yes |
YesQualcomm commented that China Unicom had agreed to help on this CR, but no confirmation from them had been received.
| agreed | No | ||
S3‑193047 | Adding K5GSRVCC as a possible input key to derive IKSRVCC and CKSRVCC | Qualcomm Incorporated | CR | Agreement |
7.4Security aspects of single radio voice continuity from 5GS to UTRAN (5GS_UTRAN_SEC) (Rel-16)
| Yes |
Yes
| agreed | No | S3‑192918 | |
S3‑193048 | draftCR for URLLC | Huawei, Hisilicon, Qualcomm | draftCR | Approval |
7.6Security of URLLC for 5GS (5G_URLLC_SEC) (Rel-16)
| Yes |
Yes
| approved | No | S3‑192766 | |
S3‑193049 | Security for non-public networks - update to S3-192453 | Qualcomm, Nokia, Nokia Shanghai Bell | draftCR | Agreement |
7.7Security for 5GS Enhanced support of Vertical and LAN Services (Vertical_LAN_SEC) (Rel-16)
| Yes |
YesOrange objected to NOTE 2: not clear how the credentials EAP-AKA' and 5G AKA are stored. ORANGE TO PROVIDE EXACT WORDING. Thales commented that there had been previous agreement on the note.
The Chair clarified that this was a draft CR in any case.
| approved | No | S3‑192592 | |
S3‑193050 | SUCI privacy for SNPN | Qualcomm Incorporated, Nokia, Nokia Shanghai Bell | other | Approval |
7.7Security for 5GS Enhanced support of Vertical and LAN Services (Vertical_LAN_SEC) (Rel-16)
| Yes |
Yes
| approved | No | S3‑192927 | |
S3‑193051 | Security for non-public networks | Qualcomm Incorporated, Nokia, Nokia Shanghai Bell | CR | - |
7.7Security for 5GS Enhanced support of Vertical and LAN Services (Vertical_LAN_SEC) (Rel-16)
| Yes |
Yes
| agreed | No | S3‑192577 | |
S3‑193052 | DraftCR - Proposed skeleton for supporting 5G CIoT | Ericsson, Nokia | draftCR | - |
7.8Security of Cellular IoT for 5GS (CIoT_sec_5G) (Rel-16)
| Yes |
Yes
| approved | No | S3‑192959 | |
S3‑193053 | skeleton of 5WWC | Huawei, Hisilicon | draftCR | Approval |
7.9Security of the Wireless and Wireline Convergence for the 5G system architecture (5WWC_SEC) (Rel-16)
| Yes |
YesThis will be the living document that captures the inputs of this agenda item.
| approved | No | S3‑192760 | |
S3‑193054 | Add a new Annex for the authentication of non-5GC NAS capable devices in WWC | CableLabs, Charter Communications, Nokia, Nokia Shanghai Bell, Lenovo, Motorola Mobility, Ericsson, Comcast, Rogers Communications | draftCR | Agreement |
7.9Security of the Wireless and Wireline Convergence for the 5G system architecture (5WWC_SEC) (Rel-16)
| Yes |
Yes
| approved | No | S3‑192581 | |
S3‑193055 | New WID on Security aspects of enhancements to the Service-Based 5G System Architecture | Nokia, Nokia Shanghai Bell | WID new | Agreement |
7.12New Work Item proposals
| Yes |
Yes
| agreed | No | S3‑192605 | |
S3‑193056 | New WID on security of the enhancement to the 5GC location services | CATT | WID new | Agreement |
7.12New Work Item proposals
| Yes |
Yes
| agreed | No | S3‑192828 | |
S3‑193057 | SID on Storage of Secure Parameters in a 5G system | Vodafone Espaρa SA | SID new | Agreement |
8.20New study item proposals
| Yes |
Yes
| agreed | No | S3‑192903 | |
S3‑193058 | Claification on UE context transfer in registration with AMF reallocation via direct NAS reroute | Huawei, Hisilicon | CR | Approval |
7.1.3Other 5G security aspects
| Yes |
Yes
| agreed | No | S3‑192709 | |
S3‑193059 | Reply to: Reply LS on Mobile-terminated Early Data Transmission | Nokia | LS out | approval |
7.11.10Security Aspects of Narrowband IOT (CIoT)
| Yes |
YesConfirming SA2's assumption.
| approved | No | ||
S3‑193060 | Add missing message flow for Procedure for steering of UE | Intel Deutschland GmbH | CR | Agreement |
7.11.14PLMN RAT selection (Steering of Roaming) (Rel-15)
| Yes |
Yes
| agreed | No | S3‑192632 | |
S3‑193061 | Minor corrections to 33163 | Juniper Networks | CR | Approval |
7.11.15Battery Efficient Security for very low Throughput Machine Type Communication Devices (BEST_MTC_Sec) (Rel-15)
| Yes |
Yes
| agreed | No | S3‑192579 | |
S3‑193062 | Minor corrections to 33163 | Juniper Networks | CR | Approval |
7.11.15Battery Efficient Security for very low Throughput Machine Type Communication Devices (BEST_MTC_Sec) (Rel-15)
| Yes |
Yes
| agreed | No | S3‑192580 | |
S3‑193063 | Notes on the evening session on SIV | BT | report | Information |
8.15Study on Security Impacts of Virtualisation (FS_SIV) (Rel-16)
| Yes |
Yes
| noted | No | ||
S3‑193064 | eSBA: pCR to update Evaluation of Solution #16 | Nokia, Nokia Shanghai Bell | pCR | Approval |
8.1Study on Security Aspects of the 5G Service Based Architecture (FS_SBA-Sec) (Rel-15)
| Yes |
Yes
| approved | No | S3‑192609 | |
S3‑193065 | Draft TR 33.855 | Ericsson | draft TR | Approval |
8.1Study on Security Aspects of the 5G Service Based Architecture (FS_SBA-Sec) (Rel-15)
| No |
Yes
| left for email approval | No | ||
S3‑193066 | Evaluation for Solution #23 (Token-based authorization for Scenario D using stateless SeCoP) | Ericsson | pCR | Approval |
8.1Study on Security Aspects of the 5G Service Based Architecture (FS_SBA-Sec) (Rel-15)
| Yes |
Yes
| approved | No | S3‑192804 | |
S3‑193067 | Update of Solution #24 (Token-based authorization for Scenario C using stateless SeCoP) | Ericsson | pCR | Approval |
8.1Study on Security Aspects of the 5G Service Based Architecture (FS_SBA-Sec) (Rel-15)
| Yes |
Yes
| approved | No | S3‑192803 | |
S3‑193068 | Evaluation for Solution #24 (Token-based authorization for Scenario C using stateless SeCoP) | Ericsson | pCR | Approval |
8.1Study on Security Aspects of the 5G Service Based Architecture (FS_SBA-Sec) (Rel-15)
| Yes |
Yes
| approved | No | S3‑192805 | |
S3‑193069 | eSBA: new solution for NF service consumer verification during service access authorization in indirect communication scenario | Huawei, Hisilicon | pCR | Approval |
8.1Study on Security Aspects of the 5G Service Based Architecture (FS_SBA-Sec) (Rel-15)
| Yes |
Yes
| approved | No | S3‑192694 | |
S3‑193070 | Conclusion of Key Issue #22 (Authorization of NF service access in indirect communication) | Ericsson,Nokia | pCR | Approval |
8.1Study on Security Aspects of the 5G Service Based Architecture (FS_SBA-Sec) (Rel-15)
| Yes |
Yes
| approved | No | S3‑192806 | |
S3‑193071 | New WID on Security aspects of SEAL | Samsung | WID new | Agreement |
7.12New Work Item proposals
| Yes |
Yes
| agreed | No | S3‑192907 | |
S3‑193072 | Analysis of SEAL | Samsung | discussion | discussion |
7.12New Work Item proposals
| Yes |
Yes
| noted | No | ||
S3‑193073 | New WID on Security for NR Integrated Access and Backhaul | Samsung | WID new | - |
7.12New Work Item proposals
| Yes |
Yes
| agreed | No | S3‑192909 | |
S3‑193074 | Security of RRC UE capability transfer procedure in EPS | Ericsson | CR | Agreement |
7.11.1SAE/LTE Security
| Yes |
Yes
| not pursued | No | S3‑192861 | |
S3‑193075 | New solution: Telescopic FQDN for the SeCoP | Ericsson | pCR | Approval |
8.1Study on Security Aspects of the 5G Service Based Architecture (FS_SBA-Sec) (Rel-15)
| Yes |
Yes
| approved | No | S3‑192807 | |
S3‑193076 | LS to CT4 on ESPA using indirect communication | NTT-Docomo | LS out | Approval |
8.1Study on Security Aspects of the 5G Service Based Architecture (FS_SBA-Sec) (Rel-15)
| Yes |
Yes
| approved | No | ||
S3‑193077 | eSBA: Add conclusion on KI #20 | Nokia, Nokia Shanghai Bell | pCR | Approval |
8.1Study on Security Aspects of the 5G Service Based Architecture (FS_SBA-Sec) (Rel-15)
| Yes |
Yes
| approved | No | S3‑192610 | |
S3‑193078 | Conclusion of Key Issue #21: Secure message transport via the SeCoP | Ericsson | pCR | Approval |
8.1Study on Security Aspects of the 5G Service Based Architecture (FS_SBA-Sec) (Rel-15)
| No |
Yes
| approved | No | S3‑192814 | |
S3‑193079 | New solution: Token-based authorization for NF Sets / NF Service Sets by existing methods | Ericsson | pCR | Approval |
8.1Study on Security Aspects of the 5G Service Based Architecture (FS_SBA-Sec) (Rel-15)
| Yes |
Yes
| approved | No | S3‑192808 | |
S3‑193080 | LS to SA2 on ESPA NF sets | NTT-Docomo | LS out | Approval |
8.1Study on Security Aspects of the 5G Service Based Architecture (FS_SBA-Sec) (Rel-15)
| Yes |
Yes
| approved | No | ||
S3‑193081 | eSBA: Add conclusion on KI #26 | Nokia, Nokia Shanghai Bell, Nokia | pCR | Approval |
8.1Study on Security Aspects of the 5G Service Based Architecture (FS_SBA-Sec) (Rel-15)
| Yes |
Yes
| approved | No | S3‑192611 | |
S3‑193082 | UP Gateway deployments | Ericsson | pCR | Approval |
8.1Study on Security Aspects of the 5G Service Based Architecture (FS_SBA-Sec) (Rel-15)
| Yes |
Yes
| approved | No | S3‑192818 | |
S3‑193083 | Discussion on UDR related contributions | Nokia | discussion | discussion |
7.1.1UDR
| Yes |
Yes
| endorsed | No | ||
S3‑193084 | LS on security asepcts of AMF re-alocation procedure | Qualcomm | LS out | Approval |
7.1.3Other 5G security aspects
| Yes |
Yesthis was split into two different versions: 195 and 196.
| revised | No | S3‑193195 | |
S3‑193085 | Threat analysis on misplacement of encrypted IE in JSON object by IPX | Nokia, Nokia Shanghai Bell | draftCR | Approval |
7.2.7Security Edge Protection Proxy (SEPP) (TS 33.517)
| Yes |
Yes
| approved | No | S3‑192657 | |
S3‑193086 | Test Case: No misplacement of encrypted IE in JSON object by IPX | Nokia, Nokia Shanghai Bell | pCR | Approval |
7.2.7Security Edge Protection Proxy (SEPP) (TS 33.517)
| Yes |
Yes
| approved | No | S3‑192658 | |
S3‑193087 | Draft TS 33.512 | Huawei | draft TS | Approval |
7.2.2Access and Mobility Management Function (TS 33.512)
| Yes |
Yes
| approved | No | ||
S3‑193088 | TR 33.848 Annex - Administration of Virtualisation | NCSC | pCR | Approval |
8.15Study on Security Impacts of Virtualisation (FS_SIV) (Rel-16)
| Yes |
Yes
| noted | No | S3‑192541 | |
S3‑193089 | TR 33.848 Annex - Virtualisation Security Questions | NCSC | pCR | Approval |
8.15Study on Security Impacts of Virtualisation (FS_SIV) (Rel-16)
| Yes |
Yes
| noted | No | S3‑192542 | |
S3‑193090 | TR 33.848 Security Threats and Requirements for Key Issue 1 | NCSC | pCR | Approval |
8.15Study on Security Impacts of Virtualisation (FS_SIV) (Rel-16)
| Yes |
Yes
| noted | No | S3‑192544 | |
S3‑193091 | Threats and Requirements for Key Issue #2 | Nokia, Nokia Shanghai Bell | pCR | Approval |
8.15Study on Security Impacts of Virtualisation (FS_SIV) (Rel-16)
| No |
Yes
| approved | No | S3‑192890 | |
S3‑193092 | Threats and Requirements for Key Issue #3 | Nokia, Nokia Shanghai Bell | pCR | Approval |
8.15Study on Security Impacts of Virtualisation (FS_SIV) (Rel-16)
| No |
Yes
| noted | No | S3‑192891 | |
S3‑193093 | TR 33.848 Security Threats and Requirements for Key Issue 5 | NCSC,Nokia | pCR | Approval |
8.15Study on Security Impacts of Virtualisation (FS_SIV) (Rel-16)
| Yes |
Yes
| noted | No | S3‑192546 | |
S3‑193094 | Threats and Requirements for Key Issue #5 | Nokia, Nokia Shanghai Bell,NCSC | pCR | Approval |
8.15Study on Security Impacts of Virtualisation (FS_SIV) (Rel-16)
| No |
Yes
| noted | No | S3‑192899 | |
S3‑193095 | eSBA: Add conclusion on KI #27 | Nokia, Nokia Shanghai Bell | pCR | Approval |
8.1Study on Security Aspects of the 5G Service Based Architecture (FS_SBA-Sec) (Rel-15)
| Yes |
Yes
| approved | No | S3‑192629 | |
S3‑193096 | LS to SA2 on UP gateway function | Deutsche Telekom | LS out | Approval |
8.1Study on Security Aspects of the 5G Service Based Architecture (FS_SBA-Sec) (Rel-15)
| Yes |
Yes
| approved | No | ||
S3‑193097 | Update of solution #15 in TR 33.855 | Huawei, Hisilicon | pCR | Approval |
8.1Study on Security Aspects of the 5G Service Based Architecture (FS_SBA-Sec) (Rel-15)
| Yes |
Yes
| approved | No | S3‑192687 | |
S3‑193098 | New Solution: resource level authorization using access tokens | Ericsson | pCR | Approval |
8.1Study on Security Aspects of the 5G Service Based Architecture (FS_SBA-Sec) (Rel-15)
| Yes |
Yes
| approved | No | S3‑192817 | |
S3‑193099 | eSBA: Add conclusion on KI #29 | Nokia, Nokia Shanghai Bell | pCR | Approval |
8.1Study on Security Aspects of the 5G Service Based Architecture (FS_SBA-Sec) (Rel-15)
| Yes |
Yes
| approved | No | S3‑192613 | |
S3‑193100 | Resolving the ENs in Solution #25 | Huawei, Hisilicon | pCR | Approval |
8.1Study on Security Aspects of the 5G Service Based Architecture (FS_SBA-Sec) (Rel-15)
| Yes |
Yes
| approved | No | S3‑192693 | |
S3‑193101 | New KI: Botnet threats caused from improper CIOT device usage | NIST, ATT, SPRINT, CABLE LABS, CISCO | pCR | Approval |
8.4Study on evolution of Cellular IoT security for the 5G System (FS_CIoT_sec_5G) (Rel-16)
| Yes |
Yes
| approved | No | S3‑192916 | |
S3‑193102 | Address EN in key issue 13 and solution 20 | Huawei, Hisilicon | pCR | Approval |
8.4Study on evolution of Cellular IoT security for the 5G System (FS_CIoT_sec_5G) (Rel-16)
| Yes |
YesRemoval of the last editor's note only.
| approved | No | S3‑192769 | |
S3‑193103 | Draft TR 33.861 | Ericsson | draft TR | Approval |
8.4Study on evolution of Cellular IoT security for the 5G System (FS_CIoT_sec_5G) (Rel-16)
| No |
Yes
| left for email approval | No | ||
S3‑193104 | Evaluation to Sol#4 | Ericsson, Intel | pCR | Approval |
8.4Study on evolution of Cellular IoT security for the 5G System (FS_CIoT_sec_5G) (Rel-16)
| Yes |
Yes
| approved | No | S3‑192895 | |
S3‑193105 | Address EN in solution 19 | Huawei, Hisilicon | pCR | Approval |
8.4Study on evolution of Cellular IoT security for the 5G System (FS_CIoT_sec_5G) (Rel-16)
| Yes |
Yes
| approved | No | S3‑192773 | |
S3‑193106 | Mitigate DDoS Attack on RAN based on RAN coordination | Huawei, Hisilicon | pCR | Approval |
8.4Study on evolution of Cellular IoT security for the 5G System (FS_CIoT_sec_5G) (Rel-16)
| Yes |
Yes
| approved | No | S3‑192789 | |
S3‑193107 | CIOT: New solution for protection of NAS Redirection message | Ericsson | pCR | Approval |
8.4Study on evolution of Cellular IoT security for the 5G System (FS_CIoT_sec_5G) (Rel-16)
| Yes |
Yes
| approved | No | S3‑192898 | |
S3‑193108 | Conclusion for Key Issue #13 | Huawei, Hisilicon | pCR | Approval |
8.4Study on evolution of Cellular IoT security for the 5G System (FS_CIoT_sec_5G) (Rel-16)
| Yes |
Yes
| approved | No | S3‑192770 | |
S3‑193109 | Address two Editors Note of solution 4 | Huawei, Hisilicon | pCR | Approval |
8.5Study on the security of the Wireless and Wireline Convergence for the 5G system architecture (FS_5WWC_SEC) (Rel-16)
| Yes |
Yes
| approved | No | S3‑192754 | |
S3‑193110 | Draft TR 33.807 | Huawei | draft TR | Approval |
8.5Study on the security of the Wireless and Wireline Convergence for the 5G system architecture (FS_5WWC_SEC) (Rel-16)
| No |
Yes
| left for email approval | No | ||
S3‑193111 | Evaluation of Solution #7 | Ericsson | pCR | Approval |
8.5Study on the security of the Wireless and Wireline Convergence for the 5G system architecture (FS_5WWC_SEC) (Rel-16)
| No |
Yes
| withdrawn | Yes | ||
S3‑193112 | Add conclusion for KI#2 | Huawei, Hisilicon | pCR | Approval |
8.5Study on the security of the Wireless and Wireline Convergence for the 5G system architecture (FS_5WWC_SEC) (Rel-16)
| Yes |
YesOnly first change is kept.
| approved | No | S3‑192758 | |
S3‑193113 | Draft TR 33.815 | Sprint | draft TR | Approval |
8.6Study on Security Aspects of PARLOS (FS_PARLOS_Sec) (Rel-16)
| No |
Yes
| left for email approval | No | ||
S3‑193114 | A solution to providing some network authorisation in PARLOS | Qualcomm Incorporated | pCR | Approval |
8.6Study on Security Aspects of PARLOS (FS_PARLOS_Sec) (Rel-16)
| Yes |
Yes
| approved | No | S3‑192943 | |
S3‑193115 | pCR to 33.815 clarifying requirements on Parlos | DOCOMO Communications Lab. | pCR | Approval |
8.6Study on Security Aspects of PARLOS (FS_PARLOS_Sec) (Rel-16)
| Yes |
Yes
| approved | No | S3‑192965 | |
S3‑193116 | Proposed conclusion on providing some network authorisation in PARLOS | Qualcomm Incorporated,Spring | pCR | Approval |
8.6Study on Security Aspects of PARLOS (FS_PARLOS_Sec) (Rel-16)
| Yes |
Yes
| approved | No | S3‑192944 | |
S3‑193117 | P-CR: Proposed recommendations for PARLOS | Sprint Corporation | pCR | Agreement |
8.6Study on Security Aspects of PARLOS (FS_PARLOS_Sec) (Rel-16)
| No |
Yes
| withdrawn | Yes | ||
S3‑193118 | Addressing EN in PARLOS Evaluation clause 7.2.3 | Nokia, Nokia Shangahi Bell | pCR | Approval |
8.6Study on Security Aspects of PARLOS (FS_PARLOS_Sec) (Rel-16)
| Yes |
YesChanges in the evaluation clause were kept.
The solution changes are merged in 114 as suggested by Qualcomm.
| approved | No | S3‑192583 | |
S3‑193119 | Draft TR 33.813 | Nokia | draft TR | Approval |
8.8Study on Security aspects of Enhancement of Network Slicing (FS_eNS_SEC) (Rel-16)
| No |
Yes
| left for email approval | No | ||
S3‑193120 | Addressing EN in solution 6 | Huawei, HiSilicon | pCR | Approval |
8.8Study on Security aspects of Enhancement of Network Slicing (FS_eNS_SEC) (Rel-16)
| No |
Yes
| noted | No | S3‑192720 | |
S3‑193121 | Adding evaluation to Solution 7 | Ericsson | pCR | Approval |
8.8Study on Security aspects of Enhancement of Network Slicing (FS_eNS_SEC) (Rel-16)
| Yes |
Yes
| approved | No | S3‑192848 | |
S3‑193122 | Update to Solution 8 protecting NSSAI in AS layer | Nokia, Nokia Shanghai Bell, Ericsson | pCR | Approval |
8.8Study on Security aspects of Enhancement of Network Slicing (FS_eNS_SEC) (Rel-16)
| Yes |
Yes
| approved | No | S3‑192584 | |
S3‑193123 | Resolving editors notes on solution #10 in TR 33.813 | Qualcomm Incorporated | pCR | Approval |
8.8Study on Security aspects of Enhancement of Network Slicing (FS_eNS_SEC) (Rel-16)
| Yes |
Yes
| approved | No | S3‑192931 | |
S3‑193124 | TR 33.813 - update for solution #11 | InterDigital Communications | pCR | Approval |
8.8Study on Security aspects of Enhancement of Network Slicing (FS_eNS_SEC) (Rel-16)
| Yes |
Yes
| approved | No | S3‑192528 | |
S3‑193125 | Solution on privacy protection of NSSAI | ZTE Corporation | pCR | Approval |
8.8Study on Security aspects of Enhancement of Network Slicing (FS_eNS_SEC) (Rel-16)
| Yes |
Yes
| approved | No | S3‑192627 | |
S3‑193126 | LS on AUSF role | Ericsson | LS out | Approval |
8.8Study on Security aspects of Enhancement of Network Slicing (FS_eNS_SEC) (Rel-16)
| Yes |
Yes
| approved | No | S3‑192850 | |
S3‑193127 | Complete the Evaluation for Solution #4 | Nokia, Nokia Shanghai Bell | pCR | Approval |
8.9Study on Security of the enhancement to the 5GC location services (FS_eLCS_Sec) (Rel-16)
| Yes |
Yes
| approved | No | S3‑192676 | |
S3‑193128 | Draft TR 33.814 | CATT | draft TR | Approval |
8.9Study on Security of the enhancement to the 5GC location services (FS_eLCS_Sec) (Rel-16)
| No |
Yes
| left for email approval | No | ||
S3‑193129 | Cover sheet TR 33.814 for approval | CATT | TS or TR cover | Approval |
8.9Study on Security of the enhancement to the 5GC location services (FS_eLCS_Sec) (Rel-16)
| Yes |
Yes
| approved | No | ||
S3‑193130 | Draft TR 33.825 | Huawei | draft TR | Approval |
8.10Study on security for 5G URLLC (FS_5G URLLC_SEC) (Rel-16)
| No |
Yes
| left for email approval | No | ||
S3‑193131 | Cover sheet 33.825 for approval | Huawei | TS or TR cover | Approval |
8.10Study on security for 5G URLLC (FS_5G URLLC_SEC) (Rel-16)
| Yes |
Yes
| approved | No | ||
S3‑193132 | Draft TR 33.819 | Nokia | draft TR | Approval |
8.12Study on Security for 5GS Enhanced support of Vertical and LAN Services (FS_Vertical_LAN_SEC) (Rel-16)
| No |
Yes
| left for email approval | No | ||
S3‑193133 | TSC key issue on time synchronization | Nokia, Nokia Shanghai Bell | pCR | Approval |
8.12Study on Security for 5GS Enhanced support of Vertical and LAN Services (FS_Vertical_LAN_SEC) (Rel-16)
| Yes |
Yes
| approved | No | S3‑192597 | |
S3‑193134 | Conclusion to Key Issue #6.1 | Samsung | pCR | Approval |
8.12Study on Security for 5GS Enhanced support of Vertical and LAN Services (FS_Vertical_LAN_SEC) (Rel-16)
| Yes |
YesEvaluation change stayed.
| approved | No | S3‑192953 | |
S3‑193135 | TR 33.819 - DH based solution for CAG ID privacy | InterDigital Communications | pCR | Approval |
8.12Study on Security for 5GS Enhanced support of Vertical and LAN Services (FS_Vertical_LAN_SEC) (Rel-16)
| Yes |
Yes
| approved | No | S3‑192526 | |
S3‑193136 | TR 33.819 - hash based solution for CAG ID privacy | InterDigital Communications | pCR | Approval |
8.12Study on Security for 5GS Enhanced support of Vertical and LAN Services (FS_Vertical_LAN_SEC) (Rel-16)
| Yes |
YesAdding several editor's notes addressing Huawei's comments.
| approved | No | S3‑192527 | |
S3‑193137 | LS on link layer ID update | NEC | LS out | Approval |
8.18Study on Security Aspects of 3GPP support for Advanced V2X Services (FS_eV2X_Sec)
| No |
Yes
| withdrawn | Yes | ||
S3‑193138 | Living Document: New Annex for the SEPP in TR 33.926 | Nokia, Nokia Shanghai Bell | draftCR | Approval |
7.2.7Security Edge Protection Proxy (SEPP) (TS 33.517)
| Yes |
Yes
| approved | No | S3‑192602 | |
S3‑193139 | Adding SEPP critical assets and threats to TR 33.926 | Huawei, Hisilicon | CR | Approval |
7.2.7Security Edge Protection Proxy (SEPP) (TS 33.517)
| Yes |
Yes
| agreed | No | S3‑192700 | |
S3‑193140 | Way forward - KI#2 Proposal#4 SI protection | Ericsson, Nokia, Vodafone, Deutsche Telekom AG, CableLabs, AT&T, NIST, CATT, China Unicom, Apple, Samsung | pCR | Approval |
8.7Study on 5G security enhancement against false base stations (FS_5GFBS) (Rel-16)
| No |
Yes
| withdrawn | Yes | ||
S3‑193141 | Solution for CAG ID protection | Huawei, Hisilicon | pCR | Approval |
8.12Study on Security for 5GS Enhanced support of Vertical and LAN Services (FS_Vertical_LAN_SEC) (Rel-16)
| Yes |
Yes
| approved | No | S3‑192690 | |
S3‑193142 | LS on sending CAG-ID in NAS signalling | Qualcomm Incorporated | LS out | Approval |
8.12Study on Security for 5GS Enhanced support of Vertical and LAN Services (FS_Vertical_LAN_SEC) (Rel-16)
| Yes |
Yes
| approved | No | ||
S3‑193143 | Update to Key issue#5 in UP IP | Apple | pCR | Approval |
8.14Study on User Plane Integrity Protection (FS_UP_IP_Sec) (Rel-16)
| Yes |
YesImproving the English.
| approved | No | S3‑192647 | |
S3‑193144 | pCR to 33.853 - addition of solution for LTE | Vodafone Espaρa SA | pCR | Approval |
8.14Study on User Plane Integrity Protection (FS_UP_IP_Sec) (Rel-16)
| Yes |
Yes
| approved | No | S3‑192659 | |
S3‑193145 | Resolving the Editor's note for Solution 5 in TR 33.853 | China Mobile | pCR | Approval |
8.14Study on User Plane Integrity Protection (FS_UP_IP_Sec) (Rel-16)
| Yes |
Yes
| approved | No | S3‑192728 | |
S3‑193146 | New Solution for a UE connected to 5GC indicating its support of UP IP over eUTRA | Ericsson | pCR | Approval |
8.14Study on User Plane Integrity Protection (FS_UP_IP_Sec) (Rel-16)
| Yes |
YesAdding an editor's note adressing Nokia's concerns.
Changes in notation as proposed by Qualcomm.
| approved | No | S3‑192801 | |
S3‑193147 | Draft TR 33.853 | Vodafone | draft TR | Approval |
8.14Study on User Plane Integrity Protection (FS_UP_IP_Sec) (Rel-16)
| No |
Yes
| left for email approval | No | ||
S3‑193148 | IAB-node: terminology change | THALES, ORANGE | pCR | Approval |
8.17Study on Security for NR Integrated Access and Backhaul (FS_NR_IAB_Sec)
| Yes |
YesAdding an editor's note on the terminology.
| approved | No | S3‑192665 | |
S3‑193149 | Draft TR 33.824 | Samsung | draft TR | Approval |
8.17Study on Security for NR Integrated Access and Backhaul (FS_NR_IAB_Sec)
| No |
Yes
| left for email approval | No | ||
S3‑193150 | IAB: Assumptions related to key hierarchy in IAB architecture in 5G | Ericsson | pCR | Approval |
8.17Study on Security for NR Integrated Access and Backhaul (FS_NR_IAB_Sec)
| Yes |
YesAddressing the comments on the use of MT.
| approved | No | S3‑192825 | |
S3‑193151 | Requirement on authorization of IAB Node | Samsung | pCR | Approval |
8.17Study on Security for NR Integrated Access and Backhaul (FS_NR_IAB_Sec)
| Yes |
Yes
| approved | No | S3‑192911 | |
S3‑193152 | Solution for authorization of IAB Node | Samsung | pCR | Approval |
8.17Study on Security for NR Integrated Access and Backhaul (FS_NR_IAB_Sec)
| Yes |
YesChange in clause 6.3.1.1 removed.
| approved | No | S3‑192912 | |
S3‑193153 | KI #2.3: security threats and potential requirements | Ericsson | pCR | Approval |
8.17Study on Security for NR Integrated Access and Backhaul (FS_NR_IAB_Sec)
| Yes |
Yes
| approved | No | S3‑192826 | |
S3‑193154 | 33.836 - solution #1 update | InterDigital Communications | pCR | Approval |
8.18Study on Security Aspects of 3GPP support for Advanced V2X Services (FS_eV2X_Sec)
| Yes |
Yes
| approved | No | S3‑192522 | |
S3‑193155 | TR 33.836 - update for solution #2 | InterDigital Communications | pCR | Approval |
8.18Study on Security Aspects of 3GPP support for Advanced V2X Services (FS_eV2X_Sec)
| Yes |
Yes
| approved | No | S3‑192523 | |
S3‑193156 | Draft TR 33.836 | LG | draft TR | Approval |
8.18Study on Security Aspects of 3GPP support for Advanced V2X Services (FS_eV2X_Sec)
| No |
Yes
| left for email approval | No | ||
S3‑193157 | TR 33.836 - solution #3 update | InterDigital Communications | pCR | Approval |
8.18Study on Security Aspects of 3GPP support for Advanced V2X Services (FS_eV2X_Sec)
| Yes |
Yes
| approved | No | S3‑192524 | |
S3‑193158 | TR 33.836 solution #4 update | InterDigital Communications | pCR | Approval |
8.18Study on Security Aspects of 3GPP support for Advanced V2X Services (FS_eV2X_Sec)
| Yes |
YesSame editor's notes about 5G Prose were added.
| approved | No | S3‑192525 | |
S3‑193159 | new solution on privacy protection for unicast | NEC Corporation | pCR | Approval |
8.18Study on Security Aspects of 3GPP support for Advanced V2X Services (FS_eV2X_Sec)
| Yes |
Yes
| approved | No | S3‑192571 | |
S3‑193160 | eV2X: New solution for Security for eV2X unicast messages over PC5 | Intel Deutschland GmbH | pCR | Approval |
8.18Study on Security Aspects of 3GPP support for Advanced V2X Services (FS_eV2X_Sec)
| Yes |
YesMotorola: replay protection should be addressed. This was taken offlie.
Interdigital had multiple comments that were addressed in editor's notes.
| approved | No | S3‑192634 | |
S3‑193161 | Proposed solution for deriving PC5 layer keys based on higher layer keys | Qualcomm Incorporated | pCR | Approval |
8.18Study on Security Aspects of 3GPP support for Advanced V2X Services (FS_eV2X_Sec)
| Yes |
Yes
| approved | No | S3‑192932 | |
S3‑193162 | new KI on privacy protection for broadcast | NEC Corporation | pCR | Approval |
8.18Study on Security Aspects of 3GPP support for Advanced V2X Services (FS_eV2X_Sec)
| Yes |
YesAdding an editor's note as proposed by Ericsson.
| approved | No | S3‑192569 | |
S3‑193163 | V2X Group Key Provisioning | Lenovo, Motorola Mobility | pCR | Approval |
8.18Study on Security Aspects of 3GPP support for Advanced V2X Services (FS_eV2X_Sec)
| Yes |
Yes
| approved | No | S3‑192741 | |
S3‑193164 | new KI on minimizing the impact of privacy protection mechanism in the application layer communication | NEC Corporation | pCR | Approval |
8.18Study on Security Aspects of 3GPP support for Advanced V2X Services (FS_eV2X_Sec)
| Yes |
Yes
| approved | No | S3‑192574 | |
S3‑193165 | new solution on minimizing the impact of privacy protection mechanism in the application layer communication | NEC Corporation | pCR | Approval |
8.18Study on Security Aspects of 3GPP support for Advanced V2X Services (FS_eV2X_Sec)
| Yes |
Yes
| approved | No | S3‑192575 | |
S3‑193166 | New KI: Key issue on UP security policy handling for PC5 and Uu interface | Huawei, Hisilicon | pCR | Approval |
8.18Study on Security Aspects of 3GPP support for Advanced V2X Services (FS_eV2X_Sec)
| Yes |
YesJust to remove "SA5" next to the reference.
| approved | No | S3‑192695 | |
S3‑193167 | terminology alignment on groupcast | NEC Corporation | pCR | Approval |
8.18Study on Security Aspects of 3GPP support for Advanced V2X Services (FS_eV2X_Sec)
| Yes |
YesLG asked to remove the added requirements.
| approved | No | S3‑192568 | |
S3‑193168 | Draft TR 33.835 | China Mobile | draft TR | Approval |
8.3Study on authentication and key management for applications based on 3GPP credential in 5G IoT (FS_AKMA)(Rel-16)
| No |
Yes
| left for email approval | No | ||
S3‑193169 | Solution #15 updates including evaluation update | Ericsson | pCR | Approval |
8.3Study on authentication and key management for applications based on 3GPP credential in 5G IoT (FS_AKMA)(Rel-16)
| Yes |
Yes
| approved | No | S3‑192885 | |
S3‑193170 | Conclusion on AKMA architecture and authentication procedure | China Mobile, Nokia, Nokia Shanghai Bell | pCR | Approval |
8.3Study on authentication and key management for applications based on 3GPP credential in 5G IoT (FS_AKMA)(Rel-16)
| Yes |
Yes
| approved | No | S3‑192677 | |
S3‑193171 | Resovle Editor's notes in Solution for Key freshness in AKMA | Huawei, Hisilicon | pCR | Approval |
8.3Study on authentication and key management for applications based on 3GPP credential in 5G IoT (FS_AKMA)(Rel-16)
| Yes |
Yes
| approved | No | S3‑192788 | |
S3‑193172 | New KI for TR 33.835 - roaming environment | InterDigital Communications | pCR | Approval |
8.3Study on authentication and key management for applications based on 3GPP credential in 5G IoT (FS_AKMA)(Rel-16)
| No |
Yes
| withdrawn | Yes | ||
S3‑193173 | Way forward - KI#1 Proposal#1 UE caps | Ericsson, Nokia, Vodafone, Deutsche Telekom AG, CableLabs, LG Electronics, Samsung, Apple | pCR | Approval |
8.7Study on 5G security enhancement against false base stations (FS_5GFBS) (Rel-16)
| Yes |
Yes
| approved | No | S3‑192863 | |
S3‑193174 | eSBA: Add conclusion on KI #23 | Nokia, Nokia Shanghai Bel,Ericssonl | pCR | Approval |
8.1Study on Security Aspects of the 5G Service Based Architecture (FS_SBA-Sec) (Rel-15)
| Yes |
Yes
| approved | No | S3‑192614 | |
S3‑193175 | LS to RAN2 on FBS detection | Huawei, HiSilicon | LS out | Approval |
8.7Study on 5G security enhancement against false base stations (FS_5GFBS) (Rel-16)
| Yes |
Yes
| approved | No | S3‑192739 | |
S3‑193176 | Draft TR 33.809 | Apple | draft TR | Approval |
8.7Study on 5G security enhancement against false base stations (FS_5GFBS) (Rel-16)
| No |
Yes
| left for email approval | No | ||
S3‑193177 | Cover sheet for TR 33.835 information | China Mobile | TS or TR cover | Approval |
8.3Study on authentication and key management for applications based on 3GPP credential in 5G IoT (FS_AKMA)(Rel-16)
| Yes |
Yes
| approved | No | ||
S3‑193178 | New WID on Authentication and Key Management for Applications based on 3GPP credential in 5G | China Mobile | WID new | Approval |
7.12New Work Item proposals
| Yes |
Yes
| agreed | No | S3‑192859 | |
S3‑193179 | Cover sheet TR 33.807 for approval | Huawei | TS or TR cover | Approval |
8.5Study on the security of the Wireless and Wireline Convergence for the 5G system architecture (FS_5WWC_SEC) (Rel-16)
| Yes |
Yes
| approved | No | ||
S3‑193180 | Draft TR 33.818 | China Mobile | draft TR | Approval |
8.11Study on SECAM and SCAS for 3GPP virtualized network products (FS_VNP_SECAM_SCAS) (Rel-16)
| No |
Yes
| left for email approval | No | ||
S3‑193181 | Adding contents into clause 4.8 | China Mobile | pCR | Approval |
8.11Study on SECAM and SCAS for 3GPP virtualized network products (FS_VNP_SECAM_SCAS) (Rel-16)
| Yes |
Yes
| approved | No | S3‑192838 | |
S3‑193182 | Adding the description of the parts in SCAS documents and ToE into clause 5.2.1 and 5.2.2 | China Mobile M2M Company Ltd. | pCR | - |
8.11Study on SECAM and SCAS for 3GPP virtualized network products (FS_VNP_SECAM_SCAS) (Rel-16)
| Yes |
Yes
| approved | No | S3‑192841 | |
S3‑193183 | Adding the description of Generic Vitualized Network Product model of type 1 | China Mobile | pCR | Approval |
8.11Study on SECAM and SCAS for 3GPP virtualized network products (FS_VNP_SECAM_SCAS) (Rel-16)
| Yes |
Yes
| approved | No | S3‑192842 | |
S3‑193184 | Adding the description for generic virtualized network product model of type 2 | China Mobile M2M Company Ltd. | pCR | Approval |
8.11Study on SECAM and SCAS for 3GPP virtualized network products (FS_VNP_SECAM_SCAS) (Rel-16)
| Yes |
Yes
| approved | No | S3‑192843 | |
S3‑193185 | Draft TR 33.848 | BT | draft TR | Approval |
8.15Study on Security Impacts of Virtualisation (FS_SIV) (Rel-16)
| Yes |
Yes
| left for email approval | No | ||
S3‑193186 | Update of Authentication Enhancements SID | Qualcomm Incorporated | SID revised | Agreement |
8.16Study on authentication enhancements in 5GS (FS_AUTH_ENH) (Rel-16)
| Yes |
YesIncluding the new dates.
| agreed | No | S3‑192919 | |
S3‑193187 | Key issue on the authenticaiton result storage in the UDM | Huawei, Hisilicon | pCR | Approval |
8.16Study on authentication enhancements in 5GS (FS_AUTH_ENH) (Rel-16)
| Yes |
Yes
| approved | No | S3‑192692 | |
S3‑193188 | Draft TR 33.846 | Ericsson | draft TR | Approval |
8.16Study on authentication enhancements in 5GS (FS_AUTH_ENH) (Rel-16)
| No |
Yes
| left for email approval | No | ||
S3‑193189 | Handling of Sync failure | ZTE Corporation | pCR | Approval |
8.16Study on authentication enhancements in 5GS (FS_AUTH_ENH) (Rel-16)
| Yes |
Yes
| approved | No | S3‑192622 | |
S3‑193190 | A Solution for Key Isssue#2.1 and key issue #4.1 in TR 33.846 | China Mobile | pCR | Approval |
8.16Study on authentication enhancements in 5GS (FS_AUTH_ENH) (Rel-16)
| Yes |
Yes
| approved | No | S3‑192681 | |
S3‑193191 | mitigate the linkability attack | Huawei, Hisilicon | pCR | Approval |
8.16Study on authentication enhancements in 5GS (FS_AUTH_ENH) (Rel-16)
| Yes |
Yes
| approved | No | S3‑192972 | |
S3‑193192 | Conclusion on KI#15 | Ericsson | pCR | Approval |
8.5Study on the security of the Wireless and Wireline Convergence for the 5G system architecture (FS_5WWC_SEC) (Rel-16)
| Yes |
Yes
| approved | No | S3‑192797 | |
S3‑193193 | Key issue on Secure network credentials creation for constrained devices | Nokia, Nokia Shanghai Bell, Perspecta Labs, Interdigital | pCR | Approval |
8.12Study on Security for 5GS Enhanced support of Vertical and LAN Services (FS_Vertical_LAN_SEC) (Rel-16)
| Yes |
Yes
| noted | No | S3‑192599 | |
S3‑193194 | Notes of the second offline session on AMF relocation | NTT-Docomo | report | Information |
7.1.3Other 5G security aspects
| Yes |
Yes
| noted | No | ||
S3‑193195 | Draft LS on security asepcts of AMF re-alocation procedure | Ericsson | LS out | Approval |
7.1.3Other 5G security aspects
| Yes |
Yes
| merged | No | S3‑193197 | S3‑193084 |
S3‑193196 | Draft LS on security asepcts of AMF re-alocation procedure | Huawei | other | discussion |
7.1.3Other 5G security aspects
| Yes |
YesThis contains part of the LS in tdoc 084.
| revised | No | S3‑193197 | |
S3‑193197 | LS on security asepcts of AMF re-alocation procedure | Qualcomm | LS out | Approval |
7.1.3Other 5G security aspects
| Yes |
Yes
| approved | No | S3‑193196 | |
S3‑193198 | Cover sheet TS 33.517 for approval | Nokia | TS or TR cover | Approval |
7.2.7Security Edge Protection Proxy (SEPP) (TS 33.517)
| Yes |
Yes
| approved | No | ||
S3‑193199 | SA3 meeting calendar | MCC | other | - |
10Future Meeting Dates and Venues
| Yes |
Yes
| revised | No | S3‑193203 | S3‑192503 |
S3‑193200 | Work item on integrating GBA to 5GC | Ericsson, Vodafone | WID new | Approval |
7.12New Work Item proposals
| Yes |
Yes
| agreed | No | S3‑192883 | |
S3‑193201 | New Key Issue on Rejected S-NSSAI Revokation | Lenovo, Motorola Mobility | pCR | Approval |
8.8Study on Security aspects of Enhancement of Network Slicing (FS_eNS_SEC) (Rel-16)
| Yes |
Yes
| approved | No | S3‑192744 | |
S3‑193202 | Work Plan input from Rapporteurs | MCC | other | - |
9.2Rapporteur input on status of WID or SID
| No |
Yes
| noted | No | S3‑192504 | |
S3‑193203 | SA3 meeting calendar | MCC | other | - |
10Future Meeting Dates and Venues
| Yes |
Yes
| noted | No | S3‑193199 |