Tdoc List

2018-11-16 14: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‑183200 Agenda WG Chairman agenda   Yes
Yes
revised No S3‑183253  
    S3‑183253 Agenda WG Chairman agenda Approval Yes
Yes
approved No   S3‑183200
3 IPR and Anti-Trust Law Reminder                      
4 Meeting reports                      
4.1 Approval of the report from previous SA3 meeting(s) S3‑183201 Report from SA3#92 MCC report   Yes
Yes
approved No    
    S3‑183206 Report from SA3#92Ad-Hoc MCC report   Yes
Yes
approved No    
4.2 Report from SA Plenary S3‑183203 Report from last SA meeting WG Chairman report   Yes
YesORANGE queried about the GSMA LS on SoR (Steering of Roaming). Ericsson commented that they had some input prepared to be checked later in the meeting.
noted No    
4.3 Report from SA3-LI S3‑183634 TS 33 127 v110 BT plc draft TS Agreement Yes
YesBT commented that this revision was a correction on a wrongly implemented CR. It was brought to this meeting for approval. BT commented that this draft was sent for information and approval to the next SA plenary.
approved No   s3i180608
    S3‑183635 Cover sheet for presentation of TS 33.127 to SA Plenary SA3 (SA3-LI) TS or TR cover Agreement Yes
Yes
approved No   s3i180603
5 Items for early consideration                      
5.1 CRs from SA3#92bis S3‑183207 Intra-gNB-CU term synchronization Huawei, HiSilicon CR Approval Yes
Yes
agreed No    
    S3‑183208 Update RNA Update Procedure Security Huawei, HiSilicon CR Approval Yes
Yes
agreed No    
    S3‑183209 N2 HO: Handling source algorithms for RRC Reestablishment procedure Huawei, Hisilicon CR Approval Yes
Yes
agreed No    
    S3‑183210 Handling of UP security policy in MR-DC Huawei, Hisilicon, Qualcomm Incorporated, Ericsson CR Approval Yes
Yes
revised No S3‑183835  
    S3‑183835 Handling of UP security policy in MR-DC Huawei, Hisilicon, Qualcomm Incorporated, Ericsson CR Approval Yes
Yes
agreed No   S3‑183210
    S3‑183211 Delete EN in SBA Requirements Huawei, Hisilicon CR Approval Yes
Yes
agreed No    
    S3‑183212 Clarifications on AccessToken_Get Response message Huawei, Hisilicon CR Approval Yes
Yes
agreed No    
    S3‑183213 Editorial corrections on Authorization of NF service access Huawei, Hisilicon CR Approval Yes
Yes
agreed No    
    S3‑183214 Add discover procedure as a pre-requisite for obtaining access token Huawei, Hisilicon CR Approval Yes
Yes
agreed No    
    S3‑183215 correction on the mobility from 5G to 4G Huawei, Hisilicon CR Approval Yes
Yes
agreed No    
    S3‑183216 Clarification on handover from EPS to 5GS Huawei, Hisilicon CR Approval Yes
Yes
merged No S3‑183836  
    S3‑183217 Editorial corrections on the 5GS to EPS handover procedure Huawei, HiSilicon CR Approval Yes
Yes
agreed No    
    S3‑183218 Clarification for Target to Source container Huawei, HiSilicon CR Approval Yes
Yes
agreed No    
    S3‑183219 Multiple NAS connections: clarification on the action of MAC verification in registration request over non-3gpp access Huawei, HiSilicon CR Approval Yes
Yes
agreed No    
    S3‑183220 Interworking Ė correcting keying material in HO request message (EPS to 5GS) Ericsson CR Agreement Yes
Yes
revised No S3‑183836  
    S3‑183836 Interworking Ė correcting keying material in HO request message (EPS to 5GS) Ericsson,Huawei CR Agreement Yes
Yes
agreed No   S3‑183220
    S3‑183221 Length of IV salt and sequence counter Ericsson CR Agreement Yes
Yes
agreed No    
    S3‑183222 Correction to the Security Service for Steering of Roaming Ericsson CR Agreement Yes
Yes
agreed No    
    S3‑183223 Mobility Ė Clarification of downlink NAS COUNT in N2 handover Ericsson CR Agreement Yes
Yes
agreed No    
    S3‑183224 NAS key refresh Ericsson CR Agreement Yes
Yes
agreed No    
    S3‑183225 Caching access tokens Ericsson CR Agreement Yes
Yes
agreed No    
    S3‑183226 Addition of multiple instance IDs to OAuth2.0 access token claims Ericsson CR Agreement Yes
Yes
agreed No    
    S3‑183227 Corrections to references for security related service in clause 14 CATT CR Agreement Yes
Yes
agreed No    
    S3‑183228 Correction to Nudm_UEAuthentication_ResultConfirmation service CATT CR Agreement Yes
Yes
agreed No    
    S3‑183229 Correction to 5G AKA procedure Ė no need for "SUPI or SUCI" (in step 10) Orange, Ericsson, Nokia CR Approval Yes
Yes
agreed No    
    S3‑183233 Adjusting the description of the initial NAS protection method Qualcomm Incorporated, ZTE, China Mobile CR Agreement Yes
Yes
not pursued No    
    S3‑183234 Acknowledging possibility of early calculation of EMSK Qualcomm Incorporated, Huawei, Hsilicon CR Agreement Yes
Yes
agreed No    
    S3‑183235 Precedence of protection policies on the N32 interface Telekom Deutschland GmbH CR Approval Yes
Yes
agreed No    
    S3‑183236 Handling of encrypted IEs on the N32 interface Telekom Deutschland GmbH CR   Yes
Yes
agreed No    
    S3‑183237 Corrections and additions in definitions and related clauses Nokia, Nokia Shanghai Bell CR   Yes
Yes
agreed No   S3‑183072
    S3‑183238 Clarification to AUSF key derivation Nokia, Nokia Shanghai Bell CR   Yes
Yes
agreed No   S3‑183097
    S3‑183239 Clarification to support of authentication methods Nokia, Nokia Shanghai Bell CR   Yes
Yes
agreed No   S3‑183077
    S3‑183240 Adding reference to 33.501 in 33.102 Nokia, Nokia Shanghai Bell CR   Yes
Yes
agreed No   S3‑182957
    S3‑183241 Alignment regarding KEY reference to 33.220 Nokia, Nokia Shanghai Bell CR   Yes
Yes
agreed No   S3‑183098
    S3‑183242 Misleading text with reference regarding serving network name Nokia, Nokia Shanghai Bell CR   Yes
Yes
agreed No   S3‑183099
    S3‑183243 Clarification on first bits of EMSK Nokia, Nokia Shanghai Bell CR   Yes
Yes
agreed No   S3‑182960
    S3‑183244 Removing mandatory text from note Nokia, Nokia Shanghai Bell CR   Yes
Yes
agreed No   S3‑182967
    S3‑183245 Reference correction Nokia, Nokia Shanghai Bell CR   Yes
Yes
agreed No   S3‑182968
    S3‑183246 Remove EN in 13.2 Nokia, Nokia Shanghai Bell CR Approval Yes
Yes
agreed No    
    S3‑183247 Clarifications to clause 13.2.1 Nokia, Nokia Shanghai Bell CR Approval Yes
Yes
agreed No    
    S3‑183248 Remove EN in 13.2.2.1 Nokia, Nokia Shanghai Bell CR Approval Yes
Yes
agreed No    
    S3‑183249 Correction in step 2 of 13.2.2.2 Nokia, Nokia Shanghai Bell CR Approval Yes
Yes
agreed No    
    S3‑183250 Corrections in 13.2.2.4 on N32-f context ID Nokia, Nokia Shanghai Bell CR Approval Yes
Yes
agreed No    
    S3‑183251 Clarifications and corrections in clause 13.2.4 Nokia, Nokia Shanghai Bell CR Approval Yes
Yes
agreed No    
    S3‑183254 Multiple NAS Connection: Correcting NAS link identifier Nokia CR Approval Yes
Yes
agreed No    
    S3‑183255 CR to 33210 r15 adding references for the TLS Protocol Profiles clause Juniper Networks, Ericsson CR   Yes
Yes
agreed No    
    S3‑183256 CR to 33210 r16 adding Other 3GPP Profiles clause and references Juniper Networks, Ericsson CR   Yes
Yes
agreed No    
    S3‑183257 CR to 33310 r16 removing annex e Juniper Networks, Ericsson CR   Yes
Yes
agreed No    
5.2 Others                      
6 Reports and Liaisons from other Groups                      
6.1 3GPP Working Groups S3‑183276 LS to 3GPP TSG-SA WG6 on Use of ITS Dedicated Spectrum within V2X UE ETSI TC ITS LS in   Yes
YesNo action for SA3.
noted No    
    S3‑183653 3GPP SA3 statement SA3 WG vice chair (NTT-Docomo) other Information Yes
Yes
endorsed No    
    S3‑183706 LS on IAB security R2-1818748 LS in Discussion Yes
YesIt was pointed out that this could have security implications that would need further study in SA3, hence the answers would be very short. Huawei commented that the answer was not trivial and more time was needed. Nokia was in line with this.Huawei pointed out that this was Rel-16 and there was no hurry. AT&T preferred to reply to RAN2 in the short deadline given by them. The Chair proposed to answer with a disclaimer given that SA3 was not aware of the full picture, just a preliminary reply. This was what Ericsson had in mind. Qualcomm agreed with this reply. Huawei: we donít have a deadline in the LS. This can be seen for the next meeting. Nokia supported this. It was agreed to propose a draft that could be discussed. BT: the intention of RAN2 was to have a response for this week. The Chair confirmed that he was personaly contacted to have a reply for the meeting week. Qualcomm commented that RAN2 needed SA3's response to conclude their study and even a preliminary response would be useful for them. Juniper: they should design a protocol that doesnít depend on our schoosing.
replied to No    
    S3‑183711 Reply to: LS on IAB security Ericsson LS out approval Yes
Yes
approved No    
6.2 IETF                      
6.3 ETSI SAGE                      
6.4 GSMA                      
6.5 OMA                      
6.6 TCG                      
6.7 oneM2M                      
6.8 TC-CYBER                      
6.9 ETSI NFV                      
6.10 Other Groups S3‑183277 LS on Joint ETSI - OSA Workshop: Open Implementations & Standardization ETSI LS in   Yes
YesAlex (BT) commented that this clashed with SA plenary. It was commented that SA3 could make a contribution about SA3 security.
noted No    
    S3‑183286 LS on SG17 work item X.5Gsec-q: Security guidelines for applying quantum-safe algorithms in 5G systems ITU-T SG17 LS in   Yes
Yes
replied to No    
    S3‑183482 LS_to_LS on SG17 work item X 5Gsec-q China Mobile LS out   Yes
Yes
noted No    
    S3‑183793 Reply-LS on work item "X.5Gsec-q" ETSI TC Cyber WG QSC LS in discussion Yes
Yes
noted No    
    S3‑183794 Liaison Statement to ITU-T SG17: Response to proposal for ITU-T SG17 question on quantum-safe communication ETSI TC Cyber WG QSC LS in discussion Yes
Yes
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‑183554 Correction to Key hierarchy diagram Samsung CR   Yes
Yes
revised No S3‑183678  
    S3‑183678 Correction to Key hierarchy diagram Samsung CR - Yes
YesRevised to make the figure bigger.
agreed No   S3‑183554
7.1.2 Key derivation S3‑183504 Alignment on KEY Nokia, Nokia Shanghai Bell CR Agreement Yes
Yes
agreed No    
    S3‑183556 Corrections to KSEAF derivation in Key distribution and derivation Samsung CR Approval Yes
Yes
agreed No    
7.1.3 Mobility S3‑183345 Clarification on how AMF confirm UE SUPI Huawei, Hisilicon CR Approval Yes
YesEricsson: some incorrect statements in the note. Nokia: this is not needed. Huawei: without this, external people to SA3 will not understand the procedure. Docomo supported the fact that this was not needed.
not pursued No    
7.1.4 AS security S3‑183318 AS subscription temperary identifier privacy ZTE Corporation CR Approval Yes
YesNokia: 5.3.X should be in a RAN spec. Ericsson: this new clause is not needed. It was agreed to remove the new clause from the CR and reword the statement on the gNB in the second change (since it wasnít clear to which gNB it was referring).
revised No S3‑183663  
    S3‑183663 AS subscription temperary identifier privacy ZTE Corporation CR Approval Yes
Yes
agreed No   S3‑183318
    S3‑183408 Discussion on Support AS Security Algorithms Negotiation during INACTIVE transition and RRC Reestablishment in R15 Huawei, Hisilicon discussion Discussion Yes
YesVodafone: the conclusion of the study is to do nothing for four years (potentially the next generation after 5G). NCSC: observations 1 and 2 should actually be included in the study.
noted No    
    S3‑183342 Update RRC reestablishment security procedure based on RAN2 agreement Huawei, Hisilicon CR Approval Yes
YesEricsson, Qualcomm: it is too late to introduce this feature now.
revised No S3‑183664  
    S3‑183664 Update RRC reestablishment security procedure based on RAN2 agreement Huawei, Hisilicon CR Approval Yes
Yes
agreed No   S3‑183342
    S3‑183621 Clarification on RRC Inactive procedure support by ng-eNB Qualcomm Incorporated CR Agreement Yes
Yes
revised No S3‑183665  
    S3‑183665 Clarification on RRC Inactive procedure support by ng-eNB Qualcomm Incorporated CR Agreement Yes
Yes
agreed No   S3‑183621
    S3‑183407 CR-to-TS33501-RRC Reestablishment security handling when N2 Handover happens Huawei, Hisilicon CR Approval Yes
YesQualcomm: it impacts ASN.1 and it's too late for this. Ericsson: too late for this, it's more about optimization than a security issue. Docomo commented that this could go to Rel-16. The Chair commented that this should be brought back in Rel-16. This was agreed.
not pursued No    
    S3‑183322 Proposal about improvement of the UP security policy China Mobile CR Approval Yes
YesEricsson didnít agree with the wording. Docomo was OK with having a default behaviour described here, by rewording the changes. This was taken offline.
revised No S3‑183666  
    S3‑183666 Proposal about improvement of the UP security policy China Mobile CR Approval Yes
Yes
agreed No   S3‑183322
    S3‑183586 Support of UP security policy in ng-eNB Ericsson draftCR Approval Yes
YesContent goes into the CR in 586 unchanged.
approved No    
    S3‑183667 Support of UP security policy in ng-eNB Ericsson CR Approval Yes
Yes
agreed No    
    S3‑183344 Adding UP security policy in SN Addition/modification Request message Huawei, Hisilicon CR Approval Yes
Yes
revised No S3‑183740  
    S3‑183740 Adding UP security policy in SN Addition/modification Request message Huawei, Hisilicon CR Approval Yes
Yes
agreed No   S3‑183344
    S3‑183361 UP IP handling for split PDU session in MR-DC scenarios Huawei, Hisilicon CR Approval Yes
YesEricsson: UP security policy should be the same and this CRs allows to have different UP security policies. Intel: No difference between eNodeB and gNoeb termination points. Nokia: expanding this feature in Rel-15 does not make sense. Huawei: we are not proposing having different UP security policies in the same PDU session. It is the same for the PDU session. Ericsson: all bearers terminated in the same node should have the same secirity policy; the problem lies in the split.
not pursued No    
    S3‑183362 Adding NR-DC to the scenarios of MR-DC Huawei, Hisilicon CR Approval Yes
YesEricsson didnít agree with the changes.
revised No S3‑183668  
    S3‑183668 Adding NR-DC to the scenarios of MR-DC Huawei, Hisilicon,Qualcomm,Ericsson CR Approval Yes
Yes
merged No S3‑183835 S3‑183362
    S3‑183606 Draft CR to S3-183210 (Handling of UP security policy in MR-DC) Ericsson draftCR Agreement Yes
YesQualcom disagreed. Not in line with what SA3 has agreed before. Huawei supported this CR. Nokia commented that this would introduce unnecessary complexity.Qualcomm agreed, this could be potentially a problem. Ericsson replied that RAN could be consulted on the supposed complexity of this.
merged No S3‑183668  
    S3‑183669 Draft CR to S3-183210 (Handling of UP security policy in MR-DC) Ericsson draftCR Agreement No
Yes
withdrawn Yes    
    S3‑183622 NR-NR Dual Connectivity Qualcomm Incorporated CR Agreement Yes
YesEricsson commented that the used baseline was incorrect since the content in 6.10.4 was different from what appeared here. Huawei agreed.
merged No S3‑183668  
    S3‑183437 Reply LS on security requirements for Integrity protection for DRBs in MR-DC Huawei, Hisilicon LS out   Yes
Yes
revised No S3‑183660  
    S3‑183660 Reply LS on security requirements for Integrity protection for DRBs in MR-DC Huawei, Hisilicon LS out - Yes
Yes
approved No   S3‑183437
    S3‑183317 Editorial modification on gNB requirement ZTE Corporation CR Approval Yes
Yes
agreed No    
    S3‑183602 Discussion on the applicability of gNB requirements to ng-eNB Ericsson discussion Discussion Yes
Yes
noted No    
    S3‑183644 NG-RAN Ė clause 6.9.2.2 Ericsson CR Agreement Yes
YesIt was commented that it should be "NG-RAN node" instead of "NG-RAN". Nokia didn't agree with the new term KNG-RAN. This was confusing. Ericsson replied that this was defined in the SA3 spec already.
revised No S3‑183670 S3‑183603
    S3‑183670 NG-RAN Ė clause 6.9.2.2 Ericsson CR Agreement No
Yes
agreed No   S3‑183644
    S3‑183645 NG-RAN Ė clause 6.9.2.3.3 Ericsson CR Agreement Yes
Yes
revised No S3‑183671 S3‑183604
    S3‑183671 NG-RAN Ė clause 6.9.2.3.3 Ericsson CR Agreement Yes
Yes
agreed No   S3‑183645
    S3‑183646 NG-RAN Ė clause 6.9.2.3.4 Ericsson CR Agreement Yes
Yes
revised No S3‑183672 S3‑183605
    S3‑183672 NG-RAN Ė clause 6.9.2.3.4 Ericsson CR Agreement Yes
Yes
agreed No   S3‑183646
    S3‑183603 NG-RAN Ė clause 6.9.2.2 Ericsson CR Agreement Yes
Yes
revised No S3‑183644  
    S3‑183604 NG-RAN Ė clause 6.9.2.3.3 Ericsson CR Agreement Yes
Yes
revised No S3‑183645  
    S3‑183605 NG-RAN Ė clause 6.9.2.3.4 Ericsson CR Agreement Yes
Yes
revised No S3‑183646  
    S3‑183587 E-UTRA connected to 5GC Ericsson draftCR Approval No
Yes
withdrawn Yes    
7.1.5 NAS security S3‑183313 Modification of initial NAS message protection ZTE Corporation CR Approval Yes
Yes
merged No S3‑183673  
    S3‑183314 Modification on NAS SMC procedure ZTE Corporation CR Approval Yes
Yes
merged No S3‑183673  
    S3‑183315 Handling of initial NAS message other than RR when failure occur ZTE Corporation CR Approval Yes
YesEricsson: not clear if this is needed.
not pursued No    
    S3‑183588 Handling of initial NAS protection failures Ericsson draftCR Approval Yes
Yes
noted No    
    S3‑183589 Way forward on how to address mobility cases for the initial NAS protection mechanism Ericsson discussion Endorsement Yes
YesEricsson pointed out that relying on the CT1 solution is not very optimised.
noted No    
    S3‑183590 Handling of mobility scenarios involving an AMF key change for the initial NAS protection mechanism Ericsson draftCR Approval Yes
Yes
noted No    
    S3‑183591 Handling of mobility scenarios involving an AMF key change for the initial NAS protection mechanism Ericsson draftCR Approval Yes
Yes
noted No    
    S3‑183609 Discussion on the CT1 LS on initial NAS security Qualcomm Incorporated discussion Endorsement Yes
Yes
noted No    
    S3‑183610 Adjusting the description of the initial NAS protection method Qualcomm Incorporated draftCR Agreement Yes
YesContents will be merged into 673 since this is a draftCR.
noted No    
    S3‑183673 Aligning the description of the initial NAS security procedures based on the CT1 agreements Qualcomm Incorporated,ZTE CR Agreement Yes
Yes
agreed No    
    S3‑183611 LS on initial NAS message protection Qualcomm Incorporated LS out Approval Yes
YesVodafone: who makes the decision on what goes on clear and what doesnít? Qualcomm replied that it will be up to SA3.
revised No S3‑183741  
    S3‑183741 LS on initial NAS message protection Qualcomm Incorporated LS out Approval Yes
Yes
approved No   S3‑183611
    S3‑183374 Initial NAS Discussion on privacy solutions Intel Corporation (UK) Ltd discussion Endorsement Yes
Yes
noted No    
    S3‑183642 Comments on S3-183374 Nokia, Nokia Shanghai Bell discussion Approval Yes
YesEricsson: we should point out the implications for our preferences. Trust on the VPLMN was widely discussed in the group. Docomo didnít see this as a big issue. Verizon preferred the solution in 565. Vodafone didnít want visited networks breaking the level of security that the Home Network had decided. Ericsson wanted to highlight the security aspects in order to reveal the slices that are privacy sensitive. We cannot say that both solutions have the same level of security since one exposes more information than the other. Alex (BT): we need to accept that the VPLMN will have some control on this. It was agreed to write down the results of the discussions on the LS in 659.
noted No    
    S3‑183316 Editorial modification on initial NAS message protection ZTE Corporation CR Approval Yes
Yes
merged No S3‑183673  
    S3‑183612 Discussion on the SA2 LS on initial NAS security Qualcomm Incorporated discussion Endorsement Yes
Yes
noted No    
    S3‑183613 LS on initial NAS message protection Qualcomm Incorporated LS out Approval Yes
Yes
noted No    
    S3‑183614 Network control of sending S-NSSAIs in the RRC signalling Qualcomm Incorporated CR Agreement Yes
Yes
not pursued No    
    S3‑183550 Discussion on the Reply LSs on initial NAS security agreements Samsung discussion Endorsement Yes
Yes
noted No    
    S3‑183641 Comments on S3-183550 NSSAI inclusion in NAS Nokia, Nokia Shangahi bell other Approval Yes
YesSamsung: the attack is difficult but still feasible. NCSC didnít see this attack as feasible.
noted No    
    S3‑183325 Discussion on i/c LS S2-1811543 NSSAI in RRC message Nokia, AT&T, Verizon Wireless, Inter Digital discussion Endorsement Yes
Yes
noted No    
    S3‑183326 draft-LS out reply to i/c LS on NSSAI in RRC message Nokia other Approval Yes
Yes
noted No    
    S3‑183584 Multiple NAS connections and algorithm change Ericsson draftCR Approval Yes
YesQualcomm: Very restrictive behaviour in the UE and it is also introducing a new requirement on the UE that will make it unnecessarily complex.
noted No    
    S3‑183585 Multiple NAS connecions: mobility with horizontal KAMF derivation Ericsson draftCR Approval Yes
Yes
noted No    
    S3‑183615 Discussion on CT1 on Scenarios with multiple registrations to the same AMF Qualcomm Incorporated discussion Endorsement Yes
Yes
noted No    
    S3‑183616 Addressing possible security context mismatch on non-3GPP acces when multiply registered on one PLMN Qualcomm Incorporated CR Agreement Yes
Yes
not pursued No    
    S3‑183601 Handling of NAS COUNTs Ericsson CR Agreement Yes
Yes
revised No S3‑183674  
    S3‑183674 Handling of NAS COUNTs Ericsson CR Agreement Yes
Yes
agreed No   S3‑183601
    S3‑183328 Clarify SUPI format in KAMF computation Nokia CR Approval Yes
YesEricsson: this is stage 3 information; is it in our scope? Nokia confirmed this. Qualcomm had some issues with this so it had to be taken offline. They also commented that some alingment might be needed with CT4.
revised No S3‑183675  
    S3‑183675 Clarify SUPI format in KAMF computation Nokia CR Approval No
Yes
agreed No   S3‑183328
    S3‑183360 Clarification: AMF confirming UE SUPI in case NAS SMC failed Huawei, Hisilicon CR Approval Yes
YesNokia wanted to have some clarifications and a reference to the requirement needed to be added.
revised No S3‑183676  
    S3‑183676 Clarification: AMF confirming UE SUPI in case NAS SMC failed Huawei, Hisilicon,Nokia CR Approval Yes
Yes
agreed No   S3‑183360
    S3‑183624 Security mechanism for UE Parameters Update via UDM Control Plane Procedure Qualcomm Incorporated CR Agreement Yes
YesVodafone: strong objection to having this in Rel-15. Vodafone asked to have minuted: Updating routing id over the air is a very poor procedure. Their objection was sustained. Qualcomm: this is a SA2 related CR and it's a Plenary discussion. IDEMIA: is this essential for Rel-15? Ericsson: it's the security solution for a SA2 CR. ORANGE: this is cat-B, not F. The Chair asked the companies to start focusing on Rel-16 instead of keep bringing input for Rel-15.
revised No S3‑183742  
    S3‑183742 Security mechanism for UE Parameters Update via UDM Control Plane Procedure Qualcomm Incorporated,Huawei CR Agreement Yes
YesVodafone withdrew their sustained objection after a note was added in 6.Y.1. They asked to be minuted that they were not satisfied with having this CR for Rel-15 and that they may raise this concern in the next SA Plenary.
agreed No   S3‑183624
    S3‑183636 Comments on S3-183624 NEC Corporation other Agreement Yes
YesVodafone: we deal with this in the previous meeting, no point in going through this again. Provisioning is ut of scope of 3GPP.
noted No    
    S3‑183472 Discussion on UE Parameters Update via UDM Control Plane Procedure Huawei, Hisilicon discussion Endorsement Yes
Yes
noted No    
    S3‑183474 Solution for UE Parameters Update via UDM Control Plane Procedure Huawei, Hisilicon CR Agreement Yes
YesVodafone: This is not aligned with a decision taken in SA2 since they haven't agreed in anything based on the LS that we sent during the last meeting. There are also a lot of points here that are out of scope of 3GPP. ORANGE: SA2 hasnít answered our LS so we shouldn't waste on figuring out a solution. Docomo was more interested in the integrity protection of the ME back channel going to the Home Network. NEC: we cannot ignore that SA2 will go forward in two weeks when they have their meeting. Vodafone insisted that SA3 could not procceed without a response from SA2. Nokia: SA2 has discussed this and agreed on solutions and they are available for us, although we havenít received a response.
merged No S3‑183742  
    S3‑183329 Editorial correction in Clause 6.9.3.2 Nokia CR Approval Yes
YesIt was commented that removing the "H" from the parameter name was not possible since this was used by CT4 and mentioned in other parts of the SA3 spec.
revised No S3‑183677  
    S3‑183677 Editorial correction in Clause 6.9.3.2 Nokia CR Approval Yes
Yes
agreed No   S3‑183329
    S3‑183402 Editorial corrections on NAS SMC procedure Huawei, Hisilicon CR Approval Yes
Yes
agreed No    
7.1.6 Security context                      
7.1.7 Visibility and Configurability                      
7.1.8 Primary authentication S3‑183501 Clarification to the transfer of authentication success result to the UDM Nokia, Nokia Shanghai Bell CR Agreement Yes
Yes
agreed No    
    S3‑183503 Correction of formatting error Nokia, Nokia Shanghai Bell CR Agreement Yes
YesDocomo commented that there was a reason for having the formatting; it was done to point out that the paragraph was independent.
not pursued No    
    S3‑183594 Update of EAP-AKAí reference to make it compatible with 5G Ericsson draftCR Agreement Yes
YesMCC had issues with referencing documents that donít exist ("future updates" or versions that will superced the current one). Ericsson commented that the current version does not work with 5G. NCSC also had issues with this. Huawei proposed to add an editor's note stating that the draft could not referenced until it was formally approved in IETF. Agreed content goes to 679.
noted No    
    S3‑183679 Update of EAP-AKAí reference to make it compatible with 5G Ericsson CR Agreement Yes
Yes
agreed No    
    S3‑183595 Update of EAP-AKAí RFC 5448 in progress Ericsson discussion Discussion Yes
Yes
noted No    
7.1.9 Secondary authentication S3‑183467 CR on Secondary Re-authentication Huawei, HiSilicon CR Agreement Yes
Yes
revised No S3‑183661  
    S3‑183661 CR on Secondary Re-authentication Huawei, HiSilicon CR Agreement Yes
YesRewording proposed by Nokia.
agreed No   S3‑183467
7.1.10 Interworking S3‑183400 correction on handover procedure from 5G to 4G Huawei, Hisilicon CR Approval Yes
Yes
agreed No    
    S3‑183476 Clarification on interworking Huawei, Hisilicon CR Agreement Yes
YesQualcomm didnít agree with some of the changes. This was revised to that effect.
revised No S3‑183680  
    S3‑183680 Clarification on interworking Huawei, Hisilicon CR Agreement Yes
Yes
agreed No   S3‑183476
    S3‑183618 Corrections on the number of bits of downlink NAS COUNT value to be delivered in the 5GS to EPS handover procedure Qualcomm Incorporated CR Agreement Yes
Yes
agreed No    
    S3‑183619 Clarification on storing the selected EPS NAS algorithms Qualcomm Incorporated CR Agreement Yes
Yes
agreed No    
    S3‑183620 KgNB derivation in EPS to 5GS handover Qualcomm Incorporated draftCR Approval Yes
YesEricsson: not sure that we need these changes. There was no issue with the KgNb. This had to be taken offline.
noted No    
    S3‑183797 KgNB derivation in EPS to 5GS handover Qualcomm Incorporated CR Approval Yes
Yes
agreed No    
    S3‑183623 KgNB derivation in N2 handover Qualcomm Incorporated CR Agreement Yes
Yes
agreed No    
    S3‑183643 Discussion on the changes proposed in S3-183620 and S3-183623 Qualcomm Incorporated discussion   Yes
Yes
noted No    
7.1.11 non-3GPP access                      
7.1.12 NDS S3‑183230 Adding references for the TLS Protocol Profiles clause Juniper Networks, Ericsson CR   No
Yes
withdrawn Yes    
    S3‑183231 Update NDS/IP scope with application layer crypto profiles Juniper Networks, Ericsson CR   No
Yes
withdrawn Yes    
    S3‑183232 Move TLS crypto profiles to TS 33.210 Juniper Networks, Ericsson CR   No
Yes
withdrawn Yes    
    S3‑183381 Corrections to 9. Security procedures for non-service based interfaces LG Electronics CR Agreement Yes
Yes
agreed No    
7.1.13 Service based architecture                      
7.1.13.1 Interconnect (SEPP related) S3‑183647 NF-SEPP TLS handling Ericsson Hungary Ltd draftCR Approval Yes
Yes
noted No   S3‑183566
    S3‑183441 Telescopic FQDN creation within the SEPP Telekom Deutschland GmbH, Nokia CR Approval Yes
Yes
not pursued No    
    S3‑183546 Issue with using wildcard certificates in SEPP Nokia, Nokia Shanghai Bell discussion Agreement Yes
Yes
noted No    
    S3‑183633 Resolution of Editorís note on wildcard certificates in S3-183441 Nokia, Nokia Shanghai Bell, Telekom Deutschland GmbH CR Agreement Yes
Yes
not pursued No    
    S3‑183638 Scenarios that require generation of telescopic FQDN in SEPP Nokia, Nokia Shanghai Bell CR Agreement Yes
Yes
not pursued No    
    S3‑183548 Telescopic FQDN for callback URIs Nokia, Nokia Shanghai Bell discussion Agreement Yes
Yes
noted No    
    S3‑183468 Discussion on verification of PLMN ID in N32 message Huawei, Hisilicon discussion Endorsement Yes
YesVodafone didnít agree with concern one. SA3 provides the tools to GSMA to implement the roaming agreements. The split of work between SA3 and GSMA is correct. They didnít agree on concern 3 either. Ericsson commented that the most important point was that SEPP should check whether the PLMNid was fake. Vodafone didnít object to this, but they wanted tools to prevent roaming agreements giving away information, come up wit some specific rules to avoid this. DT commented that the SEPP could enforce some checks and the details could be figured out offline. Ericsson, NEC: let us not put all the rules in our documents as this would be a great amount of work. We provide the tools but not the rules. Juniper supported this as well. NTT-Docomo: PLMNid should be available and the rules are implementation specific. An offline session was needed in order to come out with a joint agreement in a CR.
noted No    
    S3‑183639 Verification of PLMN ID in N32 message Huawei, Hisilicon CR Agreement Yes
Yes
not pursued No   S3‑183469
    S3‑183443 Verification of the PLMN-ID by the receiving SEPP Telekom Deutschland GmbH, Nokia CR Approval Yes
Yes
not pursued No    
    S3‑183442 Corrections to N32 Protection Policies Telekom Deutschland GmbH, Nokia CR Approval Yes
Yes
revised No S3‑183684  
    S3‑183684 Corrections to N32 Protection Policies Telekom Deutschland GmbH, Nokia CR Approval Yes
Yes
agreed No   S3‑183442
    S3‑183522 N32: remove redundant references to encrypted IEs Ericsson CR Agreement Yes
Yes
revised No S3‑183685  
    S3‑183685 N32: remove redundant references to encrypted IEs Ericsson CR Agreement Yes
Yes
agreed No   S3‑183522
    S3‑183480 CR to TS 33.501 regarding N32-f key hierarchy China Mobile CR   Yes
Yes
agreed No    
    S3‑183547 Security between SEPP and IPX Nokia, Nokia Shanghai Bell, Telekom Deutschland GmbH CR Approval Yes
YesNEC: Say "should use" instead of "SA3 strongly recommends".
revised No S3‑183686  
    S3‑183686 Security between SEPP and IPX Nokia, Nokia Shanghai Bell, Telekom Deutschland GmbH CR Approval Yes
Yes
agreed No   S3‑183547
    S3‑183549 Two parallel N32-c connections between SEPPs Nokia, Nokia Shanghai Bell CR Approval Yes
Yes
revised No S3‑183687  
    S3‑183687 Two parallel N32-c connections between SEPPs Nokia, Nokia Shanghai Bell CR Approval Yes
Yes
agreed No   S3‑183549
    S3‑183469 Verification of PLMN ID in N32 message Huawei, Hisilicon CR Agreement Yes
Yes
revised No S3‑183639  
    S3‑183648 Draft CR Corrections to N32 Protection Policies Telekom Deutschland draftCR Approval Yes
Yes
noted No    
    S3‑183649 Draft CR Adopting more normative language in clause 13 Telekom Deutschland draftCR discussion Yes
YesEricsson: you are going too far beyond the descriptive language in some points. Some other companies had also comments on other instances of the text so this was taken offline. Agreements are taken in S3-183688.
noted No    
    S3‑183655 Two parallel N32-c connections between SEPPs Nokia draftCR discussion Yes
YesAgreed content goes into S3-183687.
noted No    
    S3‑183656 Security between SEPP and IPX Nokia draftCR discussion Yes
YesAgreed content goes into 686.
noted No    
    S3‑183657 Editorial corrections in 13.2 Nokia draftCR discussion Yes
YesAgreed content is included in S3-183689.
noted No    
    S3‑183681 Inter PLMN routing Nokia discussion Discussion No
Yes
withdrawn Yes    
    S3‑183682 Inter PLMN routing Nokia CR Agreement Yes
Yes
agreed No    
    S3‑183683 Verification of PLMNid by the receiving SEPP Deutsche Telekom CR Agreement Yes
Yes
agreed No    
    S3‑183789 LS on verification of PLMN-ID in the SEPP Deutsche Telekom LS out Approval Yes
Yes
approved No    
7.1.13.2 Other S3‑183478 Update on access token in roaming scenario Huawei, Hisilicon CR Agreement Yes
Yes
revised No S3‑183743  
    S3‑183743 Update on access token in roaming scenario Huawei, Hisilicon CR Agreement Yes
Yes
agreed No   S3‑183478
    S3‑183479 Remove the shared secret based token protection mechanism from the token related procedure Huawei, Hisilicon CR Agreement Yes
YesChina Mobile objected to this contribution. Nokia was in favour of not changing it either, maybe leave it as an implementation issue.
not pursued No    
    S3‑183523 pSEPP-pNF authentication Ericsson CR Agreement Yes
Yes
agreed No    
    S3‑183444 Adopting more normative language in clause 13 Telekom Deutschland GmbH, Nokia CR Approval Yes
Yes
revised No S3‑183688  
    S3‑183688 Adopting more normative language in clause 13 Telekom Deutschland GmbH, Nokia CR Approval Yes
Yes
agreed No   S3‑183444
    S3‑183422 Editorial corrections on Application layer security on the N32 interface Huawei, Hisilicon CR Approval Yes
YesNokia: it overaps with some other contributions.
merged No S3‑183689  
    S3‑183499 Shift of text from SEPP intro to subclause Nokia, Nokia Shanghai Bell CR Agreement Yes
YesEricsson: the new clause should be an introduction of 13.2 and not the whole clause 13.
revised No S3‑183690  
    S3‑183690 Shift of text from SEPP intro to subclause Nokia, Nokia Shanghai Bell CR Agreement Yes
Yes
agreed No   S3‑183499
    S3‑183540 Editorial corrections in 13.2 Nokia, Nokia Shanghai Bell CR Agreement Yes
Yes
revised No S3‑183689  
    S3‑183689 Editorial corrections in 13.2 Nokia, Nokia Shanghai Bell,Huawei CR Agreement Yes
Yes
agreed No   S3‑183540
    S3‑183566 NF-SEPP TLS handling Ericsson India Private Limited CR Agreement Yes
Yes
revised No S3‑183647  
    S3‑183382 IP protection for SN terminated bearers Intel Corporation (UK) Ltd CR   Yes
YesUsed baseline was wrong.
not pursued No    
    S3‑183708 Minutes of SBA Offline Discussion Deutsche Telekom report discussion No
Yes
withdrawn Yes    
7.1.14 Privacy S3‑183628 Clarifications to SUPI and SUCI Qualcomm Incorporated draftCR Approval Yes
YesIDEMIA commented that SUPI type was needed since there were two types. Qualcomm: SUPI type is not needed since in here it is always the IMSI. Some offline discussion on whether the SUPI type was needed or not. This was noted and the agreed content made into a CR.
noted No    
    S3‑183525 Maximum output size of SUPI concealment schemes Ericsson discussion Endorsement Yes
Yes
noted No    
    S3‑183524 Maximum output size of SUPI concealment scheme Ericsson draftCR Approval Yes
YesThere were some concerns on mandating the 3000 octets so this had to be taken offline. Vodafone: I donít want issues when a legacy USIM is in a new UE. Agreed content goes to 692.
noted No    
    S3‑183692 Maximum output size of SUPI concealment scheme Ericsson CR Approval Yes
Yes
agreed No    
    S3‑183500 Clarification to protection scheme identifier Nokia, Nokia Shanghai Bell CR Agreement Yes
Yes
revised No S3‑183693  
    S3‑183693 Clarification to protection scheme identifier Nokia, Nokia Shanghai Bell CR Agreement Yes
Yes
agreed No   S3‑183500
    S3‑183502 Intro of subclauses to clause 6.12.2 Nokia, Nokia Shanghai Bell CR Agreement Yes
YesORANGE commented that the last title should not be about guidance since it was normative. IDEMIA and Qualcomm didnít find this useful so it was not pursued.
not pursued No    
    S3‑183505 Alignment on Home Network Public Key Nokia, Nokia Shanghai Bell CR Agreement Yes
YesMCC commented that the clauses in the changes should follow the order in the specification (6.2.2 at the end was wrong).
revised No S3‑183694  
    S3‑183694 Alignment on Home Network Public Key Nokia, Nokia Shanghai Bell CR Agreement Yes
Yes
agreed No   S3‑183505
    S3‑183625 Clarifications to SUPI and SUCI Qualcomm Incorporated CR Agreement No
Yes
withdrawn Yes    
    S3‑183790 Clarifications to SUPI and SUCI Qualcomm,Nokia CR Agreement Yes
YesNokia commented some points of confusion coming from their CT4 colleagues.
agreed No    
7.1.15 Incoming and outgoing Lses S3‑183264 Reply LS on maximum output size of SUPI concealment schemes C1-186992 LS in   Yes
Yes
replied to No    
    S3‑183265 LS on Scenarios with multiple registrations to the same AMF C1-186993 LS in   Yes
YesThis information has been taken into account in other documents.
noted No    
    S3‑183266 Reply LS on inclusion of selected PLMN into the complete message C1-186994 LS in   Yes
Yes
noted No    
    S3‑183267 Reply LS on initial NAS security agreements R2-1816022 LS in   Yes
Yes
noted No    
    S3‑183268 LS on initial NAS message protection C1-186995 LS in   Yes
Yes
replied to No    
    S3‑183272 LS on N32 error signalling C4-187145 LS in   Yes
Yes
noted No    
    S3‑183273 Reply LS on Maximum output size of SUPI concealment schemes C4-187633 LS in   Yes
Yes
replied to No    
    S3‑183281 LS on security requirements for Integrity protection for DRBs in MR-DC R2-1816054 LS in   Yes
Yes
replied to No    
    S3‑183283 Reply LS on Secondary Re-Authentication S2-1811431 LS in   Yes
Yes
noted No    
    S3‑183284 Reply LS on Clarifications on SUPI definition and NAI format S2-1811525 LS in   Yes
Yes
replied to No    
    S3‑183662 Reply to: Reply LS on Clarifications on SUPI definition and NAI format Qualcomm LS out approval Yes
Yes
approved No    
    S3‑183287 Reply LS on initial NAS security agreements S2-1811568 LS in   Yes
Yes
approved No    
    S3‑183659 Reply to:LS on initial NAS security agreements Intel LS out approval Yes
Yes
approved No    
    S3‑183295 Draft Reply LS to ITU-T SG17 on X.5Gsec-q study NCSC LS out Approval Yes
YesVodafone preferred this LS to the option presented by China Mobile. The Chair commented that it was agreed in the previous SA3 meeting that a response LS was needed to tell ITU-T that there was an overlap and this needed to be avoided.
revised No S3‑183654  
    S3‑183654 Reply LS to ITU-T SG17 on X.5Gsec-q study NCSC LS out Approval No
Yes
approved No   S3‑183295
    S3‑183363 Reply LS on security requirements for Integrity protection for DRBs in MR-DC Huawei, Hisilicon CR Approval No
Yes
withdrawn Yes    
    S3‑183375 draft reply LS on security requirements for RRC connection release Intel Corporation (UK) Ltd LS out   Yes
YesBT: does this apply to emergency calls? They are an exception. Ericsson: we donít need the LS since we agree with their LS and there is no action.
noted No    
    S3‑183466 Discussion on LS from SA2 on 2nd Authentication Huawei, HiSilicon discussion Endorsement Yes
Yes
noted No    
    S3‑183658 Response LS on maximum output size of SUPI concealment schemes Ericsson LS out Approval Yes
Yes
approved No    
    S3‑183830 Assigning additional FC values to TS 33.501 Qualcomm CR Agreement Yes
Yes
agreed No    
7.1.16 Others S3‑183298 Corrections to definition of 5G NAS security context CMCC CR Approval No
Yes
revised No S3‑183303, S3‑183304  
    S3‑183302 Discussion on one potential way to improve the efficiency of IP Apple Computer Trading Co. Ltd discussion Discussion Yes
Yes
revised No S3‑183632  
    S3‑183303 Unify the name of RAN network in 33.501 CMCC CR Approval No
Yes
revised No S3‑183324 S3‑183298
    S3‑183304 Replace 5G-RAN with NG-RAN in 33.501 China Mobile CR Approval No
Yes
withdrawn Yes   S3‑183298
    S3‑183323 Corrections to definition of 5G AS security context for 3GPP access China Mobile CR Approval Yes
Yes
revised No S3‑183695  
    S3‑183695 Corrections to definition of 5G AS security context for 3GPP access China Mobile CR Approval Yes
Yes
agreed No   S3‑183323
    S3‑183324 Replace 5G-RAN with NG-RAN in TS 33.501 China Mobile CR Approval Yes
YesNokia didn't agree with this. Ericsson: there is no 5G RAN term. We should change this.
agreed No   S3‑183303
    S3‑183379 Corrections to 5.2 Requirements on the UE LG Electronics CR Agreement Yes
Yes
agreed No    
    S3‑183380 Corrections to 5.3 Requirements on the gNB LG Electronics CR Agreement Yes
Yes
agreed No    
    S3‑183401 Editorial corrections on the UP integrity mechanisms Huawei, Hisilicon CR Approval Yes
Yes
agreed No    
    S3‑183438 CR to TS33.501-Registration related text correction CATT CR Agreement Yes
YesThis had to be checked offline as petitioned by Ericsson.
revised No S3‑183738  
    S3‑183738 CR to TS33.501-Registration related text correction CATT CR Agreement Yes
Yes
agreed No   S3‑183438
    S3‑183632 Discussion on one potential way to improve the efficiency of IP Apple Computer Trading Co. Ltd discussion Discussion Yes
YesLenovo: this should be studied in one of the current SIDs, better not to agree on these conclusions right now. Qualcomm: there are issues with the randomised IV. Vodafone agreed that this was a good input for some of the Studies brought into this meeting.
noted No   S3‑183302
7.2 Security Assurance Specification for 5G (SCAS_5G) (Rel-16)                      
7.2.1 NR Node B (gNB) (TS 33.511) S3‑183430 UPdate test cases in 33.511 Huawei, Hisilicon pCR Approval Yes
YesDiscussed together with the paper from Ericsson in 608.
revised No S3‑183696  
    S3‑183696 UPdate test cases in 33.511 Huawei, Hisilicon pCR Approval Yes
Yes
approved No   S3‑183430
    S3‑183429 Adding Execution Steps to in 4.2.2.1.1, 4.2.2.1.2, and 4.2.2.1.7 Huawei, Hisilicon pCR Approval Yes
Yes
revised No S3‑183698  
    S3‑183698 Adding Execution Steps to in 4.2.2.1.1, 4.2.2.1.2, and 4.2.2.1.7 Huawei, Hisilicon pCR Approval Yes
Yes
approved No   S3‑183429
    S3‑183406 Add the evidences of the test cases Huawei, Hisilicon pCR Approval Yes
Yes
noted No    
    S3‑183405 Mapping requirements and test cases from 33.216 to 33.511 Huawei, Hisilicon pCR Approval Yes
Yes
revised No S3‑183699  
    S3‑183699 Mapping requirements and test cases from 33.216 to 33.511 Huawei, Hisilicon pCR Approval Yes
Yes
approved No   S3‑183405
    S3‑183431 New requirements and testcases on UP security policy related Huawei, Hisilicon pCR Approval Yes
Yes
noted No    
    S3‑183697 Draft TS 33.511 Huawei draft TS Approval Yes
Yes
approved No    
7.2.2 Access and Mobility Management Function (TS 33.512) S3‑183555 RES* verification failure test case Nokia, Nokia Shanghai Bell pCR Approval Yes
Yes
approved No    
    S3‑183446 Adding unique names to test cases Telekom Deutschland GmbH pCR Approval Yes
Yes
approved No    
    S3‑183700 draft TS 33.512 Deutsche Telekom draft TS Approval Yes
Yes
approved No    
7.2.3 User Plane Function (UPF) (TS 33.513)                      
7.2.4 Unified Data Management (UDM) (TS 33.514) S3‑183637 PCR to TR33.514 SUCI test case correction CATT pCR Approval Yes
Yes
revised No S3‑183701  
    S3‑183701 PCR to TR33.514 SUCI test case correction CATT pCR Approval Yes
Yes
approved No   S3‑183637
    S3‑183702 Draft TS 33.514 NEC draft TS Approval Yes
Yes
approved No    
7.2.5 Session Management Function (SMF) (TS 33.515)                      
7.2.6 Authentication Server Function (AUSF) (TS 33.516) S3‑183607 draft TS 33.516 (AUSF SCAS) Ericsson India Private Limited draft TS Approval Yes
Yes
approved No    
7.2.7 Security Edge Protection Proxy (SEPP) (TS 33.517) S3‑183387 Skeleton of SCAS SEPP TS 33.517 Nokia, Nokia Shanghai Bell pCR Approval Yes
Yes
approved No    
    S3‑183388 Scope of SCAS SEPP TS 33.517 Nokia, Nokia Shanghai Bell pCR Approval Yes
Yes
approved No    
    S3‑183389 Reference of SCAS SEPP TS 33.517 Nokia, Nokia Shanghai Bell pCR Approval Yes
Yes
noted No    
    S3‑183703 Draft TS 33.517 Nokia draft TS Approval Yes
Yes
approved No    
7.2.8 Network Resource Function (NRF) (TS 33.518) S3‑183390 Skeleton of SCAS NRF TS 33.518 Nokia, Nokia Shanghai Bell pCR Approval Yes
Yes
approved No    
    S3‑183391 Scope of SCAS NRF TS 33.518 Nokia, Nokia Shanghai Bell pCR Approval Yes
Yes
approved No    
    S3‑183392 Reference of SCAS NRF TS 33.518 Nokia, Nokia Shanghai Bell pCR Approval Yes
Yes
noted No    
    S3‑183704 Draft TS 33.518 Nokia draft TS Approval Yes
Yes
approved No    
7.2.9 Network Exposure Function (NEF) (TS 33.519) S3‑183319 Scope of TS 33.519 ZTE Corporation pCR Approval Yes
Yes
approved No    
    S3‑183320 References of TS 33.519 ZTE Corporation pCR Approval Yes
Yes
approved No    
    S3‑183321 Authentication on application functions ZTE Corporation pCR Approval Yes
Yes
revised No S3‑183707  
    S3‑183707 Authentication on application functions ZTE Corporation pCR Approval Yes
Yes
approved No   S3‑183321
    S3‑183705 Draft TS 33.519 ZTE draft TS Approval Yes
Yes
approved No    
7.3 eMCSec R16 security (MCXSec) (Rel-16)                      
7.4 Other work areas                      
7.4.1 SAE/LTE Security S3‑183343 eNB allowing Unauthenticated UEs in LSM Huawei, Hisilicon CR Approval Yes
YesNokia: it adds a new requirement for existing eNodeBs. The solution could be a simple configuraton issue. The CR is not necessary. Ericsson: just refer to TS 36.413. NTT-Docomo didnít understand the need for this. This was taken offline.
not pursued No    
    S3‑183373 Correction on LTE suspend/resume procedure for EDT capable UE Intel Corporation (UK) Ltd CR   Yes
YesVodafone was puzzled: we have done integrity protection for LTE without a WID, but for 5G we needed a Work Item. Nokia offered some rewording so the document was revised for this.
revised No S3‑183650  
    S3‑183650 Correction on LTE suspend/resume procedure for EDT capable UE Intel Corporation (UK) Ltd CR - Yes
Yes
agreed No   S3‑183373
    S3‑183593 LTE EDT Ė integrity protection of uplink EDT data Ericsson CR Agreement Yes
YesEricsson commented that RAN groups had to be queried whether this change was possible.They wanted to provide integrity protection for the uplink data and keep it 32 bits. An LS would have to be sent during the meeting week. It was pointed out that this CR was for Rel-15. Note from MCC: it is too late to bring cat-B CRs for Rel-15 so this has to be checked.
merged No S3‑183651  
7.4.2 IP Multimedia Subsystem (IMS) Security                      
7.4.3 Network Domain Security (NDS) S3‑183258 CR to 33310 r15 corrections of references and annex Juniper Networks, Ericsson CR   Yes
Yes
agreed No    
    S3‑183259 CR to 33310 r16 corrections of references Juniper Networks, Ericsson CR   Yes
Yes
agreed No    
7.4.4 UTRAN Network Access Security                      
7.4.5 GERAN Network Access Security                      
7.4.6 Generic Authentication Architecture (GAA)                      
7.4.7 Security Aspects of Home(e)NodeB (H(e)NB)                      
7.4.8 Mission Critical (MCPTT, MCSec, eMCSec, MONASTERY_SEC) S3‑183278 Observations on standards and technical constraints from 2nd MCPTT Plugtests ETSI CTI LS in   Yes
Yes
noted No    
    S3‑183263 LS on Observations from 2nd MCPTT Plugtests C1-186964 LS in   Yes
Yes
noted No    
    S3‑183305 Add symmetric key distribution mechanisms to TS 33.180 Airbus DS SLC discussion Approval Yes
YesEricsson: for what Release do you want this? Airbus: this release if possible. Some companies were agains this in release 16 (Vodafone, NCSC).
noted No    
    S3‑183419 Security solution for temporary group Ė broadcast group call procedure Huawei, Hisilicon CR Approval Yes
YesMotorola: not technically possible to do this. The Chair commented that this was a new solution being brought into Release 15, far from cat F.
not pursued No    
7.4.9 Security Assurance Specifications (SCAS-SA3, SCAS_PGW, SCAS_eNB) S3‑183383 5G inclusion in TS 33.117 Nokia, Nokia Shanghai Bell, Telekom Deutschland GmbH CR Approval Yes
YesMCC commented that this should be Rel-16 work and the WID code should be SCAS_5G.
agreed No    
    S3‑183384 Incorporating general SBA aspects in TS 33.117 Nokia, Nokia Shanghai Bell, Telekom Deutschland GmbH CR Approval Yes
YesThe Chair commented that this was a specification under change control and that adding empty clauses was not the right way of doing it. It was agreed to have a living document in the form of a draft CR where content could be added every meeting. Once the whole change is agreed, the last version of the draft CR will become a CR and all changes implemented directly into TS 33.117.
not pursued No    
    S3‑183385 Test Case of transport layer protection for SBI Nokia, Nokia Shanghai Bell, Telekom Deutschland GmbH CR Approval Yes
YesContent will go into the draft CR.
not pursued No    
    S3‑183386 Editorial corrections in TS 33.117 Nokia, Nokia Shanghai Bell CR Approval Yes
YesMCC commented that the editorial changes should go into the Rel-16 version of the specification.
agreed No    
    S3‑183428 Add EDCE5 realted requirements and testcases to 33.216 Huawei, Hisilicon CR Approval Yes
Yes
revised No S3‑183710  
    S3‑183710 Add EDCE5 realted requirements and testcases to 33.216 Huawei, Hisilicon CR Approval Yes
Yes
agreed No   S3‑183428
    S3‑183432 Update requirements in 4.2.3.2.2 in 33.117 Huawei, Hisilicon CR Approval Yes
Yes
agreed No    
    S3‑183452 New test case: No code execution or inclusion of external ressources by JSON parsers Telekom Deutschland GmbH CR Approval Yes
YesContent is agreed and it will go into the draftCR in 709.
not pursued No    
    S3‑183498 Formatting issue Nokia, Nokia Shanghai Bell CR Agreement Yes
Yes
agreed No    
    S3‑183515 Adding missing references in TS 33.117 Nokia, Nokia Shanghai Bell CR Approval Yes
Yes
agreed No    
    S3‑183608 SCAS discussion Ericsson India Private Limited pCR Discussion Yes
Yes
noted No    
    S3‑183626 General SCAS API requirements Ericsson India Private Limited CR Approval Yes
YesNokia wondered if this was a security input. Huawei considered that these kind of test cases were not usually discussed in SA3. This will go into the draft CR in 709.
not pursued No    
    S3‑183709 Draft CR Incorporating general SBA aspects in TS 33.117 Nokia draftCR Approval Yes
Yes
approved No    
7.4.10 Security Aspects of Narrowband IOT (CIoT) S3‑183409 Discussion on UP Integrity protection for small data in Early Data Transfer Huawei, Hisilicon discussion Endorsement Yes
Yes
noted No    
    S3‑183410 LS to RAN23 on UP Integrity Protection for Small Data in Early Data Transfer Huawei, Hisilicon LS out Approval Yes
Yes
revised No S3‑183652  
    S3‑183652 LS to RAN23 on UP Integrity Protection for Small Data in Early Data Transfer Huawei, Hisilicon LS out Approval Yes
Yes
approved No   S3‑183410
    S3‑183411 User Plane Integrity Protection for EDT Huawei, Hisilicon CR Approval Yes
Yes
revised No S3‑183651  
    S3‑183651 User Plane Integrity Protection for EDT Huawei, Hisilicon,Ericsson CR Approval Yes
Yes
agreed No   S3‑183411
    S3‑183832 Reply LS on UP Integrity Protection for Small Data in Early Data Transfer R3-187230 LS in discussion Yes
Yes
noted No    
    S3‑183833 Reply LS on UP Integrity Protection for Small Data in Early Data Transfer R2-1818666 LS in discussion Yes
Yes
noted No    
7.4.11 EPC enhancements to support 5G New Radio via Dual Connectivity (EDCE5) S3‑183279 Reply LS on " LS on Using same counter in EDCE5" R2-1816010 LS in   Yes
Yes
noted No    
    S3‑183592 EDCE5 Ė Fixing contradicting and insecure scg/sk counter handling in 33.401 from 36.331 Ericsson CR Agreement Yes
YesNokia: all these changes complicate the implementation. It was agreed to add a note. Huawei: this is not needed. RAN2 already understands what the counter is about.
revised No S3‑183712  
    S3‑183712 EDCE5 Ė Fixing contradicting and insecure scg/sk counter handling in 33.401 from 36.331 Ericsson CR Agreement Yes
Yes
not pursued No   S3‑183592
7.4.12 Northbound APIs Security for SCEF - SCS/AS Interworking (NAPS_Sec) (Rel-15)                      
7.4.13 Security Aspects of Common API Framework for 3GPP Northbound APIs (CAPIF_Sec) (Rel-15) S3‑183270 LS on security method negotiation C3-186335 LS in   Yes
Yes
replied to No    
    S3‑183557 Association of security context Samsung CR   Yes
YesNEC didn't see this as a fix.Ericsson agreed. This had to be taken offline, .
not pursued No    
    S3‑183560 [DRAFT] LS on Security method negotiation Samsung LS out   Yes
Yes
revised No S3‑183795  
    S3‑183795 LS on Security method negotiation Samsung LS out - Yes
Yes
approved No   S3‑183560
    S3‑183271 LS on API invoker onboarding C3-186414 LS in   Yes
Yes
noted No    
    S3‑183558 Missing subclause headings Samsung CR   Yes
YesNEC doubted that adding sub-clauses would cause less confusion. This is a SA6 issue, no action for SA3. They didn't have a strong opposition for not having these sub-clauses though.
agreed No    
    S3‑183559 [DRAFT] LS on API invoker onboarding Samsung LS out   Yes
YesNEC and Ericsson: the original LS was to SA6, not SA3.
noted No    
    S3‑183341 Correction/enhancement in CAPIF TS NEC Corporation CR Agreement Yes
YesEricsson: change reference to our own TLS profile in 33.310. Revised also to correct errors on the cover page.
revised No S3‑183713  
    S3‑183713 Correction/enhancement in CAPIF TS NEC Corporation CR Agreement Yes
Yes
agreed No   S3‑183341
    S3‑183421 Delete information during API invoker offboarding Huawei, Hisilicon CR Approval Yes
Yes
revised No S3‑183716  
    S3‑183716 Delete information during API invoker offboarding Huawei, Hisilicon CR Approval Yes
Yes
agreed No   S3‑183421
    S3‑183439 Security requirements on the CAPIF-3e/4e/5e reference points China Telecommunications CR Approval Yes
YesNEC commented that this was rel-16 work, and this CR was bringing the functionality change in Rel-15 and this was not possible anymore. The CR cover page even mentions the enhancements in Rel-16. It was agreed to wait for SA6 to finish their work and then initiate work in SA3,possibly with a WID.
not pursued No    
7.4.14 PLMN RAT selection (Steering of Roaming) (Rel-15) S3‑183285 LS Reply on Control Plane Solution for Steering of Roaming in 5GS GSMA LS in   Yes
YesSA will respond to this one.
noted No    
    S3‑183274 LS on Control Plane Solution for Steering of Roaming in 5GS CP-182234 LS in   Yes
Yes
noted No    
    S3‑183260 Reply LS on Control Plane Solution for Steering of Roaming in 5GS C1-186841 LS in   Yes
YesVodafone wasnít happy with the security response. Tim also mentioned that the non -security part had also wrong issues (but out of scope for SA3). T-Mobile didn't see the point of concern. They were happy with the CT1 response. Qualcomm didnít see so many problems with this response. Vodafone: there are two different mechanisms ending in two different points. This is not conveyed in here. T-Mobile commented that CT1 points out that encryption was available for the operator, optional, and it was highlighted why. The Chair didnít want to restart a discussion on SoR; this had been done in SA3 before; so he proposed to have a quick response. Alex(BT) commented that CT1 had messed up with the LI requirements. The regulatory bits were not correct.
noted No    
    S3‑183553 Draft-Reply LS on Control Plane Solution for Steering of Roaming in 5GS Samsung LS out Approval Yes
YesVodafone didnít agree with this response.
noted No    
    S3‑183715 LS on Control Plane Solution for Steering of Roaming in 5GS Vodafone LS out Approval Yes
Yes
approved No    
7.4.15 Battery Efficient Security for very low Throughput Machine Type Communication Devices (BEST_MTC_Sec) (Rel-15) S3‑183269 LS on EAS-C&U support C3-186313 LS in   Yes
Yes
postponed No    
    S3‑183714 Reply to: LS on EAS-C&U support Vodafone LS out approval No
Yes
withdrawn Yes    
7.4.16 Other work items                      
7.5 New Work Item proposals S3‑183367 New WID on security aspects of single radio voice continuity from 5G to 3G China Unicom, Huawei, HiSilicon, ZTE, CATT, OPPO, CATR WID new   Yes
YesORANGE: no need to put the different scenarios in the justification, just to refer to SA2.Make a better link to SA2 in both justification and objectives. Huawei clarified that SA2 had just approved their WID in their last meeting, so the dates were changed to accommodate this. It was noted that China Unicom was not in the meeting, but Huawei clarified that they would attend in future meetings to take care of this work.
revised No S3‑183739  
    S3‑183739 New WID on security aspects of single radio voice continuity from 5G to 3G China Unicom, Huawei, HiSilicon, ZTE, CATT, OPPO, CATR WID new - Yes
Yes
agreed No   S3‑183367
    S3‑183450 New WID - Updates and enhancements to BEST for 5G VODAFONE Group Plc WID new Agreement Yes
YesQualcomm: we have already AKMA for Rel-16 and itís related to this. We could include this work here. Vodafone commented that there was no such relationship. Ericsson: bring a study instead. Itís a new feature in the 5G system and we would need to do some study work before going normative. ORANGE agreed and also preferred to have it separately from AKMA. KPN supported having this in 5G directly as normative work. Vodafone: the study item will generate unnnecessary time and effort that will be later duplicated in the WID. They also had concerns that this WID wouldnít be approved despite the study work. NEC: just create a WID with a narrow scope, a couple of contributions and we do a one step approval. It was proposed to create TEI16 CRs but that wasn't considered as a proper working method by ORANGE and supported by MCC. It was also pointed out that it was incorrectly shown TR 33.163 instead of TS 33.163. Qualcomm pointed out that there was overlap with the scope of AKMA. This had to be taken offline and it was later postponed.
postponed No    
8 Studies                      
8.1 Study on Security Aspects of the 5G Service Based Architecture (FS_SBA-Sec) (Rel-15) S3‑183565 New option for 33.855 solution #8 Ericsson India Private Limited pCR Approval Yes
Yes
revised No S3‑183723  
    S3‑183723 New option for 33.855 solution #8 Ericsson India Private Limited pCR Approval Yes
Yes
approved No   S3‑183565
    S3‑183724 Draft TR 33.855 Deutsche Telekom draft TR Approval Yes
Yes
approved No    
8.2 Study on Long Term Key Update Procedures (FS_LTKUP) (Rel-16) S3‑183440 New SID on LTKUP Detailed Solutions VODAFONE Group Plc SID new Agreement Yes
Yes
revised No S3‑183755  
    S3‑183755 New SID on LTKUP Detailed Solutions VODAFONE Group Plc SID new Agreement Yes
Yes
agreed No   S3‑183440
    S3‑183445 pCR to TR 33.834 - Update to LTKUP Conclusions VODAFONE Group Plc pCR Approval Yes
YesGemalto wanted to add solution 5 together with solution 4b.MCC asked what was the intention of having a TR 900 series.Vodafone replied that a new SID was being brought to create such TR that would take the chosen solutions and describe them in more detail. The 900 series TR could be referenced externally.
revised No S3‑183752  
    S3‑183752 pCR to TR 33.834 - Update to LTKUP Conclusions VODAFONE Group Plc pCR Approval Yes
Yes
approved No   S3‑183445
    S3‑183753 Draft TR 33.834 Vodafone draft TR Approval Yes
Yes
approved No    
    S3‑183754 cover sheet TR 33.834 Vodafone TS or TR cover discussion Yes
Yes
approved No    
8.3 Study on Supporting 256-bit Algorithms for 5G (FS_256-Algorithms) (Rel-16) S3‑183261 Reply LS on the Impacts of increasing the MAC-I and NAS-MAC size R2-1816012 LS in   Yes
Yes
noted No    
    S3‑183262 Reply LS on LS on the Impacts of increasing the MAC-I and NAS-MAC size C1-186961 LS in   Yes
Yes
noted No    
    S3‑183252 pCR to TS 33.841 - restructure of section 4 as agreed in conf call VODAFONE Group Plc pCR Agreement Yes
YesNCSC: too late to introduce all this information, additonal drivers for 256 bits. AT&T: there will be a period of time required for SAGE to do the anylisis for the appropriate algorithms supporting 256bits. We are likely entering into Rel-17 with this. Rel-16 would serve as analysis of the algorithms. We are favouring this document. Vodafone: there are other reasons why we are doing 256 bits.
noted No    
    S3‑183308 Algorithm Agility NIST pCR Approval Yes
YesNCSC: no need to add information that we havenít looked at. NEC: the bullet points look like the objectives of a study. They should be removed.
noted No    
    S3‑183309 pCR Discussing mitigating of risks by using larger keys NIST pCR Approval Yes
YesNCSC: reluctant to write this down, we disagree with this document. Ericsson supported this. Gemalto and Huawei agreed with the content of the text. Vodafone: the conclusion we agreed on last meeting was that we donít need to do anything for 4 years. The support/non support was balanced and this was taken offline.
noted No    
    S3‑183507 pCR to 33.841 (256bit) - Update section 4 with new drivers VODAFONE Group Plc pCR Approval Yes
YesNCSC: this brings a new driver that would need additional analysis and assesment. Qualcomm disagreed with the document as well. Vodafone: if companies are comfortable with the 4 year wait, then we donít need to discuss theese documents. Huawei didn't agree with waiting for 4 years. Vodafone: if companies agree with not asking SAGE to start the process, then we can withdraw all these documents. CATT: we need 256 bits for classified communications. We support this. NCSC: introducing this now means an additional year of work to assess it. Nokia: our requirements can stand for 4 years. Vodafone: SAGE estimates a year to come back with the algorithms analysis. Vodafone proposed to send an LS to ask SAGE what algorithm would be suitable for 256 integrity and cyphering. NCSC questioned the necessity to do this. Vodafone: there are market drivers for this. Support for sending the LS: AT&T, NEC, Airbus, China Mobile, IDEMIA, Gemplus, CATT,CATR, NIST,Vodafone,Huawei,Qualcomm,T-Mobile, ZTE. Vodafone: happy to withdraw these documents and make the spec more quantum computing directed and not having to justify the time frame with them. This was agreed and a number of documents were noted.
noted No    
    S3‑183451 pCR to TR 33 841 Threat details to symmetric cryptography CATT pCR Approval Yes
YesNCSC didnít agree with the first change, not required. "To the best of our knowldege" was removed. Second change should go away too. This was agreed.
revised No S3‑183757  
    S3‑183757 pCR to TR 33 841 Threat details to symmetric cryptography CATT pCR Approval Yes
Yes
approved No   S3‑183451
    S3‑183310 pCR to Include content discussing forward security NIST pCR Approval Yes
Yes
revised No S3‑183759  
    S3‑183759 pCR to Include content discussing forward security NIST pCR Approval Yes
Yes
approved No   S3‑183310
    S3‑183292 Update to Impacted NextGen Areas - TR 33.841 NCSC pCR Approval Yes
YesBT: not only 5G voice but also media should be included here. NCSC commented that was topic for another study. Ericsson suggested some editorials. 6.2.5 and 6.1.10 were removed.
revised No S3‑183760  
    S3‑183760 Update to Impacted NextGen Areas - TR 33.841 NCSC pCR Approval Yes
Yes
approved No   S3‑183292
    S3‑183481 pCR to TR 33 841 regarding key derivation function China Mobile; Vodafone pCR   Yes
YesNCSC: last sentence is not always true. Last two sentences were removed.
revised No S3‑183761  
    S3‑183761 pCR to TR 33 841 regarding key derivation function China Mobile; Vodafone pCR - Yes
Yes
approved No   S3‑183481
    S3‑183629 TR 33.841: complete clause on OTA mechanism Gemalto N.V. pCR Approval Yes
Yes
revised No S3‑183762  
    S3‑183762 TR 33.841: complete clause on OTA mechanism Gemalto N.V. pCR Approval Yes
Yes
approved No   S3‑183629
    S3‑183447 pCR to TR 33 841 Performance aspects for the new 256-bit algorithms CATT pCR Approval Yes
Yes
withdrawn Yes    
    S3‑183477 pCR to TR 33 841 Study of individual algorithm details CATT, CAICT, China Mobile, China Telecom, China Unicom, Huawei, HiSilicon, ZTE, OPPO pCR Approval Yes
Yes
revised No S3‑183763  
    S3‑183763 pCR to TR 33 841 Study of individual algorithm details CATT, CAICT, China Mobile, China Telecom, China Unicom, Huawei, HiSilicon, ZTE, OPPO pCR Approval Yes
Yes
approved No   S3‑183477
    S3‑183516 Clause 13.1.1: AES modes Ericsson pCR Approval Yes
Yes
revised No S3‑183764  
    S3‑183764 Clause 13.1.1: AES modes Ericsson pCR Approval Yes
Yes
approved No   S3‑183516
    S3‑183475 pCR to TR 33 841 Potential requirements CAICT, CATT, China Mobile, China Telecom, China Unicom, Huawei, HiSilicon, ZTE, OPPO pCR Approval Yes
YesLast paragraph of 14.3 is not accurate. Vodafone: this needs to be clearly a requirements clause.
merged No S3‑183766  
    S3‑183290 Potential Requirements for TR 33.841 NCSC pCR Approval Yes
Yes
revised No S3‑183766  
    S3‑183766 Potential Requirements for TR 33.841 NCSC, CAICT, CATT, China Mobile, China Telecom, China Unicom, Huawei, HiSilicon, ZTE, OPPO pCR Approval Yes
Yes
approved No   S3‑183290
    S3‑183473 pCR to TR 33.841 draft conclusion CAICT, CATT, China Mobile, China Telecom, China Unicom, Huawei, HiSilicon, ZTE, OPPO, Qihoo 360 pCR Approval Yes
YesVodafone: not possible to have this in Rel-16, it will be Rel-17 or Rel-18. NIST: this doesnít reflect the content of the document.
merged No S3‑183767  
    S3‑183291 Conclusions for TR 33.841 NCSC pCR Approval Yes
YesVodafone and NIST preferred this conclusion to the document 473. It was agreed to revise this including some bits of the CATT document.
revised No S3‑183767  
    S3‑183767 Conclusions for TR 33.841 NCSC, CAICT, CATT, China Mobile, China Telecom, China Unicom, Huawei, HiSilicon, ZTE, OPPO, Qihoo 360 pCR Approval Yes
Yes
approved No   S3‑183291
    S3‑183293 Editorials for TR 33.841 NCSC pCR Approval Yes
Yes
revised No S3‑183768  
    S3‑183768 Editorials for TR 33.841 NCSC pCR Approval Yes
Yes
approved No   S3‑183293
    S3‑183294 Modifications and Clarifications for TR 33.841 NCSC pCR Approval Yes
YesGemalto: donít remove the text in clause 9.1. It introduces some useful background. MCC commented that the use of "must" was not allowed in 3GPP specifications. This was reworded.
revised No S3‑183765  
    S3‑183765 Modifications and Clarifications for TR 33.841 NCSC pCR Approval Yes
Yes
approved No   S3‑183294
    S3‑183393 pCR to TR 33.841 draft conclusion CATT pCR Approval Yes
Yes
withdrawn Yes    
    S3‑183448 pCR to TR 33 841 Potential requirements CATT pCR Approval Yes
Yes
withdrawn Yes    
    S3‑183449 pCR to TR 33 841 Study of individual algorithm details CATT pCR Approval Yes
Yes
withdrawn Yes    
    S3‑183756 LS to SAGE on 256bit algorithms Vodafone LS out Approval Yes
Yes
approved No    
    S3‑183758 Draft TR 33.841 Vodafone draft TR Approval No
Yes
approved No    
    S3‑183769 Cover sheet TR 33.841 Vodafone TS or TR cover Approval No
Yes
approved No    
8.4 Security aspects of single radio voice continuity from 5G to UTRAN (FS_5G_UTRAN_SEC) (Rel-16) S3‑183395 Proposed change to the solution #1.1 of TR 33.856 Huawei, Hisilicon pCR Approval Yes
YesQualcomm wanted to add a sentence in step 2 on using a different FC value that cannot be used in another key derivation. The NOTE in 4 needs to be aligned with the previous statement.
revised No S3‑183728  
    S3‑183728 Proposed change to the solution #1.1 of TR 33.856 Huawei, Hisilicon pCR Approval Yes
Yes
approved No   S3‑183395
    S3‑183396 clean up the EN of subclause 6.4.3 in TR 33.856 Huawei, Hisilicon pCR Approval Yes
Yes
approved No    
    S3‑183398 add evaluation to solution #5 Huawei, Hisilicon pCR Approval Yes
Yes
approved No    
    S3‑183368 Impacts on existing nodes and functionality for the solution "Return from UTRAN to E-UTRAN or NR" China Unicom pCR   Yes
Yes
approved No    
    S3‑183369 Evaluation for the solution "Return from UTRAN to E-UTRAN or NR" China Unicom pCR   Yes
YesDocomo commented that the phrase had to be reworded since there was some confusion with the description of the attack.
revised No S3‑183730  
    S3‑183730 Evaluation for the solution "Return from UTRAN to E-UTRAN or NR" China Unicom pCR - Yes
Yes
approved No   S3‑183369
    S3‑183370 Conclusion for the solution "Return from UTRAN to E-UTRAN or NR" China Unicom pCR   Yes
YesMCC commented that the second sentence on the normative work expected in 33.501 was not relevant to the TR and more related to plans for a future WID, so this was removed.
revised No S3‑183731  
    S3‑183731 Conclusion for the solution "Return from UTRAN to E-UTRAN or NR" China Unicom pCR - Yes
Yes
approved No   S3‑183370
    S3‑183397 clean up the EN of subclause 7 in TR 33.856 Huawei, Hisilicon pCR Approval Yes
YesRevised to remove the entirety of the editor's note.
revised No S3‑183732  
    S3‑183732 clean up the EN of subclause 7 in TR 33.856 Huawei, Hisilicon pCR Approval Yes
Yes
approved No   S3‑183397
    S3‑183617 Addressing the editorís notes in the conclusions clause of TR 33.856 Qualcomm Incorporated pCR Approval Yes
Yes
noted No    
    S3‑183399 editorial modification on TR 33.856 Huawei, Hisilicon pCR Approval Yes
Yes
approved No    
    S3‑183729 Draft TR 33.856 China Unicom draft TR Approval Yes
Yes
approved No    
    S3‑183733 Cover sheet TR 33.856 Huawei TS or TR cover Approval Yes
Yes
approved No    
8.5 Study on authentication and key management for applications based on 3GPP credential in 5G IoT (FS_AKMA)(Rel-16) S3‑183394 Protecting SUPI for user privacy ZTE Corporation pCR Approval Yes
YesZTE: it doesnít say anything between the UE and the network. Huawei: we donít need this here. ORANGE: separate both requirements. Adding privacy protection and the purpose of this in the revision, as proposed by Qualcomm and ORANGE.
revised No S3‑183734  
    S3‑183734 Protecting SUPI for user privacy ZTE Corporation pCR Approval Yes
Yes
approved No   S3‑183394
    S3‑183533 Key Issue on Compliance with Local Rules and Regulations NEC Corporation pCR Approval Yes
YesMCC commented that the sentence of "AKMA should be made regulations aware.." looked like a requirement. It was pointed out that this wasn't the intention and it was agreed to reword it as "needs to be done.." directly into the spec by the rapporteur.
approved No    
    S3‑183544 New Key Issue: Generic battery efficient end-to-end security KPN pCR Approval Yes
YesVodafone: battery efficient bit is too narrow.Happy to say "battery effcient" without the i.e. Ericsson: the operator would provide the keys here? It's strange. ORANGE: puzzled by some of the terms, like "simple UE". We are not saying anywhere that AKMA shall support GBA as it is implied here. Huawei: worried about the operator eavesdropping the communications.It was agreed to remove the threat. Ericsson: the point of AKMA is not to protect the UE from the operator. Vodafone: consider lawful interception issues here, LI needs to check this.
revised No S3‑183736  
    S3‑183736 New Key Issue: Generic battery efficient end-to-end security KPN pCR Approval Yes
Yes
approved No   S3‑183544
    S3‑183561 New KI: Key Lifetimes Ericsson India Private Limited pCR Approval Yes
YesVodafone: what happens when the max lifetime is reached? We need requirements for that too. Nokia: why are we negotiating the keys again in the security threat? Ericsson replied that it is similar to what happens in GBA. Gemalto confirmed that this case was widely studied in the GBA work. This had to be taken offline. The max lifetime was the only non controversial issue.
revised No S3‑183737  
    S3‑183737 New KI: Key Lifetimes Ericsson India Private Limited pCR Approval Yes
Yes
approved No   S3‑183561
    S3‑183563 New KI: API for AKMA keys in UE Ericsson India Private Limited pCR Approval Yes
YesVodafone, Qualcomm: we donít standardize this. It was decided to add an editor's note in order to clarify Qualcomm's concerns.
revised No S3‑183746  
    S3‑183746 New KI: API for AKMA keys in UE Ericsson India Private Limited pCR Approval Yes
Yes
approved No   S3‑183563
    S3‑183631 Key Issue on secure communication between ME and UICC Alibaba (China) group., Ltd., China Mobile pCR Approval Yes
YesORANGE: interface between ME and UICC is in the scope of ETSI SCP, not ours. There was not much support for this contribution, so it was finally noted.
noted No   S3‑183306
    S3‑183307 AKMA candidate solution for non-3GPP credential download Alibaba (China) group., Ltd., China Mobile pCR Approval Yes
YesRelated to the previous one. Vodafone: totally out of scope.
noted No    
    S3‑183420 Solution for bootstrapping authentication of AKMA Huawei, Hisilicon pCR Approval Yes
YesNEC: where do the keys go? What are they bound to? We need a key hierarchy as well. It was agreed to add an editor's note to address this. These and other comments were addressed in the revision.
revised No S3‑183747  
    S3‑183747 Solution for bootstrapping authentication of AKMA Huawei, Hisilicon pCR Approval Yes
Yes
approved No   S3‑183420
    S3‑183511 Discussion and pCR of Candidate Solution: Transport independent procedure using existing protocols China Mobile; Alibaba (China) Group., Ltd. pCR   Yes
YesFigure changed to grey scale since the colors didnít mean anything. It was also agreed to add an Editor's note on architecture as proposed by Nokia. Split into solutions as well.
revised No S3‑183748  
    S3‑183748 Discussion and pCR of Candidate Solution: Transport independent procedure using existing protocols China Mobile; Alibaba (China) Group., Ltd. pCR - Yes
Yes
approved No   S3‑183511
    S3‑183513 Discussion and pCR of candidate solution: UE implementation schemes in achieving AKMA procedures China Mobile; Alibaba (China) Group., Ltd. pCR   Yes
YesVodafone: colors mean nothing, make the figures editable, also split into different solutions. KPN: what is CP and AT? Please add their definitions.
revised No S3‑183749  
    S3‑183749 Discussion and pCR of candidate solution: UE implementation schemes in achieving AKMA procedures China Mobile; Alibaba (China) Group., Ltd. pCR - Yes
Yes
approved No   S3‑183513
    S3‑183562 New solution: Access independent architecture solution for AKMA Ericsson India Private Limited pCR Approval Yes
Yes
revised No S3‑183750  
    S3‑183750 New solution: Access independent architecture solution for AKMA Ericsson India Private Limited pCR Approval Yes
Yes
approved No   S3‑183562
    S3‑183564 New solution: Stand-alone architecture solution for AKMA Ericsson India Private Limited pCR Approval Yes
Yes
revised No S3‑183751  
    S3‑183751 New solution: Stand-alone architecture solution for AKMA Ericsson India Private Limited pCR Approval Yes
Yes
approved No   S3‑183564
    S3‑183306 Key Issue on secure communication between UE and application server Alibaba (China) group., Ltd., China Mobile pCR Approval Yes
Yes
revised No S3‑183631  
    S3‑183735 Draft TR 33.835 China Mobile draft TR Approval Yes
Yes
approved No    
8.6 Study on evolution of Cellular IoT security for the 5G System (FS_CIoT_sec_5G) (Rel-16) S3‑183539 Key Issue #4 Ė Signalling overload due to Malicious Applications on the UE KPN pCR Approval Yes
YesEricsson: the need for human intervention is something we usually donít mention in our specs. This was removed.
merged No S3‑183772  
    S3‑183460 Improvement for key issue on the signalling overload due to malicious applications on the UE Huawei, HiSilicon pCR Approval Yes
YesVodafone: no difference here between malicious operation and poor programming? T-Mobile: misbehaving should not be in the network to start with. KPN: second requirement should be a temporarily removal, not permanent (too strong). T-Mobile: isolating instead of removing from the network.
revised No S3‑183772  
    S3‑183772 Improvement for key issue on the signalling overload due to malicious applications on the UE Huawei, HiSilicon,KPN pCR Approval Yes
Yes
approved No   S3‑183460
    S3‑183331 Add security requirements to key issue#6 Nokia pCR Approval Yes
YesQualcomm: these are not requirements, they are solutions. KPN supported these requirements. Qualcomm: the application is in another level, it is not possible to evaluate it drom the network point of view. ORANGE agreed.
noted No    
    S3‑183541 New KI: Protection of interface used by NIDD procedures Ericsson LM pCR Approval Yes
Yes
revised No S3‑183773  
    S3‑183773 New KI: Protection of interface used by NIDD procedures Ericsson LM pCR Approval Yes
Yes
approved No   S3‑183541
    S3‑183538 New Key Issue: Remote (de)provisioning of credentials KPN pCR Approval Yes
YesORANGE: we decided not to deal with this topic anymore, since SA2 has not concluded on this issue.
noted No    
    S3‑183415 Key Issue on Classification of IoT UE based on Attack Method Huawei, Hisilicon pCR Approval Yes
YesNEC wanted to rewiord the requirements. Nokia: remove the last requirement. Colin (BT): donít duplicate the work that other SDOs are doing. E.g. TC CYBER, GSMA. ORANGE supported this. Qualcomm: this is out of scope of 3GPP.
noted No    
    S3‑183332 Adding Key issue for Connectionless service security Nokia pCR Approval Yes
YesEricsson: some requirements already covered in other key issues, others are too solution specific. ORANGE: donít refer to solution 29 especifically.Threats are too specific too.
revised No S3‑183775  
    S3‑183775 Adding Key issue for Connectionless service security Nokia pCR Approval Yes
Yes
approved No   S3‑183332
    S3‑183545 New KI: Privacy protection of the NIDD API between UPF/NEF and AF Ericsson LM pCR Approval Yes
YesNEC: reword the security threat. It had to be taken offline to address some concerns from ORANGE. Huawei: remove UPF from the title.
noted No    
    S3‑183776 New KI: Privacy protection of the NIDD API between UPF/NEF and AF Ericsson LM pCR Approval No
Yes
withdrawn Yes    
    S3‑183338 Solution proposal for FS_CIoT_sec_5G NEC Corporation pCR Approval Yes
YesEricsson: there is an overhead in the network side. It is not clear whether this is needed so it should be captured in an editor's note. Huawei: remove the evaluation and bring one back next meeting. BT: losing security in favour of performance here. Add condition on security policy here.
revised No S3‑183777  
    S3‑183777 Solution proposal for FS_CIoT_sec_5G NEC Corporation pCR Approval Yes
Yes
approved No   S3‑183338
    S3‑183537 Security solution for MO SMS in initial NAS message - handling AMF re-allocation Ericsson LM pCR Approval Yes
Yes
revised No S3‑183778  
    S3‑183778 Security solution for MO SMS in initial NAS message - handling AMF re-allocation Ericsson LM pCR Approval Yes
Yes
approved No   S3‑183537
    S3‑183535 Security solution for small data sent with EDT in RRC Resume Request for E-UTRA connected to 5GC Ericsson pCR Approval Yes
Yes
revised No S3‑183779  
    S3‑183779 Security solution for small data sent with EDT in RRC Resume Request for E-UTRA connected to 5GC Ericsson pCR Approval Yes
Yes
approved No   S3‑183535
    S3‑183536 Security solution for small data included in initial NAS to handle AMF reallocation Ericsson LM pCR Approval Yes
Yes
revised No S3‑183780  
    S3‑183780 Security solution for small data included in initial NAS to handle AMF reallocation Ericsson LM pCR Approval Yes
Yes
approved No   S3‑183536
    S3‑183542 New Solution for Key Issue #4: Use of UE Configuration Update KPN pCR Approval Yes
YesNokia: vague solution. Huawei: this detection mechanism is out of scope of 3GPP. ORANGE: it is written in the evaluation that it is out of scope of 3GPP. Several editor's notes were agreed to be added in the revision.
revised No S3‑183781  
    S3‑183781 New Solution for Key Issue #4: Use of UE Configuration Update KPN pCR Approval Yes
Yes
approved No   S3‑183542
    S3‑183346 Solution for protecting gNB from RRC re-establishment DDoS attack Huawei, Hisilicon pCR Approval Yes
YesORANGE: thresholds are in scope of 3GPP? This is implementation specific and should not go through in normative work.
revised No S3‑183782  
    S3‑183782 Solution for protecting gNB from RRC re-establishment DDoS attack Huawei, Hisilicon pCR Approval Yes
Yes
approved No   S3‑183346
    S3‑183543 New solution for protection of interface used by NIDD procedures Ericsson LM pCR Approval Yes
Yes
revised No S3‑183783  
    S3‑183783 New solution for protection of interface used by NIDD procedures Ericsson LM pCR Approval Yes
Yes
approved No   S3‑183543
    S3‑183416 Capture IoT Security Related Requirement in other 3GPP Document Huawei, Hisilicon pCR Approval Yes
YesORANGE: the specs can change, and this is hard to maintain. Useful for a discussion document, but not for the TR.
noted No    
    S3‑183352 Solution for protecting gNB from RRC re-establishment DDoS attack Huawei, Hisilicon pCR Approval No
Yes
withdrawn Yes    
    S3‑183774 Draft TR 33.861 Ericsson draft TR Approval Yes
Yes
approved No    
8.7 Study on the security of the Wireless and Wireline Convergence for the 5G system architecture (FS_5WWC_SEC) (Rel-16) S3‑183275 Response to 3GPP SA2 liaison S2-189038 on Ďgeneral status of workí BBF LS in   Yes
Yes
postponed No    
    S3‑183280 Reply LS on security requirements for RRC connection release R2-1816053 LS in   Yes
Yes
noted No    
    S3‑183282 Reply LS on devices behind 5G-RG accessing the 5GC S2-1810989 LS in   Yes
Yes
noted No    
    S3‑183288 Reply LS on 5WWC status of work and interim agreements S2-1811575 LS in   Yes
YesPotential response when replying to 275.
noted No    
    S3‑183517 Update of Key Issue #2: FN-RG authentication and authorization Ericsson pCR Approval Yes
YesNEC: why do we study the authentication and authorization of FN-RG if this is outside the scope of 3GPP? It's BBF stuff. Ericsson: BBF will ask us questions about this. We can have something in our TR or we can communicate with them via LS. Huawei: this is in scope of SA2. It was agreed to send an LS to SA2 to consult them on this topic. The document was finally noted.
noted No    
    S3‑183518 New solution for Key Issue #2: FN-RG authentication and authorization Ericsson pCR Approval Yes
Yes
noted No    
    S3‑183519 New KI: Authentication of 5G capable UE behind a RG Ericsson pCR Approval Yes
YesORANGE didnít find this necessary.This is not different from an WiFi access point.NEC supported this. Nokia and Deutsche Telekom preferred to have this key issue added. ORANGE: what's the added value for having another mechanism for non 3GPP access? It was agreed to add a note where it was stressed that any other authentication rather than 5GC authentication would need a strong reason.
revised No S3‑183786  
    S3‑183786 New KI: Authentication of 5G capable UE behind a RG Ericsson pCR Approval Yes
Yes
approved No   S3‑183519
    S3‑183521 New Solution: 5GC-capable UEs behind 5G-RG/FN-RG using N3GPP-access solutions Ericsson pCR Approval Yes
YesHuawei: postponed the evaluation part until SA2 has finished with this. Ericsson: we cannot wait for SA2, it would be too late.
revised No S3‑183791  
    S3‑183791 New Solution: 5GC-capable UEs behind 5G-RG/FN-RG using N3GPP-access solutions Ericsson pCR Approval Yes
Yes
approved No   S3‑183521
    S3‑183520 New KI: User plane data handling for 5G capable UE behind a RG Ericsson pCR Approval Yes
Yes
revised No S3‑183787  
    S3‑183787 New KI: User plane data handling for 5G capable UE behind a RG Ericsson,NEC pCR Approval Yes
Yes
approved No   S3‑183520
    S3‑183534 Key Issue on Access Independent Security for 5WWC NEC Corporation pCR Agreement Yes
Yes
revised No S3‑183788  
    S3‑183788 Key Issue on Access Independent Security for 5WWC NEC Corporation pCR Agreement Yes
Yes
approved No   S3‑183534
    S3‑183376 Key Issue: Requirement of Trust mechanism of Non 3GPP UEs China Telecom Corporation Ltd. pCR Approval Yes
YesORANGE: what is a non-5GC capable UE? Nokia didnít want to agree with this key issue either. Ericsson: there is no scenario in SA2 that covers this.
noted No    
    S3‑183423 Secure storage of UICC Huawei, Hisilicon pCR Approval Yes
YesNEC: there is nothing new here, there are solutions for this. There was no support for this document.
noted No    
    S3‑183424 secure boot of 5G-RG Huawei, Hisilicon pCR Approval Yes
Yes
noted No    
    S3‑183425 Prevent from 5G-RG cheating Huawei, Hisilicon pCR Approval Yes
YesWhat's the difference in this context between a 5G-RG and an UE? I could use my phone as a WiFi hotspot. Juniper and Nokia supported Ericsson. Huawei: this RG is more exposed than your phone.
noted No    
    S3‑183426 solution on 5G-RG authentication Huawei, Hisilicon pCR Approval Yes
Yes
approved No    
    S3‑183427 Editoral Change of Solution 1 Huawei, Hisilicon pCR Approval Yes
Yes
approved No    
    S3‑183784 Draft TR 33.807 Huawei draft TR Approval Yes
Yes
approved No    
    S3‑183785 LS on FN-RG authentication and related questions Ericsson LS out Approval Yes
Yes
approved No    
8.8 Study on Security Aspects of PARLOS (FS_PARLOS_Sec) (Rel-16) S3‑183567 Update of PARLOS solution #1 Motorola Mobility, Lenovo pCR Approval Yes
YesEricsson didnít agree with removing the editor's note and they proposed to reformulate it. Sprint: these could be unauthenticated devices without an USIM. Things can be handled by an ME without an USIM. The term UE was to be replaced by ME. Sprint added that false base stations atttacks are possible due to the current FCC regulations. The document was revised to address these comments.
revised No S3‑183725  
    S3‑183725 Update of PARLOS solution #1 Motorola Mobility, Lenovo pCR Approval Yes
Yes
approved No   S3‑183567
    S3‑183630 P-CR describing current manual roaming in US Sprint Corporation pCR Agreement Yes
YesVodafone: some other countries different from US have this issue as well. What happens if they try to attach as an VF UK customer and there is no roaming agreement with VF UK? Are you switching to the manual roaming? Sprint replied affirmatively, and Vodafone didn't find it acceptable. This enabling customers to break their agreements. An editor's note on this issue was added. MCC commented that mentioning companies like American Roaming Networks could lead to copyright issues that should be avoided. A reference to a study or paper where the data was found would be more useful. Mirko (MCC) also suggested to add a reference to the SA1 study document. There were several editorial issues that were taken into account as well in the revision.
revised No S3‑183727  
    S3‑183727 P-CR describing current manual roaming in US Sprint Corporation pCR Agreement Yes
Yes
approved No   S3‑183630
    S3‑183726 Draft TR 33.815 Sprint draft TR Approval Yes
Yes
approved No    
8.9 Study on 5G security enhancement against false base stations S3‑183300 skeleton of TR 33.809-Study on 5G Security Enhancement against False Base Station Apple Computer Trading Co. Ltd pCR Approval Yes
Yes
approved No    
    S3‑183568 Clause #4 for the upcoming TR on FS_5GFBS Ericsson pCR Approval Yes
YesNTT-Docomo: Some parts should go to the Introduction of the draft report.
revised No S3‑183800  
    S3‑183800 Clause #4 for the upcoming TR on FS_5GFBS Ericsson pCR Approval Yes
Yes
approved No   S3‑183568
    S3‑183296 Discussion of Potential threats caused by false base station Apple Computer Trading Co. Ltd discussion Agreement Yes
Yes
noted No    
    S3‑183297 Key issue of authenticating gNB on broadcast and unicast message Apple Computer Trading Co. Ltd pCR Approval Yes
YesORANGE: requirement looks too solution specific. Ericsson: when you mention PWS you should refer to what SA3 has done on this topic. This overlaps with 580 and 581.
availablem No S3‑183801  
    S3‑183330 Key issue false base station detection and isolation Nokia pCR Approval Yes
YesBT: false base stations are already isolated. The requirement was removed.
revised No S3‑183802  
    S3‑183802 Key issue false base station detection and isolation Nokia,Ericsson pCR Approval Yes
Yes
approved No   S3‑183330
    S3‑183347 Key Issue on spoofing system informations Huawei, Hisilicon pCR Approval Yes
Yes
merged No S3‑183801  
    S3‑183349 Key Issue on Spoofing UE paging messages Huawei, Hisilicon pCR Approval Yes
Yes
noted No    
    S3‑183551 Key issue on AS security during RRC Idle mode Samsung pCR Approval Yes
Yes
merged No S3‑183801  
    S3‑183570 Enhancing detection - new KI for the upcoming TR on FS_5GFBS Ericsson pCR Approval Yes
Yes
merged No S3‑183802  
    S3‑183580 SI integrity - new KI for the upcoming TR on FS_5GFB Ericsson pCR Approval Yes
YesThe Chair commented that a catalog of common possible attacks on the base stations should be avoided in this document. It was enough just to refer to other documents that describe them.
revised No S3‑183801  
    S3‑183801 SI integrity - new KI for the upcoming TR on FS_5GFB Ericsson,Samsung,Apple,Huawei pCR Approval Yes
Yes
approved No   S3‑183580
    S3‑183579 SI replay - new KI for the upcoming TR on FS_5GFB Ericsson pCR Approval Yes
YesThe requirement was removed. MCC commented that it was not possible to refer to TR 33.899 since the draft had been withdrawn.
merged No S3‑183801  
    S3‑183581 Rogue REJECTS - new KI for the upcoming TR on FS_5GFB Ericsson pCR Approval Yes
Yes
merged No S3‑183803  
    S3‑183569 SON security - new KI for the upcoming TR on FS_5GFBS Ericsson pCR Approval Yes
Yes
revised No S3‑183804  
    S3‑183804 SON security - new KI for the upcoming TR on FS_5GFBS Ericsson pCR Approval Yes
Yes
approved No   S3‑183569
    S3‑183470 Key issue on Authentication relay attack Huawei, Hisilicon pCR Approval Yes
Yes
revised No S3‑183805  
    S3‑183805 Key issue on Authentication relay attack Huawei, Hisilicon pCR Approval Yes
Yes
approved No   S3‑183470
    S3‑183299 Key issue of security protection on the unicast message from the UE before security activation Apple Computer Trading Co. Ltd pCR Approval Yes
YesIt was agreed to remove the requirements. China Mobile commented that this was not a key issue for the fake base station.
revised No S3‑183803  
    S3‑183803 Key issue of security protection on the unicast message from the UE before security activation Apple Computer Trading Co. Ltd,Ericsson pCR Approval Yes
Yes
approved No   S3‑183299
    S3‑183571 Enhancing untraceability - new KI for the upcoming TR on FS_5GFB Ericsson pCR Approval Yes
Yes
noted No    
    S3‑183348 Key Issue on HO failure caused by fake base station Huawei, Hisilicon pCR Approval Yes
Yes
merged No S3‑183804  
    S3‑183572 Privacy visibility - new KI for the upcoming TR on FS_5GFB Ericsson pCR Approval Yes
YesBT,Nokia and Apple objected to this. ORANGE supported this, since the user could react with some action if he receives the data that there is a false base station,
noted No    
    S3‑183576 Service visibility - new KI for the upcoming TR on FS_5GFB Ericsson pCR Approval Yes
YesApple objected to this.
noted No    
    S3‑183582 Radio jamming - placeholder-only KI for the upcoming TR on FS_5GFB Ericsson pCR Approval Yes
YesDeutsche Telekom didnít see the need to include this key issue.
revised No S3‑183806  
    S3‑183806 Radio jamming - placeholder-only KI for the upcoming TR on FS_5GFB Ericsson pCR Approval Yes
Yes
approved No   S3‑183582
    S3‑183301 Key issue of security overhead and complexity Apple Computer Trading Co. Ltd pCR Approval Yes
YesORANGE: this key issue is based on TR 33.899, which was withdrawn, and I donít agree with this. Deutsche Telekom and Huawei supported this.
noted No    
    S3‑183350 Protecting UE from connnecting to fake basestation during HO Huawei, Hisilicon pCR Approval Yes
YesORANGE: too early for this evaluation, remove it. Ericsson, Qualcomm: too early for the whole document.
noted No    
    S3‑183351 Aoviding unnecessary HO caused by fake base station Huawei, Hisilicon pCR Approval Yes
Yes
noted No    
    S3‑183552 Solution for AS security during RRC Idle mode Samsung pCR Approval Yes
YesORANGE: when we bring these solutions from TR 33.899, shouldnít we use their evaluations as well? We donít need to re-evaluate. There was no requirement for this solution, so it was noted.
noted No    
    S3‑183353 Key Issue on spoofing system informations Huawei, Hisilicon pCR Approval No
Yes
withdrawn Yes    
    S3‑183354 Key Issue on HO failure caused by fake base station Huawei, Hisilicon pCR Approval No
Yes
withdrawn Yes    
    S3‑183355 Key Issue on Spoofing UE paging messages Huawei, Hisilicon pCR Approval No
Yes
withdrawn Yes    
    S3‑183357 Solution for pretecting UE from HO to fake base station Huawei, Hisilicon pCR Approval Yes
Yes
withdrawn Yes    
    S3‑183358 Protecting UE from connnecting to fake basestation during HO Huawei, Hisilicon pCR Approval No
Yes
withdrawn Yes    
    S3‑183359 Aoviding unnecessary HO caused by fake base station Huawei, Hisilicon pCR Approval No
Yes
withdrawn Yes    
    S3‑183365 Solution for pretecting UE from HO to fake base station Huawei, Hisilicon pCR Approval No
Yes
withdrawn Yes    
    S3‑183799 Draft TR 33.809 Apple draft TR Approval Yes
Yes
approved No    
8.10 Study of KDF negotiation for 5G System Security S3‑183414 Scope for TR 33.808 KDF negotiation Huawei, Hisilicon pCR Approval Yes
Yes
approved No    
    S3‑183508 Key issue on Need for UE capability based KDF negotiation in 5GS NEC Corporation pCR Approval Yes
YesEricsson and ORANGE objected to the key issue. ORANGE was not comfortable with having the UE deciding the KDF. Ericsson: we study a need and this key issue assumes there is a need. Docomo, ORANGE and Qualcomm supported that the need should be studied first. Huawei: there are companies who are convinced that this is not needed, so we could just finish with a "this is not needed". It was agreed to have the following process: - Justify the need. - Study the solution.
noted No    
    S3‑183412 Key Issue on KDF negotiation between UE and AMF Huawei, Hisilicon pCR Approval Yes
YesDocomo: the security threats are not security related.
revised No S3‑183796  
    S3‑183796 Key Issue on KDF negotiation between UE and AMF Huawei, Hisilicon pCR Approval Yes
Yes
approved No   S3‑183412
    S3‑183512 Key Issue on Need for Bidding down protection NEC Corporation pCR Approval Yes
Yes
noted No    
    S3‑183413 Key Issue on Avoiding Bidding down attack on KDF negotiation Huawei, Hisilicon pCR Approval Yes
Yes
noted No    
    S3‑183510 Key Issue on Need for Flexible KDF negotiation NEC Corporation pCR Approval Yes
Yes
noted No    
    S3‑183792 Draft TR 33.808 Huawei draft TR Approval Yes
Yes
approved No    
8.11 Study on Security aspects of Enhancement of Network Slicing S3‑183333 Skeleton proposal for TR for Enhanced Network Slicing Nokia pCR Approval Yes
Yes
approved No    
    S3‑183334 eNet Slice TR content for scope Nokia pCR Approval Yes
Yes
approved No    
    S3‑183335 pCR to TR 33.813 content for references Nokia pCR Approval Yes
Yes
approved No    
    S3‑183336 pCR to TR33.813 content for definitions and abbreviations Nokia pCR Approval Yes
Yes
noted No    
    S3‑183337 pCR to TR 33.813 Adding key issue for Slice specific authentication Nokia pCR Approval Yes
YesBT: you can have a slice without secondary authentication. Ericsson: key issue details should refer to what SA2 is doing, we cannot ignore them.
revised No S3‑183808  
    S3‑183808 pCR to TR 33.813 Adding key issue for Slice specific authentication Nokia,Huawei pCR Approval Yes
Yes
approved No   S3‑183337
    S3‑183463 New KI on slice authentication Huawei, HiSilicon pCR Approval Yes
Yes
merged No S3‑183808  
    S3‑183531 A key issue: Security and privacy aspects related to Network Slice specific access authentication and authorization China Mobile pCR   Yes
Yes
approved No    
    S3‑183339 Key issue proposal for security aspects of enhanced support of network slices NEC Corporation pCR Approval Yes
YesHuawei: the two requirements address different key issues. Remove the second requirements. Nokia: what's UE protection? What's being protected? Eventually the requirements were removed. Ericsson: how is this done if the UE is always connected to one AMF? Huawei: there is a study where the UE is connected to multipleAMFs. ORANGE: slices with different security requirements are being mentioned, what does it mean? What are the different requirements you refer to?
noted No    
    S3‑183464 New KI on slice isolation Huawei, HiSilicon pCR Approval Yes
YesORANGE: in TR 33.899 we discussed this extensively, what's new in here?
noted No    
    S3‑183583 New key issue on key separation between Network Slices Ericsson pCR Approval Yes
YesThe requirement was decided to be split.
revised No S3‑183809  
    S3‑183809 New key issue on key separation between Network Slices Ericsson pCR Approval Yes
Yes
approved No   S3‑183583
    S3‑183461 New KI on security features for NSaaS Huawei, HiSilicon pCR Approval Yes
YesORANGE: the study is on the SA2 solutions not on SA5.
revised No S3‑183810  
    S3‑183810 New KI on security features for NSaaS Huawei, HiSilicon,China Mobile pCR Approval Yes
Yes
approved No   S3‑183461
    S3‑183530 A key issue on Slice-specific security features in NSaaS China Mobile pCR   Yes
YesORANGE: not in the scope of the study, not SA2 work.
merged No S3‑183810  
    S3‑183462 New KI on monitored security features Huawei, HiSilicon pCR Approval Yes
YesORANGE didn't agree with the key issue since a lot of this is happening outside the slice.
noted No    
    S3‑183465 New KI on NSSAI confidentiality Huawei, HiSilicon pCR Approval Yes
YesNokia: not part of the objectives or of the SA2 work. ORANGE: confidential from where to where? Huawei replied that Over The Air.ORANGE said that this is already cover in Rel-15 work. ORANGE: this depends on the Nokia solution that is being discussed in SA2. Intel supported this contribution.
noted No    
    S3‑183807 Draft TR 33.813 Nokia draft TR discussion No
Yes
approved No    
8.12 Study on Security of the enhancement to the 5GC location services S3‑183433 Draft skeleton for TR 33.814 CATT pCR Approval Yes
YesIt was noted that the template used was wrong, reusing one from another spec.
revised No S3‑183811  
    S3‑183811 Draft skeleton for TR 33.814 CATT pCR Approval Yes
Yes
approved No   S3‑183433
    S3‑183434 pCR to TR33.814 - Scope CATT pCR Approval Yes
Yes
revised No S3‑183744  
    S3‑183744 pCR to TR33.814 - Scope CATT pCR Approval Yes
Yes
approved No   S3‑183434
    S3‑183371 Scope of FS_eLCS_Sec China Unicom pCR   Yes
Yes
merged No S3‑183744  
    S3‑183372 key issue on protect distribution positioning assistance data China Unicom pCR   Yes
Yes
merged No S3‑183770  
    S3‑183403 Key issue for encryption protection of location data Huawei, Hisilicon pCR Approval Yes
Yes
revised No S3‑183770  
    S3‑183770 Key issue for encryption protection of location data Huawei, Hisilicon pCR Approval No
Yes
noted No   S3‑183403
    S3‑183404 Key issue for integrity protection of location and assistance data Huawei, Hisilicon pCR Approval Yes
Yes
revised No S3‑183771  
    S3‑183771 Key issue for integrity protection of location and assistance data Huawei, Hisilicon pCR Approval No
Yes
noted No   S3‑183404
    S3‑183435 pCR to TR33.814 - Key issue for ciphering key delivery CATT pCR