Tdoc List

2018-04-20 13:57

TDoc Title Source Type For Agenda Avail Treated Decision Wdrn Replaced-by Replaces
S3‑181100 Agenda WG Chairman agenda  
2Approval of Agenda and Meeting Objectives
 		Yes
Yes
 		approved No    
S3‑181101 Report from last SA3 meeting MCC report  
4.1Approval of the report from previous SA3 meeting(s)
 		Yes
Yes
Action item on SCAS: open (to be fulfilled by Anja (Nokia).
Action item on GSMA documents publicly available. MCC commented that Vodafone had assured that all documents referenced were publicly available. MCC will double check this.
 
 
 
 
 		approved No    
S3‑181102 SA3 Work Plan MCC Work Plan  
9.1Review of work plan
 		Yes
Yes
 		noted No    
S3‑181103 Report from last SA meeting WG Chairman report  
4.2Report from SA Plenary
 		Yes
Yes
Docomo: let's use this late drop/ an extended timeline for the N32 interface? some companies want it for Rel-15.
Christine (Ericsson): we depend on CT4 to do this.
The Chair commented that 33.501 will have to be 100% complete in June.
Alf: there is a lot of work pending even if we bring it to 100%.
The Chair commented that if it is not 100% complete SA3 would have to be very clear that it wasn’t complete, so CT groups could be aware of this.
Huawei: there are a couple of SA5 LS referring to some interfaces that need to be secured as well. We would need to have this in Rel-15 as well.
 
 
 		noted No    
S3‑181104 SA3 meeting calendar MCC other  
10Future Meeting Dates and Venues
 		Yes
Yes
 		revised No S3‑181588  
S3‑181105 Work Plan input from Rapporteurs MCC other  
9.2Rapporteur input on status of WID or SID
 		Yes
Yes
 		noted No    
S3‑181106 Reply LS on the status of work on interfaces S5-181455 LS in  
8.3Study on security aspects of 5G Network Slicing Management (FS_ NETSLICE-MGT_Sec) (Rel-15)
 		Yes
Yes
ORANGE: the first point is not answering the question. The most relevant interfaces according to my colleague in SA5 are still in stage 1 phase.
 
 		noted No    
S3‑181107 Statement on urgency of alignment of ETSI SSP with 3GPP release 15 GSMA LS in  
6.10Other Groups
 		Yes
Yes
Postponed for the next meeting, in LaJolla, where the editor's note should be solved.
 
 		postponed No    
S3‑181108 Reply LS on Statement on urgency of alignment of ETSI SSP with 3GPP release 15 SP-180240 LS in  
6.10Other Groups
 		Yes
Yes
 		noted No    
S3‑181109 LS on encrypting broadcasted positioning data and LS on provisioning of positioning assistance data via LPPa for broadcast C1-180643 LS in  
6.13GPP Working Groups
 		Yes
Yes
It was decided to note all three LS and wait for RAN's response.
 		noted No    
S3‑181110 LS on encrypting broadcasted positioning data and on provisioning of positioning assistance data via LPPa for broadcast C4-182150 LS in  
6.13GPP Working Groups
 		Yes
Yes
 		noted No    
S3‑181111 LS on encrypting broadcasted positioning data and LS on provisioning of positioning assistance data via LPPa for broadcast S2-182415 LS in  
6.13GPP Working Groups
 		Yes
Yes
 		noted No    
S3‑181112 LS on one step MO SMS procedure C1-181759 LS in  
7.2.15Incoming and outgoing LSes
 		Yes
Yes
 		replied to No    
S3‑181113 LS on a potential USIM solution for PLMN and RAT selection policies for roaming C6-170696 LS in  
7.7PLMN RAT selection (Steering of Roaming)
 		Yes
Yes
 		noted No    
S3‑181114 Reply LS on PLMN and RAT selection policies for roaming S2-182723 LS in  
7.7PLMN RAT selection (Steering of Roaming)
 		Yes
Yes
Already taken into account.
 
 		noted No    
S3‑181115 NGMN Paper on 5G End-to-End Architecture Framework NGMN LS in  
7.2.15Incoming and outgoing LSes
 		Yes
Yes
BT: The sections on Network slicing, CU/DU split are worth checking out.
The Chair encouraged companies to review this document.
 
 		noted No    
S3‑181116 5G Security – Package 3: Mobile Edge Computing / Low Latency / Consistent User Experience Updated version NGMN LS in  
7.2.15Incoming and outgoing LSes
 		Yes
Yes
 		noted No    
S3‑181117 UE capability related to integrity protection of DRBs R2-1804056 LS in  
7.2.15Incoming and outgoing LSes
 		Yes
Yes
Related discussion in 309.
 
 		postponed No    
S3‑181118 LS on Security aspects of supporting LTE connected to 5GC R2-1804108 LS in  
7.2.15Incoming and outgoing LSes
 		Yes
Yes
 		replied to No    
S3‑181119 LS on security for inactive state R2-1804136 LS in  
7.2.15Incoming and outgoing LSes
 		Yes
Yes
 		replied to No    
S3‑181120 Reply LS on EDT procedures and AS NAS interaction R3-181573 LS in  
6.13GPP Working Groups
 		Yes
Yes
 		noted No    
S3‑181121 LS on secured Signalling-only connection RP-180590 LS in  
7.2.4AS security
 		Yes
Yes
Tdoc 181 addresses this.
 
 		replied to No    
S3‑181122 Reply LS on clarification on Restricted Operator Services S2-181407 LS in  
6.13GPP Working Groups
 		Yes
Yes
Qualcomm: Legacy UEs will not accept this RLOS access. We agree with SA2.
It was agreed to postpone this LS to the August meeting.
There is an Study Item on this in tdoc 185.
 
 		postponed No    
S3‑181123 LS response on User Plane Security Policy S2-182787 LS in  
7.2.15Incoming and outgoing LSes
 		Yes
Yes
 		noted No    
S3‑181124 LS to BBF on general status of work S2-183036 LS in  
6.13GPP Working Groups
 		Yes
Yes
Marcus (Huawei) commented that there was a related WID on this in tdoc 216.
 
 		noted No    
S3‑181125 LS on Guidance on UE WiFi MAC Address inclusion in LTE Positioning Protocol SP-180234 LS in  
6.13GPP Working Groups
 		Yes
Yes
 		noted No    
S3‑181126 Section 8, Size of the integrity protection tag MAC-I Vodafone, AT&T, MITRE, NIST, InterDigital, TCG pCR Approval
8.5Study on Supporting 256-bit Algorithms for 5G (FS_256-Algorithms) (Rel-16)
 		Yes
Yes
NCSC and Ericsson wanted to clarify that 8.z was not the conclusion of the specification.
Vodafone: remove reference to ETSI SAGE.
 
 
 		revised No S3‑181560  
S3‑181127 Co-existence of different size keys and MAC-I tags AT&T, Vodafone, NIST, MITRE, InterDigital, TCG pCR Approval
8.5Study on Supporting 256-bit Algorithms for 5G (FS_256-Algorithms) (Rel-16)
 		Yes
Yes
KPN: How do you secure against bidding down when having 128 and 256 bits?
Vodafone: this requires further investigation.
 
 		revised No S3‑181561  
S3‑181128 TCG progress report InterDigital, Inc. report Information
6.6TCG
 		Yes
Yes
1. TCG – Highlights
        • New/modified work items
            • none
        • Publication of new or revised deliverables (mostly incremental changes from the status reported at SA3#90)
o TCG Device Identifier Composition Engine – published March 2018
o TCG SNMP MIB for TPM-based Attestation – public review April 2018
o TCG PC Client Platform Reset Attack Mitigation v1.1 – public review March 2018
o TCG Protection Profile PC Client Specific TPM v1.1 – public review March 2018
o TCG Guidance for Securing Network Equipment – published January 2018
o TCG Trusted Mobility Solutions Use Cases v2 – public review January 2018
o TCG Trusted Software Stack (TSS) specs – public review January 2018
o TCG TPM 2.0 Automotive Thin Profile v1.1 – public review January 2018
o TCG Storage Interface Interactions (SIIS) – public review January 2018
2. Meetings
TCG Members Meeting in San Diego, CA – 18-22 June 2018
TCG Members Meeting in Lisbon, PT – 15-18 October 2018
MPWG meets every Thursday at 10-11 ET
TMS WG meets every Monday and Friday at 12-13 ET
 		noted No    
S3‑181129 Use of PKI to Mitigate Vulnerabilities in 3GPP Networks AT&T, MITRE, Interdigital, TCG discussion Discussion
7.2.14Privacy
 		Yes
Yes
 		noted No    
S3‑181130 33.834 - References InterDigital, Inc. pCR Approval
8.4Study on Long Term Key Update Procedures (FS_LTKUP) (Rel-15)
 		Yes
Yes
 		merged No S3‑181525  
S3‑181131 Solution #6 Editor’s Note resolution InterDigital, Inc. pCR Approval
8.4Study on Long Term Key Update Procedures (FS_LTKUP) (Rel-15)
 		Yes
Yes
 		revised No S3‑181525  
S3‑181132 USIM 5G security parameters storage trigger ZTE Corporation CR Approval
7.2.6Security context
 		Yes
Yes
Qualcomm didn’t agree with this CR.
Gemalto: number of entries for 5G parameters is up to CT6.
 
 		not pursued No    
S3‑181133 Update clause reference for key identification ZTE Corporation CR Approval
7.2.2Key derivation
 		Yes
Yes
 		merged No S3‑181434  
S3‑181134 Second RR protection for multiple registration in same PLMN ZTE Corporation CR Approval
7.2.5NAS security
 		Yes
Yes
Ericsson preferred to have their contribution in 308, and considered this to be misplaced, a bit of an overload.
 
 
 		merged No S3‑181547  
S3‑181135 Discussion on authentication and NAS SMC handling with race condition ZTE Corporation discussion Endorsement
7.2.5NAS security
 		Yes
Yes
Ericsson on proposal one: why including ABBA in the transferred context? We prefer to remove this part.
Ericsson wanted to avoid starting authentication in one AMF and terminating it in another.
Qualcomm found the first proposal wrong for the 3GPP-only case.
Ericsson: this case is valid when an UE in a non 3GPP network goes into a 3GPP network during the authentication procedure. It's better to finish the initial auth in the initial leg than starting the authentication again.
Qualcomm: proposal one does not work when there is no multi-NAS, so I would like to include this.
Docomo: Proposal 1189 would avoid proposal altogether. Ericsson didn’t agree with this.
On proposal two:
Ericsson didn't think this was needed, it is already covered somewhere else. Qualcomm and Nokia either.
ZTE: How to procceed with NAS SMC multiple registration should be decided before continuing with proposal two.
There wasn't support for proposal two.
On proposal three:
Ericsson wanted to remove the inclusion of the derivation parameter in the transferred context.Qualcomm also wanted to clarify that this proposal was for multi-NAS only.
 
 
 		revised No S3‑181548  
S3‑181136 Rules on concurrent running of authentication and NAS SMC procedure ZTE Corporation CR Approval
7.2.5NAS security
 		Yes
Yes
Ericsson didn’t agree with the restructuring.
 
 		revised No S3‑181549  
S3‑181137 Remove redundant description on SN name construction ZTE Corporation CR Approval
7.2.2Key derivation
 		Yes
Yes
KPN didn’t agree with removing the text.
 
 		not pursued No    
S3‑181138 Remove of K_AMF_CI ZTE Corporation CR Approval
7.2.3Mobility
 		Yes
Yes
 		revised No S3‑181513  
S3‑181139 Remove EN for initial NAS message protection ZTE Corporation CR Approval
7.2.5NAS security
 		Yes
Yes
Ericsson: keep only the last two changes.
 
 		revised No S3‑181544  
S3‑181140 Reconstruct for security handlings ZTE Corporation CR Approval
7.2.3Mobility
 		Yes
Yes
Ericsson: it's too early since it's a major restructuring and there are other documents changing these clauses here.
Better to bring it back during the next meeting.
 
 		not pursued No    
S3‑181141 Add description for key handing during multiple registration in same PLMN ZTE Corporation CR Approval
7.2.5NAS security
 		Yes
Yes
Ericsson: no need for a new clause, there are existing clauses where we can have this. The content is overlapping with other many contributions.
 
 		merged No S3‑181547  
S3‑181142 Add description for NAS and AS algorithm selection ZTE Corporation CR Approval
7.2.3Mobility
 		Yes
Yes
Ericsson,Nokia: this information is already present in the TS.
 
 		not pursued No    
S3‑181143 Modification on UE’s subscribe privacy requirement ZTE Corporation CR Approval
7.2.16Others
 		Yes
Yes
 		revised No S3‑181581  
S3‑181144 Modification on SMS over NAS ZTE Corporation CR Approval
7.2.5NAS security
 		Yes
Yes
 		revised No S3‑181567  
S3‑181145 Modification on NEF requirement ZTE Corporation CR Approval
7.2.16Others
 		Yes
Yes
ORANGE, Nokia didn’t support this.
 
 		not pursued No    
S3‑181146 Modification on NAS SMC procedure ZTE Corporation CR Approval
7.2.5NAS security
 		Yes
Yes
Ericsson: we have no network security policy, we have ABBA. There's a major rewrite here and we have many suggestions to improve this. On the other hand, we don’t dissapprove.
Overlapping with 1319.
 
 
 		revised No S3‑181546  
S3‑181147 Modification on key hierarchy ZTE Corporation CR Approval
7.2.1Key hierarchy
 		Yes
Yes
 		merged No S3‑181434  
S3‑181148 Editorial modification on initial NAS message protection ZTE Corporation CR Approval
7.2.5NAS security
 		Yes
Yes
Ericsson: the description is already in SA2 procedure and it is not security related. Huawei agreed and step 2 modification was removed.
 
 		merged No S3‑181544  
S3‑181149 Modification on gNB’s requirement ZTE Corporation, China Mobile CR Approval
7.2.16Others
 		Yes
Yes
Huawei didn’t support this. BT and ORANGE either.
 		not pursued No    
S3‑181150 Editorial modification on reference ZTE Corporation CR Approval
7.2.16Others
 		Yes
Yes
 		agreed No    
S3‑181151 Editorial modification on key setting and key lifetimes ZTE Corporation CR Approval
7.2.2Key derivation
 		Yes
Yes
 		merged No S3‑181434  
S3‑181152 Editorial modification on key handling in mobility registration update ZTE Corporation CR Approval
7.2.3Mobility
 		Yes
Yes
Huawei,NEC,Ericsson: this is not editorial.
 		not pursued No    
S3‑181153 Editorial modification on EAP-AKA' ZTE Corporation CR Approval
7.2.8Primary authentication
 		Yes
Yes
 		merged No S3‑181453  
S3‑181154 Editorial modification on authentication method selection ZTE Corporation CR Approval
7.2.8Primary authentication
 		Yes
Yes
Qualcomm and Nokia didn’t find this to be clarifying anything.
The reference change was accepted.
 
 		revised No S3‑181466  
S3‑181155 Editorial modification on authentication and authorization requirement ZTE Corporation CR Approval
7.2.16Others
 		Yes
Yes
 		merged No S3‑181462  
S3‑181156 Editorial modification on 5G AKA ZTE Corporation CR Approval
7.2.8Primary authentication
 		Yes
Yes
 		merged No S3‑181453  
S3‑181157 Discussion on using a key left at the AUSF for fast re-authentication ZTE Corporation discussion Endorsement
7.2.8Primary authentication
 		Yes
Yes
Qualcomm: Fast reauthentication is not necessary in 5G, it doesn't bring any benefit so there is no need to mandate it.
Nokia agreed with the above statement, they didn’t think it was urgent.
Huawei supported ZTE; fast reauthentication is used in LTE and it reduces the load in the HSS.
Ericsson commented that 5G AKA is a new feature and a radical redesign shouldn’t be done at this stage.
Alf( Docomo): it's an optimization and we have to analize whether we need to optimize.
The Chair proposed to take this work to phase two. This was agreed.
 
 
 		noted No    
S3‑181158 Add description for authentication using a key left at the AUSF - general ZTE Corporation CR Approval
7.2.8Primary authentication
 		Yes
Yes
 		not pursued No    
S3‑181159 Add description for authentication using a key left at the AUSF – EAP-AKA' ZTE Corporation CR Approval
7.2.8Primary authentication
 		Yes
Yes
 		not pursued No    
S3‑181160 Add description for authentication using a key left at the AUSF – 5G AKA ZTE Corporation CR Approval
7.2.8Primary authentication
 		Yes
Yes
 		not pursued No    
S3‑181161 Add description for fast re-authentication of multiple registration ZTE Corporation CR Approval
7.2.8Primary authentication
 		Yes
Yes
 		not pursued No    
S3‑181162 Authentication procedure is common for multiple registration in same PLMN ZTE Corporation CR Approval
7.2.5NAS security
 		Yes
Yes
Ericsson: there is no common NAS security context defined anywhere.
There was an agreement on the fundamentals but the wording couldn't be agreed.
 		merged No S3‑181547  
S3‑181163 Add condition for reset NAS COUNTs ZTE Corporation CR Approval
7.2.2Key derivation
 		Yes
Yes
 		revised No S3‑181512  
S3‑181164 LS Reply on SBI Design and its Security Implications C4-182244 LS in  
7.2.13.1Interconnect (SEPP related)
 		Yes
Yes
 		replied to No    
S3‑181165 Resolution of Editor's Note on authentication vectors KPN N.V. CR Agreement
7.2.8Primary authentication
 		Yes
Yes
Nokia: this "transformed auth vector" is confusing. This was taken offline.
Clause 3 will go into tdoc 475.
 
 		merged No S3‑181453  
S3‑181166 Resolution of Editor's note on key left at AUSF KPN N.V. CR Agreement
7.2.8Primary authentication
 		Yes
Yes
 		merged No S3‑181460  
S3‑181167 Deletion of Editor's Notes in clause 6.1.2 and 6.1.3 and restructuring KPN N.V. CR Agreement
7.2.8Primary authentication
 		Yes
Yes
 		revised No S3‑181461  
S3‑181168 Security of MAC algorithms and tags InterDigital, Inc. pCR Approval
8.5Study on Supporting 256-bit Algorithms for 5G (FS_256-Algorithms) (Rel-16)
 		Yes
Yes
NCSC didn’t understand this. It looked like general comments but it didn’t fit anywhere.
 		noted No    
S3‑181169 Assessment of the MAC tag size NIST pCR Approval
8.5Study on Supporting 256-bit Algorithms for 5G (FS_256-Algorithms) (Rel-16)
 		No
Yes
 		withdrawn Yes    
S3‑181170 Introduction of the Subscription Concealed Identifier to EPC Apple Computer Trading Co. Ltd CR Approval
7.2.14Privacy
 		No
Yes
 		withdrawn Yes    
S3‑181171 [CAPIF] 33.122 Functional Security Model Motorola Solutions Danmark A/S pCR Approval
7.6Security Aspects of Common API Framework for 3GPP Northbound APIs (CAPIF_Sec) (Rel-15)
 		Yes
Yes
 		approved No    
S3‑181172 [MCSEC] 33180 R14 EN clause 5.1.3.1 Motorola Solutions Danmark A/S CR Agreement
7.10.18Security of the Mission Critical Service (MCSec)
 		Yes
Yes
 		withdrawn Yes    
S3‑181173 [MCSec] 33180 R14 technical clarifications Motorola Solutions Danmark A/S CR Agreement
7.10.18Security of the Mission Critical Service (MCSec)
 		Yes
Yes
 		agreed No    
S3‑181174 [eMCSec] 33180 R15 Interconnection references clarification Motorola Solutions Danmark A/S CR Agreement
7.3Mission Critical Security Enhancements (eMCSec) (Rel-15)
 		Yes
Yes
 		agreed No    
S3‑181175 [eMCSec] 33180 R15 media mixing note Motorola Solutions Danmark A/S CR Agreement
7.3Mission Critical Security Enhancements (eMCSec) (Rel-15)
 		Yes
Yes
 		agreed No    
S3‑181176 [eMCSec] 33180 R15 migration user authentication Motorola Solutions Danmark A/S CR Agreement
7.3Mission Critical Security Enhancements (eMCSec) (Rel-15)
 		Yes
Yes
 		agreed No    
S3‑181177 [eMCSec] 33180 R15 various technical clarifications Motorola Solutions Danmark A/S CR Agreement
7.3Mission Critical Security Enhancements (eMCSec) (Rel-15)
 		Yes
Yes
 		agreed No    
S3‑181178 WID eMCSec R16 security Motorola Solutions Danmark A/S WID new Agreement
7.11New Work Item proposals
 		Yes
Yes
 		revised No S3‑181504  
S3‑181179 Generation and Rotation of 5G-GUTI Apple Computer Trading Co. Ltd CR Approval
7.2.14Privacy
 		Yes
Yes
ORANGE: subscription is managed by the home network and 5G-GUTI by the serving network.
Ericsson: this was one of the key issues in the TR and there were many discussions on this topic and we shouldn’t  reopen them now. It should be left for phase two.
Docomo: GUTI should be changed after every exposure and here it is after every unexposure. This needs to be discussed.
It was taken offline.
 
 		not pursued No    
S3‑181180 Introduction of the Subscription Concealed Identifier to EPC Apple Computer Trading Co. Ltd CR Approval
7.2.14Privacy
 		Yes
Yes
ORANGE: this is 5G affecting 33.401 and our Work Item doesn’t have this in scope. We need a new WID for this new mechanism.
Vodafone didn’t support this mechanism. There were other ways much less harmful ways to protect the IMSI.
Docomo: this could have impact on other groups, better to have a study.
Qihoo 360: we support the IMSI privacy in LTE, like in here.  
 
 		not pursued No    
S3‑181181 Discussion paper on RP-180590/S3-181121 Nokia discussion Endorsement
7.2.15Incoming and outgoing LSes
 		Yes
Yes
Huawei: registration procedure is separate from service request, all scenarios described in SA2 that require this signalling only connections is only for DRB.
Huawei commented that they hadn't seen any SA3 related scenario or use case. Ericsson supported Huawei.
Docomo: I understand that we are looking at scenarios where no DRB is being set up. One of these scenarios is MDT. I don’t see this in the discussions. I don’t understand why they are asking us about a RAN internal problem.
Nokia:: scenarios are an issue for SA2 or RAN groups. We need a mechanism for this. DT agreed with Nokia.
Ericsson commented that mechanisms already existed and it was up to the other groups to decide how to do the procedure.
Docomo: I understand that they are asking for scenarios in the LS.
Huawei: RRC security context is established separately from user plane context. The use case is to be defined by SA2.
 
 
 
 
 		noted No    
S3‑181182 Discussion paper on Subscription id format Nokia discussion Endorsement
7.2.14Privacy
 		Yes
Yes
 		noted No    
S3‑181183 Discussion paper on C1-181791 LS on Paging with IMSI/SUPI Nokia discussion Endorsement
7.2.15Incoming and outgoing LSes
 		Yes
Yes
Ericsson: not a new topic for us, we have sent an LS about it already. We are in CC. It's already clear that there is an issue for privacy. It's a discussion between CT1 and SA2. We have stated our opinion already.
It was agreed to send an LS response.
 
 		endorsed No    
S3‑181184 draft_Reply LS to RP-180590 Secure signalling AS context Nokia response Approval
7.2.15Incoming and outgoing LSes
 		Yes
Yes
 		revised No S3‑181451  
S3‑181185 New SID on security aspects on support of PARLOS SPRINT Corporation SID new Agreement
8.8New study item proposals
 		Yes
Yes
Colin (BT) suggested to mention the Credit Card Industry for the credit card numbers issue.
 
 		revised No S3‑181441  
S3‑181186 Editorials to 33.501 NTT DOCOMO CR  
7.2.16Others
 		Yes
Yes
 		withdrawn Yes    
S3‑181187 Clarification UE responding with SUCI to identifier request NTT DOCOMO CR Agreement
7.2.14Privacy
 		Yes
Yes
 		merged No S3‑181476  
S3‑181188 Editorials to 33.501 NTT DOCOMO CR Agreement
7.2.16Others
 		Yes
Yes
 		revised No S3‑181439  
S3‑181189 clarify UE concurrency rule NTT DOCOMO CR Agreement
7.2.5NAS security
 		Yes
Yes
Ericsson: this is needed but it doesn’t take care of proposal one in 1135.
Docomo asked to be minuted: Point of completion of the primary authentication is FFS, as a reminder for the next meeting.
 		revised No S3‑181566  
S3‑181190 Clarification for perceived potential AKA race condition NTT DOCOMO CR Agreement
7.2.8Primary authentication
 		Yes
Yes
Nokia commented that TS 29.500 captures already this in stage 3.
Docomo: it's clear hop by hop but we need to consider the end-to-end case. This is not covered by HTTP2. DT agreed.
Huawei supported Nokia.
Nokia: if there is a doubt let's check with CT4 through an LS.
Ericsson: this is in response to a vulnerability disclosure issue that didn't consider other than documents than 33.501.
It was agreed to send an LS to CT4 and keep this document open if the response was coming by the end of the week.
Docomo commented that there had been no response from CT4 in this meeting so some text would be drafted for tne next meeting among the interested companies.
 
 
 		not pursued No    
S3‑181191 Clause 5.2.5 Add a requirement for routing SUCI CATT,China Mobile CR Agreement
7.2.14Privacy
 		Yes
Yes
KPN: add "in the unencrypted part" in the requirement.
Ericsson: routing information is already mentioned, do we need this?
It was proposed to send an LS to SA2. The document was taken offline.
 
 		not pursued No    
S3‑181192 Discussion on RRC-INACTIVE state Security Huawei, Hisilicon discussion Endorsement
7.2.4AS security
 		Yes
Yes
Ericsson had some issues:
- Proposal two is too far-fetched. The UE is basically inactive. What did change in 5G to require this?
- Avoid challenging decisions with RAN.
 
Samsung supported Huawei, there is a need for a mechanism for changing algortihms.
 
Ericsson: The UE is in INACTIVE state here. Just bring the UE to connected state and do the usual procedure in LTE. The proposal may olverload the INACTIVE procedure.The algorithm change scenario is a very rare case. As soon as the target UE detects that the change is needed, comes back to connected state. Nokia supported Ericsson.
 
Huawei: SA3 is asked to evaluate the security aspect of this proposal from RAN2.
 
Huawei: we cannot assume that the target gNodeB supports the same algorithm as the UE. Ericsson replied that this would mean a weakness in LTE for something that is widely deployed.
 
Huawei proposes a LS reply in 225.
 
On Proposal 2, it was agreed that RAN2 should decide, but Ericsson wanted to understand the threat cleary.
 
It was agreed not to have a CR for this meeting.
 		noted No    
S3‑181193 Resolving Editor Note on One-Step SMS over NAS Huawei, Hisilicon CR Approval
7.2.5NAS security
 		Yes
Yes
 		merged No S3‑181567  
S3‑181194 Introduction for Dual Connectivity Huawei, Hisilicon CR Approval
7.2.4AS security
 		Yes
Yes
The figure 6.10.1.2-1 is not in scope of the dual connectivity.
The overlapping documents had to go offline. A draftCR was created to compile all the inputs: 517.
 		not pursued No    
S3‑181195 Dual Connectivity Architecture for MR-DC with 5GC Huawei, Hisilicon CR Approval
7.2.4AS security
 		Yes
Yes
Content move to 517.
 		not pursued No    
S3‑181196 Reduce complex of Key Derivation Function negotiation Huawei, Hisilicon pCR Approval
8.5Study on Supporting 256-bit Algorithms for 5G (FS_256-Algorithms) (Rel-16)
 		Yes
Yes
Ericsson: it is a bit strange to propose something else like this,instead of bringing it directly.
 		revised No S3‑181563  
S3‑181197 Correction and Clarification for EDCE5 Huawei, Hisilicon CR Approval
7.1EPC enhancements to support 5G New Radio via Dual Connectivity (EDCE5) (Rel-15)
 		Yes
Yes
 		agreed No    
S3‑181198 Correction and Clarification for the handling of KASME Huawei, Hisilicon CR Approval
7.10.1SAE/LTE Security
 		Yes
Yes
 		revised No S3‑181505  
S3‑181199 skeleton of TR33.856 Huawei, Hisilicon pCR Approval
8.6Security aspects of single radio voice continuity from 5G to UTRAN (FS_5G_UTRAN_SEC) (Rel-16)
 		Yes
Yes
MCC commented that the title, template and logo were wrong.
 		revised No S3‑181551  
S3‑181200 a proposal for the scope of TR33.856 Huawei, Hisilicon pCR Approval
8.6Security aspects of single radio voice continuity from 5G to UTRAN (FS_5G_UTRAN_SEC) (Rel-16)
 		Yes
Yes
 		revised No S3‑181552  
S3‑181201 a proposal for the introduction of TR33.856 Huawei, Hisilicon pCR Approval
8.6Security aspects of single radio voice continuity from 5G to UTRAN (FS_5G_UTRAN_SEC) (Rel-16)
 		Yes
Yes
 		revised No S3‑181553  
S3‑181202 a proposal for the key issue of TR33.856 Huawei, Hisilicon pCR Approval
8.6Security aspects of single radio voice continuity from 5G to UTRAN (FS_5G_UTRAN_SEC) (Rel-16)
 		Yes
Yes
Key issues had to be aligned with SA2 work. An editor's note was added to that effect.
 
 
 		revised No S3‑181584  
S3‑181203 a proposal for the key derivation without direct interface between AMF and MSC server of TR33.856 Huawei, Hisilicon pCR Approval
8.6Security aspects of single radio voice continuity from 5G to UTRAN (FS_5G_UTRAN_SEC) (Rel-16)
 		Yes
Yes
ORANGE pointed out that the user experience would be highly impacted here.
 
 		revised No S3‑181585  
S3‑181204 a proposal for the key derivation with interface between AMF and MSC server of TR33.856 Huawei, Hisilicon pCR Approval
8.6Security aspects of single radio voice continuity from 5G to UTRAN (FS_5G_UTRAN_SEC) (Rel-16)
 		Yes
Yes
 		revised No S3‑181586  
S3‑181205 Verification of claims in the token during service access request Huawei, Hisilicon CR Approval
7.2.13.2Other
 		Yes
Yes
Ericsson commented that the editor's note versed on the possiblity of the token being signed.
It was commented that there was much behind this editor's note and that further discussions were needed. A new CR would be brought for the next meeting.
 		not pursued No    
S3‑181206 The granularity of NF service discovery Huawei, Hisilicon CR Approval
7.2.13.2Other
 		Yes
Yes
 		revised No S3‑181487  
S3‑181207 Authorization mechanism for NEF-AF interface Huawei, Hisilicon CR Approval
7.2.16Others
 		Yes
Yes
Nokia: authorization is covered by SA2.
 
 		not pursued No    
S3‑181208 Scope of CAPIF security Huawei, Hisilicon pCR Approval
7.6Security Aspects of Common API Framework for 3GPP Northbound APIs (CAPIF_Sec) (Rel-15)
 		Yes
Yes
Motorola: T8 interface already appears in TS 23.222 Annex B. We are doing security for TS 23.222.
Samsung: the document does not consider the need of harmonization. It harmonizes or it doesn’t.
There was no support for this document.
 
 
 		noted No    
S3‑181209 Security requirements for service API discovery Huawei, Hisilicon pCR Approval
7.6Security Aspects of Common API Framework for 3GPP Northbound APIs (CAPIF_Sec) (Rel-15)
 		Yes
Yes
 		noted No    
S3‑181210 Authorization mechanism for CAPIF-2e reference point Huawei, Hisilicon pCR Approval
7.6Security Aspects of Common API Framework for 3GPP Northbound APIs (CAPIF_Sec) (Rel-15)
 		Yes
Yes
 		merged No S3‑181516  
S3‑181211 Authorization mechanism for CAPIF-2 reference point Huawei, Hisilicon pCR Approval
7.6Security Aspects of Common API Framework for 3GPP Northbound APIs (CAPIF_Sec) (Rel-15)
 		Yes
Yes
This proposal was agains the restructuring proposed by NEC in 529.
 
 		merged No S3‑181540  
S3‑181212 Security method between API invoker and API exposing function Huawei, Hisilicon pCR Approval
7.6Security Aspects of Common API Framework for 3GPP Northbound APIs (CAPIF_Sec) (Rel-15)
 		Yes
Yes
Nokia: the new text doesn’t fit into this clause. NEC agreed. They admitted that the document didn’t have the right place to include this. It was agreed to make it into an editor's note stating that the paragraph had to be moved.
 
 
 		revised No S3‑181542  
S3‑181213 Derivation of the key AEFPSK Huawei, Hisilicon pCR Approval
7.6Security Aspects of Common API Framework for 3GPP Northbound APIs (CAPIF_Sec) (Rel-15)
 		Yes
Yes
 		merged No S3‑181515  
S3‑181214 Security credentials for TLS before initiating TLS connection Huawei, Hisilicon pCR Approval
7.6Security Aspects of Common API Framework for 3GPP Northbound APIs (CAPIF_Sec) (Rel-15)
 		Yes
Yes
 		approved No    
S3‑181215 TLS-PSK ciphersuites for security method of CAPIF-2e reference point Huawei, Hisilicon pCR Approval
7.6Security Aspects of Common API Framework for 3GPP Northbound APIs (CAPIF_Sec) (Rel-15)
 		Yes
Yes
Revised to Refer to 33.210 Annex D.
 		revised No S3‑181539  
S3‑181216 SID on security of 5WWC Huawei; HiSilicon SID new Agreement
8.8New study item proposals
 		Yes
Yes
Colin (BT): privacy for individual users in the residential use case should be included. This was taken offline.
Alf( Docomo): timeline is too optimistic.
The Chair commented that the timeline could always be adjusted.
 
 		revised No S3‑181442  
S3‑181217 NAS SMC procedure of multi NAS connection Huawei; HiSilicon CR Approval
7.2.5NAS security
 		Yes
Yes
 
 
 		merged No S3‑181547  
S3‑181218 The initial value of NAS COUNT in multi NAS connection Huawei; HiSilicon CR Approval
7.2.5NAS security
 		Yes
Yes
Nokia: better to start from zero. Huawei agreed.
 
 		not pursued No    
S3‑181219 non-3GPP access when security context is available Huawei; HiSilicon CR Approval
7.2.11non-3GPP access
 		Yes
Yes
Qualcomm: this clause is getting overloaded with content, better to include the info in a separate clause. Nokia agreed.
Ericsson didn’t see it clear.
 
 		revised No S3‑181573  
S3‑181220 new KI of UP security parameters management Huawei; HiSilicon pCR Approval
8.3Study on security aspects of 5G Network Slicing Management (FS_ NETSLICE-MGT_Sec) (Rel-15)
 		Yes
Yes
 		noted No    
S3‑181221 solution of UP security policy management Huawei; HiSilicon pCR Approval
8.3Study on security aspects of 5G Network Slicing Management (FS_ NETSLICE-MGT_Sec) (Rel-15)
 		Yes
Yes
 		noted No    
S3‑181222 Update security mechanism in Xn-HO procedre Huawei; HiSilicon CR Approval
7.2.3Mobility
 		Yes
Yes
Nokia and Samsung didn’t understand the scenario and the contribution was taken offline.
 
 		revised No S3‑181555  
S3‑181223 AS SMC Handling- update Huawei; HiSilicon CR Approval
7.2.4AS security
 		Yes
Yes
 		merged No S3‑181456  
S3‑181224 AS SMC Handling-registration Huawei; HiSilicon CR Approval
7.2.4AS security
 		Yes
Yes
Nokia and Ericsson didn’t agree with removing the "only".
 
 		revised No S3‑181518  
S3‑181225 Draft Reply LS to RAN2 on security for inactive state. Huawei; HiSilicon LS out Approval
7.2.4AS security
 		Yes
Yes
Ericsson: what's the security threat?
Huawei: no security negotiation between target gNodeB and UE.
This was agreed to include it in the LS.
Huawei: let's mention the security issues and let RAN2 decide.
 
Huawei and Ericsson had to go offline to discuss their proposal number 2.
 
 
 		revised No S3‑181450  
S3‑181226 Clause 5.8 Remove a redundant requirement CATT CR Agreement
7.2.14Privacy
 		Yes
Yes
 		merged No S3‑181462  
S3‑181227 Clause 5.2.5 Privacy requirement clarification CATT CR Approval
7.2.14Privacy
 		Yes
Yes
 		merged No S3‑181462  
S3‑181228 Clause 6.11.1-2 Editorial and wording errors correction CATT CR Approval
7.2.9Secondary authentication
 		Yes
Yes
 		merged No S3‑181569  
S3‑181229 Clause 6.12.2 Add routing assistance indicator in SUCI CATT CR Agreement
7.2.14Privacy
 		Yes
Yes
Vodafone: rejecting handsets that haven’t been sold by companies is not allowed in many countries. Some companies wouldn’t want to update the USIM, so where is the roaming information coming from? Vodafone didn't disagree with this, but thought it was incomplete.
ORANGE: the requirement does not include any security part, it looks like something from a CT group.
Interdigital: this requirement affects privacy.
China Unicom supported CATT's proposal.
 
 		not pursued No    
S3‑181230 Clause 6.12.2 Wording and correction related to SUCI CATT CR Approval
7.2.14Privacy
 		Yes
Yes
 		revised No S3‑181498  
S3‑181231 Discussion for the security assurance of 3GPP virtualized network functions China Mobile Group Device Co. discussion  
8.8New study item proposals
 		Yes
Yes
Vodafone commented that the number of SIDs was already too large and some careful consideration was needed in order to reduce the number of meetings.
ORANGE referred to the plenary recommendation on reducing the number of meetings per year per working group.
Huawei supported having this SID.
DT: this is not high priority. Not a bad idea, but not urgent to do in rel-16.
ORANGE: the biggest problem is the scope, how much is done here and how much is done in ETSI.
Alex (BT): good idea but not with this scope. Limit it to the capabilities we need from the platform and ask ETSI NFV to fix it.Just use case scenarios and API capabilities.
ZTE supported this work.
Docomo was in favour of having this. There is an understanding of NFV at this stage and SCAS for this makes sense. I also understand Tim's concern. We need more meetings to reduce the current workload.
BT: it needs to be done and it will be very complex.
Ericsson was in favour of any SCAS work. If we get the SCAS for non virtualised network functions, we will look after to the virtualised network functions.This study seems to be out of scope, though.
Nokia: we are not sure how this would fit into the whole SCAS. It needs to be done later.
China Unicom considered this as a high priority work for network operators.
Alex (BT) preferred to check this in future meetings, not now.
Huawei: there is no intention in NFV to do any SCAS work. It is clearly under our scope.  
 		noted No    
S3‑181232 New SID on SCAS for 3GPP virtualized network functions China Mobile Group Device Co. SID new  
8.8New study item proposals
 		Yes
Yes
The Chair recommended some offline discussions to delimit the scope and bring it back in the August meeting.
 
 		noted No    
S3‑181233 Clause 6.12.4 Remove some redundant content CATT CR Approval
7.2.14Privacy
 		Yes
Yes
KPN didn’t agree with the last two changes.
ORANGE and Nokia didn’t agree with the CR.
 
 		not pursued No    
S3‑181234 Discussion on authentication and key management for applications based on 3GPP credential in 5G IoT China Mobile Group Device Co. discussion  
8.8New study item proposals
 		Yes
Yes
 		noted No    
S3‑181235 Study on authentication and key management for applications based on 3GPP credential in 5G IoT China Mobile Group Device Co. SID new  
8.8New study item proposals
 		Yes
Yes
Vodafone: fine with this, but worried about the wording in the objectives suggesting another specification when these are minor changes in GBA and BEST.
Qualcomm: align with 5G IoT work in SA2.
 
 
 		revised No S3‑181562  
S3‑181236 Living Document: Security of Service Based Architecture of 5G phase 1 China Mobile Group Device Co. other  
7.2.13.2Other
 		Yes
Yes
 		revised No S3‑181474  
S3‑181237 Clause 6.12.5 Add SIDF decryption process description CATT CR Approval
7.2.14Privacy
 		No
Yes
 		withdrawn Yes    
S3‑181238 Clause 6.12.5 Add SIDF decryption process description CATT CR Approval
7.2.14Privacy
 		Yes
Yes
Ericsson: redudant, we have very similar text in the annex C.3.3. ORANGE agreed.
Revised to reference this annex.
 
 
 
 		not pursued No    
S3‑181239 Discussion of 5G phase-2 work KPN N.V. discussion Agreement
8.8New study item proposals
 		Yes
Yes
Vodafone: we need normative SBA work completed by the end of Rel-16.
ORANGE supported this contribution.
 
 		noted No    
S3‑181240 Primary reauthentication Procedure Intel China Ltd. CR Agreement
7.2.8Primary authentication
 		Yes
Yes
 		not pursued No    
S3‑181241 Discussion on Prevention of Fraud Call China Mobile Group Device Co. discussion  
8.7Other study areas
 		Yes
Yes
BT agreed with the problem.However what needs to be done is at ITU level and not 3GPP.
 		noted No    
S3‑181242 Agenda and notes of conference call on SEPP protection mechanisms Deutsche Telekom AG discussion Information
7.2.13.1Interconnect (SEPP related)
 		Yes
Yes
 		noted No    
S3‑181243 Agenda and notes of conference call on SEPP security policies Deutsche Telekom AG discussion Information
7.2.13.1Interconnect (SEPP related)
 		Yes
Yes
 		noted No    
S3‑181244 N32 message anti-spoofing within the SEPP Deutsche Telekom AG other Approval
7.2.13.1Interconnect (SEPP related)
 		Yes
Yes
Ericsson: this is too detailed for a normative text.
Vodafone: this will go into a TR.No need to write such editors' notes.
Huawei: this is more requirements than a solution. Their document 285 also dealt with this issue.They asked for the second bullet to be removed.
Docomo: certificate check should be put in there.
On the second bullet Docomo commented: any SEPP can put any IP address in there. This was taken offline.
 
 
 
 
 		revised No S3‑181480  
S3‑181245 Impacted NextGen Areas NCSC pCR Approval
8.5Study on Supporting 256-bit Algorithms for 5G (FS_256-Algorithms) (Rel-16)
 		Yes
Yes
KPN: We need an introduction clause which explains the assumption of an attacker with a quantum computer.
MCC pointed out that there was quite a bit of normative text that needed to be reworded.
 
 		revised No S3‑181558  
S3‑181246 LTKUP: clarifications for solution #5 Gemalto N.V. pCR Approval
8.4Study on Long Term Key Update Procedures (FS_LTKUP) (Rel-15)
 		Yes
Yes
 		revised No S3‑181526  
S3‑181247 LTKUP: conclusion Gemalto N.V. pCR Approval
8.4Study on Long Term Key Update Procedures (FS_LTKUP) (Rel-15)
 		Yes
Yes
 		noted No    
S3‑181248 Discussion on ID binding in Secondary Authentication Huawei, Hisilicon, China Southern Power Grid discussion Endorsement
7.2.9Secondary authentication
 		Yes
Yes
 		revised No S3‑181431  
S3‑181249 ID binding in Secondary Authentication Huawei, Hisilicon, China Southern Power Grid CR Approval
7.2.9Secondary authentication
 		Yes
Yes
 		revised No S3‑181432  
S3‑181250 Updates to Secondary Authentication Procedure Huawei, Hisilicon CR Approval
7.2.9Secondary authentication
 		Yes
Yes
 		revised No S3‑181569  
S3‑181251 Authentication and authorization for slice management interface Huawei, Hisilicon pCR Approval
8.3Study on security aspects of 5G Network Slicing Management (FS_ NETSLICE-MGT_Sec) (Rel-15)
 		Yes
Yes
ORANGE: There are assumptions that are beyond SA5's work. These should be removed (6.y.2.2.4). It is hard to do these assumptions without an architecture.
ORANGE: there are a lots of "shalls" and this is a study.
 
 
 		revised No S3‑181556  
S3‑181252 OAuth based authorization for access to management functions Huawei, Hisilicon pCR Approval
8.3Study on security aspects of 5G Network Slicing Management (FS_ NETSLICE-MGT_Sec) (Rel-15)
 		Yes
Yes
 		approved No    
S3‑181253 Update to overview clause Huawei, Hisilicon pCR Approval
8.3Study on security aspects of 5G Network Slicing Management (FS_ NETSLICE-MGT_Sec) (Rel-15)
 		Yes
Yes
ORANGE insisted that this based on work on 23.501 (out of scope) and on an architecture that is not defined.
Huawei: the figure is a general overview that provides useful information.
There was disagreement between ORANGE and Huawei and this had to be taken offline.
Finally noted.
 
 		noted No    
S3‑181254 Security options Huawei, Hisilicon pCR Approval
8.3Study on security aspects of 5G Network Slicing Management (FS_ NETSLICE-MGT_Sec) (Rel-15)
 		Yes
Yes
 		revised No S3‑181433  
S3‑181255 New SID on security of URLLC in 5G system Huawei, Hisilicon SID new Approval
8.8New study item proposals
 		Yes
Yes
Qualcomm: in SA2 the scope is restricted in the connected mode of the UE. I don’t see that having an impact on SA3. Let’s wait for SA2 to see if there is any security impact. My RAN colleagues have told me that they haven't even started the work. It is too early to bring this.
Deutsche Telekom: same as Qualcomm. Let's wait and see.  
BT agreed, it was too early.
The Chair commented that the general understanding was that the SID was too early and it was necessary to wait for other groups to progress on their work.
 		noted No    
S3‑181256 Adding further details for EPS to 5G interworking Huawei, Hisilicon CR Approval
7.2.10Interworking
 		Yes
Yes
 		postponed No    
S3‑181257 Modification for algorithm names Huawei, Hisilicon CR Approval
7.2.4AS security
 		Yes
Yes
 		revised No S3‑181520  
S3‑181258 Correct typo in SBA Authorization Huawei, Hisilicon CR Approval
7.2.13.2Other
 		Yes
Yes
 		revised No S3‑181484  
S3‑181259 Discussion on SA5 LS Huawei, Hisilicon discussion Endorsement
8.3Study on security aspects of 5G Network Slicing Management (FS_ NETSLICE-MGT_Sec) (Rel-15)
 		Yes
Yes
ORANGE: their work will go beyond May, so SA3 cannot finnish before them.
Huawei commented that this wasn't the information they had from their colleagues in SA5 and from what was said in the LS.
The Chair asked Huawei if the architecture was defined. Huawei replied that their architecture is not based on SA2's work but on an information model.
ORANGE commented that the specification only has a few requirements but no architecture is present in the document.
Huawei commented that since there was no agreement between the SA5 delegates SA3 had to stick to what the LS said, and they mentioned finishing in June.
The Chair commented that SA3 could always ask for an extension if SA5 was late.
ORANGE: we should not tie this to the work in phase one of 5G.
Huawei: the work in SA5 is not a Study Item.
ORANGE: then we need to bring a WID to complete the work.
ORANGE: it is premature to discuss the rest of the proposals.
Huawei commented that they could bring a WID proposal for the next meeting in order to do normative work.
Huawei: if they finish the work in June (Rel-15), what happens with the security for that?
The Chair replied that it was normal to finish a cycle later and that should be pointed out in SA plenary.
It was asked to be minuted: SA3 activity is dependant on SA5 progress on this topic. A WID was needed to do the normative work. It was also pointed out that the network slicing work would not be complete without the security work performed by SA3.
Huawei was worried that SA3 were to be blamed on the delay of the network slicing work, but the Chair replied that this was a common issue and it was hard to avoid given the short time scales given to SA3 to perform their work,
 
 
 
 		noted No    
S3‑181260 Editorial changes over subclause B.1 Huawei, Hisilicon CR Approval
7.2.8Primary authentication
 		Yes
Yes
 		merged No S3‑181472  
S3‑181261 Fast Re-authentication Process for EAP-AKA’ Huawei, Hisilicon, China Mobile CR Approval
7.2.8Primary authentication
 		Yes
Yes
 		not pursued No    
S3‑181262 NSST integrity protection solution Huawei, Hisilicon pCR Approval
8.3Study on security aspects of 5G Network Slicing Management (FS_ NETSLICE-MGT_Sec) (Rel-15)
 		Yes
Yes
 		approved No    
S3‑181263 NSST confidentiality protection solution Huawei, Hisilicon pCR Approval
8.3Study on security aspects of 5G Network Slicing Management (FS_ NETSLICE-MGT_Sec) (Rel-15)
 		Yes
Yes
 		approved No    
S3‑181264 pCR to TR 33.834 – clarifications to key issue 1 Vodafone Group Plc pCR Approval
8.4Study on Long Term Key Update Procedures (FS_LTKUP) (Rel-15)
 		Yes
Yes
Gemalto: the requirements are not written as such, this is a threat analysis.
ORANGE: low/high risk are very difficult to evaluate in a solution.
It was agreed to revise removing the changes in the requirements clause.
 
 		revised No S3‑181527  
S3‑181265 pCR to TR 33.834 – clarifications to key issue 2 Vodafone Group Plc pCR Approval
8.4Study on Long Term Key Update Procedures (FS_LTKUP) (Rel-15)
 		Yes
Yes
 		revised No S3‑181528  
S3‑181266 Editorial corrections of clause 6.5 LG Electronics CR Agreement
7.2.4AS security
 		Yes
Yes
 		merged No S3‑181521  
S3‑181267 Editorial corrections of clause 6.6 LG Electronics CR Agreement
7.2.4AS security
 		Yes
Yes
 		revised No S3‑181522  
S3‑181268 Editorial corrections of clause 6.7 LG Electronics CR Agreement
7.2.4AS security
 		Yes
Yes
 		merged No S3‑181518  
S3‑181269 Use type parameter for asymmetric key encryption schemes LG Electronics discussion Discussion
7.2.14Privacy
 		Yes
Yes
 		noted No    
S3‑181270 Use type information as a SUCI construction input paramter in Annex C LG Electronics CR Agreement
7.2.14Privacy
 		Yes
Yes
 		revised No S3‑181449  
S3‑181271 Missing PEI requirements Motorola Mobility, Lenovo CR Approval
7.2.14Privacy
 		Yes
Yes
 		revised No S3‑181445  
S3‑181272 Missing PEI requirements Motorola Mobility LS out Approval
7.2.14Privacy
 		Yes
Yes
ORANGE: format of IMEI is not SA3 specific.
It was not needed anymore after discussions in tdoc 500 and hence it was noted.
 		noted No    
S3‑181273 pCR to TR 33.834 – new key issue, undetected key leakage Vodafone Group Plc pCR Approval
8.4Study on Long Term Key Update Procedures (FS_LTKUP) (Rel-15)
 		Yes
Yes
G&D: Note and bullet with "it is unlikely.." should go out as they are not true. ORANGE agreed.
ORANGE: it is late to add key issues and requirements at this stage. It doesn’t give time to people to bring solutions and evaluate them. Gemalto supported this.
Vodafone: broadly speaking this doesn’t change the evaluation. This is in the document already. I'm happy to remove 8.Y as well.
Alf (Vice Chair) asked who was in favour of  this document, but there was very little support for this.
 
The Vice Chair clarified that Key issues that break security should be taken care of, even if they come at a late stage.
 		noted No    
S3‑181274 Discussion of potential issues in JSON parsers NCSC discussion Discussion
7.2.13.1Interconnect (SEPP related)
 		Yes
Yes
 		noted No    
S3‑181275 pCR to TR 33.834 – updated evaluation of solution #3 Vodafone Group Plc pCR Approval
8.4Study on Long Term Key Update Procedures (FS_LTKUP) (Rel-15)
 		Yes
Yes
 		revised No S3‑181530  
S3‑181276 Adding context to SBA API requirements NCSC other Approval
7.2.13.1Interconnect (SEPP related)
 		Yes
Yes
NTT-Docomo: upgrade this document to a TR.
Vodafone supported this. Tim pointed out that working with living documents was a very bad habit in SA3.
It was commented that a new Study Item could be created and approved in one go with the TR.
 
 		merged No S3‑181474  
S3‑181277 pCR to TR 33.841- Clarification on two algorithms for resilience Vodafone Group Plc, AT&T, Interdigital, NIST, MITRE pCR Approval
8.5Study on Supporting 256-bit Algorithms for 5G (FS_256-Algorithms) (Rel-16)
 		Yes
Yes
ORANGE: we standardise the outputs and inputs of algorithms but not the algorithms themselves. Tuak and MILENAGE are not standardised.
Vodafone: these two algorithms are standardised.
It was decided to note it and come back to the next meeting with something else.
 
 		noted No    
S3‑181278 pCR to TR 33.841- Individual algorithms Vodafone Group Plc pCR Approval
8.5Study on Supporting 256-bit Algorithms for 5G (FS_256-Algorithms) (Rel-16)
 		Yes
Yes
CATT: the ZUC information is not up to date.
Gemalto: 13.1.1 (seems perfectly acceptable as the basis for 3GPP algorithms". It seems that it's too early to say this.
 
 		revised No S3‑181564  
S3‑181279 Requirements and impact of a longer MAC NCSC pCR Approval
8.5Study on Supporting 256-bit Algorithms for 5G (FS_256-Algorithms) (Rel-16)
 		No
Yes
 		withdrawn Yes    
S3‑181280 F1-C Protection Orange Spain CR Approval
7.2.4AS security
 		Yes
Yes
 		revised No S3‑181440  
S3‑181281 Living Document: Security of PLMN/RAT selection policies for roaming Orange Spain other Endorsement
7.7PLMN RAT selection (Steering of Roaming)
 		Yes
Yes
 		revised No S3‑181503  
S3‑181282 Clarification for KN3IWF delivery in authentication Huawei, Hisilicon CR Approval
7.2.11non-3GPP access
 		Yes
Yes
 		revised No S3‑181575  
S3‑181283 Requirement for AKA algorithm negotiation between UE and UDM Huawei, Hisilicon pCR Approval
8.5Study on Supporting 256-bit Algorithms for 5G (FS_256-Algorithms) (Rel-16)
 		Yes
Yes
Qualcomm: we already support 256 bits, no need for this document.
ORANGE: we don’t define the algorithms in 3GPP. The operators can support hundreds of algorithms if they want.
 		noted No    
S3‑181284 Non-random IVs in CTR mode NCSC pCR Approval
8.5Study on Supporting 256-bit Algorithms for 5G (FS_256-Algorithms) (Rel-16)
 		Yes
Yes
 		revised No S3‑181459  
S3‑181285 Discussion on fraudulent Registration Request threats Huawei, Hisilicon discussion Approval
7.2.13.1Interconnect (SEPP related)
 		Yes
Yes
Nokia:Solution 1 is adding load to the UDM.
Huawei: we are not proposing solution one.
 
 		noted No    
S3‑181286 AUSF clarification Nokia CR  
7.2.13.2Other
 		Yes
Yes
MCC commented that the clauses should be voided, not deleted.
ORANGE expressed concerns on voiding clauses that may be referenced by other groups.
It was taken offline to wait for some feedback from SA2.
 
 		merged No S3‑181458  
S3‑181287 AUSF requirements Nokia CR  
7.2.8Primary authentication
 		Yes
Yes
MCC commented that this change was not allowed, since it was introducing a new clause by renaming an existing one.
Docomo proposed just to Void clause 5.6 to move the the SEAF requirements.ORANGE warned that this could break any references to the moved clauses.
Qualcomm proposed to add the requirements in sub clauses.
 
 
 
 		merged No S3‑181462  
S3‑181288 UDM requirements Nokia, Gemalto CR  
7.2.8Primary authentication
 		Yes
Yes
ORANGE: .."accordance with other 3GPP specifications" , can you concrete which ones?
Nokia: 33.401 would be an example.
It was agreed to remove this part of the sentence and combine both sentences.
Requirements in 5.8.2 were reworded.
 
 
 
 		revised No S3‑181467  
S3‑181289 UDM clarification Nokia CR  
7.2.13.2Other
 		Yes
Yes
 		revised No S3‑181458  
S3‑181290 Clarification to home control Nokia CR  
7.2.8Primary authentication
 		Yes
Yes
 		revised No S3‑181463  
S3‑181291 Deletion of ed.note related to key left at AUSF Nokia CR  
7.2.8Primary authentication
 		Yes
Yes
 		merged No S3‑181460  
S3‑181292 Resolving ed.note in 6.1.3.1 Nokia CR  
7.2.8Primary authentication
 		Yes
Yes
 		merged No S3‑181453  
S3‑181293 Clause 6.1.2 on auth method selection - clarification Nokia CR  
7.2.8Primary authentication
 		Yes
Yes
 		revised No S3‑181465  
S3‑181294 AMF requirements Nokia CR  
7.2.8Primary authentication
 		Yes
Yes
Qualcomm, Huawei: we don’t need this.
Discussions on whether to put these as security requirements or requirements on how these functionalities work.
 
 		not pursued No    
S3‑181295 NRF and NEF requirements Nokia CR  
7.2.13.2Other
 		Yes
Yes
 		revised No S3‑181492  
S3‑181296 SN Id parameter length Nokia CR  
7.2.8Primary authentication
 		Yes
Yes
 		revised No S3‑181469  
S3‑181297 Prevent fraudulent Registration Request attack Huawei, Hisilicon other Approval
7.2.13.1Interconnect (SEPP related)
 		Yes
Yes
Ericsson questioned whether SA3 had agreed on this threat.
Docomo: this seems to be about serving network impersonation.
Ericsson proposed to create a key issue and have this as one of the possible solutions that can be evaluated.
Docomo: the key issue is network function authorization in roaming scenarios. It can be any other message than registration.
 
 
 
 		revised No S3‑181481  
S3‑181298 Editorial modification for message names in the 5G-AKA Huawei, Hisilicon CR Approval
7.2.8Primary authentication
 		Yes
Yes
 		merged No S3‑181453  
S3‑181299 Removal of security mechanism for MO SMS one step procedure Ericsson CR Agreement
7.2.5NAS security
 		Yes
Yes
 		merged No S3‑181567  
S3‑181300 Clarification of NAS MAC computation for TAU protection, algorithm selection and security activation during idle mode mobility from 5GS to EPS Ericsson CR Agreement
7.2.10Interworking
 		Yes
Yes
 		revised No S3‑181572  
S3‑181301 Clean up of clause on idle mode mobility from 5GS to EPS Ericsson CR Agreement
7.2.10Interworking
 		Yes
Yes
 		merged No S3‑181572  
S3‑181302 [DRAFT] LS on security for inactive state Ericsson LS out Approval
7.2.4AS security
 		Yes
Yes
 		merged No S3‑181450  
S3‑181303 RRC INACTIVE - Discussion on various security aspects Ericsson discussion Discussion
7.2.4AS security
 		Yes
Yes
 		noted No    
S3‑181304 RRC_INACTIVE - security handling at state transition Ericsson CR Agreement
7.2.4AS security
 		Yes
Yes
 		not pursued No    
S3‑181305 RRC_INACTIVE – security handling at mobility Ericsson CR Agreement
7.2.4AS security
 		Yes
Yes
 		not pursued No    
S3‑181306 Study on evolution of Cellular IoT security for the 5G System Ericsson SID new Agreement
8.8New study item proposals
 		Yes
Yes
 		revised No S3‑181444  
S3‑181307 NAS COUNTs Ericsson CR Agreement
7.2.5NAS security
 		Yes
Yes
 		merged No S3‑181547  
S3‑181308 Multiple NAS connections Ericsson CR Agreement
7.2.5NAS security
 		Yes
Yes
It was agreed to have all multi NAS input into the revision of this CR.
 		revised No S3‑181547  
S3‑181309 UP security policy Ericsson CR Agreement
7.2.4AS security
 		Yes
Yes
Related to the LS in 493.
Huawei didn’t support the document.
Qualcomm: this is still under discussion in SA2.
 
 
 		not pursued No    
S3‑181310 Clarifications for algorithm selection, counter setting and key derivation in mapped security contexts Ericsson CR Agreement
7.2.10Interworking
 		Yes
Yes
 		revised No S3‑181571  
S3‑181311 NAS MAC-I in IW HO from EPS to 5GS Ericsson CR Agreement
7.2.10Interworking
 		Yes
Yes
 		merged No S3‑181570  
S3‑181312 Proposal for Dual Connectivity Ericsson discussion Endorsement
7.2.4AS security
 		Yes
Yes
 		noted No    
S3‑181313 Dual Connectivity - Introduction Ericsson CR Agreement
7.2.4AS security
 		Yes
Yes
Content moved to 517.
 		not pursued No    
S3‑181314 Skeleton of FS_5G_UTRAN_SEC China Unicom pCR Approval
8.6Security aspects of single radio voice continuity from 5G to UTRAN (FS_5G_UTRAN_SEC) (Rel-16)
 		Yes
Yes
 		merged No S3‑181551  
S3‑181315 Scope of FS_5G_UTRAN_SEC China Unicom pCR Approval
8.6Security aspects of single radio voice continuity from 5G to UTRAN (FS_5G_UTRAN_SEC) (Rel-16)
 		Yes
Yes
 		merged No S3‑181552  
S3‑181316 Introduction of FS_5G_UTRAN_SEC China Unicom pCR Approval
8.6Security aspects of single radio voice continuity from 5G to UTRAN (FS_5G_UTRAN_SEC) (Rel-16)
 		Yes
Yes
 		merged No S3‑181553  
S3‑181317 Key issue of IMS Emergency Session Handling China Unicom pCR Approval
8.6Security aspects of single radio voice continuity from 5G to UTRAN (FS_5G_UTRAN_SEC) (Rel-16)
 		Yes
Yes
 		revised No S3‑181587  
S3‑181318 Discussion on the format to specify the dual connectivity procedure when attached to a 5G core Qualcomm Incorporated discussion Discussion
7.2.4AS security
 		Yes
Yes
 		noted No    
S3‑181319 Correcting the anti-bidding down parameter in figure 6.7.2-1 Qualcomm Incorporated CR Agreement
7.2.5NAS security
 		Yes
Yes
Abbreviations part was accepted and going to the definitions CR.
 		merged No S3‑181546  
S3‑181320 Not sending SUCI in response to a hash failure Qualcomm Incorporated discussion Endorsement
7.2.5NAS security
 		Yes
Yes
Ericsson agreed that there was no need with sending the SUCI again, but they agreed with asking CT1 as well.
It was agreed to send the LS.
 		endorsed No    
S3‑181321 Proposed solution for handling the NAS security when registered via 3GPP and non-3GPP in the same PLMN Qualcomm Incorporated discussion Discussion
7.2.5NAS security
 		Yes
Yes
It was agreed to add an editor's note in 6.4.2.
 
 
 		noted No    
S3‑181322 Addding the procedures for handling security context when multiply registered on one PLMN Qualcomm Incorporated CR Agreement
7.2.5NAS security
 		Yes
Yes
 		not pursued No    
S3‑181323 Discussion on resolution of the editor’s notes in EN-DC clauses of TS 33.401 Qualcomm Incorporated discussion Discussion
7.1EPC enhancements to support 5G New Radio via Dual Connectivity (EDCE5) (Rel-15)
 		Yes
Yes
This way forward was endorsed by the group.
 
 		endorsed No    
S3‑181324 Reply LS on Security aspects of supporting LTE connected to 5GC Qualcomm Incorporated LS out Approval
7.2.4AS security
 		Yes
Yes
 		revised No S3‑181448  
S3‑181325 Discussion on the freshness parameter for K_AMF derivation Qualcomm Incorporated discussion Endorsement
7.2.2Key derivation
 		Yes
Yes
Ericsson: this is not a bidding down attack. The gNodeB cannot convince the AMF to user other algorithms. The UE and AMF have different versions of Kmf so the NAS security will fail and this would become a DoS attack.
Nokia,NEC,Huawei supported the NAS COUNT solution.
Ericsson: we want to avoid the situation when the source AMF is delivering the same key to a different target AMF.
Qualcomm: but why introducing a new parameter?
 
The Chair asked for a show of hands:
 
NONCE supporting companies:
Ericsson, ZTE
NAS COUNT:
Intel, NEC,Huawei, Qualcomm,Nokia
 
It was finally agreed to use the NAS COUNT solution.
 
 		endorsed No    
S3‑181326 K’AMF derivation and NASC protection at N2 based handover Qualcomm Incorporated CR Agreement
7.2.2Key derivation
 		Yes
Yes
 		revised No S3‑181510  
S3‑181327 Discussion on the freshness parameter for KAMF derivation in EPS to 5GS mobility Qualcomm Incorporated discussion Endorsement
7.2.10Interworking
 		Yes
Yes
Ericsson: it feels wrong to use the NH.
 
 		postponed No    
S3‑181328 K’AMF derivation at EPS to 5GS mobility Qualcomm Incorporated CR Agreement
7.2.10Interworking
 		Yes
Yes
 		postponed No    
S3‑181329 KeNB derivation in 5GS to EPS handover Qualcomm Incorporated CR Agreement
7.2.10Interworking
 		Yes
Yes
 		agreed No    
S3‑181330 KgNB derivation in EPS to 5GS handover Qualcomm Incorporated CR Agreement
7.2.10Interworking
 		Yes
Yes
 		revised No S3‑181570  
S3‑181331 Discussion on ng-eNB related security specification Qualcomm Incorporated discussion Discussion
7.2.4AS security
 		Yes
Yes
 		noted No    
S3‑181332 Updates to Solution #6 in SoR Living Doc Qualcomm Incorporated, T-Mobile US other Approval
7.7PLMN RAT selection (Steering of Roaming)
 		Yes
Yes
 		revised No S3‑181426  
S3‑181333 Limiting SUCI in Identifier Response Qualcomm Incorporated CR Agreement
7.2.14Privacy
 		Yes
Yes
Docomo agreed with the concept but not with the wording. Nokia agreed.
Revised to change the wording.
revised No S3‑181499  
S3‑181334 Delete Editor’s Note in C.3.4.3 Qualcomm Incorporated CR Agreement
7.2.14Privacy
 		Yes
Yes
 		agreed No    
S3‑181335 CR for secure signalling only connections Nokia CR Approval
7.2.4AS security
 		Yes
Yes
Ericsson: let's wait for the response to our LS in 451 in the next meeting.
 
 		not pursued No    
S3‑181336 Delete Editor’s note in subclause 6.2.2.1 Huawei, Hisilicon CR  
8.2Study on security aspects of enhancements to ProSe UE-to-Network Relay (FS_REAR_Sec) (Rel-15)
 		Yes
Yes
 		agreed No    
S3‑181337 Clause 6.2.3.2 EN on Kausf identification Nokia CR Approval
7.2.1Key hierarchy
 		Yes
Yes
 		merged No S3‑181434  
S3‑181338 add definitions and abbreviations for TR33.843 Huawei, Hisilicon CR  
8.2Study on security aspects of enhancements to ProSe UE-to-Network Relay (FS_REAR_Sec) (Rel-15)
 		Yes
Yes
 		revised No S3‑181543  
S3‑181339 CR for Corrections in Clause 6.6 UP Security mechanisms Nokia CR Approval
7.2.4AS security
 		Yes
Yes
Ericsson: let's decide: shall we mandate confidentiality protection for IP based PDU sessions?
Qualcomm: let's come back to this in the next meeting, until SA2 and RAN2 have progressed on this issue.
Docomo: if there's a possibility for downgrading security, we should tell RAN2. Qualcomm replied that there several options being discussed and that if confidentiality protection wasn't ensured there would be a rejection.
 
 
 
 		not pursued No    
S3‑181340 Misleading title given to clause 6.13 Nokia CR Approval
7.2.4AS security
 		Yes
Yes
 		agreed No    
S3‑181341 SUCI - protection schemes identifiers Ericsson CR Agreement
7.2.14Privacy
 		Yes
Yes
Qualcomm: no need to have 8 bits, 4 bits are enough. We don’t need more space than the space used for supporting algorithms.
MCC: the NOTE is giving normative information, it shouldn't be a note. Also reword "Currently…" for "the defined values are".
Ericsson: we are assigning values for the proprietary scheme. How many values should we assign? Qualcomm replied that 8 values but Ericsson found them too many and suggested 4 instead.
 
 
 
 		revised No S3‑181497  
S3‑181342 SUCI - protection schemes output sizes Ericsson CR Agreement
7.2.14Privacy
 		Yes
Yes
 		merged No S3‑181495  
S3‑181343 SIDF - NF discovery with SUCI Ericsson CR Agreement
7.2.14Privacy
 		Yes
Yes
Docomo: operators need to pre-provision this in the UE.There is a need to standardise the pre-provision of routing information. I don’t agree with using the Home Network public key identifier .
Qualcomm: enforce different entities to use different keys seems to be a good idea.
ORANGE: this is not a SA3 issue, it's a CT1 issue. We don’t know all the other routing aspects that are being handled by other groups.
NEC: we need to standardise these parameters.
Interdigital didn’t agree with having this.
Vodafone: SA3 has an interest in protecting the routing information.
ORANGE: send an LS to CT1and SA2 to check how they see the routing so we know whether we need to protect the information.
KPN supported this.
NEC, Qualcomm: mandate the routing information with a "shall".
This was taken offline.
 
 		not pursued No    
S3‑181344 Corrections to 5G AKA Ericsson CR Agreement
7.2.8Primary authentication
 		Yes
Yes
 		revised No S3‑181453  
S3‑181345 Handling of synchronization failure Ericsson CR Agreement
7.2.8Primary authentication
 		Yes
Yes
Overlaps with 298.
It was commented that it was not possible anymore to delete the clause and renumber, given that it's a TS under change control.
 
 		merged No S3‑181453  
S3‑181346 Corrections to EAP-AKA’ Ericsson CR Agreement
7.2.8Primary authentication
 		Yes
Yes
The Annex A changes will go into tdoc 455. The rest is merged into 453.
 		merged No S3‑181453  
S3‑181347 Corrections on ngKSI and SUPI handling with EAP TLS Ericsson CR Agreement
7.2.8Primary authentication
 		Yes
Yes
 		revised No S3‑181470  
S3‑181348 Revocation of certificates with EAP-TLS Ericsson CR Agreement
7.2.8Primary authentication
 		Yes
Yes
 		revised No S3‑181471  
S3‑181349 Clarifications on unused 5G authentication vectors, and remaning authentication data Ericsson CR Agreement
7.2.8Primary authentication
 		Yes
Yes
ZTE: one auth vector for 5G as agreed, so we don’t have unused vectors.
Ericsson: we try to clarify that the vector is used.
ZTE found this situation hard to understand. They suggested a note for this.
 
 		merged No S3‑181453  
S3‑181350 Corrections to the lengths of input parameters in A.2 and A.4 Ericsson CR Agreement
7.2.8Primary authentication
 		Yes
Yes
 		merged No S3‑181454  
S3‑181351 Corrections related to authentication related services Ericsson CR Agreement
7.2.8Primary authentication
 		Yes
Yes
Some part will go to 453
merged No S3‑181453  
S3‑181352 NONCE as input to horizontal key derivation and calculation/verification of NAS MAC-I in NASC Ericsson CR Agreement
7.2.3Mobility
 		Yes
Yes
 		not pursued No    
S3‑181353 Corrections and clarifications on handover handling Ericsson CR Agreement
7.2.3Mobility
 		Yes
Yes
Huawei needed more time to evaluate this. It was decided to bring it back during the next meeting.
 		not pursued No    
S3‑181354 Generalization of key derivation in NG-RAN to cover both gNBs and ng-eNBs Ericsson CR Agreement
7.2.2Key derivation
 		Yes
Yes
Qualcomm: on 6.11, details regarding LTE need to be added. This was agreed and noted for a future contribution.
 
 		agreed No    
S3‑181355 Discussion on KAUSF identifier Ericsson discussion Agreement
7.2.1Key hierarchy
 		Yes
Yes
 		noted No    
S3‑181356 Identifier for Kausf Ericsson CR Agreement
7.2.1Key hierarchy
 		Yes
Yes
 		revised No S3‑181464  
S3‑181357 Correction of KAUSF source for 5G AKA Ericsson CR Agreement
7.2.1Key hierarchy
 		Yes
Yes
 		merged No S3‑181434  
S3‑181358 CR to Clause 10.2.1 on Emergency Call redirection Nokia CR Approval
7.2.6Security context
 		Yes
Yes
 		revised No S3‑181568  
S3‑181359 CR for NAI Clarification Nokia CR Approval
7.2.8Primary authentication
 		Yes
Yes
ORANGE: there is no such a case in SA2. The change in the normative part is not acceptable.
Also, no normative language in the Annex B (which is informative).
 
 
 		revised No S3‑181472  
S3‑181360 CAPIF requirements NEC Corporation pCR Approval
7.6Security Aspects of Common API Framework for 3GPP Northbound APIs (CAPIF_Sec) (Rel-15)
 		Yes
Yes
China Mobile: what is additional level of authentication?
NEC: I want to express that there should be something more.
Nokia,Samsung: this requirement is not needed.
 
 		noted No    
S3‑181361 Editorial corrections to TS 33.122 v0.1.0 NEC Corporation pCR Approval
7.6Security Aspects of Common API Framework for 3GPP Northbound APIs (CAPIF_Sec) (Rel-15)
 		Yes
Yes
 		approved No    
S3‑181362 Binding of communication endpoins to the derivation of AEFpsk NEC Corporation pCR Approval
7.6Security Aspects of Common API Framework for 3GPP Northbound APIs (CAPIF_Sec) (Rel-15)
 		Yes
Yes
 		noted No    
S3‑181363 CR to Clause 7.2.1 Non-3gpp access registration EN Nokia CR Approval
7.2.11non-3GPP access
 		Yes
Yes
 		merged No S3‑181574  
S3‑181364 Security procedure for the AEF to obtain API invoker’s authorization rights NEC Corporation pCR Approval
7.6Security Aspects of Common API Framework for 3GPP Northbound APIs (CAPIF_Sec) (Rel-15)
 		Yes
Yes
 		noted No    
S3‑181365 Security procedure for onboarding API invokers to CAPIF NEC Corporation pCR Approval
7.6Security Aspects of Common API Framework for 3GPP Northbound APIs (CAPIF_Sec) (Rel-15)
 		Yes
Yes
 		merged No S3‑181514  
S3‑181366 Clarification of access token generation to clause 5.2.2.3 Method 3 – Token Based authorization NEC Corporation pCR Approval
7.6Security Aspects of Common API Framework for 3GPP Northbound APIs (CAPIF_Sec) (Rel-15)
 		Yes
Yes
 		revised No S3‑181507  
S3‑181367 Error Correction in subclause 11.1.1 InterDigital, Inc. CR Approval
7.2.9Secondary authentication
 		Yes
Yes
 		merged No S3‑181569  
S3‑181368 CAPIF re-organizing NEC Corporation pCR Approval
7.6Security Aspects of Common API Framework for 3GPP Northbound APIs (CAPIF_Sec) (Rel-15)
 		Yes
Yes
 		revised No S3‑181529  
S3‑181369 API invoker obtaining authorization from CAPIF core fuction to access service API NEC Corporation pCR Approval
7.6Security Aspects of Common API Framework for 3GPP Northbound APIs (CAPIF_Sec) (Rel-15)
 		Yes
Yes
 		noted No    
S3‑181370 Authentication between API invoker and AEF upon the service invocation NEC Corporation pCR Approval
7.6Security Aspects of Common API Framework for 3GPP Northbound APIs (CAPIF_Sec) (Rel-15)
 		Yes
Yes
 		noted No    
S3‑181371 Resolving EN on sending SUCI in the Identifier Response message NEC Europe Ltd CR Approval
7.2.14Privacy
 		Yes
Yes
 		revised No S3‑181476  
S3‑181372 Update of information on Keys for AUSF in home network NEC Europe Ltd CR Approval
7.2.1Key hierarchy
 		Yes
Yes
 		revised No S3‑181434  
S3‑181373 Removal of error in step 10 from the figure NEC Europe Ltd CR Approval
7.2.9Secondary authentication
 		Yes
Yes
 		merged No S3‑181569  
S3‑181374 Key handling at transitions between RRC-INACTIVE and RRC-CONNECTED Samsung CR  
7.2.4AS security
 		Yes
Yes
 		not pursued No    
S3‑181375 Authentication method negotiation for 5G NEC Europe Ltd CR Approval
7.2.8Primary authentication
 		Yes
Yes
 		not pursued No    
S3‑181376 Clarifying the condition when ePDG sends its certificate in untrusted non-3GPP access Nokia CR Agreement
7.10.1SAE/LTE Security
 		Yes
Yes
 		revised No S3‑181506  
S3‑181377 Authentication method indication for 5G NEC Europe Ltd CR Approval
7.2.8Primary authentication
 		Yes
Yes
 		not pursued No    
S3‑181378 pCR to TR 33.834 – updated evaluation of solution #1 Vodafone Group Plc pCR Approval
8.4Study on Long Term Key Update Procedures (FS_LTKUP) (Rel-15)
 		Yes
Yes
ORANGE opted to remove the new text in the conclusion.
Vodafone found this as a showstopper for the study. They found it essential to have this evaluation and not inlcuding this would make them object to the approval of the TR.
The Vice Chair adviced both companies to have offline discussions and solve their differences before next meeting.
KPN supported Vodafone. SA3 would not evaluate properly the solution when removing this sentence.
G&D: the user interaction part is already mentioned in the TR, so there is no point with duplicating it.
Qualcomm supported Vodafone.
 
 
 		noted No    
S3‑181379 TS 33.501 Resolving Editors notes 5.10.1 Security Visibility BT plc CR Approval
7.2.7Visibility and Configurability
 		Yes
Yes
Vodafone: most customers will not understand this. It's a bit confusing.
ORANGE: this annex goes beyond the scope of 3GPP.
Docomo, Qualcomm: only remove the editor's note. No other change should happen. ORANGE supported this.
Vodafone: add an editor's note on what to show to the user and when. Docomo replied that this discussion had taken part already and it was agreed that this was exposed at application level.
Qualcomm: too late for Rel-15 for such editor's note.
 
 		revised No S3‑181565  
S3‑181380 Resolving EN on Kausf identification NEC Europe Ltd CR Approval
7.2.1Key hierarchy
 		Yes
Yes
Nokia: there is only one KAUSF, what's the use case for a separate identifier? There cannot be multiple KAUSF.
Ericsson: might be needed for the UE.
Qualcomm: we don’t want the KAUSF used to track the UE.
DT and ZTE agreed with Nokia and Qualcomm.  
 		not pursued No    
S3‑181381 Editor’s Note on NRF to NRF authentication when there is a non transparent proxy (SEPP) between them Nokia CR Agreement
7.2.13.2Other
 		Yes
Yes
The change was agreed and merged into 486.
 		merged No S3‑181486  
S3‑181382 Fast re-authentication procedure NEC Europe Ltd CR Approval
7.2.8Primary authentication
 		Yes
Yes
 		not pursued No    
S3‑181383 Security aspects of handover between 3GPP and untrusted non-3GPP accesses NEC Europe Ltd CR Approval
7.2.11non-3GPP access
 		Yes
Yes
ZTE: already covered by multiple registration, we don’t need this.
NEC: this scenario is mentioned in the SA2 document.
Qualcomm:this is already covered.Ericsson supported this.
 
 		not pursued No    
S3‑181384 CAPIF – Topology Hiding Samsung, MSI pCR  
7.6Security Aspects of Common API Framework for 3GPP Northbound APIs (CAPIF_Sec) (Rel-15)
 		Yes
Yes
Nokia: clarification by adding transport security layer.
 
 		revised No S3‑181538  
S3‑181385 Editor’s Note on per UE subscription level authorization in NRF Nokia CR Agreement
7.2.13.2Other
 		Yes
Yes
 		merged No S3‑181487  
S3‑181386 UDM routing information in SUCI NEC Europe Ltd CR Approval
7.2.14Privacy
 		Yes
Yes
Same topic as tdoc 343.
Nokia: something like this should not be mandated.
It was agreed to include this in the LS in 494.
 
 		not pursued No    
S3‑181387 CAPIF – Key Derivation Samsung, MSI pCR  
7.6Security Aspects of Common API Framework for 3GPP Northbound APIs (CAPIF_Sec) (Rel-15)
 		Yes
Yes
 		revised No S3‑181515  
S3‑181388 pCR to TR 33.834 – updated evaluation of solution #2 Vodafone Group Plc pCR Approval
8.4Study on Long Term Key Update Procedures (FS_LTKUP) (Rel-15)
 		Yes
Yes
G&D: a paragraph from the key issue is copy-pasted in the solution.
Vodafone: because it is essential.
It was agreed to make a summary instead of copying it.
 
 
 		revised No S3‑181531  
S3‑181389 CAPIF – Editor’s note resolution on authorization mechanism Samsung, MSI pCR  
7.6Security Aspects of Common API Framework for 3GPP Northbound APIs (CAPIF_Sec) (Rel-15)
 		Yes
Yes
 		revised No S3‑181516  
S3‑181390 CAPIF – Update on CAPIF-2e Security procedure Samsung pCR  
7.6Security Aspects of Common API Framework for 3GPP Northbound APIs (CAPIF_Sec) (Rel-15)
 		Yes
Yes
 		approved No    
S3‑181391 CAPIF – Update on CAPIF-2 authorization Samsung pCR  
7.6Security Aspects of Common API Framework for 3GPP Northbound APIs (CAPIF_Sec) (Rel-15)
 		Yes
Yes
 		merged No S3‑181540  
S3‑181392 CAPIF – API Invoker on boarding Samsung pCR  
7.6Security Aspects of Common API Framework for 3GPP Northbound APIs (CAPIF_Sec) (Rel-15)
 		Yes
Yes
 		revised No S3‑181514  
S3‑181393 SUCI - readiness to protection schemes update in future Ericsson CR Agreement
7.2.14Privacy
 		Yes
Yes
 		revised No S3‑181496  
S3‑181394 SBA: Example for SEPP Protection Policies Ericsson discussion Information
7.2.13.1Interconnect (SEPP related)
 		Yes
Yes
 		noted No    
S3‑181395 Application layer solution for N32: rewriting of HTTP message into JSON objects Ericsson other Approval
7.2.13.1Interconnect (SEPP related)
 		Yes
Yes
 		approved No    
S3‑181396 Rel-15 fallback solution for Interconnect (N32) Ericsson discussion Endorsement
7.2.13.1Interconnect (SEPP related)
 		Yes
Yes
 		withdrawn Yes    
S3‑181397 To-Do-list for application layer solution Ericsson discussion Information
7.2.13.1Interconnect (SEPP related)
 		Yes
Yes
 		noted No    
S3‑181398 Need for certificate-based N3IWF authentication in non-3GPP access Ericsson discussion Endorsement
7.2.11non-3GPP access
 		Yes
Yes
 		noted No    
S3‑181399 Use of certificates for IKEv2 in non-3GPP access Ericsson CR Agreement
7.2.11non-3GPP access
 		Yes
Yes
Qualcomm: there is security value in the removed part of step 5. There are operators who could use this.Besides, it's open to DoS attacks on the UE if we don’t leave it. Lenovo supported Qualcomm.
Ericsson: this is a big impact on the whole system since the operator has to provide certificates to all Ues.
Qualcomm: some operators have implemented this already.
 
 		not pursued No    
S3‑181400 Use of fields in CMPv2 Ericsson CR Agreement
7.10.20Other work items
 		Yes
Yes
Nokia: this may be a problem for existing implementations. Huawei agreed with Nokia, not needed.
 		not pursued No    
S3‑181401 TLS 1.3 Ericsson CR Agreement
7.10.20Other work items
 		Yes
Yes
Deutsche Telekom supported adding TLS and agreed with having it in Rel-15.
NCSC: it is saying already that the highest TLS version on both endpoints shall be used and this could lead to problems. Mandating TLS 1.3 is not ideal.
Qualcomm was concerned about mandating it for Rel-15. Recommend it for Rel-15 and mandate it for Rel-16. It is too late for Rel-15.
Comments were taken and it was agreed to bring it back during the next meeting,
The Chair commented that there was a draft IETF mentioned there and the Chair would tell them.
not pursued No    
S3‑181402 pCR: Local configuration of message protection policy in SEPP Nokia other Approval
7.2.13.1Interconnect (SEPP related)
 		Yes
Yes
Ericsson: This is a solution description with several alternatives but it is written with  normative language.
 
 		revised No S3‑181482  
S3‑181403 Remote provisioning of message protection policies in partner SEPPs Nokia other Approval
7.2.13.1Interconnect (SEPP related)
 		Yes
Yes
 		revised No S3‑181483  
S3‑181404 pCR to TR 33.834 – updates to solution #4 Vodafone Group Plc pCR Approval
8.4Study on Long Term Key Update Procedures (FS_LTKUP) (Rel-15)
 		Yes
Yes
ORANGE: Mention that there may be Low impact on the HSS. Not protected against Man in the Middle in some use cases.
Gemalto:"preferred" among the 4 solutions, clarify this in the conclusion.
 
 		revised No S3‑181532  
S3‑181405 SBA Authentication issues Ericsson discussion Endorsement
7.2.13.2Other
 		Yes
Yes
Nokia proposed to add service layer authentication not to be specified in Rel-15 in proposal one. This was agreed.
The rest of proposal one was also modified to add an explicit chain of trust.
 		revised No S3‑181485  
S3‑181406 Intra PLMN NF to NF authentication Ericsson CR Agreement
7.2.13.2Other
 		Yes
Yes
DT: When reliying on token based authentication I'm not sure that we should mandate TLS. The "shall" is a "should".
 
 
 		revised No S3‑181486  
S3‑181407 SBA: Inter-PLMN routing and TLS issues Ericsson discussion Discussion
7.2.13.2Other
 		Yes
Yes
Docomo didn’t agree with the bump in TLS.
Nokia suggested some changes that were accepted in the revision.
noted No    
S3‑181408 SBA: Token Based Authorization for the inter-PLMN case Ericsson discussion Endorsement
7.2.13.2Other
 		Yes
Yes
 		noted No    
S3‑181409 Inter PLMN routing and TLS: Solution Options Ericsson other Approval
7.2.13.2Other
 		Yes
Yes
 		revised No S3‑181490  
S3‑181410 pCR to TR 33.834 – updates to solution #5 Vodafone Group Plc pCR Approval
8.4Study on Long Term Key Update Procedures (FS_LTKUP) (Rel-15)
 		Yes
Yes
Gemalto didn’t agree with having a conclusion like this.
 
 		noted No    
S3‑181411 Reference corrections in clause 5 Nokia CR  
7.2.16Others
 		Yes
Yes
Ericsson: the references should go to Annex D instead.
 		revised No S3‑181577  
S3‑181412 Reference corrections in clause 6 Nokia CR  
7.2.16Others
 		Yes
Yes
 		revised No S3‑181578  
S3‑181413 Reference corrections in clause 8 Nokia CR  
7.2.16Others
 		Yes
Yes
 		revised No S3‑181579  
S3‑181414 Collection of editorial corrections Nokia CR  
7.2.16Others
 		Yes
Yes
 		revised No S3‑181580  
S3‑181415 pCR to TR 33.834 – updates to solution #6 Vodafone Group Plc pCR Approval
8.4Study on Long Term Key Update Procedures (FS_LTKUP) (Rel-15)
 		Yes
Yes
ORANGE: Let's add that the solution doesn't provide enough information to provide a conclusion.
MCC: instead of editor's notes, refer to "not addressed in this document".
 
 		revised No S3‑181534  
S3‑181416 pCR to 33.843 - collection of editorial fixes Vodafone Group Plc pCR Approval
8.4Study on Long Term Key Update Procedures (FS_LTKUP) (Rel-15)
 		Yes
Yes
 		revised No S3‑181523  
S3‑181417 pcr TO 33.834 - Addition of Conclusion (comment to S3-181247) Vodafone Group Plc pCR Approval
8.4Study on Long Term Key Update Procedures (FS_LTKUP) (Rel-15)
 		Yes
Yes
It was agreed that the outcome of this study was not to recommend any future normative work based on its outcome.This was captured in the revision.
 
 		revised No S3‑181535  
S3‑181418 Authorization across N32 - pCR to Living Document: Security of Service Based Architecture of 5G phase 1 NTT DOCOMO other Approval
7.2.13.1Interconnect (SEPP related)
 		Yes
Yes
Nokia: error handling with a "shall" is too strong.
Docomo: if you reject a message you need to send back an error.
 
 		revised No S3‑181479  
S3‑181419 [eMCSEC] Removal of Editor’s note in Clause I.3.4 NCSC CR Agreement
7.3Mission Critical Security Enhancements (eMCSec) (Rel-15)
 		Yes
Yes
 		revised No S3‑181488  
S3‑181420 [eMCSEC] Resolution of editor’s notes within Clause 10 on logging, audit and discreet monitoring. NCSC CR Agreement
7.3Mission Critical Security Enhancements (eMCSec) (Rel-15)
 		Yes
Yes
 		revised No S3‑181489  
S3‑181421 [MCSEC] Addition of test vector for MIKEY-SAKKE UID NCSC CR Agreement
7.10.18Security of the Mission Critical Service (MCSec)
 		Yes
Yes
 		agreed No    
S3‑181422 [eMCSEC] Addition of test vector for MIKEY-SAKKE UID NCSC CR Agreement
7.3Mission Critical Security Enhancements (eMCSec) (Rel-15)
 		Yes
Yes
 		agreed No    
S3‑181423 [MCSEC] Removal of Editor’s note in Clause 5.1.3.1. NCSC CR Agreement
7.10.18Security of the Mission Critical Service (MCSec)
 		Yes
Yes
 		agreed No    
S3‑181424 [eMCSEC] Removal of Editor’s note in Clause 5.1.3.1. NCSC CR Agreement
7.3Mission Critical Security Enhancements (eMCSec) (Rel-15)
 		Yes
Yes
 		agreed No    
S3‑181425 SBA: Commenting contribution on S3-181408 Nokia discussion Decision
7.2.13.2Other
 		Yes
Yes
 		noted No    
S3‑181426 Updates to Solution #6 in SoR Living Doc Qualcomm Incorporated, T-Mobile US, DT other Approval
7.7PLMN RAT selection (Steering of Roaming)
 		Yes
Yes
Vodafone: VPLMN will not allow the message go throguh but you want to be in that network. How do you deal with operators excluding the steering of roaming?There will be operators who will not implement this.
ORANGE: if a country has no VPLMNs not implementing this, what happens with the UE?
Qualcomm: the UE will select the PLMN as described by CT1.
ORANGE didn’t agree with the conclusion, so it was removed.
Qualcomm commented that a solution was needed for the next meeting and a technical vote may be necessary.
 
 		revised No S3‑181502 S3‑181332
S3‑181427 SBA: A framework for application layer protection scheme in SEPP Nokia discussion Endorsement
7.2.13.1Interconnect (SEPP related)
 		Yes
Yes
 		noted No    
S3‑181428 LS on SoR mechanism S3i180141 LS in  
7.7PLMN RAT selection (Steering of Roaming)
 		Yes
Yes
BT: there are some countries where turning on encryption would be a problem.
ORANGE: LI aspects are to be assessed, it should be done in the next meeting. Qualcomm agreed, but not to add it to their solution presented in the current meeting.
Ericsson commented that this was already in the living document.
 		noted No    
S3‑181429 LTE and the upcoming 5G standard GSMA LS in  
6.4GSMA
 		Yes
Yes
Colin (BT): it's true that there is no user plane integrity protection in LTE. We don't mandate in 5G but we say support, mandating depends on policy. We cannot mandate thue "use".
Alf (Docomo): a number of apps running in the phone do not properly verify the service they are talking to, and this is a bigger problem than the website itself.
Hans (DT): this is an attack to be considered seriously. We need to decided if the 64Kbits minimu integrity protection is supported by SA3 or we need the integrity protection for everything.
Qualcomm: in 5G we have mandated the support of integrity protection, and all the way up to full rate. For LTE we may need to consider it.
Alf (Docomo): we cannot get to a complete solution during this meeting.gNodeB may switch off integrity protection if it is overloaded, this is an issue to be studied.
Sander(KPN): there are things that can be done at application layer level. Not an attack only to LTE.
 
 		replied to No    
S3‑181430 LS on paging with IMSI/SUCI in 5GS C1-181791 LS in  
7.2.15Incoming and outgoing LSes
 		Yes
Yes
Discussed together with tdoc 183.
 
 		replied to No    
S3‑181431 Discussion on ID binding in Secondary Authentication Huawei, Hisilicon, China Southern Power Grid,China Unicom discussion Endorsement
7.2.9Secondary authentication
 		Yes
Yes
 		noted No   S3‑181248
S3‑181432 ID binding in Secondary Authentication Huawei, Hisilicon, China Southern Power Grid CR Approval
7.2.9Secondary authentication
 		Yes
Yes
Nokia: no requirements for the AAA server. The text in step 13 was made a note.
Ericsson: we don’t agree with the changes.We are changing the SA2 procedure and misusing the GPSI for authentication.
Qualcomm and ORANGE didn’t support this contribution either.
Huawei: GPSI is not used for seconday authentication here.
This was taken offline.
 
 
 		not pursued No   S3‑181249
S3‑181433 Security options Huawei, Hisilicon pCR Approval
8.3Study on security aspects of 5G Network Slicing Management (FS_ NETSLICE-MGT_Sec) (Rel-15)
 		Yes
Yes
ORANGE: which functionality of SA5 specification is this related to? SA5 doesn't define the characteristics of a specific slice.We protect the interface and the template (we don’t care about the content of the template).
 
 		noted No   S3‑181254
S3‑181434 Corrections on key hierarchy,key derivation, and distribution scheme NEC Europe Ltd, ZTE Corporation, Ericsson,Nokia CR Approval
7.2.1Key hierarchy
 		Yes
Yes
 		agreed No   S3‑181372
S3‑181435 Way forward for Interconnect (N32) security Ericsson, Deutsche Telekom, Nokia discussion Endorsement
7.2.13.1Interconnect (SEPP related)
 		Yes
Yes
Nokia: Give a general solution for end-to-end and enhance it for Rel-16.
Docomo: get the functionality in Rel-15 and fix it with cat F CRs.
We don’t want IPX interconnects pre Rel-15 and post Rel-15. I prefer to have this in Rel-15 if we are close enough to completion and then fix with cat-F CRs. There is still time. ORANGE agreed with this.
This had to be taken offline.
 
 
 
 
 
 		revised No S3‑181509  
S3‑181436 Changes to definition clause for drafting rule conformity Nokia CR Agreement
7.2.16Others
 		Yes
Yes
 		revised No S3‑181475  
S3‑181437 Editorial changes to clause 10 and 12 Nokia CR Agreement
7.2.16Others
 		Yes
Yes
 		revised No S3‑181582  
S3‑181438 Editorial changes to clause 9 Nokia CR Agreement
7.2.13.2Other
 		Yes
Yes
This needed some cleaning up for which there was no time for the current meeting.
 
 		not pursued No    
S3‑181439 Editorials to 33.501 NTT DOCOMO CR Agreement
7.2.16Others
 		Yes
Yes
 		revised No S3‑181576 S3‑181188
S3‑181440 F1-C Protection Orange Spain,Deutsche Telekom,KPN,Huawei,HiSilicon CR Approval
7.2.4AS security
 		Yes
Yes
Ericsson: IPSec for these interfaces is not cloud friendly. TLS or dTLS are preferred. We agree with the last requirement.
 
 		agreed No   S3‑181280
S3‑181441 New SID on security aspects on support of PARLOS SPRINT Corporation SID new Agreement
8.8New study item proposals
 		Yes
Yes
 		agreed No   S3‑181185
S3‑181442 SID on security of 5WWC Huawei; HiSilicon SID new Agreement
8.8New study item proposals
 		Yes
Yes
 		agreed No   S3‑181216
S3‑181443 Reply to: LTE and the upcoming 5G standard NTT-Docomo LS out approval
6.4GSMA
 		Yes
Yes
It was commented that some work should be done in SA3 about DNS attacks.
The Chair commented that 3GPP CVD was on its way to solve these kind of issues.
 
 		approved No    
S3‑181444 Study on evolution of Cellular IoT security for the 5G System Ericsson SID new Agreement
8.8New study item proposals
 		Yes
Yes
ORANGE: I asked in SA2 about this.There are no key issues such as these in SA2. I don’t siupporving both groups working on the same things (last bullet in objectives).
Vodafone didn't agree with the remove provisioning part.
Ericsson: let's not anticipate what SA2 does, we work on their work anyway.
DT supported ORANGE and Vodafone.
ORANGE: let's make it very clear that we are based solely on SA2, not other groups.
Vodafone: no rush, we can decide next meeting.
KPN: DoS attacks in scope of this WID?
Ericsson confirmed this.
 
Sony considered that it was worth having SA1 as a referenced group in the objectives,since they are giving us requirements.
ORANGE: I want to avoid that if SA2 concludes in their study that there will be no provisioning, we have to conclude the same. ORANGE pointed out that SA3 should stick to the SA2's agreements.
Qualcomm: there may be security requirements that go against SA2's conclusions.
Vodafone supported ORANGE: we don’t want to study provisioning when there are groups not studying it. Qualcomm agreed with this. ORANGE wanted to mention specifically SA2 and not 3GPP groups in general working on provisioning.
 
It was asked to be minuted as agreement:
If provisioning is not treated in SA2, SA3 will not be consider it in this study.
 
.
 
 
 		agreed No   S3‑181306
S3‑181445 Missing PEI requirements Motorola Mobility, Lenovo CR Approval
7.2.14Privacy
 		Yes
Yes
It was agreed to remove the new clause.
ORANGE: the second requirement was discussed in the study phase, and we concluded that it should be in Rel-16. Todor didn’t agree with the first requirement, but it was agreed to reword it.
Qualcomm and Docomo supported the second requirement.It was capturing a requirement that it is already in LTE.
Docomo: the agreement is that we want to send the PEI only when there is a NAS security setup.
 
 
 
 
 		revised No S3‑181500 S3‑181271
S3‑181446 Reply to: LS on one step MO SMS procedure Ericsson LS out approval
7.2.15Incoming and outgoing LSes
 		Yes
Yes
 		approved No    
S3‑181447 Reply to: UE capability related to integrity protection of DRBs Intel LS out approval
7.2.15Incoming and outgoing LSes
 		No
Yes
 		withdrawn Yes    
S3‑181448 Reply to: LS on Security aspects of supporting LTE connected to 5GC Qualcomm LS out approval
7.2.15Incoming and outgoing LSes
 		Yes
Yes
 		approved No   S3‑181324
S3‑181449 Use type information as a SUCI construction input paramter in Annex C LG Electronics CR Agreement
7.2.14Privacy
 		Yes
Yes
ORANGE didn’t agree with this. Same concerns as the last meeting.
Qualcomm: not a good practice to use things for IMSI privacy for other use cases. They didn’t agree with this either.
 
 		not pursued No   S3‑181270
S3‑181450 Reply to: LS on security for inactive state Huawei, Ericsson LS out approval
7.2.15Incoming and outgoing LSes
 		Yes
Yes
Discussions on the security algorithm negotiation: Ericsson and Nokia didn’t consider that a new mechanism was required.
It was commented that this was a RAN2 decision and not SA3's. It was agreed to have this sentence on the LS.
 
 
 		approved No    
S3‑181451 Reply to: LS on secured Signalling-only connection Nokia LS out approval
7.2.4AS security
 		Yes
Yes
 		approved No    
S3‑181452 Reply to: LS on paging with IMSI/SUCI in 5GS Nokia LS out approval
7.2.15Incoming and outgoing LSes
 		Yes
Yes
 		approved No    
S3‑181453 Clarifications to: Authentication procedures Ericsson, KPN N.V., Nokia, ZTE Corporation, Huawei, Hisilicon, NTT DOCOMO CR Agreement
7.2.8Primary authentication
 		Yes
Yes
 		agreed No   S3‑181344
S3‑181454 Clarifications to: Key derivation functions Nokia,Ericsson CR Agreement
7.2.8Primary authentication
 		Yes
Yes
 		agreed No    
S3‑181455 Clarifications to: Security contexts KPN,Ericsson, Nokia CR Agreement
7.2.8Primary authentication
 		Yes
Yes
 		agreed No    
S3‑181456 Clarifications to: Security handling in state transitions Nokia,Ericsson CR Agreement
7.2.8Primary authentication
 		Yes
Yes
 		agreed No    
S3‑181457 Corrections to: Security procedures for non-service based interfaces Docomo CR Agreement
7.2.8Primary authentication
 		No
Yes
 		withdrawn Yes    
S3‑181458 Corrections related to authentication related services Ericsson,Nokia CR Agreement
7.2.8Primary authentication
 		Yes
Yes
 		agreed No   S3‑181289
S3‑181459 Non-random IVs in CTR mode NCSC pCR Approval
8.5Study on Supporting 256-bit Algorithms for 5G (FS_256-Algorithms) (Rel-16)
 		Yes
Yes
 		approved No   S3‑181284
S3‑181460 Clarifications to: Authentication framework Ericsson, KPN N.V., Nokia, NTT Docomo CR Agreement
7.2.8Primary authentication
 		Yes
Yes
 		agreed No    
S3‑181461 Deletion of Editor's Notes in clause 6.1.2 and 6.1.3 and restructuring KPN N.V. CR Agreement
7.2.8Primary authentication
 		Yes
Yes
 		merged No S3‑181453 S3‑181167
S3‑181462 Clarifications to: Requirements Nokia, Gemalto, CATT, Lenovo, Motorola Mobility, Ericsson, ZTE CR Agreement
7.2.8Primary authentication
 		Yes
Yes
It was asked to be minuted the following:
 
Reason for change: S3-181287: Alignment between 23.501/23.502 and 33.501 specs needed to avoid duplication. AUSF is security related NF. AUSF requirements are not specified in SA3 spec yet.
S3-181467: SIDF is service from UDM. Requirements missing.
S3-181226: redundant requirement
S3-181227: unclarity which operator’s decision
S3-181492: shift of SBA related requirements needed
S3-181500: Missing PEI requirements
S3-181155: Useless category for Serving network authorization
S3-181439: editorial collection related to clause 5
S3-181577: wrong references on NIA and NEA algs
S3-181581: implement change agreed in last meeting: tamper resistant hardware to be replaced by USIM (in SA3#90bis, ed.note was added, but USIM not)
 
 
Summary of change: S3-181287: Using the restructering exercise where SEAF requirements are moved under AMF to rename clause 5.6 and capture AUSF requirements here.
S3-181467: Corrections to title and including
S3-181226: remove redundant requirement
S3-181227: based on home operator’s decision (“home” added)
S3-181492: void of NEF clause, shift of text and addition of NRF related requirements under SBA
S3-181500: Include PEI requirements similar to IMEI.
S3-181155: Remove of useless category for Serving network authorization
S3-181439: editorial collection related to clause 5
S3-181577: correcting references on NIA and NEA algs to refer to Annex D
S3-181581: replace tamper resistant hardware with “USIM”
 
  
Consequences if not approved: No alignment. No requirements for the most important security function in home network. PEI storage and handling in the ME is unclear. Missing references.
 
  
 		agreed No    
S3‑181463 Clarifications to: Linking increased home control to subsequent procedures Nokia CR -
7.2.8Primary authentication
 		Yes
Yes
 		agreed No   S3‑181290
S3‑181464 Identifier for Kausf Ericsson CR Agreement
7.2.1Key hierarchy
 		No
Yes
 		merged No S3‑181460 S3‑181356
S3‑181465 Clarifications to: Initiation of authentication and selection of authentication method Nokia,ZTE CR -
7.2.8Primary authentication
 		Yes
Yes
 		agreed No   S3‑181293
S3‑181466 Editorial modification on authentication method selection ZTE Corporation CR Approval
7.2.8Primary authentication
 		Yes
Yes
 		merged No S3‑181465 S3‑181154
S3‑181467 UDM requirements Nokia, Gemalto CR -
7.2.8Primary authentication
 		Yes
Yes
 		merged No S3‑181462 S3‑181288
S3‑181468 LS on avoiding race conditions in 5G AKA KPN LS out Approval
7.2.8Primary authentication
 		Yes
Yes
 		approved No    
S3‑181469 SN Id parameter length Nokia CR -
7.2.8Primary authentication
 		Yes
Yes
 		merged No S3‑181454 S3‑181296
S3‑181470 Clarifications to: Using additional EAP methods for primary authentication Ericsson, Nokia, Huawei, HiSilicon, NTT DOCOMO CR Agreement
7.2.8Primary authentication
 		Yes
Yes
 		agreed No   S3‑181347
S3‑181471 Revocation of certificates with EAP-TLS Ericsson CR Agreement
7.2.8Primary authentication
 		Yes
Yes
 		merged No S3‑181470 S3‑181348
S3‑181472 Add Realm part in NAI Nokia CR Approval
7.2.8Primary authentication
 		Yes
Yes
 		merged No S3‑181470 S3‑181359
S3‑181473 Reply to: LS Reply on SBI Design and its Security Implications NTT-Docomo LS out approval
7.2.13.1Interconnect (SEPP related)
 		Yes
Yes
 		approved No    
S3‑181474 Living Document: Security of Service Based Architecture of 5G phase 1 China Mobile Group Device Co. other -
7.2.13.2Other
 		Yes
Yes
 		approved No   S3‑181236
S3‑181475 Clarifications to definitions and abbreviations Nokia,KPN CR Agreement
7.2.16Others
 		Yes
Yes
 		agreed No   S3‑181436
S3‑181476 Resolving EN on sending SUCI in the Identifier Response message NEC Europe Ltd,Docomo CR Approval
7.2.14Privacy
 		Yes
Yes
 		merged No S3‑181496 S3‑181371
S3‑181477 Reply LS on SoR mechanism C1-182490 LS in Discussion
7.7PLMN RAT selection (Steering of Roaming)
 		Yes
Yes
Qualcomm proposed to respond with option B.
Huawei: how is the USIM preconfigured with the list? If the HPLMN doesn’t know where the UE is going? They prefered option A.
The preference was option B.
ORANGE: we are building a solution in the fly that wasn't in the scope of 5G. Steering of roaming is about business relationships; we cannot make a solution without business requirements and we haven’t had any contact and input with GSMA. We should take this to Rel-16.There is no WID about this in 3GPP.
T-Mobile: this is captured in SA1.
The Chair commented that this is a LS coming from CT1.
ORANGE: the requirement from SA1 doesn’t need this. CT1 has started work that hasn’t been agreed at all in 3GPP. The Chair commented that this issue should be discussed at SA plenary level, and not in SA3. SA3's task  was to respond CT1.
T-Mobile: it’s about security concerns on the options here.
Vodafone: option B is better but it misses how to protect the message, and the confidentiality and integrity protection.
ORANGE: we cannot do this work in Rel-15.
Qualcomm wanted this to go for Rel-15. The issue needed to be discussed at Plenary level. Let's answer that option B is the way to go. Ericsson agreed.
It was agreed to send the LS with the preference to option B.
The Chair commented that if something had to be done, like stopping the activity, it should be done in another group and not in SA3.
ORANGE: if confidentiality protection needs to be switched off as per LI requirements we wouldn't be able to carry out the security analysis properly. We cannot guarantee that this can be done in Rel-15.
KPN: ORANGE can object to this work in the SA plenary.
 
 
 
 
 
 		replied to No    
S3‑181478 Working procedure and table of clause-CRs Nokia discussion discussion
7.2.16Others
 		Yes
Yes
The work of Anja(Nokia) was appreciated by the group.
 
 		noted No    
S3‑181479 Authorization across N32 - pCR to Living Document: Security of Service Based Architecture of 5G phase 1 NTT DOCOMO other Approval
7.2.13.1Interconnect (SEPP related)
 		Yes
Yes
 		approved No   S3‑181418
S3‑181480 N32 message anti-spoofing within the SEPP Deutsche Telekom AG other Approval
7.2.13.1Interconnect (SEPP related)
 		Yes
Yes
 		approved No   S3‑181244
S3‑181481 Prevent fraudulent Registration Request attack Huawei, Hisilicon other Approval
7.2.13.1Interconnect (SEPP related)
 		Yes
Yes
 		approved No   S3‑181297
S3‑181482 pCR: Local configuration of message protection policy in SEPP Nokia other Approval
7.2.13.1Interconnect (SEPP related)
 		Yes
Yes
 		approved No   S3‑181402
S3‑181483 Remote provisioning of message protection policies in partner SEPPs Nokia other Approval
7.2.13.1Interconnect (SEPP related)
 		Yes
Yes
 		approved No   S3‑181403
S3‑181484 Correct typo in SBA Authorization Huawei, Hisilicon CR Approval
7.2.13.2Other
 		Yes
Yes
 		merged No S3‑181487 S3‑181258
S3‑181485 SBA Authentication issues Ericsson discussion Endorsement
7.2.13.2Other
 		Yes
Yes
 		endorsed No   S3‑181405
S3‑181486 Intra PLMN NF to NF authentication Ericsson CR Agreement
7.2.13.2Other
 		Yes
Yes
 		agreed No   S3‑181406
S3‑181487 The granularity of NF service discovery Huawei, Hisilicon,Nokia CR Approval
7.2.13.2Other
 		Yes
Yes
 		agreed No   S3‑181206
S3‑181488 [eMCSEC] Removal of Editor’s note in Clause I.3.4 NCSC CR Agreement
7.3Mission Critical Security Enhancements (eMCSec) (Rel-15)
 		Yes
Yes
 		agreed No   S3‑181419
S3‑181489 [eMCSEC] Resolution of editor’s notes within Clause 10 on logging, audit and discreet monitoring. NCSC CR Agreement
7.3Mission Critical Security Enhancements (eMCSec) (Rel-15)
 		Yes
Yes
 		agreed No   S3‑181420
S3‑181490 Inter PLMN routing and TLS: Solution Options Ericsson other Approval
7.2.13.2Other
 		Yes
Yes
 		approved No   S3‑181409
S3‑181491 LS on security aspects of supporting LTE connected to 5GC C1-182485 LS in discussion
7.2.15Incoming and outgoing LSes
 		Yes
Yes
 		noted No    
S3‑181492 NRF and NEF requirements Nokia CR -
7.2.13.2Other
 		Yes
Yes
 		merged No S3‑181462 S3‑181295
S3‑181493 LS on UE capability related to integrity protection of DRBs C1-182603 LS in discussion
7.2.15Incoming and outgoing LSes
 		Yes
Yes
Qualcomm: Max data rate supported from the UE to the network is currently beign discussed in SA2 and RAN2. We cannot progress until they have concluded the discussion on this issue.
 		noted No    
S3‑181494 LS on AUSF/UDM instance Selection and SUCI parameters Nokia LS out Approval
7.2.14Privacy
 		Yes
Yes
 		approved No    
S3‑181495 Clarifications to: Protection schemes for SUCI NTT-Docomo,Ericsson,Huawei,Nokia CR Agreement
7.2.14Privacy
 		Yes
Yes
 		agreed No    
S3‑181496 Clarifications to: Subscription identifier privacy Ericsson, CATT, NEC, Docomo, Nokia, Qualcomm CR Agreement
7.2.14Privacy
 		Yes
Yes
 		agreed No   S3‑181393
S3‑181497 SUCI - protection schemes identifiers Ericsson CR Agreement
7.2.14Privacy
 		Yes
Yes
 		merged No S3‑181495 S3‑181341
S3‑181498 Clause 6.12.2 Wording and correction related to SUCI CATT CR Approval
7.2.14Privacy
 		Yes
Yes
 		merged No S3‑181496 S3‑181230
S3‑181499 Limiting SUCI in Identifier Response Qualcomm Incorporated CR Agreement
7.2.14Privacy
 		Yes
Yes
 		merged No S3‑181496 S3‑181333
S3‑181500 Missing PEI requirements Motorola Mobility, Lenovo CR Approval
7.2.14Privacy
 		Yes
Yes
 		merged No S3‑181462 S3‑181445
S3‑181501 Reply to: Reply LS on SoR mechanism Samsung LS out approval
7.7PLMN RAT selection (Steering of Roaming)
 		Yes
Yes
 		approved No    
S3‑181502 Updates to Solution #6 in SoR Living Doc Qualcomm Incorporated, T-Mobile US, DT other Approval
7.7PLMN RAT selection (Steering of Roaming)
 		Yes
Yes
 		approved No   S3‑181426
S3‑181503 Living Document: Security of PLMN/RAT selection policies for roaming Samsung other Approval
7.7PLMN RAT selection (Steering of Roaming)
 		Yes
Yes
 		approved No   S3‑181281
S3‑181504 WID eMCSec R16 security Motorola Solutions Danmark A/S WID new Agreement
7.11New Work Item proposals
 		Yes
Yes
Qualcomm: specify what security issues we are dealing with.
MCC commented that this had to be a feature and the parent WIDs were related WIDs instead.
After this and some other editorials were fixed, the document was agreed.
 
 		agreed No   S3‑181178
S3‑181505 Correction and Clarification for the handling of KASME Huawei, Hisilicon CR Approval
7.10.1SAE/LTE Security
 		Yes
Yes
Changing 4G with EPS.
 		agreed No   S3‑181198
S3‑181506 Clarifying the condition when ePDG sends its certificate in untrusted non-3GPP access Nokia CR Agreement
7.10.1SAE/LTE Security
 		Yes
Yes
 		agreed No   S3‑181376
S3‑181507 Clarification of access token generation to clause 5.2.2.3 Method 3 – Token Based authorization NEC Corporation,Samsung, Motorola Solutions, Huawei pCR Approval
7.6Security Aspects of Common API Framework for 3GPP Northbound APIs (CAPIF_Sec) (Rel-15)
 		Yes
Yes
 		revised No S3‑181541 S3‑181366
S3‑181508 SBA evening session report Qualcomm report Information
7.2.13.1Interconnect (SEPP related)
 		Yes
Yes
 		noted No    
S3‑181509 Way forward for Interconnect (N32) security Ericsson, Deutsche Telekom, Nokia discussion Endorsement
7.2.13.1Interconnect (SEPP related)
 		Yes
Yes
 		endorsed No   S3‑181435
S3‑181510 K’AMF derivation and NASC protection at N2 based handover Qualcomm Incorporated CR Agreement
7.2.2Key derivation
 		Yes
Yes
The agreed part on 6.9 goes into tdoc 511.
 
 		merged No S3‑181454 S3‑181326
S3‑181511 Clarifications to: Security handling in mobility Qualcomm CR Agreement
7.2.2Key derivation
 		Yes
Yes
 		agreed No    
S3‑181512 Add condition for reset NAS COUNTs ZTE Corporation CR Approval
7.2.2Key derivation
 		Yes
Yes
It was noted that there was a clash between this document and 547. Qualcomm had the action point to review it.
 		agreed No   S3‑181163
S3‑181513 Remove of K_AMF_CI ZTE Corporation CR Approval
7.2.3Mobility
 		Yes
Yes
 		merged No S3‑181511 S3‑181138
S3‑181514 CAPIF – API Invoker on boarding Samsung,NEC pCR -
7.6Security Aspects of Common API Framework for 3GPP Northbound APIs (CAPIF_Sec) (Rel-15)
 		Yes
Yes
 		approved No   S3‑181392
S3‑181515 CAPIF – Key Derivation Samsung, MSI pCR -
7.6Security Aspects of Common API Framework for 3GPP Northbound APIs (CAPIF_Sec) (Rel-15)
 		Yes
Yes
 		approved No   S3‑181387
S3‑181516 CAPIF – Editor’s note resolution on authorization mechanism Samsung, MSI pCR -
7.6Security Aspects of Common API Framework for 3GPP Northbound APIs (CAPIF_Sec) (Rel-15)
 		Yes
Yes
 		approved No   S3‑181389
S3‑181517 Security procedures for dual connectivity Huawei,Ericsson, Qualcomm draftCR Approval
7.2.5NAS security
 		Yes
Yes
 		approved No    
S3‑181518 Clarifications to: Security algorithm selection, key establishment and security mode command procedure Huawei, Hisilicon, LG Electronics, ZTE Corporation CR Approval
7.2.4AS security
 		Yes
Yes
 		agreed No   S3‑181224
S3‑181519 LS on SA3 status on security-related API requirements Deutsche Telekom LS out Approval
7.2.13.1Interconnect (SEPP related)
 		No
Yes
 		withdrawn Yes    
S3‑181520 Clarifications to: UP security mechanisms Huawei, Hisilicon, LG Electronics CR Approval
7.2.4AS security
 		Yes
Yes
 		agreed No   S3‑181257
S3‑181521 Clarifications to: RRC security mechanisms LG CR Agreement
7.2.4AS security
 		Yes
Yes
 		agreed No    
S3‑181522 Editorial corrections of clause 6.6 LG Electronics CR Agreement
7.2.4AS security
 		Yes
Yes
 		merged No S3‑181520 S3‑181267
S3‑181523 pCR to 33.843 - collection of editorial fixes Vodafone Group Plc pCR Approval
8.4Study on Long Term Key Update Procedures (FS_LTKUP) (Rel-15)
 		Yes
Yes
 		approved No   S3‑181416
S3‑181524 Draft TR 33.834 Vodafone draft TR Approval
8.4Study on Long Term Key Update Procedures (FS_LTKUP) (Rel-15)
 		No
Yes
 		approved No    
S3‑181525 Solution #6 Editor’s Note resolution InterDigital, Inc. pCR Approval
8.4Study on Long Term Key Update Procedures (FS_LTKUP) (Rel-15)
 		Yes
Yes
It fixes the references.
 
 		approved No   S3‑181131
S3‑181526 LTKUP: clarifications for solution #5 Gemalto N.V. pCR Approval
8.4Study on Long Term Key Update Procedures (FS_LTKUP) (Rel-15)
 		Yes
Yes
Rewording as proposed by ORANGE and Vodafone.
 
 		approved No   S3‑181246
S3‑181527 pCR to TR 33.834 – clarifications to key issue 1 Vodafone Group Plc pCR Approval
8.4Study on Long Term Key Update Procedures (FS_LTKUP) (Rel-15)
 		Yes
Yes
 		approved No   S3‑181264
S3‑181528 pCR to TR 33.834 – clarifications to key issue 2 Vodafone Group Plc pCR Approval
8.4Study on Long Term Key Update Procedures (FS_LTKUP) (Rel-15)
 		Yes
Yes
 		approved No   S3‑181265
S3‑181529 CAPIF re-organizing NEC Corporation pCR Approval
7.6Security Aspects of Common API Framework for 3GPP Northbound APIs (CAPIF_Sec) (Rel-15)
 		Yes
Yes
 		revised No S3‑181540 S3‑181368
S3‑181530 pCR to TR 33.834 – updated evaluation of solution #3 Vodafone Group Plc pCR Approval
8.4Study on Long Term Key Update Procedures (FS_LTKUP) (Rel-15)
 		Yes
Yes
 		approved No   S3‑181275
S3‑181531 pCR to TR 33.834 – updated evaluation of solution #2 Vodafone Group Plc pCR Approval
8.4Study on Long Term Key Update Procedures (FS_LTKUP) (Rel-15)
 		No
Yes
 		approved No   S3‑181388
S3‑181532 pCR to TR 33.834 – updates to solution #4 Vodafone Group Plc pCR Approval
8.4Study on Long Term Key Update Procedures (FS_LTKUP) (Rel-15)
 		Yes
Yes
 		approved No   S3‑181404
S3‑181533 Conclusion of solution #5 Gemalto pCR Approval
8.4Study on Long Term Key Update Procedures (FS_LTKUP) (Rel-15)
 		Yes
Yes
 		approved No    
S3‑181534 pCR to TR 33.834 – updates to solution #6 Vodafone Group Plc pCR Approval
8.4Study on Long Term Key Update Procedures (FS_LTKUP) (Rel-15)
 		No
Yes
 		approved No   S3‑181415
S3‑181535 pcr to 33.834 - Addition of Conclusion (comment to S3-181247) ORANGE pCR Approval
8.4Study on Long Term Key Update Procedures (FS_LTKUP) (Rel-15)
 		Yes
Yes
 		approved No   S3‑181417
S3‑181536 Cover sheet 33.834 Vodafone TS or TR cover Approval
8.4Study on Long Term Key Update Procedures (FS_LTKUP) (Rel-15)
 		No
Yes
 		withdrawn Yes    
S3‑181537 Draft TS 33.122 Samsung draft TS Approval
7.6Security Aspects of Common API Framework for 3GPP Northbound APIs (CAPIF_Sec) (Rel-15)
 		Yes
Yes
 		approved No    
S3‑181538 CAPIF – Topology Hiding Samsung, MSI pCR -
7.6Security Aspects of Common API Framework for 3GPP Northbound APIs (CAPIF_Sec) (Rel-15)
 		Yes
Yes
 		approved No   S3‑181384
S3‑181539 TLS-PSK ciphersuites for security method of CAPIF-2e reference point Huawei, Hisilicon pCR Approval
7.6Security Aspects of Common API Framework for 3GPP Northbound APIs (CAPIF_Sec) (Rel-15)
 		Yes
Yes
 		approved No   S3‑181215
S3‑181540 CAPIF re-organizing NEC Corporation,Huawei,Samsung pCR Approval
7.6Security Aspects of Common API Framework for 3GPP Northbound APIs (CAPIF_Sec) (Rel-15)
 		Yes
Yes
 		approved No   S3‑181529
S3‑181541 Clarification of access token generation to clause 5.2.2.3 Method 3 – Token Based authorization NEC Corporation,Samsung, Motorola Solutions, Huawei pCR Approval
7.6Security Aspects of Common API Framework for 3GPP Northbound APIs (CAPIF_Sec) (Rel-15)
 		Yes
Yes
Modifying step 4 as proposed by Nokia.
 
 		approved No   S3‑181507
S3‑181542 Security method between API invoker and API exposing function Huawei, Hisilicon pCR Approval
7.6Security Aspects of Common API Framework for 3GPP Northbound APIs (CAPIF_Sec) (Rel-15)
 		Yes
Yes
 		approved No   S3‑181212
S3‑181543 add definitions and abbreviations for TR33.843 Huawei, Hisilicon CR -
8.2Study on security aspects of enhancements to ProSe UE-to-Network Relay (FS_REAR_Sec) (Rel-15)
 		Yes
Yes
 		agreed No   S3‑181338
S3‑181544 Remove EN for initial NAS message protection ZTE Corporation CR Approval
7.2.5NAS security
 		Yes
Yes
 		agreed No   S3‑181139
S3‑181545 LS on not sending the SUCI in response to a hash failure Qualcomm LS in Approval
7.2.5NAS security
 		Yes
Yes
 		approved No    
S3‑181546 Modification on NAS SMC procedure ZTE Corporation CR Approval
7.2.5NAS security
 		Yes
Yes
 		merged No S3‑181518 S3‑181146
S3‑181547 Multiple NAS connections Ericsson, ZTE Corporation, Huawei, Hisilicon, Qualcomm Incorporated CR Agreement
7.2.5NAS security
 		Yes
Yes
 		agreed No   S3‑181308
S3‑181548 Discussion on authentication and NAS SMC handling with race condition ZTE Corporation discussion Endorsement
7.2.5NAS security
 		Yes
Yes
 		endorsed No   S3‑181135
S3‑181549 Rules on concurrent running of authentication and NAS SMC procedure ZTE Corporation CR Approval
7.2.5NAS security
 		Yes
Yes
 		agreed No   S3‑181136
S3‑181550 Reply LS to SA3 on encryption of broadcast positioning information R2-1806308 LS in Discussion
6.13GPP Working Groups
 		Yes
Yes
 		postponed No    
S3‑181551 skeleton of TR33.856 Huawei, Hisilicon,China Unicom pCR Approval
8.6Security aspects of single radio voice continuity from 5G to UTRAN (FS_5G_UTRAN_SEC) (Rel-16)
 		Yes
Yes
 		approved No   S3‑181199
S3‑181552 a proposal for the scope of TR33.856 Huawei, Hisilicon,China Unicom pCR Approval
8.6Security aspects of single radio voice continuity from 5G to UTRAN (FS_5G_UTRAN_SEC) (Rel-16)
 		Yes
Yes
ORANGE wanted to have more clarification on the roaming scenario. The international roaming scenario didn’t seem to be clear and proposed that China Unicom to bring a contribution for the next meeting.
DT: There shouldn't be any impact in the HPLMN, I support ORANGE.
 
 		approved No   S3‑181200
S3‑181553 a proposal for the introduction of TR33.856 Huawei, Hisilicon,China Unicom pCR Approval
8.6Security aspects of single radio voice continuity from 5G to UTRAN (FS_5G_UTRAN_SEC) (Rel-16)
 		Yes
Yes
ORANGE don’t list impact on the user experience. This is a security study.
BT: I object to the inclusion of scenarion 2 and 3. This violate the agreement in SA. The use case involves an operator using VoLTE roaming from 5G to UTRAN.
ORANGE: don’t use "shall" for the support of service continuity from 5G to UTRAN. It was agreed to bring back the sentence for the next meeting.
 
 		approved No   S3‑181201
S3‑181554 Response to LS on encrypting broadcasted positioning data and LS on provisioning of positioning assistance data via LPPa for broadcast R2-1806307 LS in discussion
6.13GPP Working Groups
 		Yes
Yes
 		postponed No    
S3‑181555 Update security mechanism in Xn-HO procedre Huawei; HiSilicon CR Approval
7.2.3Mobility
 		Yes
Yes
6.7 will go to 518 and clause 6.6 will go to 520.
 		merged No S3‑181520 S3‑181222
S3‑181556 Authentication and authorization for slice management interface Huawei, Hisilicon pCR Approval
8.3Study on security aspects of 5G Network Slicing Management (FS_ NETSLICE-MGT_Sec) (Rel-15)
 		Yes
Yes
 		approved No   S3‑181251
S3‑181557 Draft TR 33.811 Huawei draft TR Approval
8.3Study on security aspects of 5G Network Slicing Management (FS_ NETSLICE-MGT_Sec) (Rel-15)
 		No
Yes
 		left for email approval No    
S3‑181558 Impacted NextGen Areas NCSC pCR Approval
8.5Study on Supporting 256-bit Algorithms for 5G (FS_256-Algorithms) (Rel-16)
 		Yes
Yes
 		approved No   S3‑181245
S3‑181559 Draft TR 33.841 Vodafone draft TR Approval
8.5Study on Supporting 256-bit Algorithms for 5G (FS_256-Algorithms) (Rel-16)
 		No
Yes
 		approved No    
S3‑181560 Section 8, Size of the integrity protection tag MAC-I Vodafone, AT&T, MITRE, NIST, InterDigital, TCG pCR Approval
8.5Study on Supporting 256-bit Algorithms for 5G (FS_256-Algorithms) (Rel-16)
 		No
Yes
 		approved No   S3‑181126
S3‑181561 Co-existence of different size keys and MAC-I tags AT&T, Vodafone, NIST, MITRE, InterDigital, TCG pCR Approval
8.5Study on Supporting 256-bit Algorithms for 5G (FS_256-Algorithms) (Rel-16)
 		Yes
Yes
 		approved No   S3‑181127
S3‑181562 Study on authentication and key management for applications based on 3GPP credential in 5G IoT China Mobile Group Device Co. SID new -
8.8New study item proposals
 		Yes
Yes
 		agreed No   S3‑181235
S3‑181563 Reduce complex of Key Derivation Function negotiation Huawei, Hisilicon pCR Approval
8.5Study on Supporting 256-bit Algorithms for 5G (FS_256-Algorithms) (Rel-16)
 		No
Yes
 		approved No   S3‑181196
S3‑181564 pCR to TR 33.841- Individual algorithms Vodafone Group Plc pCR Approval
8.5Study on Supporting 256-bit Algorithms for 5G (FS_256-Algorithms) (Rel-16)
 		No
Yes
Vodafone commented that links to ZUC, SNOW 3G, Tuak, MILENAGE and AES would be added during the next meeting.
 		approved No   S3‑181278
S3‑181565 TS 33.501 Resolving Editors notes 5.10.1 Security Visibility BT plc CR Approval
7.2.7Visibility and Configurability
 		No
Yes
 		agreed No   S3‑181379
S3‑181566 clarify UE concurrency rule NTT DOCOMO CR Agreement
7.2.5NAS security
 		Yes
Yes
 		merged No S3‑181511 S3‑181189
S3‑181567 Clarification on SMS over NAS ZTE Corporation, Ericsson, Huawei, Hisilicon CR Approval
7.2.5NAS security
 		Yes
Yes
 		agreed No   S3‑181144
S3‑181568 CR to Clause 10.2.1 on Emergency Call redirection Nokia CR Approval
7.2.6Security context
 		Yes
Yes
 		agreed No   S3‑181358
S3‑181569 Updates to Secondary Authentication Procedure Huawei, Hisilicon, Interdigital, CATT, NEC, Nokia CR Approval
7.2.9Secondary authentication
 		Yes
Yes
 		agreed No   S3‑181250
S3‑181570 Clarifications to the handover from EPS to 5Gs over N26 Qualcomm Incorporated,Ericsson CR Agreement
7.2.10Interworking
 		Yes
Yes
 		agreed No   S3‑181330
S3‑181571 Clarifications for mapping of security contexts Ericsson CR Agreement
7.2.10Interworking
 		Yes
Yes
Changes to Annex A go to 454.
 
 		agreed No   S3‑181310
S3‑181572 Clarification of NAS MAC computation for TAU protection, algorithm selection and security activation during idle mode mobility from 5GS to EPS Ericsson CR Agreement
7.2.10Interworking
 		Yes
Yes
 		agreed No   S3‑181300
S3‑181573 non-3GPP access when security context is available Huawei; HiSilicon CR Approval
7.2.11non-3GPP access
 		Yes
Yes
 		merged No S3‑181574 S3‑181219
S3‑181574 Clarifications on clause 7.2 Huawei CR Agreement
7.2.11non-3GPP access
 		Yes
Yes
 		agreed No    
S3‑181575 Clarification for KN3IWF delivery in authentication Huawei, Hisilicon CR Approval
7.2.11non-3GPP access
 		Yes
Yes
 		merged No S3‑181574 S3‑181282
S3‑181576 Editorials to 33.501 NTT DOCOMO CR Agreement
7.2.16Others
 		Yes
Yes
Clause 5 goes to 462.
Clause 6.1.2 goes to 465.
Clause 6.1.4 goes to 463.
6.8 goes to 456.
Annex A goes to 454.
6.1.1 goes to 460.
6.12 goes to 496.
6.2 is removed.
 
 
 
 
 		agreed No   S3‑181439
S3‑181577 Reference corrections in clause 5 Nokia CR -
7.2.16Others
 		Yes
Yes
 		merged No S3‑181462 S3‑181411
S3‑181578 Reference corrections in clause 6 Nokia CR -
7.2.16Others
 		Yes
Yes
 		agreed No   S3‑181412
S3‑181579 Reference corrections in clause 8 Nokia CR -
7.2.16Others
 		Yes
Yes
 		agreed No   S3‑181413
S3‑181580 Collection of editorial corrections Nokia CR -
7.2.16Others
 		Yes
Yes
Change 1 to 569.
Change 2 to 454.
Change 3 in this document and merged in 470.
 
 
 		merged No S3‑181470 S3‑181414
S3‑181581 Modification on UE’s subscribe privacy requirement ZTE Corporation CR Approval
7.2.16Others
 		Yes
Yes
Only third change stays.
 		merged No S3‑181462 S3‑181143
S3‑181582 Editorial changes to clause 10 and 12 Nokia CR Agreement
7.2.16Others
 		No
Yes
 		agreed No   S3‑181437
S3‑181583 Draft TR 33.856 China Unicom draft TR Approval
8.6Security aspects of single radio voice continuity from 5G to UTRAN (FS_5G_UTRAN_SEC) (Rel-16)
 		No
Yes
 		approved No    
S3‑181584 a proposal for the key issue of TR33.856 Huawei, Hisilicon pCR Approval
8.6Security aspects of single radio voice continuity from 5G to UTRAN (FS_5G_UTRAN_SEC) (Rel-16)
 		Yes
Yes
It was noted that 3G referred to UTRAN CS.
MCC commented that they should be potential security requirements.
 		approved No   S3‑181202
S3‑181585 a proposal for the key derivation without direct interface between AMF and MSC server of TR33.856 Huawei, Hisilicon pCR Approval
8.6Security aspects of single radio voice continuity from 5G to UTRAN (FS_5G_UTRAN_SEC) (Rel-16)
 		Yes
Yes
 		approved No   S3‑181203
S3‑181586 a proposal for the key derivation with interface between AMF and MSC server of TR33.856 Huawei, Hisilicon pCR Approval
8.6Security aspects of single radio voice continuity from 5G to UTRAN (FS_5G_UTRAN_SEC) (Rel-16)
 		Yes
Yes
 		approved No   S3‑181204
S3‑181587 Key issue of IMS Emergency Session Handling China Unicom pCR Approval
8.6Security aspects of single radio voice continuity from 5G to UTRAN (FS_5G_UTRAN_SEC) (Rel-16)
 		Yes
Yes
 		approved No   S3‑181317
S3‑181588 SA3 meeting calendar MCC other -
10Future Meeting Dates and Venues
 		Yes
Yes
 		noted No   S3‑181104