Tdoc List

2019-05-10 15:43

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‑191100 Agenda WG Vice Chairman agenda   Yes
Yes
approved No    
3 IPR and Anti-Trust Law Reminder                      
4 Meeting Reports                      
4.1 Approval of the report from previous SA3 meeting(s) S3‑191101 Report from SA4#94AH MCC report   Yes
Yes
approved No    
    S3‑191598 Report from SA3#94 MCC report Approval Yes
Yes
approved No    
4.2 Report from SA Plenary S3‑191103 Report from last SA meeting WG Vice Chairman (Qualcomm) report   Yes
Yes
noted No    
4.3 Report from SA3-LI                      
5 Items for early consideration                      
6 Reports and Liaisons from other Groups                      
6.1 3GPP Working Groups S3‑191119 Reply LS on securing warning messages in ePWS C1-191522 LS in   Yes
Yes
noted No    
    S3‑191120 Reply LS on securing warning messages in ePWS S1-190503 LS in   Yes
YesBT: PWS has regulatory requirements identified,but SA1 says that this is not the case. Vice Chair: maybe this refers to ePWS, not PWS. Nokia: no specific requirements for IoT devices as opposed to humans. Vodafone: what does an IoT unit do with this message? Ericsson: CT1 decides the specific requirements and they said in the other LS that they haven't concluded this. Vodafone: if the early warning message is a piece of text we would have concerns about this. Vodafone was to ask their SA1 delegates about this for more clarification and maybe respond to SA1. This was taken offline. Nokia: IoT devices can be very different.
noted No    
    S3‑191125 Reply LS on EAS-C&U support C3-191167 LS in   Yes
Yes
noted No    
    S3‑191126 LS on usage of EPLMNs S2-1904825 LS in   Yes
YesRelated discussion paper in 462.
replied to No    
    S3‑191599 Reply to: LS on usage of EPLMNs Vodafone LS out approval Yes
Yes
approved No    
    S3‑191462 Discussion on security aspects of EPLMN in LS from S2 (S3-191126) Vodafone GmbH discussion Discussion Yes
YesEricsson wasn't sure about proposal C, although they supported a and b. This was taken offline. Qualcomm was fine with informing SA2, but not sure about sending an LS to CT1. It's up to SA3 to work on the security, CT1 is not involved in that.
noted No    
    S3‑191127 Reply LS on Interim conclusions for SA2 study on Radio Capabilities Signalling Optimisations (FS_RACS) C4-190346 LS in   Yes
Yes
noted No    
    S3‑191129 Reply LS on GTP Recovery Counter & GSN node behaviour C4-190485 LS in   Yes
Yes
noted No    
    S3‑191135 LS on Handling of non-essential corrections (non-FASMO) CRs and non-backwards compatible CRs CP-190218 LS in   Yes
Yes
noted No    
    S3‑191148 LS on broadcast assistance data delivery R2-1905462 LS in   Yes
YesQualcomm had a discussion paper in tdoc 520 proposing a reply.CATT also proposed a reply in 350.
replied to No    
    S3‑191600 Reply to: LS on broadcast assistance data delivery Intel LS out approval Yes
Yes
approved No    
    S3‑191520 Broadcast of Location Assistance Data for NR Qualcomm Incorporated discussion Decision Yes
YesEricsson commented that integrity protection should be included here. Qualcomm, Intel: no need to reopen this discussion. This was taken offline.
noted No    
    S3‑191154 Reply LS on authentication of group of IoT devices S1-190501 LS in   Yes
Yes
replied to No    
    S3‑191601 Reply to: Reply LS on authentication of group of IoT devices Huawei LS out approval Yes
Yes
approved No    
    S3‑191244 Discussion paper Security of Bulk IoT operations Huawei, Hisilicon discussion Endorsement Yes
YesVodafone: it misses the point abut auth based on key sharing. ORANGE: SA2 and RAN groups should take care of this as well, not standalone SA3 work. Vodafone: IoT should be more secure, not less secure in our view. Huawei: SA1 is asking us about the authentication procedure. ORANGE: this is part of the registration procedure handled by SA2. IDEMIA agreed that his was to be treated firstly by SA2. BT: use case is about enabling/disabling large number of devices, so you should make it more secure. The term "operations" is more general. Huawei didnít understand why this was necessarily less secure as stated by some companies. ORANGE: send an LS to SA1. Sony added that SA2 should be added to the recipients as well. The study item in 245 was postponed given that a response from SA1 was needed.
noted No    
6.2 IETF                      
6.3 ETSI SAGE                      
6.4 GSMA S3‑191137 GSMA DESS - Diameter IPX Network End-to-End Security Solution GSMA LS in   Yes
YesSpecific action for SA3, so this LS was postponed for the next meeting.
postponed No    
6.5 OMA                      
6.6 TCG S3‑191108 TCG progress report InterDigital other Information Yes
Yesē Publication of new or revised deliverables (incremental changes from the status reported at SA3#94): o TCG TSS 2.0 TAB and Resource Manager Ė published April 2019 o TCG TSS 2.0 TPM Command Transmission Interface (TCTI) Ė published April 2019 o TCG TSS 2.0 System Level API (SAPI) Ė public review April 2019 o TCG TSS 2.0 Enhanced System Level API (ESAPI) Ė public review April 2019 o TCG PC Client Device Driver Design Principles for TPM 2.0 Ė public review February 2019 o TCG Platform Certificate Profile Ė public review February 2019 o TCG Trusted Platform Module 2.0 r1.50 Ė public review January 2019 o TCG TSS 2.0 Response Code API Ė public review January 2019 o TCG Trusted Attestation Protocol (TAP) Information Model Ė public review January 2019 2. Meetings ē TCG Members Meeting in Warsaw, Poland Ė 10-13 June 2019 ē TCG Annual Members Meeting in Toronto, Canada - 15-17 October 2019 ē 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.7 oneM2M                      
6.8 TC-CYBER                      
6.9 ETSI NFV                      
6.10 CVDs and Research S3‑191623 Way forward in CVD and research CableLabs discussion discussion Yes
YesQualcomm: published papers can be discussed publicly in the SA3 mail list. Vodafone: uncomfortable to discuss these papers in an open meeting. It was decided to continue the discussions in the next meeting on how to address the academic papers. Qualcomm warned about legal issues if a private discussion group for SA3 was created, so they wanted to check back at home the implications of this. MCC reminded that there existed a closed group for VCD where papers could be discussed before their publication and a first response could be given before discussions in SA3.
noted No    
    S3‑191743 Handling of UE radio network capabilities in 4G and 5G GSMA LS in discussion Yes
YesVodafone: RAN2 should do something first, and they are meeting next week. Our next meeting is after SA, so we would have to have a conference call to address this to meet the deadline. Qualcomm: the issue is in RAN. It's a gNodeB configuration. It's a "should" requirement from the network side to first activate security. NTT-Docomo: we could have a conference call to address this. Qualcomm: RAN is meeting next week and then in August. It was decided to postpone and come up with a conference call between June and August if necessary.
postponed No    
6.11 Other Groups S3‑191136 LS on the availability of and requesting feedback on the stable draft TR 103 582 from ETSI STF555 - "Study of use cases and communications involving IoT devices in emergency situations" ETSI SC EMTEL LS in   Yes
YesVodafone: we already missed the deadline given in here, so I propose to postpone this for the next meeting.
postponed No    
    S3‑191158 Approval of Smart Secure Platform requirement specification ETSI TC SCP LS in   Yes
Yes
noted No    
    S3‑191159 LS/r on SG17 work item X.5Gsec-q: Security guidelines for applying quantum-safe algorithms in 5G systems ITU-T SG17 LS in   Yes
Yes
noted No    
    S3‑191160 LS on SG17 new work item X.5Gsec-ecs: Security Framework for 5G Edge Computing Services ITU-T SG17 LS in   Yes
YesChina Unicom presented the document and commented that they were also participating.
noted No    
7 Work Areas                      
7.1 Security aspects of 5G System - Phase 1 (5GS_Ph1-SEC) (Rel-15)                      
7.1.1 Key hierarchy                      
7.1.2 Key derivation S3‑191203 KAUSF desynchronization problem and solutions NEC Europe Ltd discussion Information Yes
YesSuperseeded by tdoc 204.
noted No    
    S3‑191204 KAUSF desynchronization problem and solutions Ė updated version after conf call on 25 Apr. NEC Europe Ltd discussion Endorsement Yes
YesQualcomm: we donít agree with bullets 3,4 and 5. More analysis is needed and it should be considered for Rel-16, not Rel-15. Ericsson agreed with Qualcomm. NEC was fine with having the work in Rel-16 instead of Rel-15, for bullets 3-5. Qualcomm didnít see a need for bullets 3-5, independently from the release. Huawei only supported bullet 2. Samsung didn't agree with 3-5 either. Nokia needed to look at proposal 2, not agreeing on the rest.
noted No    
    S3‑191208 UDM triggered authentication NEC Europe Ltd draftCR Discussion Yes
YesMore analysis was needed on this proposal. Ericsson: if this is for Rel-16 we need a new Work Item and it is too early for that.
noted No    
    S3‑191205 Aligning the storage timing of KAUSF in 5G AKA with EAP-AKA' NEC Europe Ltd CR Agreement Yes
YesNokia didnít agree with the changes. It seemed that companies were OK with the idea, but the wording was not correct. Qualcomm: no impact on the ME.
revised No S3‑191603  
    S3‑191603 Aligning the storage timing of KAUSF in 5G AKA with EAP-AKA' NEC Europe Ltd CR Agreement Yes
Yes
agreed No   S3‑191205
    S3‑191206 Synchronization of KAUSF between AUSF and UE NEC Europe Ltd draftCR Discussion Yes
Yes
not pursued No    
    S3‑191209 KAUSF key setting in EAP AKAí NEC Europe Ltd draftCR Discussion Yes
Yes
not pursued No    
    S3‑191207 Using Key Identifiers between AUSF and UE for UPU and SoR NEC Europe Ltd draftCR Discussion Yes
Yes
noted No    
    S3‑191446 Rectifying incorrect limitation for horiz/vert key derivation Ericsson CR Agreement Yes
Yes
revised No S3‑191604  
    S3‑191604 Rectifying incorrect limitation for horiz/vert key derivation Ericsson CR Agreement Yes
Yes
agreed No   S3‑191446
    S3‑191367 Corrections on the s-Kgnb derivation Huawei, Hisilicon CR Approval Yes
YesEricsson: Wrong key name and second change does not need to be there.
revised No S3‑191605  
    S3‑191605 Corrections on the s-Kgnb derivation Huawei, Hisilicon CR Approval Yes
Yes
agreed No   S3‑191367
7.1.3 Mobility S3‑191407 Clarification on securing the procedure of idle mobility from 5GS to EPS over N26 interface Huawei, Hisilicon CR Approval Yes
YesNokia: add explanation on this in 8.5.1. Ericsson: why a separate clause? Just add a note. Vodafone: is this essential? Add the word in the title. Ericsson: all CRs cat-F are supposed to be essential anyway. No need for this.
revised No S3‑191606  
    S3‑191606 Clarification on securing the procedure of idle mobility from 5GS to EPS over N26 interface Huawei, Hisilicon CR Approval Yes
Yes
agreed No   S3‑191407
    S3‑191411 Registration failure in registration procedure with AMF reallocation caused by slicing Huawei, Hisilicon discussion Discussion Yes
YesVodafone: this is lack of efficiency, not a security hole. Huawei: you will never be registered successfully, it's a denial of service. Ericsson: step 7 discarded by UE according to Huawei, but we donít agree. The Vice Chair (NTT-Docomo) commented that confusion with the CT1 specification seemed to be the source of the discussion. An LS could be sent to them. Qualcomm agreed with sending an LS to CT1 ccSA2. It was a CT1 decision according to them. The vice chair asked if this was a Rel-15 issue, and Qualcomm replied that Rel-15 shouldn't be ruled out. This was taken offline.
noted No    
    S3‑191412 Solving registration failure in initial registration procedure with AMF reallocation Huawei, Hisilicon CR Approval Yes
YesThere was an agreement that this was a problem to be fixed, but Qualcomm preferred to contact SA2 and CT1 as well with an LS before agreeing with this CR. It was agreed the existence of an issue that needed to be solved; it was asked to be minuted "the issues in tdoc 411 need further investigation." The Chair declared the CRs as not pursued but pointed out that Huawei could bring back revisions of them to continue discussions in the next meeting.
not pursued No    
    S3‑191413 Solving registration failure in initial registration procedure with AMF reallocation Huawei, Hisilicon CR Approval Yes
Yes
not pursued No    
    S3‑191419 NAS recovery with the soure AMF in handover failure Huawei, Hisilicon CR Approval Yes
YesRelated to the LS in 147. Vodafone: this needs rewording.
merged No S3‑191607  
    S3‑191449 Verification failure of NAS container Ericsson CR Agreement Yes
YesIntel didnít see the need of this. How does the AMF will know to do the same?
merged No S3‑191607  
    S3‑191512 Clarification for the NAS MAC failure case in N2 HO Qualcomm Incorporated CR Agreement Yes
YesVodafone: wording issues. Huawei: we are not addressing how often this happens. It's a new feature and if this happens often the RAN2 LS is a good place to start, but we need to agree on how often this happens. Ericsson commented that this was out of scope of SA3.
revised No S3‑191607  
    S3‑191607 Clarification for the NAS MAC failure case in N2 HO Qualcomm Incorporated,Huawei,Ericsson CR Agreement Yes
Yes
agreed No   S3‑191512
7.1.4 AS security S3‑191143 Reply LS on Dual Connectivity R2-1902677 LS in   Yes
Yes450 related to this LS.
noted No    
    S3‑191144 Reply LS on Enforcement of maximum supported data rate for integrity protection R2-1902700 LS in   Yes
Yes
noted No    
    S3‑191379 Add detials on handling UP security in RRC inactive scenario Huawei, Hisilicon CR Approval Yes
YesQualcomm needed to take this offline.
revised No S3‑191609  
    S3‑191609 Add detials on handling UP security in RRC inactive scenario Huawei, Hisilicon CR Approval Yes
Yes
agreed No   S3‑191379
    S3‑191395 Discussion on Key handling on UE for Reestablishment Procedure in case of N2 handover failure Huawei, Hisilicon discussion Endorsement Yes
Yes
noted No    
    S3‑191394 CR to TS33501-RRC Reestablishment security handling when N2 Handover fails Huawei, Hisilicon CR Approval Yes
YesQualcomm: this is not needed in Rel-15 and it should be discussed separately in Rel-16. Ericsson agreed: RAN groups consider this as a rare case and they donít want to optimize for this. Huawei: let's ask RAN2 about their opinion on this.It is not a radio link failure. Ericsson: this is to be handled by RAN2, no LS needed. Qualcomm agreed. Huawei considered it to be a valid security issue. There was no agreement to have this for Rel-15, and more offline discussion was needed for Rel-16.
not pursued No    
    S3‑191450 Security algorithm change by SN Ericsson CR Agreement Yes
YesHuawei: this change is not needed.
not pursued No    
    S3‑191483 CR to 33.501 6.6.4 UP integrity mechanisms - UE to gNB ntegrity protection check failure reporting BT plc CR Approval Yes
YesIt was commented that TEIx for Rel-16 category-B and C was not recommended anymore by SA. The WI code would have to be taken into account. Deutsche Telekom: do we want to make this mandatory? Qualcomm: RAN2 asked SA3 last year about this being necessary and now we are reopening the issue changing our mind. Nokia: network and UE can verify that the integrity is failing already. We donít agree with this change either. Samsung: When the PDCP error happens, it is reported to the RRC layer. RRC layer knows the reason why the packet is dropped. RAN2 implements the behaviour on how to act in case there is such failure. Qualcomm: this is a RAN level discussion. They discussed this in Rel-15 and there was no agreement. Lenovo didnít agree with this either. This was taken offline.
not pursued No    
    S3‑191705 Security of RRC Reestablishment during N2 HO Huawei LS out Approval Yes
YesQualcomm and Ericsson were against sending this LS. Huawei pointed out that most companies were OK with this.
noted No    
7.1.5 NAS security S3‑191147 LS on Security failure of NAS container in HO command R2-1905460 LS in   Yes
Yes419,449 and 512 handle this issue.
replied to No    
    S3‑191608 Reply to: LS on Security failure of NAS container in HO command Ericsson LS out approval Yes
Yes
approved No    
    S3‑191124 LS on Multiple NAS connections and inter-system change from S1 mode to N1 mode in 5GMM-CONNECTED mode C1-192804 LS in   Yes
YesTdocs 452, 501, 502,503 are related documents. Tentative response from Qualcomm in 505.
replied to No    
    S3‑191346 CR to TS33.501 - NAS SMC figure correction CATT CR   Yes
Yes
agreed No    
    S3‑191387 Clarification for Initial NAS Message Protection Huawei, Hisilicon CR Approval Yes
YesEricsson: valid scenario but the additional changes are already described somewhere else. This had to be taken offline.
revised No S3‑191611  
    S3‑191611 Clarification for Initial NAS Message Protection Huawei, Hisilicon CR Approval Yes
Yes
agreed No   S3‑191387
    S3‑191447 UP policy handling in case of unauthenticated emergency calls Ericsson CR Agreement Yes
YesCableLabs agreed with the change, it clarifed an ambiguity. Alex (BT): this wording infers that the AMF may not accept unauthentication in emergency calls and this is a requirement for the network. The problem is in "in the case" words. This change was removed. Qualcomm: ME is not affected.
revised No S3‑191612  
    S3‑191612 UP policy handling in case of unauthenticated emergency calls Ericsson CR Agreement Yes
Yes
agreed No   S3‑191447
    S3‑191448 Remove EN in clause 10.2.2.2 Ericsson CR Agreement Yes
YesHuawei: specification of the messages is a CT1 issue. There were different concerns about this and Ericsson decided to bring it back during the next meeting.
not pursued No    
    S3‑191501 Correction to the handling of security context in the multi-NAS scenario Qualcomm Incorporated CR Agreement Yes
Yes
revised No S3‑191783  
    S3‑191783 Correction to the handling of security context in the multi-NAS scenario Qualcomm Incorporated,Ericsson,Huawei CR Agreement Yes
Yes
agreed No   S3‑191501
    S3‑191502 Description of issue of clashing ngKSIs with multi-NAS security Qualcomm Incorporated discussion Discussion Yes
YesHuawei considered this as a very rare case. Ericsson:
noted No    
    S3‑191503 Clashing ngKSI for different security contexts in multi-NAS scenarios Qualcomm Incorporated CR Agreement Yes
YesQualcomm will bring a revised version for the next meeting.
not pursued No    
    S3‑191122 LS on handling of non-zero ABBA value in Release 15 C1-191686 LS in   Yes
Yes
replied to No    
    S3‑191504 Response LS on handling of non-zero ABBA value in Release 15 Qualcomm Incorporated LS out Approval Yes
Yes
revised No S3‑191613  
    S3‑191613 Response LS on handling of non-zero ABBA value in Release 15 Qualcomm Incorporated LS out Approval Yes
Yes
approved No   S3‑191504
    S3‑191505 Response LS on Multiple NAS connections and inter-system change from S1 mode to N1 mode in 5GMM-CONNECTED mode Qualcomm Incorporated LS out Approval Yes
Yes
revised No S3‑191610  
    S3‑191610 Response LS on Multiple NAS connections and inter-system change from S1 mode to N1 mode in 5GMM-CONNECTED mode Qualcomm Incorporated LS out Approval Yes
Yes
approved No   S3‑191505
    S3‑191549 Clarification to Initial NAS message protection Samsung CR Approval Yes
YesThis had to be discussed offline and Samsung will bring a modified version for the next meeting.
not pursued No    
7.1.6 Security context                      
7.1.7 Visibility and Configurability                      
7.1.8 Primary authentication S3‑191230 Discussion paper on Re-authentication and UE context handling Nokia, Nokia Shanghai Bell discussion Endorsement Yes
YesEricsson: number 6 not to be handled in Rel-16. They didn't agree with the rest of the points. Qualcomm: this could create more issues than actually solving anything. Samsung supported point 6 (for Rel-16) but agreed with Qualcomm for the rest, on being careful with how to handle the issue. BT didn't agree with point 6 on the wording "in any scenario". This was taken offline
noted No    
    S3‑191589 Discussion on removing the authentication result in the UDM Huawei, Hisilicon discussion Discussion Yes
YesEricsson: the attack is valid in a very rare case. There wasn't much support for this and the accompanying CR was not pursued.
noted No   S3‑191417
    S3‑191492 Removing the authentication result in the UDM Huawei, Hisilicon CR Approval Yes
Yes
not pursued No   S3‑191418
    S3‑191444 Discussion on missing AMF/SEAF behaviour Ericsson, CableLabs discussion Endorsement Yes
YesHuawei: maybe we donít need to cope with this until someone comes with a security threat and attack related to this. If not, it would be a protocol error left for stage 3. ORANGE: this is an error case, agree with Huawei. Nokia didn't agree either. Ericsson asked what the right behaviour was. Qualcomm answered that this case scenario would not work, it doesn't matter asking about the behaviour.
noted No    
    S3‑191445 Missing AMF/SEAF behaviour Ericsson, CableLabs CR Agreement Yes
Yes
not pursued No    
    S3‑191417 Discussion on removing the authentication result in the UDM Huawei, Hisilicon discussion Discussion Yes
Yes
revised No S3‑191589  
    S3‑191418 Removing the authentication result in the UDM Huawei, Hisilicon CR Approval Yes
Yes
revised No S3‑191492  
7.1.9 Secondary authentication                      
7.1.10 Interworking S3‑191451 Verification failure of NAS MAC in NAS container at 4G to 5G HO Ericsson CR Agreement Yes
Yes
merged No S3‑191614  
    S3‑191452 Handling of 5G security contexts with multiple NAS connections at 4G to 5G HO Ericsson CR Agreement Yes
Yes
merged No S3‑191783  
    S3‑191513 Clarification for the NAS MAC failure case in interworking Qualcomm Incorporated CR Agreement Yes
Yes
revised No S3‑191614  
    S3‑191614 Clarification for the NAS MAC failure case in interworking Qualcomm Incorporated,Ericsson CR Agreement Yes
Yes
agreed No   S3‑191513
7.1.11 non-3GPP access                      
7.1.12 NDS                      
7.1.13 Service based architecture                      
7.1.13.1 Interconnect (SEPP related) S3‑191128 Reply LS on Verification of PLMN-ID in the SEPP C4-190348 LS in   Yes
Yes
replied to No    
    S3‑191615 Reply to: Reply LS on Verification of PLMN-ID in the SEPP Deutsche Telekom LS out approval Yes
Yes
approved No    
    S3‑191185 Addition of missing SEPP requirement on JOSE-patch validation Deutsche Telekom AG CR Approval Yes
YesNokia: modify the following sentence instead of adding the new sentence.
revised No S3‑191616  
    S3‑191616 Addition of missing SEPP requirement on JOSE-patch validation Deutsche Telekom AG CR Approval Yes
Yes
agreed No   S3‑191185
    S3‑191316 Name for N32 application layer security Ericsson discussion Endorsement Yes
YesVodafone: what happens if other people are using the acronym in their specs? SA has asked for essential corrections in Rel-15. NTT-Docomo: the current acronym is heavily overloaded. NCSC: change the acronym, it's unlikely that many specs are using it. Ericsson:: we would tell CT4 mainly.
noted No    
    S3‑191617 Name clarification for N32 security Ericsson,NCSC CR Agreement Yes
Yes
agreed No    
    S3‑191618 LS on clarification for N32 security Ericsson LS out Approval Yes
YesThe LS will attach the CR in 617 and sent to SA and CT so the Plenary can decide whether to accept it or not.
approved No    
7.1.13.2 Other S3‑191314 Token-based authorization for NRF's management and discovery services Ericsson CR Agreement Yes
YesEricsson: this is alignment with CT4. Huawei preferred to keep the note. BT: the cover sheet does not correspond to the clause that is being changed. It is not the right place to make the change. Ericsson commented that if this wasn't accepted, CT4 would have to revert their decision.
revised No S3‑191619  
    S3‑191619 Token-based authorization for NRF's management and discovery services Ericsson CR Agreement Yes
YesHuawei didnít agree with the changes.
not pursued No   S3‑191314
    S3‑191315 Slice information for token-based authorization Ericsson CR Agreement Yes
YesDeutsche Telekom: isnít this a Rel-16 issue? We have a key issue in Rel-16 about this. Ericsson: we do it for Rel-15 then enhancements in Rel-16.
revised No S3‑191621  
    S3‑191621 Slice information for token-based authorization Ericsson CR Agreement Yes
Yes
agreed No   S3‑191315
    S3‑191522 Discussion of SBA authorization selection China Mobile discussion Endorsement Yes
YesDeutsche Telekom: we should involve CT4 as well and have a discussion on whether we want to do it this way. Nokia didnít agree with the proposal: Authentication during discovery and authentication during service access are not mutually exclusive as the paper claims.
noted No    
    S3‑191524 Proposal of SBA authorization revision China Mobile CR Approval Yes
Yes
not pursued No    
7.1.14 Privacy S3‑191121 LS on Use of SUCI in NAS signalling C1-191685 LS in   Yes
Yes
replied to No    
    S3‑191752 Reply to: LS on Use of SUCI in NAS signalling Intel LS out approval Yes
Yes
approved No    
    S3‑191305 Discussion on LS on Use of SUCI in NAS signalling ZTE Corporation discussion Endorsement Yes
Yes
noted No    
    S3‑191306 Modification on Use of SUCI in NAS signalling ZTE Corporation CR Agreement Yes
YesQualcomm: it correctly reflects what's happening in CT1. It needs to be verified if this is acceptable from security point of view. This was taken offline.
revised No S3‑191704  
    S3‑191704 Modification on Use of SUCI in NAS signalling ZTE Corporation,Intel CR Agreement Yes
Yes
agreed No   S3‑191306
    S3‑191258 Clarification on Subscription Identifier mechanism for De-registration. Intel Corporation (UK) Ltd CR   Yes
YesNokia: the use of SUCI here opens a DoS attack scenario. Qualcomm: Deregistration with the SUCI would happen as part of the registration procedure. IDEMIA: in which case the 5G GUTI is not valid? This is what we need to identify. NTT-Docomo was concerned like Nokia as this could be misused. CableLabs didnít agree with the attack scenario. Anja (Nokia): SUCI is a one time identifier by design. Qualcomm commented that there is a requirement where the UE will keep sending the same SUCI in a specific situation. Qualcomm: if you read the CT1 specification, it is up to AMF how to handle this. Nokia: CT1 inherited this case from LTE. It was allowed in LTE, but changes adopted for SUCI require a correction in CT1. This had to be taken offline.
revised No S3‑191751  
    S3‑191751 Clarification on Subscription Identifier mechanism for De-registration. Intel Corporation (UK) Ltd CR - Yes
YesNokia: this opens up a DoS attack scenario but it's too late to change this in Rel-15. Qualcomm agreed.
agreed No   S3‑191258
    S3‑191307 LS on Use of SUCI in NAS signalling ZTE Corporation LS out Approval Yes
Yes
noted No    
    S3‑191257 draft LS response to LS on Use of SUCI in NAS signalling Intel Corporation (UK) Ltd response   Yes
Yes
noted No    
    S3‑191163 Clarification of MSIN coding for the ECIES protection shemes IDEMIA,Gemalto, Qualcomm,Ericsson,Huawei,HiSilicon CR Approval Yes
YesDiscussed with 261.
revised No S3‑191624  
    S3‑191624 Essential clarification of MSIN coding for the ECIES protection shemes IDEMIA,Gemalto, Qualcomm,Ericsson,Huawei,HiSilicon,Intel CR Approval Yes
Yes
agreed No   S3‑191163
    S3‑191261 Input encoding for ECIES protection schemes Intel Corporation (UK) Ltd CR   Yes
YesIDEMIA: we donít need to add anything else to the CT1 work.The new figure was removed.
merged No S3‑191624  
    S3‑191414 Clarification on the SUCI compuation Huawei, Hisilicon, Gemalto, IDEMIA CR Approval Yes
YesVodafone: it needs rewording.
revised No S3‑191625  
    S3‑191625 Clarification on the SUCI compuation Huawei, Hisilicon, Gemalto, IDEMIA CR Approval Yes
YesAdded a reference as proposed by Ericsson.
agreed No   S3‑191414
    S3‑191357 Subscriber privacy: ECIES test data for Profile A Gemalto N.V. discussion Discussion Yes
Yes
noted No    
    S3‑191409 Subscriber privacy: test data for Profile A of SUCI computation Huawei, Hisilicon CR Approval Yes
Yes
merged No S3‑191626  
    S3‑191220 subscriber privacy: ECIES test data Gemalto, IDEMIA, Huawei, Hisilicon CR Approval Yes
Yes
revised No S3‑191626  
    S3‑191626 subscriber privacy: ECIES test data Gemalto, IDEMIA, Huawei, Hisilicon CR Approval Yes
Yes
agreed No   S3‑191220
    S3‑191453 Missing privacy parameters Ericsson CR Agreement Yes
YesGemalto added a clarification on NOTE2: "by OTA". IDEMIA: we donít need to indicate how it is updated, it is up to the operator. Nokia, Qualcomm: all these details are in CT specs; we donít need this CR. Gemalto supported Ericsson's CR. Qualcomm: it is not an essential correction. Huawei agreed. IDEMIA: not a contentious issue, we can go forward with this change. Ericsson: in which stage 3 document is this covered? ORANGE preferred not to refer to a CT6 specification. ORANGE: Keep 5.2.5 make a new contribution for 5.8.2. Vodafone: no need to standardize what appears in 5.8.2.
revised No S3‑191627  
    S3‑191627 Missing privacy parameters Ericsson,Gemalto,IDEMIA CR Agreement Yes
Yes5.8.2 was removed and NOTE 2 modified.
agreed No   S3‑191453
7.1.15 Incoming and outgoing Lses S3‑191131 LS on Maximum HTTP payload size C4-190609 LS in   Yes
Yes
noted No    
    S3‑191156 Reply LS on Clarification of UE Trace support S2-1902901 LS in   Yes
Yes
noted No    
    S3‑191132 LS on Protected LI Parameters in N4 S3i190254 LS in   Yes
YesBT: LTE solution has security weaknesses to be hardened in 5G.
noted No    
    S3‑191133 Reply LS on Protected LI Parameters in N4 C4-191529 LS in   Yes
Yes
noted No    
    S3‑191134 Reply on LS on Protected LI Parameters in N4 S3i190283 LS in   Yes
Yes
noted No    
    S3‑191150 Response LS on reporting all cell IDs in 5G R3-191111 LS in   Yes
Yes
noted No    
    S3‑191151 Response LS on reporting all cell IDs in 5G S2-1904819 LS in   Yes
Yes
noted No    
    S3‑191152 Response LS on reporting all Cell IDs in 5G S3i190265 LS in   Yes
Yes
noted No    
    S3‑191155 Reply LS on Interception of voice services over new radio in a 5GS environment S2-1902799 LS in   Yes
Yes
noted No    
    S3‑191628 LS on support of non-3GPP only UE and support for PEI in IMEI format S2-1904836 LS in discussion Yes
Yes
postponed No    
7.1.16 Others S3‑191562 Addition of AMF/SMF requirement on security logging Deutsche Telekom AG, NTT Docomo CR Approval Yes
Yes
agreed No   S3‑191262
    S3‑191313 Various corrections to security protocols and cryptography Ericsson CR Agreement Yes
Yes
agreed No    
    S3‑191130 Reply LS on Nudr Sensitive Data Protection C4-190534 LS in   Yes
Yes
replied to No    
    S3‑191629 Reply to: Reply LS on Nudr Sensitive Data Protection Hewlett Packard Enterprise LS out approval Yes
YesNokia had a proposal to make a change in TS 33.501 with a new requirement. It was said that she could bring it back in the next meeting as Ericsson requested more time to check it.
approved No    
    S3‑191420 Missing UDR description in alignment with 29.505 Nokia, Nokia Shanghai Bell CR Agreement Yes
YesVodafone: no point in standardising this now. Telecom Italia pointed out that this was cat-B for Rel-15 and too late to be introduced. It was commented that this was aligning with CT4 changes. BT: unless the vendors update security in UDM/UDR we will have security breaches. This introduces an operational problem. Vodafone agreed. Christine (Ericsson) wanted to take it offline to clarify the concerns on the deployment of this. NTT-Docomo commented: can UDM be virtualised? If so, security is not possible; it would be a red flag. Hpe: we thought that ARPF would be a separate module, have hardware for that one. ORANGE: how do we handle having the right keys in the right hardware when having multiple UDMs? This had to be taken offline.
not pursued No    
    S3‑191421 Adding Nudr service Nokia, Nokia Shanghai Bell CR Agreement Yes
Yes
not pursued No    
    S3‑191262 Addition of AMF/SMF requirement on security logging Deutsche Telekom AG, NTT Docomo CR Approval Yes
Yes
revised No S3‑191562  
7.2 Security Assurance Specification for 5G (SCAS_5G) (Rel-16)                      
7.2.1 NR Node B (gNB) (TS 33.511) S3‑191214 New Test Case: Error handling of malformed JSON object between two network products NEC Europe Ltd draftCR Agreement Yes
Yes
revised No S3‑191487  
    S3‑191380 Completing TS 33.511 Huawei, Hisilicon pCR Approval Yes
YesEricsson queried about the conclusion on gNB-specific additions to 33.117. Huawei replied that they didnít find new test cases.
revised No S3‑191741  
    S3‑191741 Completing TS 33.511 Huawei, Hisilicon pCR Approval Yes
Yes
approved No   S3‑191380
    S3‑191381 Adding gNB critical assets and threats to TR 33.926 Huawei, Hisilicon CR Approval Yes
YesEricsson commented that a similar work should be done for the other network product classes. Ericsson: Confidentiality and inegrity protection are missing in X.2.1. The contribution was well received but it needed further discussions.
revised No S3‑191630  
    S3‑191630 Adding gNB critical assets and threats to TR 33.926 Huawei, Hisilicon CR Approval Yes
Yes
agreed No   S3‑191381
    S3‑191463 Living Document: General SBA/SBI aspects in TS 33.117 Nokia, Nokia Shanghai Bell draftCR Approval Yes
Yes
revised No S3‑191631  
    S3‑191631 Living Document: General SBA/SBI aspects in TS 33.117 Nokia, Nokia Shanghai Bell draftCR Approval Yes
Yes
approved No   S3‑191463
    S3‑191487 New Test Case: Error handling of malformed JSON object between two network products NEC Europe Ltd draftCR Agreement Yes
YesHuawei: what is a malformed JSON object? NEC: NOTE 1 explains it. Huawei: the test case needs more work. Ericsson supported this. Ericsson added that this could mean having malformed JSON objects everywhere.
revised No S3‑191701 S3‑191214
    S3‑191701 New Test Case: Error handling of malformed JSON object between two network products NEC Europe Ltd draftCR Agreement Yes
Yes
noted No   S3‑191487
    S3‑191640 Adapting maximum HTTP payload size to CT4 specification Deutsche Telekom pCR Approval Yes
Yes
approved No    
    S3‑191785 Draft TS 33.511 Huawei draft TS Approval Yes
Yes
approved No    
    S3‑191786 Cover sheet TS 33.511 Huawei TS or TR cover Approval Yes
Yes
approved No    
7.2.2 Access and Mobility Management Function (TS 33.512) S3‑191401 Test case on UE security capability invalid or unacceptable Huawei, Hisilicon pCR Approval Yes
YesDeutsche Telekom: expected result should be reworded. Nokia had some comments that needed to be taken offlien. Ericsson: there is no threat, not clearly motivated. The test is very unspecific, not clear what the test should do. Huawei: CT1 has specified what's invalid or unacceptable.We can focus on the clear scenarios if needed. Nokia: we need to do firstly a threat analysis and afterwards the test case. Huawei: it's in the rational. Nokia: it should be documented in the TR 33.926.
revised No S3‑191650  
    S3‑191650 Test case on UE security capability invalid or unacceptable Huawei, Hisilicon pCR Approval Yes
Yes
approved No   S3‑191401
    S3‑191400 Removing the EN on AMF log Huawei, Hisilicon pCR Approval Yes
Yes
merged No S3‑191651  
    S3‑191560 Removing the EN on AMF log NTT DOCOMO, Deutsche Telekom pCR   Yes
Yes
revised No S3‑191651  
    S3‑191651 Removing the EN on AMF log NTT DOCOMO, Deutsche Telekom,Huawei pCR - Yes
Yes
approved No   S3‑191560
    S3‑191181 Addition of Network Product Class Description for AMF Deutsche Telekom AG CR Approval Yes
YesMCC was hesitant about referring to Release 16 version of TS 23.501. The reference pointed to Rel-16 by default. Ericsson commented that in fact the reference should be for the Release 15 version of TS 23.501. It was decided to work with draftCRs so this was converted into a new document in 653.
not pursued No    
    S3‑191653 Addition of Network Product Class Description for AMF Deutsche Telekom AG draftCR Approval Yes
Yes
approved No    
    S3‑191182 Addition of AMF-related Security Problem Descriptions Deutsche Telekom AG CR Approval Yes
YesHuawei: add the threat rational.
revised No S3‑191654  
    S3‑191654 Addition of AMF-related Security Problem Descriptions Deutsche Telekom AG CR Approval Yes
Yes
agreed No   S3‑191182
    S3‑191652 Draft TS 33.512 Deutsche Telekom draft TS Approval Yes
Yes
approved No    
7.2.3 User Plane Function (UPF) (TS 33.513)                      
7.2.4 Unified Data Management (UDM) (TS 33.514)                      
7.2.5 Session Management Function (SMF) (TS 33.515) S3‑191396 Security Assurance Requirements and Test Case on TEID Uniqueness for SMF Huawei, Hisilicon pCR Approval Yes
Yes
revised No S3‑191655  
    S3‑191655 Security Assurance Requirements and Test Case on TEID Uniqueness for SMF Huawei, Hisilicon,Nokia pCR Approval Yes
Yes
approved No   S3‑191396
    S3‑191465 SMF Test Case: TEID Uniqueness Nokia, Nokia Shanghai Bell pCR Approval Yes
YesEricsson: it needs more work on the threats, it seems to be incomplete. Docomo had some issues that were taken offline.
merged No S3‑191655  
    S3‑191656 Draft TS 33.515 Huawei draft TS Approval Yes
Yes
approved No    
7.2.6 Authentication Server Function (AUSF) (TS 33.516) S3‑191320 Using STRIDE methodology for NPCD, SPD, assets and threats Ericsson discussion Endorsement Yes
YesHuawei wasnít sure about adding anything else to the process that was being performed in LTE and now in 5G.
noted No    
7.2.7 Security Edge Protection Proxy (SEPP) (TS 33.517) S3‑191186 Testcase: Replacing confidential IEs with NULL in original N32-f message Deutsche Telekom AG pCR Approval Yes
Yes
revised No S3‑191657  
    S3‑191657 Testcase: Replacing confidential IEs with NULL in original N32-f message Deutsche Telekom AG pCR Approval Yes
Yes
approved No   S3‑191186
    S3‑191466 New Annex for the SEPP in TR 33.926 Nokia, Nokia Shanghai Bell draftCR Approval Yes
YesHuawei: In x.2.3.1 the effect would be a worse problem than a waste of system resources. This was taken offline.
revised No S3‑191659  
    S3‑191659 New Annex for the SEPP in TR 33.926 Nokia, Nokia Shanghai Bell draftCR Approval Yes
Yes
approved No   S3‑191466
    S3‑191467 Updates to SEPP Test Cases Nokia, Nokia Shanghai Bell pCR Approval Yes
YesEricsson: remove editor's note on requirement to be added in 33.501. Huawei didn't agree with the last change, it was not needed according to them. Related to contribution 469 according to Nokia, but it was clarified that the SCAS work didnít depend on study work, so the last change was removed.
revised No S3‑191660  
    S3‑191660 Updates to SEPP Test Cases Nokia, Nokia Shanghai Bell pCR Approval Yes
Yes
approved No   S3‑191467
    S3‑191658 Draft TS 33.517 Nokia draft TS Approval Yes
Yes
approved No    
7.2.8 Network Resource Function (NRF) (TS 33.518) S3‑191397 Discussion on the security test of NRF authorization Huawei, Hisilicon discussion Discussion Yes
YesEricsson: 33.926 should contain the threat part. Huawei: we just want to show that the threat exists and we can ome back later with a contribution for 33.926.
noted No    
    S3‑191398 Way forward on the security test of NRF authorization Huawei, Hisilicon discussion Endorsement Yes
YesEricsson: not clear what we are endorsing. It was generally agreed and the wording was worked out offline.
revised No S3‑191662  
    S3‑191662 Way forward on the security test of NRF authorization Huawei, Hisilicon discussion Endorsement Yes
Yes
endorsed No   S3‑191398
    S3‑191399 Security Assurance Requirement and Test for NRF authorization on the NF discovery Huawei, Hisilicon pCR Approval Yes
YesNokia preferred to have another name for the test. They had other comments that had to be taken offline.
revised No S3‑191663  
    S3‑191663 Security Assurance Requirement and Test for NRF authorization on the NF discovery Huawei, Hisilicon pCR Approval Yes
Yes
approved No   S3‑191399
    S3‑191468 New Annex for the NRF in TR 33.926 Nokia, Nokia Shanghai Bell draftCR Approval Yes
Yes
revised No S3‑191664  
    S3‑191664 New Annex for the NRF in TR 33.926 Nokia, Nokia Shanghai Bell draftCR Approval Yes
Yes
approved No   S3‑191468
    S3‑191665 Draft TS 33.518 Nokia draft TS Approval Yes
Yes
approved No    
7.2.9 Network Exposure Function (NEF) (TS 33.519)                      
7.3 eMCSec R16 security (MCXSec) (Rel-16) S3‑191157 LS on LI Impacts for LMR-LTE Interworking study S3i190281 LS in   Yes
Yes
noted No    
    S3‑191171 [33.180] R16 Pre-established PCK Motorola Solutions UK CR Agreement Yes
Yes
revised No S3‑191647  
    S3‑191647 [33.180] R16 Establishment of PCK for MCData Samsung CR Agreement Yes
Yes
agreed No   S3‑191171
7.4 Security aspects of single radio voice continuity from 5GS to UTRAN () (Rel-16) S3‑191384 a skeleton of security aspects of 5G SRVCC to UTRAN Huawei, Hisilicon CR Approval Yes
YesORANGE: plenary decision is against X.3 (return from UTRAN to E-UTRAN or NR). We donít need it. Huawei clarified that this wasn't a CR but a draftCR. Qualcomm commented that this was a baseline, with agreed changes from the Kochi meeting; removing X.3 would need another contribution. It was agreed to remove X.3. The living document/draft CR will be in 648 and will capture the agreements of this meeting.
not pursued No    
    S3‑191500 Key derivation for SRVCC from 5G to UTRAN CS Qualcomm Incorporated discussion Endorsement Yes
Yes
endorsed No    
    S3‑191382 security procedures of 5G SRVCC to UTRAN Huawei, Hisilicon CR Approval Yes
YesContent will be merged with China Unicom's agreed content in 649.
not pursued No    
    S3‑191293 Key derivation during SRVCC from 5G to UTRAN CS China Unicom,CATT CR   Yes
YesX.1.2 will be removed and the content merged with Huawei's contribution.
not pursued No    
    S3‑191294 Emergency call in SRVCC from NR to UTRAN China Unicom, CATT CR   Yes
YesORANGE: the second paragraph doesn't make any sense.What keys are derived in here? It was clarified that the handing over to 3G should be similar as the procedure in 4G, so the wording should explain this better. Content will merge into 649.
not pursued No    
    S3‑191648 skeleton of security aspects of 5G SRVCC to UTRAN China Unicom draftCR Approval Yes
YesNew version of the living document.
approved No    
    S3‑191649 Security procedures of 5G SRVCC to UTRAN Huawei,China Unicom,CATT other Approval Yes
Yes
approved No    
7.5 Enhancements for Security aspects of Common API Framework for 3GPP Northbound APIs (eCAPIF-Sec) (Rel-16) S3‑191547 Security Requirements for CAPIF-3e/4e/5e reference points Samsung CR Approval Yes
Yes
agreed No    
7.6 Other work areas                      
7.6.1 SAE/LTE Security                      
7.6.2 IP Multimedia Subsystem (IMS) Security S3‑191590 Secure LI Data Access Living Document BT plc other Agreement No
Yes
withdrawn Yes    
7.6.3 Network Domain Security (NDS)                      
7.6.4 UTRAN Network Access Security                      
7.6.5 GERAN Network Access Security                      
7.6.6 Generic Authentication Architecture (GAA)                      
7.6.7 Security Aspects of Home(e)NodeB (H(e)NB)                      
7.6.8 Mission Critical (MCPTT, MCSec, eMCSec, MONASTERY_SEC) S3‑191113 [MCPTT] 33179 R13. Clarification of the references to RFC 3711 Airbus DS SLC CR Approval Yes
YesMotorola: it should be 40 bits. Airbus: the way it is written it refers to 32 bits. Motorola: standards says 32 bits, errata says 40 bits. We need to use 40 bits.
revised No S3‑191641  
    S3‑191641 [MCPTT] 33179 R13. Clarification of the references to RFC 3711 Airbus DS SLC CR Approval Yes
Yes
agreed No   S3‑191113
    S3‑191114 [MCSec] 33180 R14. Clarification of the references to RFC 3711 Airbus DS SLC CR Approval Yes
Yes
revised No S3‑191642  
    S3‑191642 [MCSec] 33180 R14. Clarification of the references to RFC 3711 Airbus DS SLC CR Approval Yes
Yes
agreed No   S3‑191114
    S3‑191115 [MCSec] 33180 R15. Clarification of the references to RFC 3711 Airbus DS SLC CR Approval Yes
Yes
revised No S3‑191643  
    S3‑191643 [MCSec] 33180 R15. Clarification of the references to RFC 3711 Airbus DS SLC CR Approval Yes
Yes
agreed No   S3‑191115
    S3‑191165 [33.179] R13 XSD Corrections Motorola Solutions UK CR Agreement Yes
Yes
agreed No    
    S3‑191166 [33.180] R14 XSD Corrections Motorola Solutions UK CR Agreement Yes
Yes
agreed No    
    S3‑191167 [33.180] R15 XSD Corrections (mirror) Motorola Solutions UK CR Agreement Yes
Yes
agreed No    
    S3‑191168 {33.179] R13 Remove IANA editor's notes Motorola Solutions UK CR Agreement Yes
Yes
revised No S3‑191644  
    S3‑191644 {33.179] R13 Remove IANA editor's notes Motorola Solutions UK CR Agreement Yes
Yes
agreed No   S3‑191168
    S3‑191169 [33.180] R14 Remove IANA editorís notes Motorola Solutions UK CR Agreement Yes
Yes
revised No S3‑191645  
    S3‑191645 [33.180] R14 Remove IANA editorís notes Motorola Solutions UK CR Agreement Yes
Yes
agreed No   S3‑191169
    S3‑191170 [33.180] R15 Remove IANA editorís notes (mirror) Motorola Solutions UK CR Agreement Yes
Yes
revised No S3‑191646  
    S3‑191646 [33.180] R15 Remove IANA editorís notes (mirror) Motorola Solutions UK CR Agreement Yes
Yes
agreed No   S3‑191170
    S3‑191542 Discussion on Action Item 94/1 Samsung discussion Endorsement Yes
Yes
noted No    
    S3‑191753 IANA assigned values for mission critical Motorola LS out Approval Yes
Yes
approved No    
7.6.9 Security Assurance Specifications (SCAS-SA3, SCAS_PGW, SCAS_eNB) S3‑191321 Corrections on IP packet forwarding Ericsson CR Agreement Yes
YesMCC commented that Rel-14 and Rel-15 should be changed as well making this CR a mirror. Huawei warned about implications in GSMA's work (NISAs), given that they were using 33.117 and that could affect them. Huawei wanted more time in order to make sure that the Rel-14,Rel-15 didnít have immediate impacts on the pilot testing.
revised No S3‑191632  
    S3‑191632 Corrections on IP packet forwarding Ericsson CR Agreement Yes
YesThe changes of this CR were agreed and Ericsson will bring this CR again in the next meeting; also CRs for Rel-14 and Rel-15 in order to send them to SA as a pack provided that there were no impacts as requested by Huawei.
not pursued No   S3‑191321
7.6.10 Security Aspects of Narrowband IOT (CIoT) S3‑191153 Reply LS on UP Integrity Protection for Small Data in Early Data Transfer R3-191116 LS in   Yes
YesRAN3 will be included in the response for RAN2 LS.
noted No    
    S3‑191140 Reply LS on EDT integrity protection R2-1902439 LS in   Yes
Yes
replied to No    
    S3‑191247 CR for removing EDT UP IP solution using PDCP PDU hashes. Huawei, Hisilicon CR Approval Yes
Yes
merged No S3‑191633  
    S3‑191259 Solution for integrity protection of UL EDT data Intel Corporation (UK) Ltd discussion Decision Yes
Yes
noted No    
    S3‑191440 Correction of ShortResumeMAC-I calculation for EDT Ericsson CR Agreement Yes
Yes
revised No S3‑191633  
    S3‑191633 Correction of ShortResumeMAC-I calculation for EDT Ericsson,Huawei CR Agreement Yes
Yes
agreed No   S3‑191440
    S3‑191441 LS on integrity protection for EDT Ericsson LS out Approval Yes
Yes
noted No    
    S3‑191246 draft reply LS to RAN2/RAN3 on EDT UP IP Huawei, Hisilicon LS out Approval Yes
Yes
revised No S3‑191634  
    S3‑191634 Reply LS to RAN2/RAN3 on EDT UP IP Huawei, Hisilicon LS out Approval Yes
Yes
approved No   S3‑191246
7.6.11 EPC enhancements to support 5G New Radio via Dual Connectivity (EDCE5)                      
7.6.12 Northbound APIs Security for SCEF - SCS/AS Interworking (NAPS_Sec) (Rel-15)                      
7.6.13 Security Aspects of Common API Framework for 3GPP Northbound APIs (CAPIF_Sec) (Rel-15)                      
7.6.14 PLMN RAT selection (Steering of Roaming) (Rel-15)                      
7.6.15 Battery Efficient Security for very low Throughput Machine Type Communication Devices (BEST_MTC_Sec) (Rel-15) S3‑191172 Interface and protocol stack clarifications and corrections to TS 33.163 Juniper Networks CR Approval Yes
YesVodafone: it is not 4 scenarios but three in here. Juniper: four scenarios in Rel-16.
revised No S3‑191635  
    S3‑191635 Interface and protocol stack clarifications and corrections to TS 33.163 Juniper Networks CR Approval Yes
Yes
agreed No   S3‑191172
    S3‑191173 Interface and protocol stack clarifications and corrections to TS 33.163 Juniper Networks CR Approval Yes
Yes
revised No S3‑191636  
    S3‑191636 Interface and protocol stack clarifications and corrections to TS 33.163 Juniper Networks CR Approval Yes
Yes
agreed No   S3‑191173
    S3‑191174 Making UE initiated key refresh optional in TS33.163 Juniper Networks CR   Yes
YesIt was queried whether there was work planned for Rel-16. Vodafone commented that a WID was planned for Rel-17. MCC reminded about the SA's statement on the use of TEI16 WID code and eventually the WID code for Rel-15 was also added in the cover page.
revised No S3‑191637  
    S3‑191637 Making UE initiated key refresh optional in TS33.163 Juniper Networks CR - Yes
Yes
agreed No   S3‑191174
7.6.16 Other work items S3‑191308 Deprecation of TLS 1.1 Ericsson CR Agreement Yes
YesORANGE: why removing reference to RFC4366? Vodafone: add reference in TLS 1.2 in clause 6.2.3. Cover page needed to be fixed as well.
revised No S3‑191638  
    S3‑191638 Deprecation of TLS 1.1 Ericsson CR Agreement Yes
Yes
agreed No   S3‑191308
    S3‑191309 Using EAP-TLS with TLS 1.3 Ericsson discussion Discussion Yes
YesApple: editor's note to consider current discussions in IETF. Ericsson commented that this was a discussion paper and that the CR would come back in the next meeting. Huwaei received confirmation that this would be only for rel-16.
noted No    
    S3‑191310 References to several obsoleted RFCs Ericsson CR Agreement Yes
Yes
agreed No    
    S3‑191311 TLS OCSP stapling Ericsson CR Agreement Yes
YesORANGE: this is a new feature, not a correction. Ericsson clarified that OSCP stapling referred to certificate signing in a way that the certificate authority didnít need to be online. It was commented that Ericsson would come back with the same CR and an accompanying WID for the next meeting.
not pursued No    
    S3‑191312 References to several obsoleted RFCs Ericsson CR Agreement Yes
YesRelying on 1310 discussions.
agreed No    
7.7 New Work Item proposals S3‑191288 WID on security of URLLC Huawei, HiSilicon WID new Endorsement Yes
Yes
revised No S3‑191725  
    S3‑191725 WID on security of URLLC Huawei, HiSilicon WID new Endorsement Yes
Yes
agreed No   S3‑191288
    S3‑191433 Discussion WID 5GS Vertical_LAN_SEC Nokia, Nokia Shanghai Bell discussion Discussion Yes
Yes
noted No    
    S3‑191434 WID proposal for 5GS Vertical_LAN_SEC Nokia, Nokia Shanghai Bell WID new Agreement Yes
Yes
revised No S3‑191726  
    S3‑191726 WID proposal for 5GS Vertical_LAN_SEC Nokia, Nokia Shanghai Bell WID new Agreement No
Yes
agreed No   S3‑191434
8 Studies                      
8.1 Study on Security Aspects of the 5G Service Based Architecture (FS_SBA-Sec) (Rel-15) S3‑191162 Reply LS on User Plane Security for 5GC Roaming SP-190252 LS in   Yes
Yes
noted No    
    S3‑191588 User Plane Security for 5GC Roaming (re: S3-191016) GSMA LS in   Yes
Yes
noted No    
    S3‑191218 Discussion on N9 security Deutsche Telekom AG, NTT Docomo discussion Endorsement Yes
YesEricsson: why is this a discussion and not a key issue? We have an ongoing study.
noted No    
    S3‑191177 Discussion document on roaming UP gateway Juniper Networks discussion Endorsement Yes
YesEricsson: we should study this properly with direct contributions to the TR, instead of discussion papers. Hans (DT) commented that available solutions needed to be discussed and this is what was done in this paper. Ericsson: postpone this for the next meeting with conclusions and evaluations. There was support to endorse this paper so a revision number was given to reformulate the proposal.
revised No S3‑191666  
    S3‑191666 Discussion document on roaming UP gateway Juniper Networks discussion Endorsement Yes
Yes
endorsed No   S3‑191177
    S3‑191175 Corrections for Key Issue #27 Support of a UP gateway function on the N9 interface Juniper Networks pCR Approval Yes
Yes
approved No    
    S3‑191178 Solution for KI #27: Roaming UP gateway Juniper Networks pCR Approval Yes
Yes
merged No S3‑191661  
    S3‑191219 Solution to KI #26: NDS/IP on the inter-PLMN N9 interface Juniper Networks, Nokia pCR Approval Yes
YesBT: add an editor's note on how the control plane enforces policy NDS/IP and N9 security. NTT-Docomo: not the control plane but the SMF who enforces the policy.
revised No S3‑191668  
    S3‑191668 Solution to KI #26: NDS/IP on the inter-PLMN N9 interface Juniper Networks, Nokia pCR Approval Yes
Yes
approved No   S3‑191219
    S3‑191525 eSBA: Solution to KI #27 - UP Gateway function for protection of inter-PLMN N9 interface Nokia, Nokia Shanghai Bell,Juniper pCR Approval Yes
Yes
revised No S3‑191661  
    S3‑191661 eSBA: Solution to KI #27 - UP Gateway function for protection of inter-PLMN N9 interface Nokia, Nokia Shanghai Bell pCR Approval Yes
Yes
approved No   S3‑191525
    S3‑191299 Addition of SEPP requirement on N32 error handling Deutsche Telekom AG, NTT Docomo draftCR Approval Yes
YesIt was clarified that a WID was needed in order to have this eventually as a draftCR converted into a CR. Deutsche Telekom agreed to create a pCR with the key ssue and capture this in TR 33.855 (tdoc 669).
noted No    
    S3‑191469 Error handling for PLMN ID mismatch at SEPP Nokia, Nokia Shanghai Bell draftCR Approval Yes
YesHuawei: we donít include it in SCAS because it's purely for Rel-16. The SCAS WID is based on Rel-15 specifications. Vodafone: on the sentence about the receiving SEPP, this cannot be a "shall". NTT-Docomo: better say "shall support". Huawei: check CT4 specs for the error messages. Vodafone: we are not sending an error message to an attacker. It was questioned whether this was a draftCR since it was part of the study item. This had to be shaped to be inserted into the TR instead. It was decided finally to note the document.
noted No    
    S3‑191484 Discussion paper on Service access authorization for Indirect communication with delegated discovery (Model D) Nokia, Nokia Shanghai Bell discussion Discussion Yes
Yes
noted No    
    S3‑191485 eSBA: Solution to KI #22 - Service access authorization for Indirect Communication with delegated discovery (Model D) Nokia, Nokia Shanghai Bell pCR Approval Yes
YesEricsson: different deployment scenarios should be considered. An editor's note was added about this.
revised No S3‑191671  
    S3‑191671 eSBA: Solution to KI #22 - Service access authorization for Indirect Communication with delegated discovery (Model D) Nokia, Nokia Shanghai Bell pCR Approval Yes
Yes
approved No   S3‑191485
    S3‑191490 eSBA: Solution to KI#22 - Service access authorization for Indirect Communication without delegated discovery (Model C) Nokia, Nokia Shanghai Bell pCR Approval Yes
Yes
approved No    
    S3‑191521 eSBA: Solution to KI #21: Protection of SeCoP interfaces Nokia, Nokia Shanghai Bell pCR Approval Yes
Yes
approved No    
    S3‑191523 eSBA: Solution to KI #23: NF to NF authentication and authorization in Indirect communications model Nokia, Nokia Shanghai Bell pCR Approval Yes
Yes
revised No S3‑191672  
    S3‑191672 eSBA: Solution to KI #23: NF to NF authentication and authorization in Indirect communications model Nokia, Nokia Shanghai Bell pCR Approval Yes
YesAdding editor's note on the different deployment scenarios. Added statement on key issue addressed.
approved No   S3‑191523
    S3‑191403 Key issue on authorization for delegated "Subscribe-Notify" interaction scenarios Huawei, Hisilicon pCR Approval Yes
YesVodafone: this is not written as a key issue. A key issue is not a study.
revised No S3‑191673  
    S3‑191673 Key issue on authorization for delegated "Subscribe-Notify" interaction scenarios Huawei, Hisilicon pCR Approval Yes
Yes
approved No   S3‑191403
    S3‑191404 New solution for delegated "Subscribe-Notify" interaction authorization Huawei, Hisilicon pCR Approval Yes
Yes
approved No    
    S3‑191415 New KI: Access token sharing between NFs Huawei, Hisilicon pCR Approval Yes
YesVodafone didn't agree with the solution. Deutsche Telekom: the potential requirement is too weak.
noted No    
    S3‑191416 New solution for service access authorization within a NF Set Huawei, Hisilicon pCR Approval Yes
YesVodafone: the text of the potential requirement does not have any relation to security.Deutsche Telekom and Nokia didnít agree with this change either. The change was removed.
revised No S3‑191674  
    S3‑191674 New solution for service access authorization within a NF Set Huawei, Hisilicon pCR Approval Yes
Yes
approved No   S3‑191416
    S3‑191532 eSBA: NF Consumer authentication for based on signed API Request Nokia, Nokia Shanghai Bell pCR Approval Yes
Yes
noted No    
    S3‑191675 eSBA: NF Consumer authentication for based on signed API Request Nokia, Nokia Shanghai Bell pCR Approval No
Yes
withdrawn Yes    
    S3‑191176 Solution to KI #26: NDS/IP on the inter-PLMN N9 interface Juniper Networks pCR Approval Yes
Yes
withdrawn Yes    
    S3‑191183 On configurational error handling on N32 by the receiving SEPP Deutsche Telekom AG discussion Endorsement No
Yes
withdrawn Yes    
    S3‑191184 Addition of SEPP requirement on configurational error handling Deutsche Telekom AG draftCR Approval Yes
Yes
withdrawn Yes    
    S3‑191667 Draft TR 33.855 Deutsche Telekom draft TR Approval Yes
Yes
approved No    
    S3‑191669 Key issue of signalling between SEPP and IPX provider Deutsche telekom pCR Approval Yes
Yes
approved No    
8.2 Study on Long Term Key Update Procedures (FS_LTKUP) (Rel-16)                      
8.3 Study on Supporting 256-bit Algorithms for 5G (FS_256-Algorithms) (Rel-16)                      
8.4 Security aspects of single radio voice continuity from 5G to UTRAN (FS_5G_UTRAN_SEC) (Rel-16) S3‑191295 Overview of TR33.856 China Unicom CR   Yes
Yes
revised No S3‑191788  
    S3‑191788 Overview of TR33.856 China Unicom CR - Yes
Yes
agreed No   S3‑191295
    S3‑191296 Content of clause 3 for TR33.856 China Unicom, CATT CR   Yes
Yes
agreed No    
8.5 Study on authentication and key management for applications based on 3GPP credential in 5G IoT (FS_AKMA)(Rel-16) S3‑191561 Meeting minutes of AKMA conference calls China Mobile discussion Information Yes
Yes
not treated No    
    S3‑191537 Work Plan for moving forward AKMA China Mobile discussion Endorsement Yes
Yes
not treated No    
    S3‑191554 Editorial Changes to TR 33.835 v0.4.0 China Mobile pCR Approval Yes
Yes
not treated No    
    S3‑191213 Restoring lost figures in the latest draft update of AKMA TR at SA3 #94ah NEC Europe Ltd pCR Approval Yes
Yes
not treated No    
    S3‑191479 Restore figures in Solution 3 Ericsson pCR Approval Yes
Yes
not treated No    
    S3‑191408 New KI: AKMA push Huawei, Hisilicon pCR Approval Yes
Yes
not treated No    
    S3‑191179 Update of solution #17 Ė Efficient key derivation for e2e security KPN pCR Approval Yes
Yes
not treated No    
    S3‑191211 Resolving Editorís Notes and adding conclusion to solution #18 (Key Separation for AKMA AFs using counters) NEC Europe Ltd pCR Approval Yes
Yes
not treated No    
    S3‑191212 Resolving Editorís Notes and adding conclusion to solution #20 (Key Identification when Implicit bootstrapping is used) NEC Europe Ltd pCR Approval Yes
Yes
not treated No    
    S3‑191290 Evaluation for solution 4 Huawei, HiSilicon pCR Approval Yes
Yes
not treated No    
    S3‑191386 Resovle Editor's notes in Solution for Key freshness in AKMA Huawei, Hisilicon pCR Approval Yes
Yes
not treated No    
    S3‑191471 Solution 2 Evaluation Ericsson pCR Approval Yes
Yes
not treated No    
    S3‑191472 Solution 3 Evaluation Ericsson pCR Approval Yes
Yes
not treated No    
    S3‑191534 AKMA: Implicit bootstrapping using NEF as the AKMA Anchor Function Nokia, Nokia Shanghai Bell pCR Approval Yes
Yes
not treated No    
    S3‑191548 Individual Evaluations of solution #7- #12 China Mobile pCR   Yes
Yes
not treated No    
    S3‑191558 Individual Evaluation of solution #6 China Mobile pCR Approval Yes
Yes
not treated No    
    S3‑191187 AKMA solution set analysis KPN discussion Discussion Yes
Yes
not treated No    
    S3‑191540 Discussion on AKMA overall evaluation methodology China Mobile, ZTE Corporation discussion Endorsement Yes
Yes
not treated No    
    S3‑191545 pCR of clause 7- evaluation and conclusion China Mobile pCR Approval Yes
Yes
not treated No    
    S3‑191210 Discussion on AKMA overall conclusions NEC Europe Ltd discussion Endorsement Yes
Yes
not treated No    
    S3‑191544 pCR of clause 7- evaluation and conclusion China Mobile pCR Approval No
Yes
withdrawn Yes    
    S3‑191546 pCR of clause 7- evaluation and conclusion China Mobile pCR Approval No
Yes
withdrawn Yes    
    S3‑191557 Individual Evaluation of solution #6 China Mobile pCR Approval No
Yes
withdrawn Yes    
8.6 Study on evolution of Cellular IoT security for the 5G System (FS_CIoT_sec_5G) (Rel-16) S3‑191435 CIoT: Definitions and Abbreviations Ericsson pCR Approval Yes
YesVodafone: Some of these are already in 21.905. NTT-Docomo: there may be other acronyms that can be added here.
revised No S3‑191676  
    S3‑191676 CIoT: Definitions and Abbreviations Ericsson pCR Approval Yes
Yes
approved No   S3‑191435
    S3‑191229 New KI: Separation of CP and UP in NAS CP Optimization Nokia, Nokia Shanghai Bell pCR Approval Yes
YesNokia admitted that this issue could be late for this Release and asked if it was to be pushed for the next release. Vodafone: this doesnít seem to be a security issue. Qualcomm had the same concern. If CT groups had a problem with this they should contact SA3. CableLabs: this can cause denial of service. I agree with this key issue. Vodafone understood the idea but didnít agree with the writing. Qualcomm: SA2 decided not to procceed with this one. ORANGE didnít agree with this key issue. This was taken offline.
noted No    
    S3‑191248 EDT UP IP for multiple PDCP PDUs Huawei, Hisilicon discussion Endorsement Yes
Yes
noted No    
    S3‑191249 update solution#4 with UP IP during EDT for multiple PDCP PDUs. Huawei, Hisilicon pCR Approval Yes
YesEricsson: split into two separate solutions. Overlapping with 437. Huawei: we are not bringing another solution, just details for an existing solution.
revised No S3‑191678  
    S3‑191678 update solution#4 with UP IP during EDT for multiple PDCP PDUs. Huawei, Hisilicon pCR Approval Yes
YesIt was agreed to fix a typo and replace gNodeB.
approved No   S3‑191249
    S3‑191437 CIoT: Update to Solution #4 Ericsson pCR Approval Yes
Yes
revised No S3‑191679  
    S3‑191679 CIoT: Update to Solution #4 Ericsson pCR Approval Yes
YesRevised as a completely new solution. Editors note from Qualcomm. Reformulation from Vodafone.
approved No   S3‑191437
    S3‑191436 CIoT: Evaluation to Solution #4 Ericsson pCR Approval Yes
Yes
noted No    
    S3‑191180 Update of Solution #6 Ė Use of UE Configuration Update KPN pCR Approval Yes
YesEditor's note on maximum amount of minutes as proposed by Vodafone. Vodafone: more likely that it's an malicious application. Evaluation part was removed.
revised No S3‑191680  
    S3‑191680 Update of Solution #6 Ė Use of UE Configuration Update KPN pCR Approval Yes
Yes
approved No   S3‑191180
    S3‑191252 Updating solution#7 Huawei, Hisilicon pCR Approval Yes
YesVodafone: this needs rewording. Ericsson: other Ues can take turns when attacking. Huawei: it's an engineering issue. Vodafone: there is no way of permanently block a misbehaving UE. Huawei: the gNodeB informs the core network to do something about it and we donít specify more than that.
revised No S3‑191681  
    S3‑191681 Updating solution#7 Huawei, Hisilicon pCR Approval Yes
Yes
approved No   S3‑191252
    S3‑191510 Resolving EN in Solution 9 Qualcomm Incorporated pCR Approval Yes
YesVodafone: very confusing. Not an outstanding issue since it will be treated in Rel-16 as written here. Huawei: this CIoT activity depends on SA2's agreements and here it seems that we deviating from that. This needed reformulating and Huawei wanted to include a reference to the work in SA2.
revised No S3‑191682  
    S3‑191682 Resolving EN in Solution 9 Qualcomm Incorporated pCR Approval Yes
YesHuawei commented and asked to be minuted: "All solutions which include short UP packets in NAS messages, e.g., Registration Request, Registration Complete, etc. depend on SA2 decision"
approved No   S3‑191510
    S3‑191511 Resolving EN in Solution 10 Qualcomm Incorporated pCR Approval Yes
Yes
revised No S3‑191683  
    S3‑191683 Resolving EN in Solution 10 Qualcomm Incorporated pCR Approval Yes
Yes
approved No   S3‑191511
    S3‑191365 Delete EN in solution12 Huawei, Hisilicon pCR Approval Yes
YesVodafone: time limit to the filters?An editor's note was added for this. Reference to the relevant spec in SA2 in step 4 was added.
revised No S3‑191684  
    S3‑191684 Delete EN in solution12 Huawei, Hisilicon pCR Approval Yes
Yes
approved No   S3‑191365
    S3‑191366 Add evalution in solution12 Huawei, Hisilicon pCR Approval Yes
YesVodafone: reformulate the last two sentences. Ericsson: If PDU sessions are not terminated the network will keep the PDU sessions open and this would be a waste or resources. In the end Ericsson conceded and the revision only took care of the rewording.
revised No S3‑191685  
    S3‑191685 Add evalution in solution12 Huawei, Hisilicon pCR Approval Yes
Yes
approved No   S3‑191366
    S3‑191189 Proposal for improvement FS_CIoT_sec_5G solution #15 Philips International B.V. pCR Approval Yes
Yes
revised No S3‑191686  
    S3‑191686 Proposal for improvement FS_CIoT_sec_5G solution #15 Philips International B.V. pCR Approval Yes
Yes
approved No   S3‑191189
    S3‑191188 Proposal for editor's notes in FS_CIoT_sec_5G solution #15 Philips International B.V. pCR Approval Yes
YesVodafone: this needs rewriting. Qualcomm suggested an editor's note. Vodafone wanted a statement in the evaluation on injected first messages. MCC added that the use of "must" was not allowed in 3GPP and it needed rewording.
revised No S3‑191687  
    S3‑191687 Proposal for editor's notes in FS_CIoT_sec_5G solution #15 Philips International B.V. pCR Approval Yes
Yes
approved No   S3‑191188
    S3‑191388 Resolve ENs on Solution to Mitigate DDoS Attack based on RAN Huawei, Hisilicon pCR Approval Yes
YesVodafone didnít agree with the term "massive misbehaving infrequent CIOT Ues". Huawei replied that this was coming from SA2. Vodafone: how do you get out of the blacklist? Huawei: there is a timer. Vodafone: this timer doesnít appear in here. The blacklist applies to a collection of Ues and not a single UE. The timer applies to which UE? The first one? An editor's note was added to address this.
revised No S3‑191688  
    S3‑191688 Resolve ENs on Solution to Mitigate DDoS Attack based on RAN Huawei, Hisilicon pCR Approval Yes
Yes
approved No   S3‑191388
    S3‑191389 Solution to Mitigate DDoS Attack based on RAN Caused by Massive Misbehaving Frequent CIoT Ues Huawei, Hisilicon pCR Approval Yes
YesVodafone: now the CIoT Ues are frequent, whereas in other contributions they were infrequent.Huawei replied that this was to be reworded like in the previous contribution and that the term "frequent" was coming from SA2.
merged No S3‑191688  
    S3‑191390 Solution to Mitigate DDoS Attack on AMF caused by Massive Misbehaving Infrequent CIoT Ues Huawei, Hisilicon pCR Approval Yes
Yes
revised No S3‑191689  
    S3‑191689 Solution to Mitigate DDoS Attack on AMF caused by Massive Misbehaving Infrequent CIoT Ues Huawei, Hisilicon pCR Approval Yes
YesWording changes as proposed by Vodafone.
approved No   S3‑191390
    S3‑191438 CIoT: Conclusion to KI#2 and KI#3 Ericsson pCR Approval Yes
Yes
noted No    
    S3‑191234 conclusion on KI#5 Huawei, Hisilicon pCR Approval Yes
YesIt was queried whether anyone was going to bring another solution. Ericsson preferred to postpone this for the next meeting.
noted No    
    S3‑191677 Draft TR 33.861 Ericsson draft TR Approval No
Yes
left for email approval No    
8.7 Study on the security of the Wireless and Wireline Convergence for the 5G system architecture (FS_5WWC_SEC) (Rel-16) S3‑191123 LS on SUPI formats for 5WWC C1-192776 LS in   Yes
Yes
noted No    
    S3‑191139 Response to 3GPP SA2 liaison S2-1902902 on ĎLS on updating the status of 5WWC normative workí BBF LS in   Yes
Yes
noted No    
    S3‑191586 Residential use case for 5G Core with fixed broadband access CableLabs LS in   Yes
Yes
noted No    
    S3‑191193 New KI for TR 33.807: Authentication of UE without NAS support and without 3GPP RAT behind a FN-RG or 5G-CRG with 5GC CableLabs pCR Approval Yes
Yes
revised No S3‑191702 S3‑191192
    S3‑191702 New KI for TR 33.807: Authentication of UE without NAS support and without 3GPP RAT behind a FN-RG or 5G-CRG with 5GC CableLabs pCR Approval Yes
Yes
noted No   S3‑191193
    S3‑191138 Reply LS on Authentication for UEs not Supporting NAS S2-1904829 LS in   Yes
Yes
replied to No    
    S3‑191713 Reply LS on Authentication for UEs not Supporting NAS Nokia LS out approval Yes
Yes
approved No    
    S3‑191221 Discussion on proposed response to incoming LS (S3-191138) on authentication of UEs not supporting NAS Charter Communications, CableLabs discussion Discussion Yes
YesOn question one: ORANGE: stick to what is written in TS 33.501. There are statements here that donít adhere to what is in the spec. Ericsson: it is not sufficient because it is a Rel-15 spec and this is new material for Rel-16. BT didnít agree, it's the storage what matters. Telecom Italia: SA2's interest lies in TS 33.501 annex B only. Cablelabs replied that there was a key issue on 5WWC. Charter communications: consider the Rel-16 context only, not Rel-15. AT&T: use the EAP framework if you want to use the 3GPP network. Charter Communications: this is cable access, not 3GPP access. ORANGE: if the use case is similar for non-public networks it is perfectly fine to use annex B of TS 33.501. In 5WWC the case is different. Nokia: is it possible for 3GPP to support this in Rel-16? Vodafone: Non private networks should not be in the scope of this TR, otherwise we will have a whole range of new use cases that will blur the security. Charter: Non public networks is another WID that doesnít cover fixed access. Telecom Italia: 5WWC should not just use annex B, they need to stick to the TR. This had to be taken offline.
revised No S3‑191703  
    S3‑191703 Discussion on proposed response to incoming LS (S3-191138) on authentication of UEs not supporting NAS Charter Communications, CableLabs discussion Discussion No
Yes
noted No   S3‑191221
    S3‑191318 New Key Issue: SUCI-to-SUPI mapping for the FN-RG Ericsson pCR Approval Yes
YesORANGE: replace visited network by serving network since are not covering roaming now. Telecom Italia: How is the SUCI computed in the Home gateway if it doesnít have an UICC? Ericsson replied that it wasn't computed by the home gateway but somewhere else in the network. Telecom Italia: potential architecture requirement instead of a security requirement? Ericsson SUCI to SUPI mapping is in our scope and we need to tell SA2 about this. Telecom Italia suggested that this had to be described as a security requirement, with a threat and so on. Vodafone agreed. Vodafone: the key issue is the mapping of SUCI to SUPI. The security threat was not related and scrapped from here.
revised No S3‑191690  
    S3‑191690 New Key Issue: SUCI-to-SUPI mapping for the FN-RG Ericsson pCR Approval Yes
Yes
approved No   S3‑191318
    S3‑191319 New Solution: SUCI-to-SUPI mapping for the FN-RG Ericsson pCR Approval Yes
YesNokia: the mapping is not explained. Huawei: a similar figure is available in the TR (solution #4) and there is a bunch of editor's notes in there as well. This solution exists already.Bring this back in the next meeting detailing the mapping. Nokia supported this.
noted No    
    S3‑191371 Add introduction part Huawei, Hisilicon pCR Approval Yes
YesORANGE: the introduction is not needed. MCC: the first two sentences are in fact the scope of the document. Only the reference part stays.
revised No S3‑191706  
    S3‑191706 Add references Huawei, Hisilicon pCR Approval Yes
Yes
approved No   S3‑191371
    S3‑191372 Add content to clause 4 Huawei, Hisilicon pCR Approval Yes
YesEricsson: refer to relevant SA2 specs. Nokia: refer to all possible scenarios.
revised No S3‑191707  
    S3‑191707 Add content to clause 4 Huawei, Hisilicon pCR Approval Yes
Yes
approved No   S3‑191372
    S3‑191373 Delete Editor's Note in KI#4 Huawei, Hisilicon pCR Approval Yes
Yes
revised No S3‑191708  
    S3‑191708 Delete Editor's Note in KI#4 Huawei, Hisilicon pCR Approval Yes
YesThe requirement was removed since the security of the nterface was not in the scope of the document.
approved No   S3‑191373
    S3‑191374 Add requirement and delete EN for KI#13 Huawei, Hisilicon pCR Approval Yes
Yes
revised No S3‑191709  
    S3‑191709 Add requirement and delete EN for KI#13 Huawei, Hisilicon pCR Approval Yes
YesRemoving the e.g. as proposed by Ericsson.
approved No   S3‑191374
    S3‑191375 Delete one Editorís Note in solution3 Huawei, Hisilicon pCR Approval Yes
Yes
approved No    
    S3‑191376 Delete EN for solution 5 Huawei, Hisilicon pCR Approval Yes
Yes
approved No    
    S3‑191317 New Solution: Transport security for the interfaces between W-5GAN and 5GC Ericsson pCR Approval Yes
YesHuawei: simplify the content, no need to list every interface.
approved No    
    S3‑191377 Add conclusion on KI#3 Huawei, Hisilicon pCR Approval Yes
YesTelecom Italia: getting to a solution without an evaluation?
revised No S3‑191711  
    S3‑191711 Add conclusion on KI#3 Huawei, Hisilicon pCR Approval Yes
YesFirst paragraph: reference to the solution. Second paragraph is gone as proposed by Nokia.
approved No   S3‑191377
    S3‑191378 Add Conclusion on KI#4 Huawei, Hisilicon pCR Approval Yes
Yes
approved No    
    S3‑191486 Evaluation of Solution #1 Lenovo, Motorola Mobility pCR Approval Yes
Yes
revised No S3‑191712  
    S3‑191712 Evaluation of Solution #1 Lenovo, Motorola Mobility pCR Approval Yes
Yes
approved No   S3‑191486
    S3‑191192 New KI for TR 33.807: Authentication of UE without NAS support and without 3GPP RAT behind a FN-RG or 5G-CRG with 5GC CableLabs pCR Approval Yes
Yes
revised No S3‑191193  
    S3‑191710 Draft TR 33.807 Huawei draft TR Approval Yes
Yes
approved No    
8.8 Study on Security Aspects of PARLOS (FS_PARLOS_Sec) (Rel-16) S3‑191527 Providing some evaluation for solution #2 in TR 33.815 Qualcomm Incorporated, Sprint, Nokia, Nokia Shanghai Bell pCR Approval Yes
Yes
revised No S3‑191593  
    S3‑191528 Proposed conclusion for establishing the RLOS call Qualcomm Incorporated pCR Approval Yes
Yes
revised No S3‑191594  
    S3‑191541 pCR to 33.815 on authentication of network NTT DOCOMO pCR Approval Yes
YesQualcomm: this assumes that the user has an active USIM, but this is not what's happening in SA1.SA2. They didnít agree with the key issue. Sony supported Qualcomm. ORANGE supported the requirement. Vodafone: how do you identify that you are an US person without credentials?Only US customers would expect this service. Vodafone supported this key issue. Deutsche Telekom wanted to have this key issue as well. There was a big risk of weakening the security to satisfy a specific issue for US customers. Ericsson: this key issue is against the PARLOS concept. IDEMIA supported the key issue. Nokia: this is written with the assumption that this will be an universal feature, and this is not the way it should be addresses. I donít agree with the key issue. Samsung supported this. NTT-Docomo: International (non-US) customers would have to deal with the fact that they will possess an UE vulnerable to man-in-the-middle attacks. BT supported Docomo. There was no agreement with this document.
noted No    
    S3‑191550 Clarification to Solution#1 of PARLOS Samsung pCR Approval Yes
YesVodafone: any authentication in the PARLOS network here? Samsung: it's just an update on an existing procedure. Vodafone wasn't sure that this would work technically. ORANGE: evaluation needs to be updated, add it here. Maybe add a note on the technical feasbility of this solution.
noted No    
    S3‑191727 Clarification to Solution#1 of PARLOS Samsung pCR Approval No
Yes
withdrawn Yes    
    S3‑191593 Providing some evaluation for solution #2 in TR 33.815 Qualcomm Incorporated, Sprint, Nokia, Nokia Shanghai Bell, Ericsson, Verizon UK Ltd pCR Approval Yes
YesBT: no need for man in the middle. The attacker can just call asking the user to make a call to to PARLOS. Qualcomm: it doesnít need to be an RLOS number, it can be a premium number or whatever. Vodafone:add an editor's note on the hability of the user to identify the trust of the PARLOS network needing to be provided. NTT-Docomo: paragraph three needs to go away.
revised No S3‑191728 S3‑191527
    S3‑191728 Providing some evaluation for solution #2 in TR 33.815 Qualcomm Incorporated, Sprint, Nokia, Nokia Shanghai Bell, Ericsson, Verizon UK Ltd pCR Approval Yes
Yes
approved No   S3‑191593
    S3‑191594 Proposed conclusion for establishing the RLOS call Qualcomm Incorporated, Ericsson, Verizon UK Ltd pCR Approval Yes
Yes
revised No S3‑191595 S3‑191528
    S3‑191595 Proposed conclusion for establishing the RLOS call Qualcomm Incorporated, Nokia, Nokia Shanghai Bell, Ericsson, Verizon UK Ltd pCR Approval Yes
Yes
noted No   S3‑191594
    S3‑191729 Draft TR 33.815 Qualcomm draft TR Approval Yes
Yes
approved No    
8.9 Study on 5G security enhancement against false base stations S3‑191391 Solution for Protection of RRCReject Message Huawei, Hisilicon pCR Approval Yes
Yes
not treated No    
    S3‑191393 Add New Security Threat and Requirement for Key Issue #1 for Protection of NAS Reject Message Huawei, Hisilicon pCR Approval Yes
Yes
revised No S3‑191789  
    S3‑191789 Add New Security Threat and Requirement for Key Issue #1 for Protection of NAS Reject Message Huawei, Hisilicon pCR Approval Yes
YesEricsson didnít agree with the requirement, so an editor's note was added as suggested bu NTT-Docomo.
approved No   S3‑191393
    S3‑191392 Solution for Protection of NAS Reject Message Huawei, Hisilicon pCR Approval Yes
Yes
not treated No    
    S3‑191240 Secuirty threat for RRCResumeRequest tampering. Huawei, Hisilicon pCR Approval Yes
Yes
approved No    
    S3‑191241 Solution for protecting RRCResumeRequest against tampering Huawei, Hisilicon pCR Approval Yes
Yes
approved No    
    S3‑191242 Address EN in solution #1 ďThe above text needs to be updated Ö.Ē Huawei, Hisilicon pCR Approval Yes
Yes
not treated No    
    S3‑191243 Draft LS to RAN2 on UECapabilitiesEnquire after AS SMC Huawei, Hisilicon LS out Approval Yes
Yes
not treated No    
    S3‑191345 Protection of unicast message Apple Computer Trading Co. Ltd pCR Approval Yes
Yes
revised No S3‑191620  
    S3‑191620 Protection of unicast message Apple Computer Trading Co. Ltd pCR Approval No
YesQualcomm added three editor's notes related to the key provisioning from 781 and one on camping. ORANGE also added some editor's notes and corrections.
approved No   S3‑191345
    S3‑191454 New solution (SERSI - SERving network controlled SI signatures) - builds on Solution#7 Ericsson pCR Approval Yes
YesApple: to be merged to solution 7. Add an editor's note on the assesment of this. Qualcomm, ORANGE: we need to reformat the existing solution. Samsung,Intel supported the editor's note in order to move forward. ORANGE wanted to restructure the contribution firstly. AT&T supported having this in. Ericsson: merge with solution 7, there are 10 companies supporting this. AT&T: reformatting is editorial, there is no technical justification against this. CableLabs supported AT&T. Telecom Italia was against having this in. The vice chair (Docomo) proposed to minute: This type of solution should go in but it needs to come back with the proper formatting according to Annex A. There was opposition to the formatting but a general agreement to the solution. The vice chair encouraged to discuss offline on this document and noted it.
noted No    
    S3‑191195 Using symmetric algorithm with assistance of USIM and home network ZTE Corporation pCR Approval Yes
Yes
approved No    
    S3‑191508 Shared key based MIB/SIB protection Qualcomm Incorporated pCR Approval Yes
Yes
revised No S3‑191780  
    S3‑191780 Shared key based MIB/SIB protection Qualcomm Incorporated pCR Approval Yes
YesAdding an editor's note as proposed by Huawei.
approved No   S3‑191508
    S3‑191267 Certificate based solution for 5GFBS Apple Computer Trading Co. Ltd pCR Approval Yes
Yes
revised No S3‑191781  
    S3‑191781 Certificate based solution for 5GFBS Apple Computer Trading Co. Ltd pCR Approval Yes
YesIntroducing editor's notes as proposed by ORANGE: roaming aspects, MNO controlling the revocation of CA, other signature algorithms are FFS. Qualcomm: issue of camping needs to be clarified.Editor's note on this was added. Also editor's notes on the manufacturing time, interworking with UE USIM and gNodeB.
approved No   S3‑191267
    S3‑191268 ID based solution for 5GFBS Apple Computer Trading Co. Ltd pCR Approval Yes
YesORANGE: Threats are not mitigated with signed messages,roaming scenarios are FFS. Qualcomm: PKG deployment is FFS. MCC: add references to IEEE, RFC, ISO SC27 and other mentioned bodies.
revised No S3‑191782  
    S3‑191782 ID based solution for 5GFBS Apple Computer Trading Co. Ltd pCR Approval Yes
Yes
approved No   S3‑191268
    S3‑191235 Resolve EN "signaling details of how the UE hands over to false base station Huawei, Hisilicon pCR Approval Yes
Yes
not treated No    
    S3‑191236 Solution #6: Resolve EN Handover Attemp Failure Counter Huawei, Hisilicon pCR Approval Yes
Yes
not treated No    
    S3‑191237 Solution#4: resolving EN network verification of the hashes of MIB/SIBs Huawei, Hisilicon pCR Approval Yes
Yes
not treated No    
    S3‑191238 Solution#4: Resolving EN Impact on UE power consumption Huawei, Hisilicon pCR Approval Yes
Yes
not treated No    
    S3‑191239 Solution #4: Details on the hash algorithm used for MIB/SIB hashes. Huawei, Hisilicon pCR Approval Yes
Yes
not treated No    
    S3‑191251 Enabling UE to detect FBS Huawei, Hisilicon pCR Approval Yes
Yes
noted No    
    S3‑191455 Conclusion on KI#3'S second requirement (reactive action) Ericsson pCR Approval Yes
YesHuawei: too early.
noted No    
    S3‑191464 Resolving the ENs in solution #5 Huawei, Hisilicon pCR Approval Yes
Yes
not treated No    
    S3‑191488 Mitigation against the authentication relay attack with different PLMNs Lenovo, Motorola Mobility pCR Approval Yes
YesEricsson: indications in the victim (UE) may or may not be standardised. An editor's note was added for this. Qualcomm: general error handling on the UE may be affected. Editor's note added on this.
revised No S3‑191790  
    S3‑191790 Mitigation against the authentication relay attack with different PLMNs Lenovo, Motorola Mobility pCR Approval Yes
Yes
approved No   S3‑191488
    S3‑191489 Removal of Editorís Notes of Solution #5 Lenovo, Motorola Mobility pCR Approval Yes
Yes
not treated No    
    S3‑191509 Security requirement for KI #7 Qualcomm Incorporated pCR Approval Yes
YesEricsson,Huawei: this is not a requirement, but an evaluation.
noted No    
    S3‑191256 Protecting IOT Devices Against False Base Station Attacks Qihoo 360 discussion Discussion Yes
YesDeutsche Telekom: what's the proposal to endorse? Qihoo: just for discussion. Apple: we can have key issues for these kind of devices. Huawei: we donít know if this has any impact on our study. CableLabs: capture this content somewhere, it's a good input. The Chair suggested Qihoo360 to bring a pCR for the next meeting or some endorsement proposal. Huawei proposed a key issue for the CIoT study.
noted No    
    S3‑191269 Modification for AnnexA Apple Computer Trading Co. Ltd pCR Approval Yes
Yes
not treated No    
    S3‑191347 Way forward for evaluation for every solution Apple Computer Trading Co. Ltd pCR Agreement Yes
Yes
not treated No    
    S3‑191344 Identity based Signature against false base station on Key Issue #2 Huawei, HiSilicon pCR Approval No
Yes
withdrawn Yes    
    S3‑191779 Draft TR 33.809 Apple draft TR Approval No
Yes
left for email approval No    
8.10 Study of KDF negotiation for 5G System Security                      
8.11 Study on Security aspects of Enhancement of Network Slicing (FS_eNS_SEC) (Rel-16) S3‑191227 eNS Update to solution 1 Slice specific secondary authentication Nokia, Nokia Shanghai Bell pCR Approval Yes
YesHuawei: some issues that were agreed not to have here are coming back: secondary authentication in step 11 for example. We should use the term "slice specific authentication". Huawei: this doesnít address key issue 4 (privacy), remove it from the evaluation. Nokia: NAS messages are protected already, no parameter is exposed. ORANGE and Qualcomm agreed: adding a sentence clarifying this would be sufficient. Gemalto: the requirement doesn't show explicit end points, only addresses the privacy of the user.
revised No S3‑191730  
    S3‑191730 eNS Update to solution 1 Slice specific secondary authentication Nokia, Nokia Shanghai Bell pCR Approval Yes
Yes
approved No   S3‑191227
    S3‑191328 Removing ENs for solution #2 Huawei, HiSilicon pCR Approval Yes
Yes
revised No S3‑191732  
    S3‑191732 Removing ENs for solution #2 Huawei, HiSilicon pCR Approval Yes
Yes
approved No   S3‑191328
    S3‑191329 Add Evaluation to Solution #2 Huawei, HiSilicon pCR Approval Yes
Yes
revised No S3‑191733  
    S3‑191733 Add Evaluation to Solution #2 Huawei, HiSilicon pCR Approval Yes
Yes
approved No   S3‑191329
    S3‑191322 Update to solution #3 on NSaaS security features Huawei, HiSilicon pCR Approval Yes
YesNokia: the new text is not clear. ORANGE: secondary authentication is ortogonal to the slices, why is this here?When you configure the secondary authentication you donít know to which external network you are connecting to. Qualcomm agreed with ORANGE. Secondary authentication is a different issue from slice specific authentication.
noted No    
    S3‑191323 Conclusion to KI #3 Huawei, HiSilicon pCR Approval Yes
YesORANGE: it's too early to conclude, some other companies might come back with other solutions.
noted No    
    S3‑191118 Update to solution #4 InterDigital Belgium. LLC pCR Approval Yes
YesNokia: clarify the dependency between the RAT and access type.The document was revised to address this.
revised No S3‑191734  
    S3‑191734 Update to solution #4 InterDigital Belgium. LLC pCR Approval Yes
Yes
approved No   S3‑191118
    S3‑191326 Solution to KI #4 Huawei, HiSilicon pCR Approval Yes
YesNokia: What is this solution about and what is being protected? This is not a new solution. Qualcomm:this doesnít add any value. There is no requirement to protect the user id between the UE and the AAA; we would need to revisit the key issue. Qualcomm proposed to add an editor's note on the above. This was agreed. The evaluation was removed as well.
revised No S3‑191735  
    S3‑191735 Solution to KI #4 Huawei, HiSilicon pCR Approval Yes
Yes
approved No   S3‑191326
    S3‑191327 Conclusion to KI #4 Huawei, HiSilicon pCR Approval Yes
Yes
noted No    
    S3‑191331 Discussions on Key Issue AMF key separation Huawei, HiSilicon discussion Agreement Yes
YesNokia disagreed witht the key issue. The Chair commented that this was discussed in the previous meeting and it had been seen that SA2 pushed this issue to Rel-17. ORANGE: this issue was out of scope in SA2 and they didnít agree with any solution. Huawei is making an invalid interpretation. Nokia: the UE cannot connect to two AMF at the same time. The figure is wrong. Huawei proposed an LS to SA2 if there was no agreement with this paper. ORANGE agreed to ask SA2 if this had been pushed to Rel-17. Qualcomm replied that they had checked the SA2 report and this had been pushed to Rel-17. Huawei disagreed and commented that they had a different interpretation. There wasn't support for the LS. This discussion was noted and all the related documents.
noted No    
    S3‑191332 Overview on solutions to AMF key separation Huawei, HiSilicon discussion Agreement Yes
Yes
noted No    
    S3‑191333 pCR on AMF key separation solutions solution 1 Huawei, HiSilicon pCR Approval Yes
Yes
noted No    
    S3‑191334 pCR on AMF key separation solutions solution 2 Huawei, HiSilicon pCR Approval Yes
Yes
noted No    
    S3‑191335 pCR on AMF key separation solutions solution 3 Huawei, HiSilicon pCR Approval Yes
Yes
noted No    
    S3‑191325 Discussion paper on KI#6 on NSSAI in RRC Huawei, HiSilicon discussion Discussion Yes
Yes
noted No    
    S3‑191324 A solution to NSSAI protection at AS transmission Huawei, HiSilicon pCR Approval Yes
YesORANGE: How the authorised NSSAI for the UE is configured in the serving network needs more details. This was added in an editor's note.
revised No S3‑191736  
    S3‑191736 A solution to NSSAI protection at AS transmission Huawei, HiSilicon pCR Approval Yes
Yes
approved No   S3‑191324
    S3‑191439 Solution to protect user ID over the air interface Ericsson pCR Approval Yes
YesEditor's note added on protection is needed between serving network to AAA server. Secondary authentication was changed to slice specific authentication. Lenovo proposed to remove the evaluation part. This was agreed.
revised No S3‑191738  
    S3‑191738 Solution to protect user ID over the air interface Ericsson pCR Approval Yes
Yes
approved No   S3‑191439
    S3‑191499 Proposed solution for protecting the S-NSSAI for transmission at the AS layer Qualcomm Incorporated pCR Approval Yes
YesIt was agreed to include the same editor's note as 736.
revised No S3‑191737 S3‑190791
    S3‑191737 Proposed solution for protecting the S-NSSAI for transmission at the AS layer Qualcomm Incorporated pCR Approval Yes
Yes
approved No   S3‑191499
    S3‑191360 pCR to TR33.813 - Key issue for deeper UP protection termination CATT pCR   Yes
YesNokia: this is not relevant to Rel-16, maybe for Rel-17. CATT: this is required by the market. Telecom Italia: SA1 addresses this kind of use cases, not here. ORANGE: SA1 should not go into security requirements. ORANGE: we need to control the UPF due to lawful interception requirements. This is material for a new study item. CATT: we wanted to know if this was feasible work for the future.
noted No    
    S3‑191361 pCR to TR33.813 - Key issue for UP key separation CATT pCR   Yes
YesTelecom Italia: this input should start from an SA1 requirement. ORANGE: we need a discussion paper with more details.
noted No    
    S3‑191362 pCR to TR33.813 - Solution for UP key separation CATT pCR   Yes
Yes
noted No    
    S3‑191228 Preliminary comparison of solutions Nokia, Nokia Shanghai Bell pCR Approval Yes
YesNokia clarified that this reflected results before the current meeting. The Chair asked if conclusions should be postponed to the next meeting. Telecom Italia: "not applicable" means no solution? Nokia confirmed this. The table was revised to address the results from the current meeting. Qualcomm: it shouldn't be a conclusion but in an annex. Nokia: the conclusion text should follow this. An overall evaluation clause was added to the conclusion in order to accommodate this table.
revised No S3‑191739  
    S3‑191739 Preliminary comparison of solutions Nokia, Nokia Shanghai Bell pCR Approval Yes
Yes
approved No   S3‑191228
    S3‑191330 Conclusion to KI #1 Huawei, HiSilicon pCR Approval Yes
YesNokia: the conclusion needs to be expanded.
noted No    
    S3‑191731 Draft TR 33.813 Nokia draft TR Approval Yes
Yes
approved No    
8.12 Study on Security of the enhancement to the 5GC location services (FS_eLCS_Sec) (Rel-16) S3‑191141 LS on RAN2 conclusion for NR positioning SI R2-1902479 LS in   Yes
Yes
replied to No    
    S3‑191142 LS on RAN2 conclusion for NR positioning SI R3-191141 LS in   Yes
Yes
noted No    
    S3‑191442 Discussion on RAN2 conclusion for NR positioning SI Ericsson discussion Endorsement Yes
Yes
noted No    
    S3‑191350 LS reply to RAN WG2 LS on broadcast assistance data delivery CATT LS out   Yes
Yes
noted No    
    S3‑191443 LS on security and privacy aspects of NR positioning Ericsson LS out Approval Yes
Yes
revised No S3‑191750  
    S3‑191750 LS on security and privacy aspects of NR positioning Ericsson LS out Approval Yes
Yes
approved No   S3‑191443
    S3‑191364 Reply LS on RAN2 conclusion for NR positioning Huawei, Hisilicon pCR Approval Yes
YesIntel supported this response. CATT wasn't convinced with the physical risk.Qualcomm agreed with this, they preferred to wait for RAN's progress. Huawei: we do have requirements for a secure environment and we should tell them about them. It was agreed that SA3 needed to wait for RAN's progress in this work. CATT: RAN will finish this work in December, our work item will be really delayed.
noted No    
    S3‑191351 pCR to TR33.814 - Key issue for confidentiality protection of broadcast assistance data CATT pCR   Yes
YesQualcomm: we already agreed in the LS in tdoc 600 for a solution for this.
noted No    
    S3‑191353 pCR to TR33.814 - Key issue for integrity protection of broadcast assistance data CATT pCR   Yes
Yes
revised No S3‑191602  
    S3‑191602 pCR to TR33.814 - Key issue for integrity protection of broadcast assistance data CATT pCR - Yes
YesSame as tdoc 351. This was already addressed in tdoc 600.
noted No   S3‑191353
    S3‑191297 Key issue for encryption of broadcast assistance data in eLCS CAICT, China Unicom pCR   No
Yes
withdrawn Yes    
    S3‑191298 Key issue for encryption of broadcast assistance data in eLCS CAICT, China Unicom pCR   Yes
Yes
noted No    
    S3‑191352 pCR to TR33.814 - Key issue for distribution of assistance data ciphering key CATT pCR   Yes
YesQualcomm: SA2 has decided to do the same for the 5G system in Rel-16. This is not needed.
noted No    
    S3‑191354 pCR to TR33.814 - Key issue for the security architecture of eLCS CATT pCR   Yes
Yes
noted No    
    S3‑191349 pCR to TR33.814 - Key issue for security aspect of eLCS architecture enhancement CATT pCR   Yes
YesEricsson commented that it was better to bring this back in a later stage.
noted No    
    S3‑191363 Address EN in key issue 4 Huawei, Hisilicon pCR Approval Yes
YesNokia didn't know what the role of the AMF was in the enforcement of the privacy. ORANGE didnít understand the meaning of privacy control here, but since it was part of existing text of the specification they withdrew their comment. Qualcomm didnít agree with the AMF/UE enforcing the privacy control.
noted No    
    S3‑191368 Address EN and update in key issue 5 Huawei, Hisilicon pCR Approval Yes
YesNokia and Ericsson had concerns on the requirements so the editor's note came back.
revised No S3‑191754  
    S3‑191754 Address EN and update in key issue 5 Huawei, Hisilicon pCR Approval Yes
Yes
approved No   S3‑191368
    S3‑191190 New solution to key issue 5 in TR 33.814 (FS_eLCS_Sec): UE faking/altering location measurements Philips International B.V. pCR Approval Yes
YesORANGE: there are no requirements.
noted No    
    S3‑191369 A solution to prevent from providing faked/altered location estimate Huawei, Hisilicon pCR Approval Yes
Yes
noted No    
    S3‑191355 pCR to TR33.814 - Solution of ciphering algorithms CATT pCR   Yes
Yes
noted No    
    S3‑191356 pCR to TR33.814 - Solution of provisioning keys for broadcast assistance data protection CATT pCR   Yes
Yes
noted No    
    S3‑191358 pCR to TR33.814 - The solution for the distribution of broadcast assistance data deciphering key CATT pCR   Yes
Yes
noted No    
    S3‑191359 pCR to TR33.814 - The analysis of security architecture of eLCS CATT pCR   Yes
YesCATT proposed to move the content to clause 4. Qualcomm and Ericsson commented on the figure and CATT agreed to bring this back in the next meeting.
noted No    
    S3‑191470 Update to Solution#4 Enhance privacy control in LCS Nokia, Nokia Shanghai Bell pCR Approval Yes
Yes
approved No    
    S3‑191755 Draft TR 33.814 CATT draft TR Approval Yes
Yes
approved No    
8.13 Study on security for 5G URLLC (FS_5G URLLC_SEC) (Rel-16) S3‑191281 Reference part Huawei, HiSilicon pCR Approval Yes
Yes
approved No    
    S3‑191284 Delete the EN of Introduction Huawei, HiSilicon pCR Approval Yes
Yes
approved No    
    S3‑191285 Abbreviations Huawei, HiSilicon pCR Approval Yes
Yes
approved No    
    S3‑191215 Evaluation and text for resolving editorís note for solution #5 in TR 33.825 NEC Europe Ltd pCR Approval Yes
Yes
revised No S3‑191723  
    S3‑191723 Evaluation and text for resolving editorís note for solution #5 in TR 33.825 NEC Europe Ltd,Huawei pCR Approval No
Yes
noted No   S3‑191215
    S3‑191286 Delete the EN of solution 5 Huawei, HiSilicon pCR Approval Yes
Yes
revised No S3‑191724  
    S3‑191724 Delete the EN of solution 5 Huawei, HiSilicon pCR Approval Yes
Yes
approved No   S3‑191286
    S3‑191507 Evaluation of solution #5: Security for redundant data transmission Qualcomm Incorporated pCR Approval Yes
Yes
noted No    
    S3‑191274 Evaluation for solution 5 Huawei, HiSilicon pCR Approval Yes
Yes
merged No S3‑191723  
    S3‑191283 Adding the key issue details and threats for KI #1 Huawei, HiSilicon pCR Approval Yes
Yes
approved No    
    S3‑191279 Deleting EN of solution 4 Huawei, HiSilicon pCR Approval Yes
YesMCC commented that the introduction could not have normative requirements and proposed to reformulate the paragraph in present tense removing the shall and "it is required".
revised No S3‑191757  
    S3‑191757 Deleting EN of solution 4 Huawei, HiSilicon pCR Approval Yes
Yes
approved No   S3‑191279
    S3‑191280 Evaluation for solution 4 Huawei, HiSilicon pCR Approval Yes
Yes
revised No S3‑191758  
    S3‑191758 Evaluation for solution 4 Huawei, HiSilicon pCR Approval Yes
Yes
approved No   S3‑191280
    S3‑191277 Deleting the EN of solution 3 Huawei, HiSilicon pCR Approval Yes
Yes
revised No S3‑191759  
    S3‑191759 Deleting the EN of solution 3 Huawei, HiSilicon pCR Approval Yes
Yes
approved No   S3‑191277
    S3‑191275 Evaluation for solution 3 Huawei, HiSilicon pCR Approval Yes
Yes
approved No    
    S3‑191278 Adding more clarification text of solution 7 Huawei, HiSilicon pCR Approval Yes
Yes
revised No S3‑191760  
    S3‑191760 Adding more clarification text of solution 7 Huawei, HiSilicon pCR Approval Yes
Yes
approved No   S3‑191278
    S3‑191477 Solution #7 evaluation Ericsson pCR Approval Yes
Yes
approved No    
    S3‑191287 Evaluation for solution 6 Huawei, HiSilicon pCR Approval Yes
YesEricsson: solution 6 is out of scope. Delete the evaluation.
revised No S3‑191761  
    S3‑191761 Evaluation for solution 6 Huawei, HiSilicon pCR Approval Yes
Yes
approved No   S3‑191287
    S3‑191474 URLLC: Resolving EN in solution #8 Ericsson pCR Approval Yes
Yes
revised No S3‑191742  
    S3‑191742 URLLC: Resolving EN in solution #8 Ericsson pCR Approval Yes
Yes
approved No   S3‑191474
    S3‑191475 URLLC: Evaluation to solution #8 Ericsson pCR Approval Yes
Yes
revised No S3‑191762  
    S3‑191762 URLLC: Evaluation to solution #8 Ericsson pCR Approval Yes
Yes
approved No   S3‑191475
    S3‑191506 Missing implementation of S3-190797: Conclusion on KI #8 for Study on the security for URLLC Qualcomm Incorporated pCR Approval Yes
Yes
approved No    
    S3‑191276 Security solutions summary Huawei, HiSilicon pCR Approval Yes
YesEricsson: where to put this table?
revised No S3‑191763  
    S3‑191763 Security solutions summary Huawei, HiSilicon pCR Approval Yes
Yes
approved No   S3‑191276
    S3‑191270 Conclusion for key issue 1 Huawei, HiSilicon pCR Approval Yes
YesEricsson: remove solution 5.
revised No S3‑191764  
    S3‑191764 Conclusion for key issue 1 Huawei, HiSilicon pCR Approval Yes
Yes
approved No   S3‑191270
    S3‑191271 Conclusion for key issue 2 Huawei, HiSilicon pCR Approval Yes
Yes
noted No    
    S3‑191478 Conclusion to KI#1 and KI#2 Ericsson pCR Approval Yes
Yes
noted No    
    S3‑191272 Conclusion for key issue 3 Huawei, HiSilicon pCR Approval Yes
Yes
noted No    
    S3‑191476 URLLC: Recommendation for KI#3 Ericsson pCR Approval Yes
Yes
noted No    
    S3‑191273 Conclusion for key issue 4 Huawei, HiSilicon pCR Approval Yes
YesBT: we need to check the relation with the SA2 specification. Add an editor's note. Ericsson: we donít agree with solution 3 part. This was removed.
revised No S3‑191765  
    S3‑191765 Conclusion for key issue 4 Huawei, HiSilicon pCR Approval Yes
Yes
approved No   S3‑191273
    S3‑191282 Way forward of FS_5G_URLLC security study Huawei, HiSilicon pCR Approval Yes
Yes
withdrawn Yes    
    S3‑191756 Draft TR 33.825 Huawei draft TR Approval Yes
Yes
approved No    
    S3‑191787 Cover sheet TR 33.825 Huawei TS or TR cover Approval Yes
Yes
approved No    
8.14 Study on SECAM and SCAS for 3GPP virtualized network products (FS_VNP_SECAM_SCAS) (Rel-16) S3‑191526 Scope of a SECAM SCAS for 3GPP virtualized network products China Mobile, CAICT pCR   Yes
Yes
not treated No    
    S3‑191530 Scope of SECAM evaluation for 3GPP virtualized network products China Mobile, CAICT pCR Approval Yes
Yes
not treated No    
    S3‑191531 Scope of SECAM Accreditation for 3GPP virtualized network products China Mobile, CAICT pCR Approval Yes
Yes
not treated No    
    S3‑191533 Adding roles in SECAM for 3GPP virtualized network products into clause 4.6 China Mobile, CAICT pCR Approval Yes
Yes
not treated No    
    S3‑191535 Adding contents into clause 4 China Mobile, CAICT pCR Approval Yes
Yes
not treated No    
8.15 Study on Security for 5GS Enhanced support of Vertical and LAN Services (FS_Vertical_LAN_SEC) (Rel-16) S3‑191425 Solution and Conclusion on 5GLAN authentication Nokia, Nokia Shanghai Bell pCR Approval Yes
YesMCC reminded to add the references of the named specifications (e.g. 33.501) in clause 2 of the next draft TR.
approved No    
    S3‑191426 Solution on SMF handling the UP security policy for a 5GLAN Group Nokia, Nokia Shanghai Bell pCR Approval Yes
Yes
approved No    
    S3‑191427 Solution and conclusion for TSC Nokia, Nokia Shanghai Bell pCR Approval Yes
YesTaken offline to express that the authentication procedure in 33.501 is to be followed.
revised No S3‑191767  
    S3‑191767 Solution and conclusion for TSC Nokia, Nokia Shanghai Bell pCR Approval Yes
Yes
approved No   S3‑191427
    S3‑191106 Discussion on possible privacy/confidentiality attacks in PLMN integrated NPN InterDigital discussion Endorsement Yes
Yes
noted No    
    S3‑191553 Resolution of Editorís note on privacy impact in Solution #3 Samsung pCR Approval Yes
Yes
revised No S3‑191768  
    S3‑191768 Resolution of Editorís note on privacy impact in Solution #3 Samsung pCR Approval Yes
YesEditor's note was finally kept.
approved No   S3‑191553
    S3‑191592 Comment on contribution S3-191553 InterDigital Belgium. LLC discussion Discussion Yes
Yes
noted No    
    S3‑191596 New KI for PLMN integrated NPN InterDigital Germany GmbH pCR Approval Yes
YesThere was no agreement with the security threats and requirements.
revised No S3‑191769 S3‑191107
    S3‑191769 New KI for PLMN integrated NPN InterDigital Germany GmbH pCR Approval Yes
Yes
approved No   S3‑191596
    S3‑191597 New KI for Public network integrated NPN InterDigital Germany GmbH pCR Approval Yes
Yes
revised No S3‑191770 S3‑191164
    S3‑191770 New KI for Public network integrated NPN InterDigital Germany GmbH pCR Approval Yes
Yes
approved No   S3‑191597
    S3‑191233 Non-AKA based EAP methods with credentials stored and processed in UDM/ARPF CableLabs pCR Approval Yes
YesORANGE didnít agree with the key issue. The key hierarchy key issue is already covered somewhere else. Qualcomm argued that the use case was supported by the Rel-15 frameork
noted No    
    S3‑191428 Key issue on PNiNPN authentication Nokia, Nokia Shanghai Bell pCR Approval Yes
YesEricsson didnít see the threat clearly. ORANGE: the security requirements donít match because you can access the NPN networks without authenticating, you cannot mandate authentication. Qualcomm: we should close the TR without adding more key issues. Nokia: we want to close on this key issue. Telecom Italia: the solution should not exist. No support for this document, hence it was noted.
noted No    
    S3‑191429 Solution and evaluation for PNiNPN authentication Nokia, Nokia Shanghai Bell pCR Approval Yes
YesORANGE: not needed. We should not put material from our specifications in the TRs. This is exisitng already.
noted No    
    S3‑191339 Discussion on Architecture of PLMN integrated NPN Huawei, HiSilicon discussion Agreement Yes
Yes
noted No    
    S3‑191348 Amendment to Key Issue# 2.1 Huawei, HiSilicon pCR Approval Yes
YesORANGE: SA2 already created an architecture that doesn't imply changes in the security architecture. No work for us in this key issue. Huawei: you mention the standalone case, this is for the integrated case.
noted No    
    S3‑191338 Solution for efficient authentication for access between NPN and PLMN Huawei, HiSilicon pCR Approval Yes
Yes
noted No    
    S3‑191424 Solutions and conclusion for SNPN service access via PLMN and vice versa Nokia, Nokia Shanghai Bell pCR Approval Yes
YesORANGE: everything is captured in the SA2 specification.The solution is in their document already. This will not prodce eventually CRs into 33.501. Gemalto: we need a conclusion on this key issue, otherwise this will come back. The Chair commented that existing solutions can apply. ORANGE didnít agree since this didnít have any impact on our specifications. ORANGE: just say that no normative work is required. Everything was gone except the conclusion, which was reworded.
revised No S3‑191771  
    S3‑191771 Solutions and conclusion for SNPN service access via PLMN and vice versa Nokia, Nokia Shanghai Bell pCR Approval Yes
Yes
approved No   S3‑191424
    S3‑191370 update in solution 4 Huawei, Hisilicon pCR Approval Yes
Yes
revised No S3‑191772  
    S3‑191772 update in solution 3 Huawei, Hisilicon pCR Approval Yes
Yes
approved No   S3‑191370
    S3‑191495 Proposed evaluation details for solution #4 in TR 33.819 Qualcomm Incorporated pCR Approval Yes
Yes
approved No    
    S3‑191552 Editorís note for KI #1.1 Samsung pCR Approval Yes
Yes
approved No    
    S3‑191496 Proposed conclusion details for key issue #1.1 in TR 33.819 Qualcomm Incorporated pCR Approval Yes
YesEricsson: too early.
noted No    
    S3‑191551 Alignment of the term Non-Standalone NPN Samsung pCR Approval Yes
Yes
approved No    
    S3‑191555 Resolution of Editorís note on entities protected in Solution #3 Samsung pCR Approval Yes
Yes
approved No    
    S3‑191556 Evaluation to Solution #3 Samsung pCR Approval Yes
YesEricsson: how do you know that the UE is present without authentication and not a reply attack? Samsung: this is always possible but it is not addressed in this key issue. Editor's note added: change of CAGid by the network, provisioning of the updated id to the UE is out of scope of this solution.
revised No S3‑191773  
    S3‑191773 Evaluation to Solution #3 Samsung pCR Approval Yes
Yes
approved No   S3‑191556
    S3‑191430 Summary of security aspects covered in this study Nokia, Nokia Shanghai Bell pCR Approval Yes
Yes
revised No S3‑191774  
    S3‑191774 Summary of security aspects covered in this study Nokia, Nokia Shanghai Bell pCR Approval Yes
YesLast part from "the key issues are grouped.." removed as proposed by Qualco