Tdoc List

2016-11-14 11:07

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‑161600 Agenda WG Chairman report   Yes
YesGuenther (Nokia) commented that Rel-14 for stage 2 has been finished. 5G topics are headed towards Rel-15 to be more precise.
 		revised No S3‑161963  
    S3‑161963 Agenda WG Chairman report - Yes
Yes
 		approved No   S3‑161600
3 IPR Reminder                      
4 Meeting Reports                      
4.1 Approval of the report from SA3#84 and SA3#84 bis S3‑161601 Report from SA3#84 MCC report   Yes
Yes
 		approved No    
    S3‑161602 Report from SA3 Adhoc NextGen MCC report   Yes
Yes
 		revised No S3‑161964  
    S3‑161964 Report from SA3 Adhoc NextGen MCC report - No
YesRevised to introduce the correct attendees of the meeting.
 		approved No   S3‑161602
4.2 Report from SA #73 S3‑161604 Report from last SA meeting WG Chairman report   Yes
Yes
 		noted No    
4.3 Report from SA3-LI                      
5 Items for early consideration                      
6.1 3GPP Working Groups S3‑161932 LS on eDRX Paging Hyper-frame and PTW_Start Calculation R2-165935 LS in   Yes
Yes
 		noted No    
    S3‑161943 LS on SeDoC related authentication procedure S2-165439 LS in   Yes
YesEricsson: it seems to me that it is a new authentication method for IMS although we have many of those already. CSI node is a trusted node. Guenther (Nokia): this looks like a new authentication method that does not clearly fit in the SA3 IMS spec.Not sure that we want that the security policy requires a re-authentication. It was noted that more time was needed to give a response.
 		replied to No    
    S3‑161965 Reply to: LS on SeDoC related authentication procedure Deutsche Telekom LS out approval No
Yes
 		left for email approval No    
6.2 IETF                      
6.3 ETSI SAGE                      
6.4 GSMA                      
6.5 3GPP2                      
6.6 OMA                      
6.7 TCG                      
6.8 oneM2M                      
6.9 TC-CYBER                      
6.10 ETSI NFV security                      
6.11 Other Groups S3‑161930 LS-Out to NFV on Target Location ETSI TC LI LS in   Yes
YesTarget's location cannot be derived in an NFV environment.
 		noted No    
7.1.1 Security Assurance Specification for 3GPP network product classes (General, TS 33.117) (SCAS-SA3) S3‑161638 Detailing clauses 4.2.1, 4.2.3.1 and 4.3.1 TELECOM ITALIA S.p.A. CR Approval Yes
Yes
 		revised No S3‑162049  
    S3‑162049 Detailing clauses 4.2.1, 4.2.3.1 and 4.3.1 TELECOM ITALIA S.p.A. CR Approval No
YesChanged the reference to the 800 series TR to the TS (since the 800 series cannot be referenced).
 		agreed No   S3‑161638
7.1.2 Security Assurance Specification for 3GPP network product classes (MME, TS 33.116) (SCAS-SA3)                      
7.1.3 Security Assurance Specification for PGW network product class (PGW, TS 33.250) (SCAS_PGW) S3‑161607 pCR adding the security requirements of minimized kernel network functions in the section 4.3.3.1.2 of TS33.250 CATR pCR   Yes
Yes
 		approved No    
    S3‑161609 Adding the security requirements of user plane traffic differentiation ZTE Corporation pCR Approval Yes
YesTIM: the desccription could be better described, otherwise it will be difficult to reproduce the test case. An editor's note was agreed to address this issue later. NEC: expected format of evidence TBD. Nokia had a problem with the requirement mentioning APNs. Is this coming from a SA2 spec? It was agreed to add an editor's note on the pending reference to SA2.
 		revised No S3‑162050  
    S3‑162050 Adding the security requirements of user plane traffic differentiation ZTE Corporation pCR Approval Yes
Yes
 		approved No   S3‑161609
    S3‑161634 Adding requirement on unpredictable Charging ID TELECOM ITALIA S.p.A. pCR Approval Yes
YesEricsson: the concept of unpredictable is not defined in the spec. This should be clarified. Huawei proposed to use "random" instead. TIM: bringing "random" causes certain issues that we want to avoid.
 		noted No    
    S3‑161635 Adding test case on the uniqueness of the Charging ID deriving from the 3GPP specifications TELECOM ITALIA S.p.A. pCR Approval Yes
Yes
 		revised No S3‑162051  
    S3‑162051 Adding test case on the uniqueness of the Charging ID deriving from the 3GPP specifications TELECOM ITALIA S.p.A. pCR Approval Yes
YesIt removes a pre-condition as proposed by Ericsson. DT:step two at least 10000 according to the current power of the processors.
 		approved No   S3‑161635
    S3‑161636 Adding requirement within 3GPP TR 33.250 on unpredictable TEID generated by the PGW and related test case. TELECOM ITALIA S.p.A. pCR Approval Yes
YesEricsson pointed out the unpredictability as previous contributions. Ericsson: we don’t have a threat. Should we write the requirement and then find the threat? Is this the process? TIM: start a threat analysis to find whether the requirement is correct. TIM will bring a description for the next time. This was noted.
 		noted No    
    S3‑161637 Adding requirement on the uniqueness of GTP TEID generated by the PGW and related test case. TELECOM ITALIA S.p.A. pCR Approval Yes
YesEricsson pointed out the TEID uniqueness issue and others that were already found in TIM's previous contributions.
 		revised No S3‑162052  
    S3‑162052 Adding requirement on the uniqueness of GTP TEID generated by the PGW and related test case. TELECOM ITALIA S.p.A. pCR Approval Yes
Yes
 		approved No   S3‑161637
    S3‑161765 pCR adding the introduction in the section 4.1 of TS33.250 China Mobile Com. Corporation, Huawei, ZTE, CATR pCR Approval Yes
Yes
 		revised No S3‑162053  
    S3‑162053 pCR adding the introduction in the section 4.1 of TS33.250 China Mobile Com. Corporation, Huawei, ZTE, CATR pCR Approval Yes
YesSome minor editorial changes pointed out by MCC.
 		approved No   S3‑161765
    S3‑161771 pCR adding the security requirements of traffic separation in the section 4.3.5 of TS33.250 China Mobile Com. Corporation, Huawei, ZTE, CATR pCR Approval Yes
YesNokia, DT and Telecom Italia suggested to change the requirement.
 		revised No S3‑162054  
    S3‑162054 pCR adding the security requirements of traffic separation in the section 4.3.5 of TS33.250 China Mobile Com. Corporation, Huawei, ZTE, CATR pCR Approval Yes
Yes
 		approved No   S3‑161771
    S3‑161773 pCR adding the security functional requirements on the PGW deriving from 3GPP specifications China Mobile Com. Corporation, Huawei, ZTE, CATR pCR Approval Yes
YesTIM:the requirement cannot be understood here. MCC reminded about adding references to the specs that are mentioned (23.401, 33.117 and so on).
 		revised No S3‑162055  
    S3‑162055 pCR adding the security functional requirements on the PGW deriving from 3GPP specifications China Mobile Com. Corporation, Huawei, ZTE, CATR pCR Approval No
Yes
 		Left for email approval No   S3‑161773
    S3‑161811 adding the security requirements of IP address reallocation interval Huawei; Hisilicon; China Mobile pCR   No
No
 		withdrawn Yes    
    S3‑161812 adding the security requirements of IP address reallocation interval Huawei; Hisilicon; China Mobile pCR   Yes
YesNoted without presentation. Huawei commented that a Threat analysis is needed.
 		noted No    
    S3‑161813 adding the security requirements of IP address reallocation interval Huawei; Hisilicon; China Mobile pCR   No
No
 		withdrawn Yes    
    S3‑161823 adding the security requirements of IP address reallocation interval Huawei; Hisilicon; China Mobile pCR   No
No
 		withdrawn Yes    
    S3‑161824 adding the security requirements of IP address reallocation interval Huawei; Hisilicon; China Mobile pCR   No
No
 		withdrawn Yes    
    S3‑161825 adding the security requirements of IP address reallocation interval Huawei; Hisilicon; China Mobile pCR   Yes
YesNoted without presentation. Huawei commented that a threat analysis is needed.
 		noted No    
    S3‑162056 TS 33.250 China Mobile draft TS Approval No
Yes
 		left for email approval No    
7.1.4 Security Assurance Specification for eNB network product class (eNB, TS 33.216) (SCAS_eNB) S3‑161904 Draft TS Skeleton for 33.216 Huawei Tech.(UK) Co., Ltd draft TS Approval Yes
Yes
 		approved No    
    S3‑161905 Scope of TS 33.216 Huawei Tech.(UK) Co., Ltd pCR Approval Yes
Yes
 		approved No    
    S3‑161906 Adding Reference to TS 33.216 Huawei Tech.(UK) Co., Ltd pCR Approval Yes
Yes
 		approved No    
    S3‑162057 TS 33.216 Huawei draft TS Approval Yes
Yes
 		approved No    
7.1.5 Other                      
7.2 New GPRS algorithms for EASE (EASE_ALGOs_SA3) S3‑161887 discussion document on Ease Algorithm specifications VODAFONE Group Plc discussion Discussion Yes
YesFrench government requires us to know who has the copies. ETSI must license the specifications. The algorithms content were seen by the SA3 group in a non-public area of the local server. The files were seen anyway back in the Mexico meeting. Vodafone noted that these files come from ETSI SAGE, not a company contribution from Vodafone. SA3 agreed with the procedure of going ahead with the redacted documents going to the Plenary.
 		noted No    
    S3‑161952 Draft TS 55.241 - Specification of the GIA4 integrity algorithm for GPRS - GIA4 specification - (Release 14) VODAFONE Group Plc draft TS Agreement Yes
YesMCC noted that it should be version 001 since it's an editorial change.
 		revised No S3‑162126  
    S3‑162126 Draft TS 55.241 - Specification of the GIA4 integrity algorithm for GPRS - GIA4 specification - (Release 14) VODAFONE Group Plc draft TS Agreement No
Yes
 		left for email approval No   S3‑161952
    S3‑161953 Draft TS 55.242 - Specification of the GIA4 integrity algorithm for GPRS - Implementers test data - (Release 14) VODAFONE Group Plc draft TS Agreement Yes
Yes
 		postponed No    
    S3‑161954 Draft TS 55.243 - Specification of the GIA4 integrity algorithm for GPRS - Design conformance test data - (Release 14) VODAFONE Group Plc draft TS Agreement Yes
Yes
 		postponed No    
    S3‑161955 TS 55.251 - Specification of the GEA5 encryption and GIA5 integrity algorithms for GPRS - GEA5 and GIA5 algorithm specification -(Release 14) VODAFONE Group Plc draft TS Agreement Yes
YesMCC noted that it should be version 001 since it's an editorial change. The information of where to find the algorithms will not be written in the spec, but in the ETSI website.
 		revised No S3‑162128  
    S3‑162128 TS 55.251 - Specification of the GEA5 encryption and GIA5 integrity algorithms for GPRS - GEA5 and GIA5 algorithm specification -(Release 14) VODAFONE Group Plc draft TS Agreement No
Yes
 		left for email approval No   S3‑161955
    S3‑161956 TS 55.252 - Specification of the GEA5 encryption and GIA5 integrity algorithms for GPRS - Implementers test data -(Release 14) VODAFONE Group Plc draft TS Agreement Yes
Yes
 		postponed No    
    S3‑161957 TS 55.253 - Specification of the GEA5 encryption and GIA5 integrity algorithms for GPRS - Design conformance test data - (Release 14) VODAFONE Group Plc draft TS Agreement Yes
Yes
 		postponed No    
    S3‑162127 Cover sheet for TS 55.241 Vodafone TS or TR cover Approval No
Yes
 		left for email approval No    
    S3‑162129 Cover sheet TS 55.251 Vodafone TS or TR cover Approval No
Yes
 		left for email approval No    
7.3 Battery Efficient Security for very low Throughput Machine Type Communication Devices (BEST_MTC_Sec) S3‑161622 Adding BEST Service to TS 33.401 KPN, Vodafone CR Agreement Yes
Yes
 		revised No S3‑161849  
    S3‑161849 Adding BEST Service to TS 33.401 KPN, Vodafone CR Agreement Yes
Yes
 		postponed No   S3‑161622
    S3‑161743 Allocation of FC values for BEST KPN, Vodafone CR Agreement Yes
Yes
 		postponed No    
7.4 Support of EAP Re-Authentication Protocol for WLAN Interworking (ERP) S3‑161642 Adding support of EAP Re-Authentication Protocol for WLAN Interworking (TWAN) ORANGE CR Agreement Yes
YesAlf: Lack of normative verbs: shalls and shoulds. Orange: This CR is for trusted access. Ericsson: are we to widen up to WLAN? Nokia: this is beyond the scope of our WID. Ericsson: Is this run by IKEv2?
 		revised No S3‑162020  
    S3‑162020 Adding support of EAP Re-Authentication Protocol for WLAN Interworking (TWAN) ORANGE, Broadcom, Ericsson CR Agreement Yes
Yes
 		agreed No   S3‑161642
7.5 Security of the Mission Critical Service (MCSec) S3‑161612 Skeleton of TS 33.180 CESG (NCSC) draft TS Approval Yes
Yes
 		approved No    
    S3‑161644 [MCX] Proposed Mapping of 33.179 into 33.180 CESG (NCSC) discussion Discussion Yes
Yes
 		noted No    
    S3‑161643 [MC_Sec] Baseline for 33.180 CESG (NCSC) draft TS Approval Yes
Yes
 		approved No    
    S3‑161645 [MC_Sec] Scope for 33.180 CESG (NCSC) pCR Approval Yes
Yes
 		approved No    
    S3‑161613 pCR 33.180 clause 3 Motorola Solutions Danmark A/S pCR Approval Yes
Yes
 		approved No    
    S3‑161617 pCR 33.180 pCR clause 5 Motorola Solutions Danmark A/S pCR Approval Yes
Yes
 		revised No S3‑161969  
    S3‑161969 pCR 33.180 pCR clause 5 Motorola Solutions Danmark A/S pCR Approval Yes
YesCESG was fine with the document but they wanted to send an LS to SA6 on the terminology.
 		approved No   S3‑161617
    S3‑161614 pCR 33.180 clause 6 Motorola Solutions Danmark A/S pCR Approval Yes
Yes
 		approved No    
    S3‑161615 pCR 33.180 Annex B Motorola Solutions Danmark A/S pCR Approval Yes
Yes
 		revised No S3‑162030  
    S3‑162030 pCR 33.180 Annex B Motorola Solutions Danmark A/S pCR Approval Yes
Yes
 		approved No   S3‑161615
    S3‑161616 pCR 33.180 Annex C Motorola Solutions Danmark A/S pCR Approval Yes
Yes
 		approved No    
    S3‑161646 [MC_Sec] Clean up of Clause 5.2 CESG (NCSC) pCR Approval No
No
 		withdrawn Yes    
    S3‑161996 TS 33.180 CESG draft TS Approval Yes
Yes
 		approved No    
    S3‑162082 Ls on terminology used y SA6 CESG LS out Approval Yes
Yes
 		approved No    
7.6.1 SAE/LTE Security S3‑161664 Privacy Protection for EAP-AKA and EAP-AKA’ Apple (UK) Limited discussion Discussion Yes
YesVodafone: we should think of other solutions. Apple: we are not changing the routing. Nokia commented that it was better to wait until we have other solutions since it would be strange to have different solutions for V2X and 5G for example. Vodafone: we may end up predetermining something in 5G because we used it in LTE. Apple: this is affecting an actual problem, there is some emergency. Vodafone: solutions exist, but no standard solutions exist, so there is no such emergency. It was decided to wait a bit and make a decision when V2X and 5G progress further. Qualcomm: IMSI privacy problem also exists when the UE connects in the cellular network. E.g. false base station attack.
 		noted No    
    S3‑161665 Privacy Protection for EAP-AKA and EAP-AKA’ Apple (UK) Limited CR Approval Yes
Yes
 		revised No S3‑161666  
    S3‑161666 Privacy Protection for EAP-AKA Apple (UK) Limited CR Approval Yes
Yes
 		not pursued No   S3‑161665
    S3‑161799 Correcting LWA-ID derivation mismatch Qualcomm Incorporated CR   Yes
Yes
 		agreed No    
    S3‑161891 Usage of Tuak Gemalto N.V. discussion Decision Yes
YesVodafone: current mechanisms allow to choose the algorithm to use. Gemalto: specify the values of the IMF to allow the algorithm seleciton. Vodafone: this is not within the scope of 3GPP, to choose what algorithms to use. Nokia agreed. Gemalto: why is this restriction here? Ericsson: Tuak doesn’t need to be mentioned. Gemalto: no objection to enable input key longer than 128 bits. Heiko (Morpho) commented that this is just a discussion document, we need to agree on the CRs that come afterwards. Nokia: no working agreement until we see the CRs.
 		noted No    
7.6.2 IP Multimedia Subsystem (IMS) Security                      
7.6.3 Network Domain Security (NDS) S3‑161907 3GPP security profile update – IPsec Ericsson discussion Discussion Yes
Yes
 		noted No    
    S3‑161908 3GPP security profile update – IPsec Ericsson CR Agreement Yes
YesMCC pointed out that redefining "support" for this spec was not appropiate since it is a well known term in standards language and changing its definition would lead to confusion and errors.
 		revised No S3‑162007  
    S3‑162007 3GPP security profile update – IPsec Ericsson CR Agreement Yes
Yes
 		agreed No   S3‑161908
    S3‑161918 3GPP security profile update - IPsec Ericsson CR Agreement Yes
Yes
 		revised No S3‑162008  
    S3‑162008 3GPP security profile update - IPsec Ericsson CR Agreement Yes
Yes
 		agreed No   S3‑161918
    S3‑161919 3GPP security profile update - IPsec Ericsson CR Agreement Yes
Yes
 		revised No S3‑162009  
    S3‑162009 3GPP security profile update - IPsec Ericsson CR Agreement Yes
Yes
 		agreed No   S3‑161919
    S3‑161909 3GPP security profile update – Certificates and CRLs Ericsson discussion Discussion Yes
Yes
 		noted No    
    S3‑161910 3GPP security profile update – Certificates and CRLs Ericsson CR Agreement Yes
Yes
 		revised No S3‑162010  
    S3‑162010 3GPP security profile update – Certificates and CRLs Ericsson CR Agreement Yes
Yes
 		agreed No   S3‑161910
    S3‑161911 3GPP security profile updates – TLS Ericsson discussion Discussion Yes
Yes
 		noted No    
    S3‑161912 3GPP security profile update – TLS Ericsson CR Agreement Yes
Yes
 		revised No S3‑162011  
    S3‑162011 3GPP security profile update – TLS Ericsson CR Agreement Yes
Yes
 		agreed No   S3‑161912
    S3‑161913 3GPP security profile updates – Remaining issues and new updates Ericsson discussion Discussion Yes
Yes
 		noted No    
    S3‑161914 3GPP security profile update – 33.220 Ericsson CR Agreement Yes
Yes
 		revised No S3‑162012  
    S3‑162012 3GPP security profile update – 33.220 Ericsson CR Agreement Yes
Yes
 		agreed No   S3‑161914
    S3‑161915 3GPP security profile update – 33.221 Ericsson CR Agreement Yes
Yes
 		revised No S3‑162013  
    S3‑162013 3GPP security profile update – 33.221 Ericsson CR Agreement Yes
Yes
 		agreed No   S3‑161915
    S3‑161916 3GPP security profile update – 33.234 Ericsson CR Agreement Yes
No
 		withdrawn Yes    
    S3‑161917 3GPP security profile update – 33.320 Ericsson CR Agreement Yes
Yes
 		revised No S3‑162014  
    S3‑162014 3GPP security profile update – 33.320 Ericsson CR Agreement Yes
Yes
 		agreed No   S3‑161917
    S3‑161948 3GPP security profile update – 43.318 Ericsson draftCR   Yes
Yes
 		revised No S3‑162015  
    S3‑162015 3GPP security profile update – 43.318 Ericsson draftCR - Yes
YesThis draftCR will be sent to RAN6 as endorsed by SA3 in a LS. CRs will be created in RAN6 with the same content and agreed at RAN6 level.
 		endorsed No   S3‑161948
    S3‑162016 LS on 3GPP security profile update Ericsson LS out Approval Yes
Yes
 		approved No    
7.6.4 UTRAN Network Access Security S3‑161925 LS on Legacy Security Issues C1-164579 LS in   Yes
YesPostponed due to the lack of contributions to give input in a response.
 		postponed No    
    S3‑161936 Response LS on Legacy Security Issues R6-160125 LS in   Yes
YesPostponed due to the lack of contributions to give input in a response.
 		postponed No    
7.6.5 GERAN Network Access Security                      
7.6.6 Generic Authentication Architecture (GAA)                      
7.6.7 Multimedia Broadcast/Multicast Service (MBMS) S3‑161928 LS response to SA4 on progress of FS_xMBMS study item C3-162236 LS in   Yes
Yes
 		noted No    
    S3‑161939 Response on LS on progress of FS_xMBMS study item S1-162535 LS in   Yes
Yes
 		noted No    
    S3‑161941 Response to LS S2-164299 from CT WG3 on progress of FS_xMBMS study item and to LS S2-164288 from SA WG4 also on progress of FS_xMBMS study item S2-165435 LS in   Yes
Yes
 		noted No    
7.6.8 Security Aspects of Home(e)NodeB (H(e)NB)                      
7.6.9 Security Aspects related to Machine-Type Communication ((e)MTC)                      
7.6.10 Security Aspects of Isolated E-UTRAN Operation for Public Safety (IOPS)                      
7.6.11 Security of MCPTT (MCPTT) S3‑161937 Reply LS on questions on discreet listening and recording for MCPTT S1-162264 LS in   Yes
YesCESG observed: Is this a problem for SA3-LI or SA3?
 		noted No    
    S3‑161946 Reply LS to SA3 on discreet listening and recording for MCPTT S6-161229 LS in   Yes
Yes
 		noted No    
    S3‑161926 LS on protection of RTCP transported media control messages, RTCP APP transported pre-established session control messages and MBMS subchannel control messages C1-164680 LS in   Yes
Yes
 		replied to No    
    S3‑161997 Reply to: LS on protection of RTCP transported media control messages, RTCP APP transported pre-established session control messages and MBMS subchannel control messages CESG LS out approval Yes
Yes
 		approved No    
    S3‑161653 [MCPTT] Clarifying the protection of media control within 33.179 CESG (NCSC) CR Agreement Yes
Yes
 		agreed No    
    S3‑161862 Discussion on the need and on the potential mechanisms for the protection of MBMS subchannel control messages Ericsson LM discussion Discussion Yes
Yes
 		noted No    
    S3‑161865 Protection of MBMS subchannel control messages Ericsson LM CR Agreement Yes
YesCESG didn't agree with having this for Rel-13. Ericsson commented that CT1 ias asking for this to be in Rel-13. MCC commented that Rel-13 is frozen and that Cat-B CRs are not allowed anymore, just corrections. It was commented that since this is a correction to be made to avoid a security vulnerability this can be considered as cat- F and hence acceptable in Rel-13. This was agreed by the group.
 		revised No S3‑161998  
    S3‑161998 Protection of MBMS subchannel control messages Ericsson LM CR Agreement Yes
Yes
 		agreed No   S3‑161865
    S3‑161786 Aligning XML encryption mechanism with CT WG agreements Samsung CR Agreement Yes
YesCESG would rather use a stage 2 text instead of referencing a stage 3 spec. Samsung agreed.
 		revised No S3‑161999  
    S3‑161999 Aligning XML encryption mechanism with CT WG agreements Samsung, Airbus DS SLC, Motorola Solutions, Nokia CR Agreement Yes
Yes
 		agreed No   S3‑161786
    S3‑161792 Aligning XML Integrity protection mechanism with CT WG agreements Samsung CR Agreement Yes
YesAirbus preferred not to have a reference to a stage 3 spec, and asked for some stage 2 wording instead.
 		revised No S3‑162000  
    S3‑162000 Aligning XML Integrity protection mechanism with CT WG agreements Samsung , Airbus DS SLC, CESG (NCSC), Nokia CR Agreement Yes
Yes
 		agreed No   S3‑161792
    S3‑161652 Clarification on the use of MKFC CESG (NCSC) CR Agreement Yes
Yes
 		agreed No    
    S3‑161861 Correction of TS 33.220 references Samsung CR Agreement Yes
Yes
 		agreed No    
7.6.12 Security for Enhancements to Proximity-based Services - Extensions (eProSe-Ext-SA3)                      
7.6.13 Enhanced Access Security for Extended Coverage GSM in relation to Cellular IoT (EASE_EC_GSM) S3‑161722 Alignment with stage 3 implementation of GPRS integrity protection Intel Corporation (UK) Ltd CR Approval Yes
Yes
 		merged No S3‑162085  
    S3‑161724 Alignment with stage 3 implementation of GPRS integrity protection Intel Corporation (UK) Ltd CR Approval Yes
Yes
 		merged No S3‑162084  
    S3‑161901 Clarification related to the LLC acknowledge mode Ericsson LM CR Agreement Yes
Yes
 		revised No S3‑162084  
    S3‑162084 Clarification related to the LLC acknowledge mode Ericsson LM CR Agreement Yes
Yes
 		agreed No   S3‑161901
    S3‑161902 Clarification related to the LLC acknowledge mode Ericsson LM CR Approval Yes
Yes
 		revised No S3‑162085  
    S3‑162085 Clarification related to the LLC acknowledge mode Ericsson LM CR Approval Yes
Yes
 		agreed No   S3‑161902
    S3‑161927 LS on LLC updates for EC-GSM-IOT enhanced security C1-164853 LS in   Yes
Yes
 		replied to No    
    S3‑162086 Reply to: LS on LLC updates for EC-GSM-IOT enhanced security Ericsson LS out approval Yes
Yes
 		approved No    
7.6.14 Security Aspects of Narrowband IOT (CIoT) S3‑161654 draft_CR to 33.401 Correct Reference to NAS Spec in 8.2 Nokia CR   Yes
Yes
 		revised No S3‑162090  
    S3‑162090 draft_CR to 33.401 Correct Reference to NAS Spec in 8.2 Nokia CR - Yes
Yes
 		agreed No   S3‑161654
    S3‑161655 draft_reply LS to R2-167293 using S-TMSI in RAN Paging Nokia LS out Approval Yes
YesNTT-Docomo: is this the same as regular paging? Now it's using the IMSI.
 		noted No    
    S3‑161656 draft_reply LS to R2-167296 RRC Connection Re-Establishment for NB-IoT (DoNAS) Nokia LS out Approval Yes
Yes
 		noted No    
    S3‑161657 draft_ Reply LS to R3-162642 on Light Connection Nokia LS out Approval Yes
Yes
 		revised No S3‑162087  
    S3‑162087 Reply LS to R3-162642 on Light Connection Nokia, Intel LS out Approval Yes
YesDeutsche Telekom: the message from SA3 is replay protection for the message coming from the eNodeB. No need to go into details. This was taken offline.
 		approved No   S3‑161657
    S3‑161717 Security of RRC Connection re-establishment of NB-IOT for CP Solution Intel Corporation (UK) Ltd discussion Discussion Yes
YesEricsson: the token is only used in the uplink. If the downlink is not integrity protected the UE would not know if it is attached to the eNodeB or not. I welcome opinions on this better than discussing the threat.
 		revised No S3‑162089  
    S3‑162089 Security of RRC Connection re-establishment of NB-IOT for CP Solution Intel Corporation (UK) Ltd discussion Discussion No
Yes
 		noted No   S3‑161717
    S3‑161720 Discussion on RAN2 LS pertaining to Light Connection Intel Corporation (UK) Ltd discussion Discussion Yes
Yes
 		noted No    
    S3‑161879 draft reply-LS on S-TMSI in RAN paging Ericsson LS out   Yes
YesDeutsche Telekom: I don’t understand the issue of using the S-TMSI. NTT-Docomo: If S-TMSI is used for RAN paging would it limit the number of re-allocations? I don’t understand the paging mechanism. Nokia: we need to agree on whether there is a risk when using S-TMSI. Deutsche Telekom: our ability to update the S-TMSI frequently would be limited according to the second bullet. Nokia: there is an opportunity of changing the S-TMSI when the RAN paging is successful and it results in a NAS connection, the updated wouldn't be so limited. Alf (NTT Docomo): where is this described? It looked like companies needed to study more the background of this. This was taken offline.
 		noted No    
    S3‑161920 RLF for CP NB-IoT Ericsson discussion   Yes
Yes
 		noted No    
    S3‑161933 LS on S-TMSI in RAN paging R2-167293 LS in   Yes
Yes
 		replied to No    
    S3‑162123 Reply to: LS on S-TMSI in RAN paging Ericsson LS out approval Yes
Yes
 		approved No    
    S3‑161934 Security aspects of RRC Connection Re-Establishment for NB-IoT (DoNAS) R2-167296 LS in   Yes
Yes
 		replied to No    
    S3‑162088 Reply to: Security aspects of RRC Connection Re-Establishment for NB-IoT (DoNAS) Intel LS out approval Yes
Yes
 		approved No    
    S3‑161935 LS on Light connection R3-162642 LS in   Yes
Yes
 		replied to No    
7.6.15 Other work items S3‑161922 LS on I-WLAN specification referencing within CT6 C6-160408 LS in   Yes
YesLG commented that SA3 should send CRs for CT6 to check. The references are for Rel-12, not Rel-13. It was confirmed that Rel-12 for I-WLAN will stay, rel-13 was withdrawn. Heiko commented that the only solution found in CT6 was to refer to the Rel-12 version. If SA3 moves things to 33.402 CT6 needs to take this into account to refer to this spec.
 		replied to No    
    S3‑162017 Reply to: LS on I-WLAN specification referencing within CT6 Ericsson LS out approval Yes
Yes
 		approved No    
    S3‑161940 Reply LS on I-WLAN handling and specification withdrawal S2-165026 LS in   Yes
Yes
 		noted No    
    S3‑161876 I-WLAN specification withdrawal Ericsson discussion   Yes
Yes
 		noted No    
    S3‑161878 Alignment according to withdrawal of I-WLAN feature Ericsson CR   Yes
YesIt was commented that it is an exception to refer to a specific Release of a spec, in the context of I-WLAN. Normally the latest Release available or the same release as the the current one. It was also pointed out that this is a Cat C CR for Rel-13 and this would be an exception as well.
 		revised No S3‑162018  
    S3‑162018 Alignment according to withdrawal of I-WLAN feature Ericsson CR - Yes
Yes
 		agreed No   S3‑161878
    S3‑161885 Alignment according to withdrawal of I-WLAN feature Ericsson CR   Yes
Yes
 		revised No S3‑162021  
    S3‑162021 Alignment according to withdrawal of I-WLAN feature Ericsson CR - Yes
Yes
 		agreed No   S3‑161885
    S3‑161882 Alignment according to withdrawal of I-WLAN feature Ericsson draftCR   Yes
Yesthe CR will be brought into RAN6.
 		endorsed No    
    S3‑161883 Alignment according to withdrawal of I-WLAN feature Ericsson draftCR   Yes
Yes
 		endorsed No    
    S3‑161892 Unauthenticated Emergency services over TWAN Nokia CR Agreement Yes
Yes
 		revised No S3‑162091  
    S3‑162091 Unauthenticated Emergency services over trusted WLAN Nokia CR Agreement Yes
YesSome changes proposed by Ericsson.
 		agreed No   S3‑161892
    S3‑161895 Unauthenticated Emergency services over untrusted WLAN Nokia CR Agreement Yes
Yes
 		revised No S3‑162092  
    S3‑162092 Unauthenticated Emergency services over untrusted WLAN Nokia CR Agreement Yes
Yes
 		agreed No   S3‑161895
    S3‑161898 KDF for Unauthenticated emergency services over WLAN Nokia CR Agreement Yes
Yes
 		agreed No    
8.1 Study on Security for Proximity-based Services (FS_ProSe_Sec) S3‑161860 Solution against spatial replay attacks based on a new coordinate grid Ericsson LM pCR Approval Yes
YesThis will go to a living document, then its content eventually transferred to the TR.
 		revised No S3‑162093  
    S3‑162093 Solution against spatial replay attacks based on a new coordinate grid Ericsson LM other Endorsement Yes
YesLiving document.
 		endorsed No   S3‑161860
    S3‑161921 Update of TR 33.833 after review by EditHelp Qualcomm Incorporated pCR Approval Yes
YesThe TR will be sent for approval in SA#75.
 		approved No    
    S3‑162094 TR 33.833 Qualcomm draft TR Approval No
Yes
 		left for email approval No    
    S3‑162095 Cover sheet 33.833 Qualcomm TS or TR cover Approval No
Yes
 		left for email approval No    
8.2 TR on Security Assurance scheme for 3GPP network products (33.916) (SCAS-SA3TR)                      
8.3 Study on EGPRS Access Security Enhancements with relation to cellular IoT (FS_EASE_IoT)                      
8.4 Study on IMS Enhanced Spoofed Call Prevention and Detection (FS_ESCAPADES)                      
8.5 Study on security aspects for LTE support of V2X services (FS_V2XLTE) S3‑161766 New WID on security aspect of architecture enhancements for LTE support of V2X services Huawei, HiSilicon WID new   Yes
YesNormative work for V2X piggybacked in the SA2 WID proposal. It was commented that deadline for Rel-14 was March 2017, although the spec would be approved by June 2017 (Rel 15 dates). The dates were to be seen later. Nokia: reformulate the objectives. Nokia supports this WID as well.
 		revised No S3‑162058  
    S3‑162058 New WID on security aspect of architecture enhancements for LTE support of V2X services Huawei, HiSilicon WID new - Yes
Yes
 		agreed No   S3‑161766
    S3‑161760 V2X security architecture based on the new security elements Huawei, Hisilicon pCR   Yes
YesEricsson: you are proposing a solution here, but I'm fine with it if you move it to the right place of the spec. Nokia: is this aligned with sA2? Huawei: if they agree on this solution they will have to go for this one.
 		revised No S3‑162059  
    S3‑162059 V2X security architecture based on the new security elements Huawei, Hisilicon pCR - Yes
Yes
 		approved No   S3‑161760
    S3‑161938 Reply LS on Clarification to privacy requirements S1-162531 LS in   Yes
Yes
 		noted No    
    S3‑161829 Update on V2X UE Privacy key issue Nokia pCR Approval Yes
YesMCC pointed out that it is not possible to refer to 3GPP working groups inside the specifications. This was changed. The last editor's note was removed.
 		revised No S3‑162060  
    S3‑162060 Update on V2X UE Privacy key issue Nokia pCR Approval Yes
Yes
 		approved No   S3‑161829
    S3‑161830 Privacy solution Nokia pCR Approval Yes
YesEricsson: this is not very specific. I would like to see here where to support LI requirements. Alex (BT): put a note saying that LI is not supported in the PLMN. This was agreed. Qualcomm: it is not working for the home network case when roaming. It was agreed to add an editor's note addressing this comment.
 		revised No S3‑162061  
    S3‑162061 Privacy solution Nokia pCR Approval Yes
Yes
 		approved No   S3‑161830
    S3‑161831 V2X Annex on privacy by regulation EU Nokia pCR Approval Yes
Yes831 and 832 were presented in SA3#84, but people required time to learn about regulations. Ericsson: include a reference to the report on UE regulation on the user information consent. LG: there can be other regulations rather than the EU. Alex (BT): privacy regulations are written on people and not physical devices. I agree with this going in for reference but remember that applying anything to physical assets will affect LI requirements.
 		revised No S3‑162062  
    S3‑162062 V2X Annex on privacy by regulation EU Nokia pCR Approval Yes
Yes
 		approved No   S3‑161831
    S3‑161832 V2X Annex on privacy by regulation US Nokia pCR Approval Yes
YesAlex (BT): this refers to a report whereas 831 refers to hard regulation, so 831 and 832 cannot be treated equally.This is guidance expecting to become regulation. It was confirmed that there is work on this going for regulation. A note on this was added.
 		revised No S3‑162063  
    S3‑162063 V2X Annex on privacy by regulation US Nokia pCR Approval Yes
Yes
 		approved No   S3‑161832
    S3‑161845 Discussion on the UE tracking threat with V2V/V2I communication Ericsson LM discussion Endorsement Yes
YesIt was proposed to add this discussion into the TR. This was agreed.
 		endorsed No    
    S3‑161846 Solution against UE tracking based on PC5 autonomous mode Ericsson LM pCR Approval Yes
YesNokia: Are there still discussions in SA2 about this? Ericsson: this is already specified. How to pre-provision these parameters is an open aspect that could be noted in an editor's note.
 		revised No S3‑162064  
    S3‑162064 Solution against UE tracking based on PC5 autonomous mode Ericsson LM pCR Approval Yes
Yes
 		approved No   S3‑161846
    S3‑161848 Solution for V-UE pseudonymity based on a V2X MVNO Ericsson LM pCR Approval Yes
YesAlex (BT): add a note on the LI issues in here. This note was agreed. Qualcomm: roaming case brings privacy issues. An editor's note was agreed.
 		revised No S3‑162065  
    S3‑162065 Solution for V-UE pseudonymity based on a V2X MVNO Ericsson LM pCR Approval Yes
Yes
 		approved No   S3‑161848
    S3‑161751 A Vehicle UE Privacy Protection Framework with Homomorphic Encryption Huawei, HiSilicon pCR   Yes
YesHuawei clarified that this works for a single operator network. Ericsson: not clear the use case for the homomorphic encryption. An editor's note was inserted for further clarification of this. Alex (BT): an editor's note on how this solution would support LI in the HPLMN is for further study. CESG: fallback case is needed when re-provisioning is required. Editor's note added for this.
 		revised No S3‑162066  
    S3‑162066 A Vehicle UE Privacy Protection Framework with Homomorphic Encryption Huawei, HiSilicon pCR - Yes
Yes
 		approved No   S3‑161751
    S3‑161814 Enhancements to solution 6.9 on encrypting IMSI to provide privacy from the serving network Qualcomm Incorporated pCR Approval Yes
YesCESG: fallback step as in 2066. Ericsson: not sure about encrypting the Avs. This addresses a very rare case. Alex (BT): this is not practical. Not clear how the triggering in the serving network works. It looks like the home network is telling the serving network what to intercept. I suggest that Qualcomm presents this in LI for evaluation. Ericsson: strong requirements from SA1 on privacy are confronted against strong requirements from SA3-LI here. Alex(BT): there is not contradiction. The LI issue applies to communications not to the UE .Requirement on using V2X subscription on anything other than safe messages. Nokia proposed to add text on the evaluation and this was agreed. The document was taken for offline discussions.
 		revised No S3‑162067  
    S3‑162067 Enhancements to solution 6.9 on encrypting IMSI to provide privacy from the serving network Qualcomm Incorporated pCR Approval Yes
Yes
 		approved No   S3‑161814
    S3‑161796 Clarification of V2X UE source IP address for TS 23.285 LG Electronics France discussion Discussion Yes
YesEricsson: it's too early for sending the LS since we don’t know what solutions we find at the application layer. Ericsson: the IP addresses may not be changed but randomised. It was also agreed that all identifiers need to be changes at the same time. It was agreed to send the LS to SA2.
 		noted No    
    S3‑161798 Draft LS on V2X UE IP address change LG Electronics France LS out Approval Yes
Yes
 		revised No S3‑162068  
    S3‑162068 LS on V2X UE IP address change LG Electronics France LS out Approval Yes
Yes
 		approved No   S3‑161798
    S3‑161820 Adding details to the reattach procedure in solution 6.5 Qualcomm Incorporated pCR Approval Yes
YesEricsson: not reasonable. Every 5 min we re-attach, and it's very bad for user experience (it interrupts services). Qualcomm: this is used only for V2X, it won’t interrupt other services. It's not worth sacrifying privacy over safety. Ericsson: no need to re-attach when off-coverage. It was agreed to have an editor's note with more details on this issue. Alex(BT): consider randomization on the timers on lower density scenarios, it may work better. Huawei: if the car is on the highway the randomization is not enough, it is still predictable. MCC proposed to remove the reference to "RAN2 agreements" since this should be a reference to a spec and not a working group. This was moved to an editor's note.
 		revised No S3‑162069  
    S3‑162069 Adding details to the reattach procedure in solution 6.5 Qualcomm Incorporated pCR Approval Yes
Yes
 		approved No   S3‑161820
    S3‑161821 LS on eNB-specific reattach boundary time for V2X UEs using Uu mode Qualcomm Incorporated LS out Approval Yes
YesEricsson: this is very solution specific. Orange and Nokia agreed with Ericsson. LG agreed to send an LS with this content.
 		noted No    
    S3‑161779 Solution for UE Security Credential Provisioning and Tracing with Identity based Cryptography Huawei, Hisilicon pCR   Yes
YesLG: how to do certificate revocation is FFS. This should be added in an editor's note. Huawei: this exists already in other clauses, we can take it from there.
 		revised No S3‑162070  
    S3‑162070 Solution for UE Security Credential Provisioning and Tracing with Identity based Cryptography Huawei, Hisilicon pCR - Yes
Yes
 		approved No   S3‑161779
    S3‑161754 Alternative security procedure for data transfer between UE and V2X Control Function Huawei, Hisilicon pCR   Yes
YesQualcomm: how tdoes he solution work when you are not connected to the 3GPP network? An editor's note was added for this. Another editor's note on GBA was added.
 		revised No S3‑162071  
    S3‑162071 Alternative security procedure for data transfer between UE and V2X Control Function Huawei, Hisilicon pCR - Yes
Yes
 		approved No   S3‑161754
    S3‑161828 V2X security between V2X AS and LTE network Nokia pCR Approval Yes
Yes
 		approved No    
    S3‑161822 Including V2X AS as instantiation of GCS AS Nokia CR Agreement Yes
Yes
 		agreed No    
    S3‑161767 Optimized certificate-based security solution for PC5 LTE-V2X communication Huawei, HiSilicon pCR   Yes
YesQualcomm didn’t agree with this contribution since some of the issues were not correct. Nokia agreed.
 		noted No    
    S3‑161756 correction of the text in the clause 6.1.1.1.2.1 Huawei, Hisilicon pCR   Yes
Yes
 		approved No    
    S3‑161758 The format definition of PDCP layer based on existing solutions for protecting the broadcast messages on PC5 interface. Huawei, Hisilicon pCR   Yes
YesHuawei: not a new solution, this is using PDCP. Qualcomm: not good to say that 3GPP doesn’t like what is done in other SDOs (ETSI ITS and others) and create a disruptive solution.
 		approved No    
    S3‑161762 Authorization procedure for V-UE acquiring radio resource from eNB Huawei, Hisilicon pCR   Yes
YesEricsson: this is not needed, the UE is already authenticated. Qualcomm agreed. Nokia: impact on the existing existing eNodeB specification needs to be evaluated.
 		noted No    
    S3‑161850 Split of solution #7 for authorization and accountability Ericsson LM pCR Approval Yes
Yes
 		approved No    
    S3‑161764 addition of recommendation section Huawei, HiSilicon pCR   Yes
YesQualcomm: the solution is complete, it's already definded by another SDOs since 10 years ago. Ericsson: are we doing evaluation on solutions in this part? This should be in the evaluation clause, this looks like you are doing an evaluation of the solutions in the TR. Nokia: we have open issues, it's still early for this. Alex (BT) objected to this contribution.
 		noted No    
    S3‑161815 Conclusion of V2X communication security Qualcomm Incorporated pCR Approval Yes
YesEricsson commented that the conclusion was too early. Nokia proposed to have this conclusion as an intermediate agreement. We agree on some principles but we are not excluding anything.
 		revised No S3‑162072  
    S3‑162072 Conclusion of V2X communication security Qualcomm Incorporated pCR Approval Yes
Yes
 		approved No   S3‑161815
    S3‑161816 Conclusion of the V3 interface security Qualcomm Incorporated pCR Approval Yes
YesAdding the interim agreement.
 		revised No S3‑162073  
    S3‑162073 Conclusion of the V3 interface security Qualcomm Incorporated pCR Approval Yes
Yes
 		approved No   S3‑161816
    S3‑161817 Conclusion on security of the interfaces between network entities for V2X Qualcomm Incorporated pCR Approval Yes
Yes
 		revised No S3‑162074  
    S3‑162074 Conclusion on security of the interfaces between network entities for V2X Qualcomm Incorporated pCR Approval Yes
YesAdding the interim agreement.
 		approved No   S3‑161817
    S3‑161818 Update and conclusion on solution 6.6 on UE privacy due to data traversing the network Qualcomm Incorporated pCR Approval Yes
YesEricsson: there is no conclusion on privacy yet.This was taken out.
 		revised No S3‑162075  
    S3‑162075 Update and conclusion on solution 6.6 on UE privacy due to data traversing the network Qualcomm Incorporated pCR Approval Yes
Yes
 		approved No   S3‑161818
    S3‑161819 Conclusion on UE privacy from the MNO for V2X Qualcomm Incorporated pCR Approval Yes
YesEricsson: still too many open issues. BT objected to the contribution too.
 		noted No    
    S3‑161960 Comments by Nokia on V2X privacy conclusion of S3-161819 Nokia pCR Approval Yes
YesBT didn’t agree with this editor's note.
 		noted No    
    S3‑161962 Discussion on V2V communication data confidentiality LG Electronics France pCR Approval Yes
Yes
 		merged No S3‑162072 S3‑161801
    S3‑161749 A Vehicle UE Privacy Protection Framework with Homomorphic Encryption Huawei, HiSilicon pCR   No
No
 		withdrawn Yes    
    S3‑161752 A Vehicle UE Privacy Protection Framework with Homomorphic Encryption Huawei, HiSilicon pCR   No
No
 		withdrawn Yes    
    S3‑161780 Solution for UE Security Credential Provisioning and Tracing with Identity based Cryptography Huawei, Hisilicon pCR   No
No
 		withdrawn Yes    
    S3‑161801 Discussion on V2V communication data confidentiality LG Electronics France pCR Approval Yes
Yes
 		revised No S3‑161962  
    S3‑162077 TR 33.885 Huawei draft TR Approval No
YesIt was agreed to send it for information.
 		left for email approval No    
    S3‑162078 Cover sheet TR 33.885 Huawei TS or TR cover Approval No
Yes
 		left for email approval No    
8.6.1 Security architecture S3‑161873 SA3 decisions on security architecture needed by SA2 Nokia discussion   Yes
YesThe content was to be included in an LS to SA2 to be drafted by Nokia. Every point of this paper was presented to see if it could be included in the LS. Some companies had contributions that touched some of the points so their agreement had to go through those papers first (for example co-locating SEAF and SCMF was still controversial).
 		revised No S3‑162047  
    S3‑162047 SA3 decisions on security architecture needed by SA2 Nokia discussion - No
Yes
 		noted No   S3‑161873
    S3‑161826 Termination point for user plane security Ericsson LM pCR Approval Yes
YesTim commented that UP gateway is for network end. The editor's note is confusing. Huawei didn’t agree with the editor's note either. Architectural questions are to be solved in the TS architectural work. Nokia agreed with the intention of the editor's note, the questions were valid for them. It was commented that a clarification of the requirements were needed here.
 		revised No S3‑161970  
    S3‑161970 Termination point for user plane security Ericsson LM pCR Approval Yes
Yes
 		noted No   S3‑161826
    S3‑161675 Add details, threads and requirements to key issue #1.5 on security of NAS signallings before security activation Huawei, Hisilicon pCR   Yes
Yes
 		approved No    
    S3‑161706 Resolving ENs in key issue #1.15 Termination point of UP security Huawei, HiSilicon pCR   Yes
YesEricsson: moving the termination point from the access network to the core network is an architecture issue that should be consulted with SA2. Deutsche Telekom: all we care about is whether it is in the base station or not. It doesn't matter if it is the access or the core network. Double encryption was a waste of resources in LTE. Stefan agreed with these changes. Florin (Broadcom) commented that deeper encryption for access is all right. Nokia wanted the editor's note in 5.1.3.15.3 to stay since this was a huge decision that needs to be done by SA3. Ericsson agreed. This editor's note stayed since many companies supported it. Broadcom discussed offline with Huawei the heterogeneous access termination point since they didn't fully agree with it.
 		revised No S3‑161971  
    S3‑161971 Resolving ENs in key issue #1.15 Termination point of UP security Huawei, HiSilicon pCR - Yes
Yes
 		approved No   S3‑161706
    S3‑161709 Resolving the Editor’s notes in Key Issue#1.16 Huawei, Hisilicon pCR   Yes
YesOrange didn’t agree with the second editor's note. Huawei: the definition for flow exists in the SA2 TR. Orange: it doesn’t, it's not precise. Nokia: there is room for clarifications in the SA2 TR, we should keep the second editor's note. It was agreed to keep the second editor's note.
 		revised No S3‑161972  
    S3‑161972 Resolving the Editor’s notes in Key Issue#1.16 Huawei, Hisilicon pCR - Yes
Yes
 		approved No   S3‑161709
    S3‑161678 Flexible security policies negotiation in control plane Huawei, HiSilicon pCR   Yes
YesAlf: (NTT Docomo): delete references to quantum computing. Orange: UE aspects should be brought overall in this document. It was agreed to add an editor's note on this.
 		revised No S3‑161973  
    S3‑161973 Flexible security policies negotiation in control plane Huawei, HiSilicon pCR - Yes
Yes
 		approved No   S3‑161678
    S3‑161747 pCR to TR 33.899, radio interface user plane integrity, evaluation VODAFONE Group Plc pCR Approval Yes
Yes
 		revised No S3‑161974  
    S3‑161974 pCR to TR 33.899, radio interface user plane integrity, evaluation VODAFONE Group Plc pCR Approval Yes
YesAddressing Nokia's and NTT-Docomo's comments.
 		approved No   S3‑161747
    S3‑161750 pCR to TR 33.899, radio interface user plane encryption, evaluation VODAFONE Group Plc pCR Approval Yes
YesDiscussed with 667.
 		approved No    
    S3‑161667 Clarification on Solution#1.1 and #1.3 Huawei, Hisilicon pCR   Yes
Yes
 		revised No S3‑161975  
    S3‑161975 Clarification on Solution#1.1 and #1.3 Huawei, Hisilicon pCR - Yes
Yes
 		approved No   S3‑161667
    S3‑161748 pCR to TR 33.899, periodic local authentication and packet count check, evaluation VODAFONE Group Plc pCR Approval Yes
Yes
 		revised No S3‑161976  
    S3‑161976 pCR to TR 33.899, periodic local authentication and packet count check, evaluation VODAFONE Group Plc pCR Approval Yes
Yes
 		approved No   S3‑161748
    S3‑161632 pCR to TR 33.899: Update of a solution #1.4 on key hierarchy for 5G security NEC EUROPE LTD pCR Approval Yes
YesNokia: we need to keep open the editors note on RAN slicing if they are still discussing it. Oberthur didn’t agree with removing the last editor's note (RAN network slicing). First editor's note gets extended, third one comes back. The fourth editor's note had to be taken offline.
 		revised No S3‑161977  
    S3‑161977 pCR to TR 33.899: Update of a solution #1.4 on key hierarchy for 5G security NEC EUROPE LTD pCR Approval Yes
Yes
 		approved No   S3‑161632
    S3‑161728 Alternative architecture for storage of a key in the HMPLN when the NG-UE is roaming Qualcomm Incorporated pCR Approval Yes
Yes
 		revised No S3‑161978  
    S3‑161978 Alternative architecture for storage of a key in the HMPLN when the NG-UE is roaming Qualcomm Incorporated pCR Approval Yes
YesEricsson needed some clarification on the new key hierarchy figure.
 		approved No   S3‑161728
    S3‑161735 pCR update of solution # 1.6 to include more details on the roaming scenario Qualcomm Incorporated pCR Approval Yes
Yes
 		revised No S3‑161979  
    S3‑161979 pCR update of solution # 1.6 to include more details on the roaming scenario Qualcomm Incorporated pCR Approval Yes
YesCooperation with SA2 and RAN will be needed. Added in an editor's note.
 		approved No   S3‑161735
    S3‑161631 pCR to TR 33 899 Updated Solution 1.8 Key hierarchy for NextGen NEC EUROPE LTD pCR Approval Yes
YesNokia: keep the second editor's note (end of document). NEC agreed. Changes in the table as proposed by Morpho. Isolation aspect was taken offline.
 		revised No S3‑161980  
    S3‑161980 pCR to TR 33 899 Updated Solution 1.8 Key hierarchy for NextGen NEC EUROPE LTD pCR Approval Yes
Yes
 		approved No   S3‑161631
    S3‑161702 Terminologies update and modification on key hierarchy in solution #1.9 Huawei, HiSilicon pCR   Yes
YesOrange: This is contradicting Doc 1873 agreed in proposal 2. Nokia:it's not clear if this figure refers to the roaming case or not. Ericsson commented that Huawei argues that the ARPF could be in the third party network. Heiko: third party ARPF has same functionality as the normal ARPF? Does it have the same interface or we have to define a new one? Nokia: ARPF can be in the third party session by definition. NEC: where is the SCMF in the figures? There was no answer to this, so it was taken offline. Afterwards, the figure were changed and the text accordingly.
 		revised No S3‑161981  
    S3‑161981 Terminologies update and modification on key hierarchy in solution #1.9 Huawei, HiSilicon pCR - Yes
Yes
 		approved No   S3‑161702
    S3‑161674 Security of NAS signallings before security activation Huawei, HiSilicon pCR   Yes
Yes
 		approved No    
    S3‑161870 Single termination point for NAS security Nokia pCR   Yes
YesVodafone: SA2 hasn't gone too far with this yet. Nokia: if SA2 goes forward with this solution, this is SA3 input. Qualcomm: additional security aspects in the evaluation part (e.g. moving Ues). Huawei: sliced security isolation for FFS. Editor's notes were agreed to address these comments.
 		revised No S3‑161982  
    S3‑161982 Single termination point for NAS security Nokia pCR - Yes
Yes
 		approved No   S3‑161870
    S3‑161769 pCR to TR33.899 - Solutions for Low Latency Security Issues VODAFONE Group Plc pCR Approval Yes
YesInterdigital: secure component is hardware or software..? Vodafone: it's irrelevant to the solution. An editor's note was agreed to be added.
 		revised No S3‑161983  
    S3‑161983 pCR to TR33.899 - Solutions for Low Latency Security Issues VODAFONE Group Plc pCR Approval Yes
Yes
 		approved No   S3‑161769
    S3‑161761 pCR to TR33.899, Use of a Non removable USIM for all UE security VODAFONE Group Plc pCR Approval Yes
YesMCC comented that the USIM should be called "NextGen" to be aligned with the rest of the spec TR 33.899, and better start using the term "5G" for future work. Deutsche Telekom: the solution is incomplete. An editor's note was added about identity. Gemalto: mention quantum safe cryptography. Qualcomm pointed out that it is referencing an ETSI SCP draft document, not formally approved. This should be taken into account in the reference. Nokia: what is 5G NR USIM? Vodafone: we will use NextGen USIM. These issues were addressed offline in the revision.
 		revised No S3‑161984  
    S3‑161984 pCR to TR33.899, Use of a Non removable USIM for all UE security VODAFONE Group Plc pCR Approval Yes
Yes
 		approved No   S3‑161761
    S3‑161679 A solution for KDF negotiation between UE and ARPF Huawei, HiSilicon pCR   Yes
Yes
 		noted No    
    S3‑161633 pCR to TR 33 899 Attach procedure for NextGen NEC EUROPE LTD pCR Approval Yes
YesThis wasn't clear to several companies like Nokia and Huawei. LG proposed to associate a key issue with this proposal. There wasn't much support finally and it was noted.
 		noted No    
    S3‑161626 pCR to TR 33.899 Security Mode procedure for NextGen NEC EUROPE LTD pCR Approval Yes
YesEricsson: Termination point for NAS protocol is still in the end function and now we propose to take it to the SEAF. Orange didn’t have it clear either and it was decided to note the document.
 		noted No    
    S3‑161623 pCR to TR 33.899: Update of a solution #1.4 on key hierarchy for 5G security NEC EUROPE LTD pCR   No
No
 		withdrawn Yes    
    S3‑161624 pCR to TR 33 899 Updated Solution 1.8 Key hierarchy for NextGen NEC EUROPE LTD pCR   No
No
 		withdrawn Yes    
    S3‑161625 pCR to TR 33 899 Initial attach procedure for NextGen NEC EUROPE LTD pCR Approval No
No
 		withdrawn Yes    
    S3‑161630 pCR to TR 33 899 Updated Solution 1.8 Key hierarchy for NextGen NEC EUROPE LTD pCR Approval No
No
 		withdrawn Yes    
    S3‑161700 Terminologies update and modification on key hierarchy in solution #1.9 Huawei, HiSilicon pCR   No
No
 		withdrawn Yes    
    S3‑161701 Terminologies update and modification on key hierarchy in solution #1.9 Huawei, HiSilicon pCR   No
No
 		withdrawn Yes    
    S3‑161703 Terminologies update and modification on key hierarchy in solution #1.9 Huawei, HiSilicon pCR   No
No
 		withdrawn Yes    
    S3‑161708 Resolving ENs in key issue #1.15 Termination point of UP security Huawei, HiSilicon pCR   No
No
 		withdrawn Yes    
    S3‑161711 Resolving the Editor’s notes in Key Issue#1.16 Huawei, Hisilicon pCR   No
No
 		withdrawn Yes    
    S3‑161768 pCR to TR 33.899: Evaluation of Solution #1.2, Periodic local authentication and packet count check VODAFONE Group Plc pCR Approval No
No
 		withdrawn Yes    
    S3‑161968 LS on state of SA3 discussions on NG security architecture Nokia LS out Approval Yes
YesThe approved tdoc 2081 contains a contradictory statement with 1.6. Co-locating AUSF and APRF was agreed there, on an editor's note. This note in 2081 says that the interface between AUSF and APRF depends on a SA2 decision, whereas in this LS it says that it could not be agreed in SA3. The Chair commented that SA3 needs to ask SA2 about this. Huawei proposed the Editor's note: The need for standardising the interface between these two depend on SA2 and SA3 decisions.
 		approved No    
8.6.2 Authentication S3‑161712 Definition and Clarification for Security Policy Control Function Huawei, Hisilicon pCR   Yes
YesNokia: a separate entity like this that centralizes all policy decisions should remain as an implementation option. I don’t agree with the change now. Orange: remove note on AUSF selection.
 		revised No S3‑161987  
    S3‑161987 Definition and Clarification for Security Policy Control Function Huawei, Hisilicon pCR - Yes
Yes
 		approved No   S3‑161712
    S3‑161783 Amendment to the Terms for the Authentication Huawei, Hisilicon pCR   Yes
YesNokia: An interface between AUSF and ARPF would be very difficult to define. This requirement was pending from an answer for the LS of SA2. An editor's note was added.
 		revised No S3‑162081  
    S3‑162081 Amendment to the Terms for the Authentication Huawei, Hisilicon pCR - Yes
Yes
 		revised No S3‑162124 S3‑161783
    S3‑162124 Amendment to the Terms for the Authentication Huawei, Hisilicon pCR - Yes
YesRevised to reword the editor's note according to the LS S3-161968.
 		approved No   S3‑162081
    S3‑161888 Placing AUSF always in the home network Nokia pCR   Yes
YesEricsson and Huawei didn’t agree with the change. Nokia commented that this would be need to be raised as an open issue to SA2. An LS will be sent for this issue.
 		noted No    
    S3‑161886 Comments on termination of EAP method in the VPLMN for solution 2.9 Nokia pCR   Yes
Yes
 		approved No    
    S3‑161669 Add a new requirement in KI 2.1 Huawei; Hisilicon pCR   Yes
YesVodafone didn’t agree with the change proposed here. We already satisfy this requirement in 3G, this is not needed in a 5G study. Huawei: we don’t have the concept of phase one or two in SA3, so this is still applicable. Broadcom: this is part of phase one.
 		noted No    
    S3‑161807 Update of Key issue #2.10. Authorization alternative Huawei, Hisilicon pCR   Yes
YesOrange: they don’t talk about third party but about slices in SA1.
 		revised No S3‑161991  
    S3‑161991 Update of Key issue #2.10. Authorization alternative Huawei, Hisilicon pCR - Yes
Yes
 		approved No   S3‑161807
    S3‑161875 New key issue "Increasing home control in roaming situations" Nokia pCR   Yes
YesDiscussed together with 877. The second requirement was reworded as proposed by Ericsson. Huawei didn’t agree with this requirement (they proposed a "may" instead of a "shall"). This wasn't agreed. The document was revised to leave just the agreed parts.
 		revised No S3‑161988  
    S3‑161988 New key issue "Increasing home control in roaming situations" Nokia pCR - Yes
Yes
 		approved No   S3‑161875
    S3‑161877 Linking location update with authentication confirmation Nokia pCR   Yes
Yes
 		approved No    
    S3‑161881 EPS AKA enhanced with UE authentication confirmation Nokia pCR   Yes
YesHuawei didn’t agree with the "commercially unattractive" sentence, but it was generally agreed by the group (with a comment from Deutsche Telekom addressed in the revision).
 		revised No S3‑161989  
    S3‑161989 EPS AKA enhanced with UE authentication confirmation Nokia pCR - Yes
Yes
 		approved No   S3‑161881
    S3‑161884 Introducing EPS AKA* to authentication framework in solution 2.7 Nokia pCR   Yes
YesTerminology needs to be reviewed as proposed by Broadcom. MCC asked to remove the mention to CT4 in the alternative 1b. Ericsson proposed to add an editor's note about Increasing home control in roaming situations.
 		revised No S3‑161990  
    S3‑161990 Introducing EPS AKA* to authentication framework in solution 2.7 Nokia pCR - Yes
Yes
 		approved No   S3‑161884
    S3‑161670 A solution for un-trusted non-3GPP access Huawei; Hisilicon pCR   Yes
Yes
 		revised No S3‑161992  
    S3‑161992 A solution for un-trusted non-3GPP access Huawei; Hisilicon pCR - Yes
Yes
 		approved No   S3‑161670
    S3‑161682 Reducing Signalling with Group Authentication Huawei, HiSilicon pCR   Yes
YesOrange queried whether the gateway was a relay UE. Huawei: The gateway could be a relay UE in one of the cases. Orange: relay Ues are in phase two in SA2, so they won’t work in phase One. Qualcomm: note the contributions that refer to phase two, there is no time for these and we must prioritise phase one. The Chair commented that by noting it means that they will just not be treated.
 		noted No    
    S3‑161685 Multiplex Authentication and Reduce NAS signalling Huawei, Hisilicon pCR   Yes
YesThe Chair commented that Massive IoT is in phase two. There wasn't much support so this was noted.
 		noted No    
    S3‑161725 Identity-based authentication for service provider connectivity Huawei, Hisilicon pCR   Yes
YesNTT-Docomo: One key gone missing the whole thing is broken. No key revocation. Too many open issues.
 		noted No    
    S3‑161774 pCR to TR33.899 - new solution - Identity-based Authentication of Equipment VODAFONE Group Plc pCR Approval Yes
YesVodafone: no long term identification in this solution. NTT-Docomo didn’t agree with the solution, Nokia supported NTT-Docomo. NTT-Docomo: This solution requires pushing tokens to all devices regularly.
 		revised No S3‑162025  
    S3‑162025 pCR to TR33.899 - new solution - Identity-based Authentication of Equipment VODAFONE Group Plc pCR Approval Yes
Yes
 		approved No   S3‑161774
    S3‑161890 Combining solutions 2.2 and 10.2 Nokia pCR   Yes
Yes
 		approved No    
    S3‑161705 Clarification for Editor’s notes in Solution #2.13 Huawei, Hisilicon pCR   Yes
YesOrange: what is a third party ARPF? Remove" third party".
 		revised No S3‑161993  
    S3‑161993 Clarification for Editor’s notes in Solution #2.13 Huawei, Hisilicon pCR - Yes
Yes
 		approved No   S3‑161705
    S3‑161686 MASA supports 4G USIM Huawei, Hisilicon pCR   Yes
YesNokia: what is a 4G USIM? Huawei: it's a LTE USIM. Nokia: in LTE we can use R99/UMTS SIMs. Which one do you refer to exactly?You don’t need additional functionality to make the USIM work in LTE. Add an editor's note on the need for clarification for the term 4G USIM. Orange: there is no HSS in 5G (looking at the figure). How does it work? This had to be clarified in the revision.
 		revised No S3‑161994  
    S3‑161994 MASA supports 4G USIM Huawei, Hisilicon pCR - Yes
YesMCC commented that there is no"4G" term in 3GPP specifications. It was agreed to add an editor's note for clarification of the "4G USIM".
 		approved No   S3‑161686
    S3‑161687 MASA Guarantees the Serving Network Public Key Authenticty Huawei, Hisilicon discussion   Yes
Yes
 		noted No    
    S3‑161688 pCR to TR33.899 MASA Guarantees the Serving Network Public Key Authenticty Huawei, Hisilicon pCR   Yes
YesNokia had a problem with this contribution, nobody seemed to support it.
 		revised No S3‑162022  
    S3‑162022 pCR to TR33.899 MASA Guarantees the Serving Network Public Key Authenticty Huawei, Hisilicon pCR - Yes
Yes
 		approved No   S3‑161688
    S3‑161689 MASA Details of Mutual Authentication Huawei, Hisilicon pCR Approval Yes
Yes
 		noted No    
    S3‑161690 pCR to TR33.899 MASA Details of Mutual Authentication Huawei, Hisilicon pCR Approval Yes
Yes
 		revised No S3‑162023  
    S3‑162023 pCR to TR33.899 MASA Details of Mutual Authentication Huawei, Hisilicon pCR Approval Yes
YesAdding an editor's note on the evaluation as proposed by Nokia.
 		approved No   S3‑161690
    S3‑161691 MASA NG-UE Security Capabilities Negotiation Huawei, Hisilicon pCR   Yes
YesOrange: Efficiency of the protocol is FFS. Lot of info is being sent to the HSS. This causes an impact by design.
 		revised No S3‑162024  
    S3‑162024 MASA NG-UE Security Capabilities Negotiation Huawei, Hisilicon pCR - Yes
Yes
 		approved No   S3‑161691
    S3‑161692 MASA - Value in sending NG-UE Security Capabilities to HSS Huawei, Hisilicon pCR Approval Yes
YesNoted without presentation.
 		noted No    
    S3‑161694 Value in sending NG-UE Security Capabilities to HSS Huawei, Hisilicon pCR Approval Yes
YesNoted without presentation.
 		noted No    
    S3‑161721 pCR_Update Solution #2.14 for non-AKA based Authentication Huawei, Hisilicon pCR   Yes
YesJuniper wanted an editor's note clarifying the last figure (especially step 5). This was agreed. Orange: impact on the charging system is FFS. This was added in an editor's note.
 		revised No S3‑162026  
    S3‑162026 pCR_Update Solution #2.14 for non-AKA based Authentication Huawei, Hisilicon pCR - Yes
Yes
 		approved No   S3‑161721
    S3‑161738 Updates to Device Certificate Enrollment in solution 2.10 Qualcomm Incorporated pCR Approval Yes
Yes
 		revised No S3‑162027  
    S3‑162027 Updates to Device Certificate Enrollment in solution 2.10 Qualcomm Incorporated pCR Approval Yes
YesFourth bullet removed as petitioned by Nokia.
 		approved No   S3‑161738
    S3‑161753 pCR to TR 33.899, updating long term secret key, improvement and evaluation VODAFONE Group Plc pCR Approval Yes
YesMCC commented that parts of the text need to be reworded in "standards language" (use of "we", or "I" for example). Also use of "NextGen" instead of 5G.
 		revised No S3‑162028  
    S3‑162028 pCR to TR 33.899, updating long term secret key, improvement and evaluation VODAFONE Group Plc pCR Approval Yes
Yes
 		approved No   S3‑161753
    S3‑161755 pCR to TR 33.899, session key exchange protocol, improvement and evaluation VODAFONE Group Plc pCR Approval Yes
Yes
 		approved No    
    S3‑161770 pCR to TR33.899 - Evaluation of Solution #2.3 VODAFONE Group Plc pCR Approval Yes
YesNokia: Is this solution adequate for Massive IoT? Vodafone: can't recall who put this solution, this is just an evaluation. Nokia: Massive IoT would go for phase 2. Is the solution needed now? It wasn't clear whether this would apply for Massive IoT.
 		approved No    
    S3‑161772 pCR to TR33,899 - Revision of the evaluation for Solution #2.6 VODAFONE Group Plc pCR Approval Yes
Yes
 		revised No S3‑162029  
    S3‑162029 pCR to TR33,899 - Revision of the evaluation for Solution #2.6 VODAFONE Group Plc pCR Approval Yes
Yes
 		approved No   S3‑161772
    S3‑161797 Resolving Editor’s Note on AAA proxy in Solution #2.8 Samsung pCR Approval Yes
Yes
 		approved No    
    S3‑161800 Updates to Solution #2.8 to introduce EAP-TLS authentication Samsung pCR Approval Yes
Yes
 		approved No    
    S3‑161852 Adding details to solution 2.5 KPN pCR Approval Yes
Yesnoted without presentation.
 		noted No    
    S3‑161854 Modifications to solution 2.11 KPN pCR Approval Yes
Yesnoted without presentation
 		noted No    
    S3‑161889 Removing option of AUSF in visited network for solution 2.7 Nokia pCR   Yes
Yes
 		approved No    
    S3‑161899 Update to solution #2.9: adding EAP-TTLS Ericsson LM pCR Approval Yes
Yes
 		approved No    
    S3‑161900 Update to solution #2.9: Fast re-authentication with ERP Ericsson LM pCR Approval Yes
YesNokia suggested to add an editor's note; this was accepted. Other comments from Nokia were also addressed in the revision.
 		revised No S3‑162031  
    S3‑162031 Update to solution #2.9: Fast re-authentication with ERP Ericsson LM pCR Approval Yes
Yes
 		approved No   S3‑161900
    S3‑161730 Update of solution #2.19 to clarify some editor’s notes Qualcomm Incorporated pCR Approval Yes
Yes
 		approved No    
    S3‑161693 MASA - Value in sending NG-UE Security Capabilities to HSS Huawei, Hisilicon pCR Approval No
No
 		withdrawn Yes    
    S3‑161713 Definition and Clarification for Security Policy Control Function Huawei, Hisilicon pCR   No
No
 		withdrawn Yes    
    S3‑161763 pCR to 33.899 - enhanced USIM features for 5G VODAFONE Group Plc pCR Approval No
No
 		withdrawn Yes    
    S3‑161784 Amendment to the Terms for the Authentication Huawei, Hisilicon pCR   No
No
 		withdrawn Yes    
    S3‑161806 Update of Key issue #2.10. Authorization alternative Huawei, Hisilicon pCR   No
No
 		withdrawn Yes    
    S3‑161808 Update of Key issue #2.10. Authorization alternative Huawei, Hisilicon pCR   No
No
 		withdrawn Yes    
8.6.3 Security context and key management S3‑161833 Key issue on security key and context identification Nokia pCR Approval Yes
YesVodafone:Can we confidentiallity protect in every country? Nokia: it's a should for confidentiality. Ericsson: even for integrity.
 		revised No S3‑162033  
    S3‑162033 Key issue on security key and context identification Nokia pCR Approval Yes
Yes
 		approved No   S3‑161833
    S3‑161834 Solution on security key and context identification Nokia pCR Approval Yes
YesBroadcom: how do you send the NAS command? The Chair commented that this text was agreed already, it’s not part of the contribution. Ericsson: the problem comes when removing CCNF. It was agreed to keep CCNF.
 		revised No S3‑162034  
    S3‑162034 Solution on security key and context identification Nokia pCR Approval Yes
Yes
 		approved No   S3‑161834
    S3‑161757 pCR to TR 33.899, UE requests key refresh, refinement and evaluation VODAFONE Group Plc pCR Approval Yes
YesAlf (NTT-Docomo): The requirements are operational, not security requirements. Vodafone: we are trying to address the editor's notes, we would be happy to remove the requirements and editor's note associated. It was agreed to add an editor's note that other solutions rather than dropping the connection should be investigated. Qualcomm's contribution 1734 proposed an alternative that was discussed as well. It was merged with this contribution. These changes and others proposed by NTT-Docomo were agreed.
 		revised No S3‑162035  
    S3‑162035 pCR to TR 33.899, UE requests key refresh, refinement and evaluation VODAFONE Group Plc pCR Approval Yes
Yes
 		approved No   S3‑161757
    S3‑161608 Solution for independent RAN keys ZTE Corporation pCR Approval Yes
YesTIM proposed to add an editor's note on whether CA is needed for this solution. Nokia: Performance problems when having an additional AKA process. Nokia didn’t see the purpose of using a public key ( figure 5.3.4.y.2.1-1). They questioned the requirement on which this is based. There is no such requirement. Deutsche Telekom commented that the key issue addresses a different problem. Stefan agreed with Guenther.
 		noted No    
    S3‑161672 introduce algorithms negotiation call flow HUAWEI TECHNOLOGIES Co. Ltd. pCR   Yes
YesBroadcom: what is SSF? Huawei: currently defined in SA2. This is defined in one of their solutions. Nokia: Details on Security capabilities sent in the auth response are needed. This was added in an editor's note.
 		revised No S3‑162036  
    S3‑162036 introduce algorithms negotiation call flow HUAWEI TECHNOLOGIES Co. Ltd. pCR - Yes
Yes
 		approved No   S3‑161672
    S3‑161673 A solution for key negotiation in dual connectivity scenario Huawei, HiSilicon pCR   Yes
YesNokia didn't agree with this proposal: there is overhead on this solution. Alf: Not enough details on the Random numbers to be sent in the D-H. This also may need a bigger computational power. TIM: the D-H could have an impact on the radio.
 		revised No S3‑162037  
    S3‑162037 A solution for key negotiation in dual connectivity scenario Huawei, HiSilicon pCR - Yes
Yes
 		approved No   S3‑161673
    S3‑161699 Security Key Refresh Triggered by UE Huawei, HiSilicon pCR   Yes
YesVodafone and Orange addressed the case of UE roaming in a contry that doesn’t allow confidentiality would not be allowed to use the network. Nokia: step 4 doesn't clarify whether it is integrity protected (the policy of the home network). Vodafone: we have the UICC and an OMA secure process for managing objects in the UE. Two processes for managing objects securely, do we need a third one? Interdigital: is this real time? An editor's note was added on this issue.
 		revised No S3‑162038  
    S3‑162038 Security Key Refresh Triggered by UE Huawei, HiSilicon pCR - Yes
Yes
 		approved No   S3‑161699
    S3‑161719 Authentication and Key Agreement for non-3GPP access Intel Corporation (UK) Ltd pCR   Yes
YesNokia, Qualcomm and Samsung had many issues with the proposal. This was discussed offline.
 		revised No S3‑162080  
    S3‑162080 Authentication and Key Agreement for non-3GPP access Intel Corporation (UK) Ltd pCR - Yes
Yes
 		approved No   S3‑161719
    S3‑161731 pCR solution to Key Issue # 3.1 Interception of radio interface keys sent between operator entities Qualcomm Incorporated pCR Approval Yes
Yes
 		revised No S3‑162039 S3‑161437
    S3‑162039 pCR solution to Key Issue # 3.1 Interception of radio interface keys sent between operator entities Qualcomm Incorporated pCR Approval Yes
Yes
 		approved No   S3‑161731
    S3‑161959 Comments on S3-161731 "pCR solution to Key Issue # 3.1 Interception of radio interface keys sent between operator entities" by Qualcomm Incorporated Nokia pCR   Yes
Yes
 		merged No S3‑162039  
    S3‑161734 pCR solution to Key Issue # 3.2 on refreshing keys Qualcomm Incorporated pCR Approval Yes
Yes
 		merged No S3‑162035 S3‑161434
    S3‑161894 Evaluating solution #2.6 against key issue 3.1 Nokia pCR   Yes
Yes
 		approved No    
    S3‑161668 Introduce D-H algorithm negotiation method in Solution #3.1 Huawei, Hisilicon pCR   Yes
Yes
 		approved No    
    S3‑161723 Update Solution for Security Context Management for UE with Multiple Access Technologies Huawei, HiSilicon, CATR pCR   Yes
Yes
 		approved No    
    S3‑161736 Enhancements to solution 3.4 Qualcomm Incorporated pCR Approval Yes
YesBroadcom: the whole authentication should be detailed in a different way from what is shown here. They didn't want to have it as a separate solution. Nokia was fine with the solution, it just needed some more sentences.
 		revised No S3‑162040  
    S3‑162040 Enhancements to solution 3.4 Qualcomm Incorporated pCR Approval Yes
Yes
 		approved No   S3‑161736
8.6.4 RAN security S3‑161697 Potential security requirements on gNB Huawei, HiSilicon pCR   Yes
YesInterdigital: add root of trust to the definitions. I disagree with the second requirement, it's not only the boot-up that needs to be integrity protected. Help of root of trust doesn't need to be here. Gemalto agreed with this, it's a solution not a requirement. Nokia: this should go to the security assurance specification, not here. Qualcomm agreed with Gemalto: some rewording is needed in the requirements. Deutsche Telekom suggested to use existing requirements in 33.401. This was taken offline.
 		revised No S3‑162041  
    S3‑162041 Potential security requirements on gNB Huawei, HiSilicon,Interdigital pCR - Yes
Yes
 		approved No   S3‑161697
    S3‑161662 Additions to Security aspects of dual connectivity Nokia pCR Approval Yes
Yes
 		approved No    
    S3‑161864 Details on Key issue #4.4: Security aspects of intra-NR mobility Ericsson pCR   Yes
Yes
 		approved No   S3‑161415
    S3‑161863 Details on Key issue #4.5: Security aspects of WLAN aggregation Ericsson pCR   Yes
Yes
 		revised No S3‑162042 S3‑161418
    S3‑162042 Details on Key issue #4.5: Security aspects of WLAN aggregation Ericsson pCR - Yes
YesIncludes some modifications suggested by Broadcom, relating this to the RAN and changing the editor's note.
 		approved No   S3‑161863
    S3‑161744 Requirement of preventing the RRC connection resource exhausted from DOS attacks Huawei, Hisilicon pCR   Yes
YesNokia: this is for massive IoT, we agreed to postpone these kind od contributions. It was agreed to note it for this reason.
 		noted No    
    S3‑161805 Resolving Editor’s Note on UE behaviour in reading the SIB Samsung pCR Approval Yes
Yes
 		revised No S3‑162043  
    S3‑162043 Resolving Editor’s Note on UE behaviour in reading the SIB Samsung pCR Approval Yes
Yes
 		approved No   S3‑161805
    S3‑161778 pCR adding key issue of key handling in RRC inactive connected state to RRC connected state transition China Mobile Com. Corporation pCR Approval Yes
Yes
 		revised No S3‑162032  
    S3‑162032 pCR adding key issue of key handling in RRC inactive connected state to RRC connected state transition China Mobile Com. Corporation pCR Approval Yes
YesEricsson: this is subject to agreements in RAN.It was agreed to add an editor's note.
 		approved No   S3‑161778
    S3‑161897 Resolving Editor’s Note on provisioning of public keys to the UE Samsung pCR Approval Yes
Yes
 		revised No S3‑162044  
    S3‑162044 Resolving Editor’s Note on provisioning of public keys to the UE Samsung pCR Approval Yes
Yes
 		approved No   S3‑161897
    S3‑161658 Discussion paper on broadcast messages with digital signature Nokia discussion Discussion Yes
Yes
 		noted No    
    S3‑161659 Verification of gNB using UL monitoring and System Query Nokia pCR Approval Yes
Yes
 		revised No S3‑162083  
    S3‑162083 Verification of gNB using UL monitoring and System Query Nokia pCR Approval Yes
Yes
 		approved No   S3‑161659
    S3‑161660 Evaluation of digital signature solution 5.4.4.1 Nokia pCR Approval Yes
Yes
 		approved No    
    S3‑161661 Evaluation of digital signature solution 5.4.4.2 Nokia pCR Approval Yes
Yes
 		revised No S3‑162130  
    S3‑162130 Evaluation of digital signature solution 5.4.4.2 Nokia pCR Approval Yes
YesAdding an editor'd note as proposed by Samsung.
 		approved No   S3‑161661
    S3‑161733 pCR solution to Key Issue # 4.6 User plane DoS attacks Qualcomm Incorporated pCR Approval Yes
YesInterdigital suggested to add an editor's note on other key distribution methods could work with this solution. MCC suggested to revise the second sentence of NOTE 1 since it includes a requirement (never to be included in informative notes) and references to 3GPP working methods. This was agreed. KPN: the key issue here seems to be massive IoT.SA3 had agreed to postpone this topic due to lack of time. This had to be discussed offline.
 		revised No S3‑162045 S3‑161435
    S3‑162045 pCR solution to Key Issue # 4.6 User plane DoS attacks Qualcomm Incorporated pCR Approval Yes
Yes
 		noted No   S3‑161733
    S3‑161777 Prevent UP DoS Attack over Air Interface Huawei, HiSilicon pCR   Yes
YesNokia: this is for IoT small devices. I suggest to postpone it. Huawei: small data solutions are part of phase one. Nokia: SA2 will decide where small data is going to during their next meeting. It had to be discussed offline whether this document was about Massive IoT or about small data in order to have it treated.
 		revised No S3‑162079  
    S3‑162079 Prevent UP DoS Attack over Air Interface Huawei, HiSilicon pCR - Yes
YesNokia commented that small data was decided to be postponed, but the Chair commented that this had been opened and commented.
 		approved No   S3‑161777
8.6.5 Security within NG-UE S3‑161707 Additional Storage Requirements for Credentials Intel Corporation (UK) Ltd pCR   Yes
YesOverlapping with 1737, 2006,1868. Orange only agreed partly with the second last requirement.
 		noted No    
    S3‑161737 Security requirements for Key Issue # 5.1 Qualcomm Incorporated pCR Approval Yes
Yes
 		noted No    
    S3‑161958 Comments to S3-161737 ORANGE, Vodafone, Telecom Italia, Oberthur Technologies pCR Approval Yes
YesVodafone: we don’t mandate the protection storage in a confidential integrity protected way, it's poorly written here. Storage should be in a tampered resistant hardware. This was agreed. NTT-Docomo: integrity protection of the algorithm or the key? Huawei: how do we store the algorithm? Vodafone: software. Huawei: just say it, but this looks like a solution. Integrity protection of algorithms: Interdigital: stored in tamper resistant doesn’t mean it cannot be changed. It has to be integrity protected, otherwise anyone can go and change it. It's a requirement for the storage. Deutsche Telekom: acccessibility of parameters requirement covers this already. KPN: integrity protection is the generic requirement, protection against manipulation in a tamper resistant storage is just one possible solution. Intel agreed. Orange: the tamper resistant storage ensures that the algorithm and keys cannot be reached. Qualcomm: algorithm storage? What is it? Vodafone: tamper resistant, you cannot change the software, what is the point of integrity protection? Alf: tamper resistant hardware says that you cannot access the software but it does not refer to the access to the algorithm. Ensure that the algorithm is the one selected by the operator and can be changed by it, not someone else. Vodafone: if I want to put different USIMs in a device I don’t see why 3GPP does not allow me that. The Chair clarified that when an algorithm cannot be changed: integrity protection. Qualcomm disagreed. Gemalto commented that the algorithm can be updated, it's possible that this happens in the future. Klaus agreed. Vodafone: AKA to EAP, this is a 5G use case. Security of storage and operation are the points. Ericsson: no need of the word "hardware" in the context of tamper resistant. Orange: state of the art is like this, we have to use hardware. KPN:: perhaps someone will come with a solution that comes with an equal security. This is evaluation of the solution. If the Cloud is a solution equally secure, KPN would agree to that, for example. Qualcomm: in the key issue details there are no references to the algorithm part. Orange: no storage no processing no protection of the algorithm to be discussed then. Blackberry agreed with KPN. Also, no need to mention hardware. Huawei agreed with Blackberry with the hardware issue. TIM; tamper resistance and hardware can be there, no contradiction. Vodafone: it is right to mention the word hardware. Deutsche Telekom: it is not the issue whether this is a separate component, and I agree with keeping the word hardware. Ericsson: hardware is a solution when you mention tamper resistance. The Chair commented that although Ericsson and the others may be right, many companies still want to keep it. Vodafone: you will need the hardware to run the software. The Chair proposed to have tamper resistance environment and then lisitng requirements, but this wasn't agreed. Intel: what do we mean by hardware here? Orange: it's a place where we have operations for the credentials. Intel: UICC? Orange: didn’t say that. The storage will be defined elsewhere e.g. ETSI SCP, the solution can be found outside 3GPP. Deutsche Telekom: in 5G we can find alternatives to UICC, I don’t see the reasons to resist to have pure requirements. Vodafone: as long as it is suitable secure, we are prepared to look at any solution. Tamper resistance software is linked to tamper resistance hardware. Ericsson: in the requirements clauses we have "ffs" in editor's notes and this is blocking progress and causing confusion. Qualcomm agreed. NTT-Docomo: I propose requirements derived from security threats and reason why these requirements are coming from them. I agree with Vesa, the reality is that we don’t have agreed security requirements. The Chair commented that if there is no agreement we can just drop this topic and focus on others. Orange: let's stick with what we have with regards to the requirements. Vodafone: all docs have aspects that people can agree with, there is no blockage. The Chair commented that progress needs to be made and have some agreements, otherwise there is no progress for the next meeting. Morpho commented if we don’t agree in a solution we stick in 5G with what we have now, the UICC. Ericsson: no agreement in a radio technology means stick with LTE? The Chair: fallback is the way out bit probably not what will happen.
 		revised No S3‑162006  
    S3‑162006 Comments to S3-161737 ORANGE, Vodafone, Telecom Italia, Oberthur Technologies, Deutsche Telekom, AT&T, Giesecke & Devrient pCR Approval Yes
YesVodafone: Integrity and confidentiality of the parameters and the same for the algorithm are difference concepts. There is no decision anywhere that there are public algorithms. It's the responsibility of the operator that both algorithm and parameters are confidentiality and integrity protected. This has been out of scope of standards until now and I don’t understand why we go for this here. Morpho: confidentiality protection weakens what we have today. Orange: I agree with your comment. Ericsson argued that this commenting contribution was hard to follow since there were changes on changes and addition of requirements.
 		noted No   S3‑161958
    S3‑161868 Requirements for NG-UE Ericsson pCR   Yes
Yes
 		noted No    
    S3‑161704 Additional requirements for storage of identities Intel Corporation (UK) Ltd pCR Approval Yes
Yes
 		noted No    
    S3‑161680 Requirements for NG-UE Huawei, HiSilicon pCR   Yes
YesOrange: still under discussion in SA1, whether to have different types of devices or not. It needs to be aligned with SA1 agreements. Orange: what are security capabilities? Can you be more precise? Vodafone: I don’t see having a class being an advantage. Huawei: different devices need to have different capabilities. Vodafone: have a class where all the devices can be tight in one place, to avoid having a huge market variation. Huawei: hard to achieve all requirements in a single device. Orange: we define mandatory and optional requirements. Ericsson: add an editor's note on the progress in SA1. NTT-Docomo: I like that the network can reject Ues based on the lack of security capabilities. Vodafone: this exists already. Orange didn’t agree with the threat, who says that the device doesn’t have all the security capabilities. Klaus: IoT is for the next phase, we shouldn't go on with that. The Chair decided to allow some reqriting and put an editor's note on alignment with SA1 to go ahead.
 		revised No S3‑162048  
    S3‑162048 Requirements for NG-UE Huawei, HiSilicon pCR - Yes
Yes
 		approved No   S3‑161680
    S3‑161867 New key issue #5.y: Storage and processing of credentials and identifiers for the massive Internet of Things Ericsson pCR   Yes
YesKPN pointed out that it’s been agreed not to go for Massive IoT during this time. This was noted then.
 		noted No    
8.6.6 Authorization S3‑161804 Update of key issue #6.y: Accounting and non-repudiation Huawei, Hisilicon pCR   Yes
YesInterdigital: Extend it to non random access.
 		revised No S3‑162096  
    S3‑162096 Update of key issue #6.y: Accounting and non-repudiation Huawei, Hisilicon pCR - Yes
Yes
 		approved No   S3‑161804
    S3‑161618 Solution #6.x: Dynamic Authorization by Operator/MNO INTERDIGITAL COMMUNICATIONS pCR Agreement Yes
YesNokia: hard to have this in the current architecture being defined in SA2. It was agreed to add an editor's note on the flow. Qualcomm: example of dynamic service? Interdigital: you are attached in a slice, you request a new service and then you attach to another slice.
 		revised No S3‑162097  
    S3‑162097 Solution #6.x: Dynamic Authorization by Operator/MNO INTERDIGITAL COMMUNICATIONS pCR Approval Yes
Yes
 		approved No   S3‑161618
    S3‑161619 Solution #6.y: Dynamic Authorization by Trusted 3-rd Party INTERDIGITAL COMMUNICATIONS pCR Agreement Yes
Yes
 		revised No S3‑162076  
    S3‑162076 Solution #6.y: Dynamic Authorization by Trusted 3-rd Party INTERDIGITAL COMMUNICATIONS pCR Approval Yes
YesVodafone: unnecessarily complex.Morpho agreed, this is not in line with the requirement from SA1. China Mobile: auth for the 3rd party should be handled in the third party, not the MNO.Interidgital replied that it was explained in the contribution. Orange was against the contribution. Vodafone was fine with it until the evaluation was filled in.
 		revised No S3‑162098 S3‑161619
    S3‑162098 Solution #6.y: Dynamic Authorization by Trusted 3-rd Party INTERDIGITAL COMMUNICATIONS pCR Approval Yes
YesAdding an editor's note.
 		approved No   S3‑162076
    S3‑161827 Solution for UE authorization based on a secondary authentication with a third party server Ericsson LM pCR Approval Yes
YesEricsson: this applies to all solutions. An editor's note for alignment with SA2 was agreed to be added. Key issue 6.3 removed. Vodafone: we don’t like the signalling going through the user plane. The evaluation is not such, it should be deleted. Nokia: remove references to current mechanisms in the justification. Also added an editor's note.
 		revised No S3‑162099  
    S3‑162099 Solution for UE authorization based on a secondary authentication with a third party server Ericsson LM pCR Approval Yes
Yes
 		approved No   S3‑161827
8.6.7 Subscription privacy S3‑161611 Key issue #7.y: Need to protect entire Permanent Identifier INTERDIGITAL, THALES pCR Approval Yes
YesVodafone and Qualcomm didn’t agree with this. Thales: this key issue covers a very important issue in 5G. Vodafone: it's already in the document. Ericsson: some solutions didn’t cover the routing information. Vodafone was fine with this. Nokia: all solutions that protect the country code would be out of the table if we accept this. An editor's note was added for this. Alf (NTT Docomo): what kind of attack is it in here? Interdigital: passive attack over the air. Qualcomm: too early to agree on this requirement. Wait for evaluation.
 		revised No S3‑162100 S3‑161455
    S3‑162100 Key issue #7.y: Need to protect entire Permanent Identifier INTERDIGITAL, THALES pCR Approval No
Yes
 		approved No   S3‑161611
    S3‑161639 pCR for adding solution for key issues #7.4 and #7.7: effective generation of temporary or short-term identifiers based on channel estimation THALES pCR Approval Yes
YesVodafone: biggest problem of changing identifiers is that some system don’t bother changing them. This is about generating random numbers. Not in the scope of 3GPP to define how to generate a random number. Ericsson: some processing is needed here, not good. Add an editor's note on further clarification needed, how the process can improve the refreshment time of the temporal identifier. Vodafone: the advantage of this over existing mechanishms is for further study. Huawei: An attacker near the received can have a good channel estimation.
 		revised No S3‑162101 S3‑161404
    S3‑162101 pCR for adding solution for key issues #7.4 and #7.7: effective generation of temporary or short-term identifiers based on channel estimation THALES pCR Approval Yes
Yes
 		approved No   S3‑161639
    S3‑161793 pCR to TR 33.899: Temporary Identity refresh parameters VODAFONE Group Plc pCR Approval Yes
YesEricsson: too solution specific for being a requirement. Nokia: no need to give implementation details like here.Vodafone replied that he changed it from a requirement to a solution. Deutsche Telekom: second potential requirement should stay.
 		approved No    
    S3‑161841 Additional EN on requirement because of LI aspect of key issue 7.1 was S3-161445 Nokia, Ericsson, LG Electronics pCR Approval Yes
Yes
 		noted No    
    S3‑161842 Additional requirement on transmission of identifiers in key issue 7.6 was S3-161446 Nokia, Ericsson, LG Electronics pCR Approval Yes
Yes
 		approved No    
    S3‑161732 pCR to update solution #7.4: Privacy enhanced Mobile Subscriber Identifier (PMSI) Qualcomm Incorporated pCR Approval Yes
Yes
 		approved No   S3‑161436
    S3‑161836 Commenting solution 7.4 was S3-161388 Nokia pCR Approval Yes
Yes
 		approved No    
    S3‑161835 Commenting solution 7 3 and proposal to split from LI was S3-161447 Nokia, Ericsson pCR Approval Yes
YesAlex (BT):ffs whether this solution needs the PLMN non assistance requirements.
 		revised No S3‑162102  
    S3‑162102 Commenting solution 7 3 and proposal to split from LI was S3-161447 Nokia, Ericsson pCR Approval Yes
Yes
 		approved No   S3‑161835
    S3‑161620 pCR for adding solution to key issue #7.2 : Concealing permanent or long-term subscriber identifier with opportunistic encryption THALES pCR Approval Yes
Yes
 		approved No   S3‑161405
    S3‑161775 pCR Security enhancement to the attach procedure without relying on PKI China Mobile Com. Corporation, Thales pCR Approval Yes
YesEricsson: this is not solving the issue. China Mobile: this is not an active attack.
 		revised No S3‑162105  
    S3‑162105 pCR Security enhancement to the attach procedure without relying on PKI China Mobile Com. Corporation, Thales pCR Approval No
Yes
 		left for email approval No   S3‑161775
    S3‑161776 pCR Security enhancement to the attach procedure relying on PKI China Mobile Com. Corporation pCR Approval Yes
YesNokia: mention the key issue. Added also an editor's note.
 		revised No S3‑162106  
    S3‑162106 pCR Security enhancement to the attach procedure relying on PKI China Mobile Com. Corporation pCR Approval Yes
Yes
 		approved No   S3‑161776
    S3‑161782 Protect the Permanent or Long Termn User Identity with Public Key Techologies Huawei, HiSilicon pCR   Yes
YesEricsson: more clarification on the roaming case.
 		revised No S3‑162103  
    S3‑162103 Protect the Permanent or Long Termn User Identity with Public Key Techologies Huawei, HiSilicon pCR - Yes
Yes
 		approved No   S3‑161782
    S3‑161837 5G Privacy Pseudonym-IMSI - intro solution was S3-161463 Nokia pCR Approval Yes
Yes
 		approved No    
    S3‑161838 5G Privacy Pseudonym-IMSI - process steps was S3-161464 Nokia pCR Approval Yes
Yes
 		approved No    
    S3‑161839 5G Privacy Pseudonym-IMSI evaluation was S3-161466 Nokia pCR Approval Yes
Yes
 		approved No    
    S3‑161858 Refreshing CN short-term subscriber identifiers Ericsson pCR Approval Yes
Yes
 		approved No    
    S3‑161681 Update requirement on long term identifier aspect of key issue 7.2 Huawei, HiSilicon pCR   Yes
Yes
 		approved No    
    S3‑161843 Need of LS regarding effects of LI requirement on privacy solutions Nokia, Ericsson pCR Approval Yes
Yes
 		noted No    
    S3‑161759 pCR to TR 33.899, UE requests temporary identifier refresh, evaluation VODAFONE Group Plc pCR Approval Yes
Yes
 		approved No    
    S3‑161715 Identity privacy and backwards compatibility Huawei, HiSilicon pCR   Yes
YesEricsson: a key issue cannot be promoted into a solution, remove the references. Nokia: no backwards compatibility?allowing the UE fall back to 4G wouldn’t help for backwards compatibility.
 		revised No S3‑162107  
    S3‑162107 Identity privacy and backwards compatibility Huawei, HiSilicon pCR - Yes
Yes
 		approved No   S3‑161715
    S3‑161853 Updating solution #7.3 Ericsson, Telecom Italia pCR Approval Yes
Yes
 		approved No    
    S3‑161641 New privacy solution for concealing permanent subscriber identifier TELECOM ITALIA S.p.A., Ericsson pCR Approval Yes
YesColin (CESG) commented that this is related to the LS from TC CYBER, which could be noted. Alex (BT): add in the second bullet of the evaluation clause "this is subject to the correct key provided to the serving network".
 		revised No S3‑162108  
    S3‑162108 New privacy solution for concealing permanent subscriber identifier TELECOM ITALIA S.p.A., Ericsson pCR Approval Yes
Yes
 		approved No   S3‑161641
    S3‑161856 Encrypting IMSI based on ECIES Ericsson, Telecom Italia pCR Approval Yes
Yes
 		approved No    
    S3‑161855 Privacy-enhanced LTE-style mechanism for temporary identifier assignment Ericsson pCR Approval Yes
Yes
 		revised No S3‑162109  
    S3‑162109 Privacy-enhanced LTE-style mechanism for temporary identifier assignment Ericsson pCR Approval Yes
Yes
 		approved No   S3‑161855
    S3‑161716 Identity privacy and backwards compatibility Huawei, HiSilicon pCR   No
No
 		withdrawn Yes    
8.6.8 Network slicing security S3‑161788 Clarifications on the Solutions for Network Slicing Security LG Electronics France pCR Approval Yes
Yes
 		approved No    
    S3‑161745 Security Architecture for Network Slicing CATT, CATR pCR Approval Yes
YesIt was commented that the Visited network/Home network instead of third party is a competition for the current MVNO solutions, and also a more costly alternative. Nokia: there are assumptions here that depend on what is decided in SA2. An editor's note for this was added.
 		revised No S3‑162114  
    S3‑162114 Security Architecture for Network Slicing CATT, CATR pCR Approval Yes
Yes
 		approved No   S3‑161745
    S3‑161729 Isolation of slices using UP security terminating in the network Qualcomm Incorporated pCR Approval Yes
YesHuawei: How the subscription profile is made is ffs. Created an editor's note. Nokia: underlying trust model needs to be clarified. Added editor's note. On another Nokia's comments: Second editor's note on SMF making its decision. Third editor's note on relation between the MMS and slices needs further clarification according to the response LS.
 		revised No S3‑162110  
    S3‑162110 Isolation of slices using UP security terminating in the network Qualcomm Incorporated pCR Approval Yes
Yes
 		approved No   S3‑161729
    S3‑161740 Solution for Security Mechanism Differentiation for Network Slices HUAWEI TECHNOLOGIES Co. Ltd. pCR   Yes
YesUsing a similar editor's note as in 987.
 		revised No S3‑162111  
    S3‑162111 Solution for Security Mechanism Differentiation for Network Slices HUAWEI TECHNOLOGIES Co. Ltd. pCR - Yes
Yes
 		approved No   S3‑161740
    S3‑161741 Network authentication supporting network slices Huawei, Hisilicon pCR   Yes
YesNokia: It should aligned with the SA2 architecture solution. An editor's note was agreed for this.
 		revised No S3‑162112  
    S3‑162112 Network authentication supporting network slices Huawei, Hisilicon pCR - Yes
Yes
 		approved No   S3‑161741
    S3‑161789 Slice authentication Huawei, Hisilicon pCR   Yes
Yes
 		revised No S3‑162113  
    S3‑162113 Slice authentication Huawei, Hisilicon pCR - Yes
YesEditor's note on aligning with the SA2 architecture.
 		approved No   S3‑161789
    S3‑161961 Comments on contribution S3-161789 Nokia discussion Approval Yes
YesThe Chair commented that the criteria to put this in phase two hasn't been agreed in SA3. The goal is organize the network slice topic. The conference call on NxtGen will also deal with this (prioritization and scope of work).
 		noted No    
    S3‑161903 PCO based User Authentication and authorization for Slice access Nokia pCR Approval Yes
Yes
 		approved No    
8.6.9 Relay security S3‑161696 Potential security requirements on Relay Huawei, HiSilicon pCR Approval Yes
YesThis topic will go for phase 2.
 		noted No    
    S3‑161695 A mutual authentication and session key generation scheme between remote UE and Network over the relay Huawei, HiSilicon pCR Approval Yes
YesThis topic will go for phase 2.
 		noted No    
8.6.10 Network domain security S3‑161949 Authorization requirements for communication between network elements Huawei, Hisilicon pCR   Yes
Yes
 		approved No    
    S3‑161896 Resolving EN in solution 10.2 Nokia pCR   Yes
Yes
 		revised No S3‑162115  
    S3‑162115 Resolving EN in solution 10.2 Nokia pCR - Yes
Yes
 		approved No   S3‑161896
    S3‑161684 Authorization requirements for communication between network elements Huawei, Hisilicon pCR   Yes
No
 		withdrawn Yes    
8.6.11 Security visibility and configurability S3‑161791 UE configuration of key and identifier refresh LG Electronics France pCR Approval Yes
YesEricsson proposed an editor's note on the malfunctioning of the UE overrifdign the network settings. Nokia: what do we have to say something beyond the security provided by the network? An UE can say that I have app that "needs this security parameters and if your network doesn't support this capability I wont connect to it". An editor's note was added to address this issue. Vodafone:"ability to trigger a refresh of security keys". What keys? I don’t want to apply it to all keys. LG: it's copied from a key issue. The original key issue must be changed as well, then. Deutsche Telekom: change the radio interface keys for something more clear. It was decided to state that the original key issue needed to be fixed.
 		revised No S3‑162116  
    S3‑162116 UE configuration of key and identifier refresh LG Electronics France pCR Approval Yes
Yes
 		approved No   S3‑161791
8.6.12 Credential provisioning S3‑161714 Updates to Remote credential provisioning – Add Headless IoT device to existing user’s MNO subscription Intel Corporation (UK) Ltd pCR Approval Yes
YesNokia: the device needs to be configured with a certificate. This was added. Added an editor's note on the evolution part as proposed by Dragan from Oberthur: impact on low power devices.
 		revised No S3‑162117  
    S3‑162117 Updates to Remote credential provisioning – Add Headless IoT device to existing user’s MNO subscription Intel Corporation (UK) Ltd pCR Approval Yes
Yes
 		approved No   S3‑161714
    S3‑161710 Updates to remote credential provisioning using captive portal technique Intel Corporation (UK) Ltd pCR Approval Yes
YesOrange: one way authentication defined by SA2? Intel: it refers to attach procedure, not authentication.
 		revised No S3‑162118  
    S3‑162118 Updates to remote credential provisioning using captive portal technique Intel Corporation (UK) Ltd pCR Approval Yes
Yes
 		approved No   S3‑161710
    S3‑161802 Updates to Solution #12.4 on Provisioning server location Samsung pCR Approval Yes
Yes
 		approved No    
    S3‑161803 Updates to Solution #12.4 to detail EAP-TLS authentication procedure Samsung pCR Approval Yes
YesVodafone: the clause is quite messy. Lot of wrong terms here. And we are adding more mess here. An editor's note on the need for reworking this was added. Added a second Editor's note as proposed by Nokia.
 		revised No S3‑162119  
    S3‑162119 Updates to Solution #12.4 to detail EAP-TLS authentication procedure Samsung pCR Approval Yes
Yes
 		approved No   S3‑161803
    S3‑161726 Remote Provisioning for IoT devices without Initial Credentials Huawei, Hisilicon, CATR pCR   Yes
YesNumerous comments from Nokia and Vodafone. This was noted.
 		noted No    
    S3‑161785 Group Provisioning for IoT devices via a Companion UE Huawei, Hisilicon pCR   Yes
YesWithin scope of phase 2. For the sake of priority this topic will be treated in a later stage.
 		noted No    
    S3‑161866 FS_NSA: solution for credentials provisioning Gemalto N.V. pCR Approval Yes
YesVodafone: it seems to me that it is out of scope of 3GPP. Gemalto: steps 3,4,5 and 6 shows that it is within scope. Vodafone: this is what we are already doing in a network attach with the current IMSI, not a change whatsoever. Heiko (Morpho): pre- deployment in the manufacturer phase, what is the benefit here instead of providing with the normal 3GPP subscription? Klaus: I don’t see the benefit of this either. NTT-Docomo: I would rather note this, but we can have an editor's note in the evaluation. Orange: I cannot agree with this kind of solution due to business implications. Gemalto: but that is part of the evaluation part.
 		noted No    
    S3‑161859 New solution: Network access for credentials provisioning Ericsson pCR   Yes
YesVodafone: how is this preeventing DoS attacks?I'd like to see that.I need to know some clarifications and benefits of this solution. I'm not against the solution. Gemalto: is this a massive IoT topic? Vodafone: remote provisioning is a Massive IoT topic. Several companies denied this. Ericsson agreed to add more details for Vodafone. Ericsson: remote provisioning is generic, where is it pinpointed that this belongs to Massive IoT. Vodafone: key issue is from the factory use case, IoT related. Ericsson commented that these are two different use cases. The Chair commented that IoT can be either a massive IoT topic or not. And those which do not belong to Massive IoT are handled with higher priority,in this phase. It was noted that the next conference call would clarify the work in phases.
 		revised No S3‑162120  
    S3‑162120 New solution: Network access for credentials provisioning Ericsson pCR - Yes
Yes
 		approved No   S3‑161859
    S3‑161739 Discussion on provisioning of credentials Qualcomm Incorporated discussion Discussion Yes
YesVodafone: add also bootstrap credentials. A profile that is in there for the purpose of pre-provision. Orange: does this impact the SA2 architecture? Qualcomm: this is triggered by a LS from SA2. It's irrelevant to this paper. Alf (NTT-Docomo: this will impact SA2 architecture. Attach procedure should include authentication. Intel: no common understanding of what SA1 meant with "no provision". Vodafone: it doesn't mean that the provision is not there. The Chair commented that it was understood here that the UE needs to be authenticated, just include that in the response LS.
 		noted No    
    S3‑161727 Remote Provisioning for IoT devices without Initial Credentials Huawei, Hisilicon, CATR pCR   No
No
 		withdrawn Yes    
8.6.13 Interworking and migration S3‑161718 Possible Handover scenarios within NextGen networks NEC EUROPE LTD discussion Information Yes
Yes
 		noted No    
    S3‑161671 Clarify the meaning of “no interworking with GSM/GPRS, UMTS” Huawei, Hisilicon pCR   Yes
YesHuawei: the interworking is not clear. The Chair commented that in case SA2 decided to go this way SA3 should tell them to be careful. ORANGE: where is this written? The Chair commented that this is not essential now. Huawei should show this to the other groups before SA3 can take action on it.
 		noted No    
    S3‑161840 Update on security area interworking and migration Nokia pCR Approval Yes
Yes
 		revised No S3‑162121  
    S3‑162121 Update on security area interworking and migration Nokia pCR Approval Yes
Yes
 		approved No   S3‑161840
    S3‑161629 pCR to TR 33.899: Proposal of key issue and solution for option 3 NEC EUROPE LTD pCR Approval Yes
YesOrange: Reason for having always the UP always integrity protected? The requirement mentioning this was removed. Ericsson: option 3 belongs already to RAN's key issues. Many parts of the solution are more in RAN scope than SA3 scope.
 		revised No S3‑162131  
    S3‑162131 pCR to TR 33.899: Proposal of key issue and solution for option 3 NEC EUROPE LTD pCR Approval No
Yes
 		left for email approval No   S3‑161629
    S3‑161844 5G interworking - key issue on bidding down attack was S3-161394 Nokia pCR Approval Yes
YesEricsson: formulate the requirements less solution centric. Second requirement goes away, the first requirement had some part of it moved to the solutions.
 		revised No S3‑162132  
    S3‑162132 5G interworking - key issue on bidding down attack was S3-161394 Nokia pCR Approval Yes
Yes
 		approved No   S3‑161844
    S3‑161628 pCR to TR 33.899 Handover procedure for NextGen NEC EUROPE LTD pCR Approval Yes
YesEricsson: there are points out of scope of SA3, they belong to RAN. Mandatory key change during handover seems to be mandated, this should be studied. The terminology should also be aligned with the RAN groups (NG (R) AN).
 		revised No S3‑162133  
    S3‑162133 pCR to TR 33.899 Handover procedure for NextGen NEC EUROPE LTD pCR Approval No
Yes
 		left for email approval No   S3‑161628
    S3‑161627 pCR to TR 33.899 Update of Key Issue 13.1 Security for Handover NEC EUROPE LTD pCR Approval No
No
 		withdrawn Yes    
8.6.14 Small data S3‑161872 Small data security area introduction Ericsson pCR   Yes
Yes
 		not treated No    
    S3‑161698 Clarification of requirements for preventing user plane DoS attack Huawei, HiSilicon pCR   Yes
Yes
 		not treated No    
    S3‑161874 Key issues in Small data Ericsson pCR   Yes
Yes
 		not treated No    
    S3‑161871 Key issue for Small data Ericsson pCR   Yes
Yes
 		not treated No    
    S3‑161781 Small Data Protection Huawei, HiSilicon, pCR   Yes
Yes
 		not treated No    
    S3‑161663 Small data security solution connectionless access Nokia pCR Approval Yes
Yes
 		not treated No    
    S3‑161746 Restrict frequency and amount of small data Huawei, Hisilicon pCR   Yes
Yes
 		not treated No    
    S3‑161677 A security solution for small user data transfer via control plane Huawei, HiSilicon pCR   Yes
Yes
 		not treated No    
    S3‑161683 A Ticket-Based Solution for Small Data Transmission in User Plane Huawei, HiSilicon pCR   Yes
Yes
 		not treated No    
    S3‑161794 A Client-Puzzle-Based Dos Attack Defense Approach for mIoT Infrequent Small Data Transmission Huawei, Hisilicon, pCR   Yes
Yes
 		not treated No    
    S3‑161857 Optimized Re-authentication mechanism KPN pCR Approval Yes
Yes
 		not treated No    
    S3‑161869 Security solution for Infrequent Small Data Ericsson pCR   Yes
Yes
 		not treated No    
    S3‑161795 A Client-Puzzle-Based Dos Attack Defense Approach for mIoT Infrequent Small Data Transmission Huawei, Hisilicon, pCR   No
No
 		withdrawn Yes    
8.6.15 Broadcast/Multicast security                      
8.6.16 Management Security S3‑161787 adding the new key issue in the section 5.16.3 of TR33.899 v0.3 China Mobile Com. Corporation pCR Approval Yes
YesVodafone: we support the filtering of child pornography but this is out of scope of SA3. This is content filtering. The definition of what should be filtered is also out of scope. Orange: The calling ID requirement is related to an IMS feature,not 5G.
 		noted No    
    S3‑161809 Network slice life-cycle security Huawei, Hisilicon pCR   Yes
YesVodafone: addition of key issues and security areas. Adding new key issues in this Release isn't going to be closing this specification. We don’t have time. Orange: where are the APIs coming from? Any SA2 spec? Huawei couldn’t find the reference. It was decided to add an editor's note.
 		revised No S3‑162134  
    S3‑162134 Network slice life-cycle security Huawei, Hisilicon pCR - No
Yes
 		left for email approval No   S3‑161809
    S3‑161810 Network slice life-cycle security Huawei, Hisilicon pCR   No
No
 		withdrawn Yes    
8.6.17 Cryptographic algorithms S3‑161847 The Impact of Quantum Computers and Post Quantum Cryptography Ericsson discussion Discussion Yes
Yes
 		noted No    
    S3‑161851 Update of Key issue #17.2: Quantum safe cryptography Ericsson pCR Approval Yes
Yes
 		revised No S3‑162135  
    S3‑162135 Update of Key issue #17.2: Quantum safe cryptography Ericsson pCR Approval No
YesUS Chamber of Commerce: we cannot wait until the quantum computers arrive. Huawei: UE capabilities should be taken into consideration.
 		left for email approval No   S3‑161851
    S3‑161893 pCR to TR 33.899: Quantum safe cryptography solutions VODAFONE Group Plc pCR Approval Yes
YesGemalto: OTA is mentioned, we also have remote management defined by GSMA. Vodafone: the GSMA one is not mentioned in 3GPP documents.
 		approved No    
8.6.18 Other S3‑161944 LS reply on 5G work alignment S2-166238 LS in   Yes
YesFloren commented that SA2 will change the attached document, so this should be taken into account.
 		noted No    
    S3‑161947 Reply LS on Cooperation on NGS FMC SP-160743 LS in   Yes
Yes
 		noted No    
    S3‑161924 LS OUT on NFV-based solutions for next generation mobile networks ETSI ISG NFV LS in   Yes
YesVodafone supported the cooperation with ISG NFV. A response stating that SA3 is looking into it with a study. Ericsson clarified that SA3 is still looking whether it is worth working on NFV security or not, this should be explained in the response. Deutsche Telekom: not good to send an LS now since they haven’t started any work and we have no conclusions here. It was agreed to reply this LS during the next meeting. Heiko (Morpho) commented that other groups like SA,SA2,SA5 are being sent this LS and they may reply. This will be seen in SA plenary as well and the SA3 Chair will bring up this issue in SA#74 that SA3 will take it into consideration and reply.
 		postponed No    
    S3‑161929 LS to 3GPP SA3 on PII protection in the mobile and 5G networks ETSI TC CYBER LS in   Yes
YesColin (CESG) commented that this WID was initiated by Telecom Italia, but they were not present in the meeting. There were no comments to this LS from the delegates.
 		noted No    
    S3‑161942 LS on "Attach procedure for Remote SIM Provisioning” S2-165437 LS in   Yes
YesTim (Vodafone) commented that there are some solutions in the NextGen TR but SA3 was not ready to give a response to SA2 for this meeting. Nokia didn’t see clearly what SA2 was asking for. Morpho noted that the wording is a bit confusing. Orange agreed that the requirement given by SA1 was confusing. Qualcomm proposed to work on a response for this meeting and see if this could be agreed to be sent.
 		replied to No    
    S3‑161966 Reply to: LS on "Attach procedure for Remote SIM Provisioning” Qualcomm LS out approval Yes
Yes
 		approved No    
    S3‑161945 LS on “Next Generation” Security Requirements SA3-LI LS in   Yes
YesVodafone commented that this would be useful to be included in TR 33.899. Qualcomm: create a contribution for the next meeting. Nokia: we have identities other than humans now (e.g. cars), so has LI considered this? BT: vehicles that cannot be targeted would be not sold in some countries.The requirement does extend to non human entities.
 		noted No    
    S3‑161923 Request to SA3 to take the 3GPP TR 33.899 study item forward as a work item for Release 15 Mobile Manufacturers Forum LS in   Yes
YesNick (Blackberry) presented this contribution. MMF would like SA3 to progress work in Key Issue 2.4: Equipment Identifier Authentication work and is willing to cooperate with them. It was commented that there wasn't much to say now, just that SA3 is working on it. Sander (KPN) proposed to check if all these requirements are captured in our key issue for the next meeting. Blackberry proposed to work on a response.
 		replied to No    
    S3‑161967 Reply to: Request to SA3 to take the 3GPP TR 33.899 study item forward as a work item for Release 15 Blackberry LS out approval No
Yes
 		approved No    
    S3‑161676 DoS from External Network Huawei, HiSilicon pCR   Yes
Yes
 		revised No S3‑162136  
    S3‑162136 DoS from External Network Huawei, HiSilicon pCR - Yes
Yes
 		approved No   S3‑161676
    S3‑161640 Discussion on key-free secured pairing and protected radio access to network THALES discussion   Yes
Yes
 		not treated No   S3‑161427
    S3‑162019 Use Cases from TR 22.862 (Enablers for Critical Communications) 3GPP SA1 discussion Presentation Yes
YesSlides from the joint session between SA1 and SA3.
 		noted No    
    S3‑162122 Base document for discussion of priorisation of key issues Zugenmaier, Alf tdoc number 09:30 18 KB NTT-Docomo discussion discussion Yes
YesConference calls to be held: - RAN2 light connection. Nokia takes the lead. - DONAS. - BEST normative work. Vodafone. - NSA topics after the prioritzation call. Calls to be held by End of November, beginning of December. This document will be discussed during the conference calls.
 		noted No    
    S3‑162137 Minutes from joint SA1/SA3 meeting MCC report Information No
Yes
 		noted No    
    S3‑162138 TR 33.899 Ericsson draft TR Approval No
Yes
 		left for email approval No    
    S3‑162139 Short notes from Joint session SA1-SA3 SA1 WG Chair report Information No
Yes
 		noted No    
8.7 Study on Mission Critical Security Enhancements (FS_MC_Sec) S3‑161647 [MC_Sec] Key Issue on Multiple Security Domains CESG (NCSC) pCR Approval Yes
Yes
 		revised No S3‑161985  
    S3‑161985 [MC_Sec] Key Issue on Multiple Security Domains CESG (NCSC) pCR Approval Yes
Yes
 		approved No   S3‑161647
    S3‑161648 [MC_Sec] Solution on Multiple Security Domains CESG (NCSC) pCR Approval Yes
Yes
 		revised No S3‑161986  
    S3‑161986 [MC_Sec] Solution on Multiple Security Domains CESG (NCSC) pCR Approval Yes
Yes
 		approved No   S3‑161648
    S3‑161621 pCR 33.880 MCVideo and MCPTT common requirements Motorola Solutions Danmark A/S pCR Approval Yes
Yes
 		approved No    
    S3‑161610 pCR 33.880 MCVideo proposal Motorola Solutions Danmark A/S pCR Approval Yes
YesMCC commented that the text in the spec should release agnostic regardless of it being a TR. All references to Releases need to be removed. Tim (Motorola) warned that any change in the Rel-13 version of MCPTT will have to be taken to Rel-14 with pCRs.
 		revised No S3‑162001  
    S3‑162001 pCR 33.880 MCVideo proposal Motorola Solutions Danmark A/S pCR Approval Yes
Yes
 		approved No   S3‑161610
    S3‑161649 [MC_Sec] Key Issue on MCData SDS Security CESG (NCSC) pCR Approval Yes
Yes
 		approved No    
    S3‑161650 [MC_Sec] Solution for MCData SDS key management within signalling CESG (NCSC) pCR Approval Yes
Yes
 		approved No    
    S3‑161651 [MC_Sec] Solution for MCData SDS key management alongside messages CESG (NCSC) pCR Approval Yes
Yes
 		revised No S3‑162004  
    S3‑162004 [MC_Sec] Solution for MCData SDS key management alongside messages CESG (NCSC) pCR Approval Yes
Yes
 		approved No   S3‑161651
    S3‑162002 Alignment with Rel-13 CESG pCR Approval Yes
Yes
 		approved No    
    S3‑162003 LS on MC data prioritization and questions Motorola Solutions LS out Approval Yes
Yes
 		approved No    
    S3‑162005 TR 33.880 CESG draft TR Approval Yes
Yes
 		approved No    
8.8.1 Study on Subscriber Privacy Impact in 3GPP (SPI)                      
8.8.2 Security Assurance Specification for 3GPP network product classes (33.926) (SCAS) S3‑161931 NESAS Pilot Release Documents GSMA SECAG LS in   Yes
YesIt was encouraged to provide feedback to SA3 or directly to GSMA.
 		noted No    
8.8.3 Study on Battery Efficient Security for very low Throughput Machine Type Communication Devices S3‑161880 BEST: Clarifying potential impact of Solution 8 on PGW Nokia, Vodafone CR Approval Yes
Yes
 		not treated No    
    S3‑161950 solutions 11 & 12 guarantee one-to-one mapping of GUTI and current Ks Huawei, Hisilicon CR   Yes
Yes
 		revised No S3‑161995  
    S3‑161995 solutions 11 & 12 guarantee one-to-one mapping of GUTI and current Ks Huawei, Hisilicon CR - Yes
Yes
 		not treated No   S3‑161950
    S3‑161951 How solutions 11 & 12 guarantee one-to-one mapping of GUTI and current Ks Huawei, Hisilicon discussion Discussion Yes
Yes
 		not treated No    
8.8.4 Other study items S3‑161742 New SID on security aspect of architecture enhancements to ProSe UE-to-Network Relay Huawei, Hisilicon SID new   Yes
Yes
 		revised No S3‑162104  
    S3‑162104 New SID on security aspect of architecture enhancements to ProSe UE-to-Network Relay Huawei, Hisilicon SID new - No
Yes
 		not treated No   S3‑161742
    S3‑161790 Discussion on a method to prevent fake base stations China Mobile Com. Corporation discussion Discussion Yes
Yes
 		not treated No    
9 Review and Update of Work Plan S3‑161603 SA3 Work Plan MCC Work Plan   Yes
Yes
 		noted No    
    S3‑161606 Work Plan input from Rapporteurs MCC other   Yes
Yes
 		revised No S3‑162125  
    S3‑162125 Work Plan input from Rapporteurs MCC other - No
Yes
 		noted No   S3‑161606
10 Future Meeting Dates and Venues S3‑161605 SA3 meeting calendar MCC other   Yes
YesMCC pointed out that the 2018 dates should be decided during the next SA3 meeting.
 		noted No    
11 Any Other Business