Tdoc List

2019-06-28 16:12

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‑191800 Agenda WG 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‑191801 Report from last SA3 meeting/s MCC report   Yes
Yes
approved No    
4.2 Report from SA Plenary S3‑191803 Report from last SA meeting WG Chairman report   Yes
Yes
noted No    
4.3 Report from SA3-LI                      
5 Items for early consideration S3‑191840 LS reply on Nudr Sensitive Data Protection S2-1906761 LS in   Yes
Yes
noted No    
    S3‑191841 Reply LS on Nudr Sensitive Data Protection SP-190581 LS in   Yes
YesVodafone queried if changes implemented in Rel-15 had to be reversed. The Chair replied that was the case. NTT-Docomo: massive security work needed here, not even ready for Rel-16. It was decided to send an LS to SA2 and CT4 and postpone the reply to SA for the next meeting.
postponed No    
    S3‑192277 Reply to: Reply LS on Nudr Sensitive Data Protection Nokia LS out approval Yes
YesIt was clarified that changes in Rel-15 were needed in CT4. The Chair replied that this was not what was asked in SA. ORANGE: we never said that we had a specific authentication that shall be used. Proprietary algorithms used currently by operators will not work. Alex(BT): as specified this resolves in 5G weaker than 4G, due to the use of proprietary algorithms by operators. Anja(Nokia): this means that we are in the same situation as last meeting. Gemalto replied that last meeting was about a new feature in the storage in the UDM whereas this was a correction. The Chair commented that this may lead to a correction in a CT4 specification. Who supports sending the LS: Telecom Italia, Nokia, ORANGE,China Mobile, BT, Gemalto,Docomo,Hpe supported sending the LS. Ericsson didnít support sending the LS.
revised No S3‑192456  
    S3‑192456 LS on Nudr Sensitive Data Protection Nokia LS out approval Yes
Yes
approved No   S3‑192277
    S3‑192057 LS-UDR Nokia LS out Approval Yes
Yes
noted No    
    S3‑191985 Material related to UDM-ARPF-UDR discussion Nokia, Nokia Shanghai Bell discussion Information Yes
Yes
noted No    
    S3‑191862 Moving Forward on Storing Authentication Data Hewlett-Packard Enterprise discussion Endorsement Yes
YesVodafone: there would be security interoperability issues between the ARPF and UDR, no assurance for backwards compatibility.There is no time to do any security assesments anymore for Rel-15. It was clarified that SA3 was requrested to align with stage 3. Huawei: against adding requirements for this in 33.501 Rel-16. Alex(BT): we need to accept that SA made the decision of keeping the UDR. All companies were OK with that in SA, except Vodafone. Go with the Plenary's decision, keep it in Rel-15 "it's in the UDR", and look at it in Rel-16. The Chair commented that the issue on Rel-15 would the priority and work forward in Rel-16 would be discussed afterwards.
noted No    
    S3‑192140 Discussion of credential data protection China Mobile discussion Endorsement Yes
YesKPN, Nokia disagreed with the Rel-15 proposal. Something had to be done in Rel-15. Huawei supported this.
noted No    
    S3‑191984 Discussion on UDM-UDR-ARPF issues Nokia, Nokia Shanghai Bell discussion Endorsement Yes
YesVodafone found quite a lot to disagree in here. The document seems to imply that we take the SA's view as long term. The Chair clarified that SA3 will follow the guidance of SA in Rel-15. There is no choice here. Some proposals wanted to add something in Rel-15, some proposals said that nothing should be done in Rel-15. Vodafone: implementation problems as Rel-15 is showing now. Gemalto: Authentication data and suscription credentials are different concepts and SA is confusing them. Vodafone: there is a problem with addressing the storage of sensitive data in the UDR or proprietary repository. China Mobile: Rel-15 is frozen in SA3 too, no need to change anything in there. ORANGE: the definition of subscription credentials need to change. Georg Mayer (SA Chair) commented that these were defined in CT4 specifications. The deployment may be done differently but then they would not follow CT4 specs. Extending the definition or putting a note would be helpful. ORANGE: add a note: "Security storage in the UDR is out of scope of this document". Anders (HP): we cannot say all storage is out of scope.
noted No    
6 Reports and Liaisons from other Groups                      
6.1 3GPP Working Groups S3‑191836 LS on Ciphering solution for broadcast of Assistance Data R2-1908473 LS in   Yes
Yes
replied to No    
    S3‑191941 Nokia comments on R2-1908473 UE DL assistance data. Nokia, Nokia Shanghai Bell discussion Discussion Yes
Yes
noted No    
    S3‑191942 Draft reply LS on R2-1908473 UE DL assistance data. Nokia , Nokia Shanghai Bell LS out   Yes
Yes
revised No S3‑192268  
    S3‑192268 Reply LS on Cuiphering solution for broadcast of Assistance Data Nokia , Nokia Shanghai Bell LS out - Yes
Yes
approved No   S3‑191942
    S3‑191924 Ciphering of broadcast assistance data for UE-based positioning Qualcomm Incorporated discussion Decision Yes
YesEricsson: integrity protection is needed. Qualcomm replied that the agreement was that integrity protection was not needed. Interdigital: passive attacks are considered? When the UE is receiving coordinates from the gNodeB?. Qualcomm: high location accuracy is needed for some Ues, apps or the operator. Access control is for Ues that are subscribed for it. This is an use case that needed cyphering. Alf (Docomo): keystream could be used for something else. A predicted or extracted keystream should be looked at. Vodafone: publishing the location of the gNodeBs is a usual procedure among operators. It's publicly available data. Qualcomm: there is no security risk when using cyphering the static broadcast assistance data. Ericsson: add a reminder that Unicast uses NAS security and integrity protection can be added.
noted No    
6.2 IETF                      
6.3 ETSI SAGE                      
6.4 GSMA S3‑191837 GTP Recovery Counter & GSN node behaviour GSMA LS in   Yes
YesNokia: the choice of options require some study from SA3. Vodafone: we need a study item for this, and reply to them with an LS that we will do a study. Better not to postpone this LS. The Chair noted that this was an LS asking CT4 and not SA3, so no specific action for SA3 was required. Nokia: CT4 will not give a proper answer on the security of this.
replied to No    
    S3‑192269 Reply to: GTP Recovery Counter & GSN node behaviour Nokia LS out approval Yes
YesIt was agreed to send an LS reply where it would be stated that SA3 will look into this matter.
approved No    
    S3‑191845 Diameter IPX Network End-to-End Security Solution GSMA LS in   Yes
YesVodafone: I expect CRs for TS 33.401 as a result of this.A study item is needed. Iko (KPN): there is non 3GPP functionality here, that does not concern us. NCSC agreed with KPN. Nokia: on the Diameter solution we can give some feedback in the next meeting. AT&T: IETF has been working on Diameter security for years. How is it that GSMA has better security expertise on this issue? Vodafone commented that they had better knowledge of how the networks are implemented and deployed.
replied to No    
    S3‑192270 Reply to: Diameter IPX Network End-to-End Security Solution KPN LS out approval Yes
Yes
approved No    
6.5 OMA                      
6.6 TCG S3‑191814 TCG progress report InterDigital, Inc. report Information Yes
YesHighlights: ē Publication of new or revised deliverables (incremental changes from the status reported at SA3#95) ē TCG TPM 2.0 Auto Thin Profile Ė publication in June 2019 ē TCG Trusted Attestation Protocol (TAP) Info Model Ė publication in June 2019 ē TCG Trusted Attestation Protocol (TAP) Use Cases Ė public review June 2019 ē TCG TPM 2.0 r1.55 Ė X.509 Certs & Attached Components Ė public review May 2019 ē TCG TSS 2.0 TAB and Resource Manager Ė published April 2019 ē TCG TSS 2.0 TPM Command Transmission Interface (TCTI) Ė published April 2019 ē TCG TSS 2.0 System Level API (SAPI) Ė public review April 2019 ē TCG TSS 2.0 Enhanced System Level API (ESAPI) Ė public review April 2019 ē TCG PC Client Device Driver Design Principles for TPM 2.0 Ė public review February 2019 ē TCG Platform Certificate Profile Ė public review February 2019 ē IETF Remote ATtestation ProcedureS (RATS) WG in IETF Security Area About: https://datatracker.ietf.org/wg/rats/about/ Charter: https://datatracker.ietf.org/doc/charter-ietf-rats/ Documents: https://datatracker.ietf.org/wg/rats/documents/ Problem Space - Verifiable remote attestation - architecture and secure protocols - Solutions spanning from IoT devices to Data Center systems and Cloud infrastructure - Compact implementation solutions for resource-constrained systems - Composition and correlation for complex systems (e.g., rack-mount routers) - Primary support for CBOR Web Token (CWT) https://tools.ietf.org/html/rfc8392 - Secondary support for JSON Web Token (JWT) https://tools.ietf.org/html/rfc7519 - Multiple security components (GP SE, TCG TPM, TCG DICE, TCG MARS, etc.) 2. Meetings ē TCG Annual Members Meeting in Warsaw, Poland Ė 10-13 June 2019 o Sessions of Cyber Resilience, Network Equipment, DICE, IoT, Industrial, etc. o Kickoff of Measurement and Attestation RootS (MARS) in Embedded Systems ē 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‑191848 Handling of UE radio network capabilities in 4G and 5G GSMA LS in   Yes
Yes
replied to No    
    S3‑192271 Reply to: Handling of UE radio network capabilities in 4G and 5G NTT-Docomo LS out approval Yes
YesIncludes agreement on proposal 1 in tdoc 992.
approved No    
    S3‑192265 Reply LS on Handling of UE radio network capabilities in 4G and 5G R2-1908467 LS in Information Yes
Yes
replied to No    
    S3‑191939 Nokia comments on GSMA LS on UE radio capability exchange Nokia discussion   Yes
YesORANGE: what's the privacy issue? Nokia: fingerprinting of the device. The device type can be identified, software version, capability. Also whether the user has instantiated a particular application, watssapp or whatever. ORANGE: for 5G the IMSI is cyphered, not the same problem. We cannot hide the IMSI so it's not possible to provide backward compatibility in 4G. Besides, in Nokia's examples of privacy issues the user's identity is never exposed. Futurewei: this has been discussed before with RAN2. They donít have a problem with mandating for the security in the Uecapabilityenquiry procedure. NTT-Docomo: I agree with the issue in 5G with device fingerprinting.
noted No    
    S3‑191938 Nokia comments on R2-1908467 reply LS to GSMA UE capability Nokia discussion Endorsement Yes
YesFuturewei supported this proposal.
noted No    
    S3‑191992 Proposal for handling of UE radio network capabilities in 4G and 5G Ericsson discussion Endorsement Yes
YesFuturewei supported proposal 1 and 4. ORANGE: combine 1 and 2 in a new proposal 5. Nokia: proposal 2 doesnít address the issue and 3 is a new issue. Vodafone also liked proposal 1. The Chair saw that most companies supported proposal 1. Qualcomm liked proposal 2, Docomo supported proposal 1 and 2. In case RAN2 had issues with proposal 2, the shalls could be replaced with "should".
noted No    
    S3‑191809 Draft LS to RAN2 on UECapabilitiesEnquire after AS SMC Futurewei LS out Approval Yes
Yes
noted No    
    S3‑191940 Nokia comments on GSMA LS on UE radio capbility exchange Nokia, Nokia Shangahi Bell LS out Approval Yes
Yes
noted No    
    S3‑192266 Impersonation Attacks in 4G Networks GSMA LS in Discussion Yes
YesQualcomm: we are already studying UP IP for LTE. If we have this, the attack cannot be launched. Docomo: the billing issue is not here. You cannot create more traffic. Qualcomm was uncomfortable with replying with details to a paper that was not public yet. It was agreed to reply without much detail.
replied to No    
    S3‑192272 Reply to: Impersonation Attacks in 4G Networks Nokia LS out approval No
Yes
approved No    
6.11 Other Groups S3‑191833 NGMN 5G End-to-End Architecture Framework NGMN LS in   Yes
Yes
noted No    
    S3‑191844 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
YesDocomo: we should feedback requirements for roaming users need to be clear with regards to PWS messages in IoT devices.There is some work in SA1 and CT1 for ePWS. If we receive more LS about this work we should keep EMTEL in the loop.
noted No    
    S3‑192267 LS on withdrawal of TS 103 383 ďSmart Cards; Embedded UICC; Requirements Specification ETSI TC SCP LS in Information Yes
YesORANGE took the action point of preparing the CRs. A reply to this LS when the CRs were agreed would be done for the next meeting. Telecom Italia queried why the GSMA document was more important than the TCP document. Vodafone commented that the GSMA document was more widely implemented. ORANGE: SCP document is requirements-only and the GSMA documents has more things than requirements. Nokia: shouldn't we add other references after removing this one? ORANGE replied that it wasn't necessary.
postponed No    
    S3‑192273 Removing references in TS 33.501 of TS 103 383 ORANGE discussion Information Yes
YesCRs will come next meeting.
noted No    
7 Work Areas                      
7.1 Security aspects of 5G System - Phase 1 (5GS_Ph1-SEC) (Rel-15)                      
7.1.1 Key hierarchy S3‑192052 Mandating time based generation of SQNs Nokia, Nokia Shanghai Bell CR Agreement Yes
YesEricsson didn't agree with this recommendation. There are problems in the deployments when having different clocks. There are other ways of mitigating this attack. Qualcomm: our understanding was to enhance the authentication to address this problem. We have a key issue related to this for the study item. It was agreed to follow this in the related study work.
not pursued No    
7.1.2 Key derivation S3‑192073 Clarification on length of EARFCN-DL in key derivation Huawei, Hisilicon CR Approval Yes
YesRelated to tdoc 1971 (ZTE).
not pursued No    
    S3‑192135 Revisit the KAUSF desynchronization problem China Mobile discussion Endorsement Yes
YesNokia didnít agree with this scenario. If the authentication happened already, how can the attacker trigger another authentication? Only the AMF can do this. Alex (BT) didn't see the issue here,it's just error handling when there is a de-synchronization. Qualcomm agreed: the system will recover itself.
noted No    
    S3‑192139 KAUSF synchronziation between the UE and AUSF China Mobile CR Approval Yes
Yes
not pursued No    
    S3‑191971 length of ARFCN-DL ZTE Corporation CR Agreement Yes
YesVodafone: Why is the length coded in two bytes? What's the point of the first 00? Qualcomm: it was defined like that (look at L0). Nokia: this is not a new parameter, why do we need a new definition?
agreed No    
7.1.3 Mobility S3‑191972 uplink NAS Count for KeNB derivation in idle mode mobility to EPS ZTE Corporation CR Agreement Yes
YesOverlap with tdocs 1916,1917. This had to be taken offline.
not pursued No    
    S3‑192004 Security handling in registration procedure at AMF reallocation caused by slicing Ericsson discussion Endorsement Yes
Yes
revised No S3‑192262  
    S3‑192262 Security handling in registration procedure at AMF reallocation caused by slicing Ericsson Hungary Ltd discussion Endorsement Yes
Yes
noted No   S3‑192004
7.1.4 AS security                      
7.1.5 NAS security S3‑191911 Discussion on possible solutions to AMF relocation issues Qualcomm Incorporated discussion Endorsement Yes
YesOverlaps with 2148.Huawei didnít agree and preferred to go for their proposal in 2148.
noted No    
    S3‑191912 Missing security context handling during registration procedures Qualcomm Incorporated CR Agreement Yes
Yes
agreed No    
    S3‑192148 Solving registraiton failure in ilde mobility registration procedure with AMF Reallocation China Telecom, Huawei, Hisilicon CR Approval Yes
YesChina Mobile disagreed with this proposal. It wouldnít work against a false base station attack. Ericsson: we may be finding security holes in this olution and it needs to be studied more carefully. Qualcomm: what happens when the AMF doesnít talk to the old AMF and it doesnít pull the old security context? Huawei warned that if this was not solved in Release 15 there would backward compatibility issues in Release 16. Qualcomm: Intra-AMF connection within a network would avoid this problem in Release 15. ZTE: We prefer a solution that doesn't impact the UE. The Chair asked the delegates if there was any chance of having this solved in Release 15. Noamen commented that more CRs would be welcome for the next meeting. Martin (AT&T): if we donít solve this, we are getting to the situation of having to use a proprietary solution and it will cause once again that nothing will be standardized with many proprietary solutions already in the market. It was proposed to send an LS to CT1. This was discussed in tdoc 2281.
not pursued No    
    S3‑192159 Discussson paper on AMF reallocation China Telecom, Huawei, Hisilicon discussion Discussion Yes
Yes
noted No    
    S3‑192219 Clarification to Initial NAS message protection Samsung CR Approval Yes
YesMCC asked if this issue needed to be fixed, why it wasn't done in Rel-15. This was brought as TEI16, and it could be flagged out in SA.Samsung replied that it had been rejected to do it in Release 15 in the previous meeting, but in release 16 it was only introducing a new characteristic in the UE, not a new feature. Ericsson wasn't sure if this was affecting SA2's procedures and SA3 may have to consult them firstly.
revised No S3‑192282  
    S3‑192282 Clarification to Initial NAS message protection Samsung CR Approval Yes
YesSmall changes as proposed by Suresh (Nokia). Futurewei suggested to reword the consequences if not approved on the CR cover.
agreed No   S3‑192219
    S3‑192281 LS on registration issues in the AMF re-allocation Huawei LS out Approval Yes
YesThe Chair warned that if this had an impact on Rel-15 stage 3, this could be rejected by CT groups. Vodafone commented that CT groups were meeting in the same location as SA3 next time, so this could be discussed with them. It was argued that this could have some impact on backward compatibility and the release could be discussed with CT.
approved No    
    S3‑192353 Report from session on registation failures with AMF reallocation Huawei report Information Yes
Yes
noted No    
    S3‑192454 AMF reallocation Huawei discussion Endorsement Yes
YesIt takes the problem description of S3-192159 to be forwarded in the LS S3-192281.
noted No    
7.1.6 Security context S3‑191979 uplink NAS Count for Kasme derivation in idle mode mobility to EPS ZTE Corporation CR Agreement Yes
YesSuresh (Nokia) didnít agree with this change. ZTE: we guarantee that we use always the same value this way when the last COUNT is increased. Huawei: we agree with the problem they're trying to solve, not with the solution here.Scenario too specific, NAS uplink count value would be the more generic problem. It was agreed the existence of the problem, but the resolution/clarification needed to be taken offline.
revised No S3‑192284  
    S3‑192284 uplink NAS Count for Kasme derivation in idle mode mobility to EPS ZTE Corporation CR Agreement Yes
Yes
agreed No   S3‑191979
7.1.7 Visibility and Configurability S3‑191884 SoR-MAC-IUE verification failure handling by UDM NEC Europe Ltd CR Agreement Yes
YesThe Chair asked if this had impact on stage 3. NEC couldnít answer. Ericsson: if it's a malicious AMF why it would forward the malitious message? Vodafone: if there is no match it would just fail. Qualcomm: this is a CT1 problem, not to be addressed here. Samsung added that this increased complexity.
not pursued No    
    S3‑191955 Clarification on Procedure for steering of UE in VPLMN during mobility registration update Intel China Ltd., NEC CR   Yes
YesQualcomm: this scenario doesnít apply here. Vodafone agreed; this only takes place in the initial registration.
not pursued No    
7.1.8 Primary authentication S3‑191986 Definition of authentication subscription data Nokia, Nokia Shanghai Bell CR Agreement Yes
YesDocomo: second change should not be part of a definition, it's a requirement. Alf (Docomo): on the subscription credential(s) definition: these kind of discussion should not happen in a definition clause. This is not even a proper defintion format. The first definition on authentication subscription data was also discussed. Vodafone and MCC expressed their concerns that the definition was not used anywhere in the specification. Telecom Italia: a list of full parameters that are subscription credentials cannot be even agreed in SA3 so we cannot expect that CT groups assume them. Telecom Italia wished that it was clear for the operator that the security processes in the second note were not described anywhere else. MCC also noted that the term "in the present release" was redundant and just saying "not defined" would be clear enough.
revised No S3‑192276  
    S3‑192276 Definition of authentication subscription data Nokia, Nokia Shanghai Bell CR Agreement Yes
YesNTT-Docomo: happy with this, but we need to verify that the definitions are being used in the text of the spec and that they are still correct. Maybe send a LS and have a conference call in between meetings.Gemalto and ORANGE agreed. NTT-Docomo: this should lead to a study item in Rel-16. Alf (Docomo): allowing the storage in the UDR goes beyond making a definition, things are being stored in the ARPF throughout the spec and we need to modify those parts as well. ORANGE disagreed with the requirements on the UDM. It was commented that this document would serve as a baseline for further work for the next meeting, but in the end the document was noted. Telecom Italia: realistic to have UDR co-located/inside the ARPF? This would mean different requirements to be considered. Hpe: implementation issue. Tim (Vodafone) proposed to organize a conference call before the next meeting. Adrian (Qualcomm) will chair the call. Minutes were to be created and delivered to the next SA3 meeting. Georg (SA Chair) proposed to sync with CT4 on the call.
not pursued No   S3‑191986
    S3‑191936 Requirements on UDM/ARPF Gemalto, Nokia CR Approval Yes
YesORANGE: why are the UDM and ARPF together? Nokia: we are not consider them as separate identities and SA2 is wrong in their specification. Vodafone didn't support the CR. The main issue comes from the virtualization, and the virtualization study should take care of this. The same with the following CRs. Alf(Docomo): we would need a WID to have something normative agreed in Rel-16. I'd rather have a separate SID rather than putting it into the virtualization. The Chair commented that the objective was to create CRs to follow SA's guidance on the Release 15 open issues. Alex (BT): this CR doesn't fix the security issue requested in SA, which is the key storage not being done somewhere else necessarily ideal. This is not easy work and it needs further consideration. He suggested to drop the standardization in Rel-15 and fix it properly in Release 16. That would save a lot of time. Telecom Italia: practical consequences of doing nothing? The Chair understood that there would be none. Alex: the risk exists in 4G equally.In practical terms for the implementations in Rel-15 is to reduce the level of virtualization in some of the interfaces around ARPF. We leave it to the vendors to solve this. This was left open for offline discussion.
not pursued No    
    S3‑192334 Requirements on UDM/ARPF Gemalto, Nokia CR Approval No
Yes
withdrawn Yes    
    S3‑192055 Update on ARPF Nokia, Nokia Shanghai Bell CR Agreement Yes
YesVodafone: same comment as the previous CR. We only need to change the definition. Alex (BT): UDM cannot encrypt this. ORANGE didnít agree with the second change at all. This had to be taken offline.
not pursued No    
    S3‑192054 Missing UDR description in alignment with 29.505 Nokia, Nokia Shanghai Bell CR Agreement Yes
YesORANGE: having the "may be stored in the UDR" means that it is possible to store it somewhere else than the UDM. We need to require the storage somewhere with a "shall". Vodafone objected to this contribution as well.
not pursued No   S3‑191420
    S3‑192053 Requirement on UDR Nokia, Nokia Shanghai Bell CR Agreement Yes
YesTelecom Italia: the "e,g, permanent key" is not enough. We are not being precise enough. Alex (BT): the requirement should be on the subscription to the UDR data only. And the authentication is separable from the authentication of any other type of data.
not pursued No    
    S3‑192046 Requirements for credential storage in the UDR Ericsson CR Agreement Yes
YesVodafone: not for Rel-15, but good input for virtualization.
not pursued No    
    S3‑192056 Adding Nudr service Nokia, Nokia Shanghai Bell CR Agreement Yes
YesORANGE: don't agree with the bullet "identifier store in UDM/ARPFÖ". It's implementation specific. Nokia: this is what's done in CT4. China Mobile: this looks like a new feature rather than a correction. Vodafone rejeted the document.
not pursued No   S3‑191421
    S3‑192182 Clarification on authentication vector generation Nokia, Nokia Shanghai Bell CR Agreement Yes
YesORANGE: donít agree with the sentence about the proprietary repository of the operator. Not part of the standard. Vodafone rejected the document as well: Not Rel-15, better for virtualization part.
not pursued No    
    S3‑192259 Authentication Data Storage in 5G UDR for Release 15 Hewlett-Packard Enterprise CR Approval Yes
YesORANGE: not happy with the second change as it looks like a new requirement modifying the existing requirement. Alf (NTT-Docomo): similar problems with the second change. Vodafone: is trust boundary defined anywhere? They agreed with the rest of the change. The second change seemed to be allowing and forbidding SA3 at the same time. Alex (BT): you're forbidding anyone in the network to access the UDR except the ARPF.I get the concept but it's far more nuanced. ORANGE; "shall reside" is an implementation issue, not our problem here.
not pursued No    
    S3‑191881 [DRAFT] LS to SA2 for Moving Forward on Storing Authentication Data Hewlett-Packard Enterprise LS out Approval Yes
Yes
noted No    
    S3‑191882 [DRAFT] LS to CT4 for Moving Forward on Storing Authentication Data Hewlett-Packard Enterprise LS out Approval Yes
Yes
noted No    
    S3‑191999 Correction of reference to draft-ietf-emu-rfc5448bis Ericsson CR Agreement Yes
YesQualcomm didn't agree with the change. No update here until the IETF document is updated. The change should also be done in Rel-16. not Rel-15. Qualcomm: leave the annex F as it is in Rel-15. As for the rest, wait until the IETF is updated. ORANGE supported this. China Mobile: we donít reference drafts in 3GPP. The Chair clarified that this draft-referencing was currently done in 3GPP. The Chair added that the use of a reference in an editor's note was incorrect according to the current procedure with CT1. Qualcomm: delete the editor's note in Release 15 and follow Annex F; come back with this issue in Release 16, where it will not produce any issues. This was kept open in order to resolve the reference issue. Finally not pursued but he way forward will be performed for the next meeting.
not pursued No    
    S3‑192154 Issues on not removing the authentication result in the UDM Huawei, Hisilicon discussion Discussion Yes
Yes
noted No    
    S3‑192155 Removing the authentication result in the UDM Huawei, Hisilicon CR Approval Yes
YesEricsson: this is not needed. Qualcomm supported this.
not pursued No    
    S3‑192161 Removing the authentication result in the UDM Huawei, Hisilicon CR Approval Yes
YesSame comments as 2155. The Chair commented that Huawei was welcome to bring a key issue to the study for the next meeting in order to understand better the scenario.
not pursued No    
7.1.9 Secondary authentication                      
7.1.10 Interworking S3‑191916 Issues of resetting NAS COUNT values in 5G to 4G mobility Qualcomm Incorporated discussion Endorsement Yes
YesQualcomm insisted that there was an issue to be considered here.
noted No    
    S3‑191917 NAS Count values in the mapped EPS security context in 5GS to EPS change Qualcomm Incorporated CR Agreement Yes
YesEricsson: The COUNT value was created for replay protection. If we set the values the same as in 4G we'll be having some issues. Qualcomm: our choice is the simplest, otherwise we need to address this in other WG's specs like CT4. The MME is not aware about the idle mobility between 5G and 4G, for the MME we are only in 4G. This had to be taken offline.
not pursued No    
    S3‑191923 Reply LS on handling of native non-current 5G NAS security context Qualcomm Incorporated LS out Approval Yes
YesQualcomm: The problem is that there is integrity protection in the Registration request only when there is a native 5G security context. When moving from 5G to 4G the UE shall discard the 5G security context to avoid problems. This wasn't clear for Huawei.
revised No S3‑192279  
    S3‑192279 Reply LS on handling of native non-current 5G NAS security context Qualcomm Incorporated LS out Approval Yes
Yes
approved No   S3‑191923
    S3‑191995 Recommendation to run AKA after IW HO from 4G to 5G Ericsson CR Agreement Yes
YesNokia: why the recommendation? Ericsson: this is due to the written text under step 10. To take care of the "else" part of this statement. ORANGE wanted to add some statement for the operator. Vodafone: if we have a mapped 5G security context recommended at some point in the authentication why does it go here? Huawei: this is not needed. Docomo: we agreed not force this reauthentication. If you come from a mapped 4G context that is coming from a mapped 5G context you would need this. An operator recommended policy would have an unclear situation where to be applied. It was agreed to refer to the operator's policy and what triggers this. Docomo add a note about the reason for the triggering being the mapped context coming from the 3G context, otherwise there is no way of tracking why we are doing this whenever operators are switching off the 3G network. Nokia commented that this would give an additional requirement on the AMF. This was taken offline.
revised No S3‑192285  
    S3‑192285 Recommendation to run AKA after IW HO from 4G to 5G Ericsson CR Agreement Yes
Yes
agreed No   S3‑191995
    S3‑192218 Description of issue of security context transfer following the handover from EPS to 5GS Huawei, Hisilicon discussion Discussion Yes
YesQualcomm disagreed with the scenario. Option 2 was not backward compatible hence not possible for Rel-15. Ericsson preferred option 1, although the CR was based on option 2. Nokia wasn't convinced about the issue.
noted No   S3‑192156
    S3‑192151 Clarification on security context transfer during handover from S1 mode to N1 mode Huawei, Hisilicon CR Approval Yes
YesBased on option 2 of tdoc 2218. Huawei: There may be issues that need further study here. Qualcomm didnít see any issues.
not pursued No    
    S3‑192156 Description of issue of security context transfer following the handover from EPS to 5GS Huawei, Hisilicon CR Discussion Yes
Yes
revised No S3‑192218  
    S3‑192157 Discussion on the inconsistency of eKSI in idle mode mobility from 5GS to EPS over N26 Huawei, Hisilicon discussion Approval No
Yes
withdrawn Yes    
    S3‑192158 Clarification on the eKSI in idle mode mobility from 5GS to EPS over N26 Huawei, Hisilicon CR Approval Yes
YesEricsson: we might have to involve CT1 here. The Chair clarified that CT1 may not do anything else for Release 15. This was left open for discussion.
not pursued No    
    S3‑192162 Changes on handover from EPS to 5GS over N26 Huawei, Hisilicon CR Approval Yes
YesORANGE: maybe you have to remove NOTE 2 as well.
agreed No    
7.1.11 non-3GPP access                      
7.1.12 NDS                      
7.1.13 Service based architecture                      
7.1.13.1 Interconnect (SEPP related)                      
7.1.13.2 Other                      
7.1.14 Privacy S3‑192226 Modification on the usage of Identity Request Apple (UK) Limited CR Endorsement Yes
Yes
revised No S3‑192280  
    S3‑192280 Modification on the usage of Identity Request Apple (UK) Limited CR Endorsement Yes
YesORANGE: Identity request is part of the registration procedure. Docomo: There is value in this. Make it Rel-16. It protects the privacy of a single UE and it prevents DoS attacks. Qualcomm: we have this clarified in another clause. Not needed. Ahmad (Futurewei): the UE shall ignore if the request is coming out of the authentication procedure; I'm not sure if this is included in Release 15. Nokia: AMF can reauthenticate the UE anytime it wants, by sending the auth request to the UE. This is not needed. Qualcomm: we agreed to remove the requirement due to an LS from CT1 (S3-191121). Why adding this again? CT1 would have an issue. Intel: this is already covered somewhere else. Apple: we need to reconsider this. Qualcomm: after checking CT1 specs, we have found that this is not correct.
not pursued No   S3‑192226
7.1.15 Incoming and outgoing Lses S3‑191846 LS on support of non-3GPP only UE and support for PEI in IMEI format S2-1904836 LS in   Yes
Yes
replied to No    
    S3‑192278 Reply to: LS on support of non-3GPP only UE and support for PEI in IMEI format BT LS out approval Yes
YesIt was agreed to reply with "Reuse the same as in 3GPP access."
approved No    
    S3‑191847 Response LS on support of non-3GPP only UE and support for PEI in IMEI format s3i190363 LS in   Yes
Yes
noted No    
    S3‑191839 Further LS relating to ďResponse LS on reporting all Cell IDs in 5GĒ S2-1906170 LS in   Yes
Yes
noted No    
    S3‑191830 Reply LS on Security failure of NAS container in HO command C1-193708 LS in   Yes
YesAready taken care of.
noted No    
    S3‑192264 LS on handling of native non-current 5G NAS security context after an inter-system change from S1 mode to N1 mode in idle mode C1-193944 LS in Information Yes
YesQualcom's response reply in tdoc 923.
replied to No    
    S3‑191832 Reply LS on Clarification for N32 security C4-192467 LS in   Yes
Yes
noted No    
    S3‑191842 Reply LS on Clarification request on NF authorization in UE Reachability Notification Request procedure S2-1906636 LS in   Yes
Yes
noted No    
    S3‑191831 LS on handling of native non-current 5G NAS security context after an inter-system change from S1 mode to N1 mode in idle mode C1-193944 LS in   Yes
Yes
withdrawn Yes    
7.1.16 Others S3‑192142 Correnction of Reference China Mobile CR Approval Yes
Yes
revised No S3‑192333  
    S3‑192333 Correnction of Reference China Mobile CR Approval Yes
YesChanges on the cover sheet.
agreed No   S3‑192142
    S3‑192248 Privacy protection for non-3GPP in 33.402 Apple (UK) Limited discussion Agreement Yes
Yes
revised No S3‑192274  
    S3‑192274 Privacy protection for non-3GPP in 33.402 Apple (UK) Limited discussion Agreement Yes
Yes
noted No   S3‑192248
    S3‑192231 Privacy protection for non-3GPP in 33.402 Apple (UK) Limited CR Endorsement Yes
Yes
revised No S3‑192275  
    S3‑192275 Privacy protection for non-3GPP in 33.402 Apple (UK) Limited CR Agreement Yes
YesORANGE: This is not applicable for 5G but only for 4G. Telecom Italia agreed. Ericsson: this is a category B CR (new feature) and it needs a WID. Huawei was also concerned about this since even 5G could be impacted. ORANGE preferred to discuss a study item on this. Ericsson: backward compatibility, bidding down, LI impact. Alex(BT): there are far more security holes in 4G that have preference over this one. I donít mind having a study, though. I'd rather go to 5G issues first.
not pursued No   S3‑192231
    S3‑192244 LS on Integrity protection data rate enumeration Apple LS out Decision Yes
Yes
revised No S3‑192434  
    S3‑192434 LS on Integrity protection data rate enumeration Apple LS out Decision Yes
YesVodafone asked to minute: this means that handsets will provide integrity protection at full rate/fastest speed possible. This is clearly a big problem, as a note for the companies rejecting this LS. ORANGE supported Vodafone. Alex (BT) supported Vodafone as well. Not all handsets high end and low end, will support this capability, it is not realistic. Vodafone asked to be minuted: we are disgusted that our customers will be insecure. ORANGE asked for reasons for not sending this LS but there was no reason given. This statement was asked to be minuted as well.
noted No   S3‑192244
    S3‑192245 UP IP data rate Apple (UK) Limited discussion Decision Yes
YesVodafone supported this. No backward compatibilities issues here.ORANGE supported the LS as well. Alf (Docomo): Handsets that cannot do integrity protection are limited to 64Kb/s in software and in hardware have a determined supported data rate. I hope this will not be required. Colin (BT): concerns on something in the network not supporting this and having to be dropped down due to the high requirements. Vodafone: customers will need this integrity protection. Alf: If you have chispets that can do those values while supporting higher data rates there is no point in supporting this. Qualcomm: this proposal should be discussed in RAN2 if they want to revisit this. The Chair asked if this was for Rel-15 or Rel-16. Apple replied that ideally Rel-15 and if not rel-16. The Chair commented that Rel-15 was frozen and no more changes could be done as requested by CT groups. Nokia asked whether this values were coming from, what they were based on. Alex (BT): I support needing high data rates, but review CT1 specs for these values. This was taken offline.
noted No    
7.2 Security Assurance Specification for 5G (SCAS_5G) (Rel-16)                      
7.2.1 NR Node B (gNB) (TS 33.511) S3‑191961 Add abbreviation and correct references Futurewei Technologies CR Agreement Yes
Yes
agreed No    
    S3‑192006 STRIDE diagram for the gNB Ericsson discussion Discussion Yes
YesHuawei: Is this for the TR or TS? Ericsson: this is for discussion purposes only. Assest and threats would be the next step.
noted No    
7.2.2 Access and Mobility Management Function (TS 33.512) S3‑192163 Completing TS 33.512 Huawei, Hisilicon, Deutsche Telekom AG pCR Approval Yes
Yes
revised No S3‑192288  
    S3‑192288 Completing TS 33.512 Huawei, Hisilicon, Deutsche Telekom AG pCR Approval Yes
Yes
approved No   S3‑192163
    S3‑192179 Addition of AMF-related Security Problem Descriptions Huawei, Hisilicon CR Approval Yes
YesNokia: what happens if we have incorrect handling in X.2.2.3? The title needs to be changed. Nokia: remove the "waste of time" statement. Ericsson: who's the attacker here? Can you clarify it in the text? Ericsson suggested some other editorials to be fixed as well. It was clarified that this was intended to be input for the draftCR (which appears as a baseline). The CR is not pursued but the input to the draftCR is revised into tdoc 2286.
not pursued No    
    S3‑192286 Addition of AMF-related Security Problem Descriptions Huawei, Hisilicon other Approval Yes
Yes
approved No    
    S3‑192287 DraftCR on Assests and threats specific to the AMF Huawei draftCR Approval Yes
Yes
approved No    
    S3‑192403 Draft TS 33.512 Huawei draft TS Approval No
Yes
eft for email approval No    
7.2.3 User Plane Function (UPF) (TS 33.513) S3‑192164 Completing TS 33.513 Huawei, Hisilicon pCR Approval Yes
Yes
revised No S3‑192291  
    S3‑192291 Completing TS 33.513 Huawei, Hisilicon pCR Approval Yes
Yes
approved No   S3‑192164
    S3‑192165 Adding UPF critical assets and threats to TR 33.926 Huawei, Hisilicon CR Approval Yes
YesEricsson: SBI interfaces should be listed too.
not pursued No    
    S3‑192289 Adding UPF critical assets and threats to TR 33.926 Huawei, Hisilicon other Approval Yes
Yes
approved No    
    S3‑192290 DraftCR on Aspects of the network product class UPF Huawei draftCR Approval Yes
Yes
approved No    
    S3‑192292 Draft TS 33.513 Samsung draft TS Approval No
Yes
eft for email approval No    
7.2.4 Unified Data Management (UDM) (TS 33.514) S3‑192130 Adding references, definitions and abbreviations to SCAS UDM NEC Europe Ltd pCR Approval Yes
Yes
approved No   S3‑191885
    S3‑192134 Adding introduction text to SCAS UDM NEC Europe Ltd pCR Approval Yes
Yes
merged No S3‑192296 S3‑191886
    S3‑191888 New test case to SCAS UDM: SoR-MAC-IUE verification failure handling NEC Europe Ltd pCR Approval Yes
Yes
noted No    
    S3‑192167 Adding UDM critical assets and threats to TR 33.926 Huawei, Hisilicon CR Approval Yes
YesEricsson: list SBI interfaces here, only reference points are mentioned. Huawei: the SBI interfaces area already specified somewhere else. It was agreed to address it later by adding an editor's note. Revised to include some comments from Ericsson's as well. Not pursued since its intention was to be a draftCR. Content will go into tdoc 294.
not pursued No    
    S3‑192294 Adding UDM critical assets and threats to TR 33.926 Huawei, Hisilicon other Approval Yes
Yes
approved No    
    S3‑192221 Completing TS 33.514 Huawei, Hisilicon, NEC pCR Approval Yes
YesOverlap with tdoc 2134.
revised No S3‑192296 S3‑192166
    S3‑192296 Completing TS 33.514 Huawei, Hisilicon, NEC pCR Approval Yes
Yes
approved No   S3‑192221
    S3‑192136 Adding content to clause 4.2.3, 4.3 and 4.4 in SCAS UDM NEC Europe Ltd pCR Approval Yes
Yes
approved No   S3‑191887
    S3‑191885 Adding references, definitions and abbreviations to SCAS UDM NEC Europe Ltd pCR Approval Yes
Yes
revised No S3‑192130  
    S3‑191886 Adding introduction text to SCAS UDM NEC Europe Ltd pCR Approval Yes
Yes
revised No S3‑192134  
    S3‑191887 Adding content to clause 4.2.3, 4.3 and 4.4 in SCAS UDM NEC Europe Ltd pCR Approval Yes
Yes
revised No S3‑192136  
    S3‑192166 Completing TS 33.514 Huawei, Hisilicon pCR Approval Yes
Yes
revised No S3‑192221  
    S3‑192293 Draft TS 33.514 NEC draft TS Approval No
Yes
eft for email approval No    
    S3‑192295 DraftCR on aspects specific to the network product class UDM Huawei draftCR Approval Yes
Yes
approved No    
7.2.5 Session Management Function (SMF) (TS 33.515) S3‑192168 Adding test case for UE security policy comparison during handover Huawei, Hisilicon pCR Approval Yes
Yes
revised No S3‑192298  
    S3‑192298 Adding test case for UE security policy comparison during handover Huawei, Hisilicon pCR Approval Yes
Yes
approved No   S3‑192168
    S3‑192169 Completing TS 33.515 Huawei, Hisilicon pCR Approval Yes
Yes
revised No S3‑192300  
    S3‑192300 Completing TS 33.515 Huawei, Hisilicon pCR Approval Yes
Yes
approved No   S3‑192169
    S3‑192170 Adding SMF critical assets and threats to TR 33.926 Huawei, Hisilicon CR Approval Yes
YesHuawei: add a paragraph on protecting the user traffic data. Ericsson: charging ID uniqueness is not security related. In the end, it was decided to leave it. This CR was not pursued but the content will go into a draft CR in tdoc 2297.
not pursued No    
    S3‑192297 DraftCR on Adding SMF critical assets and threats to TR 33.926 Huawei, Hisilicon draftCR Approval Yes
Yes
approved No    
    S3‑192181 Adding a test case for charging id uniqueness Huawei, Hisilicon pCR Approval Yes
Yes
revised No S3‑192301  
    S3‑192301 Adding a test case for charging id uniqueness Huawei, Hisilicon pCR Approval Yes
Yes
approved No   S3‑192181
    S3‑192299 Draft TS 33.515 Huawei draft TS Approval No
Yes
eft for email approval No    
7.2.6 Authentication Server Function (AUSF) (TS 33.516) S3‑192172 Adding AUSF critical assets and threats to TR 33.926 Huawei, Hisilicon CR Approval Yes
Yes. This CR was not pursued but the contents will go into tdoc 302.
not pursued No    
    S3‑192302 Adding AUSF critical assets and threats to TR 33.926 Huawei, Hisilicon draftCR Approval Yes
Yes
approved No    
    S3‑192042 STRIDE diagram for the AUSF Ericsson discussion Discussion Yes
Yes
noted No    
    S3‑192043 Attack tree for sensitive data in AUSF Ericsson discussion Discussion Yes
Yes
noted No    
    S3‑192044 AUSF assets and threats Ericsson discussion Discussion Yes
Yes
noted No    
    S3‑192045 Living document: AUSF aspects in 33.926 Ericsson draftCR Approval Yes
YesOverlap with tdoc 172.
merged No S3‑192302  
    S3‑192171 Completing TS 33.516 Huawei, Hisilicon pCR Approval Yes
Yes
approved No    
    S3‑192303 Draft TS 33.516 Ericsson draft TS Approval Yes
Yes
approved No    
7.2.7 Security Edge Protection Proxy (SEPP) (TS 33.517) S3‑192143 Living Document: New Annex for the SEPP in TR 33.926 Nokia, Nokia Shanghai Bell draftCR Approval Yes
Yes
revised No S3‑192304  
    S3‑192304 Living Document: New Annex for the SEPP in TR 33.926 Nokia, Nokia Shanghai Bell draftCR Approval Yes
Yes
approved No   S3‑192143
    S3‑192186 Threat Analysis of Incorrect Handling for Protection Policies Mismatch by the SEPP Nokia, Nokia Shanghai Bell draftCR Approval Yes
Yes
revised No S3‑192305  
    S3‑192305 Threat Analysis of Incorrect Handling for Protection Policies Mismatch by the SEPP Nokia, Nokia Shanghai Bell draftCR Approval Yes
YesClarify the mistmatch in the threat description. Removes IPX provider in the threat description and it fixes some typos.
approved No   S3‑192186
    S3‑192189 Test Case: Correct Handling of Protection Policy Mismatch in the SEPP Nokia, Nokia Shanghai Bell pCR Approval Yes
Yes
revised No S3‑192306  
    S3‑192306 Test Case: Correct Handling of Protection Policy Mismatch in the SEPP Nokia, Nokia Shanghai Bell pCR Approval Yes
Yes
approved No   S3‑192189
    S3‑192192 Threat Analysis on Weak JWS Algorithm Nokia, Nokia Shanghai Bell draftCR Approval Yes
Yes
revised No S3‑192308  
    S3‑192308 Threat Analysis on Weak JWS Algorithm Nokia, Nokia Shanghai Bell draftCR Approval Yes
YesRemoving examples from the threat description.
approved No   S3‑192192
    S3‑192194 Test Case: JWS Profile Restriction in the SEPP Nokia, Nokia Shanghai Bell pCR Approval Yes
Yes
revised No S3‑192309  
    S3‑192309 Test Case: JWS Profile Restriction in the SEPP Nokia, Nokia Shanghai Bell pCR Approval Yes
Yes
approved No   S3‑192194
    S3‑192180 Updating SEPP critical assets and threats in TR 33.926 Huawei, Hisilicon CR Approval Yes
YesIt overlaps with 2184. The CR (should have been a draftCR) is not pursued butThe content will be merged into 310.
not pursued No    
    S3‑192184 Threat Analysis on Exposure of Confidential IEs in N32-f message Nokia, Nokia Shanghai Bell draftCR Approval Yes
Yes
revised No S3‑192310  
    S3‑192310 Threat Analysis on Exposure of Confidential IEs in N32-f message Nokia, Nokia Shanghai Bell,Huawei draftCR Approval Yes
Yes
approved No   S3‑192184
    S3‑192197 Updating TS 33.517 with the Threat Reference for the Test Case in 4.2.2.5 Nokia, Nokia Shanghai Bell pCR Approval Yes
Yes
merged No S3‑192311  
    S3‑192173 Completing TS 33.517 Huawei, Hisilicon pCR Approval Yes
Yes
revised No S3‑192311  
    S3‑192311 Completing TS 33.517 Huawei, Hisilicon,Nokia pCR Approval Yes
Yes
approved No   S3‑192173
    S3‑192307 Draft TS 33.517 Nokia draft TS Approval Yes
Yes
approved No    
7.2.8 Network Resource Function (NRF) (TS 33.518) S3‑192174 Updating TS 33.518 Huawei, Hisilicon, Nokia, Nokia Shanghai Bell pCR Approval Yes
Yes
approved No    
    S3‑192312 Draft TS 33.518 Nokia draft TS Approval Yes
Yes
approved No    
7.2.9 Network Exposure Function (NEF) (TS 33.519) S3‑192175 Completing TS 33.519 Huawei, Hisilicon pCR Approval Yes
Yes
revised No S3‑192314  
    S3‑192314 Completing TS 33.519 Huawei, Hisilicon pCR Approval Yes
Yes
approved No   S3‑192175
    S3‑192176 Adding NEF critical assets and threats to TR 33.926 Huawei, Hisilicon CR Approval Yes
YesNot pursued as the content will go into the draftCR in tdoc 313.
not pursued No    
    S3‑192313 Adding NEF critical assets and threats to TR 33.926 Huawei, Hisilicon draftCR Approval Yes
Yes
approved No    
    S3‑192315 Draft TS 33.519 ZTE draft TS Approval No
Yes
eft for email approval No    
7.2.10 Others S3‑192137 Living Document: General SBA/SBI aspects in TS 33.117 Nokia, Nokia Shanghai Bell draftCR Approval Yes
Yes
revised No S3‑192316  
    S3‑192316 Living Document: General SBA/SBI aspects in TS 33.117 Nokia, Nokia Shanghai Bell draftCR Approval Yes
Yes
approved No   S3‑192137
    S3‑192177 adding critical assets and threats to TR 33.926 for general SBA/SBI aspects Huawei, Hisilicon CR Approval Yes
YesRevised content will go to the contribution to the draftCR in 317.
not pursued No    
    S3‑192317 adding critical assets and threats to TR 33.926 for general SBA/SBI aspects Huawei, Hisilicon other Approval Yes
Yes
approved No    
    S3‑192138 Addition Assets and Threats for Generic NFs Nokia, Nokia Shanghai Bell CR Approval Yes
YesContent is merged in 317.
not pursued No    
    S3‑192178 Update of living Document: General SBA/SBI aspects in TS 33.117 Huawei, Hisilicon draftCR Approval Yes
Yes
revised No S3‑192318  
    S3‑192318 Update of living Document: General SBA/SBI aspects in TS 33.117 Huawei, Hisilicon draftCR Approval Yes
Yes
approved No   S3‑192178
    S3‑192141 Updating the Living Document with Threat References Nokia, Nokia Shanghai Bell draftCR Approval Yes
Yes
merged No S3‑192318  
7.3 eMCSec R16 security (MCXSec) (Rel-16) S3‑191834 Observations on standards and technical constraints from 3rd MCX remote Plugtests ETSI CTI LS in   Yes
YesMotorola commented that CT1 proposed that everything went all through them, given that there was an additional LS from CT1 to which SA3 will reply directly instead of this one. CTI will be in copy in that LS whereas this one will be noted.
noted No    
    S3‑191861 [33.180] R16 - Fix hash result (mirror) Motorola Solutions Germany CR Agreement Yes
Yes
agreed No    
7.4 Security aspects of single radio voice continuity from 5GS to UTRAN () (Rel-16) S3‑191989 Living doucment for 5G_UTRAN_SEC China Unicom draftCR   Yes
YesEricsson noted that this needed to show the changes are revision marks.
revised No S3‑192335  
    S3‑192335 Living doucment for 5G_UTRAN_SEC China Unicom draftCR - No
Yes
approved No   S3‑191989
    S3‑192067 Dicussion on security handling after voice call ends Huawei, Hisilicon discussion Endorsement Yes
YesAlex (BT): the call drops down to the lower technology and stays down as agreed in SA. This is against that and I object to this proposal.
noted No    
    S3‑192068 security handling after voice call ends Huawei, Hisilicon CR Approval Yes
Yes
not pursued No    
    S3‑192011 SRVCC keys China Unicom draftCR   Yes
Yes
approved No    
    S3‑192012 key generation in MME_SRVCC China Unicom other   Yes
YesQualcomm: this implies additional signalling that we donít need. It overlaps with our proposal in 903. It was agreed to go for Qualcomm's contribution that deleted the editor's note where both overlapped.
noted No    
    S3‑192010 Rename the derived key China Unicom draftCR   Yes
Yes
merged No S3‑192336  
    S3‑191903 Proposed updates to the draft CR on SRVCC from 5G to UTRAN CS Qualcomm Incorporated other Approval Yes
YesDeleting the editor's note thatís being modified by China Unicom in 2012.
revised No S3‑192336  
    S3‑192336 Proposed updates to the draft CR on SRVCC from 5G to UTRAN CS Qualcomm Incorporated,China Unicom other Approval Yes
Yes
approved No   S3‑191903
    S3‑191904 Assigning a FC value to TS 33.501 for K5GSRVCC calculation Qualcomm Incorporated CR Agreement Yes
Yes
revised No S3‑192337  
    S3‑192337 Assigning a FC value to TS 33.501 for K5GSRVCC calculation Qualcomm Incorporated CR Agreement Yes
Yes
agreed No   S3‑191904
    S3‑191905 Adding K5GSRVCC as a possible input key to derive IKSRVCC and CKSRVCC Qualcomm Incorporated CR Agreement Yes
Yes
revised No S3‑192338  
    S3‑192338 Adding K5GSRVCC as a possible input key to derive IKSRVCC and CKSRVCC Qualcomm Incorporated CR Agreement Yes
Yes
agreed No   S3‑191905
    S3‑191906 Revision of SRVCC WID Qualcomm Incorporated WID revised Agreement Yes
YesORANGE: it doesnít make sense to keep the UICC being modified "donít know". IDEMIA and Gemalto disagreed with having to revise the WID to change the impact.
agreed No    
7.5 Enhancements for Security aspects of Common API Framework for 3GPP Northbound APIs (eCAPIF-Sec) (Rel-16) S3‑192215 Editorial correction of CAPIF-3e/4e/5e requirements clause Samsung CR Approval Yes
Yes
agreed No    
    S3‑191937 Requirement on authenticating unpublish requests Ericsson CR   Yes
YesSamsung: we don't need this requirement, itís already covered.
not pursued No    
    S3‑192213 Security procedures for CAPIF-3e/4e/5e reference points Samsung CR Approval Yes
YesNokia didn't agree with this contribution. NCSC: N32 is quite heavy weight, more complicated than it appears here.
not pursued No    
    S3‑192214 Security aspects of CAPIF-7/7e reference points Samsung CR Approval Yes
Yes
revised No S3‑192339  
    S3‑192339 Security aspects of CAPIF-7/7e reference points Samsung CR Approval Yes
YesThird change goes away.
agreed No   S3‑192214
7.6 Security of URLLC for 5GS (5G_URLLC_SEC) (Rel-16) S3‑192125 draftCR for URLLC TS Huawei, Hisilicon draftCR Approval Yes
YesQualcomm: some parts of this are still in the air and we need some conclusions before agreeing on this. Let's wait for the next meeting. Nokia supported this. Huawei commented that this was a living document and could be changed anytime according to the discussions. Qualcomm didnít agree with the introduction either. It was decided to come back to the next meeting with this. It was the general idea that the objective was to introduce this content in an annex to TS 33.501, so it was expected to bring back a similar contribution to the next meeting.
noted No    
7.7 Security for 5GS Enhanced support of Vertical and LAN Services (Vertical_LAN_SEC) (Rel-16) S3‑192058 NPN references in existing text Nokia, Nokia Shanghai Bell CR Agreement Yes
YesORANGE didn't agree with this CR. There was no previous agreement on adding an Annex.They had some other issues that were shared by Gemalto.Vodafone didnít agree with referencing to Annex Z this way. Anja(Nokia) commented that she would bring another proposal for the next meeting. Gemalto: each time there's a new annex, the 5G core part would be impacted and we would need to be changing it constantly.
not pursued No    
7.8 Other work areas                      
7.8.1 SAE/LTE Security S3‑191954 Clarification of NIA0 with SgNB for UE NR capability Intel China Ltd. CR   Yes
YesEricsson: there is impact on CT1. Qualcomm was fine with the change.
agreed No    
7.8.2 IP Multimedia Subsystem (IMS) Security                      
7.8.3 Network Domain Security (NDS)                      
7.8.4 UTRAN Network Access Security                      
7.8.5 GERAN Network Access Security                      
7.8.6 Generic Authentication Architecture (GAA)                      
7.8.7 Security Aspects of Home(e)NodeB (H(e)NB)                      
7.8.8 Mission Critical (MCPTT, MCSec, eMCSec, MONASTERY_SEC) S3‑191829 LS on ETSI Plugtest standards Issues C1-193601 LS in   Yes
Yes
replied to No    
    S3‑192332 Reply to: LS on ETSI Plugtest standards Issues Motorola Solutions LS out approval Yes
Yes
approved No    
    S3‑191860 [33.180] R15 - Fix hash result Motorola Solutions Germany CR Agreement Yes
Yes
agreed No    
7.8.9 Security Assurance Specifications (SCAS-SA3, SCAS_PGW, SCAS_eNB) S3‑192037 Corrections on IP packet forwarding Ericsson CR Agreement Yes
Yes
agreed No    
    S3‑192038 Corrections on IP packet forwarding Ericsson CR Agreement Yes
Yes
revised No S3‑192319  
    S3‑192319 Corrections on IP packet forwarding Ericsson CR Agreement Yes
YesFixing some cover page errors.
agreed No   S3‑192038
    S3‑192039 Corrections on IP packet forwarding Ericsson CR Agreement Yes
Yes
revised No S3‑192320  
    S3‑192320 Corrections on IP packet forwarding Ericsson CR Agreement Yes
Yes
agreed No   S3‑192039
    S3‑192040 Threat analysis for OAM configurator spoofing Ericsson discussion Discussion Yes
Yes
noted No    
    S3‑192041 Living document: generic assets and threats Ericsson draftCR Approval Yes
Yes
revised No S3‑192321  
    S3‑192321 Living document: generic assets and threats Ericsson draftCR Approval Yes
Yes
approved No   S3‑192041
    S3‑192092 Propose fuzz tests run 100 000 times Huawei, Hisilicon CR Approval Yes
YesEricsson wasn't sure about stating out a number like 10000. Huawei: there should be a baseline about the number of runs for the tester. It was agreed to remove the number. Some errors on the CR cover page were also pointed out.
revised No S3‑192322  
    S3‑192322 R16_Carification for Fuzz tests run Huawei, Hisilicon CR Approval Yes
Yes
agreed No   S3‑192092
    S3‑192093 R15_clarification for Fuzz tests run Huawei, Hisilicon CR Approval Yes
Yes
revised No S3‑192323  
    S3‑192323 R15_clarification for Fuzz tests run Huawei, Hisilicon CR Approval Yes
Yes
agreed No   S3‑192093
    S3‑192094 R14_clarification for Fuzz tests run Huawei, Hisilicon CR Approval Yes
Yes
revised No S3‑192324  
    S3‑192324 R14_clarification for Fuzz tests run Huawei, Hisilicon CR Approval Yes
Yes
agreed No   S3‑192094
    S3‑192095 Clairication on the intention of the requirment Huawei, Hisilicon CR Approval Yes
Yes
revised No S3‑192325  
    S3‑192325 Clairication on the intention of the requirment Huawei, Hisilicon CR Approval Yes
Yes
agreed No   S3‑192095
    S3‑192096 R15_Mirror_Clairication on the intention of the requirment Huawei, Hisilicon CR Approval Yes
Yes
revised No S3‑192326  
    S3‑192326 R15_Mirror_Clairication on the intention of the requirment Huawei, Hisilicon CR Approval Yes
Yes
agreed No   S3‑192096
    S3‑192097 R14_Mirror_Clairication on the intention of the requirment Huawei, Hisilicon CR Approval Yes
Yes
revised No S3‑192327  
    S3‑192327 R14_Mirror_Clairication on the intention of the requirment Huawei, Hisilicon CR Approval Yes
Yes
agreed No   S3‑192097
    S3‑192098 A document is needed to show the support features Huawei, Hisilicon CR Approval Yes
Yes
revised No S3‑192350  
    S3‑192350 A document is needed to show the support features Huawei, Hisilicon CR Approval Yes
Yes
agreed No   S3‑192098
    S3‑192099 R15_Mirror_A document is needed to show the support features Huawei, Hisilicon CR Approval Yes
Yes
revised No S3‑192351  
    S3‑192351 R15_Mirror_A document is needed to show the support features Huawei, Hisilicon CR Approval Yes
Yes
agreed No   S3‑192099
    S3‑192100 R14_Mirror_A document is needed to show the support features Huawei, Hisilicon CR Approval Yes
Yes
revised No S3‑192352  
    S3‑192352 R14_Mirror_A document is needed to show the support features Huawei, Hisilicon CR Approval Yes
Yes
agreed No   S3‑192100
    S3‑192101 Align account numbers in testcase with the requirement Huawei, Hisilicon CR Approval Yes
Yes
revised No S3‑192329  
    S3‑192329 Align account numbers in testcase with the requirement Huawei, Hisilicon CR Approval Yes
Yes
agreed No   S3‑192101
    S3‑192102 R15_Mirror_Align account numbers in testcase with the requirement Huawei, Hisilicon CR Approval Yes
Yes
revised No S3‑192330  
    S3‑192330 R15_Mirror_Align account numbers in testcase with the requirement Huawei, Hisilicon CR Approval Yes
Yes
agreed No   S3‑192102
    S3‑192103 R14_Mirror_Align account numbers in testcase with the requirement Huawei, Hisilicon CR Approval Yes
Yes
revised No S3‑192331  
    S3‑192331 R14_Mirror_Align account numbers in testcase with the requirement Huawei, Hisilicon CR Approval Yes
Yes
agreed No   S3‑192103
7.8.10 Security Aspects of Narrowband IOT (CIoT)                      
7.8.11 EPC enhancements to support 5G New Radio via Dual Connectivity (EDCE5)                      
7.8.12 Northbound APIs Security for SCEF - SCS/AS Interworking (NAPS_Sec) (Rel-15)                      
7.8.13 Security Aspects of Common API Framework for 3GPP Northbound APIs (CAPIF_Sec) (Rel-15)                      
7.8.14 PLMN RAT selection (Steering of Roaming) (Rel-15)                      
7.8.15 Battery Efficient Security for very low Throughput Machine Type Communication Devices (BEST_MTC_Sec) (Rel-15) S3‑192007 Discussion Document on the evolution of BEST VODAFONE Group Plc discussion Discussion No
Yes
withdrawn Yes    
7.8.16 Other work items S3‑192008 WID on BEST Test Specificationd for HSE and UE VODAFONE Group Plc WID new Agreement Yes
YesQualcomm: test specs are developed in RAN5. Vodafone: we did it for TUAK and all algorithms we've had in the past. Qualcomm: test specs that we agree that are in our scope.RAN5 write tests not only for RAN, but for other groups.Interoperability and protocol performance test cases are done in RAN5. They even have for IMS. Interdigital agreed. Vodafone: RAN5 has no expertise for this work. Alf (Docomo): ask RAN5 with an LS. Vodafone: we will not go to RAN5 under any circumstances. MCC: this cannot be done for Release 15 as a Rel-16 version of TS 33.163 already exists and the work will be done there. This had to be taken offline.
noted No    
7.9 New Work Item proposals S3‑192047 New WID on evolution of Cellular IoT security for the 5G System Ericsson WID new Agreement Yes
YesVodafone: the WID doesnít detail enough the justification and objectives. MCC agreed, it seemed too brief and it needed some more wording.
revised No S3‑192354  
    S3‑192354 New WID on evolution of Cellular IoT security for the 5G System Ericsson WID new Agreement Yes
Yes
agreed No   S3‑192047
    S3‑192104 WID on Security of the Wireless and Wireline Convergence for the 5G system architecture Huawei, Hisilicon WID new Approval Yes
YesVodafone: the objectives need rewording.
revised No S3‑192355  
    S3‑192355 WID on Security of the Wireless and Wireline Convergence for the 5G system architecture Huawei, Hisilicon WID new Approval Yes
Yes
agreed No   S3‑192104
8 Studies                      
8.1 Study on Security Aspects of the 5G Service Based Architecture (FS_SBA-Sec) (Rel-15) S3‑192035 Correction of implementation of S3-191671 Ericsson pCR Approval Yes
Yes
approved No    
    S3‑192246 Discussion paper on resource level authorization using OAuth 2.0 access tokens Nokia, Nokia Shanghai Bell pCR Approval Yes
Yes
noted No    
    S3‑192247 Key Issue on resource level authorization during service access Nokia, Nokia Shanghai Bell pCR Approval Yes
Yes
revised No S3‑192412  
    S3‑192412 Key Issue on resource level authorization during service access Nokia, Nokia Shanghai Bell pCR Approval Yes
Yes
approved No   S3‑192247
    S3‑192249 pCR Ė Solution for resource level authorization using access tokens Nokia, Nokia Shanghai Bell pCR Approval Yes
Yes
approved No    
    S3‑192258 pCR to 33.855 on NF authorization with SeCoP NTT DOCOMO INC. pCR Approval Yes
Yes
approved No   S3‑192256
    S3‑192250 Discussion paper on policy-based authorization for indirect communication Nokia, Nokia Shanghai Bell discussion - Yes
Yes
noted No    
    S3‑192251 pCR on Policy based authorization for Indirect communications Nokia, Nokia Shanghai Bell pCR Approval Yes
Yes
revised No S3‑192413  
    S3‑192413 pCR on Policy based authorization for Indirect communications Nokia, Nokia Shanghai Bell pCR Approval Yes
YesORANGE: SA2 is using the term SCP for something else. Change the name.
approved No   S3‑192251
    S3‑192033 New solution: Token-based authorization for Scenario D using stateless SeCoP Ericsson pCR Approval Yes
Yes
revised No S3‑192439  
    S3‑192439 New solution: Token-based authorization for Scenario D using stateless SeCoP Ericsson pCR Approval Yes
YesAdding two editor's notes.
approved No   S3‑192033
    S3‑192034 New solution: Token-based authorization for Scenario C using stateless SeCoP Ericsson pCR Approval Yes
Yes
revised No S3‑192440  
    S3‑192440 New solution: Token-based authorization for Scenario C using stateless SeCoP Ericsson pCR Approval Yes
YesAdding three new edtior's notes.
approved No   S3‑192034
    S3‑192150 Solution for NF service consumer verification during service access authorization Huawei, Hisilicon pCR Approval Yes
Yes
revised No S3‑192441  
    S3‑192441 Solution for NF service consumer verification during service access authorization Huawei, Hisilicon pCR Approval Yes
Yes
approved No   S3‑192150
    S3‑192152 Evaluation of solution #15 in TR 33.855 - Delegated "Subscribe-Notify" interaction Authorization Huawei, Hisilicon pCR Approval Yes
Yes
noted No    
    S3‑192153 Update of solution #19 in TR 33.855 - Authorization within a NF Set Huawei, Hisilicon pCR Approval Yes
Yes
revised No S3‑192442  
    S3‑192442 Update of solution #19 in TR 33.855 - Authorization within a NF Set Huawei, Hisilicon,Nokia pCR Approval Yes
Yes
approved No   S3‑192153
    S3‑192253 Solution for Authorization of NFs within a NF Set Nokia, Nokia Shanghai Bell pCR Approval Yes
Yes
merged No S3‑192442  
    S3‑192254 pCR to 33.855 on SeCoP distribution NTT DOCOMO INC. pCR Approval Yes
Yes
revised No S3‑192443  
    S3‑192443 pCR to 33.855 on SeCoP distribution NTT DOCOMO INC. pCR Approval Yes
Yes
approved No   S3‑192254
    S3‑192252 pCR on NF to SeCoP interface security in service-mesh based deployments Nokia, Nokia Shanghai Bell pCR Approval Yes
Yes
approved No    
    S3‑192255 pCR on removing EN in Solution #21 Nokia, Nokia Shanghai Bell pCR Approval Yes
Yes
revised No S3‑192444  
    S3‑192444 pCR on removing EN in Solution #21 Nokia, Nokia Shanghai Bell pCR Approval Yes
Yes
approved No   S3‑192255
    S3‑192256 pCR to 33.855 on NF authorization with SeCoP NTT DOCOMO INC. pCR Approval Yes
Yes
revised No S3‑192258  
    S3‑192365 Minutes of the SBA offline session Ericsson report Information Yes
Yes
noted No    
    S3‑192438 Draft TR 33.855 Ericsson draft TR Approval No
Yes
eft for email approval 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)                      
8.5 Study on authentication and key management for applications based on 3GPP credential in 5G IoT (FS_AKMA)(Rel-16) S3‑192187 Meeting minutes of AKMA conference calls China Mobile report Information Yes
Yes
noted No    
    S3‑192211 Meeting minutes of AKMA conference call on 4th June China Mobile report Information Yes
Yes
noted No    
    S3‑192190 Work Plan for moving forward AKMA China Mobile discussion   Yes
Yes
noted No    
    S3‑192146 New KI: AKMA push Huawei, Hisilicon pCR Approval Yes
YesQualcomm: not sure that we need this. GBA Push is not really used. There is no use case for this.Vodafone commented that it was used. ORANGE: reword the requirement.
revised No S3‑192428  
    S3‑192428 New KI: AKMA push Huawei, Hisilicon pCR Approval Yes
Yes
approved No   S3‑192146
    S3‑192160 Solution for AKMA push Huawei, Hisilicon pCR Approval Yes
YesORANGE: remove the evaluation. Ericsson: User identity should be clarified in step one of the figure.
revised No S3‑192429  
    S3‑192429 Solution for AKMA push Huawei, Hisilicon pCR Approval Yes
Yes
approved No   S3‑192160
    S3‑192263 New solution: Integrating GBA to 5GC Ericsson Hungary Ltd pCR Approval Yes
YesORANGE didn't support bringing old GBA into 5G. Something new should be created. Qualcomm and China Mobile supported this. Out of scope. Vodafone: how are GBA services evolving into 5G then?
noted No   S3‑192005
    S3‑192220 Implicit bootstrapping using NEF as the AKMA Anchor Function Nokia, Nokia Shanghai Bell, China Mobile pCR Approval Yes
Yes
approved No    
    S3‑192000 Solution 2 evaluation Ericsson pCR Approval Yes
YesORANGE: second bullet point in the advantages needs to go away. Qualcomm: authentication procedure overhead needs to be pointed out.
revised No S3‑192450  
    S3‑192450 Solution 2 evaluation Ericsson pCR Approval Yes
Yes
approved No   S3‑192000
    S3‑192001 Solution 3 evaluation Ericsson pCR Approval Yes
Yes
revised No S3‑192451  
    S3‑192451 Solution 3 evaluation Ericsson pCR Approval Yes
Yes
approved No   S3‑192001
    S3‑191877 Update of solution #17 - Efficient key derivation for e2e security KPN pCR Approval Yes
Yes
approved No    
    S3‑191890 Resolving Editorís Notes and adding conclusion to solution #18 NEC Europe Ltd pCR Approval Yes
Yes
approved No    
    S3‑191891 Resolving Editorís Notes and adding conclusion to solution #20 NEC Europe Ltd pCR Approval Yes
Yes
not treated No    
    S3‑192002 Solution #15 updates including evaluation update Ericsson pCR Approval Yes
Yes
not treated No    
    S3‑192003 Solution #13 evaluation Ericsson pCR Approval Yes
Yes
not treated No    
    S3‑192065 Resovle Editor's notes in Solution for Key freshness in AKMA Huawei, Hisilicon pCR Approval Yes
Yes
not treated No    
    S3‑192126 Evaluation for solution Huawei, Hisilicon pCR Approval Yes
Yes
not treated No    
    S3‑192196 Individual Evaluation of solution #6 China Mobile pCR Approval Yes
Yes
not treated No    
    S3‑192198 Individual Evaluations of solution #7- #12 China Mobile pCR Approval Yes
Yes
not treated No    
    S3‑192207 Evaluation of solution#1- Introducing third party key to AKMA China Mobile pCR   Yes
Yes
not treated No    
    S3‑191878 AKMA solution set analysis KPN discussion Discussion Yes
Yes
noted No    
    S3‑192201 Discussion on AKMA overall evaluation methodology China Mobile, ZTE Corporation discussion Endorsement Yes
YesVodafone: no evaluation on how this evolves from GBA here. This is replacing GBA. Qualcomm: donít mix GBA and AKMA.They're different. This is a separate document. ORANGE didnít understand the classification of the key issues.
noted No    
    S3‑192204 skeleton of clause 7- evaluation and conclusion China Mobile pCR   Yes
YesORANGE: 7.5 will be the API on the UE, not implementations.
revised No S3‑192427  
    S3‑192427 skeleton of clause 7- evaluation and conclusion China Mobile pCR - Yes
Yes
approved No   S3‑192204
    S3‑191889 Discussion on AKMA overall conclusions NEC Europe Ltd discussion Endorsement Yes
YesKPN disagreed with the contribution. Qualcomm: endorse proposal one. Nokia supported this. The Chair asked for a show of hands: ORANGE, Nokia, ZTE,Qualcomm,china mobile,Huawei, NEC supported proposal one. Ericsson, KPN,Gemalto, Vodafone didnít support endorsing this.
noted No    
    S3‑192193 Editorial Changes to TR 33.835 v0.4.0 China Mobile pCR Approval Yes
Yes
approved No    
    S3‑191892 Editorial corrections of AKMA TR 33.835 v0.4.0 NEC Europe Ltd pCR Approval Yes
Yes
approved No    
    S3‑192005 New solution: Integrating GBA to 5GC Ericsson pCR Approval Yes
Yes
revised No S3‑192263  
    S3‑192430 Draft TR 33.835 China Mobile draft TR Approval No
Yes
eft for email approval No    
8.6 Study on evolution of Cellular IoT security for the 5G System (FS_CIoT_sec_5G) (Rel-16) S3‑191893 Editorial correction of TR 33.861 NEC Europe Ltd pCR Approval Yes
Yes
approved No    
    S3‑192106 Update Solution 17 to Supplement Missing Part When Merging with S3-191389 Huawei, Hisilicon pCR Approval Yes
Yes
approved No    
    S3‑191872 New KI: Sleep deprivation attacks to CIOT terminals Huawei, HiSilicon pCR Approval Yes
YesNokia: this will not work as it is proposed. Intel agreed and commented that the UE has to wake up to verify the integrity protection anyway. Futurewei: 5G-TMSI cannot be leaked. They also disagreed with the contribution. Alf: delete requirements, keep the key issue for security analysis purposes. Ericsson: we agree with Futurewei, 5G-TMSI is sent after security activation. There was no support for this paper.
noted No    
    S3‑192111 Key Issue for RRC Connection Re-Establishment for the control plane for NB-IoT connected to 5GC Huawei, Hisilicon pCR Approval Yes
YesEricsson: S-TMSI size, which is RAN2's concern, is not addressed here. Nokia: Impact of S-TMSI truncation needs a security issue. We will not make the decision of truncating but we need to study the security implications. This would mean rewriting the key issue to address the concerns of RAN2 raised in their LS.
revised No S3‑192393  
    S3‑192393 Key Issue for RRC Connection Re-Establishment for the control plane for NB-IoT connected to 5GC Huawei, Hisilicon pCR Approval Yes
Yes
approved No   S3‑192111
    S3‑191810 Update of Solution Solution #4 Futurewei pCR Approval Yes
Yes
approved No    
    S3‑191835 LS on RRC Connection Re-Establishment for CP for NB-IoT connected to 5GC R2-1908264 LS in   Yes
Yes
replied to No    
    S3‑191943 Nokia comments on R2-1908264 LS on RRC Connection Re-establishment Nokia, Nokia Shanghai Bell discussion Discussion Yes
YesHuawei: this is not a security perspective. Nokia: without an ID the solution will not work.
noted No    
    S3‑191811 Evaluation of Solution #4 Futurewei pCR Approval Yes
Yes
noted No    
    S3‑192397 Evaluation of Solution #4 Futurewei pCR Approval No
Yes
withdrawn Yes    
    S3‑192016 CIOT: add evaluation to solution #4 Ericsson pCR Approval Yes
Yes
noted No    
    S3‑191952 Evaluation to Security solution 4 for UL small data transfer in RRC Suspend and Resume with early data transmission (EDT) Intel China Ltd. pCR Approval Yes
Yes
noted No    
    S3‑191909 Evaluation of the integrity protection provided by EDT solutions #4 and #18 Qualcomm Incorporated pCR Approval Yes
YesHuawei: in LTE the air interface has no user plane,there is no such bidding down attack. The LTE technology does not support integrity protection. Qualcomm: integrity protection is added in order to have it modified it over the air. Why are we having integrity protection then?
noted No    
    S3‑191876 Update of Solution #6 - Use of UE Configuration Update KPN pCR Approval Yes
Yes
approved No    
    S3‑192071 Delete EN in solution12 Huawei, Hisilicon pCR Approval Yes
Yes
approved No    
    S3‑191879 Proposal for editor's note in FS_CIoT_sec_5G solution #15 Philips International B.V. pCR Approval Yes
YesNokia didnít agree with the change. Futurewei wasn't convinced about the way the editor's notes were handled either.The first two changes went away.
revised No S3‑192398  
    S3‑192398 Proposal for editor's note in FS_CIoT_sec_5G solution #15 Philips International B.V. pCR Approval Yes
Yes
approved No   S3‑191879
    S3‑192105 Address EN in solution 17 Huawei, Hisilicon pCR Approval Yes
YesEricsson was concerned about how the black list was maintained since the constant change would lead to an increase in signalling. Otherwise they agreed with the change.
approved No    
    S3‑192107 Add Evaluation for Solution 17 Huawei, Hisilicon pCR Approval Yes
YesNokia had the same comment as Ericsson in the previous contribution: maintaining the black list would cause overhead. Ericsson: in the practice they would be multiple black lists. Nokia: this gets complex when considering the mobility part.
revised No S3‑192399  
    S3‑192399 Add Evaluation for Solution 17 Huawei, Hisilicon pCR Approval Yes
Yes
approved No   S3‑192107
    S3‑192013 CIoT: Update to Solution #18 Ericsson pCR Approval Yes
YesFuturewei: "potential enhancement" is not referring to anything. I'm against this. Remove reference to key issue integrty protection. This was agreed.
revised No S3‑192400  
    S3‑192400 CIoT: Update to Solution #18 Ericsson pCR Approval Yes
Yes
approved No   S3‑192013
    S3‑192014 CIoT: Evaluation to Solution #18 Ericsson pCR Approval Yes
YesOverlapping with 806, 953.
revised No S3‑192401  
    S3‑192401 CIoT: Evaluation to Solution #18 Ericsson,Futurewei,Intel pCR Approval Yes
Yes
approved No   S3‑192014
    S3‑191806 Evaluation of Solution Solution #18 Futurewei pCR Approval Yes
Yes
merged No S3‑192401  
    S3‑191953 Evaluation to Security solution 18 for UL small data transfer in RRC Suspend and Resume with early data transmission (EDT) Intel China Ltd. pCR Approval Yes
Yes
merged No S3‑192401  
    S3‑192108 Add Details and Evaluation for Solution 19 Huawei, Hisilicon pCR Approval Yes
Yes
revised No S3‑192402  
    S3‑192402 Add Details and Evaluation for Solution 19 Huawei, Hisilicon pCR Approval Yes
YesAdding an editor's note on the group of misbehaving UEs as proposed by Ericsson.
approved No   S3‑192108
    S3‑191920 Solution for integrity protection of EDT Qualcomm Incorporated pCR Approval Yes
YesFuturewei objected to having this solution because there was a whole study item dedicated to this: user plane integrity protection. This didnít belong here. Qualcomm: Evaluation in solution 4 and 18 that there is a bidding down risk but we donít have proper protection against that. Qualcomm: what is the key issue for? Futurewei: it's for when we donít use the user plane integrity protection completely. Intel supported Qualcomm but proposed to add the evaluation later when the UP IP study had a conclusion.
noted No    
    S3‑192018 CIOT: New solution for UP IP in PDCP to protect UL EDT data in Msg3 Ericsson pCR Approval Yes
Yes
noted No    
    S3‑191951 Security solution for UL small data transfer in RRC Suspend and Resume with early data transmission (EDT) with legacy fall back Intel China Ltd. pCR Approval Yes
Yes
revised No S3‑192328  
    S3‑192328 Security solution for UL small data transfer in RRC Suspend and Resume with early data transmission (EDT) with legacy fall back Intel China Ltd. pCR Approval No
Yes
noted No   S3‑191951
    S3‑192017 CIOT: Optional support of RRC Inactive in eMTC connected to 5GC Ericsson pCR Approval Yes
YesFuturewei: If you read RAN2 agreement, NB-IoT is not supported.
noted No    
    S3‑191871 Mitigate DDoS Attacks on RAN based on RAN coordination Huawei, HiSilicon pCR Approval Yes
YesSamsung didnít agree with this.
noted No    
    S3‑192019 DDoS protection based on NWDAF and Overload Control Ericsson pCR Approval Yes
YesHuawei: out of scope of this key issue. The key issue is about how to detect and what to do after detection.
noted No    
    S3‑192115 Solution for Protection of NAS Redirection Message Huawei, Hisilicon pCR Approval Yes
YesEricsson: There is a requirement in Rel-15 and there is impact on UE and network, an overhead increase. Remove the evaluation and add another editor's note on why legacy mechanisms are not used here.
revised No S3‑192404  
    S3‑192404 Solution for Protection of NAS Redirection Message Huawei, Hisilicon pCR Approval Yes
Yes
approved No   S3‑192115
    S3‑191873 A solution to protect CIOT terminals from sleep deprivation attacks Huawei, HiSilicon pCR Approval Yes
Yes
noted No    
    S3‑192112 Solution for RRC Connection Re-Establishment for the control plane for NB-IoT connected to 5GC Huawei, Hisilicon pCR Approval Yes
Yes
revised No S3‑192452  
    S3‑192452 Solution for RRC Connection Re-Establishment for the control plane for NB-IoT connected to 5GC Huawei, Hisilicon pCR Approval Yes
Yes
approved No   S3‑192112
    S3‑192113 Reply LS on RRC Connection Reestablishment for CP for NB-IoT connected to 5GC Huawei, Hisilicon LS out Approval Yes
Yes
revised No S3‑192394  
    S3‑192394 Reply LS on RRC Connection Reestablishment for CP for NB-IoT connected to 5GC Huawei LS out Approval Yes
Yes
approved No   S3‑192113
    S3‑192015 CIoT: Conclusion to KI#2 and KI#3 Ericsson pCR Approval Yes
Yes
noted No    
    S3‑191812 Conclusion for KI#2 for RRC based solutions Futurewei pCR Approval Yes
Yes
noted No    
    S3‑191813 Conclusion for KI#3 for RRC signaling based solutions Futurewei pCR Approval Yes
Yes
noted No    
    S3‑192114 Conclusion for KI#2 and KI#3 of frequent CIoT Ues Huawei, Hisilicon pCR Approval Yes
Yes
noted No    
    S3‑192109 Discussion Paper for Mitigation of DDoS Attack Huawei, Hisilicon discussion Endorsement Yes
Yes
noted No    
    S3‑192110 conclusion for KI#4 Huawei, Hisilicon pCR Approval Yes
YesEricsson: no need to do normative work. We agree with SA2 on the fact that we can rely on existing mechanisms. KPN: both Ericsson's (tdoc 2021) and Huawei's conclusions are not correct.
noted No    
    S3‑192021 Conslusion for KI#4 Ericsson pCR Approval Yes
YesSupported by Nokia.
noted No    
    S3‑191870 Conclusion to KI #5 Huawei, HiSilicon pCR Approval Yes
YesDiscussed together with tdoc 2020. Ericsson: the solution will not make a difference if the attacker is a bit more sophisticated. Supported by Qualcomm.
noted No    
    S3‑192020 Conslusion for KI#5 Ericsson pCR Approval Yes
Yes
noted No    
    S3‑191980 Conclusion on Key Issue #7 Lenovo, Motorola Mobility pCR   Yes
YesEricsson: the conclusion is better rely on existing mechanisms. Nokia: this is not necessary.
noted No    
    S3‑192392 Draft TR 33.861 Ericsson draft TR Approval No
Yes
eft 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‑191838 Reply LS on Authentication for UEs not Supporting NAS S1-191595 LS in   Yes
YesORANGE: they seem to interpret the requirement in a different way. They are not really answering our question.A laptop is not an IoT device.
noted No    
    S3‑191843 LS to BBF on WWC status S2-1906821 LS in   Yes
Yes
noted No    
    S3‑192083 Delete Editor's in Solution#3 and add evaluation Huawei, Hisilicon pCR Approval Yes
YesDiscussed with 2222 and 2223. Vodafone: we shouldnít write in a spec that we need input from BBF unless it's in an editor's note. MCC agreed with this. Nokia: we conclude with what's in our scope and in case BBF comes up with a solution we can update the study.
merged No S3‑192382  
    S3‑192222 Resolve Editorís Note in solution 3 Nokia, Nokia Shanghai Bell pCR Approval Yes
Yes
revised No S3‑192382  
    S3‑192382 Resolve Editorís Note in solution 3 Nokia, Nokia Shanghai Bell,Huawei pCR Approval Yes
Yes
approved No   S3‑192222
    S3‑192223 WWC - Evaluation of Solution #3 Nokia, Nokia Shanghai Bell pCR Approval Yes
Yes
merged No S3‑192382  
    S3‑192084 Delete Editor's in Solution#5 and add evaluation Huawei, Hisilicon pCR Approval Yes
Yes
revised No S3‑192383  
    S3‑192383 Delete Editor's in Solution#5 and add evaluation Huawei, Hisilicon,Nokia pCR Approval Yes
Yes
approved No   S3‑192084
    S3‑192225 WWC - Resolve Editorís Note in solution 5 Nokia, Nokia Shanghai Bell pCR Approval Yes
Yes
merged No S3‑192383  
    S3‑192232 WWC - Evaluation of Solution #5 Nokia, Nokia Shanghai Bell pCR Approval Yes
Yes
merged No S3‑192383  
    S3‑192085 Conclusion on KI#1 Huawei, Hisilicon pCR Approval Yes
Yes
approved No    
    S3‑192077 Add requirement to KI#2 Huawei, Hisilicon pCR Approval Yes
Yes
approved No    
    S3‑192089 Merge S3-191319 to solution 4 Huawei, Hisilicon pCR Approval Yes
Yes
approved No    
    S3‑192228 WWC - Resolve Editorís Note on Authentication in solution 4 Nokia, Nokia Shanghai Bell pCR Approval Yes
Yes
revised No S3‑192385  
    S3‑192385 WWC - Resolve Editorís Note on Authentication in solution 4 Nokia, Nokia Shanghai Bell pCR Approval Yes
Yes
approved No   S3‑192228
    S3‑192230 WWC - Resolve Editorís Note on trust in solution 4 Nokia, Nokia Shanghai Bell pCR Approval Yes
YesTaken care of in 2089.
noted No    
    S3‑192224 WWC - Evaluation of Solution #4 Nokia, Nokia Shanghai Bell pCR Approval Yes
Yes
approved No    
    S3‑191988 Conclusion for Key Issue #5 Lenovo, Motorola Mobility pCR   Yes
Yes
approved No    
    S3‑191987 Removal of Editorís Note and Addition of Evaluation Lenovo, Motorola Mobility pCR   Yes
Yes
revised No S3‑192386  
    S3‑192386 Removal of Editorís Note and Addition of Evaluation Lenovo, Motorola Mobility pCR - Yes
Yes
approved No   S3‑191987
    S3‑192227 Resolve Editorís Note in solution 6 Nokia, Nokia Shanghai Bell pCR Approval Yes
Yes
merged No S3‑192386  
    S3‑191983 Conclusion for Key Issue #6 Lenovo, Motorola Mobility pCR   Yes
Yes
approved No    
    S3‑192078 Add threat and requirement to KI#10 Huawei, Hisilicon pCR Approval Yes
Yes
approved No    
    S3‑192233 WWC - Add conclusion on KI #10 Nokia, Nokia Shanghai Bell pCR Approval Yes
Yes
approved No    
    S3‑192080 Add threat and requirement to KI#11 Huawei, Hisilicon pCR Approval Yes
Yes
revised No S3‑192387  
    S3‑192387 Add threat and requirement to KI#11 Huawei, Hisilicon pCR Approval Yes
Yes
approved No   S3‑192080
    S3‑192234 WWC - Add conclusion on KI #11 Nokia, Nokia Shanghai Bell pCR Approval Yes
Yes
approved No    
    S3‑192079 Add requirement to KI#12 Huawei, Hisilicon pCR Approval Yes
YesORANGE, Ericsson: we need a threat for this requirement.
revised No S3‑192388  
    S3‑192388 Add requirement to KI#12 Huawei, Hisilicon pCR Approval Yes
Yes
approved No   S3‑192079
    S3‑192087 Solution on Line ID protection Huawei, Hisilicon pCR Approval Yes
Yes
noted No    
    S3‑192090 Conclusion on KI#12 Huawei, Hisilicon pCR Approval Yes
Yes
noted No    
    S3‑192235 WWC - Add conclusion on KI #12 Nokia, Nokia Shanghai Bell pCR Approval No
Yes
withdrawn Yes    
    S3‑192236 WWC - Add conclusion on KI #12 Nokia, Nokia Shanghai Bell pCR Approval Yes
Yes
revised No S3‑192389  
    S3‑192389 WWC - Add conclusion on KI #12 Nokia, Nokia Shanghai Bell pCR Approval Yes
Yes
approved No   S3‑192236
    S3‑192081 Add requirement and delete EN for KI#14 Huawei, Hisilicon pCR Approval Yes
YesORANGE: Keep the key issue and say that the scenario is not in scope of this document.
revised No S3‑192390  
    S3‑192390 Add requirement and delete EN for KI#14 Huawei, Hisilicon pCR Approval Yes
Yes
approved No   S3‑192081
    S3‑192086 Conclusion on KI#14 Huawei, Hisilicon pCR Approval Yes
Yes
revised No S3‑192391  
    S3‑192391 Conclusion on KI#14 Huawei, Hisilicon pCR Approval Yes
Yes
approved No   S3‑192086
    S3‑192082 Add requirement and delete EN for KI#15 Huawei, Hisilicon pCR Approval Yes
Yes
approved No    
    S3‑192088 Mapping SUCI to SUPI Huawei, Hisilicon pCR Approval Yes
Yes
approved No    
    S3‑192091 Conclusion on KI#16 Huawei, Hisilicon pCR Approval Yes
Yes
approved No    
    S3‑191949 DraftCR - update Annex B to support the authentication of non-3GPP devices CableLabs, Charter, Nokia, Nokia Shanghai Bell draftCR Discussion Yes
Yes
revised No S3‑192283  
    S3‑192283 DraftCR - update Annex B to support the authentication of non-3GPP devices CableLabs, Charter, Nokia, Nokia Shanghai Bell draftCR Discussion Yes
YesORANGE: changes in B.1 not necessary. Some re-wording is needed as there is normative meaning in an informative annex.
noted No   S3‑191949
    S3‑191883 DraftCR - update Annex B to support the authentication of non-3GPP UE CableLabs draftCR Discussion No
Yes
withdrawn Yes    
    S3‑192384 Draft TR 33.807 Huawei draft TR Approval No
Yes
eft for email approval No    
8.8 Study on Security Aspects of PARLOS (FS_PARLOS_Sec) (Rel-16) S3‑191925 Proposed conclusion for PARLOS Qualcomm Incorporated, Intel, Samsung, Sprint, Verizon UK Ltd pCR Approval Yes
YesAdd an editor's note on the mitigations. Second part was removed. It was asked to be minuted: The group agreed that solution one is considered to be too complex to be the way forward.
noted No    
    S3‑191926 pCR: Resolution of EN in Solution 2 evaluation Qualcomm Incorporated, Intel, Samsung, Sprint, Verizon UK Ltd pCR Approval Yes
Yes
not treated No    
    S3‑191944 Way forward on Emergency solution for PARLOS Nokia, Nokia Shanghai Bell pCR Approval Yes
YesDocomo: part of the evaluation contains part of the solution. An editor's note was added for this.
revised No S3‑192380  
    S3‑192380 Way forward on Emergency solution for PARLOS Nokia, Nokia Shanghai Bell pCR Approval Yes
Yes
approved No   S3‑191944
    S3‑192229 pCR to 33.815 on authentication of network NTT DOCOMO INC. pCR Approval Yes
YesSprint: there is a requirement that reads that the user is always informed of whether they are using RLOS. RLOS is not only for calls as well. NTT-Docomo: if the user is not aware, we have the threat. If the UE-user interface fulfils the requirement, that's fine, but the issue is there. SA1 is giving a solution. Vodafone: our consumers are not aware, they don't know what RLOS is about. BT supported this. ORANGE supported NTT-Docomo's contribution. The feature should not impact the users and this is essential. Qualcomm: I donít agree putting this key issue. We have discussed this with other 3GPP groups like SA1 and SA2. Vodafone: this is setting up a massive fake base station issue. BT: the user will be directed to confirm actions that he doesnít understand. Alex (BT): if we donít document this we will get CVDs about this in the future. False base stations are a real threat and this needs to be included. The Chair suggested to record the key issue and the threat without a requirement. NTT-Docomo: there is a solution in SA1's specification. We need the requirement to align with what SA1 has agreed. It was agreed to capture SA1's text, and a note on the user's interaction for incerasing their awareness.
revised No S3‑192378  
    S3‑192378 pCR to 33.815 on authentication of network NTT DOCOMO INC. pCR Approval Yes
Yes
approved No   S3‑192229
    S3‑192237 pCR to 33.815 on user awareness of PARLOS service NTT DOCOMO INC. pCR Approval Yes
YesNokia supported adding a note on the user interacting and selecting the RLOS service as done in the previous contribution. The same note was added as a baseline. Same changes as the previous contribution as well. Vodafone: what happens with IoT devices? Docomo answered that NB-IoT are excluded, the other are not.
revised No S3‑192379  
    S3‑192379 pCR to 33.815 on user awareness of PARLOS service NTT DOCOMO INC. pCR Approval Yes
Yes
approved No   S3‑192237
    S3‑192381 Draft TR 33.815 Sprint draft TR Approval No
Yes
eft for email approval No    
8.9 Study on 5G security enhancement against false base stations S3‑191807 Secuirty threat for RRCResumeRequest tampering. Futurewei pCR Approval Yes
Yes
withdrawn Yes    
    S3‑191808 Solution for protecting RRCResumeRequest against tampering Futurewei pCR Approval Yes
Yes
withdrawn Yes    
    S3‑191868 Address EN in solution #1 Huawei, HiSilicon pCR Approval Yes
Yes
not treated No    
    S3‑192238 UE capability protection Apple pCR Approval Yes
Yes
not treated No    
    S3‑192206 Resolving EN on New and Last serving gNB interactions Samsung pCR Approval Yes
Yes
not treated No    
    S3‑192208 Evaluation of Solution#2 Samsung pCR Approval Yes
Yes
revised No S3‑192447  
    S3‑192447 Evaluation of Solution#2 Samsung,Apple pCR Approval Yes
Yes
approved No   S3‑192208
    S3‑192241 update of solution #2 Apple pCR Approval Yes
Yes
merged No S3‑192447  
    S3‑192116 Solution for Protection of RRC Reject Message Huawei, Hisilicon pCR Approval Yes
Yes
revised No S3‑192410  
    S3‑192410 Solution for Protection of RRC Reject Message Huawei, Hisilicon pCR Approval Yes
Yes
approved No   S3‑192116
    S3‑192117 Solution for Protection of NAS Reject Message Huawei, Hisilicon pCR Approval Yes
Yes
revised No S3‑192411  
    S3‑192411 Solution for Protection of NAS Reject Message Huawei, Hisilicon pCR Approval No
Yes
noted No   S3‑192117
    S3‑191990 New solution (SERSI - SERving network controlled SI signatures) Ericsson pCR Approval Yes
YesFuturewei didnít agree with the new solution, only the delta should be shown. Ericsson: we have shown different aspects of the same solution in other TRs. Apple supported this solution. ORANGE: protection before the first registration is not covered. There was some strong disagreement with some other parts and the document was noted.
noted No    
    S3‑192209 Updates to Solution#7 on obtaining accurate clock information Samsung pCR Approval Yes
Yes
not treated No    
    S3‑192210 Deletion of EN on Location update reject in Solution#7 Samsung pCR Approval Yes
Yes
not treated No    
    S3‑192212 Assessment of solution #7 to Annex A.3 Samsung pCR Approval Yes
YesEricsson: sharing aspects are missing.It was sugested to add an editor's note on this assesment.
revised No S3‑192449  
    S3‑192449 Assessment of solution #7 to Annex A.3 Samsung pCR Approval Yes
Yes
approved No   S3‑192212
    S3‑192239 update of Certificate based solution Apple pCR Approval Yes
Yes
not treated No    
    S3‑192242 update of solution #14 Apple pCR Approval Yes
Yes
noted No    
    S3‑191922 Evaluation of the shared key based MIB/SIB protection solution Qualcomm Incorporated pCR Approval Yes
Yes
noted No    
    S3‑192261 Comments of S3-191922 Futurewei Technologies pCR Approval Yes
Yes
noted No    
    S3‑192072 A solution to MIB and SIB protection Huawei, Hisilicon pCR Approval Yes
Yes
not treated No    
    S3‑191863 Resolve EN on signaling details of how the UE hands over to false base station Huawei, HiSilicon pCR Approval Yes
Yes
not treated No    
    S3‑191864 Handover Attempts failure counter Huawei, HiSilicon pCR Approval Yes
Yes
not treated No    
    S3‑191865 Solution #4: Resolving EN on network verification of the hashes of MIB/SIBs Huawei, HiSilicon pCR Approval Yes
Yes
not treated No    
    S3‑191866 Solution #4: Resolving EN on Impact on UE power consumption Huawei, HiSilicon pCR Approval Yes
Yes
not treated No    
    S3‑191867 Solution #4: Details on the hash algorithm used for MIB/SIB hashes Huawei, HiSilicon pCR Approval Yes
Yes
not treated No    
    S3‑191869 Enabling UE to detect FBS Huawei, HiSilicon pCR Approval Yes
Yes
not treated No    
    S3‑192118 Solution for Avoiding UE connecting to False Base Station during Conditional Handover Huawei, Hisilicon pCR Approval Yes
Yes
not treated No    
    S3‑191956 Security solution for UE to avoid connecting to the false base station during a handover procedure Intel China Ltd. pCR   Yes
Yes
not treated No    
    S3‑191991 Conclusion on KI#3'S second requirement (reactive action) Ericsson pCR Approval Yes
Yes
not treated No    
    S3‑191950 Evaluation to Solution 6.6 Intel China Ltd. pCR Approval Yes
Yes
not treated No    
    S3‑191982 Update of Solution #15 Lenovo, Motorola Mobility pCR   Yes
Yes
not treated No    
    S3‑192145 Resolving the ENs in solution #5 Huawei, Hisilicon, Lenovo, Motorola Mobility pCR Approval Yes
Yes
not treated No    
    S3‑192240 update of Key issue#7 Apple pCR Approval Yes
Yes
withdrawn Yes    
    S3‑191921 Evaluation against MitM false base station attacks Qualcomm Incorporated discussion Endorsement Yes
Yes
not treated No    
    S3‑192243 Meeting minutes of SA3 5GFBS conference call on June 2th Apple pCR Information Yes
Yes
not treated No    
    S3‑192409 Report from offline discussions on 5GFBS Apple report Information Yes
Yes
noted No    
    S3‑192448 Draft TR 33.809 Apple draft TR Approval Yes
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‑191945 Addressing EN in solution#1 Nokia, Nokia Shanghai bell pCR Approval Yes
YesLenovo: You donít want the serving network know all users' IDs. Huawei: this solution provides protection of User ID for the slice authentication between UE and serving network. This statement was added.
revised No S3‑192363  
    S3‑192363 Addressing EN in solution#1 Nokia, Nokia Shanghai bell pCR Approval Yes
Yes
approved No   S3‑191945
    S3‑192260 Evaluation for solution #4 InterDigital, Inc. pCR Approval Yes
YesNokia clarified that this was compliant with SA2's work.
approved No   S3‑191819
    S3‑192199 A Solution to authentication method negotiation Huawei, HiSilicon pCR Approval Yes
YesEricsson: what is the reason for re-iventing the EAP negotiation?Nokia, ORANGE had also problems with this contribution.
noted No    
    S3‑191929 Conclusion to KI #1 (slice authentication) Huawei, HiSilicon pCR Approval Yes
YesNokia: not right for key issue 1.
revised No S3‑192366  
    S3‑192366 Conclusion to KI #1 (slice authentication) Huawei, HiSilicon pCR Approval Yes
Yes
approved No   S3‑191929
    S3‑191930 Conclusions to KI#2 (AMF Key separation) Huawei, HiSilicon pCR Approval Yes
Yes
revised No S3‑192367  
    S3‑192367 Conclusions to KI#2 (AMF Key separation) Huawei, HiSilicon pCR Approval Yes
YesIt was clarified that there was no conclusion was reached given that the use case in SA2 was not concluded either.
approved No   S3‑191930
    S3‑191932 Add evalution to solution 3 Huawei, HiSilicon pCR Approval Yes
YesORANGE objected to having this approved and preferred to to postpone the evaluation.There are some considerations in the solution that havenít been sufficiently assesed.
noted No    
    S3‑191931 Conclusions to KI#3 (NSaaS) Huawei, HiSilicon pCR Approval Yes
Yes
noted No    
    S3‑191946 2. Addressing EN in KI#4. Nokia, Nokia Shanghai bell pCR Approval Yes
YesLenovo: editor's note not addressed properly. The user could be compromised by the AMF and over the air protection would not be enough. Qualcomm: we have a big problem if the AMF is compromised, it is trusted.
noted No    
    S3‑191981 Removal of Editorís Notes of solution #5 Lenovo, Motorola Mobility pCR   Yes
YesORANGE: considerations of provisioning of public keys are being made when removing these editor's notes. We need to add a note on saying that these mechanisms will not be studied. The contribution found some additional opposition and it was finally noted.
noted No    
    S3‑191933 Amendment to solution 6 Huawei, HiSilicon pCR Approval Yes
YesNokia: what is being protected here? Is there any additional protection apart from NAS security? Huawei: EAP mechanisms. Qualcomm: this breaks the EAP model. You cannnot encypt the EAP ID (which is the user ID) you cannot do any routing. ORANGE: we donít have stable requirements today that justify the statement "meets the requirement of the key issue". This was left open.
noted No    
    S3‑192022 Adding evaluation and resolving EN in Solution 7 Ericsson pCR Approval Yes
YesORANGE: remove the evaluation. We donít have the requirement for this. Huawei agreed with the document.
revised No S3‑192369  
    S3‑192369 Adding evaluation and resolving EN in Solution 7 Ericsson pCR Approval Yes
YesFirst change was kept, evaluation was removed.
approved No   S3‑192022
    S3‑192149 Evaluation to solution #9 and conclusion to KI#5 Huawei, Hisilicon pCR Approval Yes
Yes
revised No S3‑192370  
    S3‑192370 Evaluation to solution #9 and conclusion to KI#5 Huawei, Hisilicon pCR Approval Yes
Yes
approved No   S3‑192149
    S3‑192023 Discussion paper on NSSAI in AS layer protection Ericsson pCR Discussion Yes
YesORANGE: encrypting the NSSAI brings a lot of overhead.
noted No    
    S3‑191934 Solution details on solution 8 Huawei, HiSilicon pCR Approval Yes
YesNokia: RAND per UE or per NSSAI? Huawei replied that per UE. Nokia suggested that this would have to be clarified. Ericsson: if the UE goes to IDLE and the RAND removes the context? Huawei: you would need to restart.
revised No S3‑192371  
    S3‑192371 Solution details on solution 8 Huawei, HiSilicon pCR Approval Yes
Yes
approved No   S3‑191934
    S3‑191935 Evalution for solution 8 Huawei, HiSilicon pCR Approval Yes
YesNokia: Complexity in gNB needs to be considered. Qualcomm: add an editor's note on what happens when the UE changes of NG-RAN node.
revised No S3‑192372  
    S3‑192372 Evalution for solution 8 Huawei, HiSilicon pCR Approval Yes
Yes
approved No   S3‑191935
    S3‑191910 Adding some details to solution #10 on protecting S-NSSAI at AS layer Qualcomm Incorporated pCR Approval Yes
YesNokia didnít find this very clear. The procedure to allocate and refresh the needed parameters needs to be clarified. An editor's note was added for this. Interdigital: add an editor's note on the encrypted NSSAI per UE. They were also concerned on the possibility of user tracking.
revised No S3‑192373  
    S3‑192373 Adding some details to solution #10 on protecting S-NSSAI at AS layer Qualcomm Incorporated pCR Approval Yes
Yes
approved No   S3‑191910
    S3‑191816 Discussion on S-NSSAI privacy protection InterDigital, Inc. discussion Endorsement Yes
YesNokia: this increases the complexity. ORANGE: the requirement on confidentiality protection of the NSSAI should be applied here. I prefer it to run in the RAN network. This is also adding complexity.
noted No    
    S3‑191817 Protection of S-NSSAI transmitted in the AS layer using T-S-NSSAI InterDigital, Inc. pCR Approval Yes
YesQualcomm: If the S-TMSI is stationary a dictionary attack is possible. Nokia agreed. An editor's note was agreed on this point. An sdditional editor's note were added as requested by Nokia.
revised No S3‑192374  
    S3‑192374 Protection of S-NSSAI transmitted in the AS layer using T-S-NSSAI InterDigital, Inc. pCR Approval Yes
Yes
approved No   S3‑191817
    S3‑191818 Protection of S-NSSAI transmitted in the AS layer InterDigital, Inc. pCR Approval Yes
Yes
noted No    
    S3‑191826 TR 33.813 - Evaluation for Solution X - S-NSSAI transmitted in the AS layer using T-S-NSSAI InterDigital, Inc. pCR Approval Yes
YesIt was clarified that this evaluated tdoc 817. ORANGE: this is still under study, as we have added editor's notes in tdoc 817. An editor's note was added to express that more evaluation was needed.
revised No S3‑192375  
    S3‑192375 TR 33.813 - Evaluation for Solution X - S-NSSAI transmitted in the AS layer using T-S-NSSAI InterDigital, Inc. pCR Approval Yes
Yes
approved No   S3‑191826
    S3‑191827 TR 33.813 - Evaluation for Solution Y - S-NSSAI transmitted in the AS layer InterDigital, Inc. pCR Approval Yes
Yes
noted No    
    S3‑191947 Adding text to Clause 9 Recommendations Nokia, Nokia Shanghai Bell pCR Approval Yes
Yes
revised No S3‑192376  
    S3‑192376 Adding text to Clause 9 Recommendations Nokia, Nokia Shanghai Bell pCR Approval Yes
YesRemoving the "shall"s as suggested by MCC and removing the second point.
approved No   S3‑191947
    S3‑191948 Draft WID for normative work on eNS. Nokia, Nokia Shangahi Bell WID new Approval Yes
YesHuawei: make it more generic. Vodafone preferred to have it more specific, more detailed. ORANGE: no reference to SA2's work. MCC commented that this was a feature, not a WID. They added that the normative CRs in 33.501 would be part of the objectives and not the justification. The SA2 work in parent WIDs table should be added in the related work items.
revised No S3‑192377  
    S3‑192377 WID for normative work on eNS. Nokia, Nokia Shangahi Bell WID new Agreement Yes
Yes
agreed No   S3‑191948
    S3‑192364 Draft TR 33.813 Nokia draft TR Approval No
Yes
eft for email approval No    
8.12 Study on Security of the enhancement to the 5GC location services (FS_eLCS_Sec) (Rel-16) S3‑191874 Requirement for key issue 5 in TR 33.814 (FS_eLCS_Sec) Philips International B.V. pCR Approval Yes
YesSprint: what about the fake measurements that are obtained by the UE but where the UE doesn't know that they are fake (e.g. spoofed messages)? Add a statement saying that the messages faked by the source are not covered. ESA: limit the scope of the requirement, as 5G positioning service can come from RAN dependent or RAN independent accesses. Ericsson: the solution for this problem doesnít need to be standardised. Qualcomm: it's a "should" requirement and add mechanisms to ensure the reliability of the location. Alf: clarify which part needs to be standardised. Huawei: keep the requirement, watch the solution. Ericsson: we need to be specific on what problem needs to be solved.
noted No    
    S3‑192069 Address EN in key issue 5 Huawei, Hisilicon pCR Approval Yes
Yes
noted No    
    S3‑191875 New solution to key issue 5 in TR 33.814 (FS_eLCS_Sec) Philips International B.V. pCR Approval Yes
Yes
noted No    
    S3‑192070 A solution to identify UEs that provides faked/altered location estimate or measurements Huawei, Hisilicon pCR Approval Yes
Yes
noted No    
    S3‑191962 pCR to TR33.814 - Key issue for the ciphering key management of broadcast assistance data CATT pCR Approval Yes
YesEricsson, Qualcomm: this is not needed. Nokia: SA2 hasnít decided whether the key is stored in the AMF yet. We donít support this document.
noted No    
    S3‑191965 pCR to TR33.814 - The solution for the ciphering key management of broadcast assistance data CATT pCR Approval Yes
Yes
noted No    
    S3‑192027 Resolving EN in KI#4 Ericsson pCR Approval Yes
YesHuawei: donít remove "system". Qualcomm: the 5GS includes the UE and the core network, we donít need the change. The editor's note can be removed. Alex (BT): LCS is a server-control applicationwhereas this reads like the UE will implement the provacy and user's consent in the handset. Qualcomm: SA2 has done this work already, no need to work on this requirement anymore. Huawei supported this.
noted No    
    S3‑191968 pCR to TR33.814 - Add reference for TR 33.814 CATT pCR Approval Yes
Yes
revised No S3‑192359  
    S3‑192359 pCR to TR33.814 - Add reference for TR 33.814 CATT pCR Approval Yes
YesIt Includes the content where the reference is used.
approved No   S3‑191968
    S3‑191969 pCR to TR33.814 - Addition of definition and abbreviation CATT pCR Approval Yes
Yes
approved No    
    S3‑191966 pCR to TR33.814 - The analysis of security architecture of eLCS CATT pCR Approval Yes
YesEricsson didnít agree with this.
noted No    
    S3‑191967 pCR to TR33.814 - Conclusions for TR33.814 CATT pCR Approval Yes
YesHuawei: let's go through the evaluations first before approving this conclusion. Alex (BT): the second point should be something like "no new mechanisms are needed". Dependent on tdoc 2076.
revised No S3‑192362  
    S3‑192362 pCR to TR33.814 - Conclusions for TR33.814 CATT pCR Approval Yes
Yes
approved No   S3‑191967
    S3‑192024 Conclusion on KI#1 (bluetooth positioning) Ericsson pCR Approval Yes
Yes
approved No    
    S3‑192025 Conclusion on KI#2 (TBS positioning) Ericsson pCR Approval Yes
Yes
approved No    
    S3‑192026 Conclusion on KI#3 (WLAN positioning) Ericsson pCR Approval Yes
Yes
approved No    
    S3‑192076 Add evualtion to solution 4 Huawei, Hisilicon pCR Approval Yes
YesAlex (BT): we have to assume that the serving network is behaving. This and other remarks were added into the evaluation.
revised No S3‑192361  
    S3‑192361 Add evualtion to solution 4 Huawei, Hisilicon pCR Approval Yes
Yes
approved No   S3‑192076
    S3‑192028 Conclusion on KI#4 (privacy control) Ericsson pCR Approval Yes
YesHuawei, Qualcomm didnít agree as it was covered by SA2 already.
noted No    
    S3‑192360 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‑192123 Remove the paragraph of Introduction Huawei, Hisilicon pCR Approval Yes
Yes
approved No    
    S3‑192124 Remove the unnecessary ENs of Key issue part Huawei, Hisilicon pCR Approval Yes
YesORANGE: removing the last editor's note is not editorial.
revised No S3‑192345  
    S3‑192345 Remove the unnecessary ENs of Key issue part Huawei, Hisilicon pCR Approval Yes
Yes
approved No   S3‑192124
    S3‑191994 URLLC: Table with available solutions in the TR Ericsson pCR Approval Yes
Yes
revised No S3‑192346  
    S3‑192346 URLLC: Table with available solutions in the TR Ericsson pCR Approval Yes
Yes
approved No   S3‑191994
    S3‑191894 Evaluation text for solution #5 in TR 33.825 NEC Europe Ltd pCR Approval Yes
Yes
noted No    
    S3‑191913 Evaluation of solution #5: Security for redundant data transmission Qualcomm Incorporated, Ericsson, Nokia pCR Approval Yes
Yes
revised No S3‑192347  
    S3‑192347 Evaluation of solution #5: Security for redundant data transmission Qualcomm Incorporated, Ericsson, Nokia pCR Approval Yes
Yes
approved No   S3‑191913
    S3‑191914 Conclusion on KI #1 for Study on the security for URLLC Qualcomm Incorporated, Ericsson, Nokia pCR Approval Yes
YesDiscussed together with tdoc 2120.
revised No S3‑192348  
    S3‑192348 Conclusion on KI #1 for Study on the security for URLLC Qualcomm Incorporated, Ericsson, Nokia,Huawei pCR Approval Yes
Yes
approved No   S3‑191914
    S3‑192120 Deleting the EN of conclusion 7.1 Huawei, Hisilicon pCR Approval Yes
Yes
merged No S3‑192348  
    S3‑191915 Conclusion on KI #2 for Study on the security for URLLC Qualcomm Incorporated, Ericsson, Nokia pCR Approval Yes
YesDiscussed together with tdoc 2122. Huawei: make it more generic, not only over-the-air.
merged No S3‑192349  
    S3‑192122 conclusion for key issue 2 Huawei, Hisilicon pCR Approval Yes
Yes
revised No S3‑192349  
    S3‑192349 conclusion for key issue 2 Huawei, Hisilicon,Qualcomm pCR Approval Yes
Yes
approved No   S3‑192122
    S3‑191993 URLLC: Recommendation for KI#3 Ericsson pCR Approval Yes
Yes
merged No S3‑192357  
    S3‑192119 conclusion for key issue 3 Huawei, Hisilicon pCR Approval Yes
Yes
revised No S3‑192357  
    S3‑192357 conclusion for key issue 3 Huawei, Hisilicon,Ericsson pCR Approval Yes
Yes
approved No   S3‑192119
    S3‑192121 Deleting the EN of conclusion 7.4 Huawei, Hisilicon pCR Approval Yes
Yes
revised No S3‑192358  
    S3‑192358 Deleting the EN of conclusion 7.4 Huawei, Hisilicon pCR Approval Yes
Yes
approved No   S3‑192121
    S3‑192344 Draft TR 33.825 Huawei draft TR Approval No
Yes
eft for email approval No    
8.14 Study on SECAM and SCAS for 3GPP virtualized network products (FS_VNP_SECAM_SCAS) (Rel-16) S3‑192183 Meeting notes of NFV SCAS conf call China Mobile other   Yes
Yes
noted No    
    S3‑192048 Scope of a SECAM SCAS for 3GPP virtualized network products China Mobile, Nokia, Nokia Shanghai Bell pCR Approval Yes
Yes
approved No    
    S3‑192062 Scope of SECAM evaluation for 3GPP virtualized network products China Mobile, Nokia, Nokia Shanghai Bell pCR Approval Yes
Yes
approved No    
    S3‑192063 Scope of SECAM Accreditation for 3GPP virtualized network products China Mobile pCR Approval Yes
YesAlex (BT) disagreed. This is outside of the scope of the 3GPP, and he didnít agree with the new text in the gap anlysis. An editor's note was added on the evaluation of the differences between the two types of network classes for acreditation purposes.
revised No S3‑192436  
    S3‑192436 Scope of SECAM Accreditation for 3GPP virtualized network products China Mobile pCR Approval Yes
Yes
approved No   S3‑192063
    S3‑192064 Adding roles in SECAM for 3GPP virtualized network products into clause 4.6 China Mobile, Nokia, Nokia Shanghai Bell pCR Approval Yes
YesAlex (BT): more of an answer, not a real gap analysis.The text doesnít fit the title. ORANGE: the text needs a language check. ORANGE: remove the last clause. Added a new editor's note on further analysis needed as well.
revised No S3‑192437  
    S3‑192437 Adding roles in SECAM for 3GPP virtualized network products into clause 4.6 China Mobile, Nokia, Nokia Shanghai Bell pCR Approval Yes
Yes
approved No   S3‑192064
    S3‑192127 Adding contents into clause 4 China Mobile pCR Approval Yes
Yes
noted