Tdoc List

2016-07-29 16:20

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‑160900 Agenda WG Chairman agenda   Yes
Yes
 		approved No    
3 IPR Reminder                      
4 Meeting Reports                      
4.1 Approval of the Report from SA3 #82 S3‑160901 Report from SA3#83 MCC report   Yes
Yes
 		approved No    
4.2 Report from SA #71 S3‑160903 Report from last SA meeting WG Chairman report   Yes
Yes
 		noted No    
4.3 Report from SA3-LI                      
5 Items for early consideration S3‑161118 proposed/draft reply LS on eDRX security NTT DOCOMO LS out Approval Yes
Yes
 		revised No S3‑161153  
    S3‑161153 Reply LS on eDRX security NTT DOCOMO LS out Approval Yes
Yes
 		approved No   S3‑161118
    S3‑161146 New WID on Support of EAP Re-Authentication Protocol for WLAN Interworking ORANGE WID new Agreement Yes
YesOrange noted that CT4 is discussing this week a related WID. A stage 2 feature WID in SA3 would allow them to track the changes and open a Building Block work item. Gemalto: Put Don't Know on the UICC Apps table. Nokia: Not good to have the habit of having to agree on late docs that are WIDs. This shouldn't be taken as a precedent. Nokia didn’t agree with the Objective. We shouldn’t make a work item on the SWA interface. BT clarified that 23.402 is on non-3GPP access.
 		revised No S3‑161152  
    S3‑161152 New WID on Support of EAP Re-Authentication Protocol for WLAN Interworking ORANGE WID new Agreement Yes
Yes
 		agreed No   S3‑161146
    S3‑161147 Nokia comments on S3-161118 Reply on eDRX security Nokia discussion   Yes
YesNTT-Docomo: sync between MME and eNodeB when there is a reset. Even with IMSI paging I don’t see how it is recovered. IMSI itself shouldn’t be the base for this. We shouldn’t have another round with RAN2, better to reply now. This was discussed offline.
 		noted No    
6.1 3GPP Working Groups S3‑160914 LS on eDRX paging timing calculation and security concern R2-164582 LS in   Yes
YesDocomo: clashing on paging needs to be resolved.
 		replied to No    
    S3‑160916 LS on Support of EAP Re-authentication for WLAN Interworking S2-162796 LS in   Yes
YesDiscussed together with 1146 (WID).
 		noted No    
    S3‑160917 LS on progress of FS_xMBMS study item S4-160837 LS in   Yes
YesNagendra (Nokia) commented that Diameter based MB2 interface should be reused. This would force SA3 to look at the security aspects. Vodafone: there is an editor's note in the TR that refers to security aspects to be dealt with SA3. It was decided to note it.
 		noted No    
    S3‑160919 LS on I-WLAN handling and specification withdrawal SP-160508 LS in   Yes
YesDiscussed with 1045. Ericsson will take action on this as stated in 1045.
 		noted No    
    S3‑161038 LS on Improvement to authentication procedure for supporting Emergency Service on WLAN S2-164273 LS in   Yes
YesNokia: 33.402 may be impacted.
 		noted No    
6.2 IETF                      
6.3 ETSI SAGE                      
6.4 GSMA S3‑160910 Liaison Statement on 5G Capabilities and Requirements GSMA LS in   Yes
YesPresented by David Hutton (GSMA). Vodafone: a guide to obsolete features and suplementary services? David (GSMA): this is directed to other players, not 3GPP SA3. Nokia: Interconnection network is not secure is weak. Using the Internet backbone is multiplying the security issues too. David: A secure model for IPX is the way forward. Nokia: it doesn’t help for misbehaving end points. David: We are working towards that point, e.g.more firewall mechanisms for SS7. The Chairman commented that this LS will help SA3 in the NSA work item. Interdigital: Slicing in serving network for home environment. A slice can be created on demand? David: it can be done that way or operators know who their roaming partners are and build it statically.
 		replied to No    
    S3‑161154 Reply to: Liaison Statement on 5G Capabilities and Requirements Ericsson LS out approval Yes
Yes
 		approved No    
    S3‑160937 NESAS Pilot Release Documents GSMA SECAG LS in   Yes
Yes
 		postponed No    
6.5 3GPP2                      
6.6 OMA                      
6.7 TCG S3‑160929 TCG progress report INTERDIGITAL COMMUNICATIONS report Information Yes
YesNokia: Network equipment subgroup? Interidigital: It's fdor routers, servers, endpoints in the network. The difference would lie in virtualization. Interdigital agreed to contribute with more info on this group.
 		noted No    
6.8 oneM2M                      
6.9 TC-CYBER                      
6.10 ETSI NFV security                      
6.11 Other Groups                      
7.1 SAE/LTE Security S3‑160908 LS on Protecting UE network capabilities from ‘bidding down attack GSMA FSAG LS in   Yes
Yes
 		replied to No    
    S3‑161216 Reply to: LS on Protecting UE network capabilities from ‘bidding down attack Qualcomm LS out approval No
Yes
 		approved No    
    S3‑161112 Protecting against the modification of Attach/TAU Request attacks Qualcomm Incorporated CR Approval Yes
Yes
 		revised No S3‑161217 S3‑160562
    S3‑161217 Protecting against the modification of Attach/TAU Request attacks Qualcomm Incorporated,Huawei CR Approval Yes
YesDiscussed together with 1133. Ericsson and Nokia supported this option.
 		agreed No   S3‑161112
    S3‑161133 Protecting against the modification of Attach/TAU Request attacks TELECOM ITALIA S.p.A., ORANGE CR Agreement Yes
Yes
 		not pursued No    
    S3‑161037 LWA editorial corrections Huawei, HiSilicon CR Agreement Yes
YesNokia and Qualcomm commented that the first change was out of scope.
 		revised No S3‑161220  
    S3‑161220 LWA editorial corrections Huawei, HiSilicon CR Agreement Yes
Yes
 		agreed No   S3‑161037
    S3‑161110 Installing PMK at the WLAN AP using EAP Blackberry, Qualcomm Incorporated CR Approval Yes
YesMCC commented that the NOTE contained the words "is required", which is incorrect since notes should not contain requirements. This was reworded.
 		revised No S3‑161222  
    S3‑161222 Installing PMK at the WLAN AP using EAP Blackberry, Qualcomm Incorporated CR Approval Yes
Yes
 		agreed No   S3‑161110
    S3‑160913 LS on PDCP ciphering for high data rates in eLWA R2-164557 LS in   Yes
Yes
 		replied to No    
    S3‑161223 Reply to: LS on PDCP ciphering for high data rates in eLWA Qualcomm LS out approval Yes
Yes
 		approved No    
    S3‑160985 Discussion paper on disabling PDCP ciphering Nokia, Intel discussion Discussion Yes
YesQualcomm: If we disable PDCP cyphering the solutions described here will not work. The concept of trusted/untrusted is not available in the serving network. We don’t agree with disabling PDCP cyphering. Nokia: RAN should work to get that information in the eNodeB (trusted/untrusted concept). Docomo: we had this discussion before, we should have PDCP active. BT: performance issue with double encryption. The UE is getting more complex. Qualcomm: the performance will not be affected. Turning on and off would be more effective.
 		noted No    
    S3‑160986 draft_LS response on disabling PDCP ciphering Nokia, Intel LS out Approval Yes
Yes
 		noted No    
    S3‑160912 LS to SA3 on LWIP counter R2-164551 LS in   Yes
Yes
 		noted No    
    S3‑160918 Response LS on Progress on Security for LWIP SP-160457 LS in   Yes
Yes
 		noted No    
    S3‑161064 LWIP - Correction of the UEs IP address Ericsson CR Agreement Yes
Yes
 		agreed No    
7.2.1 TS 33.116 (SCAS-SA3) S3‑161120 handling editor's notes in 33.116 NTT DOCOMO pCR Approval Yes
YesMCC commented that there cannot be VOIDs in clauses since this is a draft. Renumbering of clauses would be required.Docomo commented that they would find a way to avoid this to keep the numerous references between clauses.
 		revised No S3‑161231  
    S3‑161231 handling editor's notes in 33.116 NTT DOCOMO pCR Approval Yes
Yes
 		approved No   S3‑161120
    S3‑161134 pCR adding the test case of protecting data and information in transfer into the section 5.2.3.2.4 of TS 33.116 China Mobile Com. Corporation, ZTE, Telecom Italia pCR Approval Yes
YesDocomo: there is something similar in 942 for 33.117. Remove requirement description. This was agreed. Also adding a reference to the same text in 33.117. Nokia commented that 5.2.3.2.4 seemed quite strange to be in 33.116. This had to be checked. It was agreed to send TR 33.116 for approval.
 		revised No S3‑161233  
    S3‑161233 pCR adding the test case of protecting data and information in transfer into the section 5.2.3.2.4 of TS 33.116 China Mobile Com. Corporation, ZTE, Telecom Italia pCR Approval Yes
Yes
 		approved No   S3‑161134
    S3‑161232 New draft TS 33.116 NTT-Docomo draft TS Approval No
Yes
 		left for email approval No    
    S3‑161234 Cover sheet TS 33.116 NTT-Docomo TS or TR cover discussion No
Yes
 		left for email approval No    
7.2.2 TS 33.117 (SCAS-SA3) S3‑160935 pCR to TS 33.117 on TC_CONFIDENTIAL_SYSTEM_INTERNAL_DATA Deutsche Telekom AG pCR Approval Yes
Yes
 		revised No S3‑160943  
    S3‑160936 pCR to TS 33.117 adding test case for "Protecting data and information in transfer" Deutsche Telekom AG pCR Approval Yes
Yes
 		revised No S3‑160942  
    S3‑160942 pCR to TS 33.117 adding test case for "Protecting data and information in transfer" Deutsche Telekom AG pCR Approval Yes
YesEricsson didn’t support the test case addition. Huawei and Nokia supported Ericsson.
 		revised No S3‑161237 S3‑160936
    S3‑161237 pCR to TS 33.117 adding test case for "Protecting data and information in transfer" Deutsche Telekom AG pCR Approval Yes
Yes
 		approved No   S3‑160942
    S3‑160943 pCR to TS 33.117 on TC_CONFIDENTIAL_SYSTEM_INTERNAL_DATA Deutsche Telekom AG pCR Approval Yes
Yes
 		revised No S3‑161236 S3‑160935
    S3‑161236 pCR to TS 33.117 on TC_CONFIDENTIAL_SYSTEM_INTERNAL_DATA Deutsche Telekom AG,NTT-Docomo pCR Approval Yes
Yes
 		approved No   S3‑160943
    S3‑161039 Clarification in logging access to personal data Huawei; HiSilicon pCR   Yes
Yes
 		revised No S3‑161221  
    S3‑161221 Clarification in logging access to personal data Huawei; HiSilicon pCR - Yes
Yes
 		approved No   S3‑161039
    S3‑161040 Clarification in Authentication policy Huawei; HiSilicon pCR Approval Yes
Yes
 		revised No S3‑161239  
    S3‑161239 Clarification in Authentication policy Huawei; HiSilicon pCR Approval Yes
Yes
 		approved No   S3‑161040
    S3‑161041 Clarification in Authentication policy Huawei; HiSilicon pCR Approval Yes
Yes
 		approved No    
    S3‑161050 pCR to TS 33.117 Editorial correction to testcase "TC_ IP_MULTICAST_HANDLING" Nokia Networks pCR   Yes
Yes
 		approved No    
    S3‑161052 pCR to TS 33.117 - Revision of the testcase "TC_GRATUITOUS_ARP_DISABLING Nokia Networks pCR   Yes
Yes
 		approved No    
    S3‑161053 pCR to TS 33.117 - Enhancing the testcase "TC_BVT_ROBUSTNESS AND FUZZ TESTING" Nokia Networks pCR   Yes
Yes
 		approved No    
    S3‑161116 Removing Editor’s Note in 5.2.6.2.3 TNO pCR Approval Yes
YesNokia: 33.116 has a requirement on GTP-C, and here we generalize to GTP both user and control plane. Changes in 33.117 should be compatible with what we intended with the MME in 33.116. Do we have to go through every specific entity TS every time we make a change in the general catalog? Docomo: would apply this to eNOdeB which is the other end of GTP-U? The answer was yes. Every time we make a change in the generic requirement we have to see what happens in every enitity. Nokia: we can’t have a new requirement every time we make a change. It was decided to include new requirements in the entities when a change was made in the general catalog. The document was revised for this objective.
 		revised No S3‑161240  
    S3‑161240 Removing Editor’s Note in 5.2.6.2.3 TNO pCR Approval Yes
Yes
 		approved No   S3‑161116
    S3‑161121 handling editor's notes in 33.117 NTT DOCOMO pCR Approval Yes
Yes
 		approved No    
    S3‑161122 pCR to 33.117 to 5.2.3.4.3.3 introducing password blacklists NTT DOCOMO INC. pCR   Yes
YesNokia commented that this was hard for the manufacturers to comply with.
 		revised No S3‑161238  
    S3‑161238 pCR to 33.117 to 5.2.3.4.3.3 introducing password blacklists NTT DOCOMO INC. pCR - Yes
Yes
 		approved No   S3‑161122
    S3‑161235 new draft TS 33.117 NTT-Docomo draft TS Approval No
Yes
 		left for email approval No    
    S3‑161241 Cover sheet TS 33.117 NTT-Docomo TS or TR cover Approval No
Yes
 		left for email approval No    
7.2.3 TS 33.zzz (SCAS_PGW) S3‑160954 pCR adding the skeleton of TS 33.250 China Mobile Com. Corporation, ZTE, Telecom Italia draft TS Approval Yes
Yes
 		revised No S3‑161242  
    S3‑161242 pCR adding the skeleton of TS 33.250 China Mobile Com. Corporation, ZTE, Telecom Italia draft TS Approval Yes
Yes
 		approved No   S3‑160954
    S3‑161012 Discussion paper for SCAS-PGW TNO discussion Discussion Yes
No
 		withdrawn Yes    
    S3‑161016 pCR to TS 33.250 - Adding an EN in section 5.3.3.1.2 on P-GW and traffic forwarding TNO pCR Approval Yes
YesIt was agreed to remove security objectives in 1121 and 1120. All references will be checked when renumbering the clauses, in both 33.117 and 33.926. 5.2.3 was proposed to keep it as an empty clasuse.
 		merged No S3‑161242  
    S3‑161124 PDN GW Security Issues TNO discussion Discussion Yes
Yes
 		noted No    
    S3‑161130 pCR scope of TS 33.250 China Mobile Com. Corporation, ZTE, Telecom Italia, Huawei, Hisilicon pCR Approval Yes
Yes
 		approved No    
    S3‑161243 TS 33.250 China Mobile draft TS Approval Yes
Yes
 		approved No    
7.2.4 Other S3‑161042 Remove “shall” from the TR Huawei, HiSilicon CR Approval Yes
Yes
 		revised No S3‑161244  
    S3‑161244 Remove “shall” from the TR Huawei, HiSilicon CR Approval Yes
Yes
 		agreed No   S3‑161042
    S3‑161111 WID on Security Assurance Specification for eNB Huawei, HiSilicon WID new Agreement Yes
YesBT noted that it was agreed not to do this process with several entities in parallel. Do we want to change our minds? NTT-Docomo was fine with this as long as the eNodeB was removed from the scope. Nokia agreed to cut out eNodeB. This will be a bigger step than the core network nodes, a quite different job. We should finish with the core network nodes first. Huawei: this will take a longer time so better to start soon. China Mobile agreed with having the eNodeB before the rest of core network nodes. It was agreed to go straight to the TS for the eNodeB instead of using a TR.
 		revised No S3‑161245  
    S3‑161245 WID on Security Assurance Specification for eNB Huawei, HiSilicon WID new Agreement Yes
Yes
 		agreed No   S3‑161111
7.3 Enhanced Access Security for Extended Coverage GSM in relation to Cellular IoT (EASE_EC_GSM) S3‑160955 Correction of CR implementation omissions MCC CR Agreement Yes
YesMCC commented that these were implementation errors brought to this meeting for formal agreement. These issues were agreed already in CR#0040. This CR was merged with 1092 which clashed with the figure change proposed in 1092.
 		merged No S3‑161179  
    S3‑161088 Remaining open issues in EASE: problem descriptions and solution proposals Ericsson discussion Decision Yes
Yes
 		noted No    
    S3‑161092 Corrections to EASE Ericsson CR Approval Yes
Yes
 		revised No S3‑161180  
    S3‑161180 Corrections to EASE Ericsson CR Approval Yes
Yes
 		agreed No   S3‑161092
    S3‑161108 Secure delivery of IOV-values to the MS in enhanced GPRS Ericsson CR Approval Yes
Yes
 		merged No S3‑161179  
    S3‑161179 Secure delivery of IOV-values to the MS in enhanced GPRS Ericsson CR Approval Yes
Yes
 		agreed No   S3‑161108
7.4 Security Aspects of Narrowband IOT (CIoT) S3‑160911 Reply to: LS on Clarifications on RRC Resume Request R2-164414 LS in   Yes
Yes
 		noted No    
    S3‑160915 Response LS on Clarifications on RRC Resume Request R3-161426 LS in   Yes
Yes
 		noted No    
    S3‑160984 NBIoT UP Solution CR Nokia, Ericsson CR Approval Yes
Yes
 		agreed No    
7.5 New GPRS algorithms for EASE (EASE_ALGOs_SA3) S3‑160928 Discussion document on the progress of EASE ALGO work item. VODAFONE Group Plc discussion Information Yes
YesNTT-Docomo commented that trying to rush it didn’t look appropiate and a delay would be acceptable. Orange: SA3 will not comment much on the specs given the lack of expertise in cryptography. Docomo commented that they have insisted on public review, not just in SA3 so external review would be also possible. MCC commented that apparently the papers would be sent on Monday of the meeting week, but they needed confirmation from ETSI. It was agreed to choose option one with an exception to be submitted to SA.
 		noted No    
    S3‑161138 New GPRS algorithms – status update ETSI SAGE LS in   Yes
YesVodafone commented that the algorithm specifications hadn’t in fact been sent to the French government, still stuck in ETSI's legal department. Two options are given to procceed further. Tdoc 928 discusses the options.
 		noted No    
    S3‑161181 Exception sheet EASE-ALGO_SA3 Vodafone WI exception request Agreement No
Yes
 		agreed No    
7.6.1 IP Multimedia Subsystem (IMS) Security                      
7.6.2 Network Domain Security (NDS) S3‑161055 Clarifying which RFC is relevant for ECDSA Nokia, Gemalto CR   Yes
YesNokia commented that there is a new RFC, so a decision was to be made whether to refer to the new RFC or to the old one. Ericsson: this RFC contains three variants of the same algorithm. If we go for the old RFC we have to specify further, whether to mandate three hashes. Ericsson: is there anything implemented? US Office commented that they were querying about the current status of the implementation. The Chairman commented that it made sense to delay this CR until we had more information.
 		postponed No    
    S3‑161148 Comment contribution to S3-161055 "Clarifying which RFC is relevant for ECDSA" Ericsson CR   No
No
 		withdrawn Yes    
    S3‑161149 Comments on S3-161055 "Clarifying which RFC is relevant for ECDSA" Ericsson CR   Yes
Yes
 		not pursued No    
7.6.3 UTRAN Network Access Security S3‑161051 Enforce mutual authentication ORANGE CR Agreement Yes
Yes
 		revised No S3‑161162  
    S3‑161162 Enforce mutual authentication ORANGE, Telecom Italia, Deutsche Telekom, Vodafone, Gemalto, Oberthur, Giesecke&Devrient, TeliaSonera, Vodafone CR Agreement Yes
YesNokia gave an example of quintuplet attack that should be addressed here. Prevent PLMN id being spoofed. Vodafone: MMC,MNC is translated into what we see on the screen of the UE. CESG: this is not the case on the screen of my phone. He doesn’t see the country where he is. Docomo: should we do something even if Nokia's example of attack is possible? Vodafone: put in the SIM ,MNC and MMC codes that prevent such thing. Docomo: is it worth it in terms of additional overhead? Orange: it would implementation specific to solve this issue. It was agreed to add a NOTE with a recommendation. Qualcomm: send it to CT1 for comments. Vodafone: also to CT6.
 		agreed No   S3‑161051
    S3‑161224 LS on enhancing legacy GSM security Qualcomm LS out Approval No
Yes
 		approved No    
7.6.4 GERAN Network Access Security S3‑160909 LS on Solving Legacy Security Issues GSMA FSAG LS in   Yes
Yes
 		replied to No    
    S3‑161049 2G Security improvements ORANGE CR Agreement Yes
Yes
 		revised No S3‑161161  
    S3‑161161 2G Security improvements ORANGE, Telecom Italia, Gemalto, Oberthur, Giesecke&Devrient, Vodafone, Deutsche Telekom CR Agreement Yes
YesCESG: why do you expect the base station giving you the right PLMN id? This doesn’t solve the problem. MMC,MNC is translated into a user friendly code but this is not always displayed on the screen. CESG: the fake base station could give me whatever information they want on the network id. It was agreed to have an editor's note to come back to this issue. It was also agreed to send an LS to RAN6 to ask them about these procedures.
 		agreed No   S3‑161049
7.6.5 Generic Authentication Architecture (GAA)                      
7.6.6 Multimedia Broadcast/Multicast Service (MBMS)                      
7.6.7 Security Aspects of Home(e)NodeB (H(e)NB)                      
7.6.8 Security Aspects related to Machine-Type Communication ((e)MTC)                      
7.6.9 Security Aspects of Isolated E-UTRAN Operation for Public Safety (IOPS)                      
7.6.10 Security of MCPTT (MCPTT) S3‑160906 LS response on LS on confidentiality protection of an identity in a value of an XML attribute of an XML element of an XML document included in a SIP message. C1-162978 LS in   Yes
YesCESG commented that SA3 had already commented that there is nothing to do here. Why does CT1 want to investigate an option where we have said this is not feasible? Why discussing this in CT1 and not in SA3?
 		replied to No    
    S3‑161225 Reply to: LS response on LS on confidentiality protection of an identity in a value of an XML attribute of an XML element of an XML document included in a SIP message. CESG LS out approval Yes
Yes
 		approved No    
    S3‑160907 LS on identification of originating MCPTT ID in GMS C1-163039 LS in   Yes
Yes
 		replied to No    
    S3‑161151 LS Reply to S3-160907 (C1-163039) Motorola Solutions Danmark A/S LS out Approval Yes
Yes
 		revised No S3‑161226 S3‑160973
    S3‑161226 LS Reply to S3-160907 (C1-163039) Motorola Solutions Danmark A/S LS out Approval Yes
Yes
 		approved No   S3‑161151
    S3‑160967 Signing of Access Tokens Motorola Solutions Danmark A/S CR Agreement Yes
Yes
 		revised No S3‑161195  
    S3‑161195 Signing of Access Tokens Motorola Solutions Danmark A/S CR Agreement Yes
Yes
 		agreed No   S3‑160967
    S3‑160968 Fix Identity Management interface Motorola Solutions Danmark A/S CR Agreement Yes
Yes
 		revised No S3‑161227  
    S3‑161227 Fix Identity Management interface Motorola Solutions Danmark A/S CR Agreement Yes
Yes
 		agreed No   S3‑160968
    S3‑161062 Correcting GMK revokation in TS 33.179 CESG CR Agreement Yes
Yes
 		agreed No    
    S3‑161143 Clarification on floor control signalling protection Huawei, HiSilicon CR Approval Yes
Yes
 		revised No S3‑161228 S3‑161036
    S3‑161228 Clarification on floor control signalling protection Huawei, HiSilicon CR Approval Yes
Yes
 		agreed No   S3‑161143
    S3‑160934 Correction of some implementation errors MCC CR Agreement Yes
Yes
 		agreed No    
    S3‑161035 Corrections to 33.179 HUAWEI TECHNOLOGIES Co. Ltd. CR Approval Yes
Yes
 		revised No S3‑161229  
    S3‑161229 Corrections to 33.179 HUAWEI TECHNOLOGIES Co. Ltd. CR Approval Yes
Yes
 		agreed No   S3‑161035
    S3‑161061 Clarifications to 33.179 CESG CR Agreement Yes
Yes
 		agreed No    
    S3‑160972 R-14 mission critical TS strategy Motorola Solutions Danmark A/S discussion Endorsement Yes
YesNokia supported approach #2. This was agreed by SA3 as well.
 		endorsed No    
    S3‑160971 New work item for Security Architecture for Mission Critical Services Motorola Solutions Danmark A/S WID new Agreement Yes
Yes
 		revised No S3‑161196  
    S3‑161196 New work item for Security Architecture for Mission Critical Services Motorola Solutions Danmark A/S WID new Agreement Yes
Yes
 		agreed No   S3‑160971
    S3‑160938 Recording and discreet listening of private communications Airbus Group SAS discussion Endorsement Yes
YesCESG commented that they preferred solution1. BT commented that recordings can be kept for a long time. We need a requirement for end users.Both features are needed. Motorola didn’t have a preference on the options. CESG commented that more discussion was needed. Maybe to be discussed in SA3-LI? BT: the LI community are not the end users of this. CESG proposed to send an LS to SA3-LI and SA6.
 		noted No    
    S3‑160973 SA3 response to LS S3-160907 (C1-162780) Motorola Solutions Danmark A/S LS out Approval Yes
Yes
 		revised No S3‑161151  
    S3‑161036 Clarification on floor control signalling protection Huawei, HiSilicon CR Approval Yes
Yes
 		revised No S3‑161143  
    S3‑161171 Discussion of GMK revocation issue CESG discussion discussion Yes
Yes
 		noted No    
    S3‑161230 Clarification on the requirement of recording and discrete listening CESG LS out Approval Yes
Yes
 		approved No    
7.6.11 Security for Enhancements to Proximity-based Services - Extensions (eProSe-Ext-SA3)                      
7.6.12 Other work items S3‑161045 I-WLAN feature withdrawal Ericsson discussion   Yes
YesVodafone: did SA agree on a WID for this work? Anand (Chairman) replied that this will go under TEI13.
 		endorsed No    
8.1 Study on Security for Proximity-based Services (FS_ProSe_Sec) S3‑161139 Solution for Key Issue #7.3.3 on spatial replay Ericsson discussion Endorsement Yes
YesNokia: the attack is still possible even with this solution, it is contained. Ericsson: it will be only possible within a cell. It was proposed to have a living document to work on during several meetings. This was agreed. Qualcomm commented that this could end up in a CR if succcessful. Ntt-Docomo: this happens only in ProSe? Ericsson: the scope is not limited to Prose. It exists since 2006 and it's called "wormhole attack". The proposal in 1139 was endorsed by the group.
 		revised No S3‑161248  
    S3‑161248 Solution for Key Issue #7.3.3 on spatial replay Ericsson discussion Endorsement Yes
YesThis is the skeleton for a living document.
 		noted No   S3‑161139
8.2 TR on Security Assurance scheme for 3GPP network products (33.916) (SCAS-SA3TR) S3‑161119 handling editor's notes in 33.916 NTT DOCOMO pCR Approval Yes
Yes
 		approved No    
    S3‑161145 Handling editor's notes in 33.916 related to figures NTT DOCOMO INC. pCR Approval Yes
Yes
 		approved No    
    S3‑161246 new draft TR 33.916 NTT-Docomo draft TR Approval No
Yes
 		left for email approval No    
    S3‑161247 Cover sheet TR 33.916 NTT-Docomo TS or TR cover Approval No
Yes
 		left for email approval No    
8.3 Study on EGPRS Access Security Enhancements with relation to cellular IoT (FS_EASE_IoT)                      
8.4 Study on IMS Enhanced Spoofed Call Prevention and Detection (FS_ESCAPADES)                      
8.5 Study on security aspects for LTE support of V2X services (FS_V2XLTE) S3‑161026 Adding Architecture section Huawei, HiSilicon pCR Approval Yes
YesNokia: we should refer to the TS, not the TR in SA2.
 		merged No S3‑161155  
    S3‑161155 Adding Architecture section Huawei, HiSilicon, Ericsson, Qualcomm pCR Approval Yes
YesMerge of 1026,1098,1137.
 		approved No   S3‑161026
    S3‑161098 Baseline architecture for V2X Qualcomm Incorporated pCR Approval Yes
Yes
 		merged No S3‑161155  
    S3‑161137 High level description of V2XLTE architecture Ericsson LM pCR   Yes
Yes
 		merged No S3‑161155  
    S3‑161024 Adding References and Definitions and Abbreviations Huawei, HiSilicon pCR Approval Yes
Yes
 		revised No S3‑161156  
    S3‑161156 Adding References and Definitions and Abbreviations Huawei, HiSilicon pCR Approval Yes
Yes
 		approved No   S3‑161024
    S3‑161025 Corrections to TR 33.885 Huawei, HiSilicon pCR Approval Yes
Yes
 		revised No S3‑161157  
    S3‑161157 Corrections to TR 33.885 Huawei, HiSilicon pCR Approval Yes
Yes
 		approved No   S3‑161025
    S3‑160981 V2X Discussion on privacy requirements by regulation Nokia discussion   Yes
YesOrange: the operators are aligned with this, no problems with LTE related procedures in EU. It’s already compliant. In the US part, we identify network identities linked to billing identity, not V2X identities. The security network is not impacted, it's about the identity part. This is outside the scope of 3GPP. Vodafone: we can use these V2X identities in our specs. Orange: in SA3 we don’t work at application level. It’s a separate issue from the IMSI. Qualcomm: it's up to SA1 to decide on the regulator requirements.An LS was sent for clarification already. They are meeting in August. Ericsson: ITS document on privacy issues should also be considered here.
 		noted No    
    S3‑160982 V2X Annex on privacy by regulation EU Nokia pCR   Yes
YesWaiting for SA1 to take action.
 		postponed No    
    S3‑160983 V2X Annex on privacy by regulation US Nokia pCR   Yes
YesWaiting for SA1 to take action.
 		postponed No    
    S3‑160993 V2X privacy - a way forward LG Electronics France discussion Discussion Yes
YesThere is no decision on having IMSI anonymised. Orange doesn’t agree with this. The Chairman asked whether there was anyone agreeing with proposal one. No one replied, so this was gone. Orange: we sent an LS to SA1 already since we didn’t understand those requirements. We don’t need to send this LS. Ericsson preferred to have clarification on this privacy regulation by sending this LS. Vodafone commented that V2X is a 5G feature and expressed their surprise of this not being in NSA. Huawei: it is defined for LTE now. Vodafone: so this is not working in 5G? The Chairman commented that V2X is potentially in 5G. Vodafone: the privacy in 5G may have an effect on the solution we find for V2X.
 		noted No    
    S3‑160994 Draft LS on V2X privacy clarification LG Electronics France LS out Approval Yes
YesVodafone: does this mean that we have to create a special case for V2X? Not clear. The Chairman commented that since proposal one in the previous contribution was discarded the content here could not be sent.
 		noted No    
    S3‑160996 Update of V2X attach id obfuscation LG Electronics France pCR Approval Yes
YesOrange: Anonimty with respect to the third party who knows the IMSI. So there is no anonimity. It doesn’t solve the problem. We are also waiting for SA1's response. Huawei: this is a study that can be continued without having to submit it for the next SA plenary as originally planned. Orange wanted an editor's note with their comments: anonymity with respect to the third party.This was agreed.
 		revised No S3‑161158  
    S3‑161158 Update of V2X attach id obfuscation LG Electronics France pCR Approval Yes
Yes
 		approved No   S3‑160996
    S3‑161094 Correcting a requirement for Vehicle UE Privacy (V2X) Qualcomm Incorporated pCR Approval Yes
YesOrange: this depends on the response from SA1.
 		approved No    
    S3‑161095 Hiding the subscriber IMSI from the serving network for V2X Qualcomm Incorporated pCR Approval Yes
YesOrange: how does the MME discover the home network and how is the request of authorization is routed? Qualcomm: CT1 will probably decide eventually. Orange: we don’t know the deployment options, so not true that there is one HSS in there. Todor didn’t understand how the privacy issue is handled here. The MCC needs to be provided. Orange: Home PLMN instead of Home V2X network. Orange: Auth vector request is routed for the second option is more an stage 2 option than stage 3. BT: agree with Todor, and also this is not aligned with 5G proposals. Interdigital: encryption of the IMSI is random. Qualcomm agreed. It was agreed to have an editor's note. CESG: denial of service attack to the HSS needs to be considered. Nokia: step 2 in 6.x.2.1 means additional complexity and there are other ways to get around that. CESG: LI aspects to be considered as well. A group of editor's notes will include these and more concerns from the companies.
 		revised No S3‑161163  
    S3‑161163 Hiding the subscriber IMSI from the serving network for V2X Qualcomm Incorporated pCR Approval Yes
Yes
 		approved No   S3‑161095
    S3‑161096 Reattach procedure for Vehicle UE Identity Privacy Qualcomm Incorporated pCR Approval Yes
YesNokia: large load on the eNodeB. It was agreed on having an editor's note on this.
 		revised No S3‑161164  
    S3‑161164 Reattach procedure for Vehicle UE Identity Privacy Qualcomm Incorporated pCR Approval Yes
Yes
 		approved No   S3‑161096
    S3‑161097 Vehicle UE privacy based on data traversing the network Qualcomm Incorporated pCR Approval Yes
YesEricsson: There is a NAT so you can’t see the IP of the UE. Qualcomm: if the NAT address doesn’t change it's ok. Ericsson: the IP address needs to be changed everytime the UE attaches, then. Qualcomm: this is one of the proposals. Huawei: the application layer doesn't know what the lower layer is doing. Nokia: we need to study the performance impact on the HSS.
 		revised No S3‑161165  
    S3‑161165 Vehicle UE privacy based on data traversing the network Qualcomm Incorporated pCR Approval Yes
Yes
 		approved No   S3‑161097
    S3‑161021 Key issue about data communication security between network entities Huawei, HiSilicon pCR Approval Yes
Yes
 		revised No S3‑161166  
    S3‑161166 Key issue about data communication security between network entities Huawei, HiSilicon pCR Approval Yes
Yes
 		approved No   S3‑161021
    S3‑161022 Key issue about V2I broadcast communication security Huawei, HiSilicon pCR Approval Yes
YesOrange: who authorizes the UE in the second requirement? Huawei: The network. It was also commented that requirements should be written in active voice to avoid ambiguities on who is doing the action.
 		revised No S3‑161167  
    S3‑161167 Key issue about V2I broadcast communication security Huawei, HiSilicon pCR Approval Yes
Yes
 		approved No   S3‑161022
    S3‑161027 Data communication security between network entities Huawei, HiSilicon pCR Approval Yes
Yes
 		approved No    
    S3‑161029 Security for V2X Broadcast Communication: Life Time of Credentials Huawei, HiSilicon, Deutsche Telekom AG pCR Approval Yes
Yes
 		revised No S3‑161168  
    S3‑161168 Security for V2X Broadcast Communication: Life Time of Credentials Huawei, HiSilicon, Deutsche Telekom AG pCR Approval Yes
Yes
 		approved No   S3‑161029
    S3‑161030 Security for V2X Broadcast Communication: Replay Protection Huawei, HiSilicon, Deutsche Telekom AG pCR Approval Yes
Yes
 		approved No    
    S3‑161031 Security for V2X Broadcast Communication: Introducing Temporary ID management Function for V2X Data Source Accountability Huawei, HiSilicon, Deutsche Telekom AG pCR Approval Yes
YesNokia: is it in scope to add new identities? Huawei: it's part of the security architecture. Orange: no impact on network level identities, this influences application layer IDs. Added a note and an editor's note concerning Orange and BT's comments.
 		revised No S3‑161169  
    S3‑161169 Security for V2X Broadcast Communication: Introducing Temporary ID management Function for V2X Data Source Accountability Huawei, HiSilicon, Deutsche Telekom AG pCR Approval Yes
Yes
 		approved No   S3‑161031
    S3‑161136 Solution for communication security with V2X network entities Ericsson LM pCR   Yes
Yes
 		approved No    
    S3‑160980 V2X requirement on updating of crypto Nokia pCR   Yes
YesCESG pointed out the issue of management of updating the algorithms. This was put in an editor's note. Klaus: clarify security maintaninability in the requirement. This was agreed.
 		revised No S3‑161172  
    S3‑161172 V2X requirement on updating of crypto Nokia pCR - Yes
Yes
 		approved No   S3‑160980
    S3‑161099 Legitimacy of V2X messages on key issue for data source accountability Qualcomm Incorporated pCR Approval Yes
Yes
 		revised No S3‑161173  
    S3‑161173 Legitimacy of V2X messages on key issue for data source accountability Qualcomm Incorporated pCR Approval Yes
Yes
 		approved No   S3‑161099
    S3‑161132 Solution for authorization and accountability in V2X systems Ericsson pCR   Yes
Yes
 		revised No S3‑161174  
    S3‑161174 Solution for authorization and accountability in V2X systems Ericsson pCR - Yes
Yes
 		approved No   S3‑161132
    S3‑161028 Key issue about security of UE to V2X Control Funtion interface Huawei, HiSilicon pCR Approval Yes
YesNokia: it may be applicable to the whole V3 interface. It was agreed to remove "configuration" in the requirements so it is applicable to all data. Interdigital proposed to reword "eavesdropping", it was not the correct term. Qualcomm proposed " stored in a confidentiality protected way". This was agreed.
 		revised No S3‑161175  
    S3‑161175 Key issue about security of UE to V2X Control Funtion interface Huawei, HiSilicon pCR Approval Yes
Yes
 		approved No   S3‑161028
    S3‑161023 Security of UE to V2X Control Funtion interface Huawei, HiSilicon pCR Approval Yes
Yes
 		revised No S3‑161176  
    S3‑161176 Security of UE to V2X Control Funtion interface Huawei, HiSilicon pCR Approval Yes
Yes
 		approved No   S3‑161023
    S3‑161072 pCR to 33.885 - New Key Issue on Detectability of Malicious behaviour TNO pCR Approval Yes
YesEricsson: safety related aspects are out of scope. There are other SDOs dealing with this. We cannot address faulty mechanisms here. They proposed to add and editor's note questioning the vailidy of this. Interdigital: the networks should detect strange behaviour in the car (e.g. sensing ice in a summer day). BT: selecting disabling determined devices is a possibility but out of scope. Huawei: the requirement is to disabling the sending of the erroneous data but not disabling the whole device. Orange: there are no requirements here, let's put editor's notes addressing these issues. This was agreed.
 		revised No S3‑161177  
    S3‑161177 pCR to 33.885 - New Key Issue on Detectability of Malicious behaviour TNO pCR Approval Yes
Yes
 		approved No   S3‑161072
    S3‑161178 New draft TR 33.885 Huawei draft TR Approval No
Yes
 		left for email approval No    
8.6 Study on Architecture and Security for Next Generation System (FS_NSA) S3‑161131 LS on "Next Generation" Security Requirements S2-164280 LS in   Yes
Yes
 		replied to No   S3‑161034
    S3‑161182 Reply to: LS on "Next Generation" Security Requirements Vodafone LS out approval Yes
Yes
 		approved No    
    S3‑161046 LS to SA1 on factory automation requirements ORANGE LS out Approval Yes
Yes
 		revised No S3‑161159  
    S3‑161159 LS to SA1 on factory automation requirements ORANGE LS out Approval Yes
YesInterdigital didn’t agree with the use of the UE here. UE is AKA and IMSI. If we expand from UE to add the definition of device. You program the answer, which is IMSI + AKA. Orange: you authenticate the customer, not the device. Orange: we should talk about UE in 5G, not UE in 4G. Interdigital: if we don’t say device the answer will be programmed. Nokia: generalize UE for 5G. Nokia: better not to discuss issues related to SA1's TR since they will start a TS soon and it will not be relevant anymore. Oberthur: no requirement outside the factory. Ericsson: we should take a look at clause 6 in TR 22.862. Ericsson: the LS is asking for changes in SA1 TRs that are closed already. Qualcomm: there are more than one authentication methods, they didn’t understand what the problema was with not having clear "alternative authentication methods". Claus (G&D): there is still confusion on these identifiers. It doesn’t hurt to send this to SA1. China Mobile supported sending this LS. Orange: seven companies supporting this LS, two don’t support it. Ericsson commented that there is a difference in the wording, not on sending the LS. Qualcomm had the same opinion. This had to be taken offline.
 		approved No   S3‑161046
    S3‑160924 pCR to 33.899 - update of the Introduction section VODAFONE Group Plc pCR Approval Yes
YesEricsson and Docomo commented that reference to 3GPP working groups and work items should be removed. They also commented that when referring to white papers of other organizations there should be references to them. This was confirmed by MCC.
 		revised No S3‑161184  
    S3‑161184 pCR to 33.899 - update of the Introduction section VODAFONE Group Plc pCR Approval Yes
Yes
 		approved No   S3‑160924
    S3‑160925 pCR to TR 33.899 - update of section 4.2 High level security requirements VODAFONE Group Plc pCR Approval Yes
YesOrange suggested to add a clause on signalling. Claus (G&D): difference between service, network service and NextGen services? Vodafone: to distinguish the new services that don’t exist in legacy networks. Claus (G&D): we should distinguish the different services. Juniper: an editor's note on the need for clear definitions for these services. Qualcomm: no need to have different clauses, the radio interface clause is too detailed to be high level. NTT-Docomo: subscriber privacy left out? It was agreed to be added.
 		revised No S3‑161185  
    S3‑161185 pCR to TR 33.899 - update of section 4.2 High level security requirements VODAFONE Group Plc pCR Approval Yes
Yes
 		approved No   S3‑160925
    S3‑161109 Availability of the control plane in Next Gen TNO pCR Approval Yes
YesOrange supported this contribution. Interdigital: why only UE? It would be for anything connected to the network. It was agreed to add an editor's note on the lack of definition or terminology about UE. BT: the attacks can come from false networks too.
 		merged No S3‑161185  
    S3‑160977 NSA Adding new security area on broadcast multicast Nokia pCR   Yes
Yes
 		revised No S3‑161186  
    S3‑161186 NSA Adding new security area on broadcast multicast Nokia pCR - Yes
Yes
 		approved No   S3‑160977
    S3‑160978 NSA new security area on interworking and migration Nokia pCR   Yes
YesMCC commented that all references to 3GPP working groups, working methods, tdoc numbers and so on should be removed from the Introduction. The specification should refer to other 3GPP specifications in this case. It was agreed to move such references to the Editor's note in the Introduction.
 		revised No S3‑161188  
    S3‑161188 NSA new security area on interworking and migration Nokia pCR - Yes
Yes
 		approved No   S3‑160978
    S3‑160991 Security aspects of Connectionless RAN-CN interface Nokia pCR Approval Yes
YesEricsson: no need to describe all solutions, just enumerate them.
 		revised No S3‑161189  
    S3‑161189 Security aspects of Connectionless RAN-CN interface Nokia pCR Approval Yes
Yes
 		approved No   S3‑160991
    S3‑160926 pCR to 33.899 - update of 5.1.2 Security assumptions (Architectural aspects of 5G security) VODAFONE Group Plc pCR Approval No
No
 		withdrawn Yes    
    S3‑161117 pCR adding the definition of security anchor in the section 3.1 China Mobile Com. Corporation, Huawei, Hisilicon pCR Approval Yes
Yes
 		revised No S3‑161150  
    S3‑160952 pCR to TR 33.899: Proposal of key hierarchy for 5G security NEC pCR Approval Yes
YesVodafone: no requirements without security threats. Interdigital: one set of control plane keys in the figure. A slice is not a complete network from end to end. This contribution was discussed with the similar 1101 from Qualcomm. Qualcomm: is the control plane the same for all slices? NEC: only one common control plane. Vodafone: it is likely that there will slices in both user and control planes. Nokia: control function common or split is still being discussed in SA2. Orange: slicing is also being defined in RAN so we also depend on their outcome. NEC: Key hierarchy should be defined separately from the architecture.
 		revised No S3‑161192  
    S3‑161192 pCR to TR 33.899: Proposal of key hierarchy for 5G security NEC pCR Approval Yes
Yes
 		approved No   S3‑160952
    S3‑160966 Security for serving functions not in physical protected place ZTE Corporation pCR Approval Yes
YesInterdigital: access networks are not insecure in principle. Vodafone: access networks are harder to protect, it does not necessarily means that are insecure. We need a mechanism to know where to locate the function. Close or far is not enough. What do they mean? Vodafone: this document needs heavy re-wording.
 		revised No S3‑161193  
    S3‑161193 Security for serving functions not in physical protected place ZTE Corporation pCR Approval No
Yes
 		approved No   S3‑160966
    S3‑161044 pCR to TR 33.899: UEs with Asymmetric Keys VODAFONE Group Plc pCR Approval Yes
YesGemalto: one key is a weakness. If you attack this key everything is down. They didn’t agree with the contribution. Huawei and BT supported the contribution. This was taken offline. Claus (G&D): quantum key cryptography is too far away. Vodafone: this is a TR. Gemalto supported this sentence.
 		revised No S3‑161259  
    S3‑161259 pCR to TR 33.899: UEs with Asymmetric Keys VODAFONE Group Plc pCR Approval Yes
Yes
 		approved No   S3‑161044
    S3‑161067 pCR to TR 33.899 v0.3.0 "Architecture - modifying key issue titles" Nokia pCR   Yes
Yes
 		approved No    
    S3‑161069 pCR to TR 33.899 v0.3.0 "Architecture - security features on AN-CN interfaces" Nokia pCR   Yes
Yes
 		approved No    
    S3‑161070 pCR to TR 33.899 v0.3.0 "Architecture - security features on CN-CN interfaces" Nokia pCR   Yes
Yes
 		approved No    
    S3‑161135 pCR to TR 33.899: Security Implications of Low Latency VODAFONE Group Plc pCR Approval Yes
Yes
 		revised No S3‑161194  
    S3‑161194 pCR to TR 33.899: Security Implications of Low Latency VODAFONE Group Plc pCR Approval Yes
Yes
 		approved No   S3‑161135
    S3‑161002 PCR of User Plane Security Protection Huawei, HiSilicon, Deutsche Telekom AG, Vodafone pCR   Yes
YesNokia: Key issue description looks more like a solution. Orange: why do we need KMS as a separate function for key derivation? We can reuse what we have. Huawei: it’s a logical entity, it can be located anywhere. Ericsson clarified that this describes a session based security solution. LG: there is no negotiation procedure here. Qualcomm: There are different policies and we need to clarify where they are coming from (e.g. policy control). Nokia: there is a risk of confusion when using "policy control" since it could be confused with the PCRF.
 		revised No S3‑161197  
    S3‑161197 PCR of User Plane Security Protection Huawei, HiSilicon, Deutsche Telekom AG, Vodafone pCR - Yes
Yes
 		approved No   S3‑161002
    S3‑160964 An overview of NextGen security architecture ZTE Corporation pCR Approval Yes
YesEricsson: virtualised or not they are network functions (VsF in figure). Orange: network access security and secure access to services. What's the intention here? ZTE: it's coming from 33.401. Orange: what is the trusted storage computing? Where is this figure coming from? Huawei: no connection from the 3GPP AN to the core network. ZTE: this is coming from 33.401 and 23.799, combined with some modifications. Orange: we need to be clear on where this figure is coming from. Nokia didn’t agree with the figure capturing SA2 agreements. 3GPP AN access, network slice connections don’t capture the agreements. We need to wait for SA2 before having such a figure. BT: it would be good to agree on a figure like this for 33.401.Orange supported this, although they didn’t agree on this one.
 		noted No    
    S3‑161101 pCR solution to Key # 1.2 on the need a security anchor Qualcomm Incorporated pCR Approval Yes
YesVodafone: The solution is as vulnerable as the equivalent solution in LTE (with Kasme). Qualcomm: we cannot assume all credentials will be in HSS.. Ericsson supported Orange: this should be read in the context of SA2, how they specify the AAA entity. Qualcomm: maybe an editor's note about a decision that needs to be taken on the split storage of credentials. Nokia: in 33.402 we split AAA and HSS already. Orange: AAA is only used in non 3GPP access, do we need it now for all use cases? It’s an open issue. Huawei: CP-AU can be in both home or visited network. Nokia: it is for further study whether CP-AU can change when the UE moves. Huawei: we need to decided whether in NextGen we will have an HSS or not.
 		revised No S3‑161191  
    S3‑161191 pCR solution to Key # 1.2 on the need a security anchor Qualcomm Incorporated pCR Approval Yes
Yes
 		approved No   S3‑161101
    S3‑160945 pCR to TR 33.899: Radio interface user plane integrity protection, Solution details VODAFONE Group Plc pCR Approval Yes
Yes
 		approved No    
    S3‑160927 pCR to 33.899 - Reword section 5.2.3.2.2 and 5.2.3.3 as per editors notes VODAFONE Group Plc pCR Approval No
No
 		withdrawn Yes    
    S3‑160946 pCR to TR 33.899: Authentication section introduction VODAFONE Group Plc pCR Approval Yes
Yes
 		revised No S3‑161198  
    S3‑161198 pCR to TR 33.899: Authentication section introduction VODAFONE Group Plc pCR Approval Yes
Yes
 		approved No   S3‑160946
    S3‑161065 Key Issue #2.1: Authentication framework INTERDIGITAL COMMUNICATIONS pCR Approval Yes
Yes1123 proposed a similar issue, so both tdocs were merged.
 		merged No S3‑161199  
    S3‑161074 pCR to TR 33.899 v0.3.0 "Authentication framework - key issue" Nokia pCR   Yes
Yes
 		approved No    
    S3‑161075 pCR to TR 33.899 v0.3.0 "Authentication framework - requirements" Nokia pCR   Yes
YesOrange: the second requirement does not correspond to the current SA2 specification. Nokia commented that this was taken probably from a previous version of the SA2 spec.
 		revised No S3‑161201  
    S3‑161201 pCR to TR 33.899 v0.3.0 "Authentication framework - requirements" Nokia pCR - Yes
Yes
 		approved No   S3‑161075
    S3‑160939 Key issue #2.4: Device identifier authentication INTERDIGITAL COMMUNICATIONS pCR Approval Yes
YesQualcomm suggested for Non tampered: secure and protected instead. Interdigital disagreed. BT: associated device identity credentials and not just credentials storage. Claus:we haven’t agreed on device credentials, agree with BT. Device auth more than device identifier auth. Nokia: device auth is a key issue, auth without credentials would be too difficult. Gemalto didn’t agree with addressing the issue of having device authentication as the only auth needed and performed. The editor's note was removed.
 		revised No S3‑161202  
    S3‑161202 Key issue #2.4: Device identifier authentication INTERDIGITAL COMMUNICATIONS pCR Approval Yes
Yes
 		approved No   S3‑160939
    S3‑161127 pCR complete the section 5.2.3.6 China Mobile Com. Corporation pCR Approval Yes
YesVodafone: this is not adding anything. Nokia agreed.
 		noted No    
    S3‑161123 pCR adding the potential security requirements into the section 5.2.3.7 China Mobile Com. Corporation, Huawei, Hisilicon pCR Approval Yes
YesBT wanted to keep the back off mechanism.TNO supported this since they also propose it in 1073. Ericsson commented that the second requirement on back off should go away.
 		merged No S3‑161199  
    S3‑161199 pCR adding the potential security requirements into the section 5.2.3.7 China Mobile Com. Corporation, Huawei, Hisilicon pCR Approval Yes
Yes
 		approved No   S3‑161123
    S3‑160975 pCR to TR 33.899: Authentication of the user VODAFONE Group Plc pCR Approval Yes
YesNokia: Associating the user with the device is associating two identities. Vodafone: the device is the UE. The content will be reviewed according to the discussion on the definition of device.
 		revised No S3‑161260  
    S3‑161260 pCR to TR 33.899: Authentication of the user VODAFONE Group Plc pCR Approval Yes
Yes
 		approved No   S3‑160975
    S3‑161003 Key Issue of Security for Service Provider Connection Huawei, HiSilicon, Deutsche Telekom AG, KPN pCR   Yes
YesOrange: where are the requirements for SA3 in 22.861? It was decided to check this offline. Orange: No defintion of service provider in 3GPP -> it becomes third party in the contribution.
 		revised No S3‑161203  
    S3‑161203 Key Issue of Security for Service Provider Connection Huawei, HiSilicon, Deutsche Telekom AG, KPN pCR - Yes
Yes
 		approved No   S3‑161003
    S3‑161001 Resolving Editor’s notes in Key Issue #2.1 Authentication framwork Huawei, HiSilicon pCR Approval Yes
Yes
 		noted No    
    S3‑161018 pCR to TR 33.899 New key issue - Secondary authentication by 3rd party service Nokia pCR Approval Yes
Yes
 		revised No S3‑161204  
    S3‑161204 pCR to TR 33.899 New key issue - Secondary authentication by 3rd party service Nokia pCR Approval Yes
Yes
 		approved No   S3‑161018
    S3‑161125 pCR choice of authentication methods China Mobile Com. Corporation, Huawei, Hisilicon pCR Approval Yes
YesVodafone: the threat is a bit OK. China Mobile: one IMSI can have several credentials. It's one possibility. Huawei supported this. Ericsson: the IMSI is one key identifier, I don’t get it. There should be two identifiers. Vodafone: who chooses the auth methods? Nokia: this is not a valid requirement. China Mobile: we avoid any negotiation, the choice of auth methods needs to be performed. We need to decide which auth methods are to be chosen. Qualcomm supported the idea of having several auth methods. The second requirement is not a requirement but a solution. Ericsson: it becomes a network selection problem then.
 		postponed No    
    S3‑161073 pCR to add a solution 'back-off timer' for key issue 5.2.3.7 TNO pCR Approval Yes
Yes
 		revised No S3‑161200  
    S3‑161200 pCR to add a solution 'back-off timer' for key issue 5.2.3.7 TNO pCR Approval Yes
Yes
 		approved No   S3‑161073
    S3‑161043 pCR to TR 33.899: Enhancing DH session key derivation VODAFONE Group Plc pCR Approval Yes
Yes
 		approved No    
    S3‑161076 pCR to TR 33.899 v0.3.0 "Authentication framework - solution A - candidate methods" Nokia pCR   Yes
Yes
 		approved No    
    S3‑161077 pCR to TR 33.899 v0.3.0 "Authentication framework - solution A - transport considerations" Nokia pCR   Yes
YesSamsung: RAN should be included for the transport of authentication. Huawei: AAA in home network or visited network? Nokia: this is still open. It was agreed to add an editor's note on this.
 		revised No S3‑161205  
    S3‑161205 pCR to TR 33.899 v0.3.0 "Authentication framework - solution A - transport considerations" Nokia pCR - Yes
Yes
 		approved No   S3‑161077
    S3‑161078 pCR to TR 33.899 v0.3.0 "Authentication framework - solution A - efficiency considerations" Nokia pCR   Yes
Yes
 		revised No S3‑161206  
    S3‑161206 pCR to TR 33.899 v0.3.0 "Authentication framework - solution A - efficiency considerations" Nokia pCR - Yes
Yes
 		approved No   S3‑161078
    S3‑161079 pCR to TR 33.899 v0.3.0 "Authentication framework - solution A - general information flow" Nokia pCR   Yes
YesOrange: third party auth server is not clear to exist in 5G according to the requirements. An editor's note was added to address this issue.
 		revised No S3‑161207  
    S3‑161207 pCR to TR 33.899 v0.3.0 "Authentication framework - solution A - general information flow" Nokia pCR - Yes
Yes
 		approved No   S3‑161079
    S3‑161080 pCR to TR 33.899 v0.3.0 "Authentication framework - solution A - alternatives" Nokia pCR   Yes
Yes
 		revised No S3‑161208  
    S3‑161208 pCR to TR 33.899 v0.3.0 "Authentication framework - solution A - alternatives" Nokia pCR - Yes
Yes
 		approved No   S3‑161080
    S3‑161082 pCR to TR 33.899 v0.3.0 "Authentication framework - solution A - initial evaluation" Nokia pCR   Yes
Yes
 		approved No    
    S3‑161081 EAP Encapsulation Protocol Samsung pCR Approval Yes
YesHuawei: CP-AU is not the right term. Samsung: it's the key. Discussed together with 1084.
 		revised No S3‑161210  
    S3‑161210 EAP Encapsulation Protocol Samsung pCR Approval Yes
Yes
 		approved No   S3‑161081
    S3‑161084 New solution to security area #2: EAP authentication framework Ericsson pCR   Yes
YesQualcomm: CP-AU in home network, similar to AAA server. Nokia: CP-AU, AAA terminology is ambiguous and their definitions are unclear according to SA2's work. A decision needs to be made in SA3 to clarify the terminology. Samsung;s 1081 and Ericsson's 1084 are using different terminology.It was concluded to add editor's notes on 1207,1210,1209 for this.
 		revised No S3‑161209  
    S3‑161209 New solution to security area #2: EAP authentication framework Ericsson pCR - Yes
Yes
 		approved No   S3‑161084
    S3‑161105 Solution for Key issue #2.4: Device identifier authentication Qualcomm Incorporated pCR Approval Yes
YesVodafone: every operator's AAA needs to have all certificate devices. It might be an issue for new parties coming to the market. Roaming is also an issue. An editor's note was added. BT: nuimber of subscriptions and number of devices are different. Scaling is an issue. Interdigital: what is the secure storage/secure part of the device? Qualcomm: it is defined in another contribution. Orange: the operator depends on the manufacturer CA or third party CA here, this is against the requirements.
 		revised No S3‑161211  
    S3‑161211 Solution for Key issue #2.4: Device identifier authentication Qualcomm Incorporated pCR Approval Yes
Yes
 		approved No   S3‑161105
    S3‑161086 pCR to TR 33.899 v0.3.0 "Replacing solution 2.2 with reference to solution 3.1" Nokia pCR   Yes
Yes
 		revised No S3‑161267  
    S3‑161267 pCR to TR 33.899 v0.3.0 "Replacing solution 2.2 with reference to solution 3.1" Nokia pCR - Yes
Yes
 		approved No   S3‑161086
    S3‑160947 pCR to TR 33.899: Radio interface key exchange protocol VODAFONE Group Plc pCR Approval Yes
Yes
 		revised No S3‑161268  
    S3‑161268 pCR to TR 33.899: Radio interface key exchange protocol VODAFONE Group Plc pCR Approval Yes
Yes
 		approved No   S3‑160947
    S3‑161087 pCR to TR 33.899 v0.3.0 "Evaluation of Solution #3.1: Including a key exchange..." Nokia pCR   Yes
Yes
 		revised No S3‑161269  
    S3‑161269 pCR to TR 33.899 v0.3.0 "Evaluation of Solution #3.1: Including a key exchange..." Nokia pCR - Yes
Yes
 		approved No   S3‑161087
    S3‑160948 pCR to TR 33.899: interception of radio interface keys sent between operator entities VODAFONE Group Plc pCR Approval Yes
YesEricsson: this is not really a requirement. It was agreed to re-word the requirements and the key-issue details.
 		revised No S3‑161270  
    S3‑161270 pCR to TR 33.899: interception of radio interface keys sent between operator entities VODAFONE Group Plc pCR Approval Yes
Yes
 		approved No   S3‑160948
    S3‑160949 pCR to TR 33.899: UE action if network does not update session keys VODAFONE Group Plc pCR Approval Yes
Yes
 		revised No S3‑161271  
    S3‑161271 pCR to TR 33.899: UE action if network does not update session keys VODAFONE Group Plc pCR Approval Yes
Yes
 		approved No   S3‑160949
    S3‑161100 pCR on allowing non-radio interface keys to be refreshed in the existing key issue on Refreshing radio interface keys Qualcomm Incorporated pCR Approval Yes
Yes
 		revised No S3‑161273  
    S3‑161273 pCR on allowing non-radio interface keys to be refreshed in the existing key issue on Refreshing radio interface keys Qualcomm Incorporated pCR Approval Yes
Yes
 		approved No   S3‑161100
    S3‑160979 NSA - 5.3.3.3 - addressing ENs on bidding down attack and requirements reformulation Nokia pCR   Yes
Yes
 		approved No    
    S3‑161113 pCR to 33.899 - Resolution of EN in 5.3.3.2.3 TNO pCR Approval Yes
YesQualcomm suggested removing e2e as editorial change. This was agreed.
 		revised No S3‑161272  
    S3‑161272 pCR to 33.899 - Resolution of EN in 5.3.3.2.3 TNO pCR Approval Yes
Yes
 		approved No   S3‑161113
    S3‑161007 Threats for Security Context Sharing Huawei, HiSilicon,Deutsche Telekom AG, China Mobile pCR   Yes
Yes
 		revised No S3‑161274  
    S3‑161274 Threats for Security Context Sharing Huawei, HiSilicon,Deutsche Telekom AG, China Mobile pCR - Yes
Yes
 		approved No   S3‑161007
    S3‑161106 Finalising Key issue #3.5: Unnecessary dependence of keys between security layers Qualcomm Incorporated pCR Approval Yes
YesNokia: requirement not clear. NTT-Docomo: the requirement is good but it needs re-wording. Orange: what does "unnecessary" mean?
 		revised No S3‑161275  
    S3‑161275 Finalising Key issue #3.5: Unnecessary dependence of keys between security layers Qualcomm Incorporated pCR Approval Yes
Yes
 		approved No   S3‑161106
    S3‑161144 The storage of security context Huawei; HiSilicon; China Mobile pCR Approval Yes
YesMCC: the NOTE should be an editor's note. Ericsson: remove the "must" and add "shall".
 		revised No S3‑161276 S3‑161009
    S3‑161276 The storage of security context Huawei; HiSilicon; China Mobile pCR Approval Yes
Yes
 		approved No   S3‑161144
    S3‑161010 Security context for connectionless mode Huawei; HiSilicon pCR Approval Yes
YesEricsson: the key details are not clear. This can be any threat.An editor's note was added. MCC: remove the SMARTER term and add reference to 22.891 Connectionless becomes small data.
 		revised No S3‑161277  
    S3‑161277 Security context for connectionless mode Huawei; HiSilicon pCR Approval Yes
Yes
 		approved No   S3‑161010
    S3‑160998 Solution for NSA security context sharing LG Electronics France pCR Approval Yes
YesNokia: this only applies to trusted access, not untrusted access. Some other comments from Nokia were treated offline.
 		noted No    
    S3‑161005 Security Context and Key Management Huawei, HiSilicon, Deutsche Telekom AG pCR Approval Yes
YesNokia found the auth and security derivation flow not clear. The term seccurity context is used in different ways. Orange: What is supplicant? Huawei: this is defined in SA2. The Chairman suggested to refer to the solution in SA2 and change the text accordingly. Nokia: some access special module in the UE is requesting authentication. This is for further study,
 		revised No S3‑161278  
    S3‑161278 Security Context and Key Management Huawei, HiSilicon, Deutsche Telekom AG pCR Approval Yes
Yes
 		approved No   S3‑161005
    S3‑161011 pCR adding security assumptions in security area 5.4 THALES pCR Approval Yes
YesNokia suggested to remove the second paragraph. The first paragraph is a description of the architecture that should go to another part of the specification. This was finally noted.
 		noted No    
    S3‑161019 Discussion on the necessity to reinforce the radio air interface for the next generation system THALES discussion Discussion Yes
YesNokia: this is a notion that everything we have done from GSM is insecure. Thales: it’s not a standalone solution but a brick in the wall of a whole set of new solutions. We need to consider new kinds of solutions as well.
 		noted No   S3‑161014
    S3‑161017 pCR adding key issue in security area 5.4 THALES pCR Approval Yes
YesNokia: Disclosure of auth parameters belongs to the privacy issues addressed somewhere else. Nokia: Also,some part of this text is already adressed in one of the Vodafone's contributions, security areas 2 and 3. Thales: refer to the signalling data before the auth is established to make it more generic. Nokia: this is not a threat, physical layer signalling, not to be addressed in SA3. Thales: all the attacks are coming this way now, we need to address this in 5G.
 		noted No    
    S3‑161083 Key issue Security requirements on gNB Ericsson pCR Approval Yes
YesNokia: what virtual deployments of gNodeB? Ericsson: this was discussed in RAN. Nokia wanted an editor's note for more explanation on this core deployment,
 		revised No S3‑161279  
    S3‑161279 Key issue Security requirements on gNB Ericsson pCR Approval Yes
Yes
 		approved No   S3‑161083
    S3‑161085 Key issue Security aspects of dual connectivity Ericsson pCR Approval Yes
YesBT: in 33.401 we talk about dual connectivity already, Nokia: is this dual connectivity scenarios or interworking scenarios? Ericsson: this is dual connecitvity. Nokia: where to put this? It's a new security area. MCC: not possible to reference a tdoc (SA plenary doc in this case). BT: Restrict to the scenarios that the plenary/operators endorsed in that document. It was agreed to reword the text that referred to the tdoc and remove the referencce.
 		revised No S3‑161280  
    S3‑161280 Key issue Security aspects of dual connectivity Ericsson pCR Approval Yes
Yes
 		approved No   S3‑161085
    S3‑161104 pCR on New key issue on on-demand AS integrity protection in NextGen systems Qualcomm Incorporated pCR Approval Yes
YesOrange: User or control plane? Qualcomm: user plane traffic. Nokia: a similar problem happens in LTE, not only in 5G. I would like to add a note about this. Orange: the requirement is for the user plane, please specify that.
 		revised No S3‑161281  
    S3‑161281 pCR on New key issue on on-demand AS integrity protection in NextGen systems Qualcomm Incorporated pCR Approval Yes
Yes
 		approved No   S3‑161104
    S3‑160992 pCR to TR 33.899: Network public keys VODAFONE Group Plc pCR Approval Yes
YesEricsson suggested to add an editor's note. Orange: managing a global CA is a problem among the operators. Vodafone: this is an evaluation of the solution. Orange: it's for FFS if it's achievable.
 		revised No S3‑161282  
    S3‑161282 pCR to TR 33.899: Network public keys VODAFONE Group Plc pCR Approval Yes
Yes
 		approved No   S3‑160992
    S3‑161089 Verification of authenticity of the cell Samsung R&D Institute UK pCR Approval Yes
Yes
 		revised No S3‑161257  
    S3‑161257 Verification of authenticity of the cell Samsung pCR Approval Yes
Yes
 		approved No   S3‑161089
    S3‑160974 3.1 Definitions - Device INTERDIGITAL COMMUNICATIONS pCR Approval Yes
Yes
 		postponed No    
    S3‑161102 Adding requirements to the Key Issue # 5.1 and a new key issue on storage of device credentials Qualcomm Incorporated pCR Approval Yes
Yes
 		postponed No    
    S3‑160940 Key issue #5.1: Secure storage and processing of credentials and identities INTERDIGITAL COMMUNICATIONS pCR Approval Yes
Yes
 		postponed No    
    S3‑161047 Additional Security Requirements on credential storage ORANGE pCR Approval Yes
Yes
 		revised No S3‑161160  
    S3‑161160 Additional Security Requirements on credential storage ORANGE, Telecom Italia, Gemalto, Deutsche Telekom, Oberthur, Giesecke&Devrient pCR Approval Yes
Yes
 		postponed No   S3‑161047
    S3‑161054 Potential requirements for credential storage Ericsson pCR   Yes
Yes
 		postponed No    
    S3‑160951 Key issue #6.y: Authorization decoupled from Authentication INTERDIGITAL COMMUNICATIONS pCR Approval Yes
YesEricsson: scenarios in SA2 that support this decoupling? An editor's note was added for this. Nokia: First sentence in key issue details is not true: we have user subscriber profiles.
 		postponed No    
    S3‑161090 pCR to TR 33.899 v0.3.0 "Network Authorization" Nokia pCR   Yes
Yes
 		approved No    
    S3‑160956 Split of key issue #7.1 on subscriber identifier privacy Ericsson, Nokia, Telecom Italia discussion Discussion Yes
Yes
 		noted No    
    S3‑160957 Update of key issue #7.2 on refreshing of temporary subscriber identifier Ericsson, Nokia, Telecom Italia pCR Approval Yes
Yes
 		approved No    
    S3‑160958 New privacy key issue on concealing permanent or long-term subscriber identifier Ericsson, Nokia, Telecom Italia pCR Approval Yes
Yes
 		revised No S3‑161285  
    S3‑161285 New privacy key issue on concealing permanent or long-term subscriber identifier Ericsson, Nokia, Telecom Italia pCR Approval Yes
Yes
 		approved No   S3‑160958
    S3‑160959 New privacy key issue on concealing permanent or long-term device identifier Ericsson, Nokia, Telecom Italia pCR Approval Yes
Yes
 		approved No    
    S3‑160960 New privacy key issue on using effective temporary or short-term subscriber identifiers Ericsson, Nokia, Telecom Italia pCR Approval Yes
Yes
 		approved No    
    S3‑160961 New privacy key issue on transmitting permanent identifiers in secure interface Ericsson, Nokia, Telecom Italia pCR Approval Yes
Yes
 		approved No    
    S3‑160962 New privacy key issue on transmitting permanent subscriber identifiers only when needed Ericsson, Nokia, Telecom Italia pCR Approval Yes
Yes
 		approved No    
    S3‑160963 Deletion of key issue #7.1 on subscriber identifier privacy Ericsson, Nokia, Telecom Italia pCR Approval Yes
Yes
 		approved No    
    S3‑160976 New privacy key issue on temporary device identifier Nokia, Ericsson, Telecom Italia pCR   Yes
Yes
 		approved No    
    S3‑161071 New privacy key issue on protection of network slice identifier Nokia pCR   Yes
YesBT: we have removed the term MDD from other contributions. It was agreed to remove it. Ericsson: This is ongoing work in SA2. We should postpone it. Interdigital: privacy applies to humans. In NextGen we will have non human objects. A CCV camera doesn’t have any privacy. Huawei: the UE doesn’t have the notion of slice. Nokia: the threat is written from the attacker's point of view, not the UE.
 		revised No S3‑161287  
    S3‑161287 New privacy key issue on protection of network slice identifier Nokia pCR - Yes
Yes
 		approved No   S3‑161071
    S3‑160995 Enhancing the concealment of permanent or long-term subscriber identifier Ericsson,Telecom Italia pCR Approval Yes
Yes
 		revised No S3‑161288  
    S3‑161288 Enhancing the concealment of permanent or long-term subscriber identifier Ericsson,Telecom Italia pCR Approval Yes
YesAdding an editor's note as suggested by interdigital.
 		approved No   S3‑160995
    S3‑161103 pCR on a proposed solution for IMSI privacy Qualcomm Incorporated pCR Approval Yes
YesInterdigital: you can track the mobile by routing the labels. Same editor's note as the previous contribution. Orange: what happens when message 3 is lost? Qualcomm: an editor's note will be added to explain this.
 		revised No S3‑161289  
    S3‑161289 pCR on a proposed solution for IMSI privacy Qualcomm Incorporated pCR Approval No
Yes
 		approved No   S3‑161103
    S3‑160987 Network Slice: EN in 5.8 intro and assumptions Nokia pCR Approval Yes
YesDiscussed with 1126 since they overlap.
 		merged No S3‑161212  
    S3‑161212 Network Slice: EN in 5.8 intro and assumptions Nokia,Ericsson pCR Approval Yes
Yes
 		approved No   S3‑160987
    S3‑161129 Discussion on the trust model in Next Generation systems in relation to the network slicing security area Ericsson pCR Approval Yes
YesEricsson: we are not mandating any particular solutions, this is just informative.
 		revised No S3‑161214  
    S3‑161214 Discussion on the trust model in Next Generation systems in relation to the network slicing security area Ericsson pCR Approval Yes
Yes
 		approved No   S3‑161129
    S3‑161126 Resolution of the editor’s notes under the introductory text for security area #8 on network slicing Ericsson pCR Approval Yes
YesMerged with 987.
 		merged No S3‑161212  
    S3‑160950 Key Issue #8.1: Security isolation of network slices INTERDIGITAL COMMUNICATIONS pCR Approval Yes
YesVodafone: the breach can happen in the network, not only in the UE. Huawei didn’t see clear the data leakage issue. Vodafone: accessing two separate slices forces the UE to avoid the data going through to the different slices. Ericsson: how do you avoid that? BT agreed with this. LG: UE is not aware of network slices. It was agreed to add an editor's note, on the isolation of the UE from several network slices,if it's in scope. Vodafone: two interconnected UEs in different slices (e.g. wearable devices) would need to be addressed too.
 		merged No S3‑161213  
    S3‑160988 Network Slice: 5.8.3.1 key issue isolation of slices Nokia pCR Approval Yes
YesVodafone: we need a definition of tenant. Orange: multi tenants concept is a SA2 definition. It was agreed to have an editor's note on this and ask SA2 on the tenant,multi-tenant concepts. Ericsson: network slice type is not defined in SA2. The text in the key issue is one understanding, but it is not how it is going to work. It needs to be clarified how it is going to work in the end, there is no agreement in SA2 for this. Interdigital: also the issue of being an UE, NG UE or device what we are referring to here. Interdigital: add roaming scenarios in the potential requirements.
 		merged No S3‑161213  
    S3‑161114 pCR revise the details of key issue# 8.1 China Mobile Com. Corporation, China Unicom pCR Approval Yes
Yes
 		revised No S3‑161213  
    S3‑161213 pCR revise the details of key issue# 8.1 China Mobile Com. Corporation, China Unicom pCR Approval Yes
YesIt incorporates an editor's note of 1126.
 		approved No   S3‑161114
    S3‑161115 pCR : merge the requirements of key issue #8.1 China Mobile Com. Corporation, China Unicom, Huawei, Hisilicon pCR Approval Yes
YesVodafone: the 3GPP system includes more than a platform.
 		noted No    
    S3‑160989 Network Slice: EN in 5.8.3.2 Slice differentiation Nokia pCR Approval Yes
YesEricsson: the network selection procedure is still being discussed in SA2, still one interpretation. Vodafone: default network slice, controller node,..there are a lot of new definitions that need to be specified in the document. Adding this controller node means new threats and new requirements associated to this new definition. An editor's note was agreed for this, Ericsson: "it should be possible to define access security mechanisms" is not a real requirement, it's not how we define requirements in here. Orange and BT found the requirement vague. This had to be discussed offline.
 		revised No S3‑161215  
    S3‑161215 Network Slice: EN in 5.8.3.2 Slice differentiation Nokia pCR Approval Yes
Yes
 		approved No   S3‑160989
    S3‑161006 Detailed Requirements for Security Mechanism Differentiation for Network Slices Huawei, HiSilicon,Deutsche Telekom AG pCR Approval Yes
YesOrange disgagreed with the requirement. Only agreed with the sentence with "security policy…". Interdigital agreed with the requirement. This issue was related to the LS to SA1. Gemalto suggested an editor's note detailing that this requirement is dependent on the LS. This was agreed.
 		revised No S3‑161258  
    S3‑161258 Detailed Requirements for Security Mechanism Differentiation for Network Slices Huawei, HiSilicon,Deutsche Telekom AG pCR Approval Yes
Yes
 		approved No   S3‑161006
    S3‑161068 Key Issue #8.2 - Security mechanism differentiation for different network slices INTERDIGITAL COMMUNICATIONS pCR Approval Yes
YesNoted without presentation.
 		noted No    
    S3‑161008 The Authentication & Authorization Scenarios of UE Accessing into Network Slicing Huawei, HiSilicon, Deutsche Telekom AG pCR Approval Yes
YesEricsson: it should have been in key issue authentication. It was noted that this overlapped with several other contributions.
 		merged No S3‑161262  
    S3‑161262 The Authentication & Authorization Scenarios of UE Accessing into Network Slicing Huawei, HiSilicon, Deutsche Telekom AG,Nokia pCR Approval Yes
Yes
 		approved No   S3‑161008
    S3‑161020 FS_NSA - Update to Key Issue #8.3 – Security on UE’s access to slices Nokia pCR Approval Yes
YesEricsson: not generic enough, this is still under work in SA2. Huawei proposed to agree on the key issue details and add an editor's note to go on. This was agreed. Huawei considered that figures in 1008 were a better representation than the text in 1020. LS supported this.
 		merged No S3‑161262  
    S3‑161128 Clarification and resolution of the editor’s notes in key issue of UE service authorization under the security area for network slicing Ericsson LM pCR Approval Yes
Yes
 		revised No S3‑161261  
    S3‑161261 Clarification and resolution of the editor’s notes in key issue of UE service authorization under the security area for network slicing Ericsson LM pCR Approval No
Yes
 		approved No   S3‑161128
    S3‑160990 Network slice: EN in 5.8.3.7 interslice communication Nokia pCR Approval Yes
YesEricsson: there is no refrence point defined between slices. Orange agreed. It was agreed to create a document for all those definitions that need to be discussed (1263). Huawei and Orange: what is sensitivity level? It should be defined somewhere else. An editor's note was added.
 		revised No S3‑161264  
    S3‑161264 Network slice: EN in 5.8.3.7 interslice communication Nokia pCR Approval Yes
Yes
 		approved No   S3‑160990
    S3‑161140 Key hierarchy schems for network slicing ZTE Corporation pCR Approval Yes
YesIt was commented that this is related to SA2's issues that are still under discussion and not developed enough.
 		noted No   S3‑160965
    S3‑160953 pCR to TR 33.899: Proposal of solution for key issue of network slicing security NEC pCR Approval Yes
YesOrange: Roaming case and privacy aspects to be considered. Nokia: slice security server? How do you define this? How different is from the HSS? Interdigital: SSS has policies per slice. Orange: what are the interfaces to the HSS? We need to figure out these details. Huawei agreed.
 		revised No S3‑161265  
    S3‑161265 pCR to TR 33.899: Proposal of solution for key issue of network slicing security NEC pCR Approval Yes
Yes
 		approved No   S3‑160953
    S3‑160997 Solution for Network Slicing Security LG Electronics France pCR Approval Yes
Yes
 		revised No S3‑161266  
    S3‑161266 Solution for Network Slicing Security LG Electronics France pCR Approval Yes
Yes
 		approved No   S3‑160997
    S3‑161091 Interconnection Security Key Issue Nokia pCR   Yes
Yes
 		postponed No    
    S3‑161093 Interconnection Security - Circles of Trust Nokia pCR   Yes
Yes
 		postponed No    
    S3‑161107 pCR to TR 33.899 v0.3.0 "Security visibility and configurability" Nokia pCR   Yes
Yes
 		postponed No    
    S3‑160999 Update of NSA security area #11 Security visibility and configurability LG Electronics France pCR Approval Yes
Yes
 		postponed No    
    S3‑160941 Key Issue #11.3: User control of security INTERDIGITAL COMMUNICATIONS pCR Approval Yes
Yes
 		postponed No    
    S3‑160944 Key Issue #11.4: On demand security framework INTERDIGITAL COMMUNICATIONS pCR Approval Yes
Yes
 		postponed No    
    S3‑161000 Secure Mechanism to Achieve Remote Credential Provisioning for IoT devices Huawei, HiSilicon, Deutsche Telekom AG pCR Approval Yes
Yes
 		postponed No    
    S3‑161004 Remote Provisioning for IoT devices through a Companion UE Huawei, Hisilicon, China Mobile, Deutsche Telekom AG, KPN pCR Approval Yes
Yes
 		postponed No    
    S3‑160965 Key hierarchy schems for network slicing ZTE Corporation pCR Approval Yes
Yes
 		revised No S3‑161140  
    S3‑161009 The storage of security context Huawei; HiSilicon pCR Approval Yes
Yes
 		revised No S3‑161144  
    S3‑161014 Discussion on the necessity to reinforce the radio air interface for the next generation system THALES discussion Discussion Yes
Yes
 		revised No S3‑161019  
    S3‑161034 LS on "Next Generation" Security Requirements S2-164263 LS in   Yes
Yes
 		revised No S3‑161131  
    S3‑161150 pCR adding the definition of security anchor in the section 3.1 China Mobile Com. Corporation, Huawei, Hisilicon pCR   Yes
Yes
 		revised No S3‑161190 S3‑161117
    S3‑161190 pCR adding the definition of security anchor in the section 3.1 China Mobile Com. Corporation, Huawei, Hisilicon pCR - Yes
Yes
 		approved No   S3‑161150
    S3‑161183 Definitions for FS_NSA Nokia pCR Approval Yes
Yes
 		approved No    
    S3‑161187 Clause 4.1 details Ericsson pCR Approval Yes
Yes
 		approved No    
    S3‑161263 Editor's notes on definitions Nokia pCR Approval Yes
Yes
 		approved No    
    S3‑161290 New draft R 33.899 Ericsson draft TR Approval No
Yes
 		left for email approval No    
8.7 Study on Mission Critical Security Enhancements (FS_MC_Sec) S3‑161059 Update to study item for Study on Mission Critical Security Enhancements CESG SID revised Agreement Yes
Yes
 		agreed No   S3‑160727
    S3‑161066 MC_SEC 33.880 Study Template CESG draft TR Approval Yes
Yes
 		approved No    
    S3‑161058 Scope for Mission Critical security study CESG pCR Approval Yes
Yes
 		approved No    
    S3‑161057 Discussion on adding Rel-13 key issues to 33.880 CESG discussion Discussion Yes
Yes
 		noted No    
    S3‑161056 Adding Rel-13 Key Issues to 33.880 CESG pCR Agreement Yes
Yes
 		revised No S3‑161170  
    S3‑161170 Adding Rel-13 Key Issues to 33.880 CESG pCR Approval Yes
Yes
 		approved No   S3‑161056
    S3‑160969 Key Issue for inter-domain identity management operation Motorola Solutions Danmark A/S pCR Approval Yes
Yes
 		revised No S3‑161218  
    S3‑161218 Key Issue for inter-domain identity management operation Motorola Solutions Danmark A/S pCR Approval Yes
YesAirbus: add a requirement on revocation access token from old network to the visited network. Motorola: I agree with we can solve it with the existing mechanisms. It was agreed to add an editor's note.
 		approved No   S3‑160969
    S3‑160970 Identity management for inter-domain operation Motorola Solutions Danmark A/S pCR Approval Yes
Yes
 		revised No S3‑161219  
    S3‑161219 Identity management for inter-domain operation Motorola Solutions Danmark A/S pCR Approval Yes
Yes
 		approved No   S3‑160970
    S3‑161060 Mission Critical security study document template CESG draft TR Approval Yes
No
 		withdrawn Yes    
    S3‑161249 new draft TR 33.880 CESG draft TR Approval Yes
Yes
 		approved No    
8.8.1 Study on Subscriber Privacy Impact in 3GPP (SPI)                      
8.8.2 Security Assurance Specification for 3GPP network product classes (33.926) (SCAS)                      
8.8.3 Study on Battery Efficient Security for very low Throughput Machine Type Communication Devices S3‑160920 pCR to 33.863 - addition of recomendation section VODAFONE Group Plc pCR Approval Yes
Yes
 		revised No S3‑161255  
    S3‑161255 pCR to 33.863 - addition of recomendation section VODAFONE Group Plc pCR Approval Yes
Yes
 		approved No   S3‑160920
    S3‑160922 pCR to 33.863 - Editorial updates VODAFONE Group Plc pCR Approval Yes
Yes
 		approved No    
    S3‑160930 Removing Editor’s Note in 6.1.2.2 TNO pCR Approval Yes
Yes
 		revised No S3‑161250  
    S3‑161250 Removing Editor’s Note in 6.1.2.2 TNO pCR Approval Yes
Yes
 		approved No   S3‑160930
    S3‑160931 Removing Editor’s Note in 6.1.2.3 of TR 33.863 TNO pCR Approval Yes
Yes
 		approved No    
    S3‑160932 Removing Editor’s Note in 6.1.2.6 TNO pCR Approval Yes
Yes
 		approved No    
    S3‑160933 Removing Editor’s Note in 6.2.2.2 TNO pCR Approval Yes
Yes
 		approved No    
    S3‑161013 Removing Editor’s Note in 6.4.2.3 TNO pCR Approval Yes
No
 		withdrawn Yes    
    S3‑161015 Moved EnSE functionality to Enterprise Server TNO pCR Approval Yes
YesOrange: there is no definition for enterprise server.
 		noted No    
    S3‑161048 Introduction to Diet-ESP Ericsson discussion Endorsement Yes
YesUS Home Office: strongly recommended not to use this protocol. This is not an official IETF document, and it was rejected due to being insecure. The Chairman clarified that SA3 is endorsing the request part, the rest is for information. Nothing will be added to the TR.
 		endorsed No    
    S3‑161063 pCR to TR 33.863, v1.1.1: Solution #10 (extends sol. 2): "AKA-based session key generation for application protocols" Nokia pCR   Yes
YesVodafone: update the solution evaluation to say which issues are solved. Edit the conclusions clause. BT: don't duplicate work in the groups, this is ongoing work in OneM2M. Colaboration with them could be useful. Vodafone: this is battery efficiency, very specific. BT: We need to coordinate with those who define the applications (OneM2M). Juniper: this is an end-to-end complete solution.
 		revised No S3‑161252  
    S3‑161252 pCR to TR 33.863, v1.1.1: Solution #10 (extends sol. 2): "AKA-based session key generation for application protocols" Nokia pCR - Yes
Yes
 		approved No   S3‑161063
    S3‑161032 A Method for IoT Service Layer Security Bootstrapping Huawei, Hisilicon pCR Approval Yes
Yes
 		revised No S3‑161141  
    S3‑161033 Service Layer Security Bootstrapping Mechanism for IoT Devices Huawei, HiSilicon, Deutsche Telekom AG pCR Approval Yes
Yes
 		revised No S3‑161142  
    S3‑161141 A Method for IoT Service Layer Security Bootstrapping Huawei, Hisilicon pCR Approval Yes
YesVodafone: update the conclusions clause. Orange: this solution will not work with 2G. A note was added. Nokia: GUTI doesn’t have one to one correspondence with Kasme. Gemalto: Why is this better than GBA? Orange: it is being considered by GSMA IoT group. Ericsson: more efficient because of the use of HTTP. Ericsson agreed.
 		revised No S3‑161253 S3‑161032
    S3‑161253 A Method for IoT Service Layer Security Bootstrapping Huawei, Hisilicon pCR Approval No
Yes
 		approved No   S3‑161141
    S3‑161142 Service Layer Security Bootstrapping Mechanism for IoT Devices Huawei, HiSilicon, Deutsche Telekom AG pCR Approval Yes
YesVodafone: it needs to be clear why it is battery efficient.
 		revised No S3‑161254 S3‑161033
    S3‑161254 Service Layer Security Bootstrapping Mechanism for IoT Devices Huawei, HiSilicon, Deutsche Telekom AG pCR Approval No
Yes
 		approved No   S3‑161142
    S3‑160923 pCR to 33.863 - Addition of annex detailing suggested normaitive changes VODAFONE Group Plc pCR Approval Yes
YesNokia wanted to evaluate the solutions from this meeting. Orange: there is no contribution from Nokia to challenge solution 8 and 9. Juniper: no time to re-evaluate all the solutions that we have right now. Nokia: the definition of the protocol itself should not be mandated here. We would agree to have the option of having other new solutions. Vodafone: Nokia's concerns are normative work concerns. This is a TR. The detail will go into normative work. Nokia: let’s put solutions in the TR and with contributions we decide which ones will go to the TS. Orange: the TR will give recommendations. Solution 8 and 9 are the way forward. We cannot have a conclusion saying that we can have any solution. Nokia: we need additional work to be done in the TS to make it modular. Vodafone commented that Nokia's rejection to this normative work is clearly delaying the work on purpose.
 		revised No S3‑161284  
    S3‑161284 pCR to 33.863 - Addition of annex detailing suggested normaitive changes VODAFONE Group Plc pCR Approval Yes
Yes
 		approved No   S3‑160923
    S3‑160921 WID for normaitive work of BEST VODAFONE Group Plc WID new Agreement Yes
YesHuawei rejected having point a. Vodafone would not agree on a WID without point a. The general agreement was to keep a).
 		revised No S3‑161256  
    S3‑161256 WID for normaitive work of BEST VODAFONE Group Plc WID new Agreement Yes
Yes
 		agreed No   S3‑160921
    S3‑161251 new draft TR 33.863 Vodafone draft TR discussion No
Yes
 		approved No    
    S3‑161286 Cover sheet 33.863 Vodafone TS or TR cover Approval Yes
Yes
 		left for email approval No    
8.8.4 Other study items                      
9 Review and Update of Work Plan S3‑160902 SA3 Work Plan MCC Work Plan   Yes
Yes
 		noted No    
    S3‑160905 Work Plan input from Rapporteurs MCC other   Yes
Yes
 		revised No S3‑161283  
    S3‑161283 Work Plan input from Rapporteurs MCC other - Yes
Yes
 		noted No   S3‑160905
10 Future Meeting Dates and Venues S3‑160904 SA3 meeting calendar MCC other   Yes
Yes
 		revised No S3‑161291  
    S3‑161291 SA3 meeting calendar MCC other - Yes
No
 		available No   S3‑160904
11 Any Other Business