Tdoc List

2017-10-13 16:56

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‑172200 Agenda SA WG3 Chair agenda   Yes
Yes
 		approved No    
3 IPR Reminder                      
4 Work Areas                      
4.1 EPC enhancements to support 5G New Radio via Dual Connectivity (EDCE5) (Rel-15) S3‑172204 Reply LS on algorithm selection in E-UTRA-NR Dual Connectivity C1-173748 LS in   Yes
YesVodafone:Does the IE relate to the radio or to the core? Do you use LTE IE when you use 5G radio connected to the EPC, or do you use the 5G elements? This would lead to a matrix of four possible combinations and it affects the network selection. Ericsson and Vodafone agreed that it is related to the core and not to the radio.
 		noted No    
    S3‑172210 Reply LS on NR security input parameters R2-1709969 LS in   Yes
Yes
 		noted No    
    S3‑172275 Clarification NULL Integirity algorithm for OPtion3 Huawei; Hisilicon CR Approval Yes
YesVodafone: Is this the only place where we do the translation? This can produce some confusion in the future. Huawei: it helps to distinguish the 5G UE from 4G UE. Qualcomm: this will have impact on the system. We will also have to add an emergency calls clarification. This had to be taken offline. Show of hands to see what the feeling is in the room, whether they agree with the concept, not all the small details: 275 from Huawei, UP integrity algorithms should stay: Support --> Vodafone,Huawei 367, removing the algorithms: Support -->Qualcomm, Samsung
 		not pursued No    
    S3‑172366 Dealing with the text that moves from TS 33.401 to TS 33.501 in EDCE5 Qualcomm Incorporated discussion Discussion Yes
Yes
 		noted No    
    S3‑172367 Completing the specification of the algorithms to use between UE and SgNB in EDCE5 Qualcomm Incorporated CR Agreement Yes
YesQualcomm: 33.501 will be finished in March but we have to finish EDCE5 by Xmas, so we put it in 33.401 and then move it to 33.501. This text will be gone in March. Vodafone: there is a problem with network selection here. We want to use NR radio as soon as possible but this is wrong thinking. The link to the radio and not to the core is the issue for us. This had to be taken offline.
 		not pursued No    
    S3‑172415 CR to resolve EDCE5 ENs Nokia CR Approval Yes
Yes
 		revised No S3‑172575  
    S3‑172575 CR to resolve EDCE5 ENs Nokia CR Approval Yes
Yes
 		agreed No   S3‑172415
    S3‑172376 Adding a reference to RAN procedures on EDCE5 Qualcomm Incorporated CR Agreement Yes
Yes
 		agreed No    
    S3‑172377 Clarifying the behaviour of UE to SgNB connection at a MeNB handover Qualcomm Incorporated CR Agreement Yes
Yes
 		agreed No    
    S3‑172369 Aligning the specification of the key derivation function for key to use in security algorithms between UE and SgNB in EDCE5 with the 5G specification Qualcomm Incorporated CR Agreement Yes
YesNokia: why remove KSgNB-UP-int? This had to be taken offline.
 		revised No S3‑172576  
    S3‑172576 Aligning the specification of the key derivation function for key to use in security algorithms between UE and SgNB in EDCE5 with the 5G specification Qualcomm Incorporated CR Agreement Yes
Yes
 		agreed No   S3‑172369
    S3‑172371 Assigning an FC value for EDCE5 key derivations Qualcomm Incorporated CR Agreement Yes
Yes
 		revised No S3‑172513  
    S3‑172513 Assigning an FC value for EDCE5 key derivations Qualcomm Incorporated CR Agreement Yes
Yes
 		agreed No   S3‑172371
    S3‑172375 Clarifying the security algorithms that are used between the UE and MeNB and the UE and SgNB Qualcomm Incorporated CR Agreement Yes
Yes
 		agreed No    
    S3‑172232 Corrections to SgNB security procedures SAMSUNG CR Approval Yes
Yes
 		agreed No    
    S3‑172298 Editorial corrections for Annex E Huawei; Hisilicon CR Approval Yes
YesOverlaps with 232. Nokia didn’t agree with E.1.1: We don’t need to talk about SgNB here. This was removed.
 		revised No S3‑172514  
    S3‑172514 Editorial corrections for Annex E Huawei; Hisilicon CR Approval Yes
Yes
 		agreed No   S3‑172298
    S3‑172269 Discussion on the reception of UE NR security capabilities Huawei; Hisilicon discussion Approval Yes
Yes
 		noted No    
    S3‑172270 Reception of UE NR security capabilities Huawei; Hisilicon CR Approval Yes
Yes
 		not pursued No    
    S3‑172393 Discussion on the signalling and negotiation of the NR security capabilities Ericsson discussion Approval Yes
Yes
 		noted No    
    S3‑172394 UE supported NR security algorithms indicated in NAS protocol Ericsson CR Agreement Yes
Yes
 		not pursued No    
    S3‑172372 Discussion of possible methods and proposed solution for negotiating the algorithms for use between a UE and SgNB in EDCE5 Qualcomm Incorporated discussion Discussion Yes
YesNokia: NAS based option impacts all existing eNodeBs. It has a big impact. Qualcomm: not all eNodeBs are upgraded. Huawei, NEC and Ericsson supported the NAS based solution.This was agreed as the way forward.
 		noted No    
    S3‑172373 Using AS layer signalling to negotiate the algorithm used between the UE and SgNB Qualcomm Incorporated CR Agreement Yes
Yes
 		not pursued No    
    S3‑172374 Using NAS layer signalling to negotiate the algorithm used between the UE and SgNB Qualcomm Incorporated CR Agreement Yes
Yes
 		not pursued No    
    S3‑172512 Work status of EDCE5 post SA3#88Bis Qualcomm other Information No
YesIt gathers all the changes of EDCE5 so the CRs in the next meeting don’t overlap with the agreed CRs of this meeting.
 		left for email approval No    
4.2 Security aspects of 5G System - Phase 1 (5GS_Ph1-SEC) (Rel-15) S3‑172580 Key open issues WG Chair discussion Information No
YesList of topics listed in order of priority. This was a list of open issues after the current meeting.The bold parts have higher priority.
 		noted No    
4.2.1 Key hierarchy S3‑172437 Clause 6.2 (key hierarchy from K to KSEAF) Ericsson discussion Endorsement Yes
Yes
 		noted No    
    S3‑172285 5G-RAN Key Setting Huawei & Hisilicon pCR Approval Yes
YesEricsson: NAS keys part will be relocated when a clause is created for them. An editor's note was added for this. Vodafone didn’t agree with this content and since there was no support it was finally noted.
 		noted No    
    S3‑172405 Key hierarchy Nokia pCR   Yes
YesORANGE: In "This further key may be stored in the AUSF between authentication and key agreement procedures.", this is implementation-specific and left out to the operator. Alignment with 6.1.1.1 was checked and the operator policy was mentioned there, so no change was necessary. NTT-Docomo: remove reference to 5G phase one in the notes. MCC also commented that mentioning "future phases of 5G" in the note was not appropiate either, and argued agains have it as an editor's note that would stay even after the draft was approved. It was left as an editor's note. Gemalto: replace USIM with 5G USIM. Qualcomm: The current definition of USIM does not cover the case when the UICC is integrated in a tamper resistant environment, which can be the case for 5G. BT objected to "For every key in a network entity, there is a corresponding key in the UE." since the UE could store hundreds of keys for this reason. It was decided to keep this sentence anyway. On the editor's note in 6.6.2: Leaving the first editor's note : 16 companies. Adding "for example" for a legacy USIM used in the second editor's note: three companies. This editor's note was removed.
 		revised No S3‑172547  
    S3‑172547 Key hierarchy Nokia, Ericsson, Huawei,NEC pCR - Yes
Yes
 		approved No   S3‑172405
    S3‑172431 5G Key Hierarchy NEC EUROPE LTD pCR Approval Yes
Yes
 		merged No S3‑172547  
    S3‑172481 Security for multiple NAS connections with single anchor key Ericsson discussion Approval Yes
YesProposal 3 was agreed with the assumption that Kamf is sent as it is, or a derivation of it being sent. Proposal 4 was agreed too. The document was revised to include the proposals that were endorsed.
 		revised No S3‑172554  
    S3‑172554 Security for multiple NAS connections with single anchor key Ericsson discussion Endorsement Yes
Yes
 		endorsed No   S3‑172481
    S3‑172491 Multiple registrations Ericsson pCR Approval Yes
YesMCC commented that the introduced defintions were not written as definitions but they were introducing more content. Some rewording was needed, adding notes when appropiate and also move the unnecessary content to the right clauses. Ericsson commented that these were coming from LTE, to which MCC replied that this was an opportunity to improve the definition wording.
 		revised No S3‑172555  
    S3‑172555 Multiple registrations Ericsson pCR Approval Yes
Yes
 		agreed No   S3‑172491
    S3‑172440 Clause 6.2 (key hierarchy, from KSEAF downwards) Ericsson, Huawei pCR Approval Yes
Yes
 		merged No S3‑172547  
    S3‑172433 Key Hierarchy to support multiple NAS security NEC EUROPE LTD pCR Approval Yes
Yes
 		noted No    
4.2.2 Key derivation S3‑172384 Discussion on bidding down of security features Qualcomm Incorporated discussion Discussion Yes
Yes
 		noted No    
    S3‑172401 Preventing bidding down between 5G releases - discussion Nokia discussion   Yes
Yes
 		noted No    
    S3‑172403 Preventing bidding down between 5G releases - pCR Nokia pCR   Yes
YesEricsson and Huawei didn’t agree with this solution.
 		noted No    
    S3‑172416 Computation of key left at the AUSF for 5G AKA Nokia pCR   Yes
Yes
 		noted No    
    S3‑172464 Derivation of anchor key for EAP-AKA’ Nokia pCR   Yes
Yes
 		noted No    
    S3‑172458 Computation of key left at the AUSF for EAP-AKA’ Nokia pCR   Yes
Yes
 		noted No    
    S3‑172378 Specifying the usage of EMSK as the key used to derive the 5G keys when using EAP as an authentication method Qualcomm Incorporated pCR Approval Yes
Yes
 		revised No S3‑172577  
    S3‑172577 Specifying the usage of EMSK as the key used to derive the 5G keys when using EAP as an authentication method Qualcomm Incorporated pCR Approval Yes
YesAdding an editor's note as suggested by Nokia.
 		approved No   S3‑172378
    S3‑172286 Providing details on the authentication vector and calculation of keys Huawei & Hisilicon pCR Approval Yes
Yes
 		revised No S3‑172578  
    S3‑172578 Providing details on the authentication vector and calculation of keys Huawei & Hisilicon pCR Approval Yes
Yes
 		approved No   S3‑172286
    S3‑172436 5G Key Derivation and distribution scheme NEC EUROPE LTD pCR Approval Yes
YesNokia, Ericsson: too early for this diagram and didn’t agree with it.
 		noted No    
    S3‑172262 pCR to TS 33.501: reusing {NCC, NH} to key derivation for handover Huawei; Hisilicon pCR Approval Yes
Yes
 		revised No S3‑172564  
    S3‑172564 pCR to TS 33.501: reusing {NCC, NH} to key derivation for handover Huawei; Hisilicon pCR Approval Yes
YesIt fixes clashes with 324.
 		approved No   S3‑172262
    S3‑172321 Clause 8.3.1.1.1 (key handling in handover, general, access stratum) - Disc Ericsson discussion Discussion Yes
Yes
 		noted No    
    S3‑172322 Clause 8.3.1.1.1 (key handling in handover, general, access stratum) - pCR Ericsson pCR Approval Yes
YesNokia argued about the chain-hole since 4G is working fine.and this may confuse current implementations. Huawei agreed, they wanted some consistency. Ericsson: why keeping something that is wrong and that can be fixed simply? KPN agreed with Ericsson. The Chair requested a show of hands for 322 and 262: Who supports 322: Ericsson,Intel, KPN Who supports 262: Nokia, NTT-Docomo, Huawei, Samsung,Deutsche Telekom The overall sentiment was to go for 262 and 322 was noted.
 		noted No    
    S3‑172323 Clause 8.3.1.1.1 (key derivation in handover key chaining model) - Disc Ericsson discussion Decision Yes
Yes
 		noted No    
    S3‑172324 Clause 8.3.1.1.1 (key derivation in handover, general, access stratum) - pCR Ericsson pCR Approval Yes
Yes
 		approved No    
    S3‑172427 Annex A key derivation function Nokia pCR Approval Yes
YesRevised in order to fix the FC values as proposed by NTT-Docomo. These values will be fixed later and sync with 33.220 so an editor's note was added.
 		revised No S3‑172557  
    S3‑172557 Annex A key derivation function Nokia pCR Approval Yes
Yes
 		approved No   S3‑172427
    S3‑172382 Specifying the key derivation when using 5G AKA Qualcomm Incorporated pCR Approval Yes
Yes
 		noted No    
4.2.3 Mobility S3‑172439 Discussion on skeleton for clause 6.5 and related contents in clauses 6 and 8 NEC EUROPE LTD, Lenovo, Motorola Mobility, Samsung, AT&T, KPN pCR Discussion Yes
Yes
 		noted No    
    S3‑172456 Skeleton for clause 6.5 Security handling in mobility NEC EUROPE LTD, Lenovo, Motorola Mobility, Samsung, AT&T, KPN pCR Approval Yes
YesClashing with tdoc 414 from Nokia.
 		revised No S3‑172558  
    S3‑172558 Skeleton for clause 6.5 Security handling in mobility NEC EUROPE LTD, Lenovo, Motorola Mobility, Samsung, AT&T, KPN pCR Approval Yes
Yes
 		approved No   S3‑172456
    S3‑172459 Update to clause 6.5 Security handling in mobility NEC EUROPE LTD, Lenovo, Motorola Mobility, Samsung, AT&T, KPN pCR Approval Yes
Yes459 was merged into 566, 567, 559.
 		merged No S3‑172559,S3‑172566,S3‑172567  
    S3‑172335 Clause 8.3.1.4.4 (key change on fly, NAS key re-keying) Ericsson pCR Approval Yes
Yes
 		merged No S3‑172558  
    S3‑172414 Security handling in mobility Nokia pCR   Yes
Yes
 		revised No S3‑172559  
    S3‑172559 Security handling in mobility Nokia pCR - Yes
Yes
 		approved No   S3‑172414
    S3‑172387 pCR to provide a normative text for the AMF key derivation/refresh Qualcomm Incorporated pCR Approval Yes
YesIt clashes with 271. NEC and AT&T supported this contribution. AT&T: keep this in phase one, littles changes in phase two. Nokia and Huawei had reservations on the KEY_COUNT. Ericsson proposed to continue the discussion for the next meeting. So this was noted.
 		noted No   S3‑172010
    S3‑172271 key isolation between AMFs during idle mode mobility Huawei; Hisilicon pCR Approval Yes
YesEricsson preferred this option to the Huawei option.
 		merged No S3‑172559  
    S3‑172325 Clause 8.3.1.1.2 (key handling in handover, general, non access stratum) Ericsson pCR Approval Yes
Yes
 		revised No S3‑172561  
    S3‑172561 Clause 8.3.1.1.2 (key handling in handover, general, non access stratum) Ericsson pCR Approval Yes
Yes
 		approved No   S3‑172325
    S3‑172326 Clause 8.3.1.2 (key derivation for context modification procedure) Ericsson pCR Approval Yes
YesHuawei queried about the "final KNgb". It was revised to clarify this.
 		revised No S3‑172562  
    S3‑172562 Clause 8.3.1.2 (key derivation for context modification procedure) Ericsson pCR Approval Yes
Yes
 		approved No   S3‑172326
    S3‑172250 Intra-gNB meaning in 5G RAN architecture Huawei, Hisilicon, China Mobile pCR Approval Yes
YesNokia didn’t agree with having this kind of change. Vodafone, ORANGE and BT supported it. NTT-Docomo: where does the PDCP terminate? Better to say this than talking about intra gNB-CU handover. Nokia: we need to say more about the split architecture and an new clause should added for this.
 		approved No    
    S3‑172327 Clause 8.3.1.3.1 (key derivation during handover, intra-gNB) Ericsson pCR Approval Yes
Yes
 		revised No S3‑172563  
    S3‑172563 Clause 8.3.1.3.1 (key derivation during handover, intra-gNB) Ericsson pCR Approval Yes
Yes
 		approved No   S3‑172327
    S3‑172259 Discussion on flexibility of retaining or changing AS security key Huawei; Hisilicon discussion Discussion Yes
YesNokia: we should go to RAN2 when we have a specific question. I can’t see the issues. Ericsson: in proposal one we only agree with the Handover; not with the rest. There wasn't much support for this.
 		noted No    
    S3‑172260 Draft LS on Discussion on flexibility of retaining or changing AS security key Huawei; Hisilicon LS out Approval Yes
Yes
 		noted No    
    S3‑172246 Flexible retaining AS keys solution Huawei, Hisilicon, China Mobile pCR Approval Yes
YesEricsson: Implementation dependent to say how long to keep the key. China Mobile: wjen the HO is made, we face the situation when the key may be changed or not and when. We support Huawei, we need to know in which situation the key is changed. Nokia didn’t agree with the contribution. The best mechanism is the key refresh. Samsung: retaining key time is a very complex procedure. Huawei: the gNodeB needs a mechanism to decided whether to retain a key or not. It’s not a new procedure but a policy.
 		noted No    
    S3‑172461 Update to clause 8.3 Security handling in mobility NEC EUROPE LTD, Lenovo, Motorola Mobility, Samsung, AT&T, KPN pCR Approval Yes
YesEricsson: remove NSSAI part.
 		merged No S3‑172566  
    S3‑172328 Clause 8.3.1.3.2/8.3.1.3.2 (key derivation during handover, Xn/N2) - Discussion Ericsson discussion Discussion Yes
Yes
 		noted No    
    S3‑172329 Clause 8.3.1.3.2 (key derivation during handover, Xn) - pCR Ericsson pCR Approval Yes
YesSupported by Intel, who noted 504. Huawei found it difficult to find a difference with LTE. Nokia: this is a significant improvement over LTE. There might be implications that RAN2,RAN3 should investigate. Qualcom also preferred to hear from RAN3. It was agreed to send an LS to RAN3 cc RAN2.
 		revised No S3‑172566  
    S3‑172566 Clause 8.3.1.3.2 (key derivation during handover, Xn) - pCR Ericsson,NEC pCR Approval Yes
Yes
 		approved No   S3‑172329
    S3‑172330 Clause 8.3.1.3.3 (key derivation during handover, N2) - pCR Ericsson pCR Approval Yes
Yes
 		revised No S3‑172567  
    S3‑172567 Clause 8.3.1.3.3 (key derivation during handover, N2) - pCR Ericsson,NEC pCR Approval Yes
Yes
 		approved No   S3‑172330
    S3‑172253 Updates security handling in mobility Huawei, Hisilicon, Deutsche Telekom AG pCR Approval Yes
YesKPN: Diffie-Hellman introduces a lot of man-in-the-middle problems. Huawei: the attacker would have to control the source gNB, access the air interface,…very complex to be able to perform this attack. NTT-Docomo suppported KPN. Nokia: Diffie-Hellman consumes a lot of resources and latency. There was no much support for this contribution.
 		noted No    
    S3‑172504 Security key handling during Xn handover Intel pCR Approval Yes
Yes
 		noted No   S3‑172320
    S3‑172388 pCR to provide a normative text for AS key derivation Qualcomm Incorporated pCR Approval Yes
Yes
 		noted No   S3‑172011
    S3‑172389 pCR to provide a normative text for AS key hierarchy Qualcomm Incorporated pCR Approval Yes
YesEricsson, Huawei and Nokia didn’t support this.
 		noted No   S3‑172012
    S3‑172331 Clause 8.3.1.3.4 (key derivation during handover, UE handling) Ericsson pCR Approval Yes
Yes
 		approved No    
    S3‑172332 Clause 8.3.1.4.1 (key change on fly, general) Ericsson pCR Approval Yes
Yes
 		approved No    
    S3‑172333 Clause 8.3.1.4.2 (key change on fly, AS key re-keying) Ericsson pCR Approval Yes
Yes
 		revised No S3‑172568  
    S3‑172568 Clause 8.3.1.4.2 (key change on fly, AS key re-keying) Ericsson pCR Approval Yes
Yes
 		approved No   S3‑172333
    S3‑172334 Clause 8.3.1.4.3 (key change on fly, AS key refresh) Ericsson pCR Approval Yes
Yes
 		approved No    
    S3‑172320 Security key handling during Xn handover Intel pCR Approval Yes
Yes
 		revised No S3‑172504  
    S3‑172565 LS on handling concurrent running of security procedures Ericsson LS out Approval Yes
Yes
 		approved No    
4.2.4 AS security S3‑172343 UE-assisted network-based detection of false base station - disc Ericsson discussion Discussion Yes
Yes
 		not treated No    
    S3‑172344 UE-assisted network-based detection of false base station - pCR Ericsson pCR Approval Yes
Yes
 		not treated No    
    S3‑172245 Address EN in requirements for gNB setup and configuration Huawei, Hisilicon, pCR Approval Yes
Yes
 		not treated No    
    S3‑172256 Security Procedures between 5G Network Functions Huawei, Hisilicon pCR Approval Yes
Yes
 		not treated No    
    S3‑172247 Requirements for UP and CP for the gNB Huawei, Hisilicon, China Mobile pCR Approval Yes
Yes
 		not treated No    
    S3‑172417 Clause 5.2.9 CU-DU interface requirements Nokia pCR Approval Yes
Yes
 		not treated No    
    S3‑172248 Support NIA0 algorithm for UP data Huawei, Hisilicon pCR Approval Yes
Yes
 		not treated No    
    S3‑172500 Integrity for UP, RRC and NAS Huawei; Hisilicon pCR   Yes
Yes
 		not treated No    
    S3‑172502 Replay protection for UP, RRC and NAS Huawei; Hisilicon pCR   Yes
Yes
 		not treated No    
    S3‑172501 Confidentiality for UP, RRC and NAS Huawei; Hisilicon pCR   Yes
Yes
 		not treated No    
    S3‑172255 Adding Forward & Backward Security definition to TS33.501 Huawei, Hisilicon pCR Approval Yes
Yes
 		not treated No    
    S3‑172236 Discussion on user plane protection SAMSUNG discussion   Yes
Yes
 		not treated No    
    S3‑172252 Security Algorithms Negotiation for Initial AS security context Huawei, Hisilicon, China Mobile pCR Approval Yes
Yes
 		not treated No    
    S3‑172276 Discussion on a framework of AS security Huawei; Hisilicon discussion Approval Yes
Yes
 		not treated No    
    S3‑172336 Clause 8 (open issues in AS security) - Disc Ericsson discussion Discussion Yes
Yes
 		not treated No    
    S3‑172277 AS Security Negotiation and Activation Huawei, Hisilicon pCR Approval Yes
Yes
 		not treated No    
    S3‑172278 UP security policy Huawei; Hisilicon pCR Approval Yes
Yes
 		not treated No    
    S3‑172279 UP protection features Huawei; Hisilicon pCR Approval Yes
Yes
 		not treated No    
    S3‑172337 Clause 8.1.2.1.1 (AS algo. initial context) for RRC Ericsson pCR Approval Yes
Yes
 		not treated No    
    S3‑172338 Clause 8.1.2.2 (AS security mode command procedure) for RRC Ericsson pCR Approval Yes
Yes
 		not treated No    
    S3‑172339 Clause 8 (user plane security - integrity protection) Ericsson pCR Approval Yes
Yes
 		not treated No    
    S3‑172340 Clause 8 (user plane security - confidentiality) Ericsson pCR Approval Yes
Yes
 		not treated No    
    S3‑172341 Clause 8 (relation between RRC and user plane security algorithms) Ericsson pCR Approval Yes
Yes
 		not treated No    
    S3‑172342 Clause 8 (conflict between RAN and CN) Ericsson pCR Approval Yes
Yes
 		not treated No    
    S3‑172258 Security Handling for RRC Connection Re-establishment Huawei; Hisilicon pCR Approval Yes
Yes
 		not treated No    
    S3‑172261 pCR to TS 33.501: Security Handling at Transition from RRC-INACTIVE to RRC-CONNECTED transition Huawei; Hisilicon pCR Approval Yes
Yes
 		not treated No    
    S3‑172233 pCR on signalling procedure for periodic local authentication SAMSUNG pCR Approval Yes
Yes
 		not treated No    
    S3‑172419 Clause 8.4 UP security mechanisms Nokia pCR Approval Yes
Yes
 		not treated No    
4.2.5 NAS security S3‑172406 New requirements for algorithm selection in TS 33.501 Ericsson pCR Approval Yes
Yes
 		not treated No    
    S3‑172400 Exception lists of NAS and RRC message to be integrity protected and encrypted Ericsson pCR Approval Yes
Yes
 		not treated No    
    S3‑172420 Clause 6.6.3 NAS integrity Nokia pCR Approval Yes
Yes
 		not treated No    
    S3‑172395 Registration state transitions in TS 33.501 Ericsson pCR Approval Yes
Yes
 		not treated No    
    S3‑172421 Clause 6.6.5 Handling of NAS counts Nokia pCR Approval Yes
Yes
 		not treated No    
    S3‑172430 Connection state transitions in TS 33.501 Ericsson pCR Approval Yes
Yes
 		not treated No    
    S3‑172296 Adding content to NAS security Huawei; Hisilicon pCR Approval Yes
Yes
 		not treated No    
    S3‑172383 Aligning the protection of initial NAS messages and the NAS Security Mode procedure subclauses Qualcomm Incorporated pCR Approval Yes
Yes
 		not treated No    
    S3‑172425 Clause 6.7.2 NAS SMC procedure Nokia pCR Approval Yes
Yes
 		not treated No    
    S3‑172229 PCR to 33.501 – Clause 6.7.2 – rephrased for clarity InterDigital, Inc. pCR Approval Yes
Yes
 		not treated No    
    S3‑172263 Delete allowed NSSAI in NAS SMC Huawei; Hisilicon pCR Approval Yes
Yes
 		not treated No    
    S3‑172423 Clause 6.7.1.2 AMF change Nokia pCR Approval Yes
Yes
 		not treated No    
4.2.6 Security context management S3‑172413 New UE requirement to store two 5G security contexts in TS 33.501 Ericsson pCR Approval Yes
Yes
 		not treated No    
    S3‑172272 Adding the definition of NEA0 and NIA0(5.6.1) Huawei; Hisilicon pCR Approval Yes
Yes
 		not treated No    
    S3‑172370 Providing details of the key derivation for the security algorithm keys Qualcomm Incorporated pCR Approval Yes
Yes
 		not treated No    
    S3‑172273 Adding the content on security contexts(6.3) Huawei; Hisilicon pCR Approval Yes
Yes
 		not treated No    
    S3‑172408 Handling security contexts within the serving network Nokia pCR   Yes
Yes
 		not treated No    
    S3‑172411 Clause 6.3.2 (Handling security contexts within the serving network) Ericsson pCR Approval Yes
Yes
 		not treated No    
    S3‑172410 Distribution of security contexts Nokia pCR   Yes
Yes
 		not treated No    
    S3‑172412 Security handling in state transitions Nokia pCR   Yes
Yes
 		not treated No    
    S3‑172257 pCR to TS 33.501 KDF negotiation Huawei; Hisilicon pCR Approval Yes
Yes
 		not treated No    
    S3‑172462 Discussion on 5G UE Security Capabilities with KDF identifiers NEC EUROPE LTD pCR Discussion Yes
Yes
 		not treated No    
    S3‑172466 5G UE Security Capabilities with KDF identifiers NEC EUROPE LTD pCR Approval Yes
Yes
 		not treated No    
4.2.7 Visibility & configurability S3‑172495 Security Visibility clarification LG Electronics pCR Approval Yes
Yes
 		not treated No    
    S3‑172221 Add new requirement related to visibility and configurability CATT, CATR pCR Approval Yes
Yes
 		not treated No    
    S3‑172486 pCR to 33.501 5.4.1 - Clarification of security indication NTT DOCOMO, Department of Commerce pCR Approval Yes
Yes
 		not treated No    
    S3‑172399 Visibility and configurability supporting serving network authorization Nokia pCR   Yes
YesQualcomm didn’t agree with this whole scheme, it would affect the service. Some reservations among the companies on the display of the serving network identifier or MCC. NTT-Docomo: what if you have an handover to a cell of the forbidden operator? Huawei: the user doesn't know who the roaming partner of the HPLMN is. They didn't understand the use of this. LG supported the idea of this contribution but didn’t understand the use of the MCC here. The authorization part should be removed. BT: displaying the country code, shouldn’t it be GSMA input? The security levels for roaming partners is their field.
 		not treated No    
4.2.8 Primary authentication S3‑172226 Rewriting Clause 6.1.2 and 6.1.3 in normative language and adding Annex A KPN N.V. pCR Approval Yes
YesKPN: AUSF is always in the Home Network, that's my understanding. Nokia: there's a interim requirement about this.
 		revised No S3‑172569  
    S3‑172569 Rewriting Clause 6.1.2 and 6.1.3 in normative language and adding Annex A KPN N.V. pCR Approval Yes
Yes
 		approved No   S3‑172226
    S3‑172230 PCR to 33.501 – Clause 6.1.3.1 – rephrased for clarity InterDigital, Inc. pCR Approval Yes
Yes
 		approved No    
    S3‑172237 Discussion on UDM term consistency SAMSUNG discussion Approval Yes
Yes
 		noted No    
    S3‑172478 5G AKA Discussion of Option 1 and Option 2 Huawei, HiSilicon pCR Decision Yes
YesInterdigital supported this contribution. Nokia pointed out that this contribution was not supported in past conference calls. A show of hands proved that most of the companies didn’t still support it.
 		noted No    
    S3‑172223 Moving Serving Network Name construction into it's own clause KPN N.V. pCR Approval Yes
YesTIM: Is there a possibility of pre-computing the authentication vector or not? If we have to change the response depending on to which network we send it to, where is the calculation performed? This had to be taken offline.
 		revised No S3‑172571  
    S3‑172571 Moving Serving Network Name construction into it's own clause KPN N.V. pCR Approval Yes
Yes
 		approved No   S3‑172223
    S3‑172397 Authentication and Authorization – requirements and more Nokia pCR   Yes
YesNTT-Docomo: refer to the relevant specifications instead of just saying 2G,3G,4G in the notes. Qualcomm agreed, no need to have all these notes. NTT-Docomo commented that this information would be useful for the future summary of the WID. Qualcomm had issues with serving network authentication and authorization. NTT-Docomo supported the effort of this contribution. The Chair commented that there was quite a lot of support for this contribution except Qualcomm's reservations. Qualcomm proposed to keep the requirements and remove the notes. There was further discussion on the serving network athorization and 399 was open in order to detail it further. It was agreed to add an editor's note on the serving network auth to be FFS. The case of the emergency calls was also left for further study.
 		revised No S3‑172572  
    S3‑172572 Authentication and Authorization – requirements and more Nokia pCR - Yes
Yes
 		approved No   S3‑172397
    S3‑172475 Conveying authentication result from AUSF to UDM Nokia pCR   Yes
Yes
 		revised No S3‑172573  
    S3‑172573 Conveying authentication result from AUSF to UDM Nokia pCR - Yes
Yes
 		approved No   S3‑172475
    S3‑172485 pCR to 33.501 6.1.3.2 – Mandate sending of AC NTT DOCOMO pCR Approval Yes
Yes
 		approved No    
    S3‑172487 pCR to 33.501 6.1.2, 6.1.3.2 – only one authentication vector at a time NTT DOCOMO pCR Approval Yes
YesSamsung and Qualcomm supported this contribution. NCSC: it is possible that this doesn’t work in IOPS. This had to be taken offline.
 		noted No    
    S3‑172489 pCR to 33.501 6.1.3.2 – Mandate signalling of expiry time of NTT DOCOMO pCR Approval Yes
YesBT:unstable, prone to all kind of service attacks. There seemed to be support in this document with some fixes. Ericsson proposed a note to address BT's concerns: the serving network should have time to run the authentication.
 		revised No S3‑172574  
    S3‑172574 pCR to 33.501 6.1.3.2 – Mandate signalling of expiry time of NTT DOCOMO pCR Approval Yes
Yes
 		approved No   S3‑172489
    S3‑172290 EAP Framework Huawei & Hisilicon pCR Approval Yes
Yes
 		revised No S3‑172552  
    S3‑172552 EAP Framework Huawei & Hisilicon pCR Approval Yes
YesOverlapped with 402. Vodafone commented that the Note should be an editor's note since it is talking about the future. This didn’t have any support so it was noted.
 		noted No   S3‑172290
    S3‑172402 EAP framework Ericsson, Nokia, Samsung, Qualcomm Incorporated, Intel, Huawei pCR Approval Yes
YesORANGE and Oberthur had issues with this contribution. It was taken offline.
 		revised No S3‑172579  
    S3‑172579 EAP framework Ericsson, Nokia, Samsung, Qualcomm Incorporated, Intel, Huawei pCR Approval Yes
Yes
 		approved No   S3‑172402
    S3‑172480 AKA Procedure in Interworking and Migration Scenarios Huawei, HiSilicon pCR Decision Yes
YesVodafone: I thought that AKA matched in the HSS- equivalent and the USIM. There wasn't any support for this contribution.
 		noted No    
    S3‑172289 Security Procedures with EAP-TLS Huawei & Hisilicon pCR Approval Yes
Yes
 		not treated No    
    S3‑172224 Rewriting Clause 6.1.2 and 6.1.3 in normative language and adding Annex A KPN N.V. pCR Approval Yes
Yes
 		withdrawn Yes    
4.2.9 Secondary authentication S3‑172457 Secondary authentication - Clause 12.1.2 - Resolve EN on use of Normative language Nokia pCR Approval Yes
Yes
 		not treated No    
    S3‑172460 Secondary Authentication - Resolve Editor’s Notes Nokia pCR Approval Yes
Yes
 		not treated No    
    S3‑172463 Secondary Authentication - Update text with corresponding service operations used to carry EAP messages Nokia pCR Approval Yes
Yes
 		not treated No    
    S3‑172287 Discussion on secondary authentication Huawei & Hisilicon discussion Approval Yes
Yes
 		not treated No    
    S3‑172288 Secondary authentication via NEF Huawei & Hisilicon pCR Approval Yes
Yes
 		not treated No    
    S3‑172496 Clarification on network slice access authentication and authorization LG Electronics pCR Approval Yes
Yes
 		not treated No    
    S3‑172380 Identifying a problem with secondary authentication Qualcomm Incorporated pCR Approval Yes
Yes
 		not treated No   S3‑172008
    S3‑172318 Solution to prevent unauthorized access to external Data Network Intel pCR Approval Yes
Yes
 		not treated No    
    S3‑172319 Binding Primary and Secondary authentication Intel discussion Discussion Yes
Yes
 		not treated No    
    S3‑172293 ID linkage verification in secondary authentication Huawei & Hisilicon pCR Approval Yes
Yes
 		not treated No    
    S3‑172292 DN authorization grant and revocation Huawei & Hisilicon pCR Approval Yes
Yes
 		not treated No    
    S3‑172317 Secondary Re-Authentication Intel pCR Approval Yes
Yes
 		not treated No    
    S3‑172294 Secondary authentication for multiple PDU sessions Huawei & Hisilicon pCR Approval Yes
Yes
 		not treated No    
4.2.10 Interworking S3‑172264 Discussion on security of interworking Huawei; Hisilicon discussion Discussion Yes
Yes
 		not treated No    
    S3‑172385 Security handling for interworking between NextGen Core and EPC Qualcomm Incorporated discussion Approval Yes
Yes
 		not treated No   S3‑172009
    S3‑172404 Discussion on the security for interworking between EPC and 5GC Ericsson discussion Approval Yes
Yes
 		not treated No    
    S3‑172469 Interworking - Discussion paper on security context Nokia pCR Approval Yes
Yes
 		not treated No    
    S3‑172477 Interworking - Discussion paper on issues when Interworking with a legacy MME Nokia pCR Approval Yes
Yes
 		not treated No    
    S3‑172492 Interworking - Discussion paper on integrity protection of idle mobility MM message during interworking Nokia pCR Approval Yes
Yes
 		not treated No    
    S3‑172265 regestration procedures in 5G-RAN during interworking from EPC to 5GC Huawei; Hisilicon pCR Approval Yes
Yes
 		not treated No    
    S3‑172429 Idle mode mobility from 4G to 5G Nokia pCR Approval Yes
Yes
 		not treated No    
    S3‑172266 TAU procedures in E-UTRAN during interworking from 5GC to EPC Huawei; Hisilicon pCR Approval Yes
Yes
 		not treated No    
    S3‑172432 Security for Idle mode mobility from 5G to 4G Nokia pCR Approval Yes
Yes
 		not treated No    
    S3‑172407 Proposal for a new subclause 9.X on mapping of security contexts during interworking between 4G and 5G Ericsson pCR Approval Yes
Yes
 		not treated No    
    S3‑172409 Proposal for a new subclause 9.Y on interworking security in idle mode Ericsson pCR Approval Yes
Yes
 		not treated No    
    S3‑172386 pCR to provide a solution for interworking between NextGen Core and EPC Qualcomm Incorporated pCR Approval Yes
Yes
 		not treated No   S3‑172014
    S3‑172267 handover procedures during interworking from EPC to 5GC Huawei; Hisilicon pCR Approval Yes
Yes
 		not treated No    
    S3‑172434 Security for Handover from 4G to 5G Nokia pCR Approval Yes
Yes
 		not treated No    
    S3‑172268 handover procedures during interworking from 5GC to EPC Huawei; Hisilicon pCR Approval Yes
Yes
 		not treated No    
    S3‑172438 Security for Handover from 5G to 4G Nokia pCR Approval Yes
Yes
 		not treated No    
    S3‑172295 Interworking with EPC without N26 Huawei; Hisilicon pCR Approval Yes
Yes
 		not treated No    
4.2.11 Non-3GPP access S3‑172490 Drawbacks of the NAS-over-IKE solution Motorola Mobility, Lenovo, Broadcom, Brocade, Rogers Wireless, Samsung, ITRI, CATT, Cisco discussion Approval Yes
Yes
 		revised No S3‑172510  
    S3‑172510 Drawbacks of the NAS-over-IKE solution Motorola Mobility, Lenovo, Broadcom, Brocade, Rogers Wireless, Samsung, ITRI, CATT, Cisco discussion Endorsement Yes
YesQualcomm: Initial NAS protection in 501 is not understood here, in 2.7. The security concern is not valid. Ericsson agreed with this.They also commented that the document was more SA2 oriented than security oriented. ORANGE and Intel agreed with Qualcomm about the clause 2.7. Nokia and Samsung agreed with the security conccerns in this document.
 		noted No   S3‑172490
    S3‑172398 Re-authentication in Solution 1.49 Ericsson discussion Endorsement Yes
YesNEC commented that this is not such a rare case. Ericsson: Reauthentication will not happen all the time.Most people connect to a few selected Wifi networks. Broadcom: not about one user but about multiple number of users in this situation.
 		noted No    
    S3‑172483 Details of EAP-5G Solution for registration via untrusted non-3GPP access Motorola Mobility, Lenovo, Broadcom, Brocade, Rogers Wireless, Samsung, ITRI, CATT, Cisco discussion Approval Yes
Yes
 		revised No S3‑172511  
    S3‑172511 Details of EAP-5G Solution for registration via untrusted non-3GPP access Motorola Mobility, Lenovo, Broadcom, Brocade, Rogers Wireless, Samsung, ITRI, CATT, Cisco discussion Endorsement Yes
Yes
 		noted No   S3‑172483
    S3‑172391 Discussion on Security for Non-3GPP access to 5GC Qualcomm Incorporated discussion Endorsement Yes
Yes
 		noted No    
    S3‑172468 Skeleton for clause 11 NEC EUROPE LTD pCR Approval Yes
YesNokia: 5 should go to clause 11. Qualcomm agreed. 11.6 and 11.7 were not agreed to be here.
 		noted No    
    S3‑172472 5G AKA to be used over all access network types – clause 6 Nokia pCR   Yes
YesQualcomm: no need to have this Editor's note. Nokia: it's a reminder.
 		approved No    
    S3‑172474 5G AKA to be used over all access network types – clause 11 Nokia pCR   Yes
Yes
 		approved No    
    S3‑172390 pCR: Security for Non-3GPP access to 5GC Qualcomm Incorporated pCR Approval Yes
Yes
 		noted No    
    S3‑172471 Security aspects of Non-3GPP access using 5G Core Network NEC EUROPE LTD pCR Approval Yes
YesNokia: not based on the SA2 procedure. They haven't defined such handover. NEC: the intention is to add this procedure. Huawei: this is in SA2 scope. We can only define the security aspect of a handover procedure.
 		noted No    
    S3‑172546 LS on N3GPP access Ericsson LS out Approval Yes
Yes
 		approved No    
4.2.12 NDS S3‑172203 Way for protecting sensitive information transmitted between operators ZTE Corporation, China Mobile, CATR pCR Approval Yes
Yes
 		not treated No    
    S3‑172281 pCR to TS 33.501 add management plane protection to 7.2 Huawei; Hisilicon pCR Approval Yes
Yes
 		not treated No    
    S3‑172282 pCR to TS 33.501 add reference to management plane to 5.2.4 Huawei; Hisilicon pCR Approval Yes
Yes
 		not treated No    
4.2.13 Service based architecture S3‑172227 Security Considerations for Service Based Architecture in 5G Deutsche Telekom AG discussion Endorsement Yes
YesHuawei: in Goal#5, which scenario supports hop-by-hop security? DT: In the interconnect case there are situations when end-to-end security is not possible. NTT-Docomo: some of the goals are already mentioned in our requirements. It was clarified that these were work principles for a new topic in SA3 and that an endorsement of the goals expressed here would help. NCSC was confused with folllowing this line of work, so it was decided to revise the document to have a set of goals that everybody could endorse. ORANGE preferred to remove the reference to the third party in goal#3. DT: can this be done in phase one? ORANGE: we can give security recommendations for implementation if we don’t have time for requirements. The Chair clarified that the TS will not give details on the implementation anyway, and agreed that this could be done.
 		revised No S3‑172533  
    S3‑172533 Security Considerations for Service Based Architecture in 5G Deutsche Telekom AG discussion Endorsement Yes
Yes
 		endorsed No   S3‑172227
    S3‑172244 Update the skeleton of TS 33.501 for service based architecture Huawei, Hisilicon, CATR pCR Approval Yes
Yes
 		merged No S3‑172534 S3‑172238
    S3‑172396 Introducing clause for Secrity Aspects of Service Based Architecture Ericsson pCR Approval Yes
Yes
 		merged No S3‑172534  
    S3‑172479 Skeleton for interconnection network security Nokia pCR   Yes
YesVodafone: no requirements? Nokia: they are in another document. Vodafone preferred this approach to the Huawei proposal. They also commented that SBA for roaming would be more complex and a separate clause would be needed for this. BT didn’t agree with splitting for roaming. Alex (BT) warned about the trust boundaries. Nokia commented that both trust boundaries and platform requirements can be treated in the next meeting. Inputs on this will be brought into the Reno meeting.
 		revised No S3‑172534  
    S3‑172534 Skeleton for interconnection network security Nokia pCR - Yes
Yes
 		approved No   S3‑172479
    S3‑172476 Clarification of requirements on e2e core interconnection network security Nokia pCR   Yes
Yes
 		revised No S3‑172536  
    S3‑172536 Clarification of requirements on e2e core interconnection network security Nokia pCR - Yes
Yes
 		approved No   S3‑172476
    S3‑172239 Security requirements for service based architecture Huawei, Hisilicon pCR Approval Yes
YesVodafone: this doesn’t feel like a requirements section, the language style and the way it is written are not correct. TIM:optional confidentiality and integrity protection? Mandatory to support or optional? DT: authentication of network functions as they register should be included here. The Chair commented that the essence of the document seemed to be fine, but it required some more work with the wording. It was decided to work on this offline and come back with an input for the next meeting.
 		noted No    
    S3‑172240 NF registration and authentication procedure of Service Based Architecture Huawei, Hisilicon pCR Approval Yes
YesTIM: premature to bring this. Ericsson agreed. Vodafone: this needs some language check.
 		noted No    
    S3‑172470 Discussion and pCR on authorization issue for 5G core network with SBA China Mobile Com. Corporation pCR   Yes
YesInterdigital: the Note is solution related, it shouldn’t be here. Vodafone: this doesn’t read lile a requirement. It needs proper wording.TIM agreed. People seemed to agree with the document, although rewording was needed. The note was removed.
 		revised No S3‑172538  
    S3‑172538 Discussion and pCR on authorization issue for 5G core network with SBA China Mobile Com. Corporation pCR - Yes
Yes
 		approved No   S3‑172470
    S3‑172241 Authorization of NF service discovery Huawei, Hisilicon pCR Approval Yes
YesVodafone pointed out the language aspect, it needed reqording. In roaming scenarion there are no issues with the authentification. The non roaming scenario is not as clear as you think. TIM: authorization is enough? Authentication could also be necessary. Ericsson and Nokia: lot of stuff repeated from 23.401.
 		noted No    
    S3‑172242 Authorization of NF service access Huawei, Hisilicon pCR Approval Yes
YesVodafone: Both flows seem to be very similar. One option combining both flows would be sufficient. TIM: this is written more like a SA2 contribution. Vodafone agreed, this is pushed towards the service discovery not the authorization. Ericsson agreed that this was not clear.A way forward would be to add this to the living document. Interdigital: it describes how to authorise, not about the discovery. I would like to see more of this. TIM: we are jumping straightly into solutions. Not even for the living document. Nokia agreed that this should not go as the solution for the TS, but it should go as an option to the living document.
 		revised No S3‑172539  
    S3‑172539 Authorization of NF service access Huawei, Hisilicon pCR Approval Yes
YesApproved to go to the living document in 540.
 		approved No   S3‑172242
    S3‑172243 Protection of the connection between NFs Huawei, Hisilicon pCR Approval Yes
YesVodafone: there are cost concerns here, it would be too expensive to implement. This needs to have lots of small tunnels better than big tunnels. Juniper: the cost of TLS proxies is much higher than IPsec so we should be careful with this.
 		noted No    
    S3‑172238 Update the skeleton of TS 33.501 for service based architecture Huawei, Hisilicon pCR Approval No
Yes
 		revised No S3‑172244  
    S3‑172540 Living document on SBA China Mobile other Approval Yes
Yes
 		approved No    
4.2.14 Privacy (not covered by other headings) S3‑172220 Remove editor notes related to privacy requirements CATT, CATR pCR Approval Yes
Yes
 		not treated No    
    S3‑172509 Privacy requirements on the UE Nokia pCR Decision Yes
Yes
 		not treated No   S3‑172352
    S3‑172297 Caculation of SUCI in ME Huawei; Hisilicon pCR Approval Yes
Yes
 		not treated No    
    S3‑172358 UDM requirements - key management and privacy Nokia pCR Decision Yes
Yes
 		not treated No    
    S3‑172222 Remove editor note related to SIDF and text corrections CATT pCR Approval Yes
Yes
 		not treated No    
    S3‑172356 SIDF functionality Nokia pCR Decision Yes
Yes
 		not treated No    
    S3‑172284 Raw public key provisioning CATT pCR Approval Yes
Yes
 		not treated No    
    S3‑172346 Clauses 6.8.3 (5G-GUTI refresh at periodic registration update) Ericsson, Telecom Italia pCR Approval Yes
Yes
 		not treated No    
    S3‑172347 Clauses 6.8.3 (5G-GUTI refresh at network triggered service request) Ericsson, Telecom Italia pCR Approval Yes
Yes
 		not treated No    
    S3‑172362 Cleaning up sections 6.8.1 and 6.8.2 about Subscription (Concealed) Identifier KPN N.V. pCR Approval Yes
Yes
 		not treated No    
    S3‑172254 Moving UE handling SUCI to SUCI clause Huawei, Hisilicon, China Mobile pCR Approval Yes
Yes
 		not treated No    
    S3‑172354 Merging and enhancing 6.8.1 and 6.8.2 Nokia pCR Decision Yes
Yes
 		not treated No    
    S3‑172251 Subscriber Privacy under Home network control Huawei, Hisilicon pCR Approval Yes
Yes
 		not treated No    
    S3‑172249 Meeting SUPI privacy and LI Requirements Huawei, Hisilicon, Intel pCR Approval Yes
Yes
 		not treated No    
    S3‑172506 LI conformity when privacy is used Nokia pCR Decision Yes
Yes
 		not treated No   S3‑172359
    S3‑172345 Clauses 6.1.3 and 6.7.2 (auth procedures and NAS SMC, SUPI from UE for LI) Ericsson, Telecom Italia pCR Approval Yes
Yes
 		not treated No    
    S3‑172225 Discussion on provision of SUPI from home to visited network VODAFONE Group Plc discussion Discussion Yes
Yes
 		not treated No    
    S3‑172365 Comments on S3-172225 KPN N.V. discussion Discussion Yes
Yes
 		not treated No    
    S3‑172316 Changes to Initiation of Authentication and subscription identity procedure. Intel pCR Approval Yes
Yes
 		not treated No    
    S3‑172570 Changes to Initiation of Authentication and subscription identity procedure. Intel pCR Approval No
Yes
 		withdrawn Yes    
    S3‑172355 SIDF purpose in initiation of authentication Nokia pCR Decision Yes
Yes
 		not treated No    
    S3‑172488 pCR to 33.501 6.1.3.1, 6.1.3.2 – SUPI assurance in SEAF NTT DOCOMO pCR Approval Yes
Yes
 		not treated No    
    S3‑172348 Selection of SUCI null-scheme Ericsson pCR Approval Yes
Yes
 		not treated No    
    S3‑172363 Procedure for Visited Network to request SUPI attach KPN N.V. pCR Approval Yes
Yes
 		not treated No    
    S3‑172364 Annex C: Adding Creation of the 'visited network requests null-scheme message' KPN N.V. pCR Approval Yes
Yes
 		not treated No    
    S3‑172357 Null scheme clarifications - resolving ed.note Nokia pCR Decision Yes
Yes
 		not treated No    
    S3‑172353 Requirement on AMF Nokia pCR Decision Yes
Yes
 		not treated No    
    S3‑172274 Adding the content on Subscription identification procedure(6.8.4) Huawei; Hisilicon pCR Approval Yes
Yes
 		not treated No    
    S3‑172283 Remove editor note related to SUCI CATT pCR Approval Yes
Yes
 		not treated No    
    S3‑172497 SUCI calculation Gemalto, G&D, Morpho & Oberthur (IDEMIA), Vodafone pCR Approval Yes
Yes
 		revised No S3‑172530  
    S3‑172530 SUCI calculation Gemalto, G&D, Morpho & Oberthur (IDEMIA), Vodafone pCR Approval Yes
Yes
 		not treated No   S3‑172497
    S3‑172503 pCR: Calculation of SUCI Qualcomm Incorporated pCR Approval Yes
Yes
 		not treated No   S3‑172392
    S3‑172351 (Resubmission) Annex X.3 (SUCI, ECIES scheme normative Annex) Ericsson pCR Approval Yes
Yes
 		not treated No    
    S3‑172349 (Resubmission) Discussion for drafting reply to S2-175309, relates NSSAI privacy Ericsson discussion Discussion Yes
YesQualcomm: it has to go to phase one or it won’t be usable. China Mobile didn’t support proposal 3 but they were fine with the rest. Ericsson: the consequence is that the authentication of the network slice will be delayed. There was no agreement with the proposal one. Huawei supported proposal three. Interdigital didn't support proposal 4. The Chair suggested a show of hands: Proposal one not in phase one: 9 companies Proposal one in phase one: 4 companies After this Qualcomm decided to go for phase two in order to make progress.
 		noted No    
    S3‑172361 was S3-171949 Discussion of NSSAI privacy Nokia pCR Decision Yes
YesBT and Interdigital disagreed with the conclusion. Ericsson and LG disagreed with this one.
 		noted No    
    S3‑172360 was S3-171950 TS - NSSAI privacy Nokia pCR Decision Yes
Yes
 		noted No    
    S3‑172379 Discussion on sending S-NSSAIs to the network unprotected Qualcomm Incorporated discussion Endorsement Yes
YesEricsson: why such a strong requirement on the deployment? We don’t agree with this at all. LG: I doubt that this is efficient. One policy for all UE, not slice based.
 		noted No    
    S3‑172291 Confidentiality of NSSAI Huawei & Hisilicon pCR Approval Yes
YesORANGE: How can we use theHome Network public key for the encryption if we are in the serving network? China Mobile: we cannot agree with this contribution. Interdigital didn’t support it either. Ericsson: the HN public key mechanism is optional, that is Huawei's intention here. Nokia: then the "shall" is not correct here.
 		noted No    
    S3‑172493 NSSAI Privacy Discussion LG Electronics discussion Endorsement Yes
YesLG: Send the solutions to SA2 and let them decide.
 		noted No    
    S3‑172494 NSSAI Privacy handling LG Electronics discussion Endorsement Yes
YesEricsson didn't understand the solution
 		noted No    
    S3‑172350 (Resubmission) draft Reply LS on Reply LS on 5GS Security aspects seeking resolution Ericsson pCR Approval Yes
YesORANGE: don’t send privacy sensitive information in the NSSAI. Nokia: NAS security established, there is encryption already and it is protected. Qualcomm asked to be in the minutes: Although SA3 is sending the LS the interim agreement hasn’t changed. The agreed LS is in 517.
 		noted No    
    S3‑172352 Privacy requirements on the UE Nokia pCR Decision Yes
Yes
 		revised No S3‑172509  
    S3‑172359 LI conformity when privacy is used Nokia pCR Decision Yes
Yes
 		revised No S3‑172506  
    S3‑172392 pCR: Calculation of SUCI Qualcomm Incorporated pCR Approval Yes
Yes
 		revised No S3‑172503  
    S3‑172473 SUCI calculation Gemalto, G&D, Morpho & Oberthur (IDEMIA) pCR Approval Yes
Yes
 		withdrawn Yes    
4.2.15 Others S3‑172206 LS on applicability of service based interface for legacy core network elements C1-173753 LS in   Yes
YesIt was decided to wait for SA2's response to react to this LS.
 		noted No    
    S3‑172207 Reply LS on 5G signalling protocol requirements C4-174311 LS in   Yes
Yes
 		noted No    
    S3‑172208 LS on Conclusion on Service Based Architecture Protocol Selection C3-174370,C4-174343 LS in   Yes
Yes
 		noted No    
    S3‑172209 LS to SA3 on RAN2 agreements on jumbo frames R2-1709804 LS in   Yes
YesNokia: I think it has been commented before that ZUC may have problems. Ericsson: ZUC was checked with ETSI SAGE and there was no problem. This was discussed in the San Diego meeting.
 		replied to No    
    S3‑172515 Reply to: LS to SA3 on RAN2 agreements on jumbo frames Ericsson LS out approval Yes
Yes
 		approved No    
    S3‑172211 LS reply on Support for fake gNB detection mechanisms R2-1709980 LS in   Yes
Yes
 		noted No    
    S3‑172212 LS on secure storage and processing of subscription credentials S1-173475 LS in   Yes
YesORANGE: the stated service requirement is a SA3 requirement. Vodafone: it's both SA1 and SA3 requirement. It started as a SA1 and SA plenary requirement. ORANGE: We already have 33.501 requirements on this. Vodafone: we cannot have a published document referring to the draft 33.501. Vodafone: it's clearly a security requirement and they have made a commitment to align with our view. Ericsson: this is a working agreement and it’s a stable requirement. ORANGE agreed with Vodafone, it’s a security requirement. The SA1 spec is not clearly the place to have this requirement.
 		postponed No    
    S3‑172213 LS on PLMN and RAT selection policies for roaming S1-173478 LS in   Yes
Yes
 		noted No    
    S3‑172214 Reply LS on Address Mapping Requirements S2-176561 LS in   Yes
Yes
 		noted No    
    S3‑172215 LS Response on Service Based Architecture S2-176692 LS in   Yes
Yes
 		noted No    
    S3‑172216 LS on Undetectability of LI Data stored in a UDSF S3i170259 LS in   Yes
Yes
 		noted No    
    S3‑172217 Address Mapping Requirements S3i170260 LS in   Yes
Yes
 		noted No    
    S3‑172218 Reply LS on 5GS Security aspects seeking resolution S2-175309 LS in   Yes
Yes
 		replied to No    
    S3‑172517 Reply to: Reply LS on 5GS Security aspects seeking resolution Qualcomm LS out approval Yes
Yes
 		approved No    
    S3‑172219 LS on PLMN and RAT selection policies for roaming S2-175286 LS in   Yes
YesVodafone: there is a steering of roaming from the SIM to the UE to change the network since Rel-8. A solution exists already.
 		replied to No    
    S3‑172516 Reply to: LS on PLMN and RAT selection policies for roaming Huawei LS out approval Yes
YesA solution has been discussed and it is possible. There were several issues that SA3 had agreed to include in the LS: need of feedback on specific messages, where the keys are stored and messages prepared, serious implications on security architecture, why OTA solution doesn’t work,… but companies differed on the different versions of the LS in the drafts folder (v2 and v3).
 		revised No S3‑172581  
    S3‑172581 Reply to: LS on PLMN and RAT selection policies for roaming Huawei LS out approval Yes
Yes
 		approved No   S3‑172516
    S3‑172205 Reply LS to LS on PLMN and RAT selection policies for roaming C1-173751 LS in   Yes
YesVodafone: This is another unnecessary secure area to get away from what the SIM provides. Qualcomm: CT1 and SA2 are aware about Vodafone's statement, they are looking for a control plane security solution. Vodafone: OTA solution is misrepresented in the LS. Qualcomm: the VPLMN only has access to the information passing through, not to the UE at all. Qualcomm: it is not up to SA3 to discuss OTA solutions. NTT-Docomo: we don’t understand why SA2 has opted for this.Let's ask them what is the new mechanism's advantage over OTA.
 		replied to No    
    S3‑172499 Response to LS from SA3 to TC Cyber regarding 256-bit key lengths ETSI TC CYBER LS in   Yes
Yes
 		noted No    
    S3‑172299 pCR on editorial correction of TS 33.501 NEC EUROPE LTD pCR Approval Yes
YesNokia: 5GS is used in SA2 as EPS. It was commented that pCRs for this meeting would clash and make the implementation harder. The Rapporteur would have to take care of this. It was also commented that the abbreviations for AIR and AMF would have to be dealt with since they refer to different terms. Notes would clarify this issue.
 		revised No S3‑172518  
    S3‑172518 pCR on editorial correction of TS 33.501 NEC EUROPE LTD pCR Approval Yes
Yes
 		approved No   S3‑172299
    S3‑172280 Corrections on 33501 Huawei; Hisilicon pCR Approval Yes
Yes
 		revised No S3‑172519  
    S3‑172519 Corrections on 33501 Huawei; Hisilicon pCR Approval Yes
Yes
 		approved No   S3‑172280
    S3‑172484 Editorials against 33.501 NTT DOCOMO pCR Approval Yes
Yes
 		revised No S3‑172520  
    S3‑172520 Editorials against 33.501 NTT DOCOMO pCR Approval Yes
Yes
 		approved No   S3‑172484
    S3‑172228 PCR to 33.501 – typos and language in multiple clauses. InterDigital, Inc. pCR Approval Yes
Yes
 		revised No S3‑172521  
    S3‑172521 PCR to 33.501 – typos and language in multiple clauses. InterDigital, Inc. pCR Approval Yes
Yes
 		approved No   S3‑172228
    S3‑172381 Proposed re-wording to the bidding down requirement Qualcomm Incorporated pCR Approval Yes
YesChina Mobile asked about the situation when both the UE and network are made to believe they are in 2G. Qualcomm clarified that this is a requirement for 5G. Nokia: mention "5G security features". Ericsson: clarify that the attacker is external. NTT docomo: external to the security domain. This had to be taken offline.
 		merged No S3‑172520  
    S3‑172368 Providing full details of the integrity and ciphering algorithms for TS 33.501 Qualcomm Incorporated pCR Approval Yes
Yes
 		revised No S3‑172523  
    S3‑172523 Providing full details of the integrity and ciphering algorithms for TS 33.501 Qualcomm Incorporated pCR Approval Yes
YesQualcomm clarified that these are both user plane and control plane algorithms.BT asked to distinguish them.
 		approved No   S3‑172368
    S3‑172422 Skeleton for Security for IMS Emergency session Nokia pCR Approval Yes
Yes
 		approved No    
    S3‑172424 Security for Authenticated IMS Emergency sessions Nokia pCR Approval Yes
YesQualcomm: emergency sessions are part of phase one? Nokia: it is for phase one for 3GPP access.
 		revised No S3‑172524  
    S3‑172524 Security for Authenticated IMS Emergency sessions Nokia pCR Approval Yes
YesAddressing Ericsson's comments on authentication aspects.
 		approved No   S3‑172424
    S3‑172426 Security for unauthenticated IMS Emergency sessions Nokia pCR Approval Yes
YesTIM: what is older SIM? Nokia: non-5G SIM. It was commented to better refer to "USIM" instead of SIM.
 		revised No S3‑172525  
    S3‑172525 Security for unauthenticated IMS Emergency sessions Nokia pCR Approval Yes
Yes
 		approved No   S3‑172426
    S3‑172482 Discussion on protection of Network Steering Information Ericsson discussion Approval Yes
Yes
 		noted No    
    S3‑172234 Discussion on Securing the Network Steering Information SAMSUNG pCR Approval Yes
Yes
 		noted No    
    S3‑172235 pCR for Securing the Network Steering Information SAMSUNG pCR Approval Yes
YesVodafone: In this case, everytime I want to change the preferred list I need to do the authentication again. End to end security solution is possible but more details are needed. Mandatory IE in every message was objected by Vodafone. Where are the keys stored and where all the message are being processed? This had to be considered further. Vodafone pointed out that the relation with the other lists needed to be clarified. Nokia also commented that the security impacts on the architecture were big and had to be considered as well. Vodafone: the impact on security architecture is so big that it would need a TR for this topic only.
 		noted No    
    S3‑172505 First response on ECIES for concealing IMSI or SUPI ETSI SAGE LS in   Yes
Yes
 		noted No    
    S3‑172428 Editorial updates in TS 33.501 NEC EUROPE LTD pCR Approval No
Yes
 		withdrawn Yes    
    S3‑172522 Draft TS 33.501 NTT-Docomo draft TS Approval No
Yes
 		left for email approval No    
    S3‑172553 LS on support of jumbo frames using EIA3 Vodafone LS out Approval Yes
Yes
 		approved No    
    S3‑172560 pCR to TS33.501 clause 5.4.2 taken from S3-172484 NTT-Docomo pCR Approval No
Yes
 		withdrawn Yes    
4.3 Security of the Mission Critical Service (MCSec) (Rel-14) S3‑172231 Corrections to MCData security procedures SAMSUNG CR   Yes
Yes
 		revised No S3‑172532  
    S3‑172532 Corrections to MCData security procedures SAMSUNG CR - Yes
Yes
 		agreed No   S3‑172231
    S3‑172300 [MCSec] 33180 R14 client check at GMK provisioning Motorola Solutions CR Agreement Yes
Yes
 		withdrawn Yes    
    S3‑172301 [MCSec] 33180 R14 add transmission control for MCVideo Motorola Solutions CR Agreement Yes
Yes
 		agreed No    
    S3‑172302 [MCSec] 33180 R14 MCPTT to MCX fixes Motorola Solutions CR Agreement Yes
Yes
 		agreed No    
    S3‑172303 [MCSec] 33180 R14 SIP MESSAGE clarification for MCData Motorola Solutions CR Agreement Yes
Yes
 		agreed No    
    S3‑172452 [MCSEC] Clarification on SSRC use in group communications in TS 33.180 Rel-14 NCSC CR Agreement Yes
Yes
 		revised No S3‑172541  
    S3‑172541 [MCSEC] Clarification on SSRC use in group communications in TS 33.180 Rel-14 NCSC CR Agreement Yes
Yes
 		agreed No   S3‑172452
4.4 Mission Critical Security Enhancements (eMCSec) (Rel-15) S3‑172443 [eMCSEC] Adding KMS Redirect Responses to TS 33.180 NCSC CR Agreement Yes
Yes
 		revised No S3‑172528  
    S3‑172528 [eMCSEC] Adding KMS Redirect Responses to TS 33.180 NCSC CR Agreement Yes
Yes
 		agreed No   S3‑172443
    S3‑172444 [eMCSEC] KMS enhancement, including Migration KMS, for TS 33.180 NCSC CR Agreement Yes
Yes
 		revised No S3‑172535  
    S3‑172535 [eMCSEC] KMS enhancement, including Migration KMS, for TS 33.180 NCSC CR Agreement Yes
Yes
 		agreed No   S3‑172444
    S3‑172448 [eMCSEC] Addition of Clause on Logging, Audit and Discreet Monitoring for TS 33.180 NCSC CR Agreement Yes
Yes
 		revised No S3‑172537  
    S3‑172537 [eMCSEC] Addition of Clause on Logging, Audit and Discreet Monitoring for TS 33.180 NCSC CR Agreement Yes
Yes
 		agreed No   S3‑172448
    S3‑172451 [eMCSEC] Addition of signalling Proxies to TS 33.180 NCSC CR Agreement Yes
Yes
 		revised No S3‑172544  
    S3‑172544 [eMCSEC] Addition of signalling Proxies to TS 33.180 NCSC CR Agreement Yes
Yes
 		agreed No   S3‑172451
    S3‑172418 Key Management of end-to-end encryption for mission critical communications between LMR users and 3GPP users Sepura PLC discussion Endorsement Yes
YesThere were some concerns so it was decided to send an LS to SA6 instead of endorsing this document.
 		noted No    
    S3‑172455 [eMCSEC] LS to SA6 on configuration parameters NCSC LS out Approval Yes
Yes
 		withdrawn Yes    
    S3‑172304 [eMCSec] 33180 R15 client check at GMK provisioning (mirror) Motorola Solutions CR Agreement Yes
Yes
 		withdrawn Yes    
    S3‑172305 [eMCSec] 33180 R15 add transmission control for MCVideo (mirror) Motorola Solutions CR Agreement Yes
Yes
 		withdrawn Yes    
    S3‑172306 [eMCSec] 33180 R15 MCPTT to MCX fixes (mirror) Motorola Solutions CR Agreement Yes
Yes
 		withdrawn Yes    
    S3‑172307 [eMCSec] 33180 R15 SIP MESSAGE clarification for MCData (mirror) Motorola Solutions CR Agreement Yes
Yes
 		withdrawn Yes    
    S3‑172453 [eMCSEC] Clarification on SSRC use in group communications in TS 33.180 Rel-15 NCSC CR Agreement Yes
Yes
 		withdrawn Yes    
    S3‑172545 LS to SA6 on end to end encryption for mission critical communications between LMR users and 3GPP users. NCSC LS out Approval Yes
Yes
 		approved No    
4.5 5G Phase-1 New SIDs or WIDs (Rel-15) S3‑172465 Discussion on necessity and way forward of security study for 5G core network with SBA China Mobile Com. Corporation discussion Discussion Yes
Yes
 		noted No    
    S3‑172467 New WID for enhanced security function to 5GC Service Based Architecture China Mobile Com. Corporation WID new   Yes
YesNokia didn’t agree with having this as a separate WID in the same timescale as the 5G phase one work.Guenther proposed to extend the objectives of the current 5G work.ORANGE agreed. Deutsche Telekom agreed to have this work as well, in one way or another. Vodafone supported this work on service architecture for 5G. NTT-Docomo: this needs to go to phase one, but it makes more sense to have it as a revision of the current WID.Ericsson agreed. BT: I'm concerned about the objective 2 on different PLMNs. Too ambitious to include roaming interfaces. The Chair suggested to add this in the current WID within its objectives and present a revision of the 5G WID to the plenary. ORANGE: in the current WID we are already saying that we need to address the security features of whatever SA2 is doing, so this is covered already. We don’t need to change the objectives every time SA2 comes up with something. Vodafone: this is to show that we are focusing our attention on this issue.
 		noted No    
    S3‑172498 New SID on 256-bit algorithms for 5G VODAFONE Group Plc SID new Agreement Yes
Yes
 		noted No    
    S3‑172507 Comments to "New SID on 256-bit algorithms for 5G" Ericsson discussion Discussion Yes
YesBT supported removing the quantum part.
 		merged No S3‑172556  
    S3‑172508 New SID on 256-bit algorithms for 5G – with Nokia comments Nokia SID new   Yes
YesAT&T: too much detail. They didn’t support going for Statements like strengthening the OTA. I have problems with the justification rather than the objectives. Option preferred by ORANGE among the proposed studies. They had issues with the justification. Vodafone: this gives a wider scope. Interdigital: expanding the scope when there is so little time to work on this? Qualcomm: look at the entire system, not only the OTA. We prefer the Nokia option. NCSC preferred the Nokia option for having the better scope. AT&T: the use of commercial devices for the secure communication is not acceptable. US department of commerce: 128 bit keys is our recommendation. We support the study item but it should focus less on the quantum part. NCSC: according to the latest NIST document, the 128 bits should be sufficient until at least 2030. Alex (BT) was concerned about having to adapt the whole commercial network to fit a relatively small portion of users. KPN agreed with this.
 		revised No S3‑172556  
    S3‑172556 New SID on 256-bit algorithms for 5G Nokia SID new - Yes
Yes
 		agreed No   S3‑172508
    S3‑172531 Revised WID 5G security phase one China Mobile WID revised Agreement Yes
Yes
 		agreed No    
5 Studies                      
5.1 Study on Mission Critical Security Enhancements (FS_MC_Sec) (Rel-14) S3‑172435 [eMCSEC] Update to KMS Discovery Solution in TR 33.880 NCSC pCR Approval Yes
Yes
 		revised No S3‑172526  
    S3‑172526 [eMCSEC] Update to KMS Discovery Solution in TR 33.880 NCSC pCR Approval Yes
Yes
 		approved No   S3‑172435
    S3‑172441 [eMCSEC] KMS Discovery Use cases for TR 33.880 NCSC pCR Approval Yes
Yes
 		revised No S3‑172527  
    S3‑172527 [eMCSEC] KMS Discovery Use cases for TR 33.880 NCSC pCR Approval Yes
Yes
 		approved No   S3‑172441
    S3‑172442 [eMCSEC] Evaluation of KMS Discovery in TR 33.880 NCSC pCR Approval Yes
Yes
 		approved No    
    S3‑172445 [eMCSEC] KMS Lookup (DNSSec) solution for TR 33.880 NCSC pCR Approval No
Yes
 		withdrawn Yes    
    S3‑172446 [eMCSEC] Key Issues on Interworking and Interconnetion security for TR 33.880 NCSC pCR Approval Yes
Yes
 		approved No    
    S3‑172447 [eMCSEC] Five solutions on Interworking security for TR 33.880 NCSC pCR Approval Yes
Yes
 		revised No S3‑172529  
    S3‑172529 [eMCSEC] Five solutions on Interworking security for TR 33.880 NCSC pCR Approval Yes
Yes
 		approved No   S3‑172447
    S3‑172449 [eMCSEC] Update of Signalling Proxies solution (#1.5) for TR 33.880 NCSC pCR Approval Yes
Yes
 		approved No    
    S3‑172450 [eMCSEC] Evaluation of Signalling Proxies for TR 33.880 NCSC pCR Approval Yes
Yes
 		approved No    
    S3‑172454 [eMCSEC] Update to EAR solution in TR 33.880 NCSC pCR Approval No
Yes
 		withdrawn Yes    
    S3‑172542 Draft TR 33.880 NCSC draft TR Approval Yes
Yes
 		approved No    
    S3‑172543 LS to SA6 on the use of signalling proxies as a deployment option NCSC LS out Approval Yes
Yes
 		approved No    
5.2 New Study on security aspect of 5G Network Slicing Provisioning (FS_ NETSLICE-MGT_Sec) (Rel-15) S3‑172308 Draft skeleton proposal for TR33.811 Huawei, Hisilicon, China Mobile pCR Approval Yes
YesMCC commented that this was an old template, so the new draft should be built on the new template with the 5G logo. The structure was approved in any case.
 		approved No    
    S3‑172309 Adding references to TR 33.811 Huawei, Hisilicon, China Mobile pCR Approval Yes
YesORANGE commented that TR 33.899 was a draft that was stopped, never approved, and that the reference should go away. MCC commented that references should be added as needed, since it can be the case that they will never be used. The document was noted.
 		noted No    
    S3‑172310 Introduction section for TR33.811 Huawei, Hisilicon, China Mobile pCR Approval Yes
YesNokia: don’t refer to the SA2 TR and SA3 TR on 5G. Vodafone disagreed with the first paragraph. The introduction should set the scene and in here they are referring to what 3GPP groups did in the past. They proposed to note the document and avoid having an Introduction clause. BT and ORANGE agreed.
 		noted No    
    S3‑172311 A proposal for the scope of the TR33.811 Huawei, Hisilicon pCR Approval Yes
YesBT: it's not clear what we need to do this. ORANGE wasn't happy with the way the scope was written and proposed to go back to the study objectives and put it here.
 		revised No S3‑172549  
    S3‑172549 A proposal for the scope of the TR33.811 Huawei, Hisilicon pCR Approval Yes
Yes
 		approved No   S3‑172311
    S3‑172312 A key issue of interface security for TR33.811 Huawei, Hisilicon, CATR pCR Approval Yes
YesNokia: the requirements are not complete, add an edito's note about this. MCC: make sure that the clauses give "potential requirements" since this is a TR and be careful with using normative text throughout the document since it is informative in nature, not normative. ORANGE was concerned that this was not in line with the TS in SA5 and proposed to have it noted. Vodafone agreed. The key issue is not an issue and the key issue details are not correct. It needs a lot of work. BT supported this contribution. NTT-Docomo: we should take into account the finished SA5 TR as well, not only on the normative work that they are currently doing. ORANGE: the TS and TR in SA5 have different scopes. The study item is clear with having the SA5 TS as the object of the study. It was agreed to remove the requirements, since they were object of major concern for several companies.
 		revised No S3‑172550  
    S3‑172550 A key issue of interface security for TR33.811 Huawei, Hisilicon, CATR pCR Approval Yes
Yes
 		approved No   S3‑172312
    S3‑172313 A key issue on security capabilities for TR33.811 Huawei, Hisilicon pCR Approval Yes
YesVodafone: the key issue is not an issue. The threats under the security requirements don't match with the key issue details.This needs substantial work in the wording. It was decided to revise the document targeting the key issue details.
 		revised No S3‑172551  
    S3‑172551 A key issue on security capabilities for TR33.811 Huawei, Hisilicon pCR Approval No
Yes
 		noted No   S3‑172313
    S3‑172314 A key issue on security protection of messages exchanged with customers Huawei, Hisilicon pCR Approval Yes
YesVodafone: the key issue is not worded as key issue. And there are actually two key issues here, not one.
 		noted No    
    S3‑172315 A key issue on security isolation of network slices Huawei, Hisilicon pCR Approval Yes
YesNokia: Where is this security isolation coming from? Huawei: this is coming from TR 28.801. Nokia: there was no agreement on the security isolation in our TR 33.899. Vodafone: same as the others, the key issue details are wrong. The title should be"leakage of slice data beween slices", and then write the text accordingly.
 		noted No    
    S3‑172548 draft TR 33.811 Huawei draft TR Approval No
Yes
 		left for email approval No    
6 Review and Update of Work Plan S3‑172201 SA3 Work Plan MCC other   Yes
Yes
 		noted No    
7 Future Meeting Dates and Venues S3‑172202 SA3 meeting calendar MCC other   Yes
Yes
 		noted No    
8 Any Other Business