Tdoc List

2019-11-22 15:41

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‑193900 Agenda WG Chairman agenda   Yes
Yes
revised No S3‑194442  
    S3‑194442 Agenda WG Chairman agenda - No
Yes
approved No   S3‑193900
3 IPR Anti-Trust Law and other Reminders                      
4 Meeting Report                      
4.1 Approval of the report from previous SA3 meeting(s) S3‑193901 Report from SA3#96 MCC report   Yes
YesApproved with an editorial change in tdoc 2862 as commented by Qualcomm. (AS instead of AES). This will be corrected in the final version uploaded to the 3GPP server.
approved No    
    S3‑193902 Report from SA3#96Ad-Hoc MCC report   Yes
YesMCC thanked the SA3 leadership for taking care of MCC tasks during the adhoc.
approved No    
4.2 Report from SA plenary S3‑193904 Report from last SA meeting WG Chairman report   Yes
YesHuawei asked when SA3 was going to start working on Release 17. The Chair answered that the release 17 work was based on the prioritization done in SA2, so SA3's work would depend on their progress. Vodafone asked about items such as SBA. Can SBA be classed as release 16? The Chair answered that it was release 16.
noted No    
4.3 Report from SA3-LI                      
5 Items for early consideration                      
5.1 Output of SA3#96-Ad hoc S3‑194352 Security requirements for UP Gateway Function Nokia, Nokia Shanghai Bell, Juniper CR Agreement Yes
YesThis CR will go together with the UP Gateway Function new WID that goes to the next SA plenary. That’s why it has the DUMMY WID code. The baseline was agreed and new changes would be merged into the revision.
revised No S3‑194443  
    S3‑194443 Security requirements for UP Gateway Function Nokia, Nokia Shanghai Bell, Juniper CR Agreement Yes
Yes
agreed No   S3‑194352
    S3‑194355 Protection of N9 interface Nokia, Nokia Shanghai Bell, Juniper Networks CR Agreement Yes
YesThis CR will go together with the UP Gateway Function new WID that goes to the next SA plenary. That’s why it has the DUMMY WID code. The baseline was agreed and new changes would be merged into the revision.
revised No S3‑194444  
    S3‑194444 Protection of N9 interface Nokia, Nokia Shanghai Bell, Juniper Networks CR Agreement Yes
Yes
agreed No   S3‑194355
    S3‑194356 New WID for User Plane Gateway Function for the Inter-PLMN Security Juniper Networks WID new Agreement Yes
YesVodafone asked if the date was realistic, but Juniper was not confident and the date was proposed to bechanged to March 2020. It was kept open for discussion whether to move it to this date.
revised No S3‑194445  
    S3‑194445 New WID for User Plane Gateway Function for the Inter-PLMN Security Juniper Networks WID new Agreement Yes
Yes
agreed No   S3‑194356
    S3‑194359 Security requirements for SeCoP Nokia, Nokia Shanghai Bell CR Approval Yes
Yes
revised No S3‑194446  
    S3‑194446 Security requirements for SeCoP Nokia, Nokia Shanghai Bell CR Approval Yes
YesAgreed baseline but Ericsson proposed new changes for a revision.
agreed No   S3‑194359
    S3‑194361 Authentication and authorization between SeCoP and network functions Nokia, Nokia Shanghai Bell CR Agreement Yes
Yes
agreed No    
    S3‑194363 Authentication and authorization between SeCoPs Nokia, Nokia Shanghai Bell CR Agreement Yes
Yes
agreed No    
    S3‑194378 Update to 5G_eSBA WID Nokia, Nokia Shanghai Bell WID revised Approval Yes
YesKept open in order to discuss the dates.
revised No S3‑194600  
    S3‑194600 Update to 5G_eSBA WID Nokia, Nokia Shanghai Bell WID revised Approval Yes
YesChanged to March 2020.
agreed No   S3‑194378
    S3‑194401 NPN clarifications Nokia, Nokia Shanghai Bell,Qualcomm CR Agreement Yes
YesVodafone: the change in I.2.1 makes it too broad. Other groups have misinterpreted our specification for this reason. The Chair commented that this was heavily discussed in the previous meeting. Nokia added that this referred to clauses I.2.2 and I.2.3. Qualcomm added that this was not normative but an introduction to other clauses. Vodafone withdrew their comment.
agreed No    
    S3‑194402 Removal of ed.note on conformance tests Nokia, Nokia Shanghai Bell,Qualcomm CR Agreement Yes
Yes
agreed No    
    S3‑194405 Annex 5GLAN Nokia, Nokia Shanghai Bell CR Agreement Yes
Yes
revised No S3‑194428  
    S3‑194427 Security for TSC service Nokia, Nokia Shanghai Bell discussion Information Yes
Yes
noted No    
    S3‑194406 Annex TSC security intro Nokia, Nokia Shanghai Bell CR Agreement Yes
Yes
agreed No    
    S3‑194428 Annex 5GLAN Nokia, Nokia Shanghai Bell CR Agreement Yes
Yes
agreed No   S3‑194405
5.2 Other items                      
6 Reports and Liaisons from other Groups                      
6.1 3GPP Working Groups S3‑193934 LS on AS key derivation for conditional handover R2-1911565 LS in   Yes
YesRelated contributions: 4055, 4025.
replied to No    
    S3‑193969 33501-CR on CHO key derivation Apple CR Approval Yes
YesNokia: add reference to RAN2 spec. Huawei supported this. Christine (Ericsson): wait for the reply, we don’t need to make the changes now. Qualcomm didn’t agree with having the second change as RAN2 was still working on this topic. Wait for their reply.
revised No S3‑194448  
    S3‑194448 33501-CR on CHO key derivation Apple CR Approval Yes
YesPostponed in order to add more details: Key derivation in CHO needs to be addressed in the specification.
not pursued No   S3‑193969
    S3‑193935 LS on impact on UTRAN of 5G SRVCC R2-1911753 LS in   Yes
Yes
noted No    
    S3‑193937 LS on misalignment in Counter Check Procedure R2-1911837 LS in   Yes
Yes
noted No    
    S3‑194357 Updates to Counter Check Procedure (Rel-15) Samsung CR Approval Yes
YesEricsson didn’t agree with this change. Huawei: change from shall not to "should not". Samsung insisted on an existing misalignment with RAN2. There is no benefit with having the removed the sentence according to Samsung. Qualcomm supported Samsung. Alf (NTT-Docomo): just add a note with a clarification. MCC asked if this should be cat-F and Samsung replied that it could be and that a mirror was submitted to this meeting as well. Ericsson commented that this should not be changed in Release 16, so this was taken offline.
revised No S3‑194449  
    S3‑194449 Updates to Counter Check Procedure (Rel-15) Samsung CR Approval Yes
YesMirror in 358.
agreed No   S3‑194357
    S3‑193942 LS on security for multi-CU-UP connectivity R3-194784 LS in   Yes
Yes
replied to No    
    S3‑194138 Discussion on Security of Multi-CU-UP connectivity CATT discussion Decision Yes
Yes
noted No    
    S3‑194056 Discussion on LS R3-194784 on Disaggregated CU-UPs in different security domains Nokia, Nokia Shanghai Bell discussion Endorsement Yes
Yes
noted No    
    S3‑194139 LS reply to RAN WG3 LS on security for multi-CU-UP connectivity CATT LS out Approval Yes
YesCATT: it's too late for Release 16 from our point of view. NTT-Docomo didn’t find the text in LS very clear. Qualcomm: the UE is not aware of where the user plane ends, it's handled by the RAN. SA3 needs to study this anyway, as the current architecture is not sufficient; and that's what we need to reply to them. Nokia: study item for this? It's a simple change. Qualcomm replied that this could have a significant impact on the RAN. NTT-Docomo: network side security domain could be affected as well, so this is not so simple. They proposed to take this offline to study the consequences. CATT added that RAN3 was planning to do a WID in Release 17 about this topic.
revised No S3‑194450  
    S3‑194450 LS reply to RAN WG3 LS on security for multi-CU-UP connectivity CATT LS out Approval Yes
Yes
approved No   S3‑194139
    S3‑193944 Reply LS on LS on the IAB-indication to core network S2-1910281 LS in   Yes
Yes
noted No    
    S3‑193951 LS on Enhancing Location Information Reporting with Dual Connectivity S3i190671 LS in   Yes
Yes
noted No    
    S3‑193957 N9HR Regulatory Obligations S3i190548 LS in   Yes
YesORANGE: gNode B encrypts the traffic in the visited network, why encrypting this in the UPF? BT: we have to turn off the encryption in the UPF for LI reasons. It would be nice to turn that back on. Amelia (Article 19): countries cooperating with each other, law enforcement, better than a technical solution like this. BT: make the security hole smaller would be preferable for us. ORANGE: I prefer to have a paper expalining the issues better. It was decided to note the document since the next step would be a Study Item.
noted No    
    S3‑193958 LS on security consideration of performance measurement function protocol C1-196940 LS in   Yes
YesThere were companies supporting either replying (something is needed)
postponed No    
    S3‑194451 Reply to: LS on security consideration of performance measurement function protocol ZTE LS out approval Yes
YesNo consensus. Apple asked to have in the minutes: "Apple strongly insists that the current security existing mechanism is NOT sufficient to address the security issue that 3rd part application could modify the PMF packet."
noted No    
    S3‑193949 Reply LS on UP gateway function on the N9 interface S2-1910808 LS in   Yes
Yes
replied to No    
    S3‑193989 Reply LS on UP gateway function on the N9 interface Juniper Networks LS out   Yes
YesNokia: not mandatory for us to follow SA2 guidelines. They didn't agree with removing their descripton. Nokia supported a reply LS, but this needed some reshaping. Ericsson had a similar position; better not to go against SA2.
revised No S3‑194452  
    S3‑194452 Reply LS on UP gateway function on the N9 interface Juniper Networks LS out - Yes
Yes
approved No   S3‑193989
    S3‑193966 draft Reply LS_on_CHO key derivation Apple LS out Approval Yes
YesEricsson, Qualcomm: remove the last sentence from the LS. This was taken offline.
revised No S3‑194447  
    S3‑194447 Reply LS_on_CHO key derivation Apple LS out Approval Yes
Yes
approved No   S3‑193966
    S3‑193967 Discussion on Consecutive CHO key derivation Apple discussion Endorsement No
Yes
withdrawn Yes    
    S3‑193970 Discussion on PMF Protocol Security Apple discussion Endorsement Yes
Yes
noted No    
    S3‑193971 draft reply LS on security consideration of PMF Apple LS out Approval Yes
Yes
noted No    
    S3‑194025 Discussion on CHO key derivation Apple discussion Endorsement Yes
Yes
noted No    
    S3‑194055 Discussion paper on LS (R2-1911565) on AS key derivation for Conditional Handovertional Nokia, Nokia Shanghai Bell discussion Endorsement Yes
YesNokia: it's aligned with SA3 work, no changes need to be made.The discussion was taken in the CR proposed by Apple.
noted No    
    S3‑194057 Discussion paper on PMF protocol security S3-193680 Nokia, Nokia Shanghai Bell discussion Endorsement Yes
Yes
noted No    
    S3‑194064 LS on security consideration of performance measurement function protocol ZTE Corporation LS out Approval Yes
Yes
noted No    
    S3‑194336 Reply LS on PMF Qualcomm Incorporated LS out Approval Yes
Yes
noted No    
    S3‑193987 Introduction of the Inter PLMN UP security function in the architecture Deutsche Telekom AG discussion Decision Yes
Yes
noted No    
    S3‑194431 Nokia comments on S3-193970 PMF protocol security Nokia, Nokia Shanghai Bell discussion Discussion Yes
YesApple: Nokia agrees on the attack and sees no standardization needed? We disagree. Lenovo supported the Apple contribution. Futurewei: application impacting on the UE is out of standardization scope as we concluded in the IoT work item. Qualcomm: no UP integrity protection in LTE. We don’t see the need for new security mechanisms, existing ones are sufficient. ZTE supported this. There was no consensus on the need for sending a reply LS.
noted No    
    S3‑194434 LS on Application Architecture for enabling Edge Applications S6-192399 LS in discussion Yes
Yes
noted No    
    S3‑194435 LS on native 5G NAS security context activation C1-199003 LS in discussion Yes
YesQualcomm: leave it to the AMF to decide.Stick to the top highlighted text. Huawei: Our assumption is to use the native security context as much as possible. It was commented that CT1 was meeting after SA3's next meeting, so it was decided to postpone an answer.
postponed No    
    S3‑194436 LS on GUTI allocation for MT-EDT in 5G CIoT C1-199005 LS in discussion Yes
YesHuawei: we need to discuss this offline, as it implies that MT-EDT might not be needed at all. Qualcomm: how to allocate the GUTI is not in our scope. The utility of this feature is up to other working groups, not to us. Ericsson: we have studied this and we think that the re-allocation is not needed. This had to be taken offline.
noted No    
    S3‑194666 Reply to: LS on GUTI allocation for MT-EDT in 5G CIoT Ericsson LS out approval No
Yes
noted No    
    S3‑194437 LS on Use of 3gpp-Sbi-Target-apiRoot header in HTTP requests from NFs to SEPP C4-195375 LS in discussion Yes
YesThis needed some offline discussion.
replied to No    
    S3‑194453 Reply to: LS on Use of 3gpp-Sbi-Target-apiRoot header in HTTP requests from NFs to SEPP Nokia LS out approval Yes
Yes
approved No    
    S3‑194438 Reply LS on GTP Recovery Counter & GSN node behaviour C4-195518 LS in discussion Yes
YesNo action for SA3.
noted No    
    S3‑194439 LS on ARPF in UDICOM C4-195553 LS in discussion Yes
Yes
postponed No    
    S3‑194440 LS on usage of IMSI during 3GPP based authentication C4-195574 LS in discussion Yes
YesLenovo: we think that nothing needs to be done for this scenario. Qualcomm: Blackberry brought a CR for our previous meeting related to this. SUPI privacy can be compromised, but it's up to the implementers to decide if this can happen, and it should not be specified in our standards. Nokia: this is a mix of 4G and 5G. We should reply because CT4 has a CR pending.
replied to No    
    S3‑194454 Reply to: LS on usage of IMSI during 3GPP based authentication Nokia LS out approval Yes
Yes
approved No    
    S3‑194441 LS on user identity when 5G-AKA or EAP AKA’ is used for SNPN C6-190468 LS in discussion Yes
Yes
replied to No    
    S3‑194455 Reply to: LS on user identity when 5G-AKA or EAP AKA’ is used for SNPN Samsung LS out approval Yes
YesDisagreement on the statement that if NSI is being present in the USIM, the IMSI stored in the USIM can be used by the ME to derive the NSI.Samsung, IDEMIA in favour, Orange and Qualcomm against. Qualcomm: The disagreement lies in two SUPIs in the same USIM. SA2 has no use case for this.
approved No    
6.2 IETF                      
6.3 ETSI SAGE S3‑193950 256 bit radio interface algorithm performance ETSI SAGE LS in   Yes
YesCATT: the question depends on the implementation, so it's hard to have a reply. Dedicated hardware needs to be used to achieve the required performance. We should focus on the security algorithm itself and not in its performance. Apple supported CATT: don’t focus on performance issues. Vodafone replied that there are criteria that needed to be taken into account by SAGE. SA3 could very well reply that it is up to them to decide on these parameters. Alex (BT) reminded that HTTP digest and IPSec had a similar issue in the past, and SA3 chose not to intervene so this lead to implementation problems.
replied to No    
    S3‑194288 [DRAFT] Reply to: 256 bit radio interface algorithm performance Ericsson LS out Approval Yes
YesCATT didn’t fully agree with the commodity hardware statement. Qualcomm: from UE perspective, this doesn’t preclude that SAGE can find other algorithms. Apple wanted to add this clarification. Vodafone: this is implied in all their work, we don’t need to add this clarification to every LS for them. NTT-Docomo: what is "commodity hardware" here? Replace it with something else. CATT agreed. CATT: don’t rule out hardware solutions. Apple wanted to add a sentence on the choosing of algorithms. Vodafone found obvious the process and there wans't any need of stating this. Vodafone explained that SA3 went to SAGE, who provides with algorithms that fulfil SA3's requirements. SA3 is the one choosing the algorithms, not SAGE.
revised No S3‑194456  
    S3‑194456 Reply to: 256 bit radio interface algorithm performance Ericsson LS out Approval Yes
Yes
approved No   S3‑194288
    S3‑194334 Reply LS to SAGE on 256-bit algorithms Qualcomm Incorporated LS out Approval Yes
Yes
merged No S3‑194456  
    S3‑194534 256 bit algorithm candidates ETIS SAGE LS in discussion Yes
Yes
postponed No    
6.4 GSMA                      
6.5 TCG S3‑193910 TCG progress - report from TCG rapporteur InterDigital Communications other Information Yes
YesPublication of new or revised deliverables (incremental changes from the status reported at SA3#96). • TCG Mobile Device Runtime Integrity Preservation – publication November 2019. The following public URL is available starting on 11/11/2019: https://trustedcomputinggroup.org/resource/tcg-runtime-integrity-preservation-in-mobile-devices/ • TCG TPM 2.0 Mobile Command Response Buffer Errata – publication November 2019 • TCG Trusted Attestation Protocol (TAP) Use Cases – publication November 2019 • TCG TSS 2.0 Overview and Common Structures – published October 2019 • TCG TSS 2.0 Feature API (FAPI) – public review October 2019 • TCG TSS 2.0 JSON Datatypes and Policy Language – public review October 2019 • TCG TPM 2.0 Authenticated Countdown Timer (ACT) Command – public review October 2019 • TCG Platform Certificate Profile – public review October 2019 • TCG PC Client Specific TPM Protection Profile (PTP) – public review October 2019 • TCG Trusted Attestation Protocol (TAP) Info Model – published September 2019 • TCG TSS 2.0 Enhanced System Level API (ESAPI) – published September 2019 • TCG TSS 2.0 System Level API (SAPI) – published August 2019 • TCG Guidance for Secure Update of S/W and F/W – public review August 2019 • TCG RIV: Network Equipment Remote Attestation – public review June 2019 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 2. Meetings • 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
noted No    
6.6 OneM2M                      
6.7 TC-CYBER                      
6.8 ETSI NFV                      
6.9 CVDs and Research S3‑194063 Top research papers published in 2019 on 4G and 5G security CableLabs discussion Information Yes
YesCableLabs encouraged delegates to inform on similar papers presented in other conferences. Vodafone: dangerous precedent here, especially if we show papers that haven't been properly reviewed. There is an established process in 3GPP CVD for this. We need a filter in advance to this.
noted No    
6.10 Other Groups S3‑193932 LS on O-RAN Alliance & 3GPP Coordination on O-RAN Alliance Outputs O-RAN Alliance LS in   Yes
YesNokia: there is no security group in O-RAN, so we don’t know what they are asking us to do.
noted No    
    S3‑193933 Reply LS to “O-RAN Alliance & 3GPP Coordination on O-RAN Alliance Outputs” SP-190947 LS in   Yes
Yes
noted No    
    S3‑193952 LS on SG17 new work item X.sles “Security measures for location enabled smart office services” ITU-T SG17 LS in   Yes
Yes
noted No    
    S3‑193954 LS on status of draft Recommendation ITU-T Q.SR-Trust “Signalling requirements and architecture for interconnection between trustable network entities” ITU-T SG11 LS in   Yes
Yes
noted No    
    S3‑193955 LS on SG11 activities related to improvement of the SS7 security including for digital financial services SP-190586 LS in   Yes
Yes
noted No    
7 Work Areas                      
7.1 Security aspects of 5G System - Phase 1 (Rel-15) S3‑193946 LS Response Reply LS on support of non-3GPP only UE and support for PEI in IMEI format S2-1910679 LS in   Yes
Yes
noted No    
    S3‑193947 LS Response on Security Aspects of AMF Re-allocation Procedure S2-1910724 LS in   Yes
Yes
noted No    
    S3‑193978 Issue of re-authentication when AMF re-allocation via NAS reroute vivo, Apple discussion Endorsement Yes
YesNokia: against SA2 decision. There was no agreement as Nokia and Qualcomm were against it. There was no issue for them.
noted No    
    S3‑194027 Horizontal derivation when AMF re-allocation Apple, vivo CR Approval Yes
Yes
merged No S3‑194691  
    S3‑194031 CR-R16-Horizontal derivation when AMF re-allocation Apple, vivo CR Approval Yes
Yes
merged No S3‑194692  
    S3‑194065 Considerations on security handling of registration with AMF re-allocation ZTE Corporation discussion Endorsement Yes
Yes
noted No    
    S3‑194066 Security handling in registration with AMF re-allocation ZTE Corporation CR Agreement Yes
Yes
merged No S3‑194692  
    S3‑194196 Clarification on AMF reallocation via direct NAS reroute for Rel-15 Huawei, Hisilicon CR Approval Yes
YesQualcomm: we are adding new functionality in the UE and we don’t agree with that. ZTE: changes should go to Release 16 only.
not pursued No    
    S3‑194197 Clarification on AMF reallocation via direct NAS reroute for Rel-16 Huawei, Hisilicon CR Approval Yes
Yes
not pursued No    
    S3‑194198 Clarification on primary authentication in direct NAS reroute for Rel-15 Huawei, Hisilicon CR Approval Yes
Yes
revised No S3‑194691  
    S3‑194691 Clarification on primary authentication in direct NAS reroute for Rel-15 Huawei, Hisilicon CR Approval Yes
Yes
agreed No   S3‑194198
    S3‑194199 Clarification on primary authentication in direct NAS reroute for Rel-16 Huawei, Hisilicon CR Approval Yes
Yes
revised No S3‑194692  
    S3‑194692 Clarification on primary authentication in direct NAS reroute for Rel-16 Huawei, Hisilicon,ZTE CR Approval Yes
Yes
agreed No   S3‑194199
    S3‑194315 Solving AMF re-allocations issues for via the RAN Qualcomm Incorporated discussion Endorsement Yes
Yes
noted No    
    S3‑194420 Comments on S3-194315 HUAWEI TECHNOLOGIES Co. Ltd. discussion Discussion Yes
Yes
noted No    
    S3‑194195 Solving registration failure in registration procedure with AMF reallocation Huawei, Hisilicon CR Approval Yes
YesQualcomm didn’t see any advantages in this proposal. Nokia wanted to wait for SA2's discussions. All agreed on having an issue for Release 16. The Chair asked if SA3 needed to wait for SA2's progress and Huawei strongly disagreed. This had to be taken offline. NTT-Docomo: Rel-15 UEs that end up in the wrong place? What do we do about them? Non-backward compatible changes are a cause for concern.
not pursued No    
    S3‑194076 Correction of handling of 5G security contexts during EPS to 5GS idle mode mobility Intel Corporation (UK) Ltd CR   Yes
Yes
revised No S3‑194458  
    S3‑194458 Correction of handling of 5G security contexts during EPS to 5GS idle mode mobility Intel Corporation (UK) Ltd CR - Yes
YesQualcomm wanted to add in the cover sheet that it is not a change of behaviour of the ME but for alignment.
agreed No   S3‑194076
    S3‑194293 Idle mode mobility from 5GS to EPS Ericsson CR Agreement Yes
YesHuawei: not needed. The first change is a default rule that everybody knows. Ericsson: everybody in SA3 but not outside this group. Huawei: clause 8.6.1 already describes that, why repeat? Nokia supported that this change was not necessary. There was no support for this CR.
not pursued No    
    S3‑194294 Idle mode mobility from 5GS to EPS Ericsson CR Agreement Yes
Yes
not pursued No    
    S3‑194295 Idle mode mobility from EPS to 5GS Ericsson CR Agreement Yes
YesMCC: NOTE 2 contains normative language and that needs to be changed. Huawei had also some issues and this was taken offline.
revised No S3‑194460  
    S3‑194460 Idle mode mobility from EPS to 5GS Ericsson CR Agreement No
Yes
not pursued No   S3‑194295
    S3‑194282 AMF re-allocation Ericsson discussion Endorsement Yes
YesHuawei: SA2 is waiting for SA3's feedback, and SA3 is waiting for SA2's feedback. We are playing ping pong here.
noted No    
    S3‑194296 Idle mode mobility from EPS to 5GS Ericsson CR Agreement Yes
Yes
revised No S3‑194461  
    S3‑194461 Idle mode mobility from EPS to 5GS Ericsson CR Agreement No
Yes
not pursued No   S3‑194296
    S3‑194358 Updates to Counter Check Procedure (Rel-16) Samsung CR Approval Yes
Yes
revised No S3‑194601  
    S3‑194601 Updates to Counter Check Procedure (Rel-16) Samsung CR Approval Yes
Yes
agreed No   S3‑194358
    S3‑194111 Add Missing Procedure for Security Handling for RRCConnectionRe-establishment Procedure Huawei, Hisilicon CR Approval Yes
YesQualcomm: we have this supported in LTE, so why do we need to repeat it for 5G as well? This was taken offline.
agreed No    
    S3‑194462 Add Missing Procedure for Security Handling for RRCConnectionRe-establishment Procedure Huawei, Hisilicon CR Approval No
Yes
withdrawn Yes    
    S3‑194112 Mirror for Adding Missing Procedure for Security Handling for RRCConnectionRe-establishment Procedure Huawei, Hisilicon CR Approval Yes
Yes
agreed No    
    S3‑194142 Discussion on the Xn-Handover message CATT discussion Decision Yes
YesThis was kept open until RAN3 had discussed the issue during the week and confirm the scenario. CATT got feedback from RAN3: it was considered a rare case and the final decision was to be taken by SA3. It was finally noted but further action will be taken in the next meeting.
noted No    
    S3‑194321 CR on clarification of ARFCN in KgNB derivation Qualcomm Incorporated, Nokia, Nokia Shanghai Bell CR Agreement Yes
YesHuawei: just put he reference. Qualcomm: better to give more information. The description would not be self-contained.
agreed No    
    S3‑194322 CR on clarification of ARFCN in KgNB derivation Qualcomm Incorporated, Nokia, Nokia Shanghai Bell CR Agreement Yes
Yes
agreed No    
    S3‑194298 Error handling against violation of the basic validation rules Nokia, Nokia Shanghai Bell CR Approval Yes
YesEricsson pointed out that this should go to Release 15. It was clarified that this was pointing to the Release 15 functionality of the SEPP. It was commented that the editor's note already appeared in the SCAS spec. This had to be taken offline.
not pursued No    
    S3‑194134 Amendment on 4.2.2.1.2 on AMF Huawei, Hisilicon CR Approval No
Yes
withdrawn Yes    
    S3‑194457 Correction of handling of 5G security contexts during EPS to 5GS idle mode mobility Intel CR Agreement Yes
Yes
agreed No    
7.2 Security Assurance Specification for 5G (Rel-16) S3‑194224 Fix some reference numbers Huawei, Hisilicon CR Approval Yes
Yes
agreed No    
    S3‑194342 33.511 Corrections for clean-up and alignment Nokia, Nokia Shanghai Bell CR Approval Yes
YesOverlapping with 223 and 270. The editor's notes were challenged and it was suggested to have an action point instead. Futurewei suggested to convert it into a note. Ericsson preferred to remove the editor's note and minute that the threat reference had to be replaced. Ericsson suggested: Some of the threat references are not aplicable to the requirements and they need to be replaced with new threat references that are applicable. Huawei: The whole test case needs to be revisited. The text to be minuted was taken offline. Futurewei: the removal of these test cases should not be brought back again. This has come several times already. Nokia asked to minute the following comment: "The threats referenced in sub-clauses 4.2.2.1.1, 4.2.2.1.2, 4.2.2.1.4, 4.2.2.1.5 4.2.2.1.6, 4.2.2.1.7, 4.2.2.1.8, and 4.2.2.1.9 are not applicable to the requirements to be tested, and need to be replaced with new threats to be captured in TR 33.926".
revised No S3‑194473  
    S3‑194473 33.511 Corrections for clean-up and alignment Nokia, Nokia Shanghai Bell CR Approval Yes
Yes
agreed No   S3‑194342
    S3‑194131 Adding some evidence Huawei, Hisilicon CR Approval Yes
Yes
agreed No    
    S3‑194223 Update test cases for gNB SCAS Huawei, Hisilicon CR Approval Yes
Yes
revised No S3‑194474  
    S3‑194474 Update test cases for gNB SCAS Huawei, Hisilicon CR Approval Yes
YesRevised to address an editorial change: removal of automatic bullet lists.
agreed No   S3‑194223
    S3‑194270 Test cases referring to TS 33.117 Ericsson CR Agreement Yes
YesHuawei and CATT objected to this CR.
not pursued No    
    S3‑194133 Fix the threat reference numbers for AMF Huawei, Hisilicon CR Approval Yes
YesOverlap with 343. Tdoc number on the cover is wrong. Nokia asked to be minuted: Nokia asked to be minuted the following comment: "The threat referenced in sub-clause 4.2.2.3.1 is not applicable to the requirement to be tested, and needs to be replaced with a new threat to be captured in TR 33.926".
merged No S3‑194475  
    S3‑194343 33.512 Corrections for clean-up and alignment Nokia, Nokia Shanghai Bell CR Approval Yes
Yes
revised No S3‑194475  
    S3‑194475 33.512 Corrections for clean-up and alignment Nokia, Nokia Shanghai Bell,Huawei CR Approval Yes
Yes
agreed No   S3‑194343
    S3‑194132 Modify the message names Huawei, Hisilicon CR Approval Yes
Yes
agreed No    
    S3‑194344 33.513 Corrections for clean-up and alignment Nokia, Nokia Shanghai Bell CR Approval Yes
YesOverlap with 135.
revised No S3‑194476  
    S3‑194476 33.513 Corrections for clean-up and alignment Nokia, Nokia Shanghai Bell,Huawei CR Approval Yes
Yes
agreed No   S3‑194344
    S3‑194135 Fix the threat reference numbers for UPF Huawei, Hisilicon CR Approval Yes
Yes
merged No S3‑194476  
    S3‑194345 33.514 Corrections for clean-up and alignment Nokia, Nokia Shanghai Bell CR Approval Yes
Yes
agreed No    
    S3‑193907 Alignment with TR 33.926 Futurewei Technologies CR Agreement Yes
YesOverlap with 908,347.
merged No S3‑194477  
    S3‑193908 Reference Correction Futurewei Technologies CR Agreement Yes
Yes
merged No S3‑194477  
    S3‑193909 Adding missing abbreviations Futurewei Technologies CR Agreement Yes
Yes
agreed No    
    S3‑194347 33.515 Corrections for clean-up and alignment Nokia, Nokia Shanghai Bell CR Approval Yes
Yes
revised No S3‑194477  
    S3‑194477 33.515 Corrections for clean-up and alignment Nokia, Nokia Shanghai Bell,Futurewei CR Approval Yes
Yes
agreed No   S3‑194347
    S3‑194348 33.516 Corrections for alignment Nokia, Nokia Shanghai Bell CR Approval Yes
Yes
agreed No    
    S3‑194349 33.517 Adding abbreviations and corrections for alignment Nokia, Nokia Shanghai Bell CR Approval Yes
Yes
revised No S3‑194478  
    S3‑194478 33.517 Adding abbreviations and corrections for alignment Nokia, Nokia Shanghai Bell CR Approval Yes
YesBringing back the removed editor's note.
agreed No   S3‑194349
    S3‑194350 33.518 Adding abbreviations and corrections for alignment Nokia, Nokia Shanghai Bell CR Approval Yes
Yes
agreed No    
    S3‑194067 Editorial correction in TS 33.519 ZTE Corporation CR Agreement Yes
Yes
merged No S3‑194479  
    S3‑194351 33.519 Corrections for clean-up and alignment Nokia, Nokia Shanghai Bell CR Approval Yes
Yes
revised No S3‑194479  
    S3‑194479 33.519 Corrections for clean-up and alignment Nokia, Nokia Shanghai Bell,ZTE CR Approval Yes
Yes
agreed No   S3‑194351
    S3‑194158 Miscellaneous Editorial clarifications in 33.926 Huawei, Hisilicon CR Approval Yes
Yes
agreed No    
    S3‑194301 33.117 Adding abbreviations and corrections for alignment Nokia, Nokia Shanghai Bell CR Approval Yes
Yes
agreed No    
    S3‑194159 Miscellaneous Editorial clarifications in 33.117 Huawei, Hisilicon CR Approval Yes
YesHuawei commented that there were some issues that they couldn’t fix. E.g. references such as [ef]. Huawei asked to minute that there were references that were unresolved and that anyone was welcome to fix them.
agreed No    
    S3‑194157 Miscellaneous Editorial clarifications in 33.916 Huawei, Hisilicon CR Approval Yes
YesHuawei wanted to point out that there were unresolved editor's notes in the specification.
agreed No    
    S3‑194161 Update of clause 4 Huawei, Hisilicon CR Approval Yes
YesEricsson argued that having the text in the document was OK.Nokia supported Ericsson.
not pursued No    
    S3‑194419 Clarification on aspects specific to the network product class UDM and AMF Huawei, Hisilicon CR Approval Yes
Yes
agreed No   S3‑194179
7.3 eMCSec R16 security (Rel-16) S3‑193926 LS on IANA assigned values for mission critical C1-195042 LS in   Yes
Yes
replied to No    
    S3‑194603 Reply to: LS on IANA assigned values for mission critical Motorola Solutions LS out approval Yes
Yes
approved No    
    S3‑193930 LS on how the IWF obtains key material for interworking group and private communications C1-196979 LS in   Yes
YesThe response will be included in the reply to tdoc 433.
noted No    
    S3‑193914 [MCXSec] 33180 R16 Missing Abbreviations (Mirror) Airbus CR Agreement Yes
Yes
revised No    
    S3‑193915 [MCXSec] 33180 R16 Reference Addition (Mirror) Airbus CR Agreement Yes
Yes
agreed No    
    S3‑193916 [MCXSec] 33180 R16 Correction concerning IdM client (Mirror) Airbus CR Agreement Yes
Yes
agreed No    
    S3‑193995 [33.180] R16 Fix bad reference (mirror) Motorola Solutions UK Ltd. CR Agreement Yes
Yes
agreed No    
    S3‑193996 [33.180] R16 - Consistent use of off-network Motorola Solutions UK Ltd. CR Agreement Yes
Yes
revised No S3‑194499  
    S3‑194499 Consistent use of off-network Motorola Solutions UK Ltd. CR Agreement Yes
Yes
agreed No   S3‑193996
    S3‑193997 [33.180] R16 KM client to KMS security Motorola Solutions UK Ltd. CR Agreement Yes
Yes
agreed No    
    S3‑193998 [33.180] R16 - TrK ID and InK ID Motorola Solutions UK Ltd. CR Agreement Yes
Yes
revised No S3‑194500  
    S3‑194500 [33.180] R16 - TrK ID and InK ID Motorola Solutions UK Ltd. CR Agreement Yes
Yes
agreed No   S3‑193998
    S3‑193999 [33.180] R16 - InterSD KM record Motorola Solutions UK Ltd. CR Agreement Yes
Yes
agreed No    
    S3‑194000 [33.180] R16 ETSI Plugtest clarifications Motorola Solutions UK Ltd. CR Agreement Yes
Yes
agreed No    
    S3‑194362 Algorithm negotiation procedure for MC Service Samsung CR Approval Yes
Yes
revised No S3‑194652  
    S3‑194652 Algorithm negotiation procedure for MC Service Samsung,Motorola Solutions CR Approval Yes
Yes
agreed No   S3‑194362
    S3‑194001 LS to CT1 on 3rd ETSI MCX Remote Plugtest Motorola Solutions UK Ltd. LS out Agreement Yes
Yes
revised No S3‑194501  
    S3‑194501 LS to CT1 on 3rd ETSI MCX Remote Plugtest Motorola Solutions UK Ltd. LS out Agreement Yes
Yes
revised No S3‑194611 S3‑194001
    S3‑194611 LS to CT1 on 3rd ETSI MCX Remote Plugtest Motorola Solutions UK Ltd. LS out Agreement Yes
Yes
approved No   S3‑194501
    S3‑194433 Reply LS on how the IWF obtains key material for interworking group and private communications S6-192194 LS in discussion Yes
Yes
postponed No    
    S3‑194502 Minutes of the Mission Critical offline session Qualcomm report Information Yes
Yes
noted No    
7.4 Security aspects of single radio voice continuity from 5GS to UTRAN (Rel-16)                      
7.5 Enhancements for Security aspects of Common API Framework for 3GPP Northbound APIs (Rel-16) S3‑194360 Description of CAPIF reference point: 3e,4e,5e,7 and 7e Samsung CR Approval Yes
YesTim (Motorola Solutions): we are missing CAPIF-2e's definition here. Henrik (Ericsson): CAPIF-7e is similar to CAPIF-2e in the third paragraph. These were agreed and addressed in the revision.
revised No S3‑194464  
    S3‑194464 Description of CAPIF reference point: 3e,4e,5e,7 and 7e Samsung CR Approval Yes
Yes
agreed No   S3‑194360
7.6 Security of URLLC for 5GS (Rel-16) S3‑194421 living CR of URLLC Huawei, Hisilicon draftCR   Yes
Yes
revised No S3‑194467  
    S3‑194467 living CR of URLLC Huawei, Hisilicon draftCR - No
Yes
left for email approval No   S3‑194421
    S3‑194125 Clean up Huawei, Hisilicon draftCR Approval Yes
YesNokia and Qualcomm didn’t agree with the change in the general clause. This had to be taken offline.
revised No S3‑194469  
    S3‑194469 Clean up Huawei, Hisilicon draftCR Approval Yes
Yes
approved No   S3‑194125
    S3‑194225 Resolve EN about how to ensure the UP security policy to be the same Ericsson draftCR Approval Yes
Yes
revised No S3‑194470  
    S3‑194470 Resolve EN about how to ensure the UP security policy to be the same Ericsson,Huawei draftCR Approval Yes
Yes
approved No   S3‑194225
    S3‑194122 Ensure the same setting for UP policy Huawei, Hisilicon draftCR Approval Yes
YesNokia agreed with removing the editor's note but wanted some rewording of the preceding text.
merged No S3‑194470  
    S3‑194123 Clarification on UP security policy preconfiguration Huawei, Hisilicon draftCR Approval Yes
YesQualcomm didn’t see the need of the new text at all, for the "preferred" option and so on. Nokia wasn't sure about this either. Huawei added that this clarification was needed. This was taken offline.
approved No    
    S3‑194226 Resolve EN about MN being preconfigured with SN capability to perform UP IP Ericsson draftCR Approval Yes
Yes
noted No    
    S3‑194124 Further clarification on UP activation status Huawei, Hisilicon draftCR Approval Yes
YesNokia found that there was a lot of text here. Qualcomm preferred to have an option with minimal text.
noted No    
    S3‑194061 URLLC living CR: clarifications related to security policy Nokia, Nokia Shanghai Bell other Approval Yes
Yes
noted No    
    S3‑194472 URLLC living CR: clarifications related to security policy Nokia, Nokia Shanghai Bell,Huawei,Ericsson other Approval No
Yes
withdrawn Yes    
    S3‑194418 Comment on S3-194061 Huawei, HiSilicon other   Yes
Yes
noted No    
7.7 Security for 5GS Enhanced support of Vertical and LAN Services (Rel-16) S3‑193956 LS on SUCI computation from an NSI CP-192262 LS in   Yes
Yes
replied to No    
    S3‑194335 Reply LS on SUCI computation from an NSI Qualcomm Incorporated LS out Approval Yes
YesOrange commented that the derivation still needed to be standardised. Qualcomm replied that this was up to CT4. Thales: consider whether the identifiers are active or not. IMSI and NSI can be stored in SA6. NSI can be activated with a defined mechanism. It is possible to have two identifiers and having one activated in SA6. Thales: confirm that the NSI for AKA based authentication is always derived from the IMSI. Orange confirmed that.
revised No S3‑194548  
    S3‑194548 Reply LS on SUCI computation from an NSI Qualcomm Incorporated LS out Approval Yes
Yes
approved No   S3‑194335
    S3‑194319 Removing editor's note on capturing all the details for alternative authentication methods Qualcomm Incorporated CR Agreement Yes
Yes
revised No S3‑194549  
    S3‑194549 Removing editor's note on capturing all the details for alternative authentication methods Qualcomm Incorporated CR Agreement Yes
Yes
agreed No   S3‑194319
    S3‑194409 Authentication of a TSC enabled UE Nokia, Nokia Shanghai Bell CR Agreement Yes
YesQualcomm: "specified in this document". We refer to requirements that are all over the document. Orange: specify clause 6.1. This had to be taken offline. Editorial corrections. MCC commented: Just "UE" and not "5GS UE".
revised No S3‑194550  
    S3‑194550 Access security for a TSC-enabled UE Nokia, Nokia Shanghai Bell CR Agreement Yes
Yes
agreed No   S3‑194409
    S3‑194424 UP security in TSC Nokia, Nokia Shanghai Bell CR Agreement Yes
Yes
revised No S3‑194553 S3‑194410
    S3‑194553 UP security in TSC Nokia, Nokia Shanghai Bell,Huawei CR Agreement Yes
Yes
agreed No   S3‑194424
    S3‑194093 DraftCR_TSC protection Huawei, Hisilicon draftCR Approval Yes
Yes
merged No S3‑194553  
    S3‑194386 CAG cell access check Samsung draftCR Approval Yes
YesNokia, Huawei, Ericsson objected to this.
noted No    
    S3‑194404 CAG ID privacy Nokia, Nokia Shanghai Bell CR Agreement Yes
Yes
not pursued No    
    S3‑194164 CAG ID privacy Huawei, Hisilicon draftCR Approval Yes
YesOpen depending on the agreements on the CAG ID privacy.
noted No    
    S3‑194410 UP security in TSC Nokia, Nokia Shanghai Bell CR Agreement Yes
Yes
revised No S3‑194424  
    S3‑194459 Adding TSC abbreviation Nokia CR Agreement No
Yes
agreed No    
7.8 Security of the enhancement to the 5GC location services S3‑194150 Draft CR as a living baseline for 5GS LCS normative work CATT draftCR Approval Yes
YesLiving document used as a baseline for the contributions in this meeting.
revised No S3‑194465  
    S3‑194465 Draft CR as a living baseline for 5GS LCS normative work CATT draftCR Approval Yes
Yes
approved No   S3‑194150
    S3‑194153 Draft CR for eLCS on access point security CATT draftCR Approval Yes
Yes
merged No S3‑194466  
    S3‑194090 resolving editor's note on the move of access point Huawei, Hisilicon draftCR Approval Yes
YesEricsson: moving the access point is not relevant here.Huawei conceded to go for Ericsson's proposal for the resolution of the second editor's note. Qualcomm: All release 16 Ues don’t have to support this. Clarify that it is optional.
merged No S3‑194466  
    S3‑194271 Resolving ENs in Draft CR as a living baseline for 5GS LCS normative work Ericsson draftCR Approval Yes
YesNokia supported this solution but didn’t see why changing "should" to "shall". Ericsson: what to do if the UE doesn’t receive this lst? In this case the UE would not be able to send its location for emergency purposes. Nokia didn’t agree with mandating this behaviour. This was taken offline.
revised No S3‑194466  
    S3‑194466 Resolving ENs in Draft CR as a living baseline for 5GS LCS normative work Ericsson,Huawei,CATT draftCR Approval No
Yes
approved No   S3‑194271
7.9 Security Aspects of the 5G Service Based Architecture (Rel-16) S3‑193943 Reply LS on eSBA NF Set S2-1910148 LS in   Yes
Yes
noted No    
    S3‑194250 Editorials and corrections to Security requirements for SeCoP Ericsson draftCR Approval Yes
Yes
revised No S3‑194517  
    S3‑194517 Editorials and corrections to Security requirements for SeCoP Ericsson draftCR Approval Yes
Yes
approved No   S3‑194250
    S3‑194367 TLS between NF and SEPP based on custom HTTP header Nokia, Nokia Shanghai Bell CR Agreement Yes
Yes
revised No S3‑194518  
    S3‑194518 TLS between NF and SEPP based on custom HTTP header Nokia, Nokia Shanghai Bell CR Agreement Yes
Yes
agreed No   S3‑194367
    S3‑194256 Security for roaming interfaces in indirect communication Ericsson CR Agreement Yes
Yes
revised No S3‑194519  
    S3‑194519 Security for roaming interfaces in indirect communication Ericsson,Nokia CR Agreement No
Yes
agreed No   S3‑194256
    S3‑194370 Mutual authentication between Network Functions Nokia, Nokia Shanghai Bell CR Agreement Yes
Yes
not pursued No    
    S3‑194520 Mutual authentication between Network Functions Nokia, Nokia Shanghai Bell CR Agreement No
Yes
withdrawn Yes    
    S3‑194372 NF consumer authentication by the producer in direct communication scenarios Nokia, Nokia Shanghai Bell CR Agreement Yes
Yes
not pursued No    
    S3‑194521 NF consumer authentication by the producer in direct communication scenarios Nokia, Nokia Shanghai Bell CR Agreement No
Yes
withdrawn Yes    
    S3‑194252 Using Rel-15 token-based authorization in indirect communication scenarios Ericsson CR Agreement Yes
Yes
not pursued No    
    S3‑194522 Using Rel-15 token-based authorization in indirect communication scenarios Ericsson draftCR Agreement No
Yes
left for email approval No    
    S3‑194187 Service access authorization of a NF Set Huawei, Hisilicon draftCR Approval Yes
YesContent is moved to the CR in 523.
noted No    
    S3‑194523 Service access authorization of a NF Set Huawei, Hisilicon CR Approval Yes
Yes
agreed No    
    S3‑194365 Resource Level Authorization using Access Tokens Nokia, Nokia Shanghai Bell CR Agreement Yes
YesCompeting contribution in 261. Huawei:The key issue in the TR (number 29) is not concluded yet. 365, 261 were taken offline since they depended on the outcome of the key issue.
merged No S3‑194659  
    S3‑194261 Resource Level Authorization using Access Tokens Ericsson CR Agreement Yes
Yes
not pursued No    
    S3‑194659 Resource Level Authorization using Access Tokens Ericsson,Nokia draftCR Agreement No
Yes
left for email approval No    
    S3‑194430 Commenting contribution on S3-194261 – Resource Level Authorization using Access Tokens Nokia, Nokia Shanghai Bell discussion Information Yes
Yes
noted No    
    S3‑194262 Authorization using Access Tokens based on NF-Subtype Ericsson CR Agreement Yes
YesNokia: the key issue is still open. This was left open depending on the outcome of the key issue.
not pursued No    
    S3‑194376 SBA Network Function TLS certificate profile Nokia, Nokia Shanghai Bell CR Agreement Yes
Yes
not pursued No    
    S3‑194524 SBA Network Function TLS certificate profile Nokia, Nokia Shanghai Bell draftCR Approval Yes
YesThis draftCR will be used as a baseline for discussions and it will be brought back next meeting.
noted No    
    S3‑194374 TLS entity certificate profile for SBA Nokia, Nokia Shanghai Bell CR Agreement Yes
YesHuawei: this is too early. BT: TLS profiles defined in 33.210 already? MCC added that a draftCR would be more appropriate in order to introduce content with latercontributions, given that this CR was just introducing empty clauses. Nokia commented that there was only one meeting left before the freeze of Release 16.
not pursued No    
    S3‑194251 Editorials and corrections to Protection of N9 interface Ericsson draftCR Approval Yes
YesIt will go to tdoc 444.
approved No    
7.10 Authentication and key management for applications based on 3GPP credential in 5G (Rel-16) S3‑194340 pCR: Adding UE – AF interface to the AKMA Reference Model Qualcomm Incorporated pCR Approval Yes
Yes
approved No    
    S3‑194160 Update on AKMA reference model China Mobile, Nokia, Nokia Shanghai Bell pCR Approval Yes
YesQualcomm: it should be an editor's note. China Mobile commented that this would mean that SA3 would have to resolve it and that wasn't necessary.
approved No    
    S3‑194127 AKMA network functions Huawei, Hisilicon pCR Approval Yes
YesOverlapping with tdoc 200. Qualcomm: we don’t need the AMF for RAN. Vodafone: why so many network functions interfacing here? It woud be an ideal point for an attack, creating a security hole. We should be cautious and connect what we absolutely need.
merged No S3‑194641  
    S3‑194200 Add AAnF description into clause 4.2 China Mobile, Nokia, Nokia Shanghai Bell pCR Approval Yes
YesQualcomm: requirements should go to the requirements clause, not here. Huawei: remove the editor's note.
revised No S3‑194641  
    S3‑194641 Add AAnF description into clause 4.2 China Mobile, Nokia, Nokia Shanghai Bel, Huaweil pCR Approval Yes
Yes
approved No   S3‑194200
    S3‑194128 AKMA interface description Huawei, Hisilicon pCR Approval Yes
YesEricsson: remove N1,N2. Qualcomm: Namf not needed for AKMA either.
revised No S3‑194642  
    S3‑194642 AKMA interface description Huawei, Hisilicon pCR Approval Yes
Yes
approved No   S3‑194128
    S3‑194129 AKMA security principles and requirements Huawei, Hisilicon pCR Approval Yes
YesOrange: lifetime of the keys is operators' decision.The first sentence of the last requirement was removed. Qualcomm and Orange didn’t agree with these requirements. Only the last sentence went into the merge.
merged No S3‑194643  
    S3‑194201 Add content to clause 4.4 China Mobile, Nokia, Nokia Shanghai Bell pCR Approval Yes
Yes
revised No S3‑194643  
    S3‑194643 Add content to clause 4.4 China Mobile, Nokia, Nokia Shanghai Bell,Huawei pCR Approval Yes
Yes
approved No   S3‑194201
    S3‑194272 Update of the key hierarchy Ericsson pCR Approval Yes
YesOverlapping with 341.
noted No    
    S3‑194341 pCR: pCR: Udpate of AKMA Key Hierarchy Qualcomm Incorporated pCR Approval Yes
Yes
approved No    
    S3‑194130 AKMA key management Huawei, Hisilicon pCR Approval Yes
YesEricsson: explicit/implicit lifetime was clear in the context of the TR but not so clear here. An editor's note was added to explain these in the future.
revised No S3‑194644  
    S3‑194644 AKMA key management Huawei, Hisilicon pCR Approval Yes
Yes
approved No   S3‑194130
    S3‑194228 Clause 6.X – Deriving AKMA key during UE registration Nokia, Nokia Shanghai Bell, China Mobile pCR Approval Yes
YesQualcomm proposed two editor's notes on the association with the UE is FFS.
revised No S3‑194645  
    S3‑194645 Clause 6.X – Deriving AKMA key during UE registration Nokia, Nokia Shanghai Bell, China Mobile pCR Approval Yes
Yes
approved No   S3‑194228
    S3‑194229 Clause 6.Y – Deriving AF key for a specific Application function Nokia, Nokia Shanghai Bell, China Mobile pCR Approval Yes
Yes
approved No    
    S3‑194156 Add Abrreviations to TS 33.535 China Mobile, Nokia, Nokia Shanghai Bell pCR Approval Yes
Yes
approved No    
    S3‑193985 End-to-end security KPN, China Mobile pCR Approval Yes
YesIt will come back in the next meeting since it depends on other discussions.
noted No    
    S3‑194640 Draft TS 33.535 China Mobile draft TS Approval No
Yes
left for email approval No    
7.11 Evolution of Cellular IoT security for the 5G System (Rel-16) S3‑193927 Reply LS on NAS Aspects of Mobile-terminated Early Data Transmission C1-195111 LS in   Yes
YesPart of this LS was addressed as a new LS sent from last SA3's meeting. Ericsson believed that there were still open issues and wanted to have minuted that they would bring contributions in the future to address them: "Ericsson has noted that the UP case is different ass the GUTI is not revealed in the uplink and may not need GUTI reallocation. Therefore, Ericsson may bring related contributions next meeting."
noted No    
    S3‑193928 Reply LS on Mobile-terminated Early Data Transmission R2-1911603 LS in   Yes
YesNo actions for SA3.
noted No    
    S3‑193936 Reply LS on bulk authentication issue for IoT devices R2-1911790 LS in   Yes
Yes
noted No    
    S3‑194426 Forwarding of Reply LS on GUTI allocation for 5G CIoT C1-198560 LS in   Yes
Yes
noted No    
    S3‑193948 Reply LS on RRC Connection Reestablishment for CP for NB-IoT connected to 5GC S2-1910789 LS in   Yes
Yes
replied to No    
    S3‑194482 Reply to: Reply LS on RRC Connection Reestablishment for CP for NB-IoT connected to 5GC Huawei LS out approval Yes
Yes
approved No    
    S3‑194098 Discussion on Security for truncation of 5G-S-TMSI Huawei, Hisilicon discussion Endorsement Yes
YesQualcomm: not a DoS issue. We can modify whatever messages in the middle and cause this DoS. Ericsson: the RAN cannot recreate the full 5G S-TMSI. Qualcomm: this does not introduce a new security issue. It was agreed not to describe the DoS attack in the LS.
noted No    
    S3‑194100 Reply LS to SA2 on Security Issue on 5G-S-TMSI Truncation Procedure Huawei, Hisilicon LS out Approval Yes
YesEricsson agreed with this LS with minor changes. Qualcomm didn’t agree with the DoS issue. The attack is based on man in the middle but it doesn’t lead to DoS.
noted No    
    S3‑194320 Reply LS to SA2 on RRC Connection Reestablishment for CP for NB-IoT Qualcomm Incorporated LS out Approval Yes
Yes
noted No    
    S3‑194242 DraftCR – Living document for supporting 5G CIoT security Ericsson other Approval Yes
Yes
revised No S3‑194483  
    S3‑194483 DraftCR – Living document for supporting 5G CIoT security Ericsson draftCR Approval No
Yes
left for email approval No   S3‑194242
    S3‑194101 CIoT Title Modifications to draft CR Huawei, Hisilicon draftCR Approval Yes
Yes
approved No    
    S3‑194236 [Draft CR] RRC Connection Re-Establishment for the control plane for NB-IoT radio access connected to 5GC Ericsson other Approval Yes
Yes
revised No S3‑194484  
    S3‑194484 [Draft CR] RRC Connection Re-Establishment for the control plane for NB-IoT radio access connected to 5GC Ericsson,Huawei other Approval Yes
Yes
approved No   S3‑194236
    S3‑194099 Security Procedure for RRCConnectionRe-establishment Procedure for Control Plane Optimization for 5GS CIoT Huawei, Hisilicon draftCR Approval Yes
YesClarifications and additions needed to be discussed offline. Huawei argued that it was too early to add the false base station scenario as proposed by Ericsson.
merged No S3‑194484  
    S3‑194102 Skeleton for Security handling in User Plane CIoT 5GS Optimization Huawei, Hisilicon draftCR Approval Yes
Yes
approved No    
    S3‑194103 General for Security handling in User Plane CIoT 5GS Optimization Huawei, Hisilicon draftCR Approval Yes
YesEricsson wanted to align with the progress in RAN groups through the addition of two editor's notes.
revised No S3‑194485  
    S3‑194485 General for Security handling in User Plane CIoT 5GS Optimization Huawei, Hisilicon draftCR Approval Yes
Yes
approved No   S3‑194103
    S3‑194104 Security handling in Connection Suspend Procedure for User Plane CIoT 5GS Optimization Huawei, Hisilicon draftCR Approval Yes
Yes
revised No S3‑194486  
    S3‑194486 Security handling in Connection Suspend Procedure for User Plane CIoT 5GS Optimization Huawei, Hisilicon draftCR Approval Yes
YesRevised to address Ericsson's comments.
approved No   S3‑194104
    S3‑194105 Security handling in Connection Resume in CM-IDLE with Suspend to a new ng-eNB for User Plane CIoT 5GS Optimization Huawei, Hisilicon draftCR Approval Yes
Yes
revised No S3‑194487  
    S3‑194487 Security handling in Connection Resume in CM-IDLE with Suspend to a new ng-eNB for User Plane CIoT 5GS Optimization Huawei, Hisilicon draftCR Approval Yes
YesAddressing Ericsson's comments. Disagreement on linking this to the results of the false base station topic.Huawei didn’t want to do any link but Ericsson claimed that there was relation with the message parameters exposed here (fro "source C-NRTI..to the end of Note 1).
approved No   S3‑194105
    S3‑194106 Security handling in Connection Resume in CM-IDLE with Suspend to the same ng-eNB for User Plane CIoT 5GS Optimization Huawei, Hisilicon draftCR Approval Yes
Yes
approved No    
    S3‑194323 RRC UE capability transfer procedure for CP only CIoT UEs Qualcomm Incorporated CR Agreement Yes
YesMCC argued that the CR was not introducing a correction but only adding an editor's note promising work. This was not adequate for a spec under change control and it would be better to bring the changes directly when the work in the study was mature. Qualcomm commented that without this editor's note 6.5.3 would It was proposed to add this to the living document and progress the work there; this was agreed. The CR was not pursued but the editor's note was added to the living document to continue the work there.
not pursued No    
    S3‑194237 [Draft CR] RRC Connection Resume and Suspend procedures for the user plane for NB-IoT radio access connected to 5GC Ericsson other Approval No
Yes
withdrawn Yes    
7.12 Security of the Wireless and Wireline Convergence for the 5G system architecture (Rel-16) S3‑194126 Living doc for 5WWC Huawei, Hisilicon draftCR Approval Yes
Yes
revised No S3‑194529  
    S3‑194529 Living doc for 5WWC Huawei, Hisilicon draftCR Approval No
Yes
left for email approval No   S3‑194126
    S3‑194286 Introducing missing definitions of untrusted and trusted non-3GPP accesses Ericsson draftCR Approval Yes
YesConcerns on the skeleton structure as stated by Huawei. ORANGE had concerns on whether this clause was necessary according to the content.
revised No S3‑194530  
    S3‑194530 Introducing missing definitions of untrusted and trusted non-3GPP accesses Ericsson draftCR Approval No
Yes
approved No   S3‑194286
    S3‑194287 Determining trust relationship in the UE Ericsson draftCR Approval Yes
Yes
revised No S3‑194531  
    S3‑194531 Determining trust relationship in the UE Ericsson draftCR Approval No
Yes
approved No   S3‑194287
    S3‑194146 Removal of Editor’s Note and update of the Figure 6.Y.4-1 Lenovo, Motorola Mobility draftCR Approval Yes
Yes
approved No    
    S3‑194113 Editorial change for trusted non-3GPP access Huawei, Hisilicon draftCR Approval Yes
Yes
revised No S3‑194532  
    S3‑194532 Editorial change for trusted non-3GPP access Huawei, Hisilicon draftCR Approval Yes
Yes
approved No   S3‑194113
    S3‑194283 TNAP mobility using ERP Ericsson discussion Endorsement Yes
YesDiscussed together with tdoc 116.
noted No    
    S3‑194116 Using ERP for intra-TNAN mobility Huawei, Hisilicon draftCR Approval Yes
YesLenovo asked to postpone this in order to analize it with more detail.This topic will be brought back in the next meeting.
noted No    
    S3‑194114 Update content for trusted non-3GPP access Huawei, Hisilicon draftCR Approval Yes
YesNokia: not comfortable with enabling cyphering in IpSec.
revised No S3‑194533  
    S3‑194533 Update content for trusted non-3GPP access Huawei, Hisilicon draftCR Approval Yes
Yes
approved No   S3‑194114
    S3‑194284 Trusted access key hierarchy Ericsson draftCR Approval Yes
YesHuawei had some comments on the key names and this was left for offline discussion.
revised No S3‑194606  
    S3‑194606 Trusted access key hierarchy Ericsson draftCR Approval No
Yes
approved No   S3‑194284
    S3‑194285 Trusted access key derivation Ericsson draftCR Approval Yes
Yes
revised No S3‑194607  
    S3‑194607 Trusted access key derivation Ericsson draftCR Approval No
Yes
approved No   S3‑194285
    S3‑194115 Corrections on N5CW connects 5GC via trusted non-3GPP access Huawei, Hisilicon draftCR Approval Yes
Yes
approved No    
    S3‑194608 Corrections on N5CW connects 5GC via trusted non-3GPP access Huawei, Hisilicon draftCR Approval No
Yes
withdrawn Yes    
    S3‑194117 Move Requirement of 5G-RG to clause 5 Huawei, Hisilicon draftCR Approval Yes
Yes
revised No S3‑194609  
    S3‑194609 Move Requirement of 5G-RG to clause 5 Huawei, Hisilicon draftCR Approval Yes
Yes
approved No   S3‑194117
    S3‑194118 Delete an assumption sentence Huawei, Hisilicon draftCR Approval Yes
Yes
approved No    
    S3‑194119 Add a new clause for N5CW privacy Huawei, Hisilicon draftCR Approval Yes
Yes
approved No    
    S3‑194400 Removing ENs in annex X in the living document for 5WWC CableLabs, Charter Communications,Lenovo, Motorola Mobility, EricssonRogers Communications, Nokia, Nokia Shanghai Bell, CR Approval Yes
YesOrange: hard to understand what's new and what's existent. CableLabs: red text is new. Blue text is existent.
not pursued No   S3‑194030
    S3‑194610 Removing ENs in annex X in the living document for 5WWC CableLabs, Charter Communications,Lenovo, Motorola Mobility, EricssonRogers Communications, Nokia, Nokia Shanghai Bell, draftCR Approval Yes
YesRevised to show better the changes with the revision marks.
approved No    
    S3‑194030 Removing ENs in annex X in the living document for 5WWC CableLabs, Charter Communications, Rogers Communications, Nokia, Nokia Shanghai Bell CR Approval Yes
Yes
revised No S3‑194400  
    S3‑194694 5WWC Huawei CR Agreement No
Yes
withdrawn Yes    
7.13 Security aspects of Enhancement of Network Slicing (Rel-16) S3‑193929 LS on network slice-specific authentication and authorization C1-196903 LS in   Yes
YesNo action for SA3.
noted No    
    S3‑193953 LS on SG17 new work item X.nsom-sec “Security requirements and architecture for network slice orchestration and management” ITU-T SG17 LS in   Yes
YesNo action for SA3.
noted No    
    S3‑193945 Reply LS on AUSF role in slice specific authentication S2-1910668 LS in   Yes
Yes
postponed No    
    S3‑194535 Reply to: Reply LS on AUSF role in slice specific authentication Ericsson LS out approval Yes
YesNokia objected, as Telecom Italia, Orange. Ericsson, HP , Huawei, Interdigital supported this LS.
noted No    
    S3‑194054 Discussion on LS from SA2 on AUSF role Huawei, HiSilicon discussion Agreement Yes
YesNokia: proposal 2 is a big impact on the architecture. There is also a proxy in the SA2 call flow with the same functionality as the proposed new NF. Ericsson agreed with Nokia. HP agreed with Huawei's proposal. Nokia: security for the new slice specific authentication workflow is not broken from the security perspective. Huawei should go to SA2 to defend their proposal. This was taken offline.
noted No    
    S3‑193965 Draft for ‘proposed structure for network slice security procedures’ InterDigital Communications draftCR Approval Yes
Yes
merged No S3‑194536  
    S3‑194045 Add content to Clause X.X.2 of eNS Huawei, HiSilicon draftCR Approval Yes
Yes
revised No S3‑194536  
    S3‑194536 Add content to Clause X.X.2 of eNS Huawei, HiSilicon,Nokia,Ericsson, Interdigital draftCR Approval Yes
Yes
approved No   S3‑194045
    S3‑194214 DraftCR - Proposed flow for clarifying primary authentication steps Ericsson draftCR Approval Yes
Yes
merged No S3‑194536  
    S3‑194058 Proposed text for clause x.2 of living CR for eNS Nokia, Nokia Shanghai Bell other Approval Yes
Yes
merged No S3‑194536  
    S3‑194046 Amendment to Clause X.X.3 of Slice specific authentication procedure Huawei, HiSilicon draftCR Approval Yes
YesDiscussed together with 212. Nokia: This is not aligned with SA2.how does roaming work? Unclear how Every AMF in the network gets to the AAA proxy. Huawei replied that this was an SA2 issue. Ericsson: this solution doesn’t work. Qualcomm: align the message names properly in all steps.
merged No S3‑194537  
    S3‑194212 DraftCR – Proposed call flow for Network Slice Specific Authentication and Authorization Ericsson draftCR Approval Yes
YesChina Mobile:NSSAI sent to the AAA server from network operator in step 7. NSSAI is a private part of the network's operator topology. Ericsson: this is needed in the AAA server for revocation procedures to work. Huawei disagreed, as there was alternative information that could be sent, some transformation of the information like done with the SUPI. Nokia was aligned with Ericsson. Nokia: no privacy sensitive information in the NSSAI today.
revised No S3‑194537  
    S3‑194537 DraftCR – Proposed call flow for Network Slice Specific Authentication and Authorization Ericsson,Huawei draftCR Approval Yes
Yes
approved No   S3‑194212
    S3‑194047 Note for the User ID privacy protection in Clause X.X.3 Huawei, HiSilicon draftCR Approval Yes
YesNokia disagreed with the note.Orange commented that it should be a recommendation and not mandatory. It was also discussed whether it had to be a note or not. MCC commented that notes were informative, and any normative language (recommendation or requirement) could not be used in them. It was agreed to make it plain text and have it as a recommendation.
revised No S3‑194538  
    S3‑194538 Note for the User ID privacy protection in Clause X.X.3 Huawei, HiSilicon draftCR Approval Yes
Yes
approved No   S3‑194047
    S3‑194048 Discussion on Authentication method negotiation Huawei, HiSilicon discussion Endorsement Yes
YesNokia,Qualcomm: we don’t need this.Ericsson agreed ith them, that if this was needed, it would be related to the AAA server.
noted No    
    S3‑194049 Authentication method negotiation Huawei, HiSilicon draftCR Approval Yes
Yes
noted No    
    S3‑194213 DraftCR - Proposed flow for Re-authentication and Re-authorization Ericsson draftCR Approval Yes
YesNokia: early to adopt this. Add an editor's note. Ericsson replied that SA3 needed to send these flows to SA2, so an editor's note may not be approriate. Huawei: reference to the SA2 document instead of copying the whole content from SA2. What if they update their part? Qualcomm agreed, no need to have a duplication in both groups since SA2 and SA3 could be updating the same text differently.The Chair agreed that this was a general problem and it needed to be discussed further. SA3 should make sure that work is not duplicated by communicating changes to SA2. This was taken offline.
revised No S3‑194539  
    S3‑194539 DraftCR - Proposed flow for Re-authentication and Re-authorization Ericsson draftCR Approval Yes
Yes
approved No   S3‑194213
    S3‑194215 DraftCR – Proposing a new AUSF service to support NSSAA flow Ericsson draftCR Approval Yes
YesThis depends on the outcome of the discussion on the AUSF involvement (LS in 535). Taken offline to address the
revised No S3‑194540  
    S3‑194540 DraftCR – Proposing a new AUSF service to support NSSAA flow Ericsson draftCR Approval Yes
Yes
approved No   S3‑194215
    S3‑194541 Living document on slice specific authentication procedures Nokia draftCR Approval No
Yes
left for email approval No    
7.14 Security for NR Integrated Access and Backhaul (Rel-16) S3‑194368 Requirements for Secure environment of the IAB node Samsung draftCR   Yes
YesEricsson, Orange: reference this clause from the annex.
revised No S3‑194594  
    S3‑194594 Requirements for Secure environment of the IAB node Samsung draftCR - Yes
Yes
approved No   S3‑194368
    S3‑194274 [Draft CR] Security requirements for F1 interface Ericsson draftCR Approval Yes
Yes
approved No    
    S3‑194275 [Draft CR] Security requirements on the IAB node, IAB donor and 5GC supporting IAB architecture Ericsson draftCR Approval Yes
YesQualcomm: IAB donor instead of parent IAB.
revised No S3‑194595  
    S3‑194595 [Draft CR] Security requirements on the IAB node, IAB donor and 5GC supporting IAB architecture Ericsson draftCR Approval No
Yes
approved No   S3‑194275
    S3‑194369 IAB-node integration procedure Samsung draftCR Approval Yes
YesNokia: phases are related to the deployment. Samsung replied that this was a security sequence and not related to the deployment phase. Orange agreed that this was confusing. Nokia added that additional text should be Samsung: this is not new, this is part of definitions given in RAN. MCC commented that the last paragraph didn’t seem appropriate for a general clause since it was introducing requirements. In addition to this, it looked like a requirement was given to the attackers as well.
revised No S3‑194597  
    S3‑194597 IAB-node integration procedure Samsung,Ericsson draftCR Approval Yes
Yes
approved No   S3‑194369
    S3‑194277 [Draft CR] General introduction to IAB-node Integration Procedure Ericsson draftCR Approval Yes
Yes
merged No S3‑194597  
    S3‑194371 IAB-UE part set-up procedure Samsung draftCR Approval Yes
Yes
revised No S3‑194598  
    S3‑194598 IAB-UE part set-up procedure Samsung,Ericsson draftCR Approval Yes
Yes
approved No   S3‑194371
    S3‑194278 [Draft CR] Authentication of IAB nodes Ericsson draftCR Approval Yes
Yes
merged No S3‑194598  
    S3‑194279 [Draft CR] Authorization of IAB nodes Ericsson draftCR Approval Yes
Yes
merged No S3‑194598  
    S3‑194276 [Draft CR] Security mechanisms for the F1 interface between the IAB-node (gNB-DU) and the IAB-donor-CU Ericsson draftCR Approval Yes
Yes
noted No    
    S3‑194373 F1 interface set-up procedure Samsung draftCR Approval Yes
Yes
noted No    
    S3‑194280 [Draft CR] Update of general introduction to IAB Ericsson draftCR Approval Yes
Yes
approved No    
    S3‑194281 Draft CR - Security for Integrated Access and Backhaul in EN-DC Ericsson draftCR Approval Yes
Yes
merged No S3‑194599  
    S3‑194375 Solution for IAB Architecture Samsung draftCR Approval Yes
YesORANGE: Requirements for subscription credential storage are not in TS 33.401 but in a CT spec. This was taken offline.
revised No S3‑194599  
    S3‑194599 Solution for IAB Architecture Samsung .Ericsson draftCR Approval Yes
Yes
approved No   S3‑194375
    S3‑194417 [Draft CR]Solution for IAB Architecture (Baseline version) Samsung draftCR Approval Yes
Yes
revised No S3‑194596  
    S3‑194596 [Draft CR]Solution for IAB Architecture (Baseline version) Samsung draftCR Approval No
Yes
left for email approval No   S3‑194417
7.15 Security aspects of SEAL (Rel-16) S3‑194387 Skeleton for SEAL TS 33.434 Samsung pCR Approval Yes
YesMotorola proposed some changes in the structure of the TS.
revised No S3‑194627  
    S3‑194627 Skeleton for SEAL TS 33.434 Samsung pCR Approval Yes
Yes
approved No   S3‑194387
    S3‑194388 Scope for SEAL TS 33.434 Samsung pCR Approval Yes
YesTim (Motorola) suggested to add more wording to extend the scope.
revised No S3‑194628  
    S3‑194628 Scope for SEAL TS 33.434 Samsung pCR Approval Yes
Yes
approved No   S3‑194388
    S3‑194389 Adding reference, term, abbreviation to the SEAL TS 33.434 Samsung pCR Approval Yes
Yes
revised No S3‑194629  
    S3‑194629 Adding reference, term, abbreviation to the SEAL TS 33.434 Samsung pCR Approval Yes
Yes
approved No   S3‑194389
    S3‑194390 Security requirements for SEAL Samsung pCR Approval Yes
YesOrange: differences between the different services written here? They seem to be three different services. The VAL service is not defined. Motorola provided a few more comments that had to be taken offline.
revised No S3‑194631  
    S3‑194631 Security requirements for SEAL Samsung pCR Approval Yes
Yes
approved No   S3‑194390
    S3‑194391 Security for SEAL interfaces Samsung pCR Approval Yes
YesMotorola asked to add an editor's note on additional references needed to align with the SA6 specification.The terminology also needed to be aligned with the SA6 architecture.
revised No S3‑194632  
    S3‑194632 Security for SEAL interfaces Samsung pCR Approval Yes
Yes
approved No   S3‑194391
    S3‑194392 VAL user authentication and authorization Samsung pCR Approval Yes
YesHuawei commented that this was quite a large content and asked to have more time to review it properly. Motorola also had numerous comments. Samsung replied that they would bring back this and the following contributions for the next meeting (addressing the comments from the companies).
noted No    
    S3‑194393 Security procedure for S-KMC and S-KMS Samsung pCR Approval Yes
Yes
noted No    
    S3‑194394 Annex X: OpenID Connect Samsung pCR Approval Yes
Yes
noted No    
    S3‑194395 Annex Y for TS 33.434 Samsung pCR Approval Yes
Yes
noted No    
    S3‑194630 Draft TR 33.434 Samsung draft TS Approval Yes
Yes
approved No    
7.16 Security Aspects of 3GPP support for Advanced V2X Services (Rel-16) S3‑193939 LS on PC5-S Signaling and PC5-RRC connection for NR sidelink communication R2-1914151 LS in   Yes
Yes
noted No    
    S3‑194248 pCR for eV2X TS Ericsson pCR Approval Yes
Yes
merged No S3‑194613  
    S3‑194312 Proposed text for the early clauses for V2X TS Qualcomm Incorporated, LG Electronics other Approval Yes
Yes
approved No    
    S3‑194614 Proposed text for the early clauses for V2X TS Qualcomm Incorporated, LG Electronics other Approval No
Yes
withdrawn Yes    
    S3‑194313 Proposed text for security for V2X over Uu reference point clause Qualcomm Incorporated, LG Electronics other Approval Yes
Yes
revised No S3‑194615  
    S3‑194615 Proposed text for security for V2X over Uu reference point clause Qualcomm Incorporated, LG Electronics,Ericsson other Approval Yes
Yes
approved No   S3‑194313
    S3‑194314 Proposed inclusion of groupcast and broadcast privacy solutions Qualcomm Incorporated, LG Electronics other Approval Yes
Yes
revised No S3‑194613  
    S3‑194613 Proposed inclusion of groupcast and broadcast privacy solutions Qualcomm Incorporated, LG Electronics,Ericsson other Approval Yes
Yes
approved No   S3‑194314
    S3‑194605 Notes on the V2X offline session NTT-Docomo report Information Yes
Yes
noted No    
    S3‑194625 Draft TS 33.xyz on V2X Lge other Approval No
Yes
left for email approval No    
7.17 User Plane Gateway Function for Inter-PLMN Security (Rel-16) S3‑194399 Source IP address range check for UPGF Nokia, Nokia Shanghai Bell draftCR Approval Yes
YesJuniper networks: remove "that intercepts outgoing GTP-U traffic originated from a UPF". Ericsson added that in fact the whole paragraph was not needed. Docomo: which source address are you referring to? This was taken offline.
revised No S3‑194463  
    S3‑194463 Source IP address range check for UPGF Nokia, Nokia Shanghai Bell draftCR Approval No
Yes
merged No S3‑194443 S3‑194399
    S3‑194397 UPGF - Align with Inter PLMN UP Security Function (IPUPS) Nokia, Nokia Shanghai Bell draftCR Approval Yes
YesHuawei, Juniper: bring back the first sentence. Docomo: don’t change the acronym. This was finally noted.
noted No    
7.18 Provision of Access to Restricted Local Operator Services by Unauthenticated UEs – Security Aspects (Rel-16) S3‑194337 Security aspects of RLOS Qualcomm Incorporated CR Agreement Yes
YesNokia: delete "manufactring time" from step 3. Vodafone: "where RLOS are supported"? Qualcomm replied that it referred to the regions where RLOS was supported. ORANGE commented on step 3 that the integrity of the white list was not ensured. It was agreed to bring back the manufacturing time and make it more strict. Orange: what is "valid USIM" in step 4? Qualcomm replied that if there is a USIM present with a ISIM that matches the MCC. It was agreed to remove "valid".
revised No S3‑194633  
    S3‑194633 Security aspects of RLOS Qualcomm Incorporated CR Agreement Yes
YesThe last sentence on the whitelist had to be discussed internally in MCC. If necessary, it would be modified in the next SA plenary directly.
agreed No   S3‑194337
7.19 Other work areas                      
7.19.1 SAE/LTE Security S3‑193968 33401-CR on CHO key derivation Apple CR Approval Yes
YesDepending on the discussion for 448.
revised No S3‑194602  
    S3‑194602 33401-CR on CHO key derivation Apple CR Approval Yes
Yes
not pursued No   S3‑193968
7.19.2 IP Multimedia Subsystem (IMS) Security                      
7.19.3 Network Domain Security (NDS)                      
7.19.4 UTRAN Network Access Security                      
7.19.5 GERAN Network Access Security                      
7.19.6 Generic Authentication Architecture (GAA)                      
7.19.7 Security Aspects of Home(e)NodeB (H(e)NB)                      
7.19.8 Mission Critical (MCPTT, MCSec, eMCSec, MONASTERY_SEC) S3‑193923 [MCPTT] 33179 R13 Missing Abbreviations Airbus CR Agreement Yes
Yes
agreed No    
    S3‑193920 [MCSec] 33180 R14 Missing Abbreviations Airbus CR Agreement Yes
Yes
agreed No    
    S3‑193917 [eMCSec] 33180 R15 Missing Abbreviations (Mirror) Airbus CR Agreement Yes
Yes
agreed No    
    S3‑193993 [33.180] R14 - Fix bad reference Motorola Solutions UK Ltd. CR Agreement Yes
Yes
agreed No    
    S3‑193994 [33.180] R15 Fix bad reference (mirror) Motorola Solutions UK Ltd. CR Agreement Yes
Yes
agreed No    
    S3‑193924 [MCPTT] 33179 R13 Reference Addition Airbus CR Agreement Yes
Yes
agreed No    
    S3‑193921 [MCSec] 33180 R14 Reference Addition (Mirror) Airbus CR Agreement Yes
Yes
agreed No    
    S3‑193918 [eMCSec] 33180 R15 Reference Addition (Mirror) Airbus CR Agreement Yes
Yes
agreed No    
    S3‑193925 [MCPTT] 33179 R13 Correction concerning IdM client Airbus CR Agreement Yes
Yes
agreed No    
    S3‑193922 [MCSec] 33180 R14 Correction concerning IdM client (Mirror) Airbus CR Agreement Yes
Yes
agreed No    
    S3‑193919 [eMCSec] 33180 R15 Correction concerning IdM client (Mirror) Airbus CR Agreement Yes
Yes
agreed No    
7.19.9 Security Assurance Specifications (SCAS-SA3, SCAS_PGW, SCAS_eNB) S3‑194299 33.216 Corrections for clean-up and alignment R15 Nokia, Nokia Shanghai Bell CR Approval Yes
YesFuturewei disagreed with the removal of the test cases since those were being used. China Mobile: why removing 4.2.7? We care about the functional requirements. Futurewei preferred not to see editor's notes and it was asked to minute that the execution steps for Uu reference point in the test case in sub-clause 4.2.2.1.3 needed to be added.
revised No S3‑194480  
    S3‑194480 33.216 Corrections for clean-up and alignment R15 Nokia, Nokia Shanghai Bell CR Approval Yes
Yes
agreed No   S3‑194299
    S3‑194300 33.216 Corrections for clean-up and alignment R16 Nokia, Nokia Shanghai Bell CR Approval Yes
YesNokia asked to minute the following comment: "The execution steps for Uu reference point in the test case in sub-clause 4.2.2.1.3 need to be added."
revised No S3‑194481  
    S3‑194481 33.216 Corrections for clean-up and alignment R16 Nokia, Nokia Shanghai Bell CR Approval Yes
Yes
agreed No   S3‑194300
7.19.10 Security Aspects of Narrowband IOT (CIoT) S3‑193938 Reply LS on Handling of UE radio network capabilities in 4G and 5G R2-1911850 LS in   Yes
Yes
replied to No    
    S3‑194075 Reply LS on Handling of UE radio network capabilities in 4G and 5G Intel Corporation (UK) Ltd LS out   Yes
YesQualcomm and Huawei agreed with this reply. Qualcomm added that it should be mentioned that SA3 was still studying this issue. This had to be taken offline as Nokia had issues with the reply to question 1.
revised No S3‑194488  
    S3‑194488 Reply LS on Handling of UE radio network capabilities in 4G and 5G Intel Corporation (UK) Ltd LS out - Yes
Yes
approved No   S3‑194075
    S3‑194241 DRAFT Reply LS on Handling of UE radio network capabilities in 4G and 5G Ericsson LS out Approval Yes
Yes
noted No    
    S3‑194243 Security of RRC UE capability transfer procedure in EPS Ericsson CR Approval Yes
YesQualcomm: release 16 new feature, so we should wait for the results of the study to be completed. Ericsson: EPS is not part of the study, this is a different issue. Nokia: this is something new for legacy (LTE) Ues. Qualcomm: we want the same mechanism as 5G in here, but let's wait until the study is finished. Huawei agreed with this.
not pursued No    
    S3‑194244 RRC Connection Resume and Suspend procedures Ericsson CR Approval Yes
YesNokia wanted to add more text to make it clear. They agreed with the change. Ericsson didn’t find this necessary. Nokia promised to bring a CR next time to propose
agreed No    
    S3‑194245 RRC Connection Resume and Suspend procedures Ericsson CR Approval Yes
Yes
agreed No    
7.19.11 EPC enhancements to support 5G New Radio via Dual Connectivity (EDCE5)                      
7.19.12 Northbound APIs Security for SCEF - SCS/AS Interworking (NAPS_Sec) (Rel-15)                      
7.19.13 Security Aspects of Common API Framework for 3GPP Northbound APIs (CAPIF_Sec) (Rel-15)                      
7.19.14 PLMN RAT selection (Steering of Roaming) (Rel-15) S3‑193931 LS on Clarification on the requirement for steering of roaming C1-197001 LS in   Yes
YesNo action for SA3.
noted No    
7.19.15 Battery Efficient Security for very low Throughput Machine Type Communication Devices (BEST_MTC_Sec) (Rel-15)                      
7.19.16 Other work items S3‑194263 Certificate and CRL profile update Ericsson CR Agreement Yes
YesHuawei asked these group of CRs to be postponed for the next meeting. MCC commented that the notes were not appropriate as they were predicting the prohibition of features in future 3GPP releases.
not pursued No    
    S3‑194264 TLS Recommended Cipher Suites Ericsson CR Agreement Yes
Yes
not pursued No    
    S3‑194265 Required TLS extenstions and algorithms Ericsson CR Agreement Yes
Yes
not pursued No    
    S3‑194266 IKEv2 profile update 33.210 Ericsson CR Agreement Yes
Yes
not pursued No    
    S3‑194267 IKEv2 profile update 33.310 Ericsson CR Agreement Yes
Yes
not pursued No    
    S3‑194268 Using EAP-TLS with TLS 1.3 Ericsson CR Agreement Yes
YesOrange commented that Annex B was informative so the normative text could not be ntroduced here.
not pursued No    
7.20 New work item proposals S3‑193913 New WID on Security Aspects of PARLOS SPRINT Corporation WID new Agreement Yes
Yes
revised No S3‑194525  
    S3‑194525 New WID on Security Aspects of PARLOS SPRINT Corporation WID new Agreement Yes
Yes
agreed No   S3‑193913
    S3‑193979 New WID on eV2X security LG Electronics Inc. WID new Approval Yes
Yes
revised No S3‑194468  
    S3‑194468 New WID on eV2X security LG Electronics Inc. WID new Approval Yes
YesORANGE: the requirements in TR 33.836 are potential, don’t refer to this TR and stick to the TS as a base. Editorial comments from MCC.
agreed No   S3‑193979
    S3‑193982 Skeleton for TS on eV2X LG Electronics Inc. discussion Agreement Yes
YesHuawei: 5.2.2 gives the impression that the privacy requirements are the most important. They are part of the security requirements. Article19 objected to removing privacy from the tile of clause 5.2.2. Huawei didn’t agree with keeping it in the title.
revised No S3‑194526  
    S3‑194526 Skeleton for TS on eV2X LG Electronics Inc. other Approval Yes
Yes
approved No   S3‑193982
    S3‑194180 New WID: Work Item on Security Assurance Specification for IMS Huawei, Hisilicon WID new Approval Yes
YesORANGE: why excluding the IMS Access Gateway from the scope of the WID? Huawei commented that they were open to other network elements. It was agreed to generalize this. It was clarified that this affected Release 17 (wrong templated used for this WID). Nokia: SCAS for 5G or LTE? In SA2 they are working on IMS for 5G. ORANGE: this is SCAS for the previous Release, as we always do. This is SCAS for Release 15.
revised No S3‑194527  
    S3‑194527 New WID: Work Item on Security Assurance Specification for IMS Huawei, Hisilicon WID new Approval Yes
Yes
agreed No   S3‑194180
    S3‑194269 New WID on 3GPP profiles for cryptographic algorithms and IETF protocols Ericsson WID new Agreement Yes
YesQualcomm: remove PFS objective and justification. NCSC: bullets look like key issues or solutions rather than objectives. Ericsson clarified that there were CRs for this meeting already, but with the WID TEI16 (to be changed to DUMMY).
revised No S3‑194528  
    S3‑194528 New WID on 3GPP profiles for cryptographic algorithms and IETF protocols Ericsson WID new Agreement Yes
Yes
agreed No   S3‑194269
8 Studies                      
8.1 Study on Security Aspects of the 5G Service Based Architecture S3‑194167 eSBA: conclusion update on KI #22 Huawei, Hisilicon pCR Approval Yes
Yes
noted No    
    S3‑194380 Discussion paper on authorization for Model D Indirect communications Nokia, Nokia Shanghai Bell discussion Agreement Yes
Yes
noted No    
    S3‑194382 Update to conclusion on Key issue #22: Authorization of NF service access in indirect communication Nokia, Nokia Shanghai Bell pCR Approval Yes
Yes
noted No    
    S3‑194255 Update to conclusion on Key issue #23: NF to NF authentication and authorization in Indirect communication Ericsson pCR Approval Yes
Yes
noted No    
    S3‑194504 Update to conclusion on Key issue #23: NF to NF authentication and authorization in Indirect communication Ericsson pCR Approval No
Yes
withdrawn Yes    
    S3‑194194 Security requirement on Key Issue #24: service access authorization of a NF Set Huawei, Hisilicon pCR Approval Yes
Yes
revised No S3‑194505  
    S3‑194505 Security requirement on Key Issue #24: service access authorization of a NF Set Huawei, Hisilicon pCR Approval Yes
Yes
approved No   S3‑194194
    S3‑194192 Evaluation on service access authorization of a NF Set in non-roaming scenario Huawei, Hisilicon pCR Approval Yes
Yes
revised No S3‑194506  
    S3‑194506 Evaluation on service access authorization of a NF Set in non-roaming scenario Huawei, Hisilicon pCR Approval Yes
Yes
approved No   S3‑194192
    S3‑194193 Evaluation on service access authorization of a NF Set in roaming scenario Huawei, Hisilicon pCR Approval Yes
Yes
revised No S3‑194507  
    S3‑194507 Evaluation on service access authorization of a NF Set in roaming scenario Huawei, Hisilicon pCR Approval Yes
Yes
approved No   S3‑194193
    S3‑194186 Conclusion on service access authorization of a NF Set Huawei, Hisilicon pCR Approval Yes
Yes
revised No S3‑194508  
    S3‑194508 Conclusion on service access authorization of a NF Set Huawei, Hisilicon pCR Approval Yes
Yes
approved No   S3‑194186
    S3‑194425 Update on solution#15 in TR 33.855 Huawei, Hisilicon pCR Approval Yes
Yes
revised No S3‑194509 S3‑194183
    S3‑194509 Update on solution#15 in TR 33.855 Huawei, Hisilicon pCR Approval Yes
Yes
approved No   S3‑194425
    S3‑194185 Conclusion on authorization in the delegated Subscribe-Notify interaction scenarios Huawei, Hisilicon pCR Approval Yes
Yes
noted No    
    S3‑194253 Conclusion of Key Issue #28: Service access authorization in the delegated "Subscribe-Notify" scenarios Ericsson pCR Approval Yes
Yes
noted No    
    S3‑194165 New KI: Service access authorization for non-delegated subscribe-notify Huawei, Hisilicon pCR Approval Yes
Yes
revised No S3‑194510  
    S3‑194510 New KI: Service access authorization for non-delegated subscribe-notify Huawei, Hisilicon pCR Approval Yes
Yes
approved No   S3‑194165
    S3‑194182 New solution for authorization in the non-delegated "Subscribe-Notify" interaction scenarios Huawei, Hisilicon pCR Approval Yes
Yes
revised No S3‑194511  
    S3‑194511 New solution for authorization in the non-delegated "Subscribe-Notify" interaction scenarios Huawei, Hisilicon pCR Approval Yes
Yes
approved No   S3‑194182
    S3‑194184 Conclusion on authorization in the non-delegated Subscribe-Notify interaction scenarios Huawei, Hisilicon pCR Approval Yes
Yes
noted No    
    S3‑194168 eSBA: conclusion update on KI #29 Huawei, Hisilicon pCR Approval Yes
Yes
revised No S3‑194512  
    S3‑194512 eSBA: conclusion update on KI #29 Huawei, Hisilicon pCR Approval No
Yes
noted No   S3‑194168
    S3‑194258 New Key issue on NF subtypes for authorization granularity Ericsson pCR Approval Yes
Yes
revised No S3‑194513  
    S3‑194513 New Key issue on NF subtypes for authorization granularity Ericsson pCR Approval No
Yes
noted No   S3‑194258
    S3‑194259 Update of Solution #32: OAuth 2.0 based resource level authorization of NF service consumers Ericsson pCR Approval Yes
Yes
noted No    
    S3‑194260 Conclusion on NF subtypes for authorization granularity Ericsson pCR Approval Yes
Yes
noted No    
    S3‑194166 eSBA: add conclusion on KI #5 Huawei, Hisilicon pCR Approval Yes
Yes
noted No    
    S3‑194254 Conclusion for Key Issue #5 "NF-NF Authorization" Ericsson pCR Approval Yes
Yes
revised No S3‑194514  
    S3‑194514 Conclusion for Key Issue #5 "NF-NF Authorization" Ericsson pCR Approval No
Yes
noted No   S3‑194254
    S3‑194257 Removal of Editor's Notes for Security of indirect communication in roaming scenarios Ericsson pCR Approval Yes
Yes
revised No S3‑194515  
    S3‑194515 Removal of Editor's Notes for Security of indirect communication in roaming scenarios Ericsson pCR Approval No
Yes
approved No   S3‑194257
    S3‑194183 Update on solution#15 in TR 33.855 Huawei, Hisilicon pCR Approval Yes
Yes
revised No S3‑194425  
    S3‑194503 Notes from the eSBA break out session NTT-Docomo report Information Yes
Yes
noted No    
    S3‑194516 Draft TR 33.855 Ericsson draft TR Approval No
Yes
left for email approval No    
8.2 Study on Authentication and key management for applications based on 3GPP credential in 5G S3‑193984 Update to Key Issue #6 KPN, China Mobile pCR Approval Yes
Yes
approved No    
    S3‑194209 Conclusion on end to end security China Mobile, KPN pCR Approval Yes
YesEricsson: you are proposing an informative annex for normative work. KPN: we want it normative and if this is not agreed it would become informative. Vodafone: this text is not an evaluation or a conclusion. Qualcomm: this is not part of AKMA. It's pat of the interface between UE and application function. This had to be taken offline.
revised No S3‑194636  
    S3‑194636 Conclusion on end to end security China Mobile, KPN pCR Approval Yes
Yes
approved No   S3‑194209
    S3‑194273 Conclusions on Key Management Ericsson pCR Approval Yes
YesChina Mobile: The case of the reauthentication being not successful is not clear to me. Ericsson replied that this wasn't a reauthentication but another authentication decided by the network, a subsequent authentication. Huawei didn’t agree with this. Taken offline.
revised No S3‑194637  
    S3‑194637 Conclusions on Key Management Ericsson pCR Approval No
Yes
approved No   S3‑194273
    S3‑194170 Editoral changes on solution for AKMA change Huawei, Hisilicon pCR Approval Yes
YesEricsson: make sure to mention all ocurrences of security contexts here.
revised No S3‑194638  
    S3‑194638 Editoral changes on solution for AKMA change Huawei, Hisilicon pCR Approval Yes
Yes
approved No   S3‑194170
    S3‑194171 Resolving the editor’s notes in the solution of AKMA change Huawei, Hisilicon pCR Approval Yes
YesQualcomm didn’t agree with this evaluation. No need for two PUSH solutions since SA3 had already a GBA Push work item ongoing. Vodafone supported this.
noted No    
    S3‑194172 AKMA: add conclusion on KI #17 Huawei, Hisilicon pCR Approval Yes
YesTaken offline whether it will have one or two Push solutions.
noted No    
    S3‑194639 AKMA: add conclusion on KI #17 Huawei, Hisilicon pCR Approval No
Yes
withdrawn Yes    
    S3‑194210 Add abbreviations and editorial changes to TR 33.835 China Mobile pCR Approval Yes
Yes
approved No    
    S3‑194217 Cover sheet TR 33.835 for approval China Mobile TS or TR cover Approval Yes
YesVodafone objected sending this document for approval during the current meeting. The document was clashing with other existing specs and Vodafone needed more time to evaluate the TR. China Mobile commented that the completion was above 80% already. Vodafone added that the specification needed to go to EditHelp as well. Vodaone had a sustained objection. They were the only one. NTT-Docomo: there are numerous editor's notes and this should be mentioned in the outstanding issues. Orange: write cleanup in the outstanding issues. Mauro (TIM): if the group agrees on a needed cleanup what's the rush for sending this now instead of the next meeting? China Mobile: SA should know that we have done 80% of the work. BT found it better to delay and joined Vodafone. The Chair commented that the next meeting would focus especially on normative work and that the group would be under a lot of pressure to finish release 16.
revised No S3‑194695  
    S3‑194695 Cover sheet TR 33.835 for approval China Mobile TS or TR cover Approval No
YesNTT-Docomo commented that they preferred not to spend more time discussing this and send it for approval. Qualcomm: it is clearly more than 80% completed. Lenovo supported sending this for approval. Nokia: let's focus on the TS. ZTE supported sending it for approval. Sending the TR for approval, show of hands: Vodafone objected. Support sending it for approval: Ericsson Apple, ZTE, Huawei,KPN,Lenovo,Qualcomm, Nokia,China Mobile. The Chair decided to send it for approval anyway but warned the delgates that Vodafone could object in plenary and in that case it would be probably brought back to SA3.
approved No   S3‑194217
    S3‑193983 Update to Key Issue #6 KPN, China Mobile pCR Approval No
Yes
withdrawn Yes    
    S3‑194216 Cover sheet TR 33.835 China Mobile International Ltd TS or TR cover Approval No
Yes
withdrawn Yes    
    S3‑194635 Draft TR 33.835 China Mobile draft TR Approval No
Yes
left for email approval No    
8.3 Study on Evolution of Cellular IoT security for the 5G System S3‑194240 Removal of three obsolete Editor’s Notes Ericsson pCR Approval Yes
Yes
approved No    
    S3‑193991 KI 14 Potential Security Requirement NIST, ATT, Sprint Corporation, CableLabs, Deutsche Telekom AG, Cisco pCR Approval Yes
YesEricsson: data format is not security related. NIST: the key issue is on communication in the user plane and prevent any communication that falls outside that scope. Ericsson: we assumed that this key issue should be left without security requirements, and concluded since there is a lot more to be evaluated; the study has continued for way too long.
revised No S3‑194490  
    S3‑194490 KI 14 Potential Security Requirement NIST, ATT, Sprint Corporation, CableLabs, Deutsche Telekom AG, Cisco pCR Approval Yes
YesReivsed to re-formulate the security requirement.
approved No   S3‑193991
    S3‑194080 Updates to Key issue Protection of UE capability transfer for UEs without AS security Intel Corporation (UK) Ltd pCR   Yes
Yes080,087,238,324 overlap in this issue.
revised No S3‑194491  
    S3‑194491 Updates to Key issue Protection of UE capability transfer for UEs without AS security Intel Corporation (UK) Ltd,Qualcomm,Huawei,Ericsson pCR - Yes
Yes
approved No   S3‑194080
    S3‑194087 Add the threat and requirement in KI#15 Huawei, Hisilicon pCR Approval Yes
Yes
merged No S3‑194491  
    S3‑194238 KI#15 - new requirement for handling UEs without AS security Ericsson pCR Approval Yes
YesQualcomm: requirement too vague.
merged No S3‑194491  
    S3‑194324 Security Requirement for KI #15 Qualcomm Incorporated pCR Approval Yes
Yes
merged No S3‑194491  
    S3‑193992 New Solution for KI #14 NIST, ATT, Sprint, CableLabs, Deutsche Telekom AG, Cisco pCR Approval Yes
YesEricsson: several editor's notes are needed since this solution is not complete: how it fits into the 3GPP network, how it interacts with the 3GPP elements. Huawei: remove the evaluation part, as it should be evaluated in SA2. Ericsson was also sceptical about this solution as it would require a lot of work and the timeline would not allow to fully study this part. Qualcomm: SA2 study is in Release 17 and this is for Release 16.
revised No S3‑194492  
    S3‑194492 New Solution for KI #14 NIST, ATT, Sprint, CableLabs, Deutsche Telekom AG, Cisco pCR Approval Yes
Yes
approved No   S3‑193992
    S3‑194088 Protection of UE capability transfer for CP optimization only CIoT UE Huawei, Hisilicon pCR Approval Yes
YesNokia: System impact, on the NAS protocol, UE capability exchange, etc..An editor's note was added about this. Qualcomm, Ericsson had issue with the evaluation part. This was taken offline.
revised No S3‑194493  
    S3‑194493 Protection of UE capability transfer for CP optimization only CIoT UE Huawei, Hisilicon pCR Approval Yes
Yes
approved No   S3‑194088
    S3‑194079 Security solution for UE Capability Transfer for UE with no AS security. Intel Corporation (UK) Ltd pCR   Yes
YesNokia: this changes the behaviour of the base station. Ericsson: this procedure between the RAN and the core network is totally new. Intel agreed to add an editor's note on this.
revised No S3‑194494  
    S3‑194494 Security solution for UE Capability Transfer for UE with no AS security. Intel Corporation (UK) Ltd pCR - Yes
YesRemoving steps 1-3. Editor's note on the new call flow RAN- core network. Evaluation was removed as proposed by Qualcomm.
approved No   S3‑194079
    S3‑194325 AMF verification of the UE radio capabilities for CP optimization only CIoT UE Qualcomm Incorporated pCR Approval Yes
YesIntel: Hash seems to be sent in the initial request in an open message, add an editor's note. Qualcomm replied that it was mandatorily protected. Ericsson: step 3 might happen before step 2, not ensured that steps happen in this order. This was taken offline.
revised No S3‑194495 S3‑193391
    S3‑194495 AMF verification of the UE radio capabilities for CP optimization only CIoT UE Qualcomm Incorporated pCR Approval Yes
Yes
approved No   S3‑194325
    S3‑194239 KI#15 - new solution for handling UEs without AS security Ericsson pCR Approval Yes
YesQualcomm: this doesn't mitigate the threat. Intel agreed with Qualcomm. Qualcomm: UE capability never verified by the network.
approved No    
    S3‑194496 KI#15 - new solution for handling UEs without AS security Ericsson pCR Approval No
Yes
withdrawn Yes    
    S3‑194326 Hash based UE capability protection for CP optimization only CIoT UE Qualcomm Incorporated pCR Approval Yes
YesIntel: in the Power ON scenario the initial registration request is sending the hash unprotected.. Ericsson: what happens if there is a mismatch? Huawei also had some issues, so these comments were taken offline.
revised No S3‑194497 S3‑193390
    S3‑194497 Hash based UE capability protection for CP optimization only CIoT UE Qualcomm Incorporated pCR Approval Yes
Yes
approved No   S3‑194326
    S3‑194235 Proposed conclusion to KI#1 Ericsson pCR Approval Yes
Yes
revised No S3‑194498  
    S3‑194498 Proposed conclusion to KI#1 Ericsson pCR Approval Yes
Yes
approved No   S3‑194235
    S3‑194234 Proposed revision of conclusion to KI#2 Ericsson pCR Approval Yes
Yes
approved No    
    S3‑194233 Proposed conclusion to KI#3 Ericsson pCR Approval Yes
Yes
approved No    
    S3‑194246 Proposed conclusion to KI #14 Ericsson pCR Approval Yes
YesLeft open since it depended on the discussion about key issue 14.
revised No S3‑194604  
    S3‑194604 Proposed conclusion to KI #14 Ericsson pCR Approval Yes
Yes
approved No   S3‑194246
    S3‑194077 Conclusion for Key issue 15 Intel Corporation (UK) Ltd pCR   Yes
Yes
noted No    
    S3‑194489 draft TR 33.861 Ericsson draft TR Approval No
YesThe Chair asked if this could be sent for approval. Ericsson replied that only one key issue was left and it would be ready for the next meeting.
left for email approval No    
8.4 Study on 5G security enhancement against false base stations S3‑194208 Updates to solution #17 - resolving Ens Ericsson pCR Approval Yes
YesOrange: confused with the terminology ("newer network?), add an editor's note about that. Get rid of the shalls, the evaluation should be removed. The network negotiation to support the feature is FFS.
revised No S3‑194668  
    S3‑194668 Updates to solution #17 - resolving Ens Ericsson pCR Approval Yes
Yes
approved No   S3‑194208
    S3‑194107 Conclusion for RRC Resume Request Protection Huawei, Hisilicon pCR Approval Yes
YesOrange,Samsung, Qualcomm objected to this conclusion.
noted No    
    S3‑194202 Updates to solution #7 - capability negotiation Ericsson pCR Approval Yes
Yes
revised No S3‑194667  
    S3‑194667 Updates to solution #7 - capability negotiation Ericsson pCR Approval Yes
Yes
approved No   S3‑194202
    S3‑194203 Updates to solution #7 - network sharing Ericsson pCR Approval Yes
Yes
noted No    
    S3‑194682 Updates to solution #7 - network sharing Ericsson pCR Approval No
Yes
withdrawn Yes    
    S3‑194204 Updates to solution #7 - signature schemes and length Ericsson pCR Approval Yes
YesOrange: the ETSI SAGE sentences should be removed.
revised No S3‑194683  
    S3‑194683 Updates to solution #7 - signature schemes and length Ericsson pCR Approval Yes
Yes
approved No   S3‑194204
    S3‑194109 Evaluation for solution #7 Huawei, Hisilicon pCR Approval Yes
Yes
noted No    
    S3‑194328 Evaluation on UE behavior on detection of false signature Qualcomm Incorporated pCR Approval Yes
Yes
noted No   S3‑193363
    S3‑194329 Evaluation on signing key management Qualcomm Incorporated pCR Approval Yes
Yes
noted No   S3‑193364
    S3‑194028 5GFBS-Update for solution#11 Apple pCR Approval Yes
Yes
revised No S3‑194685  
    S3‑194685 5GFBS-Update for solution#11 Apple pCR Approval Yes
YesRemoving the editor's note on legacy USIMs.
approved No   S3‑194028
    S3‑194327 Shared key based MIB/SIBs integrity information provided by gNB Qualcomm Incorporated pCR Approval Yes
Yes
revised No S3‑194686 S3‑193361
    S3‑194686 Shared key based MIB/SIBs integrity information provided by gNB Qualcomm Incorporated pCR Approval Yes
Yes
approved No   S3‑194327
    S3‑193975 5GFBS-conclusion of key issue#2 Apple pCR Approval Yes
YesOverlapping with 062,108, 339. There was no consensus for a way forward for key issue 2. Orange commented that the solutions of these documents had numerous security issues. The Chair asked who supported and who objected every solution: 395: Apple,Ericsson, Samsung, Commscope Objection: Orange, Qualcomm 4062: CableLabs, Apple, Samsung,Intel,BT,Commscope,Ericsson Objections: Orange, Qualcomm 108: Huawei, Qualcomm Objection: Orange,CalbleLabs,Ericsson, Commscope, Apple 339: Qualcomm, Huawei,Nokia,Deutsche Telekom,Orange Objection: Apple, Ericsson, CableLabs
noted No    
    S3‑194062 Way forward on key issue 2 in TR 33.809 CableLabs discussion Endorsement Yes
Yes
noted No    
    S3‑194108 Conclusion for Key Issue #2 Huawei, Hisilicon pCR Approval Yes
Yes
noted No    
    S3‑194339 Proposed way forward for KI#2 in TR 33.809 Qualcomm Incorporated discussion Endorsement Yes
Yes
noted No    
    S3‑193940 LS to SA3 on False Base Station Detection R3-196256 LS in   Yes
Yes
noted No    
    S3‑193941 Reply LS to SA3 on FBS detection R2-1914224 LS in   Yes
Yes
postponed No    
    S3‑194206 [DRAFT] Reply LS on false base station detection Ericsson LS out Approval Yes
Yes
merged No S3‑194687  
    S3‑194033 Reply LS to RAN2 on FBS detection Huawei, HiSilicon LS out Approval Yes
YesQualcomm: we don’t have the detailed answers for these questions. We need to estabilise the solutions before we can answer to RAN2. Futurewei: if we postpone this we don’t get any progress until the July meeting next year. Apple: work on this offline and we may agree on an answer fr this meeting.
revised No S3‑194687  
    S3‑194687 Reply LS to RAN2 on FBS detection Huawei, HiSilicon LS out Approval No
Yes
noted No   S3‑194033
    S3‑194032 Update solution 4 to clarify MIB/SIB Hash report Huawei, HiSilicon pCR Approval Yes
YesTaken offline to keep note 3 and try to reach an agreement with Qualcomm.
revised No S3‑194688  
    S3‑194688 Update solution 4 to clarify MIB/SIB Hash report Huawei, HiSilicon pCR Approval Yes
Yes
approved No   S3‑194032
    S3‑194330 Solution #4 Evaluation (Enriched MR) Qualcomm Incorporated pCR Approval Yes
YesHuawei didn’t agree with the text. This is talking only about the detection part. Ericsson didn’t agree either.
noted No   S3‑193365
    S3‑194034 Preventing UE from Connecting to FBSs Huawei, HiSilicon pCR Approval Yes
YesEricsson: this solution is not needed. This will introduce significant delay and cause the handover procedure to fail. Samsung supported this.
noted No    
    S3‑194035 Preventing UE from reselecting to FBS Huawei, HiSilicon pCR Approval Yes
YesNot needed, as it doesn’t adress the key issue properly. Orange: if the message coming from the network to the UE is not delivered for any reason, the UE cannot know that the message was intended to be sent. The UE doesn’t expect this message. You just need as an attacker to prevent the delivery of this message to the UE.
noted No    
    S3‑194036 Handover UE under MitM FBS attacks Huawei, HiSilicon pCR Approval Yes
YesEricsson: Why do you assume that the man in the middle is gone after the handover? This will not work.
noted No    
    S3‑194110 Address EN in solution 6 and solution 18 Huawei, Hisilicon pCR Approval Yes
YesNokia; whatever you send it will be accepted by the base station because you are connected to it. Nokia disagreed with the change. Ericsson was of the similar opinion. The dumb repeater does nothing else than repeating, so why the overhead? Huawei replied that the repeater was not really dumb. This was taken offline.
revised No S3‑194689  
    S3‑194689 Address EN in solution 6 and solution 18 Huawei, Hisilicon pCR Approval Yes
Yes
noted No   S3‑194110
    S3‑194207 Way forward - KI#3 False RBS detection Ericsson pCR Approval Yes
YesQualcomm: perform the evaluation before concluding. Orange: this conclusion means that we should do nothing and it is left to implementation.They didn’t agree with this way forward.
noted No    
    S3‑194205 [DRAFT] LS out to SA5 about SON poisoning Ericsson LS out Approval Yes
YesNokia: what do you want SA5 to do? Orange: better talk to your SA5 colleagues about this. It is not clear what SA5 needs to do about it. NTT-Docomo: clarify what they really need to do. This was taken offline.
noted No    
    S3‑194144 Update of Solution#15 Lenovo, Motorola Mobility pCR Approval Yes
Yes
approved No    
    S3‑194190 Resolving the ENs of solution#5 in the TR 33.809 Huawei, Hisilicon, Lenovo, Motorola Mobility pCR Approval Yes
YesInterdigital: refer to a generic satellite system, not specifically GPS. Revised to address this and other comments with editor's notes.
revised No S3‑194690  
    S3‑194690 Resolving the ENs of solution#5 in the TR 33.809 Huawei, Hisilicon, Lenovo, Motorola Mobility pCR Approval Yes
Yes
approved No   S3‑194190
    S3‑194191 Conclusion on mitigation against the authentication relay attack Huawei, Hisilicon, Lenovo, Motorola Mobility pCR Approval Yes
YesOrange disagreed with it.
noted No    
    S3‑193976 5GFBS-Update for solution#7 Apple pCR Approval No
Yes
withdrawn Yes    
    S3‑194665 Notes from the offline session on false base stations NTT-Docomo report Information Yes
Yes
noted No    
    S3‑194684 Draft TR 33.809 Apple draft TR Approval No
Yes
left for email approval No    
8.5 Study on Security aspects of Enhancement of Network Slicing S3‑194050 Conclusion to KI#3 Huawei, HiSilicon pCR Approval Yes
YesOrange objected to having normative work for this key issue.Ericsson agreed.
noted No    
    S3‑194051 Solution 8 update Huawei, HiSilicon pCR Approval Yes
YesEricsson: IDLE case: AMF relocation is to be avoided as an assumption, and this is implying that the relocation is needed. Capture this in the evaluation. Interdigital: signalling overheard is a concern here. Nokia disagreed with removing the editor's note. This didn't seem to be working.
revised No S3‑194542  
    S3‑194542 Solution 8 update Huawei, HiSilicon pCR Approval Yes
Yes
approved No   S3‑194051
    S3‑194317 Clarifications to solution #10 on protecting S-NSSAIs Qualcomm Incorporated pCR Approval Yes
YesInterdigital: clarification of the Distribution of the Key ID is not here (Idle mode mobility). Add an editor's note about that. Qualcomm replied that this comment hadn't been done before when they were asked to bring a contribution with additional clarifications.
revised No S3‑194544  
    S3‑194544 Clarifications to solution #10 on protecting S-NSSAIs Qualcomm Incorporated pCR Approval Yes
YesAdding the editor's note.
approved No   S3‑194317
    S3‑194318 Update to the evaluation of solution #10 on protecting S-NSSAIs Qualcomm Incorporated pCR Approval Yes
YesNokia commented that the impact of the idle mobility issue had to be considered. Ericsson: update this according to the editor's note added in the previous contribution. Nokia: retain the editor's note.
revised No S3‑194545  
    S3‑194545 Update to the evaluation of solution #10 on protecting S-NSSAIs Qualcomm Incorporated pCR Approval Yes
YesBringing back the editor's note.
approved No   S3‑194318
    S3‑194094 Adding evaluation to solution #10 in TR 33.813 Huawei, Hisilicon pCR Approval Yes
YesQualcomm: the previous document covers this already. We don’t agree.
noted No    
    S3‑193964 TR 33.813 - update for solution #11 InterDigital Communications pCR Approval Yes
Yes
approved No    
    S3‑193911 TR 33.813 - update for the evaluation for solution #11 InterDigital Communications pCR Approval Yes
YesQualcomm: this solution doesn't protect from attacks of people with the same NSSAI. It exists for both insiders and non-insiders.Don’t remove the editor's note. Nokia: the group size is too big, it is not a corner case.
revised No S3‑194546  
    S3‑194546 TR 33.813 - update for the evaluation for solution #11 InterDigital Communications pCR Approval Yes
Yes
approved No   S3‑193911
    S3‑194068 Update of solution #12 in TR 33.813 ZTE Corporation pCR Approval Yes
Yes
revised No S3‑194547  
    S3‑194547 Update of solution #12 in TR 33.813 ZTE Corporation pCR Approval Yes
YesIt brings back the last editor's note.
approved No   S3‑194068
    S3‑194052 Overal evaluation to solutions addressing KI#6 Huawei, HiSilicon pCR Approval Yes
YesInterdigital: Idle mobility needs to be revisited as we have done in previous papers. It was agreed to add an editor's note. Qualcomm: the table is already out of date according