Tdoc List

2019-08-30 17:51

Agenda Topic TDoc Title Source Type For Avail Treated Decision Wdrn Replaced-by Replaces
1 Opening of the Meeting                      
2 Approval of Agenda and Meeting Objectives S3‑192500 Agenda WG Chairman agenda   Yes
Yes
revised No S3‑192978  
    S3‑192978 Agenda WG Chairman agenda - Yes
Yes
approved No   S3‑192500
3 IPR and Anti-Trust Law Reminder                      
4 Meeting Reports                      
4.1 Approval of the report from previous SA3 meeting(s) S3‑192501 Report from last SA3 meeting/s MCC report   Yes
Yes
approved No    
4.2 Report from SA Plenary                      
4.3 Report from SA3-LI                      
5 Items for early consideration                      
6 Reports and Liaisons from other Groups                      
6.1 3GPP Working Groups S3‑192506 LS on Broadcast of Location Assistance Data for NR S2-1908104 LS in   Yes
Yes
noted No    
    S3‑192509 Reply LS on DL-only UE-based positioning S2-1908624 LS in   Yes
Yes
noted No    
6.2 IETF                      
6.3 ETSI SAGE S3‑192535 256 bit radio interface algorithm performance ETSI SAGE LS in   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‑192980 Reply to: 256 bit radio interface algorithm performance Qualcomm LS out approval Yes
Yes
noted No    
    S3‑192946 On the requirements for 256-bit algorithms Qualcomm Incorporated other Endorsement 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 don’t 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    
6.4 GSMA                      
6.5 TCG S3‑192520 TCG progress report InterDigital Communications report Information 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    
6.6 oneM2M                      
6.7 TC-CYBER                      
6.8 ETSI NFV                      
6.9 CVDs and Research S3‑192600 Way forward on CVD and research CableLabs, BT, Nokia discussion Endorsement Yes
YesVodafone wasn’t 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
6.10 Other Groups S3‑192505 Wireline Access Security requirements BBF LS in   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‑192512 LS on withdrawal of TS 103 383 “Smart Cards; Embedded UICC; Requirements Specification” ETSI TC SCP LS in   Yes
YesOrange brought 4 CRs for this meeting to address this issue; these were in another agenda item and agreed.
replied to No    
    S3‑192986 Reply to: LS on withdrawal of TS 103 383 “Smart Cards; Embedded UICC; Requirements Specification” Orange LS out approval Yes
Yes
approved No    
    S3‑192513 LS on SG11 activities related to improvement of the SS7 security including for digital financial services ITU-T SG11 LS in   Yes
YesBT recommended the group to read the attached documents as there were some points of interest for operators.
noted No    
    S3‑192533 LS from TC SmartM2M STF547 to 3GPP SA1 Cc SA3 ETSI TC SmartM2M LS in   Yes
Yes
noted No    
7 Work Areas                      
7.1 Security aspects of 5G System - Phase 1 (5GS_Ph1-SEC) (Rel-15)                      
7.1.1 UDR S3‑192514 Reply LS on Nudr Sensitive Data Protection SP-190581 LS in   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‑192933 Minutes of SA3/CT4 call on Nudr sensitive data protection SA3 Vice-chair (Qualcomm Incorporated) other Information Yes
Yes
noted No    
    S3‑192586 Summary of updates to S3-192276 from last meeting Nokia, Nokia Shanghai Bell discussion Endorsement Yes
Yes
noted No    
    S3‑192587 Definition of authentication subscription data and update to UDM requirement Nokia, Nokia Shanghai Bell CR Agreement 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‑192987 Definition of authentication subscription data and update to UDM requirement Nokia, Nokia Shanghai Bell CR Agreement Yes
Yes
agreed No   S3‑192587
    S3‑192588 Requirement on UDR Nokia, Nokia Shanghai Bell CR Agreement 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 Yes
YesVodafone,NTT-Docomo and Orange didn’t agree with this.Only the change in the abbreviation update was agreed. Orange added that they didn’t 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‑192988 Missing UDR description in alignment with 29.505 Nokia, Nokia Shanghai Bell CR Agreement Yes
Yes
agreed No   S3‑192589
    S3‑192591 Adding Nudr service Nokia, Nokia Shanghai Bell CR Agreement Yes
YesNokia added that this coud be done in Release 16 and proposed to not pursue it.
not pursued No   S3‑192056
    S3‑192590 Update on ARPF Nokia, Nokia Shanghai Bell CR Agreement 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‑192989 Update on ARPF Nokia, Nokia Shanghai Bell CR Agreement Yes
Yes
agreed No   S3‑192590
    S3‑193083 Discussion on UDR related contributions Nokia discussion discussion Yes
Yes
endorsed No    
7.1.2 Incoming and outgoing related Lses                      
7.1.3 Other 5G security aspects S3‑192530 Corrections for Definitions and Abbreviations clauses AT&T, Interdigital, Nokia CR Approval 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 didn’t 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‑192624 Correcting references ZTE Corporation CR Agreement Yes
YesEricsson: second change refer directly to TS 33.210 instead.
revised No S3‑192990  
    S3‑192990 Correcting references ZTE Corporation CR Agreement Yes
Yes
agreed No   S3‑192624
    S3‑192625 Removing editor notes ZTE Corporation CR Agreement 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‑192991 Removing editor notes ZTE Corporation CR Agreement Yes
Yes
agreed No   S3‑192625
    S3‑192540 Correction of text on access authentication for untrusted access BlackBerry UK Limited CR Agreement Yes
YesTreated as item for early consideration. Lenovo: the WLAN part is out of scope for us. We don’t want to see this. Nokia didn’t 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 didn’t have a requirement for that. Huawei: you can fall back to Release 8 and use LTE security.
revised No S3‑192979  
    S3‑192979 Correction of text on access authentication for untrusted access BlackBerry UK Limited CR Agreement Yes
Yes
agreed No   S3‑192540
    S3‑192793 Modification of the message name in the key derivation during handover CATT CR Agreement 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‑192708 Clarification on the topology hiding in SBI Huawei, Hisilicon CR Approval 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‑192947 Aligning KAUSF storage at the UE with SoR and UPU procedures Qualcomm Incorporated CR Agreement Yes
Yes
agreed No    
    S3‑192862 Security of RRC UE capability transfer procedure in 5GS Ericsson CR Agreement Yes
YesQualcomm: this won’t work with CIoT Ues that don’t support AES security.it's probably OK to release 15 (we don’t support CIoT optimizations there) but not for the other releases.
agreed No    
    S3‑192792 Discussion on the procedure of secondary authentication China Mobile discussion Discussion 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‑192794 Adjust the proceudure of GPSI and IP/MAC notification China Mobile CR Approval Yes
YesHuawei: call flow needs to be updated. Qualcomm: the baseline is wrong, showing only some steps.
revised No S3‑192992  
    S3‑192992 Adjust the proceudure of GPSI and IP/MAC notification China Mobile CR Approval Yes
Yes
agreed No   S3‑192794
    S3‑192777 Clarification for Secondary Authentication Huawei, Hisilicon CR Approval Yes
Yes
revised No S3‑192993  
    S3‑192993 Clarification for Secondary Authentication Huawei, Hisilicon CR Approval Yes
Yes
agreed No   S3‑192777
    S3‑192929 Discussion on leaving AMF relocation solutions to after Rel-15 Qualcomm Incorporated discussion Endorsement Yes
YesZTE supported the proposal.Huawei didn’t 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 didn’t agree and considered this needed in Release 15.
noted No    
    S3‑192930 Discussion on possible solutions to AMF relocation issues Qualcomm Incorporated discussion Discussion Yes
YesThis discussion was taken offline.
noted No   S3‑191911
    S3‑192887 Discussion about AMF re-allocation and slicing Ericsson discussion Approval Yes
YesHuawei just supported number 7. China Mobile didn’t 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 Yes
YesNokia: no need to have a new clause on this. This was left offline together with the related documents.
not pursued No    
    S3‑192615 Discussion on registration with AMF re-allocation ZTE Corporation discussion Discussion Yes
Yes
noted No    
    S3‑192617 Security for registration with AMF re-allocation ZTE Corporation CR Agreement Yes
YesNokia didn't believe that this was solving the issue. Huawei agreed.
not pursued No    
    S3‑192711 Discussing registration failure in registration procedure with AMF reallocation Huawei, Hisilicon, CAICT discussion Endorsement Yes
Yes
noted No    
    S3‑192710 Solving registration failure in registration procedure with AMF reallocation Huawei, Hisilicon, CAICT CR Approval Yes
YesEricsson: we disagree with having the UE accepting protected messages. This had to be 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 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‑193058 Claification on UE context transfer in registration with AMF reallocation via direct NAS reroute Huawei, Hisilicon CR Approval Yes
Yes
agreed No   S3‑192709
    S3‑192616 Discussion on Identity Request with AMF re-allocation ZTE Corporation discussion Discussion Yes
Yes
noted No    
    S3‑192618 LS on registration and identity request issues with AMF re-allocation ZTE Corporation LS out Approval Yes
Yes
noted No    
    S3‑192889 LS on AMF reallocation between Network Slices Ericsson LS out Approval Yes
Yes
noted No    
    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 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 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‑192997 Correction of handling of 5G security contexts during EPS to 5GS idle mode mobility Intel Deutschland GmbH,Qualcomm CR Agreement Yes
Yes
agreed No   S3‑192631
    S3‑192941 NAS Count values in the mapped EPS security context in 5GS to EPS change Qualcomm Incorporated CR Agreement Yes
YesIntel didn’t 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‑192682 Description of issue of security context transfer following the handover from EPS to 5GS Huawei, Hisilicon discussion Discussion 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 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‑192998 Security context transfer following the handover from EPS to 5GS Huawei, Hisilicon CR Approval Yes
Yes
agreed No   S3‑192683
    S3‑192717 Changes on handover from 5GS to EPS over N26 Huawei, Hisilicon CR Approval 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‑192999 Changes on handover from 5GS to EPS over N26 Huawei, Hisilicon CR Approval Yes
Yes
agreed No   S3‑192717
    S3‑192940 Issues of resetting NAS COUNT values in 5G to 4G mobility Qualcomm Incorporated discussion Endorsement 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‑192563 NAS Count values in the mapped EPS security context in 5GS to EPS change Qualcomm Incorporated CR Agreement Yes
Yes
agreed No   S3‑191917
    S3‑192996 Notes of the offline session on AMF relocation NTT-Docomo report Information Yes
Yes
noted No    
    S3‑193084 LS on security asepcts of AMF re-alocation procedure Qualcomm LS out Approval Yes
Yesthis was split into two different versions: 195 and 196.
revised No S3‑193195  
    S3‑193195 Draft LS on security asepcts of AMF re-alocation procedure Ericsson LS out Approval Yes
Yes
merged No S3‑193197 S3‑193084
    S3‑193194 Notes of the second offline session on AMF relocation NTT-Docomo report Information Yes
Yes
noted No    
    S3‑193196 Draft LS on security asepcts of AMF re-alocation procedure Huawei other discussion 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 Yes
Yes
approved No   S3‑193196
7.2 Security Assurance Specification for 5G (SCAS_5G) (Rel-16)                      
7.2.1 NR Node B (gNB) (TS 33.511) S3‑192635 Categorization of the test cases and other editorial corrections Nokia, Nokia Shanghai Bell CR Approval 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‑193003 Editorial corrections on the threat references of some test cases Nokia, Nokia Shanghai Bell CR Approval Yes
YesKeeping only editorials.
agreed No   S3‑192635
    S3‑192763 Update requirements and test cases for gNB SCAS Huawei, Hisilicon CR Approval 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‑193004 Update requirements and test cases for gNB SCAS Huawei, Hisilicon CR Approval Yes
Yes
agreed No   S3‑192763
    S3‑192823 Test cases referring to TS 33.117 Ericsson CR Agreement 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‑193001 Test cases referring to TS 33.117 Ericsson CR Agreement No
Yes
withdrawn Yes   S3‑192823
    S3‑192833 Correction to test case requirement reference L.M. Ericsson Limited CR Agreement Yes
Yes
agreed No    
7.2.2 Access and Mobility Management Function (TS 33.512) S3‑192824 Test cases referring to TS 33.117 Ericsson pCR Approval Yes
Yes
approved No    
    S3‑193002 Test cases referring to TS 33.117 Ericsson pCR Approval No
Yes
withdrawn Yes    
    S3‑192976 Comments on S3-192824 Huawei Technologies Co. Ltd. discussion Approval Yes
Yes
noted No    
    S3‑192714 Adding AMF critical assets and threats to TS 33.926 Huawei, Hisilicon CR Approval 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‑193005 Adding AMF critical assets and threats to TS 33.926 Huawei, Hisilicon CR Approval Yes
Yes
agreed No   S3‑192714
    S3‑193087 Draft TS 33.512 Huawei draft TS Approval Yes
Yes
approved No    
7.2.3 User Plane Function (UPF) (TS 33.513) S3‑192715 Adding UPF critical assets and threats to TS 33.926 Huawei, Hisilicon CR Approval Yes
Yes
revised No S3‑193006  
    S3‑193006 Adding UPF critical assets and threats to TS 33.926 Huawei, Hisilicon CR Approval 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‑192716 Editorial change on TS 33.513 Huawei, Hisilicon pCR Approval Yes
Yes
approved No    
    S3‑193009 Cover sheet TS 33.512 for approval Huawei TS or TR cover Approval Yes
Yes
approved No    
    S3‑193010 Cover sheet TS 33.513 for approval Samsung TS or TR cover Approval Yes
Yes
approved No    
    S3‑193024 Draft TS 33.513 Samsung draft TS Approval Yes
Yes
approved No    
7.2.4 Unified Data Management (UDM) (TS 33.514) S3‑192576 Editorial corrections for SCAS UDM TS 33.514 v0.5.0 NEC Corporation pCR Approval Yes
Yes
approved No    
    S3‑192697 Editorial change on TS 33.514 Huawei, Hisilicon pCR Approval Yes
Yes
approved No    
    S3‑192696 UDM critical assets and threats to TR 33.926 Huawei, Hisilicon CR Approval 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‑193008 UDM critical assets and threats to TR 33.926 Huawei, Hisilicon CR Approval Yes
Yes
agreed No   S3‑192696
    S3‑193007 Draft TS 33.514 NEC draft TS Approval Yes
Yes
approved No    
    S3‑193011 Cover sheet TS 33.514 for approval NEC TS or TR cover Approval Yes
Yes
approved No    
7.2.5 Session Management Function (SMF) (TS 33.515) S3‑192712 Adding SMF critical assets and threats to TS 33.926 Huawei, Hisilicon CR Approval Yes
Yes
revised No S3‑193012  
    S3‑193012 Adding SMF critical assets and threats to TS 33.926 Huawei, Hisilicon CR Approval Yes
YesIssue with the introduction of the annex as the previous documents.
agreed No   S3‑192712
    S3‑192713 Editorial change on TS 33.515 Huawei, Hisilicon pCR Approval Yes
Yes
revised No S3‑193013  
    S3‑193013 Editorial change on TS 33.515 Huawei, Hisilicon pCR Approval 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 Yes
Yes
approved No    
    S3‑193015 Cover sheet TS 33.515 for approval Huawei TS or TR cover Approval Yes
Yes
approved No    
7.2.6 Authentication Server Function (AUSF) (TS 33.516) S3‑192698 AUSF critical assets and threats to TR 33.926 Huawei, Hisilicon CR Approval Yes
Yes
revised No S3‑193016  
    S3‑193016 AUSF critical assets and threats to TR 33.926 Huawei, Hisilicon CR Approval Yes
Yes
agreed No   S3‑192698
    S3‑192699 Editorial change on TS 33.516 Huawei, Hisilicon pCR Approval Yes
Yes
approved No    
    S3‑193017 Draft TS 33.516 Ericsson draft TS Approval Yes
YesMCC warned that the document didn’t 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 Yes
Yes
approved No    
7.2.7 Security Edge Protection Proxy (SEPP) (TS 33.517) S3‑192602 Living Document: New Annex for the SEPP in TR 33.926 Nokia, Nokia Shanghai Bell draftCR Approval Yes
Yes
revised No S3‑193138  
    S3‑193138 Living Document: New Annex for the SEPP in TR 33.926 Nokia, Nokia Shanghai Bell draftCR Approval Yes
Yes
approved No   S3‑192602
    S3‑192700 Editorial changes on SEPP critical assets and threats to TR 33.926 Huawei, Hisilicon CR Approval 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‑193139 Adding SEPP critical assets and threats to TR 33.926 Huawei, Hisilicon CR Approval Yes
Yes
agreed No   S3‑192700
    S3‑192657 Threat analysis on misplacement of encrypted IE in JSON object by IPX Nokia, Nokia Shanghai Bell draftCR Approval 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‑193085 Threat analysis on misplacement of encrypted IE in JSON object by IPX Nokia, Nokia Shanghai Bell draftCR Approval Yes
Yes
approved No   S3‑192657
    S3‑192658 Test Case: No misplacement of encrypted IE in JSON object by IPX Nokia, Nokia Shanghai Bell pCR Approval Yes
Yes
revised No S3‑193086  
    S3‑193086 Test Case: No misplacement of encrypted IE in JSON object by IPX Nokia, Nokia Shanghai Bell pCR Approval Yes
Yes
approved No   S3‑192658
    S3‑192660 Add the missing expected format of evidence Nokia, Nokia Shanghai Bell pCR Approval Yes
Yes
approved No    
    S3‑192701 Editorial change on TS 33.517 Huawei, Hisilicon pCR Approval Yes
Yes
approved No    
    S3‑193019 Draft TS 33.517 Nokia draft TS Approval 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‑193198 Cover sheet TS 33.517 for approval Nokia TS or TR cover Approval Yes
Yes
approved No    
7.2.8 Network Resource Function (NRF) (TS 33.518) S3‑192603 Living Document: New Annex for the NRF in TR 33.926 Nokia, Nokia Shanghai Bell draftCR Decision Yes
Yes
approved No    
    S3‑192702 Adding NRF critical assets and threats to TR 33.926 Huawei, Hisilicon CR Approval Yes
YesThis is converting the living document into a CR.
revised No S3‑193020  
    S3‑193020 Adding NRF critical assets and threats to TR 33.926 Huawei, Hisilicon CR Approval Yes
YesIt removes the new changes and it maintains the original changes from the living document.
agreed No   S3‑192702
    S3‑192703 Editorial change on TS 33.518 Huawei, Hisilicon pCR Approval Yes
Yes
approved No    
    S3‑193022 Draft TS 33.518 Nokia draft TS Approval 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 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    
7.2.9 Network Exposure Function (NEF) (TS 33.519) S3‑192626 Adding abbreviation ZTE Corporation pCR Approval Yes
Yes
revised No S3‑193025  
    S3‑193025 Adding abbreviation ZTE Corporation pCR Approval Yes
Yes
approved No   S3‑192626
    S3‑192704 Adding NEF critical assets and threats to TR 33.926 Huawei, Hisilicon CR Approval Yes
Yes
revised No S3‑193027  
    S3‑193027 Adding NEF critical assets and threats to TR 33.926 Huawei, Hisilicon CR Approval 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‑193026 Draft TS 33.519 ZTE draft TS Approval Yes
Yes
approved No    
7.2.10 Other 5G SCAS aspects S3‑192601 Living Document: General SBA/SBI aspects in TS 33.117 Nokia, Nokia Shanghai Bell draftCR Decision Yes
Yes
approved No    
    S3‑192706 Update of living Document: General SBA/SBI aspects in TS 33.117 Huawei, Hisilicon CR Approval Yes
Yes
revised No S3‑193029  
    S3‑193029 Addition of general SBA/SBI aspects in TS 33.117 Huawei, Hisilicon,Nokia CR Approval Yes
YesComments on the clause numbering provided by MCC. The spec baseline had to be checked.
agreed No   S3‑192706
    S3‑192705 Adding critical assets and threats for general NFs to TR 33.926 Huawei, Hisilicon CR Approval 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‑193030 Adding critical assets and threats for general NFs to TR 33.926 Huawei, Hisilicon CR Approval Yes
Yes
agreed No   S3‑192705
    S3‑193028 Cover sheet TS 33.519 for approval ZTE TS or TR cover Approval Yes
Yes
approved No    
7.3 eMCSec R16 security (MCXSec) (Rel-16) S3‑192519 Clarifications for Protected MCData Airbus DS SLC CR Agreement Yes
YesMotorola: this is not needed. NCSC agreed. Samsung: too many stage 3 parameters. This is not needed.
revised No S3‑193021  
    S3‑193021 Clarifications for Protected MCData Airbus DS SLC CR Agreement Yes
Yes
not pursued No   S3‑192519
    S3‑192963 Algorithm Negotiation Samsung CR Agreement 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‑193043 Algorithm Negotiation Samsung CR Agreement No
Yes
withdrawn Yes    
7.4 Security aspects of single radio voice continuity from 5GS to UTRAN (5GS_UTRAN_SEC) (Rel-16) S3‑192918 Adding K5GSRVCC as a possible input key to derive IKSRVCC and CKSRVCC Qualcomm Incorporated CR Agreement Yes
Yes
revised No S3‑193047 S3‑192338
    S3‑193047 Adding K5GSRVCC as a possible input key to derive IKSRVCC and CKSRVCC Qualcomm Incorporated CR Agreement Yes
Yes
agreed No   S3‑192918
    S3‑192923 Correction to figure in draft CR for 5G to UTRAN CS SRVCC Qualcomm Incorporated, China Unicom other Approval Yes
Yes
revised No S3‑193044  
    S3‑193044 Correction to figure in draft CR for 5G to UTRAN CS SRVCC Qualcomm Incorporated, China Unicom other Approval Yes
Yes
approved No   S3‑192923
    S3‑192922 Draft CR for SRVCC 5G to UTRAN China Unicom, Qualcomm Incoporated draftCR Approval 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‑193045 Draft CR for SRVCC 5G to UTRAN China Unicom, Qualcomm Incoporated draftCR Approval Yes
Yes
approved No   S3‑192922
    S3‑193046 Security for SRVCC 5G to UTRAN CS Qualcomm,China Unicom CR Agreement Yes
YesQualcomm commented that China Unicom had agreed to help on this CR, but no confirmation from them had been received.
agreed No    
7.5 Enhancements for Security aspects of Common API Framework for 3GPP Northbound APIs (eCAPIF) (Rel-16) S3‑192955 Security procedures for CAPIF-7/7e reference points Samsung CR Agreement Yes
Yes
agreed No    
    S3‑192956 Security procedures for CAPIF-3e/4e/5e reference points Samsung CR Agreement Yes
YesNokia had doubts about referencing both 210 and 310. This was taken offline.
agreed No    
7.6 Security of URLLC for 5GS (5G_URLLC_SEC) (Rel-16) S3‑192766 draftCR for URLLC Huawei, Hisilicon draftCR Approval Yes
YesEricsson preferred to move content to an annex instead of deleting the text.
revised No S3‑193048  
    S3‑193048 draftCR for URLLC Huawei, Hisilicon, Qualcomm draftCR Approval Yes
Yes
approved No   S3‑192766
    S3‑192942 Skeleton of URLLC Qualcomm Incorporated draftCR Agreement Yes
Yes
merged No S3‑193048  
    S3‑192873 Introduction to URLLC services Ericsson draftCR Approval Yes
Yes
merged No S3‑193048  
    S3‑192874 Retaining AS security keys for redundant data transmission in user plane Ericsson draftCR Approval 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 Yes
Yes
merged No S3‑193048  
    S3‑192876 Redundant paths using Dual Connectivity for URLLC services – security keys derivation Ericsson draftCR Approval 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 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 Yes
Yes
merged No S3‑193048  
7.7 Security for 5GS Enhanced support of Vertical and LAN Services (Vertical_LAN_SEC) (Rel-16) S3‑192593 Endorsement of CR on Non-public network security Qualcomm, Nokia, Nokia Shanghai Bell discussion Agreement Yes
Yes
noted No    
    S3‑192592 Security for non-public networks - update to S3-192453 Qualcomm, Nokia, Nokia Shanghai Bell draftCR Agreement 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 doesn’t 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‑193049 Security for non-public networks - update to S3-192453 Qualcomm, Nokia, Nokia Shanghai Bell draftCR Agreement 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‑192577 Security for non-public networks Qualcomm Incorporated, Nokia, Nokia Shanghai Bell CR   Yes
Yes
revised No S3‑193051  
    S3‑193051 Security for non-public networks Qualcomm Incorporated, Nokia, Nokia Shanghai Bell CR - Yes
Yes
agreed No   S3‑192577
    S3‑192924 Some proposed editorial changes to NPN draft CR Qualcomm Incorporated, Nokia, Nokia Shanghai Bell other Approval Yes
Yes
approved No    
    S3‑192927 SUCI privacy for SNPN Qualcomm Incorporated, Nokia, Nokia Shanghai Bell other Approval 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‑193050 SUCI privacy for SNPN Qualcomm Incorporated, Nokia, Nokia Shanghai Bell other Approval Yes
Yes
approved No   S3‑192927
7.8 Security of Cellular IoT for 5GS (CIoT_sec_5G) (Rel-16) S3‑192508 Reply LS on RRC Connection Re-Establishment for CP for NB-IoT connected to 5GC S2-1908553 LS in   Yes
Yes
noted No    
    S3‑192511 Reply LS on authentication of group of IoT devices S2-1908632 LS in   Yes
Yes
noted No    
    S3‑192977 Reply LS on authentication of group of IoT devices S1-192816 LS in discussion Yes
Yes
noted No    
    S3‑192959 DraftCR - Proposed skeleton for supporting 5G CIoT Ericsson, Nokia draftCR   Yes
YesThe definition was controversial, as Huawei didn’t 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‑193052 DraftCR - Proposed skeleton for supporting 5G CIoT Ericsson, Nokia draftCR - Yes
Yes
approved No   S3‑192959
    S3‑192961 DraftCR-Control Plane Optimization for CIoT in 5G Ericsson draftCR   Yes
YesNokia: not part of the study and even in LTE we didn’t 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‑192775 Security handling in Control Plane User Data for Control Plane Optimization for 5GS CIoT Huawei, Hisilicon other Approval 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 Yes
Yes
approved No    
    S3‑192948 New Solution for botnet threats caused by improper CIOT device usage NIST, ATT, SPRINT, CABLE LABS, CISCO pCR Approval Yes
Yes
revised No S3‑192960  
7.9 Security of the Wireless and Wireline Convergence for the 5G system architecture (5WWC_SEC) (Rel-16) S3‑192760 skeleton of 5WWC Huawei, Hisilicon other Approval 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‑193053 skeleton of 5WWC Huawei, Hisilicon draftCR Approval Yes
YesThis will be the living document that captures the inputs of this agenda item.
approved No   S3‑192760
    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 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‑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 Yes
Yes
approved No   S3‑192581
7.10 Security aspects of Enhanced Network Slicing (eNS_SEC) (Rel-16) S3‑192726 Slice-specific authentication Huawei, HiSilicon draftCR Agreement 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    
7.11 Other work areas                      
7.11.1 SAE/LTE Security S3‑192861 Security of RRC UE capability transfer procedure in EPS Ericsson CR Agreement 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 doesn’t 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‑193074 Security of RRC UE capability transfer procedure in EPS Ericsson CR Agreement Yes
Yes
not pursued No   S3‑192861
7.11.2 IP Multimedia Subsystem (IMS) Security                      
7.11.3 Network Domain Security (NDS) S3‑192578 General NDS/IP SEG support for non-SBA interfaces Juniper Networks CR   Yes
Yes
revised No S3‑193000  
    S3‑193000 General NDS/IP SEG support for non-SBA interfaces Juniper Networks CR - Yes
YesRevised given that the document could not be opened by some (including MCC).
agreed No   S3‑192578
7.11.4 UTRAN Network Access Security                      
7.11.5 GERAN Network Access Security                      
7.11.6 Generic Authentication Architecture (GAA)                      
7.11.7 Security Aspects of Home(e)NodeB (H(e)NB)                      
7.11.8 Mission Critical (MCPTT, MCSec, eMCSec, MONASTERY_SEC) S3‑192516 Reply LS on ETSI Plugtest standards issues S6-191525 LS in   Yes
Yes
noted No    
7.11.9 Security Assurance Specifications (SCAS-SA3, SCAS_PGW, SCAS_eNB) S3‑192652 Additional Critical Assets and Threats to PGW Annex R16 Nokia, Nokia Shanghai Bell CR Approval Yes
Yes
revised No S3‑193033  
    S3‑193033 Additional Critical Assets and Threats to PGW Annex R16 Nokia, Nokia Shanghai Bell CR Approval Yes
Yes
agreed No   S3‑192652
    S3‑192653 Additional Critical Assets and Threats to PGW Annex R15 Nokia, Nokia Shanghai Bell CR Approval Yes
YesIt was clarified that the CR should be cat-F.
revised No S3‑193031  
    S3‑193031 Additional Critical Assets and Threats to PGW Annex R15 Nokia, Nokia Shanghai Bell CR Approval Yes
Yes
agreed No   S3‑192653
    S3‑192654 Adding Threat References to PGW Test Cases R15 Nokia, Nokia Shanghai Bell CR Approval Yes
YesChanged the category to A and creating a new CR to do the correction in release 14.
revised No S3‑193035  
    S3‑193035 Adding Threat References to PGW Test Cases R15 Nokia, Nokia Shanghai Bell CR Approval Yes
Yes
agreed No   S3‑192654
    S3‑192707 Clarification on test cases in TR 33.117 Huawei, Hisilicon CR Approval 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‑193036 Clarification on test cases in TR 33.117 Huawei, Hisilicon CR Approval Yes
Yes
agreed No   S3‑192707
    S3‑192761 Update testcase of 4.2.4.1.1.2 and 4.2.4.1.1.3 Huawei, Hisilicon CR Approval 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 Yes
YesDeutsche Telekom wasn't fine with this.
not pursued No    
    S3‑192764 Update requirements and test cases for eNB SCAS Huawei, Hisilicon CR Approval Yes
Yes
revised No S3‑193041  
    S3‑193041 Update requirements and test cases for eNB SCAS Huawei, Hisilicon CR Approval Yes
Yes
agreed No   S3‑192764
    S3‑193032 Additional Critical Assets and Threats to PGW Annex R14 Nokia CR Agreement Yes
Yes
agreed No    
    S3‑193034 Adding Threat References to PGW Test Cases R14 Nokia CR Agreement Yes
Yes
agreed No    
    S3‑193037 Clarification on test cases in TS 33.117 Huawei CR Agreement Yes
Yes
agreed No    
    S3‑193038 Clarification on test cases in TS 33.117 Huawei CR Agreement 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 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 Yes
Yes
agreed No    
    S3‑193042 Update requirements and test cases for eNB SCAS Huawei CR Agreement Yes
Yes
agreed No    
7.11.10 Security Aspects of Narrowband IOT (CIoT) S3‑192510 Reply LS on Mobile-terminated Early Data Transmission S2-1908629 LS in   Yes
YesSecurity issues: Huawei didn’t 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‑193059 Reply to: Reply LS on Mobile-terminated Early Data Transmission Nokia LS out approval Yes
YesConfirming SA2's assumption.
approved No    
    S3‑192582 Discussion paper on MT EDT LS from SA2 Nokia, Nokia Shangahi Bell discussion Endorsement Yes
Yes
noted No    
    S3‑192767 Discussion on security of MSG2 MT-EDT solution Huawei, Hisilicon discussion Decision Yes
Yes
noted No    
    S3‑192768 Reply LS on Security of MT-EDT Huawei, Hisilicon LS out Approval Yes
Yes
noted No    
    S3‑192857 [DRAFT] Reply LS on Mobile-terminated Early Data Transmission Ericsson LS out   Yes
Yes
noted No    
    S3‑192858 Disucssion on security of MT-EDT Ericsson discussion   Yes
YesQualcomm, Intel: no need for message 4 solution. Nokia: we should answer both message 2 and 4 solutions.
noted No    
    S3‑192934 Discusson on SA2 LS for MT EDT Qualcomm Incorporated discussion Endorsement 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 Yes
Yes
noted No    
7.11.11 EPC enhancements to support 5G New Radio via Dual Connectivity (EDCE5)                      
7.11.12 Northbound APIs Security for SCEF - SCS/AS Interworking (NAPS_Sec) (Rel-15)                      
7.11.13 Security Aspects of Common API Framework for 3GPP Northbound APIs (CAPIF_Sec) (Rel-15)                      
7.11.14 PLMN RAT selection (Steering of Roaming) (Rel-15) S3‑192632 Add missing message flow for Procedure for steering of UE Intel Deutschland GmbH CR Agreement Yes
YesVodafone: the bullet points now don’t reflect the change in the figure. Ericsson: is this a correction? Intel replied that this was aligned with SA2. On the other hand, this didn’t have to updated according to Release 16 changes since there was no significant impact.
revised No S3‑193060  
    S3‑193060 Add missing message flow for Procedure for steering of UE Intel Deutschland GmbH CR Agreement Yes
Yes
agreed No   S3‑192632
7.11.15 Battery Efficient Security for very low Throughput Machine Type Communication Devices (BEST_MTC_Sec) (Rel-15) S3‑192579 Minor corrections to 33163 Juniper Networks CR Approval Yes
Yes
revised No S3‑193061  
    S3‑193061 Minor corrections to 33163 Juniper Networks CR Approval Yes
Yes
agreed No   S3‑192579
    S3‑192580 Minor corrections to 33163 Juniper Networks CR Approval Yes
Yes
revised No S3‑193062  
    S3‑193062 Minor corrections to 33163 Juniper Networks CR Approval Yes
Yes
agreed No   S3‑192580
    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 Yes
Yes
noted No    
7.11.16 Other work items S3‑192668 Removing references of TS 103 383 in TS 35.231 Orange CR Approval Yes
Yes
revised No S3‑192982  
    S3‑192982 Removing references of TS 103 383 in TS 35.231 Orange CR Approval Yes
Yes
agreed No   S3‑192668
    S3‑192669 Removing references of TS 103 383 in TS 35.231 Orange CR Approval Yes
Yes
revised No S3‑192983  
    S3‑192983 Removing references of TS 103 383 in TS 35.231 Orange CR Approval Yes
Yes
agreed No   S3‑192669
    S3‑192671 Removing references of TS 103 383 in TS 35.231 Orange CR Approval Yes
Yes
revised No S3‑192984  
    S3‑192984 Removing references of TS 103 383 in TS 35.231 Orange CR Approval Yes
Yes
agreed No   S3‑192671
    S3‑192672 Removing references of TS 103 383 in TS 35.231 Orange CR Approval Yes
Yes
revised No S3‑192985  
    S3‑192985 Removing references of TS 103 383 in TS 35.231 Orange CR Approval Yes
Yes
agreed No   S3‑192672
7.12 New Work Item proposals S3‑192605 New WID on Security aspects of enhancements to the Service-Based 5G System Architecture Nokia, Nokia Shanghai Bell WID new Agreement 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‑193055 New WID on Security aspects of enhancements to the Service-Based 5G System Architecture Nokia, Nokia Shanghai Bell WID new Agreement Yes
Yes
agreed No   S3‑192605
    S3‑192636 WID of 5GFBS Apple WID new Approval 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‑192994 WID of 5GFBS Apple WID new Approval Yes
Yes
noted No   S3‑192636
    S3‑192661 WID for LTE normative work for UPIP Vodafone España SA WID new Agreement 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‑192828 New WID on security of the enhancement to the 5GC location services CATT WID new Agreement 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 didn’t mind these capabilities but not having any restrictions wouldn't be very clever. This was taken offline.
revised No S3‑193056  
    S3‑193056 New WID on security of the enhancement to the 5GC location services CATT WID new Agreement Yes
Yes
agreed No   S3‑192828
    S3‑192830 New WID on security aspect of network analytic services China Mobile M2M Company Ltd. WID new Approval 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‑192859 New WID on Authentication and Key Management for Applications based on 3GPP credential in 5G China Mobile WID new Approval Yes
YesOrange: why involving SA2? China Mobile: for architecture issues. This was taken offline.
revised No S3‑193178  
    S3‑193178 New WID on Authentication and Key Management for Applications based on 3GPP credential in 5G China Mobile WID new Approval Yes
Yes
agreed No   S3‑192859
    S3‑192883 Work item on integrating GBA to 5GC Ericsson, Vodafone WID new Approval Yes
YesQualcomm: this is a good idea and should be kept separate from the AKMA work item. We don’t 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‑193200 Work item on integrating GBA to 5GC Ericsson, Vodafone WID new Approval Yes
Yes
agreed No   S3‑192883
    S3‑192907 New WID on Security aspects of SEAL Samsung WID new Approval 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 don’t 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‑193071 New WID on Security aspects of SEAL Samsung WID new Agreement Yes
Yes
agreed No   S3‑192907
    S3‑192909 New WID on Security for NR Integrated Access and Backhaul Samsung WID new   Yes
Yes
revised No S3‑193073  
    S3‑193073 New WID on Security for NR Integrated Access and Backhaul Samsung WID new - Yes
Yes
agreed No   S3‑192909
    S3‑193072 Analysis of SEAL Samsung discussion discussion Yes
Yes
noted No    
8 Studies                      
8.1 Study on Security Aspects of the 5G Service Based Architecture (FS_SBA-Sec) (Rel-15) S3‑192609 eSBA: pCR to update Evaluation of Solution #16 Nokia, Nokia Shanghai Bell pCR Approval Yes
Yes
revised No S3‑193064  
    S3‑193064 eSBA: pCR to update Evaluation of Solution #16 Nokia, Nokia Shanghai Bell pCR Approval Yes
Yes
approved No   S3‑192609
    S3‑192606 eSBA: pCR to update Solution #21 Nokia, Nokia Shanghai Bell pCR Approval 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 Yes
Yes
approved No    
    S3‑192802 Update of Solution #23 (Token-based authorization for Scenario D using stateless SeCoP) Ericsson pCR Approval 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‑192804 Evaluation for Solution #23 (Token-based authorization for Scenario D using stateless SeCoP) Ericsson pCR Approval Yes
Yes
revised No S3‑193066  
    S3‑193066 Evaluation for Solution #23 (Token-based authorization for Scenario D using stateless SeCoP) Ericsson pCR Approval Yes
Yes
approved No   S3‑192804
    S3‑192803 Update of Solution #24 (Token-based authorization for Scenario C using stateless SeCoP) Ericsson pCR Approval Yes
Yes
revised No S3‑193067  
    S3‑193067 Update of Solution #24 (Token-based authorization for Scenario C using stateless SeCoP) Ericsson pCR Approval Yes
Yes
approved No   S3‑192803
    S3‑192805 Evaluation for Solution #24 (Token-based authorization for Scenario C using stateless SeCoP) Ericsson pCR Approval Yes
Yes
revised No S3‑193068  
    S3‑193068 Evaluation for Solution #24 (Token-based authorization for Scenario C using stateless SeCoP) Ericsson pCR Approval Yes
Yes
approved No   S3‑192805
    S3‑192694 eSBA: new solution for NF service consumer verification during service access authorization in indirect communication scenario Huawei, Hisilicon pCR Approval 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 didn’t work.
revised No S3‑193069  
    S3‑193069 eSBA: new solution for NF service consumer verification during service access authorization in indirect communication scenario Huawei, Hisilicon pCR Approval Yes
Yes
approved No   S3‑192694
    S3‑192612 eSBA: Add conclusion on KI #22 Nokia, Nokia Shanghai Bell pCR Approval Yes
YesEricsson and Nokia disagreed with the conclusions for scenario D. Conflict with the following contirbution.
merged No S3‑193070  
    S3‑192806 Conclusion of Key Issue #22 (Authorization of NF service access in indirect communication) Ericsson pCR Approval Yes
Yes
revised No S3‑193070  
    S3‑193070 Conclusion of Key Issue #22 (Authorization of NF service access in indirect communication) Ericsson,Nokia pCR Approval Yes
Yes
approved No   S3‑192806
    S3‑192815 New solution: Authorization between Network Functions in Scenario D Ericsson pCR Approval Yes
Yes
approved No    
    S3‑192614 eSBA: Add conclusion on KI #23 Nokia, Nokia Shanghai Bell pCR Approval Yes
Yes
revised No S3‑193174  
    S3‑193174 eSBA: Add conclusion on KI #23 Nokia, Nokia Shanghai Bel,Ericssonl pCR Approval Yes
Yes
approved No   S3‑192614
    S3‑192816 Conclusion of Key Issue #23: NF to NF authentication and authorization in Indirect communication Ericsson pCR Approval Yes
Yes
merged No S3‑193174  
    S3‑192807 New solution: Telescopic FQDN for the SeCoP Ericsson pCR Approval 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‑193075 New solution: Telescopic FQDN for the SeCoP Ericsson pCR Approval Yes
Yes
approved No   S3‑192807
    S3‑192610 eSBA: Add conclusion on KI #20 Nokia, Nokia Shanghai Bell pCR Approval Yes
Yes
revised No S3‑193077  
    S3‑193077 eSBA: Add conclusion on KI #20 Nokia, Nokia Shanghai Bell pCR Approval Yes
Yes
approved No   S3‑192610
    S3‑192813 Conclusion of Key Issue #20: Protection of SeCoP interfaces Ericsson pCR Approval Yes
Yes
noted No    
    S3‑192814 Conclusion of Key Issue #21: Secure message transport via the SeCoP Ericsson pCR Approval Yes
Yes
revised No S3‑193078  
    S3‑193078 Conclusion of Key Issue #21: Secure message transport via the SeCoP Ericsson pCR Approval No
Yes
approved No   S3‑192814
    S3‑192688 Dealing with the EN of solution #19 in TR33.855 Huawei, Hisilicon pCR Approval Yes
Yes
approved No    
    S3‑192689 New solution for authorization within a NF Set in the roaming scenario Huawei, Hisilicon pCR Approval Yes
Yes
approved No    
    S3‑192808 New solution: Token-based authorization for NF Sets / NF Service Sets by existing methods Ericsson pCR Approval Yes
Yes
revised No S3‑193079  
    S3‑193079 New solution: Token-based authorization for NF Sets / NF Service Sets by existing methods Ericsson pCR Approval Yes
Yes
approved No   S3‑192808
    S3‑192628 eSBA: Add conclusion on KI #24 Nokia, Nokia Shanghai Bell pCR Approval Yes
YesIt was concluded that info from SA2 was needed, hence no conclusion was to be obtained during the present meeting.
noted No    
    S3‑192809 Conclusion of Key Issue #24 (Service access authorization within a NF Set or a NF Service Set) Ericsson pCR Approval Yes
Yes
noted No    
    S3‑192811 Update of Key issue #26: Protection of N9 interface Ericsson pCR Approval Yes
YesJuniper,China Mobile supported this. There was no clear requirement.
approved No    
    S3‑192860 Resolving EN in 33855 6.18 N9 NDS/IP Juniper Networks pCR Agreement Yes
Yes
noted No    
    S3‑192611 eSBA: Add conclusion on KI #26 Nokia, Nokia Shanghai Bell pCR Approval 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: it’s 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‑193081 eSBA: Add conclusion on KI #26 Nokia, Nokia Shanghai Bell, Nokia pCR Approval Yes
Yes
approved No   S3‑192611
    S3‑192810 Conclusion of Key Issue #26: Protection of N9 interface Ericsson pCR Approval Yes
Yes
merged No S3‑193081  
    S3‑192818 UP Gateway deployments Ericsson pCR Approval 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‑193082 UP Gateway deployments Ericsson pCR Approval Yes
Yes
approved No   S3‑192818
    S3‑192629 eSBA: Add conclusion on KI #27 Nokia, Nokia Shanghai Bell pCR Approval 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 don’t 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‑193095 eSBA: Add conclusion on KI #27 Nokia, Nokia Shanghai Bell pCR Approval Yes
Yes
approved No   S3‑192629
    S3‑192687 Update of solution #15 in TR 33.855 Huawei, Hisilicon pCR Approval Yes
YesEricsson: the evaluation needs to show the disadvantages of the solution as well. This was taken offline.
revised No S3‑193097  
    S3‑193097 Update of solution #15 in TR 33.855 Huawei, Hisilicon pCR Approval Yes
Yes
approved No   S3‑192687
    S3‑192812 Conclusion of Key Issue #28: Service access authorization in the delegated "Subscribe-Notify" scenarios Ericsson pCR Approval Yes
YesHuawei and Nokia didn’t agree with the conclusion.
noted No    
    S3‑192608 eSBA: pCR to update Evaluation of Solution #26 Nokia, Nokia Shanghai Bell pCR Approval Yes
Yes
approved No    
    S3‑192817 New Solution: resource level authorization using access tokens Ericsson pCR Approval Yes
Yes
revised No S3‑193098  
    S3‑193098 New Solution: resource level authorization using access tokens Ericsson pCR Approval Yes
Yes
approved No   S3‑192817
    S3‑192613 eSBA: Add conclusion on KI #29 Nokia, Nokia Shanghai Bell pCR Approval Yes
Yes
revised No S3‑193099  
    S3‑193099 eSBA: Add conclusion on KI #29 Nokia, Nokia Shanghai Bell pCR Approval Yes
Yes
approved No   S3‑192613
    S3‑192693 Resolving the ENs in Solution #25 Huawei, Hisilicon pCR Approval Yes
YesEricsson: benefit to the existing solution should be clarified in the evaluation.
revised No S3‑193100  
    S3‑193100 Resolving the ENs in Solution #25 Huawei, Hisilicon pCR Approval Yes
Yes
approved No   S3‑192693
    S3‑192531 Resolving EN in 33855 6.18 N9 NDS/IP Juniper Networks pCR Agreement Yes
Yes
withdrawn Yes    
    S3‑193065 Draft TR 33.855 Ericsson draft TR Approval No
Yes
left for email approval No    
    S3‑193076 LS to CT4 on ESPA using indirect communication NTT-Docomo LS out Approval Yes
Yes
approved No    
    S3‑193080 LS to SA2 on ESPA NF sets NTT-Docomo LS out Approval Yes
Yes
approved No    
    S3‑193096 LS to SA2 on UP gateway function Deutsche Telekom LS out Approval Yes
Yes
approved No    
8.2 Security aspects of single radio voice continuity from 5G to UTRAN (FS_5G_UTRAN_SEC) (Rel-16)                      
8.3 Study on authentication and key management for applications based on 3GPP credential in 5G IoT (FS_AKMA)(Rel-16) S3‑192753 Implicite AKMA authenticaiton procedure Huawei, Hisilicon pCR Approval Yes
Yes
not treated No    
    S3‑192884 Evaluation of solution 13 Ericsson pCR Approval Yes
Yes
approved No    
    S3‑192885 Solution #15 updates including evaluation update Ericsson pCR Approval 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‑193169 Solution #15 updates including evaluation update Ericsson pCR Approval Yes
Yes
approved No   S3‑192885
    S3‑192675 Discussion on the conclusion of AKMA architecture and authentication procedures China Mobile, Nokia, Nokia Shanghai Bell discussion Endorsement Yes
Yes
noted No    
    S3‑192677 Conclusion on AKMA architecture and authentication procedure China Mobile, Nokia, Nokia Shanghai Bell pCR Approval 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‑193170 Conclusion on AKMA architecture and authentication procedure China Mobile, Nokia, Nokia Shanghai Bell pCR Approval Yes
Yes
approved No   S3‑192677
    S3‑192886 Conclusion for AKMA architecture and authentication Ericsson pCR Approval Yes
Yes
noted No    
    S3‑192564 Resolving Editor’s Notes and adding conclusion to solution #20 NEC Corporation pCR Approval Yes
Yes
approved No    
    S3‑192565 conclusion for KI #9 NEC Corporation pCR Approval Yes
Yes
noted No    
    S3‑192566 conclusion for KI #15 NEC Corporation pCR Approval Yes
YesQualcomm and Nokia didn’t agree with the text.
noted No    
    S3‑192788 Resovle Editor's notes in Solution for Key freshness in AKMA Huawei, Hisilicon pCR Approval Yes
YesEricsson: why using RAND? This was removed.
revised No S3‑193171  
    S3‑193171 Resovle Editor's notes in Solution for Key freshness in AKMA Huawei, Hisilicon pCR Approval Yes
Yes
approved No   S3‑192788
    S3‑192521 Corrections for TR 33.835 InterDigital Communications pCR Approval Yes
Yes
approved No    
    S3‑192532 New KI for TR 33.835 - roaming environment InterDigital Communications pCR Approval 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) didn’t find it necessary. There is still home control. Orange was happy with the requirements and they could go to general requirements clause so they didn’t depend on the solution. They were useful for the normative work. It was commented that the requirements still needed work.
noted No    
    S3‑193172 New KI for TR 33.835 - roaming environment InterDigital Communications pCR Approval No
Yes
withdrawn Yes    
    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 Yes
YesOrange, Vodafone objected to this contribution. Nokia supported it.
noted No    
    S3‑192539 New KI for TR 33.835 – browser environment InterDigital Communications pCR Approval Yes
YesQualcomm: AKMA is designed to use with any application, we don’t need to specify the browser in particular.
noted No    
    S3‑192691 Resolving the EN in AKMA push, and adding the evaluation Huawei, Hisilicon pCR Approval Yes
Yes
not treated No    
    S3‑192853 Conclusion on key issue #2 China Mobile pCR Approval Yes
Yes
not treated No    
    S3‑192854 Evaluation of solution #6 China Mobile M2M Company Ltd. pCR Approval Yes
Yes
not treated No    
    S3‑192855 Evaluation of solution#1 China Mobile M2M Company Ltd. pCR Approval Yes
Yes
not treated No    
    S3‑192856 Evaluations of solution #7- #12 China Mobile pCR Approval Yes
Yes
not treated No    
    S3‑192881 New solution: Integrating GBA to 5GC Ericsson, Vodafone pCR Approval Yes
Yes
not treated No    
    S3‑192882 New conclusions for GBA in 5GC Ericsson, Vodafone pCR Approval Yes
Yes
not treated No    
    S3‑192664 Discussion on the conclusion of AKMA architecture and authentication procedures China Mobile M2M Company Ltd. discussion Endorsement No
Yes
withdrawn Yes    
    S3‑192674 Conclusion on AKMA architecture and authentication procedure China Mobile M2M Company Ltd. pCR Approval No
Yes
withdrawn Yes    
    S3‑193168 Draft TR 33.835 China Mobile draft TR Approval No
Yes
left for email approval No    
    S3‑193177 Cover sheet for TR 33.835 information China Mobile TS or TR cover Approval Yes
Yes
approved No    
8.4 Study on evolution of Cellular IoT security for the 5G System (FS_CIoT_sec_5G) (Rel-16) S3‑192957 Manufacture Usage Description Discussion NIST, ATT, SPRINT, CABLE LABS, CISCO discussion Discussion Yes
Yes
noted No    
    S3‑192916 New KI: Botnet threats caused from improper CIOT device usage NIST, ATT, SPRINT, CABLE LABS, CISCO pCR Approval 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‑193101 New KI: Botnet threats caused from improper CIOT device usage NIST, ATT, SPRINT, CABLE LABS, CISCO pCR Approval Yes
Yes
approved No   S3‑192916
    S3‑192769 Address EN in key issue 13 and solution 20 Huawei, Hisilicon pCR Approval 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‑193102 Address EN in key issue 13 and solution 20 Huawei, Hisilicon pCR Approval Yes
YesRemoval of the last editor's note only.
approved No   S3‑192769
    S3‑192895 Evaluation to Sol#4 Ericsson, Intel pCR Approval Yes
YesQualcomm suggested some rewording in the last paragraph.
revised No S3‑193104  
    S3‑193104 Evaluation to Sol#4 Ericsson, Intel pCR Approval Yes
Yes
approved No   S3‑192895
    S3‑192967 Clarification in Solution 12 Huawei, Hisilicon pCR Approval Yes
Yes
approved No   S3‑192747
    S3‑192538 Proposal for editor's note in FS_CIoT_sec_5G solution #15 Philips International B.V. pCR Approval Yes
Yes
approved No    
    S3‑192773 Address EN in solution 19 Huawei, Hisilicon pCR Approval Yes
YesEricssson: add statement in the efficiency part about the solution based on this.
revised No S3‑193105  
    S3‑193105 Address EN in solution 19 Huawei, Hisilicon pCR Approval Yes
Yes
approved No   S3‑192773
    S3‑192939 Evaluation of Solution 20: RRC Reestablishment in RLF Qualcomm Incorporated pCR Approval Yes
Yes
approved No    
    S3‑192771 Address EN in solution 21 Huawei, Hisilicon pCR Approval Yes
Yes
approved No    
    S3‑192960 New Solution for botnet threats caused by improper CIOT device usage NIST, ATT, Sprint, Cable Labs, Cisco pCR Approval Yes
Yes
noted No   S3‑192948
    S3‑192789 Mitigate DDoS Attack on RAN based on RAN coordination Huawei, Hisilicon pCR Approval Yes
YesEricsson: editor's note on synchronising the list in RAN.
revised No S3‑193106  
    S3‑193106 Mitigate DDoS Attack on RAN based on RAN coordination Huawei, Hisilicon pCR Approval Yes
Yes
approved No   S3‑192789
    S3‑192897 CIOT: New solution for UP IP in PDCP to protect UL EDT data in Msg3 Ericsson, Qualcomm Incorporated,Intel pCR Approval Yes
Yes
approved No    
    S3‑192898 CIOT: New solution for protection of NAS Redirection message Ericsson pCR Approval Yes
YesHuawei: editor's note on signalling overhead.
revised No S3‑193107  
    S3‑193107 CIOT: New solution for protection of NAS Redirection message Ericsson pCR Approval Yes
Yes
approved No   S3‑192898
    S3‑192651 Proposal for Key Issue#1 Conclusion Philips International B.V. pCR Approval Yes
YesEricsson: Change in PDCP makes it complicated. We don’t support this.
noted No    
    S3‑192896 Conclusion on KI#2 Ericsson, Qualcomm Incorporated, Intel pCR Approval 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‑192774 Discussion on Mitigation of DDoS attack Huawei, Hisilicon discussion Endorsement Yes
Yes
noted No    
    S3‑192518 Conclusion for KI#4 KPN, Huawei, Hisilicon pCR Approval Yes
Yes
noted No    
    S3‑192894 Conclusion on KI#4 Ericsson, Qualcomm Incorporated pCR Approval Yes
Yes
noted No    
    S3‑192893 Conclusion on KI#5 Ericsson, Qualcomm Incorporated pCR Approval Yes
YesNokia supported this conclusion.
noted No    
    S3‑192790 conclusion on KI#5 Huawei, Hisilicon pCR Approval Yes
Yes
noted No    
    S3‑192772 Conclusion for Key Issue #11 Huawei, Hisilicon pCR Approval Yes
YesEricsson preferred to wait for the next meeting since they had a competing solution.
noted No    
    S3‑192770 Conclusion for Key Issue #13 Huawei, Hisilicon pCR Approval Yes
YesQualcomm: remove the second paragraph.
revised No S3‑193108  
    S3‑193108 Conclusion for Key Issue #13 Huawei, Hisilicon pCR Approval Yes
Yes
approved No   S3‑192770
    S3‑193103 Draft TR 33.861 Ericsson draft TR Approval No
Yes
left for email approval No    
8.5 Study on the security of the Wireless and Wireline Convergence for the 5G system architecture (FS_5WWC_SEC) (Rel-16) S3‑192604 Reply LS on Wireline Access Security Requirements CableLabs LS out Approval 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‑192981 Reply LS on Wireline Access Security Requirements CableLabs LS out Approval Yes
Yes
approved No   S3‑192604
    S3‑192754 Address two Editor’s Note of solution 4 Huawei, Hisilicon pCR Approval 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 don’t add new text since it is covered somewhere else.
revised No S3‑193109  
    S3‑193109 Address two Editor’s Note of solution 4 Huawei, Hisilicon pCR Approval Yes
Yes
approved No   S3‑192754
    S3‑192755 Address two Editor’s Note of solution 6 Huawei, Hisilicon pCR Approval Yes
Yes
approved No    
    S3‑192796 Removal of EN in Solution #7 Ericsson pCR Approval Yes
Yes
approved No    
    S3‑192799 Editorial changes to Solution #7 Ericsson pCR Approval Yes
Yes
approved No    
    S3‑192800 Evaluation of Solution #7 Ericsson pCR Approval Yes
Yes
approved No    
    S3‑193111 Evaluation of Solution #7 Ericsson pCR Approval No
Yes
withdrawn Yes    
    S3‑192756 Address an Editor’s Note and add evaluation for solution 7 Huawei, Hisilicon pCR Approval Yes
YesEricsson: you need keys and integrity protection.
noted No    
    S3‑192757 Add evaluation for solution 8 Huawei, Hisilicon pCR Approval 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‑192795 Conclusion for KI#7 and KI#8 Ericsson pCR Approval Yes
Yes
approved No    
    S3‑192758 Add conclusion for KI#2 Huawei, Hisilicon pCR Approval Yes
Yes
revised No S3‑193112  
    S3‑193112 Add conclusion for KI#2 Huawei, Hisilicon pCR Approval Yes
YesOnly first change is kept.
approved No   S3‑192758
    S3‑192798 Conclusion on KI#9 Ericsson pCR Approval Yes
Yes
approved No    
    S3‑192797 Conclusion on KI#15 Ericsson pCR Approval Yes
Yes
revised No S3‑193192  
    S3‑193192 Conclusion on KI#15 Ericsson pCR Approval Yes
Yes
approved No   S3‑192797
    S3‑192759 completing TR 33807 Huawei, Hisilicon pCR Approval Yes
Yes
approved No    
    S3‑193110 Draft TR 33.807 Huawei draft TR Approval No
Yes
left for email approval No    
    S3‑193179 Cover sheet TR 33.807 for approval Huawei TS or TR cover Approval Yes
Yes
approved No    
8.6 Study on Security Aspects of PARLOS (FS_PARLOS_Sec) (Rel-16) S3‑192583 Addressing EN in PARLOS Evaluation clause 7.2.3 Nokia, Nokia Shangahi Bell pCR Approval Yes
Yes
revised No S3‑193118  
    S3‑193118 Addressing EN in PARLOS Evaluation clause 7.2.3 Nokia, Nokia Shangahi Bell pCR Approval Yes
YesChanges in the evaluation clause were kept. The solution changes are merged in 114 as suggested by Qualcomm.
approved No   S3‑192583
    S3‑192747 Clarification in Solution 12 Huawei, Hisilicon pCR Approval Yes
Yes
revised No S3‑192967  
    S3‑192913 P-CR: Editorial cleanup of editor's notes Sprint Corporation pCR Agreement Yes
Yes
approved No    
    S3‑192943 A solution to providing some network authorisation in PARLOS Qualcomm Incorporated pCR Approval 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‑193114 A solution to providing some network authorisation in PARLOS Qualcomm Incorporated pCR Approval Yes
Yes
approved No   S3‑192943
    S3‑192944 Proposed conclusion on providing some network authorisation in PARLOS Qualcomm Incorporated pCR Approval Yes
Yes
revised No S3‑193116  
    S3‑193116 Proposed conclusion on providing some network authorisation in PARLOS Qualcomm Incorporated,Spring pCR Approval Yes
Yes
approved No   S3‑192944
    S3‑192945 Security aspects of RLOS Qualcomm Incorporated other Discussion Yes
Yes
noted No    
    S3‑192962 P-CR: Proposed conclusion for PARLOS Sprint Corporation pCR Agreement Yes
Yes
merged No S3‑193116  
    S3‑192964 P-CR: Proposed recommendations for PARLOS Sprint Corporation pCR Agreement Yes
Yes
merged No S3‑193116  
    S3‑193117 P-CR: Proposed recommendations for PARLOS Sprint Corporation pCR Agreement No
Yes
withdrawn Yes    
    S3‑192965 pCR to 33.815 clarifying requirements on Parlos DOCOMO Communications Lab. pCR Approval 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 don’t mention a particular country.
revised No S3‑193115  
    S3‑193115 pCR to 33.815 clarifying requirements on Parlos DOCOMO Communications Lab. pCR Approval Yes
Yes
approved No   S3‑192965
    S3‑192966 Proposed presentation cover sheet for PARLOS 33.815 Sprint Corporation TS or TR cover Agreement Yes
Yes
approved No    
    S3‑193113 Draft TR 33.815 Sprint draft TR Approval No
Yes
left for email approval No    
8.7 Study on 5G security enhancement against false base stations (FS_5GFBS) (Rel-16) S3‑192778 Wayforward for TR 33.809 Huawei, Hisilicon discussion Discussion Yes
Yes
noted No    
    S3‑192863 Way forward - KI#1 Proposal#1 UE caps Ericsson, Nokia, Vodafone, Deutsche Telekom AG, CableLabs, LG Electronics, Samsung, Apple pCR Approval 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‑193173 Way forward - KI#1 Proposal#1 UE caps Ericsson, Nokia, Vodafone, Deutsche Telekom AG, CableLabs, LG Electronics, Samsung, Apple pCR Approval Yes
Yes
approved No   S3‑192863
    S3‑192734 Address EN in solution #1 Huawei, HiSilicon pCR Approval Yes
Yes
not treated No    
    S3‑192642 Protection of UeapabilityInformation Apple pCR Approval Yes
Yes
not treated No    
    S3‑192780 Address EN in solution 16 Huawei, Hisilicon pCR Approval Yes
Yes
not treated No    
    S3‑192864 Way forward - KI#1 Proposal#2 RRC reject Ericsson, Nokia, Vodafone, Deutsche Telekom AG, CableLabs, LG Electronics, Apple pCR Approval 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 didn’t agree with this contribution.
noted No    
    S3‑192779 Discussion on Conclusion for Protection of RRC Reject message Huawei, Hisilicon discussion Decision Yes
Yes
noted No    
    S3‑192781 Conclusion for Key Issue #1 for RRC Reject Huawei, Hisilicon pCR Approval Yes
Yes
noted No    
    S3‑192782 LS to RAN2 on Protection of RRC Reject Message Huawei, Hisilicon LS out Approval Yes
Yes
not treated No    
    S3‑192949 Resolving EN on New and Last serving gNB interactions Samsung pCR Approval Yes
YesApple: we need more time to evaluate the solution.
noted No    
    S3‑192865 Way forward - KI#1 Proposal#3 RRC Resume Ericsson, Nokia, Vodafone, Deutsche Telekom AG, CableLabs, LG Electronics, Apple pCR Approval Yes
YesQualcomm: we don’t have a solution for this way forward. I agree with this conclusion, but the solution was removed. Orange agreed.
noted No    
    S3‑192783 Update on Protection of RRC Resume Request message Huawei, Hisilicon pCR Approval 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 Yes
Yes
noted No    
    S3‑192950 Solution for Resumecause protection Samsung pCR Approval Yes
Yes
not treated No    
    S3‑192785 Solution for Protection of NAS Reject Message Huawei, Hisilicon pCR Approval 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 Yes
Yes
noted No    
    S3‑192637 Conclusin of key issue#2 Apple pCR Approval 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‑192791 conclusion on KI#2 Huawei, Hisilicon pCR Approval Yes
Yes
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 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, it’s not like the AKMA situation.
noted No    
    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 No
Yes
withdrawn Yes    
    S3‑192951 Updates to Solution#7 on obtaining accurate clock information Samsung pCR Approval Yes
Yes
not treated No    
    S3‑192952 Deletion of EN on Location update reject in Solution#7 Samsung pCR Approval Yes
Yes
not treated No    
    S3‑192585 FBS add text to evaluation clause 6.7.3 Nokia, Nokia Shanghai Bell pCR Approval Yes
Yes
not treated No    
    S3‑192638 Update for Solution#7 Apple pCR Approval Yes
Yes
not treated No    
    S3‑192620 Assessment and evaluation of solution #9 ZTE Corporation pCR Approval Yes
Yes
not treated No    
    S3‑192643 Update of Solution#11 Apple pCR Approval Yes
Yes
not treated No    
    S3‑192639 Evaluation for solution#14 Apple pCR Approval Yes
Yes
not treated No    
    S3‑192938 Evaluation of the shared key based MIB/SIB protection Qualcomm Incorporated pCR Approval Yes
Yes
not treated No   S3‑191922
    S3‑192968 The solution to protect MIB/SIB information Huawei, Hisilicon pCR Approval Yes
Yes
not treated No   S3‑192748
    S3‑192936 Alternative shared key based MIB/SIB protection Qualcomm Incorporated pCR Approval Yes
Yes
not treated No    
    S3‑192867 Way forward - KI#3 Proposal#5 False RBS detection Ericsson, Nokia, Vodafone, Deutsche Telekom AG, CableLabs, LG Electronics pCR Approval 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‑192740 Conclustion for Key issue #3 Huawei, HiSilicon pCR Approval Yes
Yes
not treated No    
    S3‑192739 LS to RAN2 on FBS detection Huawei, HiSilicon LS out Approval 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‑193175 LS to RAN2 on FBS detection Huawei, HiSilicon LS out Approval Yes
Yes
approved No   S3‑192739
    S3‑192731 Solution#4: resolving EN network verification of the hashes of MIB/SIBs Huawei, HiSilicon pCR Approval Yes
Yes
not treated No    
    S3‑192732 Solution#4: Resolving EN Impact on UE power consumption Huawei, HiSilicon pCR Approval Yes
Yes
not treated No    
    S3‑192733 Solution #4: Details on the hash algorithm used for MIB/SIB hashes. Huawei, HiSilicon pCR Approval Yes
Yes
not treated No    
    S3‑192787 Solution for Avoiding UE connecting to False Base Station during Conditional Handover Huawei, Hisilicon pCR Approval Yes
Yes
not treated No    
    S3‑192868 Way forward - KI#3 Proposal#6 False RBS handover Ericsson, Nokia, Vodafone, Deutsche Telekom AG, CableLabs, LG Electronics, Samsung pCR Approval Yes
Yes
not treated No    
    S3‑192633 Security solution for UE to avoid connecting to the false base station during a handover procedure Intel Deutschland GmbH pCR Approval Yes
Yes
not treated No    
    S3‑192729 Resolve EN "signaling details of how the UE hands over to false base station Huawei, HiSilicon pCR Approval Yes
Yes
not treated No    
    S3‑192730 Resolve the second and third EN in Solution #6 Huawei, HiSilicon pCR Approval Yes
Yes
not treated No    
    S3‑192738 Evaluation of solution #6 Huawei, HiSilicon pCR Approval Yes
Yes
not treated No    
    S3‑192735 Enabling UE to detect FBS Huawei, HiSilicon pCR Approval Yes
Yes
not treated No    
    S3‑192736 preventing the UE from reselecting to the false base station Huawei, HiSilicon pCR Approval Yes
Yes
not treated No    
    S3‑192737 Avoiding UE from Suffering More MitM Attacks by Handover Huawei, HiSilicon pCR Approval 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 Yes
Yes
not treated No    
    S3‑192686 Conclusion on KI#5 of TR 33.809 Huawei, Hisilicon pCR Approval 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 Yes
Yes
not treated No    
    S3‑192685 Resolving the ENs in solution #5 Huawei, Hisilicon, Lenovo, Motorola Mobility pCR Approval Yes
Yes
not treated No    
    S3‑192743 Update of Solution #15 Lenovo, Motorola Mobility pCR Approval 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 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 Yes
Yes
not treated No    
    S3‑192937 Evaluation against MitM false base station attacks Qualcomm Incorporated discussion Endorsement Yes
Yes
not treated No    
    S3‑192640 5G paging security issue caused by false base station Apple pCR Approval 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 Yes
Yes
not treated No    
    S3‑192644 Meeting minutes of 5GFBS July conference call on July 18th Apple discussion Information Yes
Yes
not treated No    
    S3‑192645 Meeting minutes of 5GFBS August conference call on August 8th Apple discussion Information Yes
Yes
not treated No    
    S3‑193176 Draft TR 33.809 Apple draft TR Approval No
Yes
left for email approval No    
8.8 Study on Security aspects of Enhancement of Network Slicing (FS_eNS_SEC) (Rel-16) S3‑192852 Reference syntax updates Ericsson pCR Approval Yes
Yes
approved No    
    S3‑192829 Modification of solution#1 China Mobile pCR Approval 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‑192718 Adding evalution to solution 3 Huawei, HiSilicon pCR Approval Yes
YesNokia: slice specific authentication doesn’t depend on NSaaS.
noted No    
    S3‑192746 User ID privacy Lenovo, Motorola Mobility, Huawei discussion Approval Yes
Yes
noted No    
    S3‑192742 Removal of Editor’s Notes of solution #5 Lenovo, Motorola Mobility pCR Approval 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‑192720 Addressing EN in solution 6 Huawei, HiSilicon pCR Approval Yes
YesNokia didn’t 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‑193120 Addressing EN in solution 6 Huawei, HiSilicon pCR Approval No
Yes
noted No   S3‑192720
    S3‑192721 Adding evalution to solution 6 Huawei, HiSilicon pCR Approval Yes
Yes
noted No    
    S3‑192848 Adding evaluation to Solution 7 Ericsson pCR Approval Yes
Yes
revised No S3‑193121  
    S3‑193121 Adding evaluation to Solution 7 Ericsson pCR Approval Yes
Yes
approved No   S3‑192848
    S3‑192722 Addressing ENs in solution 8 Huawei, HiSilicon pCR Approval Yes
Yes
noted No    
    S3‑192584 Update to Solution 8 protecting NSSAI in AS layer Nokia, Nokia Shanghai Bell, Ericsson pCR Approval Yes
YesHuawei only agreed with the first paragraph. This was kept in the revision.
revised No S3‑193122  
    S3‑193122 Update to Solution 8 protecting NSSAI in AS layer Nokia, Nokia Shanghai Bell, Ericsson pCR Approval Yes
Yes
approved No   S3‑192584
    S3‑192931 Resolving editor’s notes on solution #10 in TR 33.813 Qualcomm Incorporated pCR Approval Yes
YesOn the yellow text; Ericsson commented that management will be very complex.
revised No S3‑193123  
    S3‑193123 Resolving editor’s notes on solution #10 in TR 33.813 Qualcomm Incorporated pCR Approval Yes
Yes
approved No   S3‑192931
    S3‑192528 TR 33.813 - update for solution #11 InterDigital Communications pCR Approval 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‑193124 TR 33.813 - update for solution #11 InterDigital Communications pCR Approval Yes
Yes
approved No   S3‑192528
    S3‑192627 Solution on privacy protection of NSSAI ZTE Corporation pCR Approval 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‑193125 Solution on privacy protection of NSSAI ZTE Corporation pCR Approval Yes
Yes
approved No   S3‑192627
    S3‑192719 Conclusions to KI #3 Huawei, HiSilicon pCR Approval Yes
Yes
noted No    
    S3‑192725 Conclusions to KI #4 Huawei, HiSilicon pCR Approval Yes
Yes
noted No    
    S3‑192723 Conclusions to KI #6 Huawei, HiSilicon pCR Approval Yes
Yes
noted No    
    S3‑192851 Conclusion on KI#6 Ericsson, Nokia pCR Approval Yes
Yes
noted No    
    S3‑192849 Discussion on AUSF role Ericsson discussion Endorsement 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 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 don’t 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‑193126 LS on AUSF role Ericsson LS out Approval Yes
Yes
approved No   S3‑192850
    S3‑192744 New Key Issue on Rejected S-NSSAI Revokation Lenovo, Motorola Mobility pCR Approval 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‑193201 New Key Issue on Rejected S-NSSAI Revokation Lenovo, Motorola Mobility pCR Approval Yes
Yes
approved No   S3‑192744
    S3‑192745 Solution on Slice Authentication Revokation Lenovo, Motorola Mobility pCR Approval Yes
Yes
noted No    
    S3‑192724 Amendment to eNS WID Huawei, HiSilicon pCR Approval 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‑193119 Draft TR 33.813 Nokia draft TR Approval No
Yes
left for email approval No    
8.9 Study on Security of the enhancement to the 5GC location services (FS_eLCS_Sec) (Rel-16) S3‑192676 Complete the Evaluation for Solution #4 Nokia, Nokia Shanghai Bell pCR Approval Yes
YesVodafone: not clear if you are recommending it or rejecting it.
revised No S3‑193127  
    S3‑193127 Complete the Evaluation for Solution #4 Nokia, Nokia Shanghai Bell pCR Approval Yes
Yes
approved No   S3‑192676
    S3‑192971 conclusion on KI#4 Huawei, Hisilicon pCR Approval Yes
Yes
noted No   S3‑192751
    S3‑192678 Conclusion on Key Issue #4 Nokia, Nokia Shanghai Bell pCR Approval Yes
Yes
approved No    
    S3‑192822 Draft CR as a living baseline for 5GS LCS normative work Ericsson draftCR Approval 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‑192748 The solution to protect MIB/SIB information Huawei, Hisilicon pCR Approval Yes
Yes
revised No S3‑192968  
    S3‑193128 Draft TR 33.814 CATT draft TR Approval No
Yes
left for email approval No    
    S3‑193129 Cover sheet TR 33.814 for approval CATT TS or TR cover Approval Yes
Yes
approved No    
8.10 Study on security for 5G URLLC (FS_5G URLLC_SEC) (Rel-16) S3‑192765 Completing 33825 Huawei, Hisilicon pCR Approval 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 hasn’t been done in this document.
approved No    
    S3‑193130 Draft TR 33.825 Huawei draft TR Approval No
Yes
left for email approval No    
    S3‑193131 Cover sheet 33.825 for approval Huawei TS or TR cover Approval Yes
Yes
approved No    
8.11 Study on SECAM and SCAS for 3GPP virtualized network products (FS_VNP_SECAM_SCAS) (Rel-16) S3‑192832 Adding gap analysis into clause 4.3.1 China Mobile pCR Approval Yes
Yes
approved No    
    S3‑192834 Adding contents into clause 4.4 China Mobile pCR Approval Yes
Yes
approved No    
    S3‑192835 Adding contents into clause 4.5 China Mobile pCR Approval Yes
Yes
approved No    
    S3‑192836 Resolving editor’s note and adding example of role instantiation into clause 4.6 China Mobile pCR Approval Yes
Yes
approved No    
    S3‑192837 Adding contents into clause 4.7 China Mobile pCR Approval Yes
Yes
approved No    
    S3‑192838 Adding contents into clause 4.8 China Mobile pCR Approval Yes
Yes
revised No S3‑193181  
    S3‑193181 Adding contents into clause 4.8 China Mobile pCR Approval Yes
Yes
approved No   S3‑192838
    S3‑192839 Adding contents into clause 4.8 China Mobile M2M Company Ltd. pCR Approval Yes
Yes
approved No    
    S3‑192840 Adding writing process overview into clause 5.1 China Mobile M2M Company Ltd. pCR Approval 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   Yes
Yes
revised No S3‑193182  
    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 - Yes
Yes
approved No   S3‑192841
    S3‑192842 Adding the description of Generic Vitualized Network Product model of type 1 China Mobile pCR Approval 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‑193183 Adding the description of Generic Vitualized Network Product model of type 1 China Mobile pCR Approval Yes
Yes
approved No   S3‑192842
    S3‑192843 Adding the description for generic virtualized network product model of type 2 China Mobile M2M Company Ltd. pCR Approval Yes
Yes
revised No S3‑193184  
    S3‑193184 Adding the description for generic virtualized network product model of type 2 China Mobile M2M Company Ltd. pCR Approval Yes
Yes
approved No   S3‑192843
    S3‑192844 Adding the description for generic virtualized network product model of type 3 China Mobile pCR Approval 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 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 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 Yes
Yes
not treated No    
    S3‑193180 Draft TR 33.818 China Mobile draft TR Approval No
Yes
left for email approval No    
8.12 Study on Security for 5GS Enhanced support of Vertical and LAN Services (FS_Vertical_LAN_SEC) (Rel-16) S3‑192594 TR33.819 update as baseline - editorial Nokia, Nokia Shanghai Bell pCR Approval Yes
Yes
approved No    
    S3‑192595 Adding intro to 33.819 Nokia, Nokia Shanghai Bell pCR Approval Yes
YesThe introducion needed rewording.
noted No    
    S3‑192598 Secure device identity creation for UEs in SNPNs Nokia, Nokia Shanghai Bell, Perspecta Labs, Interdigital pCR Approval 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 Yes
YesOrange: secure somethng we don’t 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‑193193 Key issue on Secure network credentials creation for constrained devices Nokia, Nokia Shanghai Bell, Perspecta Labs, Interdigital pCR Approval Yes
Yes
noted No   S3‑192599
    S3‑192596 TSC update Nokia, Nokia Shanghai Bell pCR Approval Yes
Yes
approved No    
    S3‑192597 TSC key issue on time synchronization Nokia, Nokia Shanghai Bell pCR Approval Yes
YesBT: what is confidentiality protection doing here if it is not plain text? It's not doing much.
revised No S3‑193133  
    S3‑193133 TSC key issue on time synchronization Nokia, Nokia Shanghai Bell pCR Approval Yes
Yes
approved No   S3‑192597
    S3‑192953 Conclusion to Key Issue #6.1 Samsung pCR Approval Yes
YesInterdigital: too early for this conclusion. Ericsson agreed about the conclusion.
revised No S3‑193134  
    S3‑193134 Conclusion to Key Issue #6.1 Samsung pCR Approval Yes
YesEvaluation change stayed.
approved No   S3‑192953
    S3‑192526 TR 33.819 - DH based solution for CAG ID privacy InterDigital Communications pCR Approval 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‑193135 TR 33.819 - DH based solution for CAG ID privacy InterDigital Communications pCR Approval Yes
Yes
approved No   S3‑192526
    S3‑192527 TR 33.819 - hash based solution for CAG ID privacy InterDigital Communications pCR Approval Yes
Yes
revised No S3‑193136  
    S3‑193136 TR 33.819 - hash based solution for CAG ID privacy InterDigital Communications pCR Approval Yes
YesAdding several editor's notes addressing Huawei's comments.
approved No   S3‑192527
    S3‑192529 TR 33.819 - Update for solution 9 InterDigital Communications pCR Approval Yes
Yes
approved No    
    S3‑192954 New solution for CAG ID privacy Samsung,Intel pCR Approval Yes
YesIntel supported this contribution.
approved No    
    S3‑192619 Security solution for CAG ZTE Corporation pCR Approval Yes
Yes
approved No    
    S3‑192690 Solution for CAG ID protection Huawei, Hisilicon pCR Approval 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‑193141 Solution for CAG ID protection Huawei, Hisilicon pCR Approval Yes
Yes
approved No   S3‑192690
    S3‑192928 Solution for the privacy protection of CAG ID using NAS signalling Qualcomm Incorporated pCR Approval 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‑193142 LS on sending CAG-ID in NAS signalling Qualcomm Incorporated LS out Approval Yes
Yes
approved No    
    S3‑192925 Proposed conclusion to key issue 6.3 on modifying the CAG list Qualcomm Incorporated pCR Approval Yes
Yes
approved No    
    S3‑192926 Adding modification of CAG list security to the draft CR Qualcomm Incorporated other Approval Yes
Yes
approved No    
    S3‑192751 conclusion on KI#4 Huawei, Hisilicon pCR Approval Yes
Yes
revised No S3‑192971  
    S3‑193132 Draft TR 33.819 Nokia draft TR Approval No
Yes
left for email approval No    
8.13 Study on LTKUP Detailed solutions (FS_LTKUP_Detail) (Rel-16) S3‑192656 pCR to TR33.935 - Addition of Diffie - Helman Key agreements section Vodafone España SA pCR Agreement Yes
Yes
withdrawn Yes    
8.14 Study on User Plane Integrity Protection (FS_UP_IP_Sec) (Rel-16) 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 Yes
YesQualcomm disagreed with the document and opted for having it noted. Samsung had similar issues with this document.
noted No    
    S3‑192647 Update to Key issue#5 in UP IP Apple pCR Approval 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‑193143 Update to Key issue#5 in UP IP Apple pCR Approval Yes
YesImproving the English.
approved No   S3‑192647
    S3‑192648 Solution to key issue#5 in UP IP Apple pCR Approval Yes
YesQualcomm: the attacker could still attack the data part of the packet. I don’t think this solution works. Deutsche Telekom: this doesn't solve the problem. Vodafone didn't find this solution workable either.
noted No    
    S3‑192659 pCR to 33.853 - addition of solution for LTE Vodafone España SA pCR Agreement Yes
YesNEC: this introduces more complexity. They didn’t 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‑193144 pCR to 33.853 - addition of solution for LTE Vodafone España SA pCR Approval Yes
Yes
approved No   S3‑192659
    S3‑192662 CR to 33.401 - Addition of User Plane Integrity Protection Vodafone España SA draftCR Agreement No
Yes
withdrawn Yes    
    S3‑192728 Resolving the Editor's note for Solution 5 in TR 33.853 China Mobile pCR Approval 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‑193145 Resolving the Editor's note for Solution 5 in TR 33.853 China Mobile pCR Approval Yes
Yes
approved No   S3‑192728
    S3‑192801 New Solution for a UE connected to 5GC indicating its support of UP IP over eUTRA Ericsson pCR Approval Yes
Yes
revised No S3‑193146  
    S3‑193146 New Solution for a UE connected to 5GC indicating its support of UP IP over eUTRA Ericsson pCR Approval Yes
YesAdding an editor's note adressing Nokia's concerns. Changes in notation as proposed by Qualcomm.
approved No   S3‑192801
    S3‑192902 Resolving Editor’s Note in Solution #1 Samsung pCR Approval Yes
YesQualcomm didn’t agree with this analysis. Nokia didn’t agree with the new sentence. There was no support for this paper.
noted No    
    S3‑192905 Conclusion to Key Issue #5 Samsung pCR   Yes
Yes
noted No    
    S3‑193147 Draft TR 33.853 Vodafone draft TR Approval No
Yes
left for email approval No    
8.15 Study on Security Impacts of Virtualisation (FS_SIV) (Rel-16) S3‑192973 Virtualisation Study Key Issue 22 was S3-191857 BT plc pCR Approval Yes
Yes
not treated No    
    S3‑192974 Virtualisation Study Key Issue 23 was S3-191858 BT plc pCR Approval Yes
Yes
not treated No    
    S3‑192975 Virtualisation Study Key Issue 24 was S3-191859 BT plc pCR Approval Yes
Yes
not treated No    
    S3‑192541 TR 33.848 Annex - Administration of Virtualisation NCSC pCR Approval Yes
Yes
revised No S3‑193088  
    S3‑193088 TR 33.848 Annex - Administration of Virtualisation NCSC pCR Approval Yes
Yes
noted No   S3‑192541
    S3‑192542 TR 33.848 Annex - Virtualisation Security Questions NCSC pCR Approval Yes
Yes
revised No S3‑193089  
    S3‑193089 TR 33.848 Annex - Virtualisation Security Questions NCSC pCR Approval Yes
Yes
noted No   S3‑192542
    S3‑192543 TR 33.848 Clarifications for Section 4 NCSC pCR Approval Yes
Yes
noted No    
    S3‑192544 TR 33.848 Security Threats and Requirements for Key Issue 1 NCSC pCR Approval Yes
Yes
revised No S3‑193090  
    S3‑193090 TR 33.848 Security Threats and Requirements for Key Issue 1 NCSC pCR Approval Yes
Yes
noted No   S3‑192544
    S3‑192890 Threats and Requirements for Key Issue #2 Nokia, Nokia Shanghai Bell pCR Approval Yes
Yes
revised No S3‑193091  
    S3‑193091 Threats and Requirements for Key Issue #2 Nokia, Nokia Shanghai Bell pCR Approval No
Yes
approved No   S3‑192890
    S3‑192545 TR 33.848 Security Requirements for Key Issue 3 NCSC,Nokia pCR Approval Yes
Yes
merged No S3‑193092  
    S3‑192891 Threats and Requirements for Key Issue #3 Nokia, Nokia Shanghai Bell pCR Approval Yes
Yes
revised No S3‑193092  
    S3‑193092 Threats and Requirements for Key Issue #3 Nokia, Nokia Shanghai Bell pCR Approval No
Yes
noted No   S3‑192891
    S3‑192546 TR 33.848 Security Threats and Requirements for Key Issue 4 NCSC pCR Approval Yes
Yes
revised No S3‑193093  
    S3‑192892 Threats and Requirements for Key Issue #4 Nokia, Nokia Shanghai Bell pCR Approval Yes
Yes
merged No S3‑193093  
    S3‑192547 TR 33.848 Security Threats and Requirements for Key Issue 5 NCSC pCR Approval Yes
Yes
merged No S3‑193094  
    S3‑193093 TR 33.848 Security Threats and Requirements for Key Issue 5 NCSC,Nokia pCR Approval Yes
Yes
noted No   S3‑192546
    S3‑192899 Threats and Requirements for Key Issue #5 Nokia, Nokia Shanghai Bell pCR Approval Yes
Yes
revised No S3‑193094  
    S3‑193094 Threats and Requirements for Key Issue #5 Nokia, Nokia Shanghai Bell,NCSC pCR Approval No
Yes
noted No   S3‑192899
    S3‑192548 TR 33.848 Security Threats and Requirements for Key Issue 6 NCSC pCR Approval Yes
Yes
noted No    
    S3‑192549 TR 33.848 Security Threats and Requirements for Key Issue 7 NCSC pCR Approval Yes
Yes
noted No    
    S3‑192550 TR 33.848 Security Threats and Requirements for Key Issue 8 NCSC pCR Approval Yes
Yes
noted No    
    S3‑192900 Threats and Requirements for Key Issue #8 Nokia, Nokia Shanghai Bell pCR Approval Yes
Yes
not treated No    
    S3‑192551 TR 33.848 Security Threats and Requirements for Key Issue 9 NCSC pCR Approval Yes
Yes
not treated No    
    S3‑192552 TR 33.848 Security Threats and Requirements for Key Issue 10 NCSC pCR Approval Yes
Yes
not treated No    
    S3‑192553 TR 33.848 Security Threats and Requirements for Key Issue 11 NCSC pCR Approval Yes
Yes
not treated No    
    S3‑192554 TR 33.848 Security Threats and Requirements for Key Issue 12 NCSC pCR Approval Yes
Yes
not treated No    
    S3‑192555 TR 33.848 Security Threats and Requirements for Key Issue 13 NCSC pCR Approval Yes
Yes
not treated No    
    S3‑192901 Threats and Requirements for Key Issue #13 Nokia, Nokia Shanghai Bell pCR Approval Yes
Yes
not treated No    
    S3‑192556 TR 33.848 Security Threats and Requirements for Key Issue 14 NCSC pCR Approval Yes
Yes
not treated No    
    S3‑192557 TR 33.848 Security Threats and Requirements for Key Issue 15 NCSC pCR Approval Yes
Yes
not treated No    
    S3‑192558 TR 33.848 Security Threats and Requirements for Key Issue 16 NCSC pCR Approval Yes
Yes
not treated No    
    S3‑192559 TR 33.848 Security Requirements for Key Issue 17 NCSC pCR Approval Yes
Yes
not treated No    
    S3‑192904 Threats and Requirements for Key Issue #17 Nokia, Nokia Shanghai Bell pCR Approval Yes
Yes
not treated No    
    S3‑192560 TR 33.848 Security Requirements for Key Issue 18 NCSC pCR Approval Yes
Yes
not treated No    
    S3‑192906 Threats and Requirements for Key Issue #18 Nokia, Nokia Shanghai Bell pCR Approval Yes
Yes
not treated No    
    S3‑192561 TR 33.848 Security Requirements for Key Issue 19 NCSC pCR Approval Yes
Yes
not treated No    
    S3‑192908 Threats and Requirements for Key Issue #20 Nokia, Nokia Shanghai Bell pCR Approval Yes
Yes
not treated No    
    S3‑192562 TR 33.848 Security Threats and Requirements for Key Issue 21 NCSC pCR Approval Yes
Yes
not treated No    
    S3‑192910 Threats and Requirements for Key Issue #21 Nokia, Nokia Shanghai Bell pCR Approval Yes
Yes
not treated No    
    S3‑192958 Categorization of the Key Issues Nokia, Nokia Shanghai Bell discussion Endorsement Yes
Yes
not treated No    
    S3‑193063 Notes on the evening session on SIV BT report Information Yes
Yes
noted No    
    S3‑193185 Draft TR 33.848 BT draft TR Approval Yes
Yes
left for email approval No    
8.16 Study on authentication enhancements in 5GS (FS_AUTH_ENH) (Rel-16) S3‑192919 Update of Authentication Enhancements SID Qualcomm Incorporated SID revised Agreement Yes
Yes
revised No S3‑193186  
    S3‑193186 Update of Authentication Enhancements SID Qualcomm Incorporated SID revised Agreement Yes
YesIncluding the new dates.
agreed No   S3‑192919
    S3‑192879 New KI: Security of session anchor keys in case the long-term key is leaked Ericsson pCR Approval 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‑192680 Key issue to mitigate the SUPI guessing attacks China Mobile pCR Approval Yes
YesOrange: more details on the attack are needed. Bring a discussion paper for this for the next meeting. Ericsson: I don’t see the relation of this with the objectives of the study.
noted No    
    S3‑192692 Key issue on the authenticaiton result storage in the UDM Huawei, Hisilicon pCR Approval 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‑193187 Key issue on the authenticaiton result storage in the UDM Huawei, Hisilicon pCR Approval Yes
Yes
approved No   S3‑192692
    S3‑192920 Proposed re-wording of the requirement in key issue #4.1 in TR 33.846 Qualcomm Incorporated pCR Approval Yes
Yes
approved No    
    S3‑192880 New Solution:EAP-AKA´ PFS Ericsson pCR Approval Yes
Yes
noted No    
    S3‑192622 Handling of Sync failure ZTE Corporation pCR Approval 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‑193189 Handling of Sync failure ZTE Corporation pCR Approval Yes
Yes
approved No   S3‑192622
    S3‑192681 A Solution for Key Isssue#2.1 and key issue #4.1 in TR 33.846 China Mobile pCR Approval Yes
Yes
revised No S3‑193190  
    S3‑193190 A Solution for Key Isssue#2.1 and key issue #4.1 in TR 33.846 China Mobile pCR Approval Yes
Yes
approved No   S3‑192681
    S3‑192972 mitigate the linkability attack Huawei, Hisilicon pCR Approval Yes
YesQualcomm: remove changes from scope. Ericsson wanted some more details in the description of the solution.
revised No S3‑193191 S3‑192752
    S3‑193191 mitigate the linkability attack Huawei, Hisilicon pCR Approval Yes
Yes
approved No   S3‑192972
    S3‑192621 Structure RAND for authentication ZTE Corporation pCR Approval Yes
Yes
not treated No    
    S3‑192663 33.846: mitigation against linkability attack THALES pCR Approval Yes
Yes
not treated No    
    S3‑192684 New solution for linkability attack Huawei, Hisilicon pCR Approval Yes
Yes
not treated No    
    S3‑192921 Using MACS to provide freshness for the protection of SQN during a re-synchronisation procedure in AKA Qualcomm Incorporated pCR Approval Yes
Yes
not treated No   S3‑191908
    S3‑192970 Proposed solution on protecting the SQN during a re-synchronisation procedure in AKA Huawei, Hisilicon pCR Approval Yes
Yes
not treated No   S3‑192750
    S3‑192623 Conclusion on linkability issues ZTE Corporation pCR Approval Yes
Yes
not treated No    
    S3‑192679 Key issue to mitigate the SUPI guessing attacks China Mobile pCR Approval No
Yes
withdrawn Yes    
    S3‑193188 Draft TR 33.846 Ericsson draft TR Approval No
Yes
left for email approval No    
8.17 Study on Security for NR Integrated Access and Backhaul (FS_NR_IAB_Sec) S3‑192665 IAB-node: terminology change THALES, ORANGE pCR Approval 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‑193148 IAB-node: terminology change THALES, ORANGE pCR Approval Yes
YesAdding an editor's note on the terminology.
approved No   S3‑192665
    S3‑192825 IAB: Assumptions related to key hierarchy in IAB architecture in 5G Ericsson pCR Approval Yes
Yes
revised No S3‑193150  
    S3‑193150 IAB: Assumptions related to key hierarchy in IAB architecture in 5G Ericsson pCR Approval Yes
YesAddressing the comments on the use of MT.
approved No   S3‑192825
    S3‑192969 Key issue on removal of USIM card in IAB node Huawei, Hisilicon pCR Approval Yes
YesOrange: I don't understand the key issue. Nokia: this is a deployment issue. Qualcomm didn’t agree either. There was no support for this key issue.
noted No   S3‑192749
    S3‑192911 Requirement on authorization of IAB Node Samsung pCR Approval Yes
YesQualcomm: what does "evaluated" mean in the requirement? This was reworded.
revised No S3‑193151  
    S3‑193151 Requirement on authorization of IAB Node Samsung pCR Approval Yes
Yes
approved No   S3‑192911
    S3‑192912 Solution for authorization of IAB Node Samsung pCR Approval Yes
YesQualcomm: the description is incomplete.
revised No S3‑193152  
    S3‑193152 Solution for authorization of IAB Node Samsung pCR Approval Yes
YesChange in clause 6.3.1.1 removed.
approved No   S3‑192912
    S3‑192914 Evaluation of solution #2.1 Samsung pCR Approval Yes
YesOrange: the solution is not clear. I cannot evaluate this.
noted No    
    S3‑192915 Evaluation of solution #3.1 Samsung pCR Approval Yes
YesQualcomm opposed to having this. This was noted.
noted No    
    S3‑192917 Conclusion to Key Issue#2.1 on authentication and authorization of the IAB Node Samsung pCR Approval Yes
Yes
noted No    
    S3‑192826 KI #2.3: security threats and potential requirements Ericsson pCR Approval 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‑193153 KI #2.3: security threats and potential requirements Ericsson pCR Approval Yes
Yes
approved No   S3‑192826
    S3‑192827 New solution: secure recovery from backhaul-RLF Ericsson pCR Approval Yes
YesQualcomm had numerous comments and preferred to have it noted. Huawei had the same opinion.
noted No    
    S3‑193149 Draft TR 33.824 Samsung draft TR Approval No
Yes
left for email approval No    
8.18 Study on Security Aspects of 3GPP support for Advanced V2X Services (FS_eV2X_Sec) S3‑192534 LS on the call for proposals for an internationally agreed Vehicular Multimedia Architecture ITU-T FG-VM LS in   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   Yes
Yes
noted No    
    S3‑192522 33.836 - solution #1 update InterDigital Communications pCR Approval 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‑193154 33.836 - solution #1 update InterDigital Communications pCR Approval Yes
Yes
approved No   S3‑192522
    S3‑192523 TR 33.836 - update for solution #2 InterDigital Communications pCR Approval 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‑193155 TR 33.836 - update for solution #2 InterDigital Communications pCR Approval Yes
Yes
approved No   S3‑192523
    S3‑192524 TR 33.836 - solution #3 update InterDigital Communications pCR Approval 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‑193157 TR 33.836 - solution #3 update InterDigital Communications pCR Approval Yes
Yes
approved No   S3‑192524
    S3‑192525 TR 33.836 solution #4 update InterDigital Communications pCR Approval Yes
Yes
revised No S3‑193158  
    S3‑193158 TR 33.836 solution #4 update InterDigital Communications pCR Approval Yes
YesSame editor's notes about 5G Prose were added.
approved No   S3‑192525
    S3‑192571 new solution on privacy protection for unicast NEC Corporation pCR Approval Yes
YesLG was not happy about NOTE 2 and proposed to remove it. Interdigital added that the solution didn’t 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‑193159 new solution on privacy protection for unicast NEC Corporation pCR Approval Yes
Yes
approved No   S3‑192571
    S3‑192634 eV2X: New solution for Security for eV2X unicast messages over PC5 Intel Deutschland GmbH pCR Approval Yes
Yes
revised No S3‑193160  
    S3‑193160 eV2X: New solution for Security for eV2X unicast messages over PC5 Intel Deutschland GmbH pCR Approval 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‑192932 Proposed solution for deriving PC5 layer keys based on higher layer keys Qualcomm Incorporated pCR Approval Yes
Yes
revised No S3‑193161  
    S3‑193161 Proposed solution for deriving PC5 layer keys based on higher layer keys Qualcomm Incorporated pCR Approval Yes
Yes
approved No   S3‑192932
    S3‑192649 Update to Key issue#5 in eV2X Apple pCR Approval Yes
YesInterdigital: this requirement is not enough.
noted No    
    S3‑192569 new KI on privacy protection for broadcast NEC Corporation pCR Approval Yes
Yes
revised No S3‑193162  
    S3‑193162 new KI on privacy protection for broadcast NEC Corporation pCR Approval Yes
YesAdding an editor's note as proposed by Ericsson.
approved No   S3‑192569
    S3‑192570 new solution on privacy protection for broadcast and groupcast NEC Corporation pCR Approval Yes
YesLG: No requirement to justify 6.Y.2.1 in 3GPP for Unicast. Remove the whole clause. Qualcomm didn’t understand why introducing PC5 signalling; besides, according to SA2's agreements on broadcast and groupcast this solution is not needed.
noted No    
    S3‑192741 V2X Group Key Provisioning Lenovo, Motorola Mobility pCR Approval 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‑193163 V2X Group Key Provisioning Lenovo, Motorola Mobility pCR Approval Yes
Yes
approved No   S3‑192741
    S3‑192572 new KI on increasing robustness and reliability in L2 ID update procedure NEC Corporation pCR Approval Yes
Yes
noted No    
    S3‑192573 new solution on increasing robustness and reliability in L2 ID update procedure NEC Corporation pCR Approval 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 Yes
Yes
revised No S3‑193164  
    S3‑193164 new KI on minimizing the impact of privacy protection mechanism in the application layer communication NEC Corporation pCR Approval Yes
Yes
approved No   S3‑192574
    S3‑192575 new solution on minimizing the impact of privacy protection mechanism in the application layer communication NEC Corporation pCR Approval Yes
YesLG: revise the figure to address the unicast case. The evaluation was also removed.
revised No S3‑193165  
    S3‑193165 new solution on minimizing the impact of privacy protection mechanism in the application layer communication NEC Corporation pCR Approval Yes
Yes
approved No   S3‑192575
    S3‑192695 New KI: Key issue on UP security policy handling for PC5 and Uu interface Huawei, Hisilicon pCR Approval Yes
Yes
revised No S3‑193166  
    S3‑193166 New KI: Key issue on UP security policy handling for PC5 and Uu interface Huawei, Hisilicon pCR Approval Yes
YesJust to remove "SA5" next to the reference.
approved No   S3‑192695
    S3‑192727 Solution on Cross-RAT PC5 control authorization indication Huawei, HiSilicon pCR Approval Yes
Yes
approved No    
    S3‑192568 terminology alignment on groupcast NEC Corporation pCR Approval Yes
Yes
revised No S3‑193167  
    S3‑193167 terminology alignment on groupcast NEC Corporation pCR Approval Yes
YesLG asked to remove the added requirements.
approved No   S3‑192568
    S3‑192567 Editorial corrections for eV2X SI TR 33.836 v0.3.0 NEC Corporation pCR Approval 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‑193137 LS on link layer ID update NEC LS out Approval No
Yes
withdrawn Yes    
    S3‑193156 Draft TR 33.836 LG draft TR Approval No
Yes
left for email approval No    
8.19 Other study areas S3‑192819 ARPF Deployment models Ericsson discussion Discussion Yes
Yes
not treated No    
    S3‑192820 Security Parameter Storage Ericsson discussion Discussion Yes
Yes
not treated No    
    S3‑192821 Privacy Aspects of ARPF deployment Ericsson discussion Discussion Yes
Yes
not treated No    
    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 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 No
Yes
withdrawn Yes    
    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   No
Yes
withdrawn Yes    
    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 No
Yes
withdrawn Yes    
    S3‑192646 Discussion on 5G UE privacy when connecting to EPC Apple discussion Agreement Yes
Yes
not treated No    
    S3‑192750 Proposed solution on protecting the SQN during a re-synchronisation procedure in AKA Huawei, Hisilicon pCR Approval Yes
Yes
revised No S3‑192970  
    S3‑192752 mitigate the linkability attack Huawei, Hisilicon pCR Approval Yes
Yes
revised No S3‑192972  
8.20 New study item proposals S3‑192517 Issues with encryption of satellite backhaul TNO, Avanti, iDirect, University of Surrey, SES discussion Discussion 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‑192515 draftTR33.xxx Storage of sensitive credentials in 5G systems v0.0.1 Vodafone España SA discussion   Yes
Yes
noted No    
    S3‑192650 EAP-AKA privacy enhancement in non-3GPP access to EPS Apple SID new Approval 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 didn’t 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‑192995 EAP-AKA privacy enhancement in non-3GPP access to EPS Apple SID new Agreement Yes
Yes
noted No   S3‑192650
    S3‑192749 Key issue on removal of USIM card in IAB node Huawei, Hisilicon pCR Approval Yes
Yes
revised No S3‑192969  
    S3‑192831 Discussion on study on user plane security termination point in 5GC CATT discussion Endorsement Yes
Yes
withdrawn Yes    
    S3‑192903 SID on Rel16 onwards Storage of Secure Parameters in a 5G system Vodafone España SA SID new Agreement 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 didn’t request us.
revised No S3‑193057  
    S3‑193057 SID on Storage of Secure Parameters in a 5G system Vodafone España SA SID new Agreement Yes
Yes
agreed No   S3‑192903
9 Work Plan and Rapporteur Input                      
9.1 Review of work plan S3‑192502 SA3 Work Plan MCC Work Plan   Yes
Yes
noted No    
9.2 Rapporteur input on status of WID or SID S3‑192504 Work Plan input from Rapporteurs MCC other   Yes
Yes
revised No S3‑193202  
    S3‑193202 Work Plan input from Rapporteurs MCC other - No
Yes
noted No   S3‑192504
10 Future Meeting Dates and Venues S3‑192503 SA3 meeting calendar MCC other   Yes
Yes
revised No S3‑193199  
    S3‑193199 SA3 meeting calendar MCC other - Yes
Yes
revised No S3‑193203 S3‑192503
    S3‑193203 SA3 meeting calendar MCC other - Yes
Yes
noted No   S3‑193199
11 Any Other Business