Tdoc List

2017-02-10 16:13

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‑170000 Agenda WG Chairman agenda   Yes
Yes
 		approved No    
3 IPR Reminder                      
4 Meeting Reports                      
4.1 Approval of the report from SA3#84 and SA3#84 bis S3‑170001 Report from SA3#85 MCC report   Yes
Yes
 		approved No    
4.2 Report from SA #73 S3‑170003 Report from last SA meeting WG Chairman report   Yes
Yes
 		noted No    
4.3 Report from SA3-LI                      
5 Items for early consideration S3‑170129 New SID on security aspect of architecture enhancements to ProSe UE-to-Network Relay Huawei, HiSilicon SID new   Yes
YesNokia: in our 5G TR we have a key issue with the connection with relays. This is overlapping with that key issue, not new. Huawei: this is purely for LTE. NTT-Docomo: how long time per meeting for this SID? The Chair commented that this would go for Rel-15 deadlines. Broadcom: WLAN access for the relay here. Is SA3 taking a separate WID for the WLAN discovery? Huawei: this part could be included. Qualcomm: this is building on SA2 study. Broadcom: the WLAN part is a separate WID in SA2. We should have a separate study for this. The Chair commented that a separate SID for the WLAN part would be better. ORANGE didn’t agree with the study going through the provisioning if there was no SA1 requirement involved. This had to be more specific. Nokia:
 		revised No S3‑170355  
    S3‑170355 New SID on security aspect of architecture enhancements to ProSe UE-to-Network Relay Huawei, HiSilicon SID new - Yes
Yes
 		agreed No   S3‑170129
6 Reports and Liaisons from other Groups                      
6.1 3GPP Working Groups S3‑170016 LS on potential security issues for access to restricted local operator services by unauthenticated Ues S1-163436 LS in   Yes
YesVodafone: the 5G TR has an answer for question 1. No response for the rest. Since the SID was confirmed to be finished in June, there was still time to respond to the LS.
 		replied to No    
    S3‑170409 Reply to: LS on potential security issues for access to restricted local operator services by unauthenticated Ues Nokia LS out approval Yes
YesSprint: we can’t say that we don’t want to support this. It's a mandate to mitigate DDOS attacks. Alf: If a scheduler avoids the DDOS, we don’t need to standardise anything if it can be done. AT&T: thresholding would clamp that amount of traffic. The only traffic higher would be government priority services. Granulating access class barring within the HPA (High Priority Access) classes would be a tool to control that traffic.
 		approved No    
    S3‑170021 Reply LS on external interface for TV services S4h160679 LS in   Yes
Yes
 		replied to No    
    S3‑170356 Reply to: Reply LS on external interface for TV services Qualcomm LS out approval Yes
Yes
 		approved No    
    S3‑170066 LS on xMB Interface for TV Services C3A170068 LS in   Yes
YesEricsson commented that SA3 needed more time to analyse this, at least another meeting cycle. Qualcomm agreed.
 		replied to No    
    S3‑170170 Reply LS on xMB Interface for TV Services S4-170240 LS in   Yes
Yes
 		noted No    
    S3‑170036 Reply LS on UE-to-NW relaying S2 170398 LS in   Yes
YesNokia commented that the question refers to layer 3 security. Some time was needed to study the question from SA2, so this was postponed.
 		postponed No    
    S3‑170038 LS on standardization of Northbound SCEF API S2 170647 LS in   Yes
YesBT commented that in the case of BEST, the security for the northbound interface needs further discussion. What security parameters are passed through this interface?
 		replied to No    
    S3‑170357 Reply to: LS on standardization of Northbound SCEF API BT Group LS out approval Yes
Yes
 		approved No    
    S3‑170084 LS on security of information provided via ANQP or DNS C1-170512 LS in   Yes
Yes
 		replied to No    
    S3‑170085 LS on applicability of WLAN emergency numbers on 3GPP access C1-170513 LS in   Yes
Yes
 		noted No    
    S3‑170344 Discussion of S3-170084 (CT1 LS on security of information provided via ANQP or DNS) BlackBerry UK Limited discussion Information Yes
YesBT Group: location information can be hard to get. Is there any requirements for how accurate the location information is? Blackberry: the SIM of the UE can have configured the emergency number of the countries where it is roaming. Broadcom: why is it a problem if we have management network in place also for the untrusted network? NTT docomo: it's an untrusted access point. It's an issue to trust it. Qualcomm: we cannot secure this information wherever it is sent to. DNS sec could work in this case.Ericsson agreed. Qualcomm: You don’t have the credentials to authenticate in this emergency call process.
 		noted No    
    S3‑170345 [DRAFT] Response LS to S3-170084 (C1-170512) LS on security of information provided via ANQP or DNS BlackBerry UK Limited LS out Approval Yes
Yes
 		revised No S3‑170358  
    S3‑170358 Response LS to S3-170084 (C1-170512) LS on security of information provided via ANQP or DNS BlackBerry UK Limited LS out Approval Yes
Yes
 		approved No   S3‑170345
    S3‑170178 Reply LS on “Conclusion on lawful interception in split EPC architecture” S3i170041 LS in   Yes
Yes
 		noted No    
    S3‑170353 Analysis on LTE Call redirection Nokia discussion discussion Yes
Yes
 		noted No    
    S3‑170365 Reply LS on SA2 involvement for the light connection s3i170035 LS in discussion Yes
Yes
 		noted No    
6.2 IETF                      
6.3 ETSI SAGE                      
6.4 GSMA S3‑170011 LS to RIFS and SA3 on Diameter Security GSMA PACKET LS in   Yes
YesBT: this is linked to the Ipx issue and SH8R. Certain interfaces are exposed. Nokia: multi-Tier, multihop, interconnection is quite complex to handle. It was decided to postpone the document and come up wtih an analysis for the next meeting.
 		postponed No    
    S3‑170012 LS reply to 3GPP – Completion LI study on S8HR GSMA PSMC LS in   Yes
Yes
 		noted No    
6.5 3GPP2                      
6.6 OMA                      
6.7 TCG S3‑170025 TCG progress report INTERDIGITAL COMMUNICATIONS other Information Yes
Yes1. TCG – Highlights • New/modified work items o TNC IF-MAP Concise Binding – CBOR (RFC 7049) – ongoing for 2017 public review Highlights: • Publication of new or revised deliverables o Preview synopsis of TCG Network Equipment SG http://www.trustedcomputinggroup.org/wp-content/uploads/NetEq-Synopsis_1_0r3.pdf o TCG TPM 2.0 PC Client Platform TPM Profile – public review January 2017 o TCG TPM 2.0 PC Client Platform Firmware Profile – public review January 2017 o TCG TPM 2.0 Hardware Requirements for DICE – public review December 2016 o TCG TPM 2.0 I2C Interface Specification v1.0 – TCG published October 2016 o TCG TPM 2.0 Library v1.36 – public review September 2016TCG FIPS 140-2 Guidance for TPM 2.0 – TCG public review August 2016 – important for NFV SEC for Common Criteria certification Meetings: TCG Members Meeting in San Diego, CA – 6-10 February 2017 TCG Members Meeting in Hamburg, Germany – June 12-15, 2017 TCG Members Meeting in Vancouver, BC – October 23-26, 2017 MPWG meets every Thursday at 10-11 ET TMS WG meets every Monday and Friday at 12-13 ET
 		noted No    
6.8 oneM2M                      
6.9 TC-CYBER                      
6.10 ETSI NFV security                      
6.11 Other Groups S3‑170010 LS First set of Architecture Principles from the NGMN P1 E2E Architecture Framework project. NGMN LS in   Yes
Yes
 		noted No    
7 Work Areas                      
7.1 Security Assurance (Rel-14)                      
7.1.1 Security Assurance Specification for 3GPP network product classes (General, TS 33.117) (SCAS-SA3) S3‑170307 Updates to HTTP User Session testcase to decrease maintenance and increase assurance Ericsson CR Approval Yes
YesAlf (Docomo): for a DIEHARD test you need a couple hundreds of megabytes.
 		not pursued No    
    S3‑170467 Updates to HTTP User Session testcase to decrease maintenance and increase assurance Ericsson CR Approval No
No
 		withdrawn Yes    
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‑170216 Adding the examples of the security functional requirements in the section 4.2.2.1 of TS33.250 China Mobile Com. Corporation pCR Approval Yes
YesAlf (Docomo): we need to define uniqueness here. China Mobile: the uniqueness here is a separate issue.Besides, the following clause is about uniqueness. Nokia didn’t support the uniqueness for billing purposes. China Mobile replied that this uniqueness is in the TS already. It was argued that there was an overlap with 342 (TIM), but China Mobile and Ericsson didn’t see it like that.
 		revised No S3‑170468  
    S3‑170468 Adding the examples of the security functional requirements in the section 4.2.2.1 of TS33.250 China Mobile Com. Corporation pCR Approval Yes
Yes
 		approved No   S3‑170216
    S3‑170232 Adding the security requirements in the section 4.2.3, 4.3.2 and 4.4 of TS33.250 China Mobile Com. Corporation pCR Approval Yes
Yes
 		approved No    
    S3‑170142 Adding PGW Annex to TR 33.926 Huawei; Hisilicon other   Yes
YesThis is a living document where threats will be added. Eventually all will be included in 33.250 in a super CR.
 		approved No    
    S3‑170143 Adding the threats about the IP address reallocation continuously in the PGW Annex of TR33.926 Huawei; Hisilicon other   Yes
YesApproved to be included in the Draft CR.
 		approved No    
    S3‑170140 Adding the security requirements of IP address reallocation interval Huawei; Hisilicon; China Mobile pCR   Yes
YesNokia: is this the only mechanism to address the threat? Should this requirement be mandated or there are other countermeasures? This was added in an Editor's note.
 		revised No S3‑170470  
    S3‑170470 Adding the security requirements of IP address reallocation interval Huawei; Hisilicon; China Mobile pCR - Yes
Yes
 		approved No   S3‑170140
    S3‑170144 Adding the threats about the UE-mutual access Annex Y of TR33.926 Huawei; Hisilicon other   Yes
YesApproved to be included in the Draft CR.
 		approved No    
    S3‑170139 Adding the security requirements of mutual access prevention Huawei; Hisilicon; China Mobile pCR   Yes
YesMCC: remove the requirement from the Note.
 		revised No S3‑170472  
    S3‑170472 Adding the security requirements of mutual access prevention Huawei; Hisilicon; China Mobile pCR - Yes
Yes
 		approved No   S3‑170139
    S3‑170342 Adding requirement within 3GPP TS 33.250 on unpredictable TEID generated by the PGW. TELECOM ITALIA S.p.A. pCR Approval Yes
YesEricsson: not sure that the threat is existing. Deutsche Telekom: similar to TCP spoofing, the threats exists. This was taken offline.
 		noted No   S3‑170081
    S3‑170082 Adding test case for the requirement on unpredictable TEID generated by the PGW TELECOM ITALIA S.p.A. pCR Approval Yes
Yes
 		noted No    
    S3‑170081 Adding requirement within 3GPP TS 33.250 on unpredictable TEID generated by the PGW TELECOM ITALIA S.p.A. pCR Approval Yes
Yes
 		revised No S3‑170342  
    S3‑170469 Draft CR Aspects to the network product class PGW Huawei draftCR Approval No
Yes
 		left for email approval No    
    S3‑170473 Draft TS 33.250 China Mobile draft TS Approval No
Yes
 		left for email approval No    
    S3‑170493 Cover sheet TS 33.250 China Mobile TS or TR cover 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‑170141 Adding eNB Annex to TR 33.926 Huawei; Hisilicon other   Yes
YesApproved to be included in the Draft CR.
 		approved No   S3‑170118
    S3‑170145 pCR_Threats related to control plane and user plane NEC EUROPE LTD pCR Approval Yes
Yes
 		revised No S3‑170475  
    S3‑170475 pCR_Threats related to control plane and user plane NEC EUROPE LTD pCR Approval Yes
Yes
 		approved No   S3‑170145
    S3‑170148 pCR to TS 33.216_ Control plane data confidentiality protection NEC EUROPE LTD pCR Approval Yes
YesNokia didn't think that the test worked with these preconditions (the tester will have access to the keys).
 		revised No S3‑170479  
    S3‑170479 pCR to TS 33.216_ Control plane data confidentiality protection NEC EUROPE LTD pCR Approval Yes
Yes
 		approved No   S3‑170148
    S3‑170149 pCR to TS 33.216_ Control plane data integrity protection NEC EUROPE LTD pCR Approval Yes
Yes
 		merged No S3‑170479  
    S3‑170150 pCR to TS 33.216_ User plane data ciphering and deciphering at eNB NEC EUROPE LTD pCR Approval Yes
Yes
 		merged No S3‑170479  
    S3‑170151 pCR to TS 33.216_ User plane data integrity protection NEC EUROPE LTD pCR Approval Yes
Yes
 		merged No S3‑170479  
    S3‑170146 pCR _Threats related to security algorithm selection during handover NEC EUROPE LTD pCR Approval Yes
YesDeutsche telekom and Ericsson found it unclear.
 		noted No    
    S3‑170154 pCR to TS 33.216_ AS security algorithm selection during UTRAN to E-UTRAN handover NEC EUROPE LTD pCR Approval Yes
Yes
 		noted No    
    S3‑170155 pCR to TS 33.216_ AS security Algorithm selection during intra-eNB handover NEC EUROPE LTD pCR Approval Yes
Yes
 		noted No    
    S3‑170147 pCR_Threats related to security mode command procedure NEC EUROPE LTD pCR Approval Yes
YesEricsson: this is not a threat, who attacks? NEC: bidding down attack by a rogue eNodeB. Deutsche Telekom had similar problems to understand this test case.
 		noted No    
    S3‑170152 pCR to TS 33.216_ Initial AS ciphering algorithm selection and use NEC EUROPE LTD pCR Approval Yes
Yes
 		noted No    
    S3‑170153 pCR to TS 33.216_ Initial AS integrity algorithm selection and use NEC EUROPE LTD pCR Approval Yes
Yes
 		noted No    
    S3‑170118 Adding eNB Annex to TR 33.926 Huawei; Hisilicon pCR   Yes
Yes
 		revised No S3‑170141  
    S3‑170474 Draft CR Aspect specific to the network product class eNB Huawei draftCR Approval No
Yes
 		left for email approval No    
    S3‑170480 TS 33.216 Huawei draft TS Approval No
Yes
 		left for email approval No    
7.1.5 Other                      
7.2 New GPRS algorithms for EASE (EASE_ALGOs_SA3) S3‑170029 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
 		revised No S3‑170369 S3‑161953
    S3‑170369 Draft TS 55.242 - Specification of the GIA4 integrity algorithm for GPRS - Implementers test data - (Release 14) VODAFONE Group Plc draft TS Agreement No
Yes
 		left for email approval No   S3‑170029
    S3‑170179 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
 		revised No S3‑170370  
    S3‑170370 Draft TS 55.243 - Specification of the GIA4 integrity algorithm for GPRS - Design conformance test data - (Release 14) VODAFONE Group Plc draft TS Agreement No
Yes
 		left for email approval No   S3‑170179
    S3‑170180 Draft 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
 		revised No S3‑170371  
    S3‑170371 Draft 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 No
Yes
 		left for email approval No   S3‑170180
    S3‑170182 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
 		revised No S3‑170372  
    S3‑170372 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 No
Yes
 		left for email approval No   S3‑170182
    S3‑170373 Cover Draft TS 55.242 Vodafone TS or TR cover Approval No
Yes
 		left for email approval No    
    S3‑170374 Cover Draft TS 55.243 Vodafone TS or TR cover Approval No
Yes
 		left for email approval No    
    S3‑170375 Cover Draft TS 55.252 Vodafone TS or TR cover Approval No
Yes
 		left for email approval No    
    S3‑170376 Cover Draft TS 55.253 Vodafone TS or TR cover Approval No
Yes
 		left for email approval No    
7.3 Support of EAP Re-Authentication Protocol for WLAN Interworking (ERP) (Rel-14) S3‑170360 Work Item exception for EARP ORANGE WI exception request Agreement No
No
 		withdrawn Yes    
    S3‑170434 Remove EN related to ERP information in the HSS ORANGE,Broadcom,Ericsson,Motorola Mobility,Lenovo CR Agreement Yes
Yes
 		agreed No    
7.4 Security of the Mission Critical Service (MCSec) (Rel-14) S3‑170083 Completion of Mission Critical WIs for Rel-14 C1-165319 LS in   Yes
Yes
 		noted No    
    S3‑170024 LS Reply on Terminology used by SA6 for Mission Critical Services S6-161621 LS in   Yes
Yes
 		noted No    
    S3‑170009 Reply LS on MCData prioritization and questions C1-165427 LS in   Yes
Yes
 		replied to No    
    S3‑170411 Reply to: Reply LS on MCData prioritization and questions Motorola Solutions LS out approval Yes
Yes
 		approved No    
    S3‑170023 MCData prioritisation responses S6-161612 LS in   Yes
Yes
 		noted No    
    S3‑170035 LS on Response to MCData questions in S6a170113 S6a170186 LS in   Yes
Yes
 		replied to No    
    S3‑170086 LS on security solution for MCdata SDS communications C1-170481 LS in   Yes
Yes
 		replied to No    
    S3‑170099 pCR 33.180 EN in clause 5.4 Motorola Solutions Danmark A/S pCR Approval Yes
Yes
 		approved No    
    S3‑170100 pCR 33.180 Integrity protection and client_id Motorola Solutions Danmark A/S pCR Approval Yes
Yes
 		revised No S3‑170413  
    S3‑170413 pCR 33.180 Integrity protection and client_id Motorola Solutions Danmark A/S pCR Approval Yes
Yes
 		approved No   S3‑170100
    S3‑170319 [MCSEC] Rewrite of key management procedures NCSC (CESG) pCR Approval Yes
Yes
 		approved No    
    S3‑170414 TR 33.180 CESG draft TR Approval No
Yes
 		approved No    
    S3‑170486 pCR 33.180 MCData SDS security solution Motorola Solutions pCR Approval Yes
Yes
 		approved No    
7.5 Security aspect of architecture enhancements for LTE support of V2X services (V2XLTE-Sec) (Rel-14) S3‑170348 V2X TS Skeleton Huawei, HiSilicon draft TS Approval Yes
Yes
 		approved No   S3‑170334
    S3‑170188 TS structure Nokia pCR Approval Yes
Yes
 		merged No S3‑170424  
    S3‑170288 Proposed text for V2X TS Qualcomm Incorporated pCR Approval Yes
YesNokia: V2 interface is out of scope of 3GPP. We don’t need to write the requirement. Gemalto: requirements on the secure environment are not clear. What’s the criteria here?
 		revised No S3‑170425  
    S3‑170425 Proposed text for V2X TS Qualcomm Incorporated,Nokia pCR Approval Yes
Yes
 		approved No   S3‑170288
    S3‑170336 V2X TS Scope Huawei, HiSilicon pCR Approval Yes
Yes
 		approved No    
    S3‑170335 V2X TS Reference Huawei, HiSilicon pCR Approval Yes
YesReferences 2 and 3 will be removed during implementation.
 		approved No    
    S3‑170189 Intro TS Nokia pCR Approval Yes
Yes
 		merged No S3‑170425  
    S3‑170190 Requirements on control plane Nokia pCR Approval Yes
Yes
 		merged No S3‑170425  
    S3‑170193 V3 interface Nokia pCR Approval Yes
Yes
 		merged No S3‑170425  
    S3‑170191 MB2 for V2X Nokia pCR Approval Yes
Yes
 		merged No S3‑170425  
    S3‑170192 NDS between network elements Nokia pCR Approval Yes
Yes
 		merged No S3‑170425  
    S3‑170334 V2X TS Skeleton Huawei, HiSilicon draft TS Approval Yes
Yes
 		revised No S3‑170348  
    S3‑170424 TS 33.185 Huawei draft TS Approval No
Yes
 		left for email approval No    
    S3‑170494 Cover sheet TS 33.185 Huawei TS or TR cover Approval No
Yes
 		left for email approval No    
    S3‑170495 Exception sheet V2X Huawei WI exception request Agreement No
Yes
 		left for email approval No    
7.6 Other work areas                      
7.6.1 SAE/LTE Security S3‑170014 LS on LTE call redirection to GERAN R2-169124 LS in   Yes
YesBT pointed out that according to tdoc R2-1689356 there were some security improvements where SA3 could have a say.This was postponed.
 		postponed No    
    S3‑170015 LS on RAN2 decisions for eLWA mobility R2-169139 LS in   Yes
Yes
 		replied to No    
    S3‑170087 LS on unauthenticated emergency session over Trusted WLAN C1-170384 LS in   Yes
Yes
 		replied to No    
    S3‑170483 Reply to: LS on unauthenticated emergency session over Trusted WLAN Ericsson LS out approval Yes
Yes
 		approved No    
    S3‑170107 eLWA: Discussion on LS R2-169139 Nokia Germany discussion Agreement Yes
Yes
 		noted No    
    S3‑170108 draft_Reply LS to RAN2 on eLWA R2-169139 Nokia Germany LS out Approval Yes
YesEricsson wanted more time to check this. Qualcomm: some of this is out of scope of 3GPP since it refers to WLAN user id. This was taken offline. It was agreed that a CR would be prepared for the next SA3 meeting.
 		revised No S3‑170482  
    S3‑170482 Reply LS to RAN2 on eLWA R2-169139 Nokia Germany LS out Approval Yes
Yes
 		approved No   S3‑170108
    S3‑170109 LWA Correction on 3GPP vendor id Nokia Germany CR Approval Yes
Yes
 		agreed No    
    S3‑170116 Privacy Protection for EAP-AKA Apple (UK) Limited discussion Discussion Yes
YesNokia: the solution is OK. We would like to have a solution not only for WiFi. Let's have an agreement with 5G and then implement in the WiFi part. Qualcomm: this problem needs to be solved in 5G as well. We agree. Apple: the most likely outcome for 5G would be something like this. We have to start somewhere. If we agree for the ePDG we can do something similar for other networks. Nokia: let's make this part of a 5G solution and then go from there. Apple: there is a solution in 5G already that is aligned with this: 7.3. Qualcomm: there are several solutions but we haven’t selected any. BT: it doesn’t support VPLMN roaming LI. It needs some tweaking. It was agreed to bring this into 5G.
 		noted No   S3‑161664
    S3‑170117 Privacy Protection for EAP-AKA Apple (UK) Limited CR Approval Yes
Yes
 		not pursued No   S3‑161666
7.6.2 IP Multimedia Subsystem (IMS) Security                      
7.6.3 Network Domain Security (NDS) S3‑170217 3GPP security profile update – 43.318 (GAN), Variant 1 Ericsson draftCR   Yes
Yes
 		noted No    
    S3‑170218 3GPP security profile update – 43.318 (GAN), Variant 2 Ericsson draftCR   Yes
YesThis is the preferred option for Ericsson. To be included in an LS for RAN6 so the CR can be created and agreed in there.
 		approved No    
    S3‑170484 Removal of exceptions of security profile in 43.318 Ericsson LS out Approval Yes
Yes
 		approved No    
7.6.4 UTRAN Network Access Security S3‑170007 LS on Legacy Security Issues C1-164579 LS in   Yes
Yes
 		noted No    
    S3‑170008 Response LS on Legacy Security Issues R6-160125 LS in   Yes
Yes
 		noted No    
    S3‑170262 AKA: 256-bit input key K Gemalto N.V. CR Agreement Yes
Yes
 		agreed No    
7.6.5 GERAN Network Access Security                      
7.6.6 Generic Authentication Architecture (GAA)                      
7.6.7 Multimedia Broadcast/Multicast Service (MBMS)                      
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‑170034 Answers to questions from CT1 joint session on Release 14 MCPTT S6a170172 LS in   Yes
Yes
 		noted No    
    S3‑170096 CR 33.179 EN in clause 5.4. Motorola Solutions Danmark A/S CR Agreement Yes
Yes
 		agreed No    
    S3‑170097 CR 33.179 EN in clause 5.5.1. Motorola Solutions Danmark A/S CR Agreement Yes
Yes
 		agreed No    
    S3‑170098 33.179 Integrity protection and client_id Motorola Solutions Danmark A/S CR Agreement Yes
Yes
 		revised No S3‑170418  
    S3‑170418 33.179 Integrity protection and client_id Motorola Solutions Danmark A/S CR Agreement Yes
Yes
 		agreed No   S3‑170098
    S3‑170320 [MCPTT] Correction to clause reference in TS 33.179 NCSC (CESG) 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‑170169 Correction of protected IOV container Intel Corporation (UK) Ltd CR Approval Yes
Yes
 		agreed No    
    S3‑170171 Correction of protected IOV container Intel Corporation (UK) Ltd CR Approval Yes
Yes
 		agreed No    
7.6.14 Security Aspects of Narrowband IOT (CIoT) S3‑170013 LS on mobility enhancements for NB-IoT R2-169115 LS in   Yes
YesNokia: there are threats in other scenarios, it is our job to analize the other threats. It was agreed to create a CR to perform this work.
 		replied to No    
    S3‑170485 Reply to: LS on mobility enhancements for NB-IoT Nokia LS out approval Yes
Yes
 		approved No    
    S3‑170077 Discussion on security method of mobility enhancement for NBIoT CP solution ZTE Corporation discussion Discussion Yes
Yes
 		noted No    
    S3‑170079 Security method of mobility enhancement for NBIoT CP solution ZTE Corporation CR Approval Yes
Yes
 		not pursued No    
    S3‑170110 NBIoT:DoNAS threat analysis Nokia Germany discussion Agreement Yes
Yes
 		noted No    
    S3‑170111 NBIoT: DoNAS security solution for large file download Nokia Germany discussion Agreement Yes
Yes
 		noted No    
    S3‑170112 Correct the Ref to NAS Spec (map CR) Nokia Germany CR Approval Yes
Yes
 		agreed No    
    S3‑170162 Security of RRC Connection re-establishment of NB-IOT for CP Solution Intel Corporation (UK) Ltd discussion Decision Yes
Yes
 		revised No S3‑170352  
    S3‑170352 Security of RRC Connection re-establishment of NB-IOT for CP Solution Intel Corporation (UK) Ltd discussion Decision Yes
Yes
 		noted No   S3‑170162
    S3‑170166 Comparison of Solution proposals for security of RRC messages for CIoT Optimization Intel Corporation (UK) Ltd discussion Decision Yes
Yes
 		noted No    
    S3‑170346 Comments on S3-170166 Comparison of solutions proposals for RRC messages for CIoT Optimization Nokia discussion Agreement Yes
Yes
 		noted No    
    S3‑170242 Building block work item: Security Enhancements of NB-IoT China Mobile Com. Corporation WID new Agreement Yes
YesThere was no support for this WID.
 		noted No    
    S3‑170254 A solution for RLF in CP NB-IoT Ericsson discussion Approval Yes
Yes
 		noted No    
    S3‑170256 RRC re-establishment for CP NB-IoT Ericsson CR   Yes
Yes
 		not pursued No    
    S3‑170302 Protecting the RLF procedure for NB-IoT UEs using the NAS security context Qualcomm Incorporated other Approval Yes
Yes
 		noted No    
    S3‑170332 DoNAS security solution Huawei, HiSilicon discussion Approval Yes
Yes
 		noted No    
7.6.15 Battery Efficient Security for very low Throughput Machine Type Communication Devices (BEST_MTC_Sec) S3‑170172 Update of progress on BEST normative work and open questions VODAFONE Group Plc discussion Discussion No
No
 		withdrawn Yes    
    S3‑170173 CR to TS 33.401 for BEST revised for modularisation VODAFONE Group Plc CR Agreement Yes
Yes
 		postponed No    
    S3‑170174 BEST: Exposing User plane protocol information at the Key Management layer Nokia discussion Discussion Yes
YesVodafone disagreed with this. Nokia: this refers to solution 10, key agreement, that Vodafone doesn’t support.
 		noted No    
    S3‑170175 BEST: Handling of key synchronization issues in Solution 10 Nokia discussion Discussion Yes
Yes
 		noted No    
    S3‑170176 proposed LS to CT4 on extension of the S6 interface for BEST VODAFONE Group Plc LS out Agreement No
No
 		withdrawn Yes    
    S3‑170183 Allocation of FC values for BEST KPN, Vodafone CR Agreement Yes
Yes
 		postponed No   S3‑161743
    S3‑170185 Adding BEST Service to TS 33.401 KPN, Vodafone CR Agreement Yes
YesSuperseeded by 173.
 		not pursued No   S3‑161849
    S3‑170260 BEST: CR to fix an error in Figure 6.10.2.3 of Solution #10 Nokia CR Approval Yes
Yes
 		revised No S3‑170487  
    S3‑170487 BEST: CR to fix an error in Figure 6.10.2.3 of Solution #10 Nokia CR Approval Yes
Yes
 		agreed No   S3‑170260
7.6.16 Other work items S3‑170238 Parameter transport for unauthenticated emergency calls over trusted WLAN, using vendor-specific EAP-method Ericsson CR Agreement Yes
Yes
 		revised No S3‑170476  
    S3‑170476 Parameter transport for unauthenticated emergency calls over trusted WLAN, using vendor-specific EAP-method Ericsson CR Agreement Yes
Yes
 		agreed No   S3‑170238
    S3‑170239 List of 3GPP vendor-specific EAP methods Ericsson CR Agreement Yes
Yes
 		agreed No    
8 Studies                      
8.1 TR on Security Assurance scheme for 3GPP network products (33.916) (SCAS-SA3TR) (Rel-14) S3‑170341 The evaluation of a new version of a 3GPP network product China Mobile Com. Corporation pCR Approval Yes
Yes
 		revised No S3‑170350  
    S3‑170350 The evaluation of a new version of a 3GPP network product China Mobile Com. Corporation pCR Approval Yes
YesThe content was agreed but it was noted that this document should go into 33.916 as a CR, not a pCR. A new tdoc number was given to create such CR: 481.
 		noted No   S3‑170341
    S3‑170481 The evaluation of a new version of a 3GPP network product China Mobile,Nokia CR Agreement Yes
Yes
 		agreed No    
8.2 Study on IMS Enhanced Spoofed Call Prevention and Detection (FS_ESCAPADES) (Rel-14)                      
8.3 Study on security aspects for LTE support of V2X services (FS_V2XLTE) (Rel-14) S3‑170322 V2X discussion for way forward LG Electronics discussion Discussion Yes
Yes
 		noted No    
    S3‑170287 Some proposed conclusions for V2X TR Qualcomm Incorporated pCR Approval Yes
Yes
 		revised No S3‑170420  
    S3‑170420 Some proposed conclusions for V2X TR Qualcomm Incorporated pCR Approval Yes
Yes
 		approved No   S3‑170287
    S3‑170330 Conclusion of V3 Interface Security Huawei, HiSilicon pCR Approval Yes
YesEricsson didn’t agree with the comparison table: This requires a IF for roaming between HSS and VCF, and SA2 hasn’t specified it. This causes an impact on the architecture. Huawei: GBA is not deployed so this solution is not deployed. Gemalto: GBA was used for Prose, it's not true that it is not deployed. Ericsson: we cannot agree with the conclusion.
 		revised No S3‑170419  
    S3‑170419 Conclusion of V3 Interface Security Huawei, HiSilicon pCR Approval Yes
Yes
 		approved No   S3‑170330
    S3‑170324 Conclusion on V2X UE Authorization LG Electronics pCR Approval Yes
Yes
 		revised No S3‑170421  
    S3‑170421 Conclusion on V2X UE Authorization LG Electronics pCR Approval Yes
Yes
 		approved No   S3‑170324
    S3‑170325 Conclusion for V2X Entities Secure Environment LG Electronics pCR Approval Yes
YesGemalto: there are requirements to store the credentials for the access.This needs to be checked. Deutsche Telekom: the key issue talks about the UE side. This is not addressed here. Nokia: what happens with the rest of the secure environment? Is it defined elsewhere? LG: we can give recommendations. There are no detailed solutions to our requirements in ETSI ITS. Huawei: the only issue is on the UE side, not on the network entities. Nokia: we still have editor's notes.
 		noted No    
    S3‑170331 PC5 Interface Security Huawei, HiSilicon pCR Approval Yes
YesDeutsche Telekom supported this proposal. Ericsson had issues with using the solution in 6.1. Nokia didn’t support the interim agreement either. This had to be taken offline.
 		revised No S3‑170422  
    S3‑170422 PC5 Interface Security Huawei, HiSilicon pCR Approval Yes
Yes
 		approved No   S3‑170331
    S3‑170310 Discussion on a way forward for the privacy issue Ericsson LM discussion Discussion Yes
YesEricsson: This confirms that the LI requirements need to be fulfilled as long as we have LTE-Uu. Deutsche Telekom wanted an official confirmation of this. KPN also wanted more details on the LI answers. Alex (BT): yes, you have to be able to in the design. It is possible to have a privacy solution. The concerns are about having people tracking identities of Ues and vehicles in the radio environment. If the PC5 is restricted to safety messages where you cannot stick data to them, they are out of scope. System safety messages broadcast: if extra data can be inserted as a communications path, regulatory bodies would be against it. If someone provides the operator with the identifier, and you want to intercept, this identifier is not necessary. BT: it only would work nationally. We are rolling out the core network stuff, but we can work on the privacy for the IMSI. Ericsson: no requirements for this. Nokia: we would have to go to SA1 for new requirements.
 		noted No    
    S3‑170323 Conclusion of Vehicle UE privacy LG Electronics pCR Approval Yes
YesBT: None of the solutions meet the SA1 requirements in isolation.. We can still track. KPN: why in these three solutions we cannot meet LI requirements? Let's ask to them. BT: The IMSI requirements clashes with the LI requirement. If we ignore the LI requirement the IMSI requirement is the only one we have actually met.
 		noted No    
    S3‑170423 TR 33.885 Huawei draft TR Approval Yes
Yes
 		approved No    
    S3‑170496 Exception sheet FS_V2XLTE Huawei WI exception request Agreement No
Yes
 		left for email approval No    
8.4 Study on Architecture and Security for Next Generation System (FS_NSA) (Rel-14)                      
8.4.1 Security architecture S3‑170215 TR 33.899: Questions and Interim Agreements on Key Issue 1.3: User plane integrity between UE and network BT Group Plc pCR Approval Yes
Yes
 		approved No    
    S3‑170090 TR 33.899: Discussion on KI 1.4, UP confidentiality between UE and Network KPN pCR Discussion Yes
Yes
 		noted No    
    S3‑170091 TR 33.899: Removal of EN in KI 1.4, UP confidentiality between UE and Network KPN pCR Approval Yes
Yes
 		revised No S3‑170361  
    S3‑170361 TR 33.899: Removal of EN in KI 1.4, UP confidentiality between UE and Network KPN pCR Approval Yes
Yes
 		approved No   S3‑170091
    S3‑170092 TR 33.899: Adding Questions related to KI 1.4, UP confidentiality between UE and Network KPN pCR Approval Yes
YesVodafone: these questions are negative and throw away all the work that has been done in the TR.They are leading to a WID of the normative work. BT: the idea is to understand what goes into phase 1. It is not to revoke the rest of the work. Nokia: this approach was done to speed up as a way forward. NTT-Docomo supported this. Vodafone remarked that they were not happy with the approach of the document. Telenor proposed to reword "compromise of a confidentiality protection algorithm".
 		revised No S3‑170362  
    S3‑170362 TR 33.899: Adding Questions related to KI 1.4, UP confidentiality between UE and Network KPN pCR Approval Yes
Yes
 		approved No   S3‑170092
    S3‑170093 TR 33.899: Adding Interim agreements related to KI 1.4, UP confidentiality between UE and Network KPN pCR Approval Yes
YesNokia proposed to leave the last bullet and remove the rest.
 		revised No S3‑170363  
    S3‑170363 TR 33.899: Adding Interim agreements related to KI 1.4, UP confidentiality between UE and Network KPN pCR Approval Yes
Yes
 		approved No   S3‑170093
    S3‑170339 TR 33.899: Solution for Key Issue 1.15: User plane security termination point KPN, Deutsche Telekom, Juniper Networks, BT, NTT DoCoMo pCR Approval Yes
YesTelecom Italia proposed in their contribution to terminate the UP security in the UPF. Deutsche Telekom was fine with this. Juniper didn't agree with this approach for the UP security termination.
 		approved No   S3‑170088
    S3‑170233 Comments to “Solution for User plane security termination point” TELECOM ITALIA S.p.A. discussion Decision Yes
YesEricsson: this solution is introducing a weakness. It was agreed to have this as a separate solution.
 		approved No    
    S3‑170265 Discussion on the termination point for user plane security Ericsson LM, Nokia discussion Approval Yes
Yes
 		noted No    
    S3‑170269 pCR on terminating user plane security in the AN Ericsson LM, Nokia pCR Approval Yes
YesNokia reminded that these are requirements to be revisited during normative work. Qualcomm: secure location; where is this coming from? The central unit could be installed in unsecure locations. Ericsson: regardless of where it is deployed we need to ensure that the security requirements are fulfilled.
 		approved No    
    S3‑170296 Protocol stack options for the user-plane security terminating at a user-plane function Qualcomm Incorporated pCR Approval Yes
YesQualcomm: still possible to terminate security beyond RAN from our point of view.
 		approved No    
    S3‑170337 TR 33.899: Questions and Interim Agreements on Key Issue 1.15: User plane security termination point KPN, Deutsche Telekom, Juniper Networks, BT, NTT DoCoMo pCR Approval Yes
Yes
 		revised No S3‑170428 S3‑170089
    S3‑170428 TR 33.899: Questions and Interim Agreements on Key Issue 1.15: User plane security termination point KPN, Deutsche Telekom, Juniper Networks, BT, NTT DoCoMo pCR Approval Yes
Yes
 		approved No   S3‑170337
    S3‑170240 Comments to “Questions and Interim Agreements on Key Issue #1.15: User plane security termination point, clause 5.1.3.15” TELECOM ITALIA S.p.A. pCR Approval Yes
Yes
 		noted No    
    S3‑170133 Consolidate untrusted n3gpp access solutions Nokia Germany pCR Approval Yes
YesIntel commented that the diagram needed to be updated according to Nokia and Qualcomm proposals. Nokia commented that this update is proposed in another document that was still to be discussed. NTT-Docomo proposed to clarify the use of the term AMF in SA2 and make it clear that there is no confusion witth the same term that already exists in 3GPP SA3 since long time ago. It was commented that the implications of reusing the same term should be pointed out and argued at SA/MCC level.
 		revised No S3‑170377  
    S3‑170377 Consolidate untrusted n3gpp access solutions Nokia Germany pCR Approval Yes
Yes
 		approved No   S3‑170133
    S3‑170134 Comparison of 5G untrusted n3gpp access solutions Nokia Germany pCR Approval Yes
Yes
 		revised No S3‑170378  
    S3‑170378 Comparison of 5G untrusted n3gpp access solutions Nokia Germany pCR Approval Yes
Yes
 		approved No   S3‑170134
    S3‑170137 Analysis on the use of IPSec transport for control and user plane of non 3GPP access BROADCOM CORPORATION discussion Endorsement Yes
YesIntel: the advantage of this is that the address of the UPF is not exposed. They supported this proposal. GRE header is needed. No Ipsec tunnel additional overhead header is needed. Deutsche telekom: exposing the address of UPF is not an issue. NTT-Docomo asked about the purpose of this discussion paper. Broadcom replied that this will be taken to SA2 if endorsed. Intel commented that an LS could be sent to express SA3's preference. Qualcomm needed more time to study this and come back to it in the next meeting.
 		endorsed No    
    S3‑170158 pCR to TR 33.899: Authentication and Key Agreement for untrusted non-3GPP access Intel Corporation (UK) Ltd pCR Approval Yes
YesBroadcom supported this contribution. Vodafone: access to what? Intel: to the core network. Vodafone: the way is written this doesn't seem to refer to 3GPP. I suggest some rewording to the title. The document was agreed.
 		approved No    
    S3‑170283 pCR on untrusted access to the 5G core Nokia, Qualcomm Incorporated pCR Approval Yes
YesIt was agreed an Editor's Note (EAP reauthentication impact is FFS) to adress the concerns of Broadcom.
 		revised No S3‑170379  
    S3‑170379 pCR on untrusted access to the 5G core Nokia, Qualcomm Incorporated pCR Approval Yes
Yes
 		approved No   S3‑170283
    S3‑170297 pCR to update solution #1.6 to include the untrusted non-3GPP access for the roaming scenario Qualcomm Incorporated pCR Approval Yes
YesQualcomm clarified that the NG-PDG is in the Home Network in this case. Broadcom: How is the key exchanged between the HPLMN and the VPLMN? Qualcomm: you need a security association of the UE with the HPLMN.There is no dependency with the VPLMN. It was agreed to add an editor's note to clarify this. It was also clarified that the NG-PDG is in the home only. This was adressed in an editor's note as well.
 		revised No S3‑170380  
    S3‑170380 pCR to update solution #1.6 to include the untrusted non-3GPP access for the roaming scenario Qualcomm Incorporated pCR Approval No
Yes
 		approved No   S3‑170297
    S3‑170119 Modify KI1.11 to add service based architecture related requirement Huawei, Hisilicon pCR   Yes
Yes
 		approved No    
    S3‑170126 Clarification for flexible security policies negotiation in control plane Huawei, Hisilicon pCR   Yes
YesEricsson: you say that it is out of scope but then there is a requirement addressing it. Huawei agreed to remove the requirement. Qualcomm: the requirement shouldn’t be deleted since it refers to the network, not the UE. It was agreed to reformulate the editor's note.
 		revised No S3‑170381  
    S3‑170381 Clarification for flexible security policies negotiation in control plane Huawei, Hisilicon pCR - No
Yes
 		approved No   S3‑170126
    S3‑170125 A solution for KDF negotiation Huawei, Hisilicon pCR   Yes
YesNokia: Why are there separate procedures for the KDF negotiation? They proposed several editor's notes that were added in the revision of the document.
 		revised No S3‑170382  
    S3‑170382 A solution for KDF negotiation Huawei, Hisilicon pCR - No
Yes
 		approved No   S3‑170125
    S3‑170159 pCR to TR 33.899_Registration procedure for NextGen networks NEC EUROPE LTD pCR Approval Yes
YesEricsson: Registration procedure is done in SA2. NEC: this is a proposal for the security part only. Nokia: there's an AKA based protocol in this flow. Add a note to clarify this. Identity request response may not be needed in step 5. This was added in an editor's note.
 		revised No S3‑170383  
    S3‑170383 pCR to TR 33.899_Registration procedure for NextGen networks NEC EUROPE LTD pCR Approval Yes
Yes
 		approved No   S3‑170159
    S3‑170160 pCR to TR 33.899_Security procedure for NextGen networks NEC EUROPE LTD pCR Approval Yes
YesNEC clarified that this doesn’t have any impact on the architecture. SPCF is part of the SA2 architecture. Nokia: this procedure depends on the key hierarchy and will have to be updated if this changes.An editor's note was added to address this issue.
 		revised No S3‑170384  
    S3‑170384 pCR to TR 33.899_Security procedure for NextGen networks NEC EUROPE LTD pCR Approval Yes
Yes
 		approved No   S3‑170160
    S3‑170161 pCR to TR 33.899_Security procedure for NextGen networks (with NAS_SM security procedure) NEC EUROPE LTD pCR Approval Yes
YesNokia: this also depends on the key hierarchy.The UP termination is also another issue that may modify this. Two editor's notes were added to address this.
 		revised No S3‑170385  
    S3‑170385 pCR to TR 33.899_Security procedure for NextGen networks (with NAS_SM security procedure) NEC EUROPE LTD pCR Approval Yes
Yes
 		approved No   S3‑170161
    S3‑170163 pCR to TR 33.899_Consolidated Key Hierarchy for NextGen Network NEC EUROPE LTD pCR Approval Yes
YesNEC clarified that this hierarchy addresses all the proposed solutions in SA3. Nokia proposed to add an editor's note to point out that this depends on future agreements on key hierarchy.
 		revised No S3‑170386  
    S3‑170386 pCR to TR 33.899_Consolidated Key Hierarchy for NextGen Network NEC EUROPE LTD pCR Approval Yes
Yes
 		approved No   S3‑170163
    S3‑170186 pCR to 33.899 - addition of solution detailing enhanced USIM features for 5G VODAFONE Group Plc pCR Approval Yes
YesBT: EAP protocols clash with protocols that already exist in the UICC. Vodafone: this is adressed already. Nokia: why running all EAP in the USIM and if not in which part? This needs a justification paper. Vodafone: this is not mandating EAP in the USIM. It's about how the USIM could be used to be an endpoint for that. Nokia: Why is this extension needed and what is the advantage? Gemalto: the feasibility is described already in the WLAN specification. Nokia: Not sure that there are more security advantages of deriving more keys from the USIM. Vodafone preferred to remove clause m.2.5 and come back in the next meeting with a better formulation instead of adding a new editor's note.
 		revised No S3‑170387  
    S3‑170387 pCR to 33.899 - addition of solution detailing enhanced USIM features for 5G VODAFONE Group Plc pCR Approval Yes
Yes
 		approved No   S3‑170186
    S3‑170245 pCR on solution for key issue 1.9 (AN-CN Control Plane) Nokia, Ericsson pCR Approval Yes
YesKPN didn’t find clear the solution 1.2.2.2 for the generic protection of the virtualized infrastructure. Qualcomm, NTT Docomo and Juniper didn’t agree with this formulation either. An Editor's note was added here. Deutsche Telekom: remove the last note given the discussions on the termination of the UP security.
 		revised No S3‑170388  
    S3‑170388 pCR on solution for key issue 1.9 (AN-CN Control Plane) Nokia, Ericsson pCR Approval Yes
Yes
 		approved No   S3‑170245
    S3‑170246 pCR on solution for key issue 1.10 (AN-CN User Plane) Nokia, Ericsson pCR Approval Yes
YesComments from the previous document also apply here. BT: there are no generic security mechanisms for NFV Security.We need to mention some application layer requirements so these mechanisms can be developed for the underlying infrastructure. An editor's note was added to address this issue.
 		revised No S3‑170389  
    S3‑170389 pCR on solution for key issue 1.10 (AN-CN User Plane) Nokia, Ericsson pCR Approval Yes
Yes
 		approved No   S3‑170246
    S3‑170273 Discussion on the security anchor function Ericsson LM discussion Discussion Yes
YesEricsson: No good reason to separate AMF and SEAF. Qualcomm: SEAF is colocated with AMF in phase one. It doesn’t mean they cannot separate in the future. Morpho: don't limit ourselves because of this phase one agreements. Ericsson: there is no interface standardised between the two entities. If we separate, this will have a propietary solution. We would like to have them colocated in phase one. Deutsche Telekom: from the security point of view we can suggest to keep them separated if this is seen as necessary in the future. Nokia: include key derivation don't standardize the interface now. NTT Docomo supported this. Qualcomm: we don’t have enough information to make a decision about this.
 		noted No    
    S3‑170274 Security context management during AMF change Ericsson LM pCR Approval Yes
Yes
 		approved No    
    S3‑170277 Solution for the security anchor function based on a primary AMF Ericsson LM pCR Approval Yes
YesNokia: what assumptions in trust of the location of the new AMF are being done here? Ericsson: they are described in the key issue.There are different levels of trust. The operator knows where the AMF are and will apply the adequate policy depending on that. Nokia: trust model on AMF location needs FFS. Telenor supported this. KPN didn’t see the purpose of this solution. Ericsson: this is based on the SA2 assumption so we need to address it.
 		revised No S3‑170391  
    S3‑170391 Solution for the security anchor function based on a primary AMF Ericsson LM pCR Approval Yes
Yes
 		approved No   S3‑170277
    S3‑170290 A solution for securing the initial NAS messages Qualcomm Incorporated pCR Approval Yes
YesVodafone: we support this but what happens when there is no security context is not clear.
 		revised No S3‑170393  
    S3‑170393 A solution for securing the initial NAS messages Qualcomm Incorporated pCR Approval No
Yes
 		approved No   S3‑170290
    S3‑170124 Protection of downlink NAS signallings before security activation Huawei, Hisilicon pCR   Yes
YesORANGE: the roaming scenario needs to be studied as well.
 		revised No S3‑170394  
    S3‑170394 Protection of downlink NAS signallings before security activation Huawei, Hisilicon pCR - No
Yes
 		approved No   S3‑170124
    S3‑170157 pCR to TR 33.899_Update solution #1.8 key hierarchy NEC EUROPE LTD pCR Approval Yes
YesEricsson: parameters like time limit or data volume; how do you know them in advance? We need more clarification on these. China Mobile: SM doesn’t change between slices. NEC: this is aligned with SA2 agreements. Several other editor notes were added to address comments from Nokia.
 		revised No S3‑170395  
    S3‑170395 pCR to TR 33.899_Update solution #1.8 key hierarchy NEC EUROPE LTD pCR Approval Yes
YesAdding editor's notes as proposed by Ericsson.
 		approved No   S3‑170157
    S3‑170292 Adding a questions relating to a security anchor and key issue #1.2 to the TR Qualcomm Incorporated pCR Approval Yes
Yes
 		approved No    
    S3‑170289 Proposals for supported features in Phase 1 of 5G security Qualcomm Incorporated discussion Discussion Yes
Yes
 		noted No    
    S3‑170051 Open Questions Related to Key Issues 1.6 and 1.7 Huawei & Hisilicon pCR   Yes
YesORANGE: what do we do with this section? Huawei: to know which questions are answered in phase one.
 		revised No S3‑170396  
    S3‑170396 Open Questions Related to Key Issues 1.6 and 1.7 Huawei & Hisilicon pCR - No
Yes
 		approved No   S3‑170051
    S3‑170165 pCR to TR 33.899_Questionnaire on Key Issue # 1.7 to Annex NEC EUROPE LTD pCR Approval Yes
YesNokia and Vodafone didn’t agree with this document. Ericsson: too many assumptions in this document to be agreable.
 		noted No    
    S3‑170248 pCR on question for key issue 1.9 ‘Security features for AN-CN Control Plane’ Nokia pCR Decision Yes
Yes
 		revised No S3‑170397  
    S3‑170397 pCR on question for key issue 1.9 ‘Security features for AN-CN Control Plane’ Nokia pCR Decision Yes
Yes
 		approved No   S3‑170248
    S3‑170252 pCR on question for key issue 1.10 ‘Security features for AN-CN User Plane’ Nokia pCR   Yes
Yes
 		revised No S3‑170398  
    S3‑170398 pCR on question for key issue 1.10 ‘Security features for AN-CN User Plane’ Nokia pCR - Yes
Yes
 		approved No   S3‑170252
    S3‑170340 Questions on Key Issue #1.8: UEs with asymmetric keys NTT DOCOMO INC. pCR   Yes
YesNokia didn’t agree with the first three bullet points of the interim agreement. They were removed. There was quite a good split on the last bullet point and the use of private keys.Some companies thought that this should go into phase one.
 		revised No S3‑170399 S3‑170338
    S3‑170399 Questions on Key Issue #1.8: UEs with asymmetric keys NTT DOCOMO INC. pCR - Yes
Yes
 		approved No   S3‑170340
    S3‑170088 TR 33.899: Solution for Key Issue 1.15: User plane security termination point KPN, Deutsche Telekom, Juniper Networks, BT pCR Approval Yes
Yes
 		revised No S3‑170339  
    S3‑170089 TR 33.899: Questions and Interim Agreements on Key Issue 1.15: User plane security termination point KPN, Deutsche Telekom, Juniper Networks, BT pCR Approval Yes
Yes
 		revised No S3‑170337  
    S3‑170338 Questions on Key Issue #1.8: UEs with asymmetric keys NTT DOCOMO INC. pCR   Yes
Yes
 		revised No S3‑170340  
    S3‑170364 Positions on UP security termination and slicing concepts Nokia, Ericsson, Samsung, Intel,Broadcom discussion discussion Yes
Yes
 		noted No    
    S3‑170465 Ls on Ipsec use for non 3GPP access Broadcom LS out Approval Yes
Yes
 		approved No    
8.4.2 Authentication S3‑170056 Proposal to prioritize key issue#2.9 in phase 1 Huawei, Hisilicon discussion Discussion Yes
YesNokia: what's the connection to the service provider? BT: the purpose of network slices is to provide connectivity to different service providers.
 		noted No    
    S3‑170055 Adding more details for SPCF Huawei, Hisilicon pCR Approval Yes
YesNokia: As for"An AUSF or a UE may support one or more authentication protocols for different network slices", this is still under discussion. I suggest to delete the whole paragraph. This was agreed.
 		revised No S3‑170400  
    S3‑170400 Adding more details for SPCF Huawei, Hisilicon pCR Approval Yes
Yes
 		approved No   S3‑170055
    S3‑170272 pCR on need for standardized interface AUSF - ARPF Nokia pCR Approval Yes
YesBT supported this simplification. Huawei asked to remove "no split for authentication functionality will be standardized. ". Also remove the "only" for EAP-AKA. Broadcom supported this. Nokia: the idea is that anybody can use their auth methods without having to adapt them, changing the standards for every one of them. Huawei: we need an interface for certaing authentication methods, it is too early to consider future possibilities. We haven't decided what authentication methods will enter into phase one. NTT-Docomo: not realistic to standardise many interfaces in phase one due to lack of time. The Chair proposed to add a sentence mentioning that this is only for phase one, so more possibilities can be added later. Huawei wasn't convinced with this.
 		revised No S3‑170401  
    S3‑170401 pCR on need for standardized interface AUSF - ARPF Nokia pCR Approval Yes
Yes
 		approved No   S3‑170272
    S3‑170069 Remove EN for Interface of AUSF and ARPF in Clause 5.2.1.2 Huawei, Hisilicon pCR Approval Yes
Yes
 		merged No S3‑170401  
    S3‑170128 Declaring the public/private key pairs (e.g in EAP-TLS) should be stored in AUSF instead of ARPF Huawei, Hisilicon pCR Approval Yes
Yes
 		approved No    
    S3‑170063 Update of 5.2.3.1.3: Resolving the Editor’s Note for Alternative Authentication Huawei, Hisilicon pCR Approval Yes
YesVodafone didn't agree with this change. Morpho: this is a very narrowed down use case. You cannot use a completely new mechanism. Vodafone: the current requirements allow already EAP to be considered. This text is irrelevant.Morpho cards agreed.
 		noted No    
    S3‑170253 pCR to key issue 2.1 Authentication Framework - key issue details Nokia, Ericsson pCR Approval Yes
YesOberthur and Huawei had concerns about the secondary authentication between the UE and DN.
 		revised No S3‑170403  
    S3‑170403 pCR to key issue 2.1 Authentication Framework - key issue details Nokia, Ericsson pCR Approval Yes
Yes
 		approved No   S3‑170253
    S3‑170255 pCR to key issue 2.1 Authentication Framework - requirements Nokia, Ericsson pCR   Yes
YesMorpho: the third requirement is not clear. We are not defining mechanisms for fixed networks here. MCC argued that "shall support mandatory-to-use" would be the same as "shall use", and "shall support optional-to-use" is actually the same as "shall support". Nokia commented that this is present in already existing text and it should be fixed in the original spec. Huawei: what does it mean "it doesn’t affect the security of the 3GPP network"? It’s gone through the mandatory authentication already. It was agreed to replace it with "weaken" instead of "affect" in the second requirement.
 		revised No S3‑170404  
    S3‑170404 pCR to key issue 2.1 Authentication Framework - requirements Nokia, Ericsson pCR - Yes
Yes
 		approved No   S3‑170255
    S3‑170268 pCR on question 5 for key issue 2.1 Authentication Framework Nokia, Ericsson pCR Decision Yes
Yes
 		approved No    
    S3‑170114 Security Procedure for Network Slicing CATT pCR   Yes
Yes
 		revised No S3‑170426  
    S3‑170426 Security Procedure for Network Slicing CATT pCR - Yes
Yes
 		approved No   S3‑170114
    S3‑170177 EAP based secondary authentication by an external data network Nokia pCR Approval Yes
Yes
 		merged No S3‑170405  
    S3‑170405 EAP based secondary authentication by an external data network Nokia pCR Approval Yes
Yes
 		approved No   S3‑170177
    S3‑170279 EAP based secondary authentication for PDU session establishment authorization Ericsson LM pCR Approval Yes
YesHuawei: the secondary authentication was claimed to be independt of the 3GPP network in tdoc 255. But this is not what happens here. Nokia: it refers to the choice being transparent. Deutsche Telekom: there could be weak keys. Ericsson: this is for an additional protection layer. It was proposed to merge the three proposals since they were similar.
 		merged No S3‑170405  
    S3‑170298 Secondary authentication and authorization using SM NAS signalling Qualcomm Incorporated pCR Approval Yes
YesHuawei: tdoc 056 should be considered. It discusses whether the given ley issue should or should not in phase one.The solutions should go for phase one in this case. This was agreed. Qualcomm: secondary authentication after primary authentication is agreed. ORANGE: make it clear that the credentials for the primary and secondary authentication are independent.
 		merged No S3‑170405  
    S3‑170280 Update to key issue #2.1: Adding architectural considerations related to 3GPP and untrusted non-3GPP accesses Ericsson pCR Approval Yes
YesNokia and Huawei wanted the paragraph under the figure to be removed. Ericsson suggested to move it to an annex, but this wasn't agreed. ORANGE: it shall support EAP-AKA, instead of just EAP; for the last sentence. BT had an issue with having EAP-AKA prime in the requirement. "Variant of EAP-AKA" would be better. The phrase was reformulated.
 		revised No S3‑170406  
    S3‑170406 Update to key issue #2.1: Adding architectural considerations related to 3GPP and untrusted non-3GPP accesses Ericsson pCR Approval Yes
Yes
 		approved No   S3‑170280
    S3‑170078 pCR to TR 33.899 - updating key issue 2.2 VODAFONE Group Plc pCR Approval Yes
Yes
 		approved No    
    S3‑170164 TR 33.899 v0.6.0 clause 5.2.3.3 Editors note -Word "non-3GPP" should be replaced by another word BT Group Plc pCR Approval Yes
YesTelenor warned about the third party concept being very foggy. This may clash with GSMA. ORANGE: third party and subscription should not go together. Ericsson:we are not comfortable with making these changes. In SA1 they talk about alternative authentication methods. It’s also about primary authentication methods only.Tdoc 285 proposes something different.
 		noted No    
    S3‑170285 Update to key issue #2.3, and a new solution on identifiers demonstrating the proposed terms Ericsson pCR Approval Yes
YesORANGE: we don’t need the alternative subscription identifier in the table. Are these identifiers aligned with SA2? Ericsson confirmed that it was aligned.
 		noted No    
    S3‑170257 Resolving second EN in clause 5.2.3.3.1 Nokia, Vodafone pCR Decision Yes
Yes
 		approved No    
    S3‑170123 A solution for equipment identifier authentication using EAP Huawei, HiSilicon pCR   Yes
Yes
 		approved No    
    S3‑170276 pCR on evaluation of solution 2.6 ‘Binding a serving network public key into the derivation of the radio interface session keys’ Nokia pCR Approval Yes
YesDiscussed together with Vodafone's comments in 347.
 		revised No S3‑170407  
    S3‑170407 pCR on evaluation of solution 2.6 ‘Binding a serving network public key into the derivation of the radio interface session keys’ Vodafone,Nokia pCR Approval Yes
Yes
 		approved No   S3‑170276
    S3‑170347 revised pCR on evaluation of solution 2.6 ‘Binding a serving network public key into the derivation of the radio interface session keys’ VODAFONE Group Plc pCR Approval Yes
YesAgreed changes will be incorporated in 407.
 		noted No    
    S3‑170303 Update to solution #2.9: New variant solution EAP-AKA* Ericsson pCR Approval Yes
Yes
 		approved No    
    S3‑170284 Update to solution #2.9: adding evaluation, and resolving ENs Ericsson pCR Approval Yes
YesNokia commented that the first editor's note still sounded like an editor's note when stating "if EAP is chosen it should be studied". MCC agreed with this. The note was reworded to say that it is out of scope of the current document. Nokia: Keep the ERP editor's note. Qualcomm and Huawei agreed with this. Broadcom: you are proposing a new method on an already existing one that may not be sufficient. Nokia had other comments that had to be taken offline.
 		revised No S3‑170410  
    S3‑170410 Update to solution #2.9: adding evaluation, and resolving ENs Ericsson pCR Approval Yes
Yes
 		approved No   S3‑170284
    S3‑170041 A clarification for 4G USIM term Huawei & Hisilicon pCR   Yes
YesAlf (Docomo): Rel-99 or Rel-8? It should be Rel-8. This was agreed. MCC queried whether the term "Rel-8 USIM" or "LTE USIM" was defined anywhere. This needed to be checked. Nokia, BT commented that the public key delivery would be in this case in the ME, which is less advantageous. Huawei: the operator would have to use a delivery mechanism in the ME for the public key. ORANGE: how would this be done? Huawei: OTA mechanisms are available to the operator. Vodafone: functionalirty that wasn't pre-programmed in the USIM would have to be done through a JAVA app, probably less secure.Most of the cards would struggle to generate the keys and cannot be updated anyway. This had to be taken offline.
 		revised No S3‑170429  
    S3‑170429 A clarification for 4G USIM term Huawei & Hisilicon pCR - Yes
Yes
 		noted No   S3‑170041
    S3‑170042 Network lying about its public key; Is it a security issue? Huawei & Hisilicon pCR   Yes
YesORANGE: How is the UE validating that the public key belongs to a specific network? This was taken offline and finally approved.
 		approved No    
    S3‑170043 Removing EN on Sending UE SEC Capabilities to Home Network Huawei & Hisilicon pCR   Yes
Yes
 		approved No    
    S3‑170044 Removing EN on Allowing SEAF to negotiate AS Security Capabilities with NG-UE Huawei & Hisilicon pCR   Yes
YesNokia: Isn’t it odd when one operator tells another operator what algorithms to use? The case of shared RAN is for further study. It was agreed to add a note on this.
 		revised No S3‑170430  
    S3‑170430 Removing EN on Allowing SEAF to negotiate AS Security Capabilities with NG-UE Huawei & Hisilicon pCR - Yes
Yes
 		approved No   S3‑170044
    S3‑170046 Removing EN on More sophisticated replay protection Huawei & Hisilicon pCR   Yes
YesNokia: out of sequence mechanisms between UE and network need to be considered. It was agreed to add an editor's note.
 		revised No S3‑170431  
    S3‑170431 Removing EN on More sophisticated replay protection Huawei & Hisilicon pCR - Yes
Yes
 		approved No   S3‑170046
    S3‑170047 Cross Referencing MASA solution to Privacy Security Area Huawei & Hisilicon pCR   Yes
Yes
 		approved No    
    S3‑170048 MASA Solution Addresses LI Requirements Huawei & Hisilicon pCR   Yes
YesQualcomm and Orange commented that privacy needs to be considered. Option 1 needs to comply with privacy requirements: what happens with Ue privacy when sending the IMSI. BT: If you turn encryption off, why do you care about privacy? It was agreed that the NAS is not mandated to provide with confidentiality in this case.
 		revised No S3‑170432  
    S3‑170432 MASA Solution Addresses LI Requirements Huawei & Hisilicon pCR - Yes
Yes
 		approved No   S3‑170048
    S3‑170049 Removing EN on HS deployment supporting solution 2.12 functionality Huawei & Hisilicon pCR   Yes
Yes
 		approved No    
    S3‑170050 Update MASA Solution Terminology inline with SA3 agreed ones Huawei & Hisilicon pCR   Yes
Yes
 		approved No    
    S3‑170040 MASA solution Goals and Evaluation Huawei & Hisilicon pCR Approval Yes
Yes
 		revised No S3‑170435  
    S3‑170435 MASA solution Goals and Evaluation Huawei & Hisilicon pCR Approval Yes
Yes
 		approved No   S3‑170040
    S3‑170278 pCR on evaluation of solution 2.12 (MASA) Nokia pCR Approval Yes
YesNokia and Docomo found problems with the random numbers RAND1,RAND2,etc.. An editor's note was added in order to progress work and have further discussions. For the top of evaluation two it was decided to have it as a working agreement with the sustained objection of Huawei and other companies. This was added in an editor's note.
 		revised No S3‑170433  
    S3‑170433 pCR on evaluation of solution 2.12 (MASA) Nokia pCR Approval Yes
Yes
 		approved No   S3‑170278
    S3‑170064 Update of Solution #2.14: Resolving the Editor’s Note Huawei, Hisilicon pCR Approval Yes
Yes
 		revised No S3‑170412  
    S3‑170412 Update of Solution #2.14: Resolving the Editor’s Note Huawei, Hisilicon pCR Approval Yes
Yes
 		approved No   S3‑170064
    S3‑170065 Update of Solution #2.14 with EAP-PSK Authentication Method Huawei, Hisilicon pCR Approval Yes
YesNokia: what is the G parameter? Huawei agreed to add some explanation for G.
 		revised No S3‑170436  
    S3‑170436 Update of Solution #2.14 with EAP-PSK Authentication Method Huawei, Hisilicon pCR Approval Yes
Yes
 		approved No   S3‑170065
    S3‑170243 Clarifying the solutions in the section 5.2.4.17 China Mobile Com. Corporation pCR Approval Yes
Yes
 		revised No S3‑170438  
    S3‑170438 Clarifying the solutions in the section 5.2.4.17 China Mobile Com. Corporation pCR Approval Yes
Yes
 		approved No   S3‑170243
    S3‑170244 Clarifying the solutions in the section 5.2.4.18 China Mobile Com. Corporation pCR Approval Yes
Yes
 		revised No S3‑170439  
    S3‑170439 Clarifying the solutions in the section 5.2.4.18 China Mobile Com. Corporation pCR Approval Yes
Yes
 		approved No   S3‑170244
    S3‑170270 pCR on evaluation of EPS AKA* Nokia pCR Approval Yes
Yes
 		revised No S3‑170440  
    S3‑170440 pCR on evaluation of EPS AKA* Nokia pCR Approval Yes
YesHuawei: the HSS being stateful introduces complexity.
 		approved No   S3‑170270
    S3‑170258 pCR on question 1 for key issue 2.1 Authentication Framework Nokia pCR Approval Yes
Yes
 		revised No S3‑170441  
    S3‑170441 pCR on question 1 for key issue 2.1 Authentication Framework Nokia pCR Approval Yes
Yes
 		approved No   S3‑170258
    S3‑170259 pCR on question 2 for key issue 2.1 Authentication Framework Nokia, Ericsson pCR   Yes
Yes
 		revised No S3‑170442  
    S3‑170442 pCR on question 2 for key issue 2.1 Authentication Framework Nokia, Ericsson pCR - Yes
Yes- Only EAP related, also mentions non 3GPP. - Exact EAP methods supported in a separate question as suggested bu ORANGE.
 		approved No   S3‑170259
    S3‑170094 TR 33.899: Adding question and removing Editor's Note from 5.2.3.1.3, KI 2.1 Authentication framework KPN pCR Approval Yes
Yes
 		noted No    
    S3‑170261 pCR on question 3 for key issue 2.1 Authentication Framework Nokia, Ericsson pCR Decision Yes
YesKPN: why not the network, instead of the UE? We cannot mandate it to the UE. Vodafone: this implies that there must be a security anchor in the USIM. The answer to the question would be no, the question needs to be reworded. Huawei: EAP-PSK should be a candidate. ORANGE: this is for the primary or the secondary authentication? Ericsson: this is for the primary authentication. We should say something about alternative authentication methods to avoid fragmentation. Alf (Docomo): the question needs rewording. BT: this would apply to V2V/non-human communication as well and it is a matter of concern.
 		noted No    
    S3‑170095 TR 33.899: Proposal for interim agreement for KI 2.1 Authentication framework KPN pCR Approval Yes
Yes
 		noted No    
    S3‑170266 pCR on question 4 for key issue 2.1 Authentication Framework Nokia, Ericsson pCR Approval Yes
Yes
 		revised No S3‑170466  
    S3‑170466 pCR on question 4 for key issue 2.1 Authentication Framework Nokia, Ericsson pCR Approval Yes
Yes
 		approved No   S3‑170266
    S3‑170291 Adding a question to authentication conclusions clause related to the editor’s note about SEAF in home network Qualcomm Incorporated pCR Approval Yes
Yes
 		revised No S3‑170443  
    S3‑170443 Adding a question to authentication conclusions clause related to the editor’s note about SEAF in home network Qualcomm Incorporated pCR Approval Yes
Yes
 		approved No   S3‑170291
    S3‑170299 Support of Equipment Identifier Authentication in Phase 1 Qualcomm Incorporated discussion Endorsement Yes
YesBT: this shouldn’t be optional to support since stolen devices should be identified. Tim (Vodafone), Orange and Alf (Docomo): no urgency for having this in pahse one. Samsung, BT, Huawei and Interdigital supported proposal one to be in the first phase. Alf: failed authentication is no different from non authentication. If we let this in, the solutions are going to be pretty heavy. Alf: If there is no bidding down attack we can discuss this in phase two.This was agreed as a way forward.
 		noted No    
    S3‑170027 pCR to TR33.899 - removal of editors notes in the Authentication Security area following conf call#11 VODAFONE Group Plc pCR Approval No
No
 		withdrawn Yes    
    S3‑170028 pCR to TR 33.899 - resolution to some of the editors notes in the Authentication Security area that were postponed in conf call11 VODAFONE Group Plc pCR Approval No
No
 		withdrawn Yes    
    S3‑170045 Removing EN on Allowing SEAF to negotiate AS Security Capabilities with NG-UE Huawei & Hisilicon pCR   No
No
 		withdrawn Yes    
    S3‑170070 Update to 5.2.3.1.3 to remove EN for Alternative Authentication Huawei, Hisilicon pCR Approval No
No
 		withdrawn Yes    
8.4.3 Security context and key management S3‑170122 Security threats of key issue #3.3 “Principles of security negotiation” Huawei, Hisilicon pCR   Yes
Yes
 		not treated No    
    S3‑170120 Update Solution 3.8 and resolve ENs Huawei, Hisilicon pCR   Yes
Yes
 		not treated No    
    S3‑170074 Hiding keys of 5G-CN with UE assistance ZTE Corporation pCR Approval Yes
Yes
 		not treated No    
8.4.4 RAN security S3‑170167 pCR to TR 33.899_Merger of Key Issues #4.3 and #4.8 NEC EUROPE LTD, Ericsson pCR Approval Yes
Yes
 		revised No S3‑170445  
    S3‑170445 pCR to TR 33.899_Merger of Key Issues #4.3 and #4.8 NEC EUROPE LTD, Ericsson pCR Approval Yes
Yes
 		approved No   S3‑170167
    S3‑170229 Updating KI - #4.4 Security aspects of intra-NR mobility Ericsson pCR Approval Yes
Yes
 		approved No    
    S3‑170234 Resolving Editor’s Notes in Key issue #4.2: Security requirements on gNB Ericsson pCR Approval Yes
Yes
 		approved No    
    S3‑170308 RAN security area introduction Ericsson pCR   Yes
Yes
 		revised No S3‑170446  
    S3‑170446 RAN security area introduction Ericsson pCR - Yes
Yes
 		approved No   S3‑170308
    S3‑170104 Handling of SI requests from unauthenticated UEs in NR BlackBerry UK Limited discussion Decision Yes
YesNokia commented that there is a key issue referring to this. Samsung: the key issue is different from what appears here. This solution will increase the load in gNodeB. Alf (Docomo): we can look at this in phase one, specifying it in phase one is unclear. Samsung, Ericsson didn’t endorse proposal one. There was no general support for this, so the document was noted.
 		noted No    
    S3‑170221 New KI - Security aspects of N2 handover Ericsson pCR Approval Yes
Yes
 		approved No    
    S3‑170222 New KI - Security aspects of sidehaul interfaces Ericsson pCR Approval Yes
Yes
 		approved No    
    S3‑170223 New KI - Flexibility to retain or to change AS security keys Ericsson pCR Approval Yes
Yes
 		revised No S3‑170447  
    S3‑170447 New KI - Flexibility to retain or to change AS security keys Ericsson pCR Approval Yes
Yes
 		approved No   S3‑170223
    S3‑170224 New KI - Changing AS security keys on-the-fly Ericsson pCR Approval Yes
Yes
 		revised No S3‑170448  
    S3‑170448 New KI - Changing AS security keys on-the-fly Ericsson pCR Approval Yes
Yes
 		approved No   S3‑170224
    S3‑170225 New KI - Dealing with radio jamming Ericsson pCR Approval Yes
YesBT,Docomo: remove the low power jamming. Deutsche Telekom: this may be in the scope of the radio design, not a security concept. BT agreed with this. An LS could be sent to RAN. It was agreed to limite the scope to detection.
 		revised No S3‑170449  
    S3‑170449 New KI - Dealing with radio jamming Ericsson pCR Approval Yes
Yes
 		approved No   S3‑170225
    S3‑170226 New KI - Privacy aspects of RAN level subscription identifiers Ericsson pCR Approval Yes
YesInterdigital pointed out an issue with the C-RNTI. This was added in an editor's note.
 		revised No S3‑170450  
    S3‑170450 New KI - Privacy aspects of RAN level subscription identifiers Ericsson pCR Approval No
Yes
 		approved No   S3‑170226
    S3‑170227 New KI - Security aspects of Xn handover Ericsson pCR Approval Yes
Yes
 		revised No S3‑170451  
    S3‑170451 New KI - Security aspects of Xn handover Ericsson pCR Approval Yes
Yes
 		approved No   S3‑170227
    S3‑170228 New KI - Security algorithm negotiation between UE and RAN Ericsson pCR Approval Yes
Yes
 		approved No    
    S3‑170231 New KI – Supporting integrity protection of UP in/between gNB and UE Ericsson pCR Approval Yes
Yes
 		approved No    
    S3‑170135 RAN Security: comparison of SIB protection solutions Nokia Germany pCR Approval Yes
Yes
 		noted No    
    S3‑170305 Clarification on the UTC-Based Time Counter Samsung pCR Approval Yes
Yes
 		approved No    
    S3‑170306 Overhead Reduction using the other SI Samsung pCR Approval Yes
Yes
 		revised No S3‑170461  
    S3‑170461 Overhead Reduction using the other SI Samsung pCR Approval Yes
Yes
 		approved No   S3‑170306
    S3‑170156 pCR to TR 33.899: Fake gNB Detection using Identity Based Signature Intel Corporation (UK) Ltd pCR Approval Yes
Yes
 		revised No S3‑170462  
    S3‑170462 pCR to TR 33.899: Fake gNB Detection using Identity Based Signature Intel Corporation (UK) Ltd pCR Approval Yes
Yes
 		approved No   S3‑170156
    S3‑170219 New solution - Security of Access Stratum (AS) keys on Xn handover Ericsson pCR Approval Yes
Yes
 		approved No    
    S3‑170220 New solution- UE-assisted false base station detection Ericsson pCR Approval Yes
YesNokia: we need to address how to address the problem of fake base stations. An editor's note was added in order to keep the solution. BT: what’s the privacy implication here? An editor's note was added here to address this issue.
 		revised No S3‑170463  
    S3‑170463 New solution- UE-assisted false base station detection Ericsson pCR Approval Yes
Yes
 		approved No   S3‑170220
    S3‑170230 New solution - Security of sidehaul interface Ericsson pCR Approval Yes
Yes
 		approved No    
    S3‑170247 Key Derivation Mechanism in RRC inactive connected state to RRC connected state transition China Mobile Com. Corporation pCR Approval Yes
YesNokia: RAN is still discussing RRC inactive state.This is premature. China Mobile: the mobility is not being discussed here.
 		noted No    
    S3‑170464 Key Derivation Mechanism in RRC inactive connected state to RRC connected state transition China Mobile Com. Corporation pCR Approval No
No
 		withdrawn Yes    
    S3‑170300 Option 3/3a/3x security aspects and conclusions Qualcomm Incorporated pCR Approval Yes
Yes
 		approved No    
    S3‑170075 Discussion on security method of UE transmit data in RRC_INACTIVE state ZTE Corporation discussion Discussion Yes
Yes
 		noted No    
    S3‑170106 Handling token and key derivation for data transmitting in RRC_INACTIVE ZTE Corporation pCR Approval Yes
YesNokia: this is a late submission. The Chair decided to note it and treat it in the next meeting.
 		noted No    
    S3‑170113 Discussion LS R2-1700656 Nokia Germany discussion Discussion Yes
Yes
 		noted No    
8.4.5 Security within NG-UE S3‑170032 Credentials storage requirements ORANGE, Deutsche Telekom AG, KPN, Vodafone, Telecom Italia, TeliaSonera, BT pCR Approval Yes
Yes
 		revised No S3‑170366  
    S3‑170366 Credentials storage requirements ORANGE, Deutsche Telekom AG, KPN, Vodafone, Telecom Italia, TeliaSonera, BT, China Mobile, AT&T, Telenor pCR Approval Yes
Yes
 		merged No S3‑170444 S3‑170032
    S3‑170235 Update of Key issue #5.1: Requirements on credentials storage Ericsson pCR Approval Yes
YesThe editor's note will be incorporated into 444.
 		merged No S3‑170444  
    S3‑170301 Security requirements for Key Issue # 5.1 Qualcomm Incorporated pCR Approval Yes
YesVodafone didn’t agree with the last bullet point. It is too restrictive, only the authentication algorithms. The secure file, other keys calculation, etc..are not included here. Qualcomm agreed with this argument. Oberthur: secure platform is not enough here as discussed in SA1. It is defined for SA3 to to define more detailed security requirements. Oberthur,Gemalto and Intel supported this document.
 		revised No S3‑170444 S3‑161737
    S3‑170444 Security requirements for Key Issue # 5.1 Qualcomm Incorporated, ORANGE, Deutsche Telekom AG, KPN, Vodafone, Telecom Italia, TeliaSonera, BT, China Mobile, AT&T, Telenor, Ericsson, Intel, Gemalto, Oberthur Technologies, G&D,Morpho pCR Approval Yes
Yes
 		approved No   S3‑170301
    S3‑170071 Solution for Key Issue 5.1 ORANGE, Deutsche Telekom AG, KPN, Vodafone, Telecom Italia, TeliaSonera, BT pCR Approval Yes
Yes
 		revised No S3‑170367  
    S3‑170367 Solution for Key Issue 5.1 ORANGE, Deutsche Telekom AG, KPN, Vodafone, Telecom Italia, TeliaSonera, BT, China Mobile, AT&T, Telenor pCR Approval No
YesEricsson and MCC argued that in both solution and evaluation details the SDO ETSI SCP is named without referencing a specific document. It is not possible to mention the SCP working group like this. Blackberry supported not mentioning ETSI SCP. Ericsson wanted to remove the conclusion and evaluation part for this reason. Morpho Cards: there is a study item in CT6 for such secure hardware platform that will feed the SCP work.
 		approved No   S3‑170071
    S3‑170072 Interim agreement on key issue 5.1 ORANGE, Deutsche Telekom AG, KPN, Vodafone, Telecom Italia, TeliaSonera, BT pCR Approval Yes
Yes
 		revised No S3‑170368  
    S3‑170368 Interim agreement on key issue 5.1 ORANGE, Deutsche Telekom AG, KPN, Vodafone, Telecom Italia, TeliaSonera, BT, China Mobile, AT&T, Telenor pCR Approval Yes
Yes
 		noted No   S3‑170072
    S3‑170236 Agreement on credentials storage: decide in normative phase Ericsson pCR Approval Yes
Yes
 		noted No    
8.4.6 Authorization S3‑170039 Section 5.6.3.3.1 - Key Issue Details INTERDIGITAL COMMUNICATIONS pCR Approval Yes
Yes
 		not treated No    
    S3‑170030 Section 5.6.4.2.2 - Resolution of Editor’s Notes. INTERDIGITAL COMMUNICATIONS pCR Decision Yes
Yes
 		not treated No    
    S3‑170031 Section 5.6.4.3.2 - Resolution of Editor’s Notes INTERDIGITAL COMMUNICATIONS pCR Approval Yes
Yes
 		not treated No    
    S3‑170281 Resolution of the editor’s notes in solution #6.4 Ericsson LM pCR Approval Yes
Yes
 		not treated No    
8.4.7 Subscription privacy S3‑170206 Update on key issues permanent vs temp id Nokia pCR Approval Yes
Yes
 		revised No S3‑170457  
    S3‑170207 Editorial corrections Nokia pCR Approval Yes
Yes
 		not treated No    
    S3‑170457 Update on key issues permanent vs temp id Nokia pCR Approval Yes
Yes
 		not treated No   S3‑170206
    S3‑170333 Update on key issues including attack details on identity probing Nokia pCR   Yes
Yes
 		revised No S3‑170458  
    S3‑170458 Update on key issues including attack details on identity probing Nokia pCR - Yes
Yes
 		not treated No   S3‑170333
    S3‑170249 Avoiding the linkability attack on the AKA protocol China Mobile Com. Corporation pCR Approval Yes
YesNTT-Docomo: IMSI privacy would avoid that. Make the case more generic.
 		revised No S3‑170427  
    S3‑170427 Avoiding the linkability attack on the AKA protocol China Mobile Com. Corporation pCR Approval Yes
Yes
 		not treated No   S3‑170249
    S3‑170062 Use of legacy USIM and NextGen ME in solution #7.12 Huawei, Hisilicon pCR Approval Yes
Yes
 		not treated No    
    S3‑170067 pCR to TR 33.899: Resolving editor’s notes on solution 7.8 THALES pCR Approval Yes
Yes
 		not treated No    
    S3‑170068 Removal of ENs for Solution #7.11 Huawei, Hisilicon pCR Approval Yes
Yes
 		revised No S3‑170351  
    S3‑170351 Removal of ENs for Solution #7.11 Huawei, Hisilicon pCR Approval Yes
Yes
 		not treated No   S3‑170068
    S3‑170076 pCR to TR 33.899 – evaluations and conclusions in subscription Privacy Key Area VODAFONE Group Plc pCR Agreement Yes
Yes
 		revised No S3‑170437  
    S3‑170437 pCR to TR 33.899 – evaluations and conclusions in subscription Privacy Key Area VODAFONE Group Plc pCR Agreement Yes
Yes
 		not treated No   S3‑170076
    S3‑170080 Updating solution #7.3 Vodafone, Telecom Italia, Ericsson pCR Agreement Yes
Yes
 		not treated No    
    S3‑170187 Updating solution #7.14 “Privacy protection of permanent or long-term subscription identifier using ABE” TELECOM ITALIA S.p.A. pCR Approval Yes
Yes
 		revised No S3‑170343  
    S3‑170196 Recovery - update of solution Nokia pCR Approval Yes
No
 		withdrawn Yes    
    S3‑170250 Remove the editor’s note in solution #7.10 China Mobile Com. Corporation pCR Approval Yes
Yes
 		not treated No    
    S3‑170251 Update the solution #7.10 China Mobile Com. Corporation pCR Approval Yes
Yes
 		not treated No    
    S3‑170293 pCR to update solution #7.4: Privacy enhanced Mobile Subscriber Identifier (PMSI) Qualcomm Incorporated pCR Approval Yes
Yes
 		not treated No    
    S3‑170294 PMSI usage in EAP-AKA’ Qualcomm Incorporated pCR Approval Yes
Yes
 		not treated No    
    S3‑170295 pCR to provide an evaluation on the solutions for identity privacy Qualcomm Incorporated pCR Approval Yes
Yes
 		not treated No    
    S3‑170194 Solution - using pools of IMSIs Nokia pCR Approval Yes
Yes
 		revised No S3‑170452  
    S3‑170452 Solution - using pools of IMSIs Nokia pCR Approval Yes
Yes
 		not treated No   S3‑170194
    S3‑170195 Solution - Encrypted pseudonym in RAND Nokia pCR Approval Yes
Yes
 		revised No S3‑170453  
    S3‑170453 Solution - Encrypted pseudonym in RAND Nokia pCR Approval Yes
Yes
 		not treated No   S3‑170195
    S3‑170197 Questions related to PKI Nokia pCR Approval Yes
Yes
 		revised No S3‑170454  
    S3‑170454 Questions related to PKI Nokia pCR Approval Yes
Yes
 		not treated No   S3‑170197
    S3‑170198 Questions related to public vs symm. crypto Nokia pCR Approval Yes
Yes
 		revised No S3‑170497  
    S3‑170497 Questions related to public vs symm. crypto Nokia pCR Approval Yes
Yes
 		not treated No   S3‑170198
    S3‑170199 Question to concealment of identifiers Nokia pCR Approval Yes
Yes
 		revised No S3‑170455  
    S3‑170455 Question to concealment of identifiers Nokia pCR Approval Yes
Yes
 		not treated No   S3‑170199
    S3‑170200 QuestionNAS msg length and migration aspects Nokia pCR Approval Yes
No
 		withdrawn Yes    
    S3‑170201 Question on synchronization Nokia pCR Approval Yes
Yes
 		revised No S3‑170498  
    S3‑170498 Question on synchronization Nokia pCR Approval Yes
Yes
 		not treated No   S3‑170201
    S3‑170202 Question to concealment of temporary identifiers Nokia pCR Approval Yes
Yes
 		revised No S3‑170456  
    S3‑170456 Question to concealment of temporary identifiers Nokia pCR Approval Yes
Yes
 		not treated No   S3‑170202
    S3‑170203 Question to full protection of permanent identifier Nokia pCR Approval Yes
Yes
 		not treated No    
    S3‑170204 Question to slice identifier protection Nokia pCR Approval Yes
Yes
 		not treated No    
    S3‑170205 Update on key issues including attack details on identity probing Nokia pCR Approval Yes
No
 		withdrawn Yes    
    S3‑170343 Updating solution #7.14 “Privacy protection of permanent or long-term subscription identifier using ABE” TELECOM ITALIA S.p.A., Ericsson pCR Approval Yes
Yes
 		not treated No   S3‑170187
8.4.8 Network slicing security S3‑170130 Definition of network slice isolation Nokia Germany pCR Approval Yes
YesHuawei didn’t agree with this definition. Morpho: this is not a requirement, it needs rewording. Qualcomm didn’t agree with this definition either: "of course cannot be achieved". Why?In the RAN, when there is encryption between UE and UPF, the isolation can be achieved. ORANGE: the concept of security isolation is too large to have it in a definition. KPN didn’t agree with the document either.
 		noted No    
    S3‑170060 Removal of ENs in Security Area #8 (subclause 5.8.2) Huawei, Hisilicon pCR Approval Yes
YesEricsson commented that the editor's note can be removed, but no need to add the text. There was no agreement.
 		noted No    
    S3‑170059 Removal of ENs for KI 8 2 Huawei, Hisilicon pCR Approval Yes
Yes
 		approved No    
    S3‑170326 Clarification of key issue #8.1 Network slice isolation LG Electronics pCR Approval Yes
Yes
 		merged No S3‑170500  
    S3‑170131 Modification of key issue network slice isolation Nokia Germany pCR Approval Yes
YesHuawei didn’t agree with the last editor's note. Nokia: this is meant for the single NG-UE. Qualcomm: security within the UE is not covered here. Deutsche Telekom: we haven’t made any assumptions whether the network is in danger because of the UE. The editor's note is right and we can answer already. The whole bullet before can be removed. Qualcomm: the attack that can happen to the UE can happen to the network. Interdigital: it’s a requirement coming from NGMN. The requirement seemed to be pretty unclear since the companies disagreed with its meaning. Another editor's note addressed this. Some comments on the deleted requirements from Qualcomm and BT: It was agreed to remove the fifth requirement.
 		revised No S3‑170500  
    S3‑170500 Modification of key issue network slice isolation Nokia Germany pCR Approval No
Yes
 		left for email approval No   S3‑170131
    S3‑170267 FS_NSA: slice isolation Gemalto N.V. pCR Approval Yes
YesORANGE: second requirement is not agreed. Interdigital found the contribution useful but had comments on all requirements. Huawei thought that the requirements were relevant. Nokia also found them relevant. SA5 is looking into the management aspects, though. Interdigital commented that SA5 does not acknowledge security issues in the virtualization field. LG commented that security work should base on SA5's work. Gemalto commented that a WID on the overall security addressing SA5 aspects could be brought into the next meeting.
 		noted No    
    S3‑170282 New Potential Security Requirements for Key Issue #8.6 Deutsche Telekom AG pCR Approval Yes
No
 		withdrawn Yes    
    S3‑170321 FS_NSA: virtualization security requirements Gemalto N.V. pCR Approval Yes
YesInterdigital commented that there were not common points with the work done in ETSI NFV Sec. Alex (BT) commented that the hypervisor is not the primary threat, it’s a subset of a bigger problem. Some references point to the wrong documents as well.Alex commented that ETSI NFV needs to support SA3 depending on the requirements that SA3 is bringing. Some coordination with NFV is required.
 		noted No    
    S3‑170058 Call flow for slice-specific NAS key derivation and distribution Huawei, Hisilicon pCR Approval Yes
YesNokia suggested an editor's note taking into account discussions from SA3#85.
 		revised No S3‑170501  
    S3‑170501 Call flow for slice-specific NAS key derivation and distribution Huawei, Hisilicon pCR Approval No
Yes
 		approved No   S3‑170058
    S3‑170057 Updates to Solution #8.9 Security mechanism differentiation for network slices Huawei, Hisilicon pCR Approval Yes
Yes
 		revised No S3‑170502  
    S3‑170502 Updates to Solution #8.9 Security mechanism differentiation for network slices Huawei, Hisilicon pCR Approval No
Yes
 		approved No   S3‑170057
    S3‑170115 Evaluation for Network Slicing Security Solution CATT pCR   Yes
YesQualcomm commented why we are writing requirements again in the evaluation clause. Vodafone: if the requirements change, nobody will change them here. Btter reference.
 		noted No    
    S3‑170132 Addressing ENs in Slicing solution 8.6 Nokia Germany pCR Approval Yes
Yes
 		not treated No    
    S3‑170168 pCR toTR 33.899_Removal of Editor’s Notes of Solution 8.1 NEC EUROPE LTD pCR Approval Yes
Yes
 		not treated No    
    S3‑170061 Slice-specific NAS keys Huawei, Hisilicon pCR Approval Yes
Yes
 		not treated No    
    S3‑170073 Modification of solution 8.5 ZTE Corporation pCR Approval Yes
Yes
 		not treated No    
8.4.9 Relay security                      
8.4.10 Network domain security                      
8.4.11 Security visibility and configurability S3‑170327 Update of key issues of security area #11 Security visibility and configurability LG Electronics pCR Approval Yes
Yes
 		not treated No    
    S3‑170328 Update of solution #11.2 Security visibility solution LG Electronics pCR Approval Yes
Yes
 		not treated No    
    S3‑170329 Update of solution #11.3 Security configurability solution LG Electronics pCR Approval Yes
Yes
 		not treated No    
8.4.12 Credential provisioning S3‑170264 Remote credential provisioning Gemalto N.V. pCR Approval Yes
Yes
 		revised No S3‑170390  
    S3‑170390 Remote credential provisioning Gemalto N.V. pCR Approval Yes
Yes
 		not treated No   S3‑170264
    S3‑170237 Authorisation of network access for credentials provisioning Ericsson pCR Approval Yes
Yes
 		not treated No    
    S3‑170309 Updates to Solution#12.4 Samsung pCR Approval Yes
Yes
 		not treated No    
    S3‑170311 Updates to Solution#12.4 to support eUICC-ID privacy Samsung pCR Approval Yes
Yes
 		not treated No    
    S3‑170312 Support for Provisioning Profile for credential provisioning Samsung pCR Approval Yes
Yes
 		not treated No    
8.4.13 Interworking and migration                      
8.4.14 Small data                      
8.4.15 Broadcast/Multicast security                      
8.4.16 Management Security S3‑170127 Network slice life-cycle Huawei, Hisilicon pCR   Yes
Yes
 		not treated No    
    S3‑170121 Automatic certificate enrolment for the gNB Huawei, Hisilicon pCR   Yes
Yes
 		not treated No    
8.4.17 Cryptographic algorithms                      
8.4.18 Other S3‑170263 FS_NSA Relation to other WGs NEC EUROPE LTD discussion   No
Yes
 		left for email approval No    
    S3‑170241 Overview of Key Issues and Solutions KPN discussion Information Yes
Yes
 		noted No    
    S3‑170286 Editorial updates of TR 33.899 Ericsson pCR   Yes
Yes
 		revised No S3‑170488  
    S3‑170488 Editorial updates of TR 33.899 Ericsson pCR - Yes
Yes
 		approved No   S3‑170286
    S3‑170275 WID for 5G System Security Architecture – Phase 1 Ericsson, Nokia WID new Agreement Yes
YesVodafone: be more specific with the objectives, concentrate on refininf the TR. AT&T: normative work needs to start now and take priority over the study work. Approve the WID, the objectives can be refined later. Qualcomm agreed with this. You can reword with "including but not limited to..". Gemalto: slicing is in phase one of SA2. Why isn’t slicing here? AT&T: any misalignment and coordination would be handled at plenary level, we shouldn’t worry about this. TIM: let's align with SA2 if we are piggibacking in their WID. Vodafone: there are items driven by SA3 and not driven by SA2. The Chair commented that SA3 not only covers the architecture but also the radio aspects, so SA3 will solve their security issues. A sentence was added to clarify this. ORANGE: this is an open list. How do we define what's in phase one? We will spend quite a long time if we don’t make this decision. The Chair commented that discussions what;'s on phase one should not affect the agreement of this WID. It's still unclear what will go into phase one. Vodafone: conclusions of 33.899 should not be put in here, since at the moment there are none. ORANGE: we can use the interim agreements to shape what will be in phase one. Vodafone argued that interim agreements and conclusions are not present in the SA3 TR and that arguments should not be repeated in the TS. Nokia: we need to agree on high level principles. We decide a solution X and later on we go into detail. You can't go straight from this TR to the TS. Vodafone: where do we capture the high level principles? My preference would be the TS. ORANGE disagreed with this, since the discussions would be too long. TIM: there should be a conclusion in the TR before going to the TS. Gemalto: for new topics, the work should be put first in the TR, get to a conclusion, then go to the TS. ORANGE: at some point of time we should stop the TR and work in the TS directly. BT: my preference is to start moving stuff into the TS instead of growing the TR.
 		revised No S3‑170477  
    S3‑170477 WID for 5G System Security Architecture – Phase 1 Ericsson, Nokia,NTT-Docomo WID new Agreement Yes
Yes
 		agreed No   S3‑170275
    S3‑170017 LS on 5G work alignment S1-163453 LS in   Yes
Yes
 		noted No    
    S3‑170006 LS OUT on NFV-based solutions for next generation mobile networks ETSI ISG NFV LS in   Yes
Yes
 		noted No    
    S3‑170271 Draft reply LS on the termination point for user plane security Ericsson LM, Nokia LS out Approval Yes
Yes
 		noted No    
    S3‑170019 LS reply on NFV-based solutions for next generation mobile networks from ETSI NFV S2-167249 LS in   Yes
Yes
 		noted No    
    S3‑170022 Reply LS to ETSI ISG NFV on NFV-based solutions for next generation mobile networks S5-166464 LS in   Yes
Yes
 		noted No    
    S3‑170020 Reply LS to LS on state of SA3 discussions on NG security architecture S2-167250 LS in   Yes
Yes
 		noted No    
    S3‑170052 Reply to LS on State of SA3 discussions on NG security architecture R2-1700652 LS in   Yes
Yes
 		replied to No    
    S3‑170408 Reply to: Reply to LS on State of SA3 discussions on NG security architecture Nokia LS out approval Yes
YesTIM argued that if all possible proposals are put in there it means that SA3 still needs to discuss them, so it doesn’t make sense to list them all. Mauro (TIM) also commented that it seems that there are two completely different topics covered in there. There was also some disagreement between Nokia and Qualcomm. Qualcomm argued that their proposals in 286 were not reflected in this LS. The Qualcomm proposal was added and removed the reference to the "SA3 Chair compromise".
 		approved No    
    S3‑170018 Reply LS on Cooperation on NGS FMC S2-167247 LS in   Yes
Yes
 		noted No    
    S3‑170037 LS to SA WG3 on privacy of registration and slice selection information S2 170687 LS in   Yes
Yes
 		postponed No    
    S3‑170053 LS on Security considerations for NR R2-1700655 LS in   Yes
Yes
 		replied to No    
    S3‑170459 Reply to: LS on Security considerations for NR NTT-Docomo LS out approval Yes
Yes
 		approved No    
    S3‑170054 LS to SA3 on Small Data Transmission R2-1700656 LS in   Yes
YesHuawei argued that the title refers to small data and it should be postponed for phase 2. Ericsson commented that the title is misleading and the content is related to phase one work: it's about active state. Small data is a RAN concept, not a SA2 concept. Oberthur commented that this was related to small data in NB-IOT. This had to be checked offline: - If it's active state, SA3 needs to do this task.Active state is part of the RAN and we will need a security solution for this. - If it's related to small data, IoT, this will be postponed.
 		replied to No    
    S3‑170460 Reply to: LS to SA3 on Small Data Transmission Nokia LS out approval Yes
Yes
 		approved No    
    S3‑170184 LS on Use of the long-term identities for Charging in the VPLMN for 5G S3i170043 LS in   Yes
Yes
 		noted No    
    S3‑170181 LS on LI requirements reconfirmed, including 5G and CIoT S3i170054 LS in   Yes
YesCSP: communication service provide. BT: this is to be taken into account for the northbound interface LS.
 		noted No    
    S3‑170359 5G Security – Package 3:Mobile Edge Computing / Low Latency / Consistent User Experience NGMN LS in discussion Yes
Yes
 		noted No    
    S3‑170503 Draft TR 33.899 Ericsson draft TR Approval No
Yes
 		left for email approval No    
    S3‑170504 Cover sheet TR 33.899 Ericsson TS or TR cover Approval No
Yes
 		left for email approval No    
8.5 Study on Mission Critical Security Enhancements (FS_MC_Sec) S3‑170208 Key issue on MBMS subchannel control message protection Ericsson LM pCR Approval Yes
Yes
 		approved No    
    S3‑170209 Solution for MBMS control subchannel protection based on a new bearer specific key Ericsson LM pCR Approval Yes
Yes
 		approved No    
    S3‑170210 Solution for MBMS control subchannel protection based on MKFC Ericsson LM pCR Approval Yes
Yes
 		approved No    
    S3‑170211 Solution for MBMS subchannel control message protection using a new server specific key Ericsson LM pCR Approval Yes
Yes
 		approved No    
    S3‑170314 [MCSEC] Key Issue on use of MBMS within the MC Domain NCSC (CESG) pCR Approval Yes
Yes
 		approved No    
    S3‑170103 R-14 eMCPTT security presentation Motorola Solutions Danmark A/S discussion Information Yes
Yes
 		noted No    
    S3‑170102 MCData SDS security presentation Motorola Solutions Danmark A/S discussion Information Yes
Yes
 		noted No    
    S3‑170313 [MCSEC] Simplifying signalling and floor control in Rel-14 NCSC (CESG) other Information Yes
Yes
 		noted No    
    S3‑170212 Key issue on exposure of group identifiers Ericsson LM pCR Approval Yes
YesAirbus: the requirement is not correct. We want to protect the identity cryptographically.
 		revised No S3‑170415  
    S3‑170415 Key issue on exposure of group identifiers Ericsson LM pCR Approval Yes
Yes
 		approved No   S3‑170212
    S3‑170213 Solution for the concealment of group identifiers using group specific pseudonyms Ericsson LM pCR Approval Yes
Yes
 		approved No    
    S3‑170214 Solution for the concealment of group identifiers using session specific pseudonyms Ericsson LM pCR Approval Yes
Yes
 		approved No    
    S3‑170315 [MCSEC] Solution for simplifying signalling key distribution NCSC (CESG) pCR Approval Yes
Yes
 		revised No S3‑170471  
    S3‑170471 [MCSEC] Solution for simplifying signalling key distribution NCSC (CESG) pCR Approval No
Yes
 		approved No   S3‑170315
    S3‑170105 pCR 33.880 First to Answer Key Mgmt Motorola Solutions Danmark A/S pCR Approval Yes
Yes
 		revised No S3‑170349  
    S3‑170318 [MCSEC] First-to-answer security solution NCSC (CESG) pCR Approval Yes
Yes
 		noted No    
    S3‑170349 pCR 33.880 First to Answer Key Mgmt Motorola Solutions, Airwave pCR Approval Yes
Yes
 		approved No   S3‑170105
    S3‑170316 [MCSEC] Temporary group call security solution – add group call user NCSC (CESG) pCR Approval Yes
Yes
 		revised No S3‑170392  
    S3‑170392 [MCSEC] Temporary group call security solution – add group call user NCSC (CESG) pCR Approval Yes
Yes
 		approved No   S3‑170316
    S3‑170317 [MCSEC] Temporary group call security solution – limited users NCSC (CESG) pCR Approval Yes
Yes
 		noted No    
    S3‑170101 pCR 33.880 MCData SDS XMPP security solution Motorola Solutions Danmark A/S pCR Approval Yes
Yes
 		revised No S3‑170402  
    S3‑170402 pCR 33.880 MCData SDS XMPP security solution Samsung, Motorola Solutions, Airwave, Airbus DS SLC pCR Approval Yes
Yes
 		approved No   S3‑170101
    S3‑170304 E2E protection of SDS over signalling plane Samsung pCR Approval Yes
Yes
 		merged No S3‑170402  
    S3‑170416 LS to SA6 on "temporary group call-user regroup" security CESG LS out Approval No
Yes
 		approved No    
    S3‑170417 TR 33.880 CESG draft TR Approval No
Yes
 		approved No    
    S3‑170489 Work Item exception FS_Mc_Sec CESG WI exception request Agreement No
Yes
 		left for email approval No    
    S3‑170490 Work Item exception Mc_Sec CESG WI exception request Agreement No
Yes
 		left for email approval No    
    S3‑170491 Cover sheet TR 33.880 CESG draft TR Approval No
Yes
 		approved No    
    S3‑170492 Cover sheet TS 33.180 CESG TS or TR cover Approval No
Yes
 		approved No    
8.6 Other study areas                      
8.6.1 Security Assurance Specification for 3GPP network product classes (33.926) (SCAS) S3‑170136 Update the threat description of Key issue 5.3.5.1 China Mobile Com. Corporation pCR Approval Yes
No
 		withdrawn Yes    
8.6.2 Study on Battery Efficient Security for very low Throughput Machine Type Communication Devices (FS_BEST_MTC_Sec) S3‑170026 CR to TS 33.863 to correct the contents table VODAFONE Group Plc CR Agreement No
No
 		withdrawn Yes    
8.6.3 Study on Security for Proximity-based Services (FS_ProSe_Sec)                      
8.6.4 Other study items                      
9 Review and Update of Work Plan S3‑170002 SA3 Work Plan MCC Work Plan   Yes
Yes
 		noted No    
    S3‑170005 Work Plan input from Rapporteurs MCC other   Yes
Yes
 		revised No S3‑170033  
    S3‑170033 Work Plan input from Rapporteurs MCC other   Yes
Yes
 		revised No S3‑170354 S3‑170005
    S3‑170354 Work Plan input from Rapporteurs MCC other - No
Yes
 		noted No   S3‑170033
10 Future Meeting Dates and Venues S3‑170004 SA3 meeting calendar MCC other   Yes
YesThe Chair commented that the adhoc meetings will have decision power.
 		revised No S3‑170478  
    S3‑170478 SA3 meeting calendar MCC other - Yes
Yes
 		noted No   S3‑170004
11 Any Other Business S3‑170138 On the use of IPSec with LWIP BROADCOM CORPORATION discussion Decision Yes
YesThere was no opposition for this so a CR will be brought into the next meeting.
 		noted No