Tdoc List

2017-12-05 01:21

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‑173000 Agenda WG Chairman report   Yes
Yes
approved No    
3 IPR Reminder                      
4 Meeting Reports                      
4.1 Approval of the report from previous SA3 meeting(s) S3‑173001 Report from SA3#88 MCC report   Yes
Yes
approved No    
    S3‑173002 Report from SA3#88Bis Ad-Hoc MCC report   Yes
Yes
approved No    
    S3‑173467 Minutes of eMeeting on LTE re-direction SA3 vice-chairman (Qualcomm) report discussion Yes
Yes
noted No    
4.2 Report from SA Plenary S3‑173004 Report from last SA meeting WG Chairman report   Yes
Yes
noted No    
4.3 Report from SA3-LI                      
5 Items for early consideration S3‑173053 Draft LS on inclusion of the SEPP into the 5G architecture (to: SA2; cc: -; contact: Deutsche Telekom) Deutsche Telekom AG LS out Approval Yes
YesMCC: source is already SA3 Vodafone: mandatory for 5G? would be happy to remove "mandatory" Ericsson: operators cannot have any other connection except this proxy? if they have direct links the proxy would not be needed Nokia: concerned about "other 3rd parties" Deutsche Telekom: worried that other operator could send commands to the network; mandatory for "service based architecture" would be ok for us Orange: SA3 should define it is probably a better expression than mandatory conclusion: offline discussion, intention is to send it early this week to SA2 after offline discussion: Deutsche Telekom: we will drop the mandatory, Huawei wants to cc GSMA DES group Vodafone: what's the intention to cc GSMA? Deutsche Telekom: because they define the attributes Vodafone: suggests to not cc GSMA
revised No S3‑173413  
    S3‑173413 Draft LS on inclusion of the SEPP into the 5G architecture (to: SA2; cc: -; contact: Deutsche Telekom) Deutsche Telekom AG LS out Approval Yes
Yes
revised No S3‑173431 S3‑173053
    S3‑173431 Draft LS on inclusion of the SEPP into the 5G architecture (to: SA2; cc: -; contact: Deutsche Telekom) Deutsche Telekom AG LS out Approval Yes
YesOrange: no need to include the architecture figure, why can security function not be defined in SA3? Why do we need to ask SA2? NTT DOCOMO: to indicate that there is something that is breaking their bus; figure was there so that they understand where it should go; Orange: then better remove e.g. text and refer to figure Interdigital: we need bubbles for SEPP Ericsson: no bubbles needed, it is not a service based interface
revised No S3‑173437 S3‑173413
    S3‑173437 LS on inclusion of the Security Edge Protection Proxy into the 5G architecture (to: SA2; cc: -; contact: Deutsche Telekom) SA3 LS out Approval Yes
YesSA3 chair: to be sent out as soon as available LS was sent out on Tue noon of SA3 #89
approved No   S3‑173431
6 Reports and Liaisons from other Groups                      
6.1 3GPP Working Groups S3‑173012 Reply LS on LTE call redirection to GERAN C1-173752 LS in   Yes
YesNokia: no action for SA3 conclusion: no LS answer
not treated No    
    S3‑173497 Reply LS to C1-173752 = S3-173012 on LTE call redirection to GERAN (R2-1714121; to: CT1; cc: SA3, RAN3; contact: Ericsson) RAN2 LS in   Yes
YesEricsson: it seems RAN2 has misunderstood the mechanism; suggests to postpone an answer and come back at SA3 #90 on this conclusion: LS answer is postponed to next SA3 meeting
postponed No    
    S3‑173016 LS on Certification/License and Identification of Aerial Vehicles R2-1709973 LS in   Yes
YesNTT DOCOMO: no inputs on this, will discuss offline conclusion: no LS answer (so far)
noted No    
    S3‑173017 Reply LS on Certification/License and Identification of Aerial Vehicles S2-178175 LS in   Yes
Yesconclusion: no LS answer
noted No    
    S3‑173451 Reply LS to S2-178175 = S3-173017 on Certification/License and Identification of Aerial Vehicles (to: SA2, RAN2; cc: RAN3, SA3, GSMA IoT Drone Interest Group; contact: Qualcomm) SA1 LS in   Yes
Yesconclusion: no LS answer
noted No    
    S3‑173020 LS on provisioning of positioning assistance data via LPPa for broadcast R2-1712030 LS in   Yes
YesEricsson: no action for SA3 conclusion: no LS answer
noted No    
    S3‑173027 LS on the support of Unicast and Groupcast transmission over PC5 for eV2X S2-178181 LS in   Yes
Yesconclusion: no LS answer
noted No    
    S3‑173518 LS on Extension of USAT Application Pairing mechanism (C6-170737; to: SA3; cc: -; contact: Gemalto) CT6 LS in   Yes
YesNote: Attachment was missing in LS C6-170737. Orange: let's postpone this discussion to the next meeting conclusion: LS answer is postponed
postponed No    
6.2 IETF                      
6.3 ETSI SAGE                      
6.4 GSMA                      
6.5 3GPP2                      
6.6 OMA                      
6.7 TCG S3‑173036 TCG progress report InterDigital, Inc. report Discussion Yes
Yes1. TCG – Highlights • New/modified work items o TCG Industrial SG of Embedded Systems WG – chartered February 2017 o Device ID Composition Engine Arch (DICE) – chartered October 2016 • Publication of new or revised deliverables o *** TCG Guidance for Securing Network Equipment – to publish December 2017 *** o *** TCG TNC Architecture 2.0 – published November 2017 *** o *** TCG TPM 2.0 Library v1.46 – public review November 2017 *** o TCG Algorithm Registry r1.27 – public review November 2017 o *** TCG Implicit ID Based Device Attestation – public review November 2017 *** o TCG Device Identifier Composition Engine – member review November 2017 o TCG Errata v1.3 for TPM 2.0 v1.38 – published September 2017 o TCG Mobile Implementation Guidance – published September 2017 2. Meetings TCG Members Meeting in Portland, OR – 26 February - 1 March 2018 TCG Members Meeting in San Diego, CA – 18-22 June 2018 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                      
7 Work Areas                      
7.1 EPC enhancements to support 5G New Radio via Dual Connectivity (EDCE5) (Rel-15) S3‑173028 Reply LS on algorithm selection in E-UTRA-NR Dual Connectivity S2-178182 LS in   Yes
Yesconclusion: no LS answer
noted No    
    S3‑173469 Reply LS to S2-178182 = S3-173028 on algorithm selection in E-UTRA-NR Dual Connectivity (R2-1714124; to: SA2, CT1, SA3; cc: CT4, RAN3; contact: Intel) RAN2 LS in   Yes
YesQualcomm: we sort of responded also with our LS on Wed morning (3444) conclusion: no LS answer
noted No    
    S3‑173408 Reply LS on algorithm selection in E-UTRA-NR Dual Connectivity C4-175349 LS in   Yes
YesHuawei: if no transfer, then there is no impact Nokia: does not agree SA3 chair: it seems the LS can be interpreted in different ways Huawei: thinks LS is clear conclusion: no LS answer
noted No    
    S3‑173113 CR to resolve EDCE5 ENs (revision of S3-172575) Nokia CR Agreement Yes
YesOrange: is this option1 for the first question of the technical votings? SA3 chair: no
agreed No   S3‑172575
    S3‑173135 Solution for UP algorithm negotiation and activation for ENDC Huawei, Hisilicon, CR Agreement Yes
YesMCC: no CR number on CR cover; revision marks are not allowed on CR covers; curly quotes should not be used (use straight quotes instead) Huawei: would like to come back to this CR later
rejected No S3‑173414  
    S3‑173360 Corrections to deletion of SCG Keys Samsung CR Agreement Yes
YesEricsson: in conflict with Qualcomm Tdoc Qualcomm: put this one first to not lose changes in the controversial discussions coming later
revised No S3‑173480  
    S3‑173480 Corrections to deletion of SCG Keys Samsung CR Agreement Yes
Yes
agreed No   S3‑173360
    S3‑173394 Emergency call handling in EDCE5 QUALCOMM CDMA Technologies discussion   Yes
YesHuawei: SA2 should make a decision how to establish the bearer and then SA3 can decide what we do SA3 chair: we just checked whether we can be proactive Huawei: we could send LS to SA2 Ericsson: include RAN2 as well Qualcomm: we could include SA1 as well; SA3 chair: so we can prepare a draft LS to SA1, SA2, RAN2 and come back on it
noted No    
    S3‑173414 LS on Emergency call support for EDCE5 (to: SA1, SA2, RAN2; cc: -; contact: Qualcomm) SA3 LS out Approval Yes
Yes
approved No    
    S3‑173042 Completing the specification of the algorithms to use between UE and SgNB in EDCE5 Qualcomm Incorporated CR Agreement Yes
Yes
rejected No   S3‑172367
    S3‑173162 Align 5G algorithm Identifiers with 33.501 Huawei; Hisilicon CR Agreement Yes
YesVodafone: UE should never integrity protect RRC? This is confusing Nokia: why shall UE implement NIA0 for integrity protection of RRC signalling, unclear what the benefit is
rejected No    
    S3‑173288 Aligning the algorithm names between EDCE5 and 5G Qualcomm Incorporated CR Agreement Yes
YesQualcomm: will overlap with previous CRs Ericsson: there are some typos in E.3.10.1
revised No S3‑173481  
    S3‑173481 Aligning the algorithm names between EDCE5 and 5G Qualcomm Incorporated CR Agreement No
Yes
agreed No   S3‑173288
    S3‑173290 Aligning the specification of the key derivation function for key to use in security algorithms between UE and SgNB in EDCE5 with the 5G specification Qualcomm Incorporated CR Agreement Yes
YesMCC: wrong meeting number #88bis on CR cover SA3 chair: we will do a show of hands about the technical voting questions later on Monday SA3 chair: CR is an example for the removal Huawei: removing UP integrity will create 2 versions of 5G UE? Qualcomm: there is one that supports 5G core and one that does not SA3 chair: show of hands: one company, one hand, multiple NEC companies have just one hand/vote Questions: 1. removal of UP integrity algorithms as in 3042, 3290 supporting: Qualcomm, Ericsson, Nokia., Samsung, Intel => 5 companies 2. keeping UP integrity algorithms as in 3162 supporting: Huawei, Interdigital => 2 companies So majority for removal but we will leave time for further offline discussion Vodafone: we need to see whether MME needs changing SA3 chair: we will come to these questions afterwards
revised No S3‑173443 S3‑172576
    S3‑173443 Aligning the specification of the key derivation function for key to use in security algorithms between UE and SgNB in EDCE5 with the 5G specification Qualcomm Incorporated CR Agreement Yes
Yesas outcome of S3-173438: it is planned to add a note regarding UP integrity as requested by Huawei (details will be discussed offline)
agreed No   S3‑173290
    S3‑173043 Using AS layer signalling to negotiate the algorithm used between the UE and SgNB Qualcomm Incorporated CR Agreement Yes
YesSA3 chair: so they are the same as last meeting Vodafone: but we will remove emergency case text? Qualcomm: yes, we were just asked to submit the CR as it was
rejected No   S3‑172373
    S3‑173044 Using NAS layer signalling to negotiate the algorithm used between the UE and SgNB Qualcomm Incorporated CR Agreement No
Yes
withdrawn Yes   S3‑172374
    S3‑173045 Using NAS layer signalling to negotiate the algorithm used between the UE and SgNB Qualcomm Incorporated CR Agreement Yes
YesSA3 chair: so they are the same as last meeting Vodafone: but we will remove emergency case text? Qualcomm: yes, we were just asked to submit the CR as it was
rejected No   S3‑172374
    S3‑173103 UE NR capability negotiation for EDCE5 Discussion paper Nokia discussion Agreement Yes
YesProposal 1: For EDCE5 feature stay with LTE algorithm definitions this meets objectives of the WID, not necessary to introduce new algorithm definitions. Proposal 2: Adding octet9 and octet10 as NR algorithm in UE network capability will not impact a legacy MME, since it is supposed to treat the message in its entirety, but will not interpret the new octets. New added octets will not get dropped during a handover to another legacy MME. Huawei: prop. 2 will not impact legacy MME but we do not agree with proposal 1 and proposal 2 Ericsson: we have similar proposals as Nokia; current system does not work with protected with hash Vodafone: supports Nokia's discussion document Qualcomm: proposal 1 is ok but proposal 2 will need further clarification, as it is not enough as it is; in REL-15 we should specify a complete solution (so that we do not need add signalling later) Huawei: sees 3 solutions to address the bidding down mentioned by Qualcomm Nokia: do we want to change MME for EDCE5 or not is the question
noted No    
    S3‑173133 EDCE5: UE NR Security Capabilities Bidding-down Huawei, Hisilicon, discussion Discussion Yes
Yesproposal 1: As long as the UE is connected to LTE and all UE security capabilities including LTE security capabilities have been replayed correctly and successfully in the NAS SMC, the UE shall not consider the absence of the UE NR security capabilities in the NAS SMC as a security vulnerability. proposal 2: If the UE NR security capability is sent in a new IE over NAS, the legacy MME will drop the UE NR security capabilities. This will eliminate any potential bidding down attack. In addition, it eliminates changes to S10 interface which is required to inform target MME whether the UE NR security capabilities have been protected against bidding down or not. proposal 3: MeNB can support EDCE5 functionality while connected to a legacy MME. proposal 4: If during the Attach procedure, the MeNB receives the UE ENDC support capability in the UE LTE Radio capabilities, the UE ENDC authorization in the Restrictions list and does not receive the UE NR security capability from the MME, the MeNB shall set an indication “UE NR Capbilities mismatch” in the RRC Connection Reconfiguration message sent to the UE. Vodafone: will we need to change MME Huawei: no Nokia: how is bidding down prevented with the additional information element? Qualcomm: receiving MME will not be informed, with IE it will know whether bidding down happened NTT DOCOMO: are we trying to solve somethng that could be solved also by configuration? Qualcomm: you would have to analyze every case
noted No    
    S3‑173132 EDCE5 Support Legacy MME: UE NR Sec Cap delivery and MME Interworking Huawei, Hisilicon, discussion Discussion Yes
Yesproposal: UE NR security capabilities shall be added in a new IE over NAS. It is more advantageous and serves the security solution better. SA3 shall communicate the recommendation to CT1 & CT4.
noted No    
    S3‑173131 ENDC5 support legacy MME: Delivery UE NR sec. cap. to MeNB in X2 & S1 HO Huawei, Hisilicon, discussion Discussion Yes
YesProposed Solution: UE sends its NR security capabilities during X2 & S1 Handover
noted No    
    S3‑173134 Supporting EDCE5 with Legacy MME Huawei, Hisilicon, CR Agreement Yes
YesMCC: adding Editor's notes in a spec under CR control Huawei: S3-173134 is implementation of S3-173131 conclusion: covered already by S3-173445
rejected No    
    S3‑173265 Discussion document on Algorithm selection in EDCE5 VODAFONE Group Plc discussion Approval Yes
Yes
revised No S3‑173393  
    S3‑173393 Discussion document on Algorithm selection in EDCE5 (with attachments) VODAFONE Group Plc discussion Approval Yes
YesVodafone: is a copy of an email that was provided via the reflector
noted No   S3‑173265
    S3‑173268 CR to 33.401 - Using existing NAS, S1-AP and X2-AP signalling to negotiate the algorithm used by NR-PDCP for EPC controlled dual connectivity between E-UTRAN and NR VODAFONE Group Plc CR Agreement Yes
YesMCC: no CR number on CR cover; CR clashing with S3-173340; wrong reference [42] for TS 36.413; missing reference text for clause 2 for TS 37.340, TS 38.323, TS 29.274, TS 36.423 conclusion: covered already by S3-173445 Vodafone: is similar to Nokia Discussion paper and also overlapping with Ericsson views so with some merging activities we could progress on this
rejected No    
    S3‑173333 Discussion on the NR algorithm bidding-down attack with legacy MME Ericsson discussion   Yes
YesAttack: Observation 1: The bidding-down attack applies only to the NR algorithms that are used in the access stratum. Observation 2: The attack does not apply to NAS security. Observation 3: The attack is successful only with initial, unprotected Attach. Mobility: Observation 4: Even if the falsified NR algorithms were forwarded by the source legacy MME to the target Rel-15 MME, the UE will send the NR algorithms again in integrity protected TAU. Interworking: Observation 5: All earlier generations are forwarding UE network capabilities to the newer generation networks without bidding-down protection.
noted No    
    S3‑173336 Solution using stand-alone TAU Ericsson discussion Approval Yes
Yesproposal: SA3 chooses the TAU based solution to prevent the bidding-down attack, and to the use of legacy MME with EDCE5 Qualcomm: we have problems with the TAU proposal Nokia: TAU will affect legacy MME and legagcy UE? Ericsson: legacy UEs not impacted Huawei: legacy MME will not understand new information, passing it on to others without any security is not a good solution Qualcomm: stage 2 and stage 3 are not aligned from REL-8 onwards
noted No    
    S3‑173338 Solution using local mapping of NR algorithms at NR RRC layer Ericsson discussion Approval Yes
Yesproposal: - NR RRC layer in eNB/gNB is allowed to do local mapping of NR algorithms if the UE is known to support EDCE5 but if the NR algorithms are not available from S1/Xn/X2 interfaces. - There are two ways to do the mapping, and we propose that SA3 chooses option 1 below: 1. The mapping is based on the LTE algorithms that the UE supports. In this way, the support of ZUC could be assumed if the UE supports ZUC. 2. The mapping can be based on the standard (33.501) that mandates the UE to implement certain NR algorithms. In this case, ZUC could not be assumed.
noted No    
    S3‑173340 Using NAS layer signalling to negotiate the algorithm used between the UE and SgNB Ericsson CR Agreement Yes
YesMCC: revision marks and comments not allowed on CR covers; CR clashing with S3-173268; wrong rev - on CR cover instead of rev 3 conclusion: covered already by S3-173445
rejected No   S3‑172374
    S3‑173291 Handling security algorithms in LTE and NR Qualcomm Incorporated discussion Endorsement Yes
Yes
noted No    
    S3‑173292 Making the NAS layer bidding down in EPC automatically cover new security features Qualcomm Incorporated CR Agreement Yes
Yesconclusion: covered already by S3-173445
rejected No    
    S3‑173194 Allowing UE to accept replayed security capbilities on LTE without UE NR security capabilities Huawei; Hisilicon, China Mobile CR Agreement Yes
YesMCC: revision marks are not allowed on CR covers; 2 times Note 4; WI code EDCE5 does not fit to AI 5GS_Ph1-SEC Vodafone: some show of hands on remaining questions would be good to know who are the contacts Huawei: we could consider 3 questions: EDCE5 to work with legacy MME?, UE NR security in new IE?, mapping LTE algorithms to NR? Qualcomm: suggests instead of a show of hands we could have a discussion over Monday lunch time SA3 chair: seems the questions are: - solution would work with legacy MME? - solution should be future proof? - having a new IE? Orange: unclear what future proof means; suggests to check regarding legacy MME only and we can then see how to continue Vodafone: support for the existing 3 algorithms or future algorithms, legacy needs to support existing 3 and we should be able to extend in the future NTT DOCOMO: suggests to have lunch break discussion about the questions, there seem to be different views regarding potential upgrades in the future SA3 chair: see 4 discussion topics: legacy MME, future proof, now IE or not, having algorithm mapping or not Vodafone: it seems to be an implementation discussion that we need conclusion: covered already by S3-173445
rejected No    
    S3‑173419 Report of offline discussion EDCE5 security NTT DOCOMO report discussion Yes
Yesconclusion: further offline discussion will happen on Monday afternoon/evening to converge on one CR and to avoid technical votings on Tue; we will see the CR proposal on Tue morning and then decide on whether the technical voting on Tue 1pm is needed
noted No    
    S3‑173438 Report of Tue evening offline discussion EDCE5 security Qualcomm report discussion Yes
YesNTT DOCOMO: with this Tdoc no technical votes will be needed; still some open issues Vodafone: CT1 will need to be informed about the outcome Vodafone: CR takes care of all 3 questions Huawei: the UP integrity aspect was not yet covered SA3 chair: we had S3-173290 which was showing if we remove UP integrity Huawei: sees that as a UE issue so would like to hear views from other SA3 chair: we had a show of hands where we ended up with 5 to 2 for removing Orange: motivation for removing UP integrity algorithm? Qualcomm: why supporting a normative algorithm that is never used? NTT DOCOMO: we do not have to worry about HO scenarios where this could be relevant? show of hands: - removal of UP integrity algorithms: Qualcomm, Ericsson, Nokia, NEC, Samsung, Vodafone, Intel - keeping of UP integrity algorithms: Huawei SA3 chair: UP integrity debate will continue in Tue morning coffee break after offline discussion: Huawei: could accept to remove UP integrity but would like to add note in a revision of S3-173290 conclusions: - based on S3-173438 Qualcomm will work on a CR in S3-173445 - note will be added in next revision of S3-173290 in S3-173443, Huawei will make a proposal - Vodafone will draft an LSout in S3-173444 to inform other WGs (which will in the end attach CR S3-173445) - no technical votes will be needed
noted No    
    S3‑173444 LS on EDCE5 algorithm indication (to: CT1, CT4, RAN2, RAN3; cc: SA2; contact: Vodafone) SA3 LS out Approval Yes
Yeswill have S3-173445 attached LS was sent out on Wed morning of SA3 #89
approved No    
    S3‑173445 Handling the algorithms for use between a UE and SgNB for EN-DC Qualcomm, NEC, Vodafone CR Agreement Yes
Yes
agreed No    
7.2 Security aspects of 5G System - Phase 1 (5GS_Ph1-SEC) (Rel-15) S3‑173523 TS 33.501 v0.5.0 collecting agreements of SA3 #89 NTT DOCOMO draft TS Agreement No
Yessending out before Thu 7.12.17 eob CET comments before Mon 11.12.17 eob CET agreed version sent out before Wed 13.12.17 eob CET
for email discussion No S3‑173524  
    S3‑173524 TS 33.501 v0.6.0 doing a restructuring NTT DOCOMO draft TS Agreement No
Yessending out before Tue 19.12.17 eob CET comments before Thu 21.12.17 eob CET agreed version sent out before Fri 22.12.17 eob CET Ericsson: some sections will have to be merged NTT DOCOMO: put the text in the same sections and if the text needs to be modified this can be done in pCRs next time SA3 chair: all pCRs to next SA3 meeting have to be based on this new TS version v0.6.0
for email discussion No   S3‑173523
    S3‑173530 Draft agenda related to 5GS_Ph1-SEC for SA3 #90 NTT DOCOMO discussion discussion No
Yesinputs should be sent by Monday 4.12. rapporteur will provide draft version on Tue 5.12. via the SA3 reflector On Thu 7.12. rapporteur will send out the endorsed S3-173530 via the SA3 email reflector
for email discussion No    
7.2.1 Key hierarchy S3‑173144 Update key hierarchy by adding Kseaf and Kausf Huawei & Hisilicon pCR Approval Yes
Yesthere are related Tdocs: Huawei: 3145, 3146, 3147, 3149 Qualcomm: 3294 Ericsson: 3343 Nokia: has a similar proposal in 3129 but fine to go with Ericsson proposal in S3-173343 SA3 chair: so let's see 3149, 3294 and 3343 as well conclusion: S3-173144 is merged in S3-173514
merged No    
    S3‑173332 Security for multiple NAS connections NEC EUROPE LTD pCR Approval Yes
YesNEC: dependent on other topic SA3 chair: so we will not treat it now
not treated No    
7.2.2 Key derivation S3‑173127 Preventing bidding down between 5G releases - discussion - was 2401 Nokia, Qualcomm Incorporated discussion Decision Yes
YesMCC: Tdoc type corrected from pCR to discussion
noted No    
    S3‑173345 Using NAS SMC to protect the FeatureSet in phase 2 Ericsson discussion Approval Yes
Yesproposal: SA3 should conclude that the potential bidding down problem between 5G phases can be solved by NAS SMC. There is no need to solve the problem in phase 1. We would also like to remind that there is no agreement in 3GPP that there will be standalone SEAF in phase 2 Interdigital: has problems to understand the proposal, picture in S3-173345 is insecure Orange: supports Ericsson NTT DOCOMO: supports the Nokia proposal (S3-173127) as it is straightforward Ericsson: no need to negotiate releases over air interface NTT DOCOMO: limits operator deployment on AMF and will be complicated Huawei: when it comes in phase 2 we will address it SA3 chair: some people say "do it in phase 1" while others say "do it in phase 2" Qualcomm: you may get 2 sets of AMFs Orange: we are reopening agreements we had for phase 1 conclusion: no consensus
noted No    
    S3‑173128 Preventing bidding down between 5G releases - was 2403 Nokia, Qualcomm Incorporated pCR Approval Yes
Yes
postponed No    
    S3‑173327 Updates to clause 6.2.2 Key Derivation and distribution scheme and Annex A.7 NEC EUROPE LTD pCR Approval Yes
Yes
not treated No    
    S3‑173129 Computation of Key in AUSF for 5G AKA - was 2416 Nokia pCR Approval Yes
Yesconclusion: merged in S3-173514
merged No    
    S3‑173149 Discussion on Kausf in 5G AKA and EAP-AKA' Huawei & Hisilicon discussion   Yes
YesMCC: type corrected from pCR to discussion
noted No    
    S3‑173145 Kausf in EAP-AKA‘ Huawei & Hisilicon pCR Approval Yes
Yesconclusion: merged in S3-173514
merged No    
    S3‑173146 key derivation for Kseaf in Annex Huawei & Hisilicon pCR Approval Yes
Yesconclusion: merged in S3-173514
merged No    
    S3‑173147 key derivation for Kseaf for 5G AKA Huawei & Hisilicon pCR Approval Yes
Yesconclusion: merged in S3-173514
merged No    
    S3‑173148 key derivation (Kgnb, NH, Kn3iwf) Huawei & Hisilicon pCR Approval Yes
YesEricsson: error on 2nd change and can be merged with Ericsson document Interdigital: first and fourth change same? Qualcomm: editor's note to align KgNB and KN3IWF derivation conclusion: ... => Kamf, editor's note will be added
revised No S3‑173517  
    S3‑173517 key derivation (Kgnb, NH, Kn3iwf) Huawei & Hisilicon, Ericsson pCR Approval Yes
Yesincludes also aspects of S3-173082 and S3-173083
approved No   S3‑173148
    S3‑173082 Annex A.X (* derivation function) Ericsson pCR Approval Yes
Yesconclusion: merged into S3-173517
merged No    
    S3‑173083 Annex A.X (KgNB* derivation function) Ericsson pCR Approval Yes
Yesconclusion: merged into S3-173517
merged No    
    S3‑173289 Providing details of the key derivation for the security algorithm keys Qualcomm Incorporated pCR Approval Yes
Yes
approved No   S3‑172370
7.2.3 Mobility S3‑173143 Intra-gNB retaining AS keys exception Huawei, Hisilicon pCR Approval No
Yes
revised No S3‑173212  
    S3‑173212 Intra-gNB retaining AS keys exception Huawei, Hisilicon,China Mobile pCR Approval Yes
Yes
not treated No   S3‑173143
    S3‑173326 Reordering clause 6.5 NEC EUROPE LTD pCR Approval Yes
Yes
not treated No    
    S3‑173096 Clause 8.3.1.3.3 (horizontal key derivation of K_AMF at N2-Handover) Ericsson pCR Approval Yes
Yes
not treated No    
    S3‑173238 Kamf Derivation when AMF set changes Huawei, Hisilicon pCR Approval Yes
Yes
not treated No    
    S3‑173386 Idle mode mobility with horizontal key derivation Ericsson pCR Approval Yes
Yes
not treated No    
    S3‑173137 Flexible retaining AS keys solution Huawei, Hisilicon, China Mobile pCR Approval Yes
Yes
rejected No    
    S3‑173150 Modifications of Clause 8.3.1.1 Huawei & Hisilicon pCR Approval Yes
Yes
not treated No    
7.2.4 AS security S3‑173084 Clause 8 (open issues in AS security) Ericsson discussion Discussion Yes
Yes
noted No    
    S3‑173366 Discussion on user plane integrity protection for DRB Samsung pCR Approval Yes
YesProposal 1: AS SMC procedure is used to select the UP integrity algorithm. Proposal 2: 5QI value indicates whether to enable the UP integrity protection for a particular DRB or not. Using the 5QI value, the UE and gNB determines whether to apply UP integrity protection and establish the DRB accordingly. Ericsson: supports proposal 1, proposal 2 is up to RAN people Qualcomm: same view as Ericsson Huawei: does not support proposal 1 & 2 Nokia: supports proposal 2 Huawei: Let's keep this Tdoc open and see other Tdocs first conclusion: merged into S3-173516
merged No    
    S3‑173087 Clause 8 and Annex D.1 (user plane security – null-integrity and non-activation of integrity protection) Ericsson pCR Approval Yes
YesHuawei: does not agree with editor's note conclusion: further offline discussion about editor's note needed conclusion: merged into S3-173516
merged No    
    S3‑173088 Clause 8 (user plane security - integrity protection) Ericsson pCR Approval Yes
Yesconclusion: merged into S3-173516
merged No    
    S3‑173402 Nokia comments on S3-173088 Nokia discussion Endorsement Yes
Yes
noted No    
    S3‑173307 Use of integrity protection of user data in 5GS Qualcomm Incorporated pCR Approval Yes
YesEricsson: is reopening a discussion
rejected No    
    S3‑173201 Support No integrity for UP Huawei; Hisilicon pCR Approval Yes
YesEricsson: does not agree with last change Huawei: same view, change not needed NTT DOCOMO: we do not have NIA0 in LTE, they can easily compress it Ericsson: we have NIA0 SA3 chair: we could just have an editor's note and clarify this
revised No S3‑173493  
    S3‑173493 Support No integrity for UP Huawei; Hisilicon pCR Approval Yes
Yes
approved No   S3‑173201
    S3‑173494 Draft LS on over the air overhead of the use of integrity protection algorithm Huawei LS out Approval No
YesEricsson: we do not need to send this LS acc. to latest RAN news
withdrawn Yes    
    S3‑173089 Clause 8 (user plane security - confidentiality) Ericsson pCR Approval Yes
YesHuawei: would like to keep this open conclusion: merged into S3-173516
merged No    
    S3‑173111 Cluase 8.4 UP Security Nokia pCR Approval Yes
Yes
revised No S3‑173495  
    S3‑173495 Cluase 8.4 UP Security Nokia pCR Approval Yes
Yes
approved No   S3‑173111
    S3‑173197 UP security policy determination Huawei; Hisilicon pCR Approval Yes
YesNokia: too much signalling
postponed No    
    S3‑173198 Discussion on granularity of UP seucirty Huawei; Hisilicon,ZTE discussion Approval Yes
YesMCC: tyoe corrected from pCR to discussion Proposal 1: Option a) is endorsed by SA3. Proposal 2: Send a LS to SA2 and RAN2 to inform the AS security mechanism. Ericsson: requires more offline discussion Nokia: Tdoc is linked to granularity discussion
noted No    
    S3‑173199 pCR on UP protection granulairty Huawei; Hisilicon pCR Approval Yes
Yesconclusion: merged into S3-173516
merged No    
    S3‑173090 Clause 8 (relation between RRC and user plane security algorithms) Ericsson pCR Approval Yes
Yesconclusion: merged into S3-173516
merged No    
    S3‑173091 Clause 8 (conflict between RAN and CN) Ericsson pCR Approval Yes
YesHuawei: is an overload issue, does not agree to editor's note Qualcomm: if this is a problem, then we need to address it conclusion: merged into S3-173516
merged No    
    S3‑173112 Clause 5.2.9 Requirements for gNB DU-CU interface Nokia, Telecom Italia pCR Approval Yes
YesHuawei: wants to add a note Ericsson: supports to go with Nokia proposal
revised No S3‑173496  
    S3‑173496 Clause 5.2.9 Requirements for gNB DU-CU interface Nokia, Telecom Italia pCR Approval Yes
Yes
approved No   S3‑173112
    S3‑173395 pCR to 33.501 to 5.2.9 - Requirements for F1 interface revisited DOCOMO Communications Lab. pCR Approval Yes
Yessee S3-173496 instead
rejected No    
    S3‑173023 LS on security during Resume reject in INACTIVE state in NR R2-1712052 LS in   Yes
YesQuestions from the LS: Q.1: Does SA3 have any security concern with the above RAN2 agreement? For example, there can be DoS attack by a fake gNB sending one or more successive response messages with Wait timer. Further RAN2 would like to ask if SA3 has any comments regarding the Wait timer values. Q.2: Does SA3 sees any risk of replay attacks, from re-using the same I-RNTI and same key to derive the (short) MAC-I for the subsequent resume request message after a rejection? Nokia: we need to reply on this conclusion: LS answer postponed
postponed No    
    S3‑173072 Security aspects of RESUME REJECT in INACTIVE state in NR ZTE Corporation discussion Approval Yes
Yes
not treated No    
    S3‑173211 Discussion on Security Issues with RRC Reject for INACTIVE Mode Intel Corporation (UK) Ltd discussion Decision Yes
Yes
not treated No    
    S3‑173086 Clause 8.1.2.2 (AS security mode command procedure) for RRC Ericsson pCR Approval Yes
Yes
not treated No    
    S3‑173186 pCR to TS 33.501 Security handling in for RRC Connection Re-establishment Huawei, Hisilicon pCR Approval Yes
Yes
not treated No    
    S3‑173195 Security-algoritms-negotiation-for-Initial-AS-security-context Huawei, Hisilicon, China Mobile pCR Approval Yes
Yesconclusion: merged into S3-173516
merged No    
    S3‑173085 Clause 8.1.2.1.1 (AS algo. initial context) for RRC Ericsson pCR Approval Yes
Yes
not treated No    
    S3‑173196 AS Security Negotiation and Activation Huawei; Hisilicon pCR Approval Yes
Yesconclusion: merged into S3-173516
merged No    
    S3‑173187 pCR to TS 33.501 5G-RAN key identification Huawei, Hisilicon pCR Approval Yes
Yes
not treated No    
    S3‑173188 pCR to TS 33.501 5G-RAN key lifetimes Huawei, Hisilicon pCR Approval Yes
Yes
not treated No    
    S3‑173180 Adding context on Establishment of keys for cryptographically protected radio bearers (subclause 8.2.1.2.2) Huawei, Hisilicon pCR Approval Yes
Yes
not treated No    
    S3‑173142 Security Procedures between 5G Network Functions Huawei, Hisilicon pCR Approval Yes
Yes
not treated No    
    S3‑173136 Address EN in requirements for gNB setup and configuration Huawei, Hisilicon, pCR Approval Yes
Yes
not treated No    
    S3‑173202 Requirements for UP and CP for the gNB Huawei, Hisilicon, China Mobile pCR Approval Yes
Yes
not treated No    
    S3‑173203 Replay protection Huawei; Hisilicon pCR Approval Yes
Yes
not treated No    
    S3‑173204 Integrity clause Huawei; Hisilicon pCR Approval Yes
Yes
not treated No    
    S3‑173205 Confidentiality clause Huawei; Hisilicon pCR Approval Yes
Yes
not treated No    
    S3‑173141 Adding Forward & Backward Security definition to TS33.501 Huawei, Hisilicon pCR Approval Yes
Yes
not treated No    
    S3‑173190 Draft reply LS to R2-1712052 = S3-173023 on security during Resume reject in INACTIVE state in NR (to: RAN2; cc: -; contact: Huawei) Huawei, Hisilicon LS out Approval Yes
YesMCC: compare to S3-173213 and S3-173389
not treated No    
    S3‑173200 Draft LS on AS security (to: SA2, RAN2; cc: -; contact: Huawei) Huawei; Hisilicon LS out Approval Yes
Yesconclusion: LS will not be sent
rejected No    
    S3‑173389 Draft reply LS to R2-1712052 = S3-173023 on security during Resume reject in INACTIVE state in NR (to: RAN2; cc: -; contact: Ericsson) Ericsson LS out Approval Yes
YesMCC: Tdoc is not an LSout as it does not use the LSout template; compare S3-173213 and S3-173190
not treated No    
    S3‑173094 Clause 8.2.2.1 (key handling – RRC INACTIVE/CONNECTED state transition) Ericsson pCR Approval Yes
Yes
not treated No    
    S3‑173179 Adding context on Transition from CM-IDLE to CM-CONNECTED (subclause 8.2.1.2.1) Huawei, Hisilicon pCR Approval Yes
Yes
not treated No    
    S3‑173181 Adding context on Transition from CM-CONNECTED to CM-IDLE (subclause 8.2.1.2.3) Huawei, Hisilicon pCR Approval Yes
Yes
not treated No    
    S3‑173213 Draft reply LS to R2-1712052 = S3-173023 on security during Resume reject in INACTIVE state in NR (to: RAN2; cc: -; contact: Intel) Intel Corporation (UK) Ltd LS out Approval Yes
YesMCC: LS does not indicate draft in the title and has source: SA3; compare S3-173389 and S3-173190
not treated No    
    S3‑173189 Discussion on security during Resume reject in INACTIVE state in NR Huawei, Hisilicon discussion Discussion Yes
Yes
not treated No    
    S3‑173095 Clause 8.2.2.2 (key handling – RRC INACTIVE mobility) Ericsson pCR Approval Yes
Yes
not treated No    
    S3‑173092 UE-assisted network-based detection of false-cell-camping - disc Ericsson, AT&T, China Mobile, T-Mobile USA discussion Endorsement Yes
Yes
not treated No    
    S3‑173035 Support of PKI for NodeB Authentication AT&T, MITRE, Interdigital, TCG discussion Decision Yes
Yestreated in connection with S3-173064; BT: how do we get emergency calls to work? is unncessary for commercial networks at the moment, you could do this proprietary if you really need it Ericsson: we see a value of a SI but not now; Orange: SI about the support of a solution is not appropriate, it should be about requirements; BT: limited system for special customers; SA3 chair: due to current time pressure bringing the WI/SI proposal at a later stage (after completion of phase 1) would be better; Qualcomm: also suggests to look at the TR in which we collected the threats Orange: sees that the proposed WI/SI has also RAN and SA2 impact Ericsson: suggests to look also at S3-173093
noted No    
    S3‑173093 UE-assisted network-based detection of false-cell-camping - pCR Ericsson, AT&T, China Mobile, T-Mobile USA pCR Approval Yes
YesEricsson: also Telecom Italia is supporting this Nokia: supports the Tdoc but suggests to add something to 8.2.3 SA3 chair: someone against the proposal? KPN: some worries Qualcomm: no changes needed ? Ericsson: not in phase 1 Qualcomm: why not putting it in the informative annex? there is no change of the normative part Huawei: same view as Qualcomm and KPN Orange: agrees with Huawei, this may also have impact on RAN
revised No S3‑173499  
    S3‑173499 UE-assisted network-based detection of false-cell-camping - pCR Ericsson, AT&T, China Mobile, T-Mobile USA pCR Approval Yes
YesEricsson: only Annex remained
approved No   S3‑173093
    S3‑173365 pCR on signalling procedure for periodic local authentication Samsung pCR Approval Yes
Yes
not treated No    
    S3‑173510 Draft LS on UP security policy (to: SA2, RAN3; cc:-; contact: Huawei) Huawei LS out Approval No
YesEricsson: not sure about algorithms in bullet list Huawei: would be fine for phase 1 Nokia: why is RAN2 in the to: list? Ericsson: which group defines policy control function? Huawei: then we include also CT3 on cc:
withdrawn Yes S3‑173520  
    S3‑173520 LS on User Plane Security Policy (to: SA2, RAN3; cc: CT3; contact: Huawei) SA3 LS out Approval Yes
Yes
approved No   S3‑173510
    S3‑173511 Report from offline session about UP security granularity NTT DOCOMO report discussion Yes
Yesoffline discussion was held during Thu lunch break SA3 chair: so points 7 and 10 are still under discussion NTT DOCOMO: 1. was the basis
noted No    
    S3‑173516 Agreements on UP security Ericsson, Huawei, Samsung, Qualcomm, Nokia, HiSilicon pCR Approval Yes
Yesthis pCR is merging aspects of the following pCRs: Ericsson: 3087, 3088, 3089, 3090, 3091 Huawei: 3195, 3196, 3199 after the results of the offline discussion in S3-173511
approved No    
7.2.5 NAS security S3‑173108 Clause 6.6.2.2 Multiple active NAS connections Nokia pCR Approval Yes
YesSA3 chair: we will discuss S3-173108, S3-173371, S3-173300, S3-173331, S3-173234, S3-173193 together
not treated No    
    S3‑173371 Multiple active NAS connections in the same PLMN’s serving network Ericsson pCR Approval Yes
YesEricsson: similar to Nokia's proposal, Nokia assumes dynamic handling
not treated No    
    S3‑173300 Discussion on the NAS security contexts when registered on both 3GPP and non-3GPP access in the same PLMN Qualcomm Incorporated discussion Endorsement Yes
Yes
noted No    
    S3‑173331 Threat model without multiple NAS keys NEC EUROPE LTD pCR Approval Yes
Yes
rejected No    
    S3‑173234 Adding content to NAS security Huawei, Hisilicon pCR Approval Yes
Yes
rejected No    
    S3‑173193 Add new requirements for multiple registrations in the same PLMN Huawei, Hisilicon, China Unicom pCR Approval Yes
YesSA3 chair: we will discuss S3-173108, S3-173371, S3-173300, S3-173331, S3-173234, S3-173193 together Ericsson: all proposals are rather close together apart from NEC proposal Intel: does it work for reauthentication? Nokia: reauthentication is simple (only when 2 it's complex), dispute is within one PLMN Intel: fine if same for all access technologies conclusion: further offline discussion needed
rejected No    
    S3‑173107 Clause 6.6.5 Handling of NAS counts -multiple NAS links Nokia pCR Approval Yes
Yes
not treated No    
    S3‑173109 Clause 6.3.4.2 Multiple registrations in same PLMN Nokia pCR Approval Yes
Yesnot treated after S3-173330
not treated No    
    S3‑173106 Changes for Multiple NAS links Annex D Nokia pCR Approval Yes
Yes
not treated No    
    S3‑173359 Multiple registrations in different PLMNs serving networks Ericsson pCR Approval Yes
Yes
postponed No    
    S3‑173177 Adding context on Transition from RM-REGISTERED to RM-DEREGISTERED (subclause 8.2.1.1.1) Huawei, Hisilicon pCR Approval Yes
Yes
not treated No    
    S3‑173178 Adding context on Transition from RM-DEREGISTERED to RM-REGISTERED (subclause 8.2.1.1.2) Huawei, Hisilicon pCR Approval Yes
Yes
not treated No    
    S3‑173383 Connection state transitions in TS 33.501 Ericsson, Huawei, Hisilicon pCR Approval Yes
Yes
revised No S3‑173489  
    S3‑173489 Connection state transitions in TS 33.501 Ericsson, Huawei, Hisilicon pCR Approval No
Nomerges also S3-173179, S3-173180, S3-173181
withdrawn Yes   S3‑173383
    S3‑173382 Registration state transitions in TS 33.501 Ericsson, Huawei, Hisilicon pCR Approval Yes
Yes
revised No S3‑173488  
    S3‑173488 Registration state transitions in TS 33.501 Ericsson pCR Approval No
Nomerges also S3-173177, S3-173178
withdrawn Yes   S3‑173382
    S3‑173184 pCR to TS 33.501 KDF negotiation Huawei, Hisilicon pCR Approval Yes
Yestreated in connection with S3-173328/3329
rejected No    
    S3‑173403 Nokia comments on KDF negotiation contributions 3184,3328,3329 Nokia discussion Endorsement Yes
Yestreated in connection with S3-173328/3329
noted No    
    S3‑173362 New requirements for algorithm selection in TS 33.501 Ericsson pCR Approval Yes
Yes
not treated No    
    S3‑173097 Clause 6.6.6 (rectifying partial protection aspects) Ericsson pCR Approval Yes
Yes
not treated No    
    S3‑173293 Aligning the protection of initial NAS messages and the NAS Security Mode procedure subclauses Qualcomm Incorporated pCR Approval Yes
Yes
not treated No   S3‑172383
    S3‑173404 Commenting contribution on S3-173293 for protection of initial NAS message Huawei Tech.(UK) Co., Ltd discussion Discussion Yes
Yes
not treated No    
    S3‑173405 Companion pCR to S3-173304 Huawei Tech.(UK) Co., Ltd pCR Approval Yes
Yes
not treated No    
    S3‑173110 Clause 6.7.2 NAS SMC procedure (over any NAS connection) Nokia pCR Approval Yes
Yes
not treated No    
    S3‑173176 Corrections on NAS security mode command procedure (subclause 6.7.2) Huawei, Hisilicon pCR Approval Yes
Yes
not treated No    
    S3‑173185 Delete allowed NSSAI in NAS SMC Huawei, Hisilicon pCR Approval Yes
Yes
not treated No    
    S3‑173361 Exception lists of NAS and RRC message to be integrity protected and encrypted Ericsson pCR Approval Yes
Yes
not treated No    
    S3‑173156 Enforcement of Session Key with DH Procedure in Serving Networks Huawei & Hisilicon pCR Approval Yes
Yes
not treated No    
    S3‑173262 pCR to 33.501 - DH procedure with AMF for protection against passive eavesdropping VODAFONE Group Plc pCR Approval Yes
Yes
not treated No    
    S3‑173275 pCR- Updating NAS security mode command procedure China Mobile pCR Approval Yes
Yes
withdrawn Yes    
    S3‑173276 pCR- Updating NAS security mode command procedure China Mobile pCR Approval Yes
Yes
not treated No    
    S3‑173277 Adding Security Mode of the Session key to the SMC procedure China Mobile discussion   Yes
Yes
not treated No    
7.2.6 Security context management S3‑173175 Adding the requirement of NEA0 and NIA0 Huawei, Hisilicon pCR Approval Yes
Yes
approved No    
    S3‑173173 Fixing the definition of NEA and NIA Huawei, Hisilicon pCR Approval Yes
Yes
approved No    
    S3‑173308 Multiple Registrations in different PLMNs using K_AUSF Qualcomm Incorporated pCR Approval Yes
YesDeutsche Telekom: is this optimisation really needed Qualcomm: is optional feature for UE and network Ericsson: not really needed in phase 1 Orange: key derivation should be discussed first Nokia: we have a number of comments and this proposal cannot work Ericsson: has a different solution in S3-173359
postponed No    
    S3‑173330 Multiple registrations in the same PLMN NEC EUROPE LTD pCR Approval Yes
YesEricsson: belongs to same set of documents that were postponed Nokia: S3-173109 clashes with this pCR Huawei: S3-173192 also clashes with this pCR
postponed No    
    S3‑173364 New UE requirement to store two 5G security contexts in TS 33.501 Ericsson pCR Approval Yes
YesQualcomm: is in wrong place Ericsson: would like to postpone this
postponed No    
    S3‑173328 Discussion on UE 5G Security Capability with KDF identifiers NEC EUROPE LTD discussion Discussion Yes
YesMCC: Tdoc type corrected from pCR to discussion
noted No    
    S3‑173329 KDF ID to be included as a part of UE Security capabilities NEC EUROPE LTD pCR Approval Yes
YesHuawei: has a related Tdoc in S3-173184 (AI 7.2.5) Nokia: has S3-173403 (AI 7.2.5)
rejected No    
    S3‑173105 Handling security contexts within the serving network Nokia, Huawei, HiSilicon pCR Approval Yes
YesNokia: also Ericsson is supporting this Tdoc Qualcomm: why should subscriber identity in the clear Orange: should be replaced by SUPI Ericsson: under 6.3.3.4 in 2nd paragraph: wondering about "upgraded"
revised No S3‑173519  
    S3‑173519 Handling security contexts within the serving network Nokia, Huawei, HiSilicon pCR Approval Yes
Yes
approved No   S3‑173105
7.2.7 Visibility & configurability S3‑173218 Security visibility China Unicom pCR Approval Yes
Yes
not treated No    
    S3‑173396 pCR to 33.501 5.4.1 - Clarification of security indication NTT DOCOMO, Department of Commerce, KPN pCR Approval Yes
Yes
not treated No    
    S3‑173227 Clarification of security indication for UE (subclause 5.4.1) LG Electronics pCR Approval Yes
Yes
not treated No    
    S3‑173126 Visibility and configurability supporting serving network authorization Nokia, LG pCR Approval Yes
Yes
not treated No    
    S3‑173219 Security configurability China Unicom pCR Approval Yes
Yes
not treated No    
7.2.8 Primary authentication S3‑173104 Clause 6 5G AKA over non-3gpp access Nokia, Lenovo, Motorola Mobility pCR Approval Yes
Yes
not treated No    
    S3‑173294 Specifying the key derivation when using 5G AKA Qualcomm Incorporated pCR Approval Yes
Yestreated in connection with S3-173144 (AI 7.2.1) conclusion: merged in S3-173514
merged No   S3‑172382
    S3‑173343 Unified handling of Kausf with 5G AKA and EAP-AKA’ Ericsson pCR Approval Yes
Yestreated in connection with S3-173144 (AI 7.2.1)
revised No S3‑173514  
    S3‑173514 Unified handling of Kausf with 5G AKA and EAP-AKA’ Ericsson, Qualcomm, Nokia, Huawei, Hisilicon pCR Approval Yes
Yesis a revision of S3-173343 and will include also changes from merged Tdocs 3144, 3145, 3146, 3147, 3294, 3129
approved No   S3‑173343
    S3‑173312 Adding numbered figure for EAP-AKA' KPN pCR Approval Yes
Yes
not treated No    
    S3‑173313 Adding numbered figure for 5G AKA. KPN pCR Approval Yes
Yes
not treated No    
    S3‑173270 Resolve Editor’s Note in clause 6.1.3.2 of TS 33.501 Huawei, Hisilicon pCR Approval Yes
Yes
not treated No    
    S3‑173273 Adding 5G Authentication Confirmation Answer for 5G-AKA Huawei, Hisilicon pCR Approval Yes
Yes
not treated No    
    S3‑173269 Removal of the number of AVs requested in Authentication Information Request message Huawei, Hisilicon pCR Approval Yes
Yes
not treated No    
    S3‑173397 pCR to 33.501 6.1.2, 6.1.3.2 – only one authentication vector at a time DOCOMO Communications Lab. pCR Approval Yes
Yes
not treated No    
    S3‑173400 Discussion on multiple authentication vectors in response to S3-173397and other docs VODAFONE Group Plc discussion Information Yes
Yes
not treated No    
    S3‑173344 Construction of serving network name with 5G AKA and EAP-AKA’ Ericsson pCR Approval Yes
Yes
not treated No    
    S3‑173125 Authorization of SN by UE Nokia, LG pCR Approval Yes
Yes
not treated No    
    S3‑173391 Information about new I-D related to EAP-AKA Ericsson discussion Information Yes
YesMCC: type corrected from pCR to discussion
not treated No    
    S3‑173263 pCR to 33.501 - DH procedure with SEAF for protection against passive eavesdropping VODAFONE Group Plc pCR Approval Yes
Yes
not treated No    
    S3‑173155 Security Procedures for EAP-TLS Huawei, Hisilicon, Ericsson, Qualcomm Incorporated, China Mobile pCR Approval Yes
Yes
not treated No    
7.2.9 Secondary authentication S3‑173342 Alignment with SA2 procedure and general cleanup Nokia pCR Approval Yes
Yes
not treated No    
    S3‑173341 Resolve ENs on use of Normative language Nokia pCR Approval Yes
Yes
not treated No    
    S3‑173228 Clarification on network slice access authentication and authorization LG Electronics pCR Approval Yes
Yes
not treated No    
    S3‑173163 Binding Primary and Secondary authentication Intel Corporation (UK) Ltd discussion Discussion Yes
Yes
not treated No    
    S3‑173401 Comments to S3-173163 China Mobile discussion   Yes
Yes
not treated No    
    S3‑173301 Identifying a problem with secondary authentication Qualcomm Incorporated pCR Approval Yes
Yes
not treated No   S3‑172380
    S3‑173164 Secure binding of primary and secondary authentication Intel Corporation (UK) Ltd pCR Approval Yes
Yes
not treated No    
    S3‑173165 Secure Data Port for Secondary Authentication Intel Corporation (UK) Ltd pCR Approval Yes
Yes
not treated No    
    S3‑173302 pCR to update the secondary authentication procedure to include the authentication/authorization confirmation between UE and SMF when a key generating EAP method is used Qualcomm Incorporated pCR Approval Yes
Yes
not treated No    
    S3‑173157 ID linkage verification in secondary authentication Huawei & Hisilicon pCR Approval Yes
Yes
not treated No    
    S3‑173303 pCR to update the secondary EAP authentication clause to take into account the roaming scenario Qualcomm Incorporated pCR Approval Yes
Yes
not treated No    
    S3‑173152 Secondary authentication via NEF Huawei & Hisilicon discussion   Yes
YesMCC: type corrected from pCR to discussion Proposal1: The SMF may use the NEF for DN authentication/authorization according to DN policy, local configuration, and/or the application identifier provided by the UE considering the impact to the AF. Proposal2: The DN authentication/authorization function may authenticate/authorize the PDU session establishment and return the authentication/authorization result to the SMF via the NEF. Nokia: is an architecture change, not in line with SA2 Orange: too late to modify SA3 chair: there is no support for the proposals, also related pCR 3151 is not agreed
noted No    
    S3‑173151 Discussion on secondary authentication Huawei & Hisilicon pCR Approval Yes
Yes
rejected No    
    S3‑173158 DN authorization grant and revocation Huawei & Hisilicon pCR Approval Yes
Yes
not treated No    
    S3‑173166 Secondary Re-Authentication Intel Corporation (UK) Ltd pCR Approval Yes
Yes
not treated No    
    S3‑173159 Secondary Authentication for multiple PDU sessions Huawei & Hisilicon pCR Approval Yes
Yes
not treated No    
7.2.10 Interworking S3‑173170 Discussion on security of interworking with N26 Huawei, Hisilicon discussion Discussion Yes
Yes
revised No S3‑173232  
    S3‑173232 Discussion on security of interworking with N26 Huawei, Hisilicon discussion Discussion Yes
YesProposal 1: MMEs are mandatory to upgrade for interworking if the above observations are taken into consideration. Proposal 2: Native security context takes precedence over mapped security context in the target system, but the source system is always required to verify the UE with its native security context when it receives the context request message. Proposal 3: The anchor key shall never be sent to the other system during the interworking procedure. Nokia: does not agree to proposal 1 Qualcomm: disagrees with proposal 1 Ericsson: should we say "no MME impact"? Qualcomm: it shall be possible to have interworking with legacy MMEs, so no upgrading should be needed for 4G-5G interworking Huawei: if no change how would MME find out that coming in UE is 5G capable? Ericsson: we do not yet need to agree to proposal 3 Orange: if SA2 is deciding to modify MME, then there is no problem for us to change but if they do not change, then we should follow SA3 chair: so you want to check with SA2? Orange: yes conclusion: proposal 1 and 3 not agreed; instead of proposal 1 the following was agreed: support for legacy MME is mandatory; instead of proposal 2 the following is agreed: "Native security context takes precedence over mapped security context in the UE"
noted No   S3‑173170
    S3‑173346 Discussion on the security for interworking between EPC and 5GC Ericsson discussion Approval Yes
YesProposal 1: The security mechanisms for interworking shall minimize, if not possible to avoid, impact on 4G. Proposal 2: The security mechanisms for interworking shall maintain at least the same level of security compared to 4G. This does not overrule the introduction of improvements. Proposal 3: The security mechanisms for interworking shall not prevent the independent evolution of 5G security. Proposal 4: The system shall provide mechanisms to protect the confidentiality and the integrity protection of the transferred UE context data for interworking. Proposal 5: The system shall provide a mechanism to authenticate the trigger message before transfer of the UE context for interworking. Proposal 6: The system shall provide backward security from 5G to 4G. Proposal 7: The system shall provide integrity protection of the initial NAS message for idle mode mobility both from 5G to 4G and from 4G to 5G. Huawei: as we said MME shall not be changed, proposal 1 is not ok Nokia: proposal 2 is unclear Ericsson: it means: we have 4G security in 5G we may want more Vodafone: should proposal 4 not say "5G system"? Qualcomm: proposal 4 should clarify: transfer between core network nodes Qualcomm: is proposal 5 just for idle mode mobility (it makes no sense in other cases)? Ericsson: yes, most interesting in idle mode Nokia: not really sure what proposal 5 wants to say Qualcomm: proposal 7 is not related to interworking, we will do it anyway conclusions: proposal 1 not agreed; instead of proposal 2 only first part is agreed: "The security mechanisms for interworking shall maintain at least the same level of security compared to 4G."; proposal 3 is agreed; instead of proposal 4 it is agreed: The system shall provide mechanisms to protect the confidentiality and integrity of the UE context data when transferred between network nodes for interworking; proposal 5 needs further offline discussion; proposal 6 is agreed; proposal 7 is not agreed
revised No S3‑173457  
    S3‑173457 Discussion on the security for interworking between EPC and 5GC Ericsson discussion Approval No
Yes
withdrawn Yes   S3‑173346
    S3‑173304 Security handling for interworking between NextGen Core and EPC Qualcomm Incorporated discussion Endorsement Yes
YesProposal #1: To support 5GC to EPC mobility, AMF shall be able to derive a key from KAMF that would be used by the MME to create a security context. Proposal #2: AMF shall be able to derive a native EPS security context. Proposal #3: To support EPC to 5GC mobility, MME shall be able to derive a key from KAMSE which would be used create a security context at SEAF. Proposal #4: To support interworking with a legacy MME, AMF shall be able to create a 5G security context using the EPS security context received from MME. Furthermore, AMF shall be able to set a key usage information (e.g., native or mapped) to the 5G security context. Proposal #5: AMF shall be able to retrieve a native 5G security context if available. Nokia: proposals 1, 2 and 5 are ok for us conclusion: proposal 1 is agreed instead of proposal 2 it is agreed: AMF shall be able to retrieve a native 5G security context if available. proposal 3 is not agreed proposal 4 is agreed instead of proposal 5 it is agreed: AMF shall be use the native 5G security context if available.
noted No   S3‑172385
    S3‑173073 Discussion paper on retaining security context in Interworking Nokia discussion Approval Yes
YesProposal 1: To support integrity protection of the idle mode moblity management (MM) message to the target network, the UE shall store the current security context (mapped or native) for the previously visited network for a limited period. Proposal 2: To support integrity check of the idle mode MM message, the source network shall store the security context for the UE for a limited period. Proposal 3: The target network shall verify the integrity of the idle mode MM message if it has the current security context for the UE. Proposal 4: If the target network successfully verified the integrity of the idle mode MM message, it shall not consider the mapped security context from the source network. In this case, the target network shall continue to use the stored current security context for the UE. Proposal 5: The target network shall use the existing parameter “MS validated” to indicate to the source network in the Context Request message that it has successfully validated the UE. The source network shall skip integrity check if “MS validated” is TRUE. Proposal 6: Send an LS to SA2, inform them of the above proposals – if agreed by SA3 – and ask them to add corresponding functionality to their specs, in particular for proposal 2. Ericsson, Huawei: we do not need proposals 1/2/3 Ericsson: for proposal 6 we have already an LS for this conclusion: proposals 1, 2, 3 are not agreed proposals 4, 5, 6 are agreed
noted No    
    S3‑173334 Skeleton proposal for clause 9 - Security of interworking NEC EUROPE LTD pCR Approval Yes
YesEricsson: should we not do Ericsson's restructuring first? conclusion: NEC's input can be addressed under Ericsson's restructuring in S3-173392
merged No    
    S3‑173233 Interworking with EPC without N26 interface Huawei, Hisilicon pCR Approval Yes
YesEricsson: has a lot of text from SA2 text, so not supporting to include this part in the SA3 spec SA3 chair:yes, we need avoid duplication
postponed No    
    S3‑173347 Proposal for a new subclause 9.X on the registration mode and the applicability of the security mechanisms for interworking between 4G and 5G Ericsson pCR Approval Yes
YesNokia: prefers S3-173347 over S3-173233
revised No S3‑173466  
    S3‑173466 Proposal for a new subclause 9.X on the registration mode and the applicability of the security mechanisms for interworking between 4G and 5G Ericsson pCR Approval Yes
Yes
approved No   S3‑173347
    S3‑173305 pCR to provide a general text for interworking between 5GC and EPC Qualcomm Incorporated pCR Approval Yes
Yesconclusion: section 9.1 will be merged into S3-173466
merged No   S3‑172386
    S3‑173075 Integrity protection of idle mobility message during Interworking Nokia discussion Approval Yes
Yes
not treated No    
    S3‑173074 Discussion paper on Interworking with a legacy MME Nokia discussion Approval Yes
Yes
not treated No    
    S3‑173172 handover procedures between 5GC and EPC with N26 Huawei, Hisilicon pCR Approval Yes
Yes
not treated No    
    S3‑173078 Handover from 4G to 5G Nokia pCR Approval Yes
Yes
not treated No    
    S3‑173079 Handover from 5G to 4G Nokia pCR Approval Yes
Yes
not treated No    
    S3‑173337 Handover procedure from EPS to 5GS NEC EUROPE LTD pCR Approval Yes
Yes
not treated No    
    S3‑173335 Handover procedure from 5GS to EPS NEC EUROPE LTD pCR Approval Yes
Yes
not treated No    
    S3‑173379 Proposal for a new subclause 9.Z.X on interworking security in handover from 4G to 5G Ericsson LM pCR Approval Yes
Yes
not treated No    
    S3‑173380 Proposal for a new subclause 9.Z.X on interworking security in handover from 5G to 4G Ericsson LM pCR Approval Yes
Yes
not treated No    
    S3‑173171 Idle mode mobility between EPC and 5GC with N26 Huawei, Hisilicon pCR Approval Yes
Yes
not treated No    
    S3‑173076 Idle mode mobility from 4G to 5G Nokia pCR Approval Yes
Yes
not treated No    
    S3‑173077 Idle mode mobility from 5G to 4G Nokia pCR Approval Yes
Yes
not treated No    
    S3‑173350 Proposal for a new subclause 9.Y.X on interworking security in idle mode from 4G to 5G Ericsson pCR Approval Yes
Yes
not treated No    
    S3‑173351 Proposal for a new subclause 9.Y.X on interworking security in idle mode from 5G to 4G Ericsson pCR Approval Yes
Yes
not treated No    
    S3‑173348 Proposal for a new subclause 9.X on mapping of security contexts during interworking between 4G and 5G Ericsson pCR Approval Yes
Yes
not treated No    
    S3‑173349 Draft reply LS to S2-178210 = S3-173030 on security handling for EPC-5GC interworking (to: SA2; cc: -; contact: Ericsson) Ericsson LS out Approval Yes
YesMCC: source is already SA3
revised No S3‑173508  
    S3‑173508 Reply LS to S2-178210 = S3-173030 on security handling for EPC-5GC interworking (to: SA2; cc: -; contact: Nokia) SA3 LS out Approval Yes
YesEricsson: worried about overhead where you have trust in 4G system LS was sent out on Thu evening of SA3 #89
approved No   S3‑173349
    S3‑173048 Security for idle mobility between 4G and 5G ZTE Corporation discussion Approval Yes
Yes
not treated No    
    S3‑173521 Agreements on interworking Nokia discussion discussion Yes
Yes
endorsed No    
7.2.11 Non-3gpp access S3‑173182 multiple NAS keys at AMF when UE connectes to the AMF belonging to different Operators Huawei, Hisilicon pCR Approval No
Yes
withdrawn Yes    
    S3‑173183 signal NAS keys at AMF when UE connects to the AMF belonging to the same Operaotr Huawei, Hisilicon pCR Approval No
Yes
withdrawn Yes    
    S3‑173192 Add a new requirement in scenario when UE has multiple registration in different PLMNs Huawei, Hisilicon, China Unicom pCR Approval Yes
Yesnot treated after S3-173330
not treated No    
    S3‑173251 Authentication for Untrusted Non-3GPP Access using EAP Motorola Mobility, Lenovo, LG Electronics, Nokia, KPN, Broadcom, Brocade pCR Approval Yes
Yes
not treated No    
7.2.12 NDS S3‑173046 Protecting sensitive information transmitted between operators - reference point presentation ZTE Corporation, China Unicom pCR Approval Yes
Yes
not treated No   S3‑172203
    S3‑173206 Add Management Plane Protection Huawei; Hisilicon pCR Approval Yes
Yes
not treated No    
    S3‑173207 Add management reference to gNB setup and configuration Huawei; Hisilicon pCR Approval Yes
Yes
not treated No    
7.2.13 Service based architecture S3‑173246 Security requirements for service based architecture Neul Limited pCR Approval No
Yes
revised No S3‑173255  
    S3‑173250 Authentication in the service registration procedure Neul Limited pCR Approval No
Yes
revised No S3‑173256  
    S3‑173253 Authorization of NF service discovery Neul Limited pCR Approval No
Yes
revised No S3‑173258  
    S3‑173258 Authorization of NF service discovery Huawei, Hisilicon pCR Approval Yes
Yes
not treated No   S3‑173253
    S3‑173255 Security requirements for service based architecture Huawei, Hisilicon pCR Approval Yes
YesDeutsche Telekom: has a problem with the language used here, "should" means no guarantee, we need "shall" Intel: has related Tdocs in S3-173209 and S3-173210 conclusion: authorization aspect will be merged into S3-173483
merged No   S3‑173246
    S3‑173209 Security requirements for Service Based Architecture Discovery Intel Corporation (UK) Ltd pCR Approval Yes
Yesconclusion: title will be changed, shall support, authorization will be added (merged with Huawei text)
merged No    
    S3‑173210 Security requirements for Service Based Architectur Registration Intel Corporation (UK) Ltd pCR Approval Yes
YesDeutsche Telekom: authorization request should be added conclusion: title will be changed, shall support, authorization will be added (merged with Huawei text)
revised No S3‑173483  
    S3‑173483 Security requirements for Service Based Architectur Registration Intel Corporation (UK) Ltd pCR Approval Yes
Yeswill include aspects of S3-173255 and S3-173209
approved No   S3‑173210
    S3‑173153 Adding KI of Service authorization to living doc Huawei & Hisilicon pCR Approval Yes
Yesconclusion: will be added into living Tdoc S3-173484
endorsed No    
    S3‑173484 Living document for service based architecture Nokia discussion discussion Yes
Yesincludes also aspects of S3-173486, S3-173490
endorsed No    
    S3‑173208 NRF Requirements Huawei; Hisilicon pCR Approval Yes
YesEricsson: first requirement is unclear NTT DOCOMO: not shared conclusion: req. 1 will be split into 2 (rest of req. 1 will be removed), req. 2 and editor's notes at the end will be removed; "NRF shall" will be integrated in requirements; req.3 will be removed
revised No S3‑173485  
    S3‑173485 NRF Requirements Huawei; Hisilicon pCR Approval Yes
YesDeutsche Telekom raised concerns about the word „may“ in the second NRF requirement, citing the agreed SBA security goal goal #4.
approved No   S3‑173208
    S3‑173220 Security for Service Based Interconnect interfaces Nokia, Deutsche Telecom discussion Approval Yes
YesProposal 1: Add in the 5G architecture a network element at the edge of the service provder network that allows for interconnect security to be implemented, in addition to other security policies such topology hiding etc. Proposal 2: Implement e2e application layer security in the network element at the edge of the network. Proposal 3: Add in the 5G architecture the possibility for active intermediate security end-nodes that may manipulate application layer information as it traverses through it. Proposal 4: Delegation of e2e application layer security to another service provider must be allowed in 5G Proposal 5: Delegation of e2e application layer security to roaming hubs must be allowed in 5G. Proposal 6: Take FS.19 – Diameter Interconnect Security, as the basis to identify Information elements (IEs) that need e2e protection in 5G SBA Proposal 7: Map identified IEs into one of the protection categories identified in clause 4.1.5 above. NTT DOCOMO: Ericsson is against security at edge proxy? Ericsson: no, but not all Ericsson: for proposals 4 & 5 we need an extra discussion document conclusion: proposal 1 is agreed, instead of proposal 2 it is agreed: Consider implementation of application layer security in SEPP proposal 3 is agreed (end has to be removed), proposals 4 and 5 not agreed proposals 6 and 7 agreed
revised No S3‑173486  
    S3‑173486 Security for Service Based Interconnect interfaces Nokia, Deutsche Telecom discussion Approval Yes
Yesconclusion: will be included into living Tdoc S3-173484
endorsed No   S3‑173220
    S3‑173221 Security architecture for Service Based Interconnect Interfaces Nokia, Deutsche Telecom discussion Approval Yes
YesEricsson: we have LS we sent to SA2 on Wed
noted No    
    S3‑173222 pCR on Requirement for e2e core network interconnection security Nokia, Deutsche Telecom pCR Approval Yes
YesDeutsche Telekom: it's not a proxy function but just a proxy conclusion: "function" in "proxy function" will be removed
revised No S3‑173487  
    S3‑173487 pCR on Requirement for e2e core network interconnection security Nokia, Deutsche Telecom pCR Approval Yes
Yes
approved No   S3‑173222
    S3‑173261 Protection of the communication between NFs Huawei, Hisilicon pCR Approval Yes
YesDeutsche Telekom, Orange: do not accept this proposal
rejected No    
    S3‑173047 Protecting sensitive information transmitted between operators - SBA ZTE Corporation, China Unicom pCR Approval Yes
YesEricsson: visited network is never authenticated Deutsche Telekom: per user basis is not acceptable to us
rejected No    
    S3‑173314 Discussion on adopting GSMA recommendations for IPX Security. KPN discussion Endorsement Yes
Yesproposals: • SA3 agrees to adopt the integrity protection mechanism proposed by GSMA; • SA3 agrees to adopt the confidentiality protection mechanism proposed by the GSMA; • SA3 agrees to the overall structure of the messages with a message-content part and a signature part as proposed in the GSMA document; • SA3 agrees to use the mechanisms in either [2] or [3] for the encrypted containers and the signature-part of the messages. KPN: proposals are for email discussion
noted No    
    S3‑173223 Application layer security based on JOSE framework Nokia, Deutsche Telecom discussion Approval Yes
Yes
noted No    
    S3‑173224 pCR on Application layer security Nokia, Deutsche Telecom pCR Approval Yes
YesNTT DOCOMO: you must explain what is the basis of the pCR; suggests and editor's note (regarding CT4 and 2 parallel https)
revised No S3‑173490  
    S3‑173490 pCR on Application layer security Nokia, Deutsche Telecom pCR Approval Yes
Yesconclusion: merged into S3-173484
merged No   S3‑173224
    S3‑173154 Merge two procedures of SBA authorization Huawei, Hisilicon, InterDigital pCR Approval Yes
Yes
not treated No    
    S3‑173259 Authorization of NF service access Huawei, Hisilicon pCR Approval Yes
Yes
not treated No    
    S3‑173225 OAuth 2.0 based service authorization for SBA Nokia discussion Decision Yes
Yes
not treated No    
    S3‑173226 pCR on OAuth based service authorization for SBA Nokia pCR Approval Yes
Yes
not treated No    
    S3‑173257 Discussion and pCR about NF authentication for SBA China Mobile other   Yes
Yes
not treated No    
    S3‑173376 Including authentication into authorization aspects Ericsson pCR Approval Yes
Yes
not treated No    
    S3‑173377 Add section for authentication between network functions Ericsson pCR Approval Yes
Yes
not treated No    
    S3‑173256 Authentication in the service registration procedure Huawei, Hisilicon pCR Approval Yes
Yes
not treated No   S3‑173250
    S3‑173526 [Draft] LS on security across inter-operator interconnect (to: CT4; cc: -; contact: Deutsche Telekom) Deutsche Telekom, NTT DOCOMO LS out Approval Yes
Yes
revised No S3‑173527  
    S3‑173527 LS on security across inter-operator interconnect (to: CT4; cc: -; contact: Deutsche Telekom) SA3 LS out Approval Yes
Yes
approved No   S3‑173526
7.2.14 Privacy (not covered by other headings) S3‑173070 Solution for meeting LI and privacy requirements CATT pCR Approval Yes
YesOrange: can we treat all proposals together SA3 chair: ok, so after S3-173070 also S3-173098, S3-173124, S3-173138, S3-173398 will be presented
postponed No    
    S3‑173098 Clauses 6.1.3 and 6.7.2 (auth procedures and NAS SMC, SUPI from UE for LI) Ericsson pCR Approval Yes
Yes
postponed No    
    S3‑173124 LI conformity when privacy is used - was 2506 Nokia, Orange pCR Approval Yes
YesOrange if mismatch between what UE and core network is sending, then our proposal is handling this at an early stage NTT DOCOMO: not clear how random R is passed around
postponed No    
    S3‑173138 Meeting SUPI privacy and LI Requirements Huawei, Hisilicon, Intel pCR Approval Yes
Yes
postponed No    
    S3‑173398 pCR to 33.501 6.1.3.1, 6.1.3.2, Annex A – SUPI assurance in SEAF DOCOMO Communications Lab. pCR Approval Yes
YesT-Mobile: supports Nokia proposal, NTT DOCOMO proposal can be attacked KPN: after discussion with regulators: IMSI needs to be got first Vodafone: LI can be done after authentication without problems SA3 LI chair: we discussed in LI group: do we trust anything before authentication is completed? the answer is no; timing: only relevant for first authentication so not a big issue; if encryption is off there is no need to transfer IMSI (no need to support the extras in this) NTT DOCOMO: SUPI will be public and could be misused Qualcomm: agrees with NTT to send NAS security mode complete; has preference to binding to some key; privacy is maintained and controled by home operator Ericsson: what happens if SUPI is send wrongly? Huawei: we heard from SA3 LI that all operator have NAS security enabled Nokia: we are worried how NAS is handled and so in our proposal we avoid sending the SUPI SA3 LI chair: no requirement for sending SUPI over unencrypted that why we assume encryption; proving that a SUPI was received (for court cases) would make a difference in the proposals; Vodafone: our S3-173272 belongs to this set as well SA3 chair: so please present S3-173272
postponed No    
    S3‑173272 Discussion on provision of SUPI from home to visited network VODAFONE Group Plc discussion Discussion Yes
YesOrange: worries that we mix now 2 topics KPN: would support variant 1 Orange: it seems we have 3 proposals supi in NAS SMC (Ericsson/Huawei ...) , hash function (Nokia ...) and binding keys (NTT DOCOMO), can we have a show of hands NTT DOCOMO: still unclear how Nokia proposal works SA3 LI: operator cannot select their own hash algorithm? show of hands: NAS/IMSI complete: ZTE, home office, NCSC, MTECH, BT, Ericsson, Intel, CMCC, CATT, KPN, Samsung, Huawei => 12 hash based: Minsiter eco, Oberthur, Nokia, T-Mobile, Orange, Gemalto => 6 binding: DOCOMO, LG, Qualcomm =>3 NTT DOCOMO: first proposal must make sure that SUPI is never sent unencrypted SA3 LI chair: IMEI more imprtant than IMSI Orange: heard the opposite SA3 LI chair: both are needed but IMEI allows to do things you cannot do with IMSI Huawei: if NAS encryption could be turned off, we need to find a solution T-Mobile: NAS encryption can be turned off Orange: yes, this is part of our spec that optionally NAS encryption can be switched off; so we cannot make at another part of the spec the assumption that it is encrypted Orange: we could think about a vote and/or check the SA3 LI view NTT DOCOMO: a way where we do not send SUPI in the clear would be acceptable for us (then we would drop our binding proposal) SA3 LI chair: response from SA3 LI could only be accepted by March 18
noted No   S3‑172225
    S3‑173099 Clause 6.8.3 (5G-GUTI refresh at periodic registration update) Ericsson, Telecom Italia pCR Approval Yes
Yes
approved No    
    S3‑173100 Clause 6.8.3 (5G-GUTI refresh at network triggered service request) Ericsson, Telecom Italia pCR Approval Yes
Yes
approved No    
    S3‑173114 Privacy requirements on the UE - was 2509 Nokia pCR Approval Yes
YesVodafone: does not support the proposal, proposal would need to standardize algorithms Orange: should say "The UE" not "A UE"
revised No S3‑173435  
    S3‑173435 Privacy requirements on the UE - was 2509 Nokia pCR Approval Yes
Yes
approved No   S3‑173114
    S3‑173278 pCR- Updating 5.1.5 Subscriber privacy China Mobile pCR Approval Yes
YesOrange: compromise: The calculation of SUCI shall be done in ME and USIM (and USIM takes precedence). BT: precedence may not be good if this is the weaker implementation Nokia: what about precedence by operator policy? Orange: mandatory in ME, possible in USIM and if in USIM we need to define a precedence Oberthur: wrong and unfair analysis provided in rational by China Mobile: - the ECDH computation delay on M0 was assumed without any optimization enabled however when optimization is enabled performance gain is significant as shown in the referenced paper on performance investigations. - not true that the network will reject the UE after 6s but instead after 30s as the timer of 6s is repeated 5 times before the procedure is aborted.
revised No S3‑173436  
    S3‑173436 pCR- Updating 5.1.5 Subscriber privacy Orange, Gemalto, Oberthur Technologies, Morpho, CATT, KPN, Vodafone, Deutsche Telekom AG pCR Approval Yes
Yes
approved No   S3‑173278
    S3‑173306 pCR: Calculation of SUCI Qualcomm Incorporated pCR Approval Yes
Yes
withdrawn Yes   S3‑172503
    S3‑173384 5G privacy: SUCI calculation Gemalto, G&D, Morpho, Oberthur, Vodafone pCR Approval Yes
Yesconclusion: merged into S3-173436
merged No    
    S3‑173230 Discussion on the use of home network public key LG Electronics discussion Endorsement Yes
Yes
noted No    
    S3‑173231 Inputs of SUCI construction in annex C LG Electronics pCR Approval Yes
YesGemalto: overlap with Ericsson contribution? Ericsson: extra separator on input here in this proposal NT DOCOMO: fixed string not useful
rejected No    
    S3‑173069 Remove editor note related to SIDF location CATT pCR Approval Yes
Yesconclusion: will be merged into S3-173446
merged No    
    S3‑173229 SIDF location clarification in subclause 6.1.2 LG Electronics pCR Approval Yes
Yesconclusion: will be merged into S3-173446
merged No    
    S3‑173117 SIDF purpose in initiation of authentication - 2355 Nokia pCR Approval Yes
YesHuawei: do we need to indicate which protection scheme was used?
revised No S3‑173446  
    S3‑173446 SIDF purpose in initiation of authentication - 2355 Nokia, LG, CATT pCR Approval Yes
Yes
approved No   S3‑173117
    S3‑173118 SIDF functionality - was 2356 Nokia pCR Approval Yes
YesInterdigital: unclear why to standardize because it is a deployment issue whether co-location KPN: authentication center is normally the place, you would not like to put it anywhere in the cloud Ericsson: we do not need editor's note Interdigital, Ericsson: we are fine with UDM SA3 chair: what about the proposed changes? Ericsson: "Functionality" would be a new term, normally we talk about function Nokia: SA2 is using "function" in a different way than SA3 Huawei: editor's note should not be in definitions Orange: has problem with note 2 unde 6.8.x SA3 chair: we had several comments to 6.8x and even the question whether this clause is needed at all conclusion: - first definition: use "Function" instead of Functionality, use "This service" instead of "This functionality" - 2nd definition: first part kept until e.g., MSIN), rest will be removed - editors' note under definitions will be removed - change in abbreviations will be cancelled
revised No S3‑173447  
    S3‑173447 SIDF functionality - was 2356 Nokia pCR Approval Yes
Yes
approved No   S3‑173118
    S3‑173102 Annex C.3 (SUCI, ECIES scheme normative Annex) Ericsson pCR Approval Yes
YesBT: do we have these profile names like top secret ?
revised No S3‑173450  
    S3‑173450 Annex C.3 (SUCI, ECIES scheme normative Annex) Ericsson pCR Approval Yes
YesVodafone: editor's notes should not be used as blocking technique
approved No   S3‑173102
    S3‑173260 pCR to 33.501 - SUPI Encryption Protocol: issues identified by ETSI SAGE VODAFONE Group Plc pCR Approval Yes
YesVodafone: we defined 6 curves while Ericsson defined 2, this is the main difference; advantage: people can at least find 2 curves that they are happy with; suggests to merge part with the curves in the Ericsson Tdoc? Qualcomm: we could not have so many curves Orange: would not agree to only NIST curves, so supporting Vodafone conclusion: curve list will be taken over into S3-173450, other parts can be discussed until next SA3 meeting
merged No    
    S3‑173065 Privacy requirement about who define SUPI protection schemes CATT pCR Approval Yes
YesVodafone: we do not support, it's up to the home operator to design so we want the opposite (MME and user are different); also wondering whether you can restrict SA3 chair: anyone supporting this Tdoc? seems there is no support
rejected No    
    S3‑173066 Remove editor note about choosing null-scheme CATT pCR Approval Yes
YesEricsson: fine with the Tdoc except first change Vodafone: it's assuming a solution of public key, you might not have public key because you do SUPI calculation in USIM BT: any validity for public key? SA3 chair: seems this can not be agreed
rejected No    
    S3‑173068 Remove editor note about visited network require null-scheme CATT pCR Approval Yes
YesEricsson: there are more Tdocs on the scheme (S3-173101, S3-173139, S3-173119)
rejected No    
    S3‑173101 Clauses 5.1.5/6.8.1 and Annex C.2 (SUCI - selection of null-scheme) Ericsson pCR Approval Yes
YesSA3 chair: discuss this further offline and see whether some editor's notes can be removed conclusion: merged into S3-173453
merged No    
    S3‑173139 Subscriber Privacy under Home network control Huawei, Hisilicon pCR Approval Yes
YesNTT DOCOMO: first 2 requirements of 6.8.2 could be kept BT: 2nd one could be changed SA3 chair: can discuss further offline
revised No S3‑173453  
    S3‑173453 Subscriber Privacy under Home network control Huawei, Hisilicon, Ericsson, CATT pCR Approval Yes
Yes
approved No   S3‑173139
    S3‑173119 Discussion paper on null-scheme SUCI request by VN Nokia pCR Approval Yes
YesNTT DOCOMO: before we implement the feature we need to figure out which countries would really have a problem BT: is it about countries or is there a finer granularity NCSC: we will not be able to ask all countries' regulators Ericsson: if a country does not allow it, they can handover to 4G NTT DOCOMO: home control on visited network could be retrofit in newer UEs later SA3 chair: we have higher priority topics and this topic seems to need more discussion
rejected No    
    S3‑173115 Requirement on AMF - was 2354 Nokia pCR Approval Yes
Yes
rejected No    
    S3‑173311 Procedure for mandating null-scheme SUCI KPN, Nokia pCR Approval Yes
Yes
not treated No    
    S3‑173310 Adding Null scheme mandatory messages KPN, Nokia pCR Approval Yes
Yes
not treated No    
    S3‑173174 Adding the content on Subscription identification procedure(6.8.4) Huawei, Hisilicon pCR Approval Yes
Yes
not treated No    
    S3‑173123 Resolving editors note on null-SUCI or SUPI for emergency call handling -v1.doc Nokia pCR Approval Yes
Yes
not treated No    
    S3‑173140 Moving UE handling SUCI to SUCI clause Huawei, Hisilicon, China Mobile pCR Approval Yes
Yes
not treated No    
    S3‑173116 SUCI introductionary text merging 6.8.1 and 6.8.2 - merge 2362 and 2354 Nokia, KPN pCR Approval Yes
Yes
not treated No    
    S3‑173121 UDM requirements - key management and privacy - was 2358 Nokia pCR Approval Yes
Yes
not treated No    
    S3‑173120 Privacy related functions in UDM Nokia pCR Approval Yes
Yes
not treated No    
    S3‑173122 Privacy data UDR - split from 2356 Nokia pCR Approval Yes
Yes
not treated No    
    S3‑173067 Remove editor note about how to connect to 5G network CATT pCR Approval Yes
Yes
not treated No    
    S3‑173071 Solution for raw public key provisioning CATT pCR Approval Yes
Yes
not treated No    
7.2.15 Others S3‑173029 Reply LS on applicability of service based interface for legacy core network elements S2-178205 LS in   Yes
Yesconclusion: no LS answer
noted No    
    S3‑173007 LS on secure storage and processing of subscription credentials S1-173475 LS in   Yes
YesLS was seen in the previous ad hoc, we will come back to it later this week conclusion: LS answer iss postponed
postponed No    
    S3‑173008 Update on the status of the work on SSP (Smart Secure Platform) ETSI TC SCP LS in   Yes
YesVodafone: LS is out-of-date, we need the latest status conclusion: no LS answer
noted No    
    S3‑173009 NGMN Paper on 5G End-to-end Architecture Framework NGMN LS in   Yes
Yesconclusion: no LS answer
noted No    
    S3‑173013 Reply LS on PLMN and RAT selection policies for roaming C1-174589 LS in   Yes
YesVodafone: they ignored a part of our LS; is creating a secure channel to MME which is not secure BT: also undear which system is considered Deutsche Telekom: supports Vodafone SA3 chair: so we need to send them an answer that we do not want this as this is wrong; do we have a related discussion Tdoc or LS reply? Orange: we clarified that their previous LS was not clear and as answer they just send us references to these Tdocs Samsung: if they come with the solution then we need to secure it Ericsson: suggests to wait a bit with our LS answer Orange: first question was not answered, so we need to send a reply LS to ask for clarification on 2 points Huawei: we could wait a bit with the answer KPN: we have not yet seen requirements from SA1 (answer to S2-175286) Orange: we need to avoid that CT1 starts to work with wrong assumptions Qualcomm: acc. to the WI code, CT1 is working here on 5G phase 1 conclusion: SA3 chair: we will come back later this week on this after offline discussion: Orange: will write an LS answer (termination in the UE, why OTS does not work, no SA3 agreement to agree this for REL-15), create a living document
replied to No    
    S3‑173426 Reply LS to C1-174589 = S3-173013 on PLMN and RAT selection policies for roaming (to: CT1; cc: CT6, SA3-LI, SA2, CT3; contact: Orange) SA3 LS out Approval Yes
YesLS was sent out on Thu afternoon of SA3 #89
approved No    
    S3‑173509 Reply LS to C1-174589 = S3-173013 on PLMN and RAT selection policies for roaming (C4-176362; to: CT1, SA3; cc: CT3, SA2; contact: Huawei) CT4 LS in   Yes
Yesconclusion: no LS answer
noted No    
    S3‑173515 Reply LS to C1-174589 = S3-173013 on PLMN and RAT selection policies for roaming (C3-176332; to: CT1; cc: SA2, SA3, CT4; contact: Huawei) CT3 LS in   Yes
Yesconclusion: no LS answer
noted No    
    S3‑173235 Discussion paper for steering of roaming Huawei, Hisilicon discussion Discussion Yes
Yesproposal: to choose one of the two solutions as baseline to provide end to end security for the delivery of the list of PLMN/access technology combinations, and approve the corresponding companion pCR (S3-173236/S3-173237) Vodafone: this is the 3rd meeting where we see that they based the document on the same mistake Orange: does not agree on observation 2 and 3 Qualcomm: we had papers in the past supporting go in the direction of solution 2 (using K_AUSF) Vodafone: we should have a study on this Gemalto: does not support solution 2, MME or UICC needs to be discussed first
noted No    
    S3‑173427 PLMN and RAT selection policies for roaming Orange discussion discussion Yes
Yesendorsed skeleton for the living document Vodafone: concerned about having too many living documents (difficult to trace) MCC: you could have a TR under the 5G WI (revised WI) and use this to store topics of related living documents SA3 chair: let's keep living document for the moment and think about the possibility to create a TR
revised No S3‑173482  
    S3‑173482 Living document on PLMN and RAT selection policies for roaming Orange discussion Endorsement Yes
Yeswill include agreements of SA3 #89 in a lving document
endorsed No   S3‑173427
    S3‑173309 Security for Network Steering of UE in 5GS Qualcomm Incorporated pCR Approval Yes
Yesproposals: 1) Agree to the following proposals 1 to 3 as the SA3 working assumption for securing the network steering information. Proposal #1: Key(s) derived from KAUSF shall be used to protect the network steering information. Proposal #2: Security procedures required at the AUSF to support steering of the UE using the control plane solution after the UE has registered shall be optional for implementation. Proposal #3: The NAS message that carries the steering information shall always include the integrity protected steering information. 2) Approve the below pCR to draft TS 33.501. Vodafone: pCR does not say that this is an addition to what exists already Qualcomm: we could a sentence about this BT: proposal seems to assume 5G as basis so this will not work on 2G/3G etc. Qualcomm: yes, the proposal is just for 5G Vodafone: we can do all this already Qualcomm: using NAS message is new Orange: Vodafone means you need to replace UE by MME; but we do not agree to such a change Qualcomm: we tried to keep it generic Orange: 2nd paragraph of pCR should be removed ("The Ntwork ...") Vodafone: last sentence is not future proof Nokia: has a proposal to rephrase last sentence and proposal 2 is not reflected in pCR Qualcomm: CT1 is looking at solution where update can happen at any time NTT DOCOMO: section 5 is requirement section and not section 6 SA3 chair: we got the information that other groups have not yet developed specs on this Orange: happy to add text in requirements section Ericsson: CT1 has only TR Qualcomm: all agreements that we go in TS are currently in a TR Oberthur: CT is still working on a SI, WI will come in Dec.17 SA3 chair: further offline discussion needed (should we work on this at all?, CT1 work going to spec?, how to document SA3 work?)
revised No S3‑173428  
    S3‑173428 Security for Network Steering of UE in 5GS Qualcomm Incorporated pCR Approval Yes
Yesconclusion: merged into living Tdoc S3-173482
merged No   S3‑173309
    S3‑173236 Protecting network selection list by UDM&ARPF Huawei, Hisilicon pCR Approval Yes
YesOrange: USIM does not keep IK CK KPN: does not want to see a solution that influences authentication SA3 chair: so this is related to solution1 of S3-173235
rejected No    
    S3‑173237 Protecting network selection list by AUSF Huawei, Hisilicon pCR Approval Yes
YesSA3 chair: so this is related to solution2 of S3-173235 Vodafone: up to VPLMN when to do the authentication
rejected No    
    S3‑173022 LS on usage of user plane integrity protection for DRB R2-1712051 LS in   Yes
YesDeutsche Telekom: why would integrity protection be a big problem? Qualcomm: due to the way their interface is working Huawei: was a performance issue (not limited to IOT) Nokia: we need to send an LS answer NTT DOCOMO: we must indicate that we need integrity protection, at what level can be discussed further SA3 chair: so we need to indicate that we need integrity protection and the solution has to be found Qualcomm: we have a reply proposal in SA2 Nokia: SA3 has an action here, and we should not limit it to low rate NTT: for all use cases we need to support integrity protection
replied to No    
    S3‑173420 Reply LS to R2-1712051 = S3-173022 and R2-1714125 = S3-173470 on maximum data rate of user plane integrity protected data (to: RAN2; cc: SA2, RAN3; contact: Qualcomm) SA3 LS out Approval Yes
YesDeutsche Telekom: we will need IPSec on CU-DU anyway Ericsson: UP integrity is currently optional, the core network can decide whether to use it LS was sent out on Thu afternoon of SA3 #89 (note: wrong Tdoc number on the Tdoc)
approved No    
    S3‑173470 LS on maximum data rate of user plane integrity protected data (R2-1714125; to: SA3; cc: SA2; contact: Qualcomm) RAN2 LS in   Yes
YesQualcomm: could reply to this also in S3-173420 (which is a reply to LSin S3-173022) NTT DOCOMO: also use case need to be taken into account Nokia: first agreement: interprets it as minimum 64kbps are offered Ericsson: this is UE side Qualcomm: UE will make an indication and network will make decision on UP integrity SA3 chair: it seems the LS is not clear KPN: seems it is the lowest maximum data rate up to which UP integrity is supported Qualcomm (RAN2): RAN2 will introduce a maximum value, once a new use case is coming up we can bring CRs to RAN2 to allow UP integrity up to a higher data rate NTT DOCOMO: why is this not aligned with QCI values? Qualcomm (RAN2): is a hardware related requirement and granularity is not enough Nokia: we should ask whether/how is the mechanism to increase the data rate that limits UP integrity protection conclusion:: further offline discussion needed
replied to No    
    S3‑173024 LS reply on Support for fake gNB detection mechanisms R4-1711318 LS in   Yes
YesNokia: LS says this is not for REL-15 but there is a pCR related to REL-15? conclusion: no LS answer
noted No    
    S3‑173030 LS on security handling for EPC-5GC interworking S2-178210 LS in   Yes
Yesthere is a draft reply LS to S3-173030 in S3-173349
replied to No    
    S3‑173040 Reply LS from 802.11 to NGMN LS on E2E Architectural Framework IEEE 802.11 LS in   Yes
Yesconclusion: no LS answer
noted No    
    S3‑173406 128-EIA3 for jumbo frames ETSI SAGE LS in   Yes
YesVodafone: originally RAN2 asked about usage of jumbo frames and it seems we could reply now that everything is fine Ericsson: we indicated already that this is ok SA3 chair: so then we do not need to send another one to RAN2 conclusion: no LS answer to ETSI SAGE
noted No    
    S3‑173041 Liaison Statement on 5G Identity and Access Management Requirements NGMN LS in   Yes
YesKPN: was discussed in SA1 NTT DOCOMO: Why is NGMN sending us GSMA LSs? SA3 chair: is the same S3-173409, we will come to this one later conclusion: see S3-173430 instead
withdrawn Yes    
    S3‑173409 Liaison Statement on 5G Identity and Access Management Requirements GSMA LS in   Yes
Yessee S3-173430 instead
withdrawn Yes    
    S3‑173430 Liaison Statement on 5G Identity and Access Management Requirements GSMA LS in   Yes
YesOrange: is this for phase 2? GSMA: SA1 SI will finish by end of REL-16 Orange: is it linked to IMSI? GSMA: has to be linked with subscription Orange: moving of credentials between devices? GSMA: we will leave this to the experts to see what is achievable NTT DOCOMO: is a nice wish list but not realistic to have it by the end of next year BT: would have impact on privacy work conclusion: no LS answer to GSMA
noted No    
    S3‑173407 Liaison Statement reply to 3GPP S3-172175: DESS Update and Requirements for Securing Inter-PLMN Signalling Interfaces in 5G GSMA LS in   Yes
YesEricsson: it seems GSMA wants to have everything they have in 4G without checking impacts KPN: there should be a mechanism to protect fields SA3 chair: do we need to reply to it? KPN: we can also respond when we have done it; there are related papers from Nokia and Deutsche Telekom NTT DOCOMO: we should not break existing business models
replied to No    
    S3‑173433 Reply LS to DESS 11_02 = S3-173407 on DESS Update and Requirements for Securing Inter-PLMN Signalling Interfaces in 5G (to: GSMA FASG DESS; cc: -; contact: KPN) SA3 LS out Approval Yes
Yes
approved No    
    S3‑173050 LS on LI relation to TS 33.501 S3i170462 LS in   Yes
Yesproposal: To be included in TS 33.501 section 5.8: "The security and privacy features specified in the present document shall not preclude or inhibit the operation of LI as specified in TS 33.126." KPN: has a problem with this as it is not possible to see whether requirement is met Vodafone: should be written in positive way SA3 LI chair: formulating it in a positive way would mean to check the 33.501 features KPN: "subject to national regulations" would be acceptable for us SA3 LI chair: not all LI and all privacy requirements can be met at the same time NTT DOCOMO: "up to national regulations" could be added in a similar way as for encryption BT: LI specs were one REL behind, do we get a problem with this? SA3 LI chair: 33.126 is written in a service agnostic way so does not see a problem conclusion: BT will draft a pCR to TS 33.501 in S3-173429, BT will draft an LS reply in S3-173512
replied to No    
    S3‑173512 Reply to: LI relation to TS 33.501 (to: SA3 LI; cc: -; contact: BT) SA3 LS out Approval Yes
Yesconclusion: source field still shows company name, therefore revised
revised No S3‑173531  
    S3‑173531 Reply to S3i170462 = S3-173050 on LI relation to TS 33.501 (to: SA3 LI; cc: -; contact: BT) SA3 LS out Approval Yes
Yes
approved No   S3‑173512
    S3‑173429 LI requirement BT pCR Approval No
Yes
withdrawn Yes    
    S3‑173392 Proposals to restructure TS 33.501 Ericsson discussion   Yes
YesNokia: there is some overlap in clause 6 and 8 NEC: would not like to have the changes NTT DOCOMO: we should get rid of the overlap, but some reasons why the overall structure was done as it is SA3 chair: would like to take a restructuring discussion offline to see how this can be done
revised No S3‑173528  
    S3‑173528 Proposals to restructure TS 33.501 Ericsson discussion - Yes
Yesconclusion: endorsed unseen
endorsed No   S3‑173392
7.3 Mission Critical Security Enhancements (eMCSec) (Rel-15) S3‑173032 LS on signalling plane security for MC system interconnection S6-171458 LS in   Yes
Yes
replied to No    
    S3‑173432 Reply LS to S6-171458 = S3-173032 on signalling plane security for MC system interconnection (to: SA6; cc: -; contact: Motorola Solutions) SA3 LS out Approval Yes
YesNCSC: some filtering may be needed
approved No    
    S3‑173033 LS on providing SIP identities to access a partner MC system S6-171490 LS in   Yes
Yes
replied to No    
    S3‑173411 Reply LS to S6-171490 = S3-173033 on LS on providing SIP identities to access a partner MC system (SCP(17)000190; to: SA6; cc: SA3, CT6, SA1; contact: Orange) ETSI TC SCP LS in   Yes
Yesconclusion: no LS answer
noted No    
    S3‑173452 Reply LS to S6-171490 = S3-173033 on providing SIP identities to access a partner MC system (to: SA6; cc: SA3, ETSI SCP, CT6; contact: Blackberry) SA1 LS in   Yes
Yesconclusion: no LS answer to SA1
noted No    
    S3‑173468 Reply LS to S6-171490 = S3-173033 on providing SIP identities to access a partner MC system (C6-170676; to: SA6; cc: SA3, ETSI SCP, SA1; contact: Blackberry) CT6 LS in   Yes
Yesconclusion: no LS answer
noted No    
    S3‑173434 Reply to S6-171490 = S3-173033 on providing SIP identities to access a partner MC system (to: SA6; cc: SA1; contact: NCSC) SA3 LS out Approval Yes
YesOrange: having multiple ISIMs may be problematic and 5. will need some rewording; SA3 chair: it may be good to discuss this draft LS first offline Motorola Solutions: some numbering needs to fixed Oberthur: SA1 and CT4 action needed Orange: no they replied already
approved No    
    S3‑173282 [eMCSEC] Addition of Element for Authenticating Requests (EAR) to TS 33.180. NCSC CR Agreement Yes
Yes
revised No S3‑173448  
    S3‑173448 [eMCSEC] Addition of Element for Authenticating Requests (EAR) to TS 33.180. NCSC CR Agreement Yes
YesNCSC: 4 group messages: some correction was needed compared previous revision NCSC: since S3-173287 is not yet accepted we still need to have some offline discussion on this Huawei: no boxes ticked? NCSC: it is just affecting application
agreed No   S3‑173282
    S3‑173283 [eMCSEC] Addition of KMS Requests to TS 33.180 to support KMS Discovery NCSC CR Agreement Yes
Yes
agreed No    
    S3‑173390 [eMCSEC] Addition of Security Gateway to TS 33.180 NCSC CR Agreement Yes
YesMCC: CR includes no change (all changes must be visible with rev marks!)
revised No S3‑173449  
    S3‑173449 [eMCSEC] Addition of Security Gateway to TS 33.180 NCSC CR Agreement Yes
YesNCSC: there are still some comments from Motorola Solutions to be solved
agreed No   S3‑173390
    S3‑173456 Exception request sheet for REL-15 WI eMCSec stage 2 NCSC, Motorola Solutions WI exception request Agreement Yes
Yesextension of 1 quarter needed as there are still SA6 parts open NCSC: intention is to report 80% to SA #78
agreed No    
    S3‑173352 Update of clause 6.6 on key hierarchy Ericsson pCR Approval No
Yes
withdrawn Yes    
    S3‑173353 Update of clause 6.7 on security contexts Ericsson pCR Approval No
Yes
withdrawn Yes    
    S3‑173354 Update of clause 6.3 skeleton on Security negotiation Ericsson pCR Approval No
Yes
withdrawn Yes    
    S3‑173355 Update for skeleton of clause 8 on Security Procedures between UE and 5G Access Network Functions Ericsson pCR Approval No
Yes
withdrawn Yes    
    S3‑173356 Update of clause 5 skeleton on Security Requirements and Features Ericsson pCR Approval No
Yes
withdrawn Yes    
    S3‑173357 Update of clause 8.1.1.2 ‘5G-RAN key identification‘ in TS 33.501 Ericsson pCR Approval No
Yes
withdrawn Yes    
    S3‑173358 Update of clause 8.1.1.3 ‘5G-RAN key lifetimes‘ in TS 33.501 Ericsson pCR Approval No
Yes
withdrawn Yes    
7.4 Battery Efficient Security for very low Throughput Machine Type Communication Devices (BEST_MTC_Sec) (Rel-15) S3‑173031 Reply LS on LI Requirements for CIoT services including BEST services S3i170239 LS in   Yes
YesVodafone: there are mutually exclusive requirements; we are turning off ciphering and integrity protection is not a problem KPN: we do not switch off encryption over the air conclusion: no LS answer and no action planned
noted No    
    S3‑173051 Collection of editorial changes to BEST TS 33.163 Juniper Networks CR Agreement Yes
YesMCC: no CR number on CR cover Vodafone: NULL is missing an L Juniper: also a reference needs correction/addition
revised No S3‑173459  
    S3‑173459 Collection of editorial changes to BEST TS 33.163 Juniper Networks CR Agreement Yes
YesVodafone: we are still waiting for some CT4 work (confirmation on S6 interface needed), should we have an exception sheet and an LS? We need subset of S6a commands, with separate interface we would not have interaction
agreed No   S3‑173051
    S3‑173460 Exception request sheet for WI BEST_MTC_Sec Vodafone WI exception request Agreement Yes
Yesprovided as target has to be extended Vodafone: CT4 will probably reply "S6a interface is fine" and so we will not need the exception sheet SA3 chair: will you do a CR for SA3 #89 then? Vodafone: editor's note could be removed but Annex will need until next meeting SA3 chair: ok, we can do both next time conclusion: Tdoc was agreed first and then after S3-173522 it was withdrawn
withdrawn Yes    
    S3‑173461 LS on extension of S6x interface for BEST (to: CT4; cc: -; contact: Vodafone) SA3 LS out Approval Yes
YesLS was sent out on Thu afternoon of SA3 #89
approved No    
    S3‑173522 Reply LS to S3-173461 on extension of S6x interface for BEST (C4-176388; to: SA3; cc: -; contact: Vodafone) CT4 LS in   Yes
YesVodafone: so exception request sheet in S3-173460 can be withdrawn and we will bring final SA3 CR next time conclusion: no LS answer
noted No    
7.5 Northbound APIs Security for SCEF - SCS/AS Interworking (NAPS_Sec) (Rel-15) S3‑173264 Security requirements of T8 interface Huawei, Hisilicon CR Agreement Yes
YesMCC: "TS" should not be in spec number field; Tdoc number and CR number missing on CR cover; wrong WI code or agenda item NEC: we have a related Tdoc in S3-173325 conclusion: will be merged into S3-173463
merged No    
    S3‑173325 Security requirement for T8 reference point NEC EUROPE LTD CR Agreement Yes
YesMCC: adding empty sections is not ideal; file name inside zip file does not show Tdoc number Nokia: what is the privacy part? Orange: 2 different requirements; example should be another bullet point/requirement SA3 chair: NEC document is covering Huawei requirements? NEC: yes conclusion: S3-173325 will be revised in S3-173463 (merging into this one also the S3-173264 aspects)
revised No S3‑173463  
    S3‑173463 Security requirement for T8 reference point NEC EUROPE LTD CR Endorsement Yes
Yesconclusion: endorsed and CR will not be sent to SA #78 but will be included in draft CR for next SA3 meeting
endorsed No   S3‑173325
    S3‑173266 Authentication and transmission protection for T8 interface Huawei, Hisilicon CR Agreement Yes
YesMCC: "TS" should not be in spec number field; Tdoc number and CR number missing on CR cover; wrong WI code or agenda item Samsung: we have a related Tdoc in S3-173363 conclusion: discuss offline what can be merged from S3-173266 into S3-173464
merged No    
    S3‑173363 Security Mechanism for T8 interface Samsung CR Agreement Yes
YesHuawei: we could also merge S3-173266 and S3-173363 SA3 chair: as the Tdocs are different a merging will not be easy Samsung: one big difference is that credentials are very much open which we do not want Nokia: supports Samsung proposal Ericsson: an agreed CR from NEC added an empty section, it would be better that the former CR is not adding the empty section BT: reference need to be checked
revised No S3‑173464  
    S3‑173464 Security Mechanism for T8 interface Samsung CR Endorsement Yes
Yesconclusion: CR is just endorsed and will not be provided to SA #78 but it will be included in the draft CR S3-173465
endorsed No   S3‑173363
    S3‑173267 Authorization of SCS/AS to send requests for the 3GPP Network Entity Huawei, Hisilicon CR Agreement Yes
YesMCC: "TS" should not be in spec number field; Tdoc number and CR number missing on CR cover; wrong WI code or agenda item Ercisson: adding title twice Nokia: cridentials to be corrected Samsung: "preconfigured" unclear conclusion: 5.5.2 headline and "After the authentication, SCEF determines whether the SCS / AS is authorized to send requests for the 3GPP Network Entity." will be merged into S3-173464
merged No    
    S3‑173465 Northbound APIs Security for SCEF - SCS/AS Interworking Huiawei, Hisilicon, NEC, Samsung draftCR Agreement Yes
YesThis will be a working draft CR
endorsed No    
7.6 Other work areas                      
7.6.1 SAE/LTE Security S3‑173021 LS on encrypting broadcasted positioning data R2-1712031 LS in   Yes
YesSA3 VC: we plan to reply to this? seems we have 2 LSout on this (S3-173297 and S3-173374)
replied to No    
    S3‑173439 Reply to R2-1712031 = S3-173021 on encrypting broadcasted positioning data (to: RAN2; cc: RAN3, SA2; contact: Ericsson) SA3 LS out Approval Yes
Yesboth proposals (from Ericsson & Qualcomm) will be attached to this LS
approved No    
    S3‑173296 Ciphering of Broadcast Assistance Data Qualcomm Incorporated discussion Endorsement Yes
YesEricsson: shouldn't we use different keys? Qualcomm: is it worth the extra complexity Ericsson: worried about limiting IV SA3 VC: let's see the alternative in S3-173373 and then discuss them together
noted No    
    S3‑173373 Discussion on details for encryption of LTE Positioning broadcast Ericsson discussion Discussion Yes
YesEricsson: suggests to send the Qualcomm and Ericsson proposals to RAN2 and let RAN2 decide as this is not really an SA3 issue SA3 VC: is this acceptable to send an LS to RAN2? Qualcomm: we should explain the MAC issue Nokia: why should RAN2 chose and not SA3? Ericsson: no security considerations anymore, RAN2 could decide (e.g. looking at aspects on quick calculation, large data) Nokia: we should do an evaluation in SA3 SA3 VC: so from SA3 point of view both proposals are acceptable; what is the RAN2 timeline for this? Ericsson: not much work ongoing at the moment Qualcomm: would be good to get feedback whether counter-mode is acceptable for RAN2
noted No    
    S3‑173297 Draft reply LS to R2-1712031 = S3-173021 on encrypting broadcasted positioning data (to: RAN2; cc: SA2; contact: Qualcomm) Qualcomm Incorporated LS out Approval Yes
YesMCC: source is already indicated as SA3; compare S3-173374 See instead S3-173439
withdrawn Yes    
    S3‑173374 Draft reply LS to R2-1712031 = S3-173021 on encrypting broadcasted positioning data (to: RAN2, SA2; cc: RAN3; contact: Ericsson) Ericsson LS out Approval Yes
YesMCC: source says already SA3; compare S3-173297 See instead S3-173439
withdrawn Yes    
    S3‑173375 Living document for ciphering of LTE positioning broadcast Ericsson discussion Approval Yes
Yes
noted No    
    S3‑173080 Clause 7.2.4.4 (rectifying use of HASH_MME at NAS_SMC in Rel-14) Ericsson CR Agreement Yes
Yes
agreed No    
    S3‑173081 Clause 7.2.4.4 (Rectifying use of HASH_MME at NAS_SMC in Rel-15) Ericsson CR Agreement Yes
Yes
agreed No    
    S3‑173191 Address EN for the RLFs for UEs doing user plane over control plane using NAS level security Huawei, Hisilicon CR Agreement Yes
YesSA3 VC: ME and Core Network boxes need to be ticked
revised No S3‑173440  
    S3‑173440 Address EN for the RLFs for UEs doing user plane over control plane using NAS level security Huawei, Hisilicon CR Agreement Yes
YesQualcomm: we had the same CR S3-173298 under different AI SA3 VC: S3-173298 can be withdrawn then and S3-173440 is agreed unseen
agreed No   S3‑173191
    S3‑173321 Improve and clarify texts under NOTE1 under clause 7.2.4.4 (Rel-14) NEC EUROPE LTD CR Agreement Yes
YesMCC: WI code missing on CR cover
revised No S3‑173415  
    S3‑173415 Improve and clarify texts under NOTE1 under clause 7.2.4.4 (Rel-14) NEC EUROPE LTD CR Agreement Yes
YesQualcomm: Note 1 text needs correction (*the Attach Request and the TAU Request" needs to be replaced in first sentence) SA3 VC: change "may" into "could" in Note 2 two times; in Note 1: remove rest "menaing that the .."
revised No S3‑173441 S3‑173321
    S3‑173441 Improve and clarify texts under NOTE1 under clause 7.2.4.4 (Rel-14) NEC EUROPE LTD CR Agreement Yes
Yesconclusion: agreed unseen
agreed No   S3‑173415
    S3‑173322 Improve and clarify texts under NOTE1 under clause 7.2.4.4 (Rel-15) NEC EUROPE LTD CR Agreement Yes
YesMCC: WI code missing on CR cover
revised No S3‑173416  
    S3‑173416 Improve and clarify texts under NOTE1 under clause 7.2.4.4 (Rel-15) NEC EUROPE LTD CR Agreement Yes
Yessame changes needed as for S3-173415
revised No S3‑173442 S3‑173322
    S3‑173442 Improve and clarify texts under NOTE1 under clause 7.2.4.4 (Rel-15) NEC EUROPE LTD CR Agreement Yes
Yesconclusion: agreed unseen
agreed No   S3‑173416
7.6.2 IP Multimedia Subsystem (IMS) Security                      
7.6.3 Network Domain Security (NDS)                      
7.6.4 UTRAN Network Access Security                      
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‑173458 Correction to MIKEY Key parameters NCSC, Motorola, Airwave 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)                      
7.6.14 Security Aspects of Narrowband IOT (CIoT) S3‑173010 LS/o on Security Requirements and Framework of Using Identity-Based Cryptography Mechanisms in Internet of Things ITU-T LS in   Yes
YesVodafone: SA1 should have this LS also in copy conclusion: no LS answer
noted No    
    S3‑173011 LS on “Security Requirements and Framework for Narrow Band Internet of Things” ITU-T LS in   Yes
YesSA3 chair: so we could send them a reply informing them about what we have done
replied to No    
    S3‑173471 Reply to ITU-T SG17-LS66 = S3-173011 on Security Requirements and Framework for Narrow Band Internet of Things (to: ITU-T SG17; cc: SA; contact: China Unicom) SA3 LS out Approval Yes
Yes
approved No    
    S3‑173019 LS on Early Data Transmission R2-1711978 LS in   Yes
Yes
replied to No    
    S3‑173014 Reply LS on Early Data Transmission C1-174595 LS in   Yes
Yesconclsuion: no LS answer
noted No    
    S3‑173015 Reply LS on Early Data Transmission S2-178180 LS in   Yes
Yesconclsuion: no LS answer
noted No    
    S3‑173169 Discussion on Security Issues with Early Data Transmission Intel Corporation (UK) Ltd discussion Discussion Yes
YesIntel: there are Qualcomm (3295) and Ericsson (3387)
noted No    
    S3‑173168 Draft reply LS to R2-1711978 = S3-173019 on Early Data Transmission (to: RAN2; cc: SA2, CT1; contact: Intel) Intel Corporation (UK) Ltd LS out Approval Yes
YesMCC: source is already SA3; compare S3-173387 conclusion: will be covered in S3-173472
merged No    
    S3‑173295 Discussion on a response to S3-173019/R2-1711978 on Early data transmission Qualcomm Incorporated discussion Endorsement Yes
Yes
noted No    
    S3‑173387 Draft reply LS to R2-1711978 = S3-173019 on Early Data Transmission (to: RAN2; cc: -; contact: Ericsson) Ericsson LM LS out Approval Yes
YesMCC: Tdoc is not an LSout as it does not use the LSout template; compare S3-173168 Ericsson: Q1 and Q2 are resolved (no security issue), for Q3 Intel does not agree Intel: we are in line from security perspective but we ask why Ericsson: for Q5 we of course prefer Ericsson solution but would like to hear others Qualcomm: on Q5 we would like to see some authorization to the UE Ericsson: does not agree with this Huawei: does not support to send NCC, is not necessary Ericsson: RAN2 is asking whether there is a security issue
revised No S3‑173472  
    S3‑173472 Reply LS to R2-1711978 = S3-173019 on Early Data Transmission (to: RAN2; cc: RAN3, SA2, CT1; contact: Ericsson) SA3 LS out Approval Yes
Yes
approved No   S3‑173387
    S3‑173298 Removing editor’s note on calculation of UL_NAS_MAC and DL_NAS_MAC Qualcomm Incorporated CR Agreement Yes
Yes
withdrawn Yes    
    S3‑173299 Security for the RLFs for UEs doing user plane over control plane using NAS level security for Rel-15 specification Qualcomm Incorporated CR Agreement Yes
YesMCC: wrong rev 2 on CR cover (which should be rev -) Qualcomm: this is actually a mirror CR that was forgotten in a previous meeting (Dali)
revised No S3‑173473  
    S3‑173473 Security for the RLFs for UEs doing user plane over control plane using NAS level security for Rel-15 specification Qualcomm Incorporated CR Agreement No
Yes
agreed No   S3‑173299
    S3‑173410 Reply LS on Early Data Transmission S2-178180 LS in   Yes
Yes
withdrawn Yes    
7.6.15 New GPRS algorithms for EASE (EASE_ALGOs_SA3) (Rel-13)                      
7.6.16 Support of EAP Re-Authentication Protocol for WLAN Interworking (ERP) (Rel-14)                      
7.6.17 Security Assurance Specifications (SCAS-SA3, SCAS_PGW, SCAS_eNB) S3‑173049 Summary for WI SCAS NTT DOCOMO WI summary Endorsement Yes
YesSA3 delegates are requested to review and to provide comments to the Tdoc author
noted No    
    S3‑173399 WI Summary of SCAS DOCOMO Communications Lab. WI summary Endorsement No
Yes
withdrawn Yes    
7.6.18 Security aspect of architecture enhancements for LTE support of V2X services (V2XLTE-Sec)                      
7.6.19 Security of the Mission Critical Service (MCSec) S3‑173054 Fix inter-domain IdM token exchange procedure Motorola Solutions Germany CR Agreement Yes
Yes
revised No S3‑173417  
    S3‑173417 Fix inter-domain IdM token exchange procedure Motorola Solutions Germany CR Agreement Yes
Yes
agreed No   S3‑173054
    S3‑173059 Fix client check during GMK provisioning Motorola Solutions Germany CR Agreement Yes
Yes
revised No S3‑173421  
    S3‑173421 Fix client check during GMK provisioning Motorola Solutions Germany CR Agreement Yes
Yes
agreed No   S3‑173059
    S3‑173284 [MCSEC] Clarification on validating GMS URI on receipt of GMK NCSC CR Agreement Yes
Yesconclusion: merged into S3-173421
merged No    
    S3‑173060 Alignment with MuSiK Stage 3 in CT1 specs 24.379 and 24.481 Motorola Solutions Germany CR Agreement Yes
Yes
revised No S3‑173424  
    S3‑173424 Alignment with MuSiK Stage 3 in CT1 specs 24.379 and 24.481 Motorola Solutions Germany CR Agreement Yes
Yes
agreed No   S3‑173060
    S3‑173055 Group config I_MESSAGE clarification Motorola Solutions Germany CR Agreement Yes
Yes
withdrawn Yes    
    S3‑173056 GMK over SIP and HTTP Motorola Solutions Germany CR Agreement Yes
Yes
withdrawn Yes    
    S3‑173058 Fix media security for private call Motorola Solutions Germany CR Agreement Yes
Yes
agreed No    
    S3‑173057 Fix reference to 33.179 Motorola Solutions Germany CR Agreement Yes
YesMotorola: 33.179 ended in REL-13, in REL-14 we have 33.180
agreed No    
    S3‑173130 Group key distribution enhancement Motorola Solutions Germany CR Agreement Yes
Yes
revised No S3‑173422  
    S3‑173422 Group key distribution enhancement Motorola Solutions Germany CR Agreement Yes
YesNCSC: this is a correction in REL-14 (to allow the REL-15 feature, see S3-173130 under AI 7.3), we also have this error in REL-13 and will need to do a REL-13 33.179 CR (see S3-173458 under AI 7.6.11)
agreed No   S3‑173130
7.6.20 Other work items S3‑173034 LS on CAPIF security aspects S6a170383 LS in   Yes
YesSA3 chair: there is a corresponding WID proposal in S3-173367 conclusion: no LS answer
noted No    
    S3‑173367 New WID on Security Aspects of Common API Framework Samsung WID new Agreement Yes
YesMotorola Solutions and Interdigital support the WI Huawei: fears that we may duplicate and not end up with a TS Nokia: harmonization should be understood as an attempt Huawei: we should not end up with 2 different mechanisms for the same SA3 chair: yes, 2 WGs working on this requires that we take this into account CMCC: wants to cosign Intel, LG: also support the WI conclusion: revised to add more supporters
revised No S3‑173498  
    S3‑173498 New WID on Security Aspects of Common API Framework Samsung WID new Agreement Yes
Yes
agreed No   S3‑173367
    S3‑173064 Proof of Concept PKI Implementation for NodeB Authentication AT&T, MITRE, Interdigital discussion Decision Yes
Yesproposal: A Study Item Description (SID) or Work Item Description (WID) should be created for the addition of functionality to support the use of PKI in special use cases to protect certain AS/NAS messages in 5G. Interdigital: this is for an isolated system, this is to lock out rogue systems completely Ericsson: thought that we were mitigating this issue already NTT DOCOMO: this is for LTE? At the moment we are very busy and so coming with this at a different time would be better; not sure that there is a business case Vodafone: same view on timing and a SI would be more appropriate than a WI MITRE: has related Tdoc in S3-173035 conclusion: can bring a proposal in the future again
noted No    
    S3‑173271 IoT botnet detection and dismantling China Mobile discussion   Yes
Yesproposal: to discuss and study the IoT botnets, and provide efficient solutions to stop IoT devices services when large scale devices are compromised. KPN: supports a later SI Vodafone: agrees with KPN but not before mid 2018 BT: worried about (1) Ericsson: not clear what SA3 could standardize for this SA3 chair: people are positive to study this in the future but not now
noted No    
    S3‑173274 Malicious Internet Voice Systems detection China Mobile discussion   Yes
YesNokia: we had a couple of SIs and WIs on this so suggests to look into the corresponding documentation BT: suggests to be a bit more careful with the language
noted No    
    S3‑173324 Editorial in TS 33.187 NEC EUROPE LTD CR Agreement Yes
YesMCC: Tdoc number missing in file name inside zip file
revised No S3‑173474  
    S3‑173474 Editorial in TS 33.187 NEC EUROPE LTD CR Agreement Yes
Yes
agreed No   S3‑173324
    S3‑173368 Security Aspects of Common API Framework for 3GPP Northbound APIs Samsung other   Yes
Yesis actually a draft TS skeleton related to new WI S3-173498
endorsed No    
    S3‑173369 pCR on CAPIF Security requirements Samsung other   Yes
Yes
postponed No    
    S3‑173370 pCR on CAPIF security within PLMN Trust Domain Samsung other   Yes
Yes
postponed No    
    S3‑173372 pCR on CAPIF Security mechanism for CAPIF-1e Samsung other   Yes
Yes
postponed No    
    S3‑173532 WI summary ERP Orange WI summary Endorsement Yes
YesSA3 delegates are requested to review and to provide comments to the Tdoc author
noted No    
8 Studies                      
8.1 Study on Mission Critical Security Enhancements (FS_MC_Sec) (Rel-14) S3‑173285 [FS_MC_SEC] Update to EAR (Solution #1.6) in TS 33.880 NCSC pCR Approval Yes
Yes
approved No    
    S3‑173286 [FS_MC_SEC] TR 33.880 EAR Authorisation solution NCSC pCR Approval Yes
Yes
approved No    
    S3‑173287 [FS_MC_SEC] Evaluation of EAR solution in TS 33.880 NCSC pCR Approval Yes
YesMotorola Solutions: there is a related CR as well and we have not yet achieved agreement on this NCSC: suggests to leave some more time for offline discussion conclusion: further offline discussion and we will come back to it later this week
approved No    
    S3‑173061 Interworking key management KI Motorola Solutions Germany pCR Approval Yes
Yes
revised No S3‑173418  
    S3‑173418 Interworking security data transfer Motorola Solutions Germany pCR Approval Yes
Yestitle was corrected
approved No   S3‑173061
    S3‑173062 Interworking key management SIP MESSAGE solution Motorola Solutions Germany pCR Approval Yes
Yes
revised No S3‑173425  
    S3‑173425 Interworking security data MESSAGE solution Motorola Solutions Germany pCR Approval Yes
Yestitle was corrected NCSC: still some KMM to be corrected (to be replaced)
approved No   S3‑173062
    S3‑173063 Interworking key management MCData solution Motorola Solutions Germany pCR Approval Yes
Yes
revised No S3‑173423  
    S3‑173423 Interworking security data MCData solution Motorola Solutions Germany pCR Approval Yes
Yestitle was corrected Motorola Solutions: still some KMM to be replaced
approved No   S3‑173063
    S3‑173388 [eMCSEC] Evaluation of Security Gateways (SeGy) NCSC pCR Approval Yes
Yes
approved No    
    S3‑173454 TR 33.880 v1.6.0 including agreements from SA3 #89 NCSC draft TR Agreement Yes
YesNCSC: TR should go to SA #78 for approval
agreed No    
    S3‑173455 Cover for TR 33.880 NCSC TS or TR cover Agreement Yes
YesNCSC: FS_MC_Sec is 90% complete (as SA6 is still working on it) Note: Presentation to SA #78 will have to be done with v2.0.0 so change of version on S3-173455 is needed before submission to SA #78.
approved No    
8.2 Study on security aspects of enhancements to ProSe UE-to-Network Relay (FS_REAR_Sec) (Rel-15) S3‑173025 LS on FS_REAR study outcome S2-176446 LS in   Yes
Yesconclusion: no LS answer
noted No    
    S3‑173018 Reply LS on FS_REAR study outcome R2-1711861 LS in   Yes
Yesconclusion: no LS answer
noted No    
    S3‑173026 LS on FS_REAR SI conclusion S2-177943 LS in   Yes
Yesconclusion: no LS answer
noted No    
    S3‑173240 Clarification of key issue #7 Huawei, Hisilicon pCR Approval Yes
YesSA3 VC: more authorization than authentication Ericsson: unclear what the key issue is
revised No S3‑173475  
    S3‑173475 Clarification of key issue #7 Huawei, Hisilicon pCR Approval Yes
Yes
approved No   S3‑173240
    S3‑173241 Authentication of eRemote UE during one-to-one communication setup Huawei, Hisilicon pCR Approval Yes
YesKPN: proposal does more than expected, e.g. also sets up secure connection LG: agrees with KPN that topic was authorization by network Ericsson: would be happy to put it in as it is, there is already an editor's note so no need to add another one conclusion: key isssue 7 will be added in introductory text
revised No S3‑173476  
    S3‑173476 Authentication of eRemote UE during one-to-one communication setup Huawei, Hisilicon pCR Approval Yes
Yes
approved No   S3‑173241
    S3‑173242 Remove Editor's Note in subclause 5.4.3 Huawei, Hisilicon pCR Approval Yes
Yes
approved No    
    S3‑173243 Remove Editor's Note in subclause 6.7.2 of Solution #7 Huawei, Hisilicon pCR Approval Yes
Yes
approved No    
    S3‑173244 Remove Editor‘s Note in Solution of Discovery Huawei, Hisilicon pCR Approval Yes
Yes
approved No    
    S3‑173245 Solution of discovery parameters configuration for eRemote UE when dynamic trust relationship establishment is supported Huawei, Hisilicon pCR Approval Yes
YesKPN: structure of the pCR needs a cleanup, also key issue has to be listed; we should solve it in line with SA2 Huawei: will do the cleanup and agrees on the last point
revised No S3‑173478  
    S3‑173478 Solution of discovery parameters configuration for eRemote UE when dynamic trust relationship establishment is supported Huawei, Hisilicon pCR Approval Yes
Yes
approved No   S3‑173245
    S3‑173315 Structure of Conclusions Clause KPN pCR Approval Yes
Yes
approved No    
    S3‑173316 Conclusions for KI #2 KPN pCR Approval Yes
Yes
approved No    
    S3‑173317 Resolving editor's Notes for KI #3 KPN pCR Approval Yes
YesHuawei: suggest to keep first editor's note in 5.3.4 KPN: ok, if Huawei intends to remove it next time conclusion: first editor's note under 5.3.4 will not be deleted and 5.x will not be added
revised No S3‑173479  
    S3‑173479 Resolving editor's Notes for KI #3 KPN pCR Approval Yes
Yes
approved No   S3‑173317
    S3‑173318 Conclusions for KI #3 KPN pCR Approval Yes
YesHuawei: does not agree to the change KPN: we can work on this until next meeting
postponed No    
    S3‑173319 Conclusions for KI #8 KPN pCR Approval Yes
Yes
approved No    
    S3‑173320 Conclusions for KI #9 KPN pCR Approval Yes
Yes
approved No    
    S3‑173339 Conclusions for KI 6 KPN N.V. pCR Approval Yes
Yes
approved No    
    S3‑173477 TR 33.843 v0.3.0 on Study on security aspect of architecture enhancements to Proximity Services (ProSe) User Equipment (UE)-to-network relay Huawei draft TR Agreement Yes
Yescapturing all agreements of SA #89 Nokia: SI has been concluded in other WGs but not in SA3? Huawei: correct, intention is to complete the SI in March 18; 79% complete will be reported to SA #78; intention is to bring the TR for 1-step approval to SA #79
agreed No    
8.3 Study on Long Term Key Update Procedures (FS_LTKUP) (Rel-15) S3‑173037 Threats against LTK and limitations of existing approaches InterDigital, Inc. discussion Decision Yes
YesVodafone: last bullet of Recommendations: only if we select GSMA based solutions Interdigital: related pCR in S3-173039
noted No    
    S3‑173038 Threats against LTK and limitations of existing approaches InterDigital, Inc. discussion Decision No
Yes
withdrawn Yes    
    S3‑173039 LTK Derivation – Key Issue 7.x InterDigital, Inc. pCR Approval Yes
YesOrange: so main threat: key transported between SIM maker and operator; requirement is suggesting a specific solution BT: there should be just one communication link; longterm key should be generated in the system that minimized the number of links Vodafone: we intend to not tie this TR to 5G, it should be applicable to other technologies as well BT: not happy about "while being stored" under 1. in 7.X.1 esp. the (e)UICC should not be there so better remove the text in ( ) Orange: wants an editor's note under requirement: which longterm keys is ffs Vodafone: we could do this next time Gemalto: maybe we can remove the e.g. MCC: general request to respect drafting rules (e.g. no automatic numbering is allowed) otherwise the rapporteur will have to do a lot of reformatting conclusion: first e.g. and ( ) at the end of 1. in 7.x.1 will be removed; 5G will be avoided, editor's note will be added
revised No S3‑173500  
    S3‑173500 LTK Derivation – Key Issue 7.x InterDigital, Inc. pCR Approval Yes
Yes
approved No   S3‑173039
    S3‑173239 pCR to TR33.834 Update long term keys based on PKI Huawei, Hisilicon pCR Approval Yes
YesOrange: is not addressing key issue we have; you are introducing a new long term key SA3 VC: it seems there is a proposal to remove evaluation or to add an editor's note BT: does not agree that it will become a new longterm key Gemalto: would like to add text under evaluation Vodafone: evaluations needs to be extended conclusion: remove 1st sentence of evaluation and discuss other parts of evaluation offline (if no consensus then evaluation will be removed)
revised No S3‑173501  
    S3‑173501 pCR to TR33.834 Update long term keys based on PKI Huawei, Hisilicon pCR Approval Yes
Yes
approved No   S3‑173239
    S3‑173249 pCR to TR33.834 - Updates as agreed at LTKUP conf call VODAFONE Group Plc pCR Approval Yes
YesVodafone: was output of conference call BT: may be in conflict with previously agreed pCR Vodafone: it is not ruling out Gemalto: editor's note for AMF based solution under 9.x.3.1 preferred Orange: 7.1.3: protect instead of change (change is already the solution) and make requirement conditional Vodafone: does not agree to "protect" SA3 VC: discuss this further offline Orange: 8.5: add "(if any)" conclusion: editor's note in 9.x.3.1, (if any) in 8.5, further discussion about 7.1.3 text
revised No S3‑173502  
    S3‑173502 pCR to TR33.834 - Updates as agreed at LTKUP conf call VODAFONE Group Plc pCR Approval Yes
Yes
approved No   S3‑173249
    S3‑173252 pCR to TR 33.834 - addition of DH trnsport options VODAFONE Group Plc pCR Approval Yes
Yes
approved No    
    S3‑173254 pCR to TR33.834 - addition of Public Key, Extended USIM OTA and inline with authentication solutions VODAFONE Group Plc pCR Approval No
Yes
withdrawn Yes    
    S3‑173323 LTKUP: solution proposal Gemalto N.V. pCR Approval Yes
YesOberthur:several keys for one IMSI? Gemalto: only one is active, same as Vodafone Vodafone: conclusions should only be put in when all solutions are in Oberthur: if card is broken all sets will be compromised so we should add "assessment if card is broken" under 9.x.3.6 Oberthur: 2nd bullet under 1. in 9.x.2 is complex and unclear how it is secured Vodafone: can add editor's note under 9.x.3.6 Vodafone: would be happy to provide SI TR for information to SA Orange: we can wait one more cycle Gemalto: agrees that it is too early to bring TR for information BT: would be ok to send the TR to SA Vodafone: anyone planning to bring more solutions? conclusion: 3 editor's notes under 9.x.3.6 about additional risks, removal of conclusion; further offline discussion whether to send TR for information to SA #78
revised No S3‑173503  
    S3‑173503 LTKUP: solution proposal Gemalto N.V. pCR Approval Yes
Yes
approved No   S3‑173323
    S3‑173504 TR 33.834 v0.3.0 collecting agreements of SA3 #89 Vodafone draft TR Agreement No
Yessending out before Thu 7.12.17 eob CET comments before Mon 11.12.17 eob CET agreed version sent out before Wed 13.12.17 eob CET
for email discussion No    
8.4 Study on security aspects of 5G Network Slicing Management (FS_ NETSLICE-MGT_Sec) (Rel-15) S3‑173161 Threats and requirement to KI#1 Huawei & Hisilicon pCR Approval Yes
Yes
revised No S3‑173492  
    S3‑173492 Threats and requirement to KI#1 Huawei & Hisilicon pCR Approval Yes
Yes
revised No S3‑173505 S3‑173161
    S3‑173505 Threats and requirement to KI#1 Huawei & Hisilicon, CATR, China Unicom pCR Approval Yes
Yes
approved No   S3‑173492
    S3‑173167 Adding security threat and requirement for TR 33.811 clause 5.1 CATR pCR Approval Yes
YesTdoc is already included in S3-173492
merged No    
    S3‑173214 Security requirements for Key issue #1: Unauthorized access to Management Exposure Interface China Unicom pCR Approval Yes
YesTdoc is already included in S3-173492
merged No    
    S3‑173160 A key issue proposal on security capability for TR33.811 Huawei & Hisilicon pCR Approval Yes
Yes
revised No S3‑173491  
    S3‑173491 A key issue proposal on security capability for TR33.811 Huawei & Hisilicon pCR Approval Yes
YesHuawei: changes compared to S3-173160: 5.x.1 was rephrased, 5.x.2 if statements, 5.x.3 requirements rewritten Orange: not related to roaming, change HPLMN to MNO Orange: bullets 2-6 under 5.X.3 should be removed and security in first bullet should be removed, is this then in the scope of SA3? BT: "customer" in bullet 4 needs clarification Interdigital: is supporting the Tdoc SA3 VC: it seems at the moment there is no consensus conclusion: talk further offline
revised No S3‑173513 S3‑173160
    S3‑173513 A key issue proposal on security capability for TR33.811 Huawei & Hisilicon pCR Approval No
YesOrange: talked with SA5 delegate that this is beyond SA3 SI
rejected No   S3‑173491
    S3‑173215 Key issue on network slice instance commissioning China Unicom pCR Approval Yes
Yes
not treated No    
    S3‑173216 Key issue on network slice instance creation conflict detection China Unicom pCR Approval Yes
Yes
not treated No    
    S3‑173217 Key issue on network slice instance decommissioning China Unicom pCR Approval Yes
Yes
not treated No    
    S3‑173279 Key issue on protecting the integrity of results of NSI supervision/reporting China Mobile pCR Approval Yes
YesBT: 5.x.3 needs rewording and remove "in transmitting" conclusion: improve 5.x.3 wording
revised No S3‑173506  
    S3‑173506 Key issue on protecting the integrity of results of NSI supervision/reporting China Mobile pCR Approval Yes
Yes
approved No   S3‑173279
    S3‑173280 Key issue on protecting Network Slice Subnet Template China Mobile Group pCR Approval Yes
YesBT: network slice subnet reference to be added SA3 VC: language can be improved; if definition/reference is not available, then we cannot agree the pCR
revised No S3‑173507  
    S3‑173507 Key issue on protecting Network Slice Subnet Template China Mobile Group pCR - Yes
Yes
approved No   S3‑173280
    S3‑173525 TR 33.811 v0.3.0 collecting agreements of SA3 #89 Huawei draft TR Agreement No
Yessending out before Thu 7.12.17 eob CET comments before Mon 11.12.17 eob CET agreed version sent out before Wed 13.12.17 eob CET
for email discussion No    
8.5 Study on Supporting 256-bit Algorithms for 5G (FS_256-Algorithms) (Rel-16) S3‑173247 initial TR33.xxx - Study on the support of 256-bit Algorithms for 5G VODAFONE Group Plc other   Yes
YesNCSC: threats for quantum cryptography? Home Office: is not about cryptography but about quantum computing Ericsson: why are points of SID used as headings but last parts are missing? Should we have editor's notes for this Vodafone: we can have it in the scope SA3 chair: you may want to have editor's notes under the section headings Qualcomm: Proposed requirements should be changed to Potential requirements Vodafone: ok Orange: we should also have a conclusion section Vodafone: this is a study of the threats but will add it
revised No S3‑173462  
    S3‑173462 initial TR33.xxx - Study on the support of 256-bit Algorithms for 5G VODAFONE Group Plc other Endorsement No
Yesnote: The SID for this SI was agreed in the last SA3 meeting in S3-172556 but it is not yet approved by SA and therefore the SID will be submitted to SA #78 for approval. Once the SID is approved a corresponding TR number can be allocated. sending out before Thu 7.12.17 eob CET comments before Mon 11.12.17 eob CET agreed version sent out before Wed 13.12.17 eob CET
for email discussion No   S3‑173247
    S3‑173248 pCR to TR33.xxx - 256 bit keys: Co-existence of different size keys and number and types of algorithms VODAFONE Group Plc other   Yes
YesVodafone: in the phone call different companies offered to fill different sections, this is our input Ericsson: suggests to remove 10.1 Ericsson: type is rather symmetric/asymmetric and not algorithms BT: we seem to fill out the back of the TR without doing the first part (the threats) so section 4 should be filled out first or at least have editor's notes in the later sections that they will checked against the earlier sections Vodafone: we can add editor's note "will be reviewed" conclusion: 10.1 and 10.2 will be removed; add editor's notes and capture all in S3-173462
noted No    
    S3‑173281 pCR to TR 33.xxx - Addition of Quantum threats and countermeasures VODAFONE Group Plc, NIST other   Yes
YesEricsson: some instead of many scientists Vodafone: ok Orange: change "security community" NCSC: add "theoretical" for speedup conclusions: changes will be captured in S3-173462
noted No    
    S3‑173378 Overview of existing GSMA/3GPP symmetric algorithms Ericsson discussion Approval Yes
YesEricsson: text could be added to living document Vodafone: in section 10? BT: correct table colours BT: maybe we should add that not all algorithms are covered Vodafone: not needed conclusion: text will be merged into section 10 of S3-173462
noted No    
    S3‑173381 Overview of NIST Post-Quantum Standardization Ericsson discussion Approval Yes
YesNCSC: do we need all this information? Orange: wonders why we need all this text NIST: we support to include the text conclusion: no consensus to include this in the living document
noted No    
    S3‑173385 Additional Benefit of 256 bit keys U.S. Department of Commerce other   Yes
Yesconclusion: will be included in S3-173462
noted No    
    S3‑173052 Draft LS on the Impacts of increasing the MAC-I (to: RAN2, RAN3; cc: ETSI SAGE; contact: AT&T) InterDigital, AT&T LS out Approval Yes
YesMCC: LS has already source: SA3 Vodafone: as the SI is not yet officially approved, we should better wait with it Qualcomm: answering RAN2/RAN3 to analyze before we did our work is strange so we would be even worried to send the LS next time
postponed No    
8.6 Other study areas                      
9