Tdoc List

2018-03-02 12:54

TDoc Title Source Type For Agenda Avail Treated Decision Wdrn Replaced-by Replaces
S3‑180500 Agenda WG Chair agenda  
2Approval of Agenda and Meeting Objectives
 		Yes
Yes
Tim (Vodafone) commented that they had two concerns:
- PLMN RAT selection should not be part of the 5G work item. The documents should be treated somewhere else.
- No voting should be performed without having agreed on the questions before the meeting. This could go against the working procedures.
 
ORANGE commented that PLMN RAT selection had been on the 5G agenda item in the last three meetings, so why disagreeing on this now?
 
Docomo commented that this is based on incoming LS and not in the WID objectives. The LS should describe where this work should be placed. SA3 should not make the decision of this being part of the 5G work and it should be escalated to SA/CT. This part can be added with a CR in 33.501 later.
 
ORANGE: CT1 does the stage 2 of this work as a 5G item.
 
BT commented that this had to be part of the 5G since the signalling must be received in the 5G network.
 
Vodafone replied that this worl is part of a Study Item. CT1 taking care of this was decided in Gothenburg (previous meeting) and not earlier than that.
 
ORANGE commented that the 5G feature list was not exhaustive, left deliberatly open to introduce more features. This is clearly a 5G feature.
 
Vodafone agreed with Docomo and had a sustained objection to treat this in the 5G agenda item. This objection was asked to be minuted. They also commented that they would object to all documents in that agenda item.
 
ORANGE: PLMN RAT selection moved somewhere else would mean that it would not go into TS 33.501. Samsung,NEC and Qualcomm supported ORANGE.
 
Ericsson clarified that this was part of 5G phase one.
 
The Chair decided to keep it in the 5G item and discuss offline how to handle this issue.
 
Ericsson commented that CMPv2 was supposed to be in the agenda, and that the documents were present in AoB agenda item. And additional agenda item was added here.
 
The Chair commented that the voting questions could be decided during the meeting. Vodafone commented that this was going against 3GPP working procedures. This had to be discussed offline. NOTE from MCC: this is unusual but the working procedures recommend an appropriate timing without specifying when, hence allowed.
 
 
 
 
 
 
 
 		revised No S3‑180847  
S3‑180501 Work Plan input from the Rapporteurs MCC other Information
6Any Other Business
 		Yes
Yes
 		revised No S3‑181004  
S3‑180502 6.12.2 PCR for making SUPI protection opaque to IMSI sniffers InterDigital, Inc. pCR Approval
4.1.14.2SUCI and Schemes
 		Yes
Yes
 		noted No    
S3‑180503 C3.2 PCR for making SUPI protection opaque to IMSI sniffers InterDigital, Inc. pCR Approval
4.1.14.2SUCI and Schemes
 		Yes
Yes
 		noted No    
S3‑180504 C3.3 PCR for making SUPI protection opaque to IMSI sniffers InterDigital, Inc. pCR Approval
4.1.14.2SUCI and Schemes
 		Yes
Yes
 		noted No    
S3‑180505 Discussion Paper on the need and ways to make SUPI protection opaque to IMSI sniffers InterDigital, Inc. discussion Discussion
4.1.14.2SUCI and Schemes
 		Yes
Yes
NCSC: This is not protecting against IMSI grabbers at all. This only works for passive sniffing.
Ericsson: this use case is very rare. Besides, SA3 should not get involved with cryptographic schemes, this is SAGE work.
Nokia supported to have a look at this use case. T-Mobile found it useful too.
BT(Alex) commented that this would need an IMSI redesigning.
Deutsche-Telekom, Docomo proposed an encoding solution. This would be for the next meeting.
ORANGE didn’t think it was a problem.
Some other companies that this use case was worth considering (e.g. Samsung, Nokia, KPN,T-Mobile). The Chair commented that the problem was understood but companies wanted to have a solution going another way. Contributions are welcome for the next meeting.
 
 		noted No    
S3‑180506 PCR for making SUPI protection opaque to IMSI sniffers InterDigital, Inc. pCR Approval
4.1.14.2SUCI and Schemes
 		Yes
Yes
 		noted No    
S3‑180507 Solution for LTK generation InterDigital, Inc. pCR Approval
5.2Study on Long Term Key Update Procedures (FS_LTKUP) (Rel-15)
 		Yes
Yes
Vodafone: LTK solution is preemptive as well as reactive. The diagram suggests an only reactive solution.
Ericsson: where would Diffie-Hellman be included?
Interdigital: this solution can include Diffie-Hellman.
Qualcomm: step 2 is optional but it triggers step 3.
Vodafone: it jumps directly to step 5. This was clarified in the revision.
 
 		revised No S3‑180932  
S3‑180508 9.1.3.4.2 clarification PCR InterDigital, Inc. pCR Approval
4.1.13.4NF-NRF Authentication & Authorization
 		Yes
Yes
 		revised No S3‑180900  
S3‑180509 Overview of 5G security architecture Huawei, Hisilicon, China Mobile, CATR, ZTE pCR Approval
4.1.1.1Miscellaneous
 		Yes
Yes
ORANGE: relationship number VI is not correct, according to TS 33.102. Huawei agreed that this could be changed.
ORANGE: what is relationship II?
Huawei: Network Domain Security.
Telecom Italia suggested some changes in bullet number one.
IDEMIA: I) should go to USIM.
 
 
 
 
 		revised No S3‑180858  
S3‑180510 Clearfy the seaf and amf requirements Huawei, Hisilicon pCR Approval
4.1.8.7Editorial corrections
 		Yes
Yes
 		approved No    
S3‑180511 Resolving Editor’s Note in UP security policy by aligning with SA2 procedure Huawei, Hisilicon pCR Approval
4.1.4.2Userplane security
 		Yes
Yes
 		merged No S3‑180920  
S3‑180512 Resolving Editor’s notes related with key derivation for EAP-TLS Huawei, HiSilicon, Qualcomm Incorporated, Ericsson pCR Approval
4.1.8.4Authentication using EAP TLS
 		Yes
Yes
BT: where to keep a list of serving network names?
ORANGE:A list maintaining a list of serving network names? IETF will not do that. This concept is not clear in the contribution.
This had to be clarified offline.
 
 		revised No S3‑180919  
S3‑180513 Authorization of NF service Access in the same PLMN Huawei, Hisilicon pCR Approval
4.1.13.4NF-NRF Authentication & Authorization
 		Yes
Yes
 		merged No S3‑180885  
S3‑180514 Resolving editors notes about authentication in service authorization Huawei, Hisilicon other Approval
4.1.13.4NF-NRF Authentication & Authorization
 		Yes
Yes
 		approved No    
S3‑180515 Resolving Editor’s notes on Privacy Issues for EAP-TLS Huawei, HiSilicon, Qualcomm Incorporated pCR Approval
4.1.8.4Authentication using EAP TLS
 		Yes
Yes
 		revised No S3‑180921  
S3‑180516 ID linkage verification in secondary authentication-v2 Huawei, Hisilicon pCR Approval
4.1.9.3Efficiency / security improvement
 		Yes
Yes
Ericsson: Where's the PUI defined? SA2 uses the term but it doesn’t seem to be defined.
Ericsson: in step 13, is it describing behaviour externally to the network? We don’t do that.
Step 13 was not agreed. The definition of PUI had to be checked offline.
 
 		revised No S3‑180908  
S3‑180517 DN triggered Secondary re-authentication procedure Huawei, Hisilicon pCR Approval
4.1.9.2Incomplete procedure
 		Yes
Yes
 		approved No    
S3‑180518 deleting the duplicate ENs about the Kausf storage Huawei, Hisilicon pCR Approval
4.1.1.2Editorials
 		Yes
Yes
 		revised No S3‑180871  
S3‑180519 deleting the duplicate ENs about ngKSI Huawei, Hisilicon pCR Approval
4.1.2.4Miscellaneous
 		Yes
Yes
 		revised No S3‑180861  
S3‑180520 Resolving editors note in Authorization of NF service access Huawei, Hisilicon pCR Approval
4.1.13.4NF-NRF Authentication & Authorization
 		Yes
Yes
DT didn’t agree with this document.
It was agreed to merge it with 885.
 
 		merged No S3‑180885  
S3‑180521 Authorization of NF service Access across PLMNs Huawei, Hisilicon pCR Approval
4.1.13.4NF-NRF Authentication & Authorization
 		Yes
Yes
 		merged No S3‑180886  
S3‑180522 Resolving Editor’s Note in clause 3.1 and cleaning up some definitions KPN pCR Approval
4.1.1.2Editorials
 		Yes
Yes
The definition clause affects tdoc 830 from IDEMIA.
 
 		revised No S3‑180869  
S3‑180523 Resolving Editors' Notes in clause 5.1.4 KPN pCR Approval
4.1.17Others
 		Yes
Yes
ORANGE: Leave the requirement.
Vodafone didn’t agree with the "securityt evaluated" statement.
 
 		noted No    
S3‑180524 Resolving Editors' notes in clause 5.1.5 KPN pCR Approval
4.1.14.2SUCI and Schemes
 		Yes
Yes
 		approved No    
S3‑180525 Resolving Editors' Notes in clauses 5.2.3 and 5.3.3 KPN pCR Approval
4.1.4.1Userplane open issues
 		Yes
Yes
 		merged No S3‑180942  
S3‑180526 Resolution of Editor's Notes in clause 5.7 KPN pCR Approval
4.1.13.5NF-NF Authentication & Authorization
 		Yes
Yes
 		approved No    
S3‑180527 Resolution of Editor’s Notes in 5.10 KPN pCR Approval
4.1.13.5NF-NF Authentication & Authorization
 		Yes
Yes
 		approved No    
S3‑180528 Living Document: Security of Service Based Architecture of 5G phase 1 China Mobile Com. Corporation other  
4.1.13.6Miscellaneous
 		Yes
Yes
 		revised No S3‑180888  
S3‑180529 Discussion and pCR to resolving TLS 1.3 Editor’s Notes in section 9.1.3.1 China Mobile Com. Corporation pCR  
4.1.13.3Transport security (intra and inter-PLMN)
 		Yes
Yes
 		approved No    
S3‑180530 pCR to resolving authentication Editor’s Notes in section 9.1.3.4 China Mobile Com. Corporation pCR  
4.1.13.4NF-NRF Authentication & Authorization
 		Yes
Yes
 		revised No S3‑180901  
S3‑180531 pCR to resolving Editor’s Notes in section 9.1.1 China Mobile Com. Corporation pCR  
4.1.13.7Editorials
 		No
Yes
 		withdrawn Yes    
S3‑180532 pCR to resolving Editor’s Notes in section 9.1.1 China Mobile Com. Corporation pCR  
4.1.13.7Editorials
 		Yes
Yes
 		approved No    
S3‑180533 Discussion and pCR for privacy calculation in UE side China Mobile Com. Corporation pCR  
4.1.14.2SUCI and Schemes
 		Yes
Yes
TIM: what’s the 5G USIM in the figure?
There was no support for this, hence it was noted.
 
 		noted No    
S3‑180534 resolving editor’s notes on protection the initial NAS message China Mobile Com. Corporation pCR  
4.1.5.2Protection of initial NAS message
Yes
Yes
 		revised No S3‑181005  
S3‑180535 resolving editor’s note on NAS SMC procedure failures China Mobile Com. Corporation pCR  
4.1.5.5NAS Security Mode Command
 		Yes
Yes
 		approved No    
S3‑180536 pCR to TR 33.841 - Assessment of quantum computing impact timelines China Mobile Com. Corporation pCR  
5.3Study on Supporting 256-bit Algorithms for 5G (FS_256-Algorithms) (Rel-16)
 		Yes
Yes
 		merged No S3‑180938  
S3‑180537 Discussion on authentication and NAS SMC with race condition ZTE Corporation discussion Endorsement
4.1.5.7Multi-NAS security
 		Yes
Yes
 		noted No    
S3‑180538 Rules on concurrent running of authentication and NAS SMC procedure ZTE Corporation pCR Approval
4.1.5.7Multi-NAS security
 		Yes
Yes
 		noted No    
S3‑180539 Discussion on deletion of Kseaf ZTE Corporation, Huawei, Hisilicon discussion Endorsement
4.1.1.1Miscellaneous
 		Yes
Yes
 		noted No    
S3‑180540 Discussion on N2 handover procedure ZTE Corporation discussion Endorsement
4.1.3.2Security in AMF change between AMF sets
 		Yes
Yes
 		noted No    
S3‑180541 N2 handover procedure ZTE Corporation pCR Approval
4.1.3.2Security in AMF change between AMF sets
 		Yes
Yes
 		revised No S3‑180955  
S3‑180542 Discussion on visited network control of using null-scheme ZTE Corporation discussion Endorsement
4.1.14.1SUPI and LI
 		Yes
Yes
 		noted No    
S3‑180543 Visited network control of null-scheme ZTE Corporation pCR Approval
4.1.14.1SUPI and LI
 		Yes
Yes
Qualcomm: we discussed this during the last meeting and agreed to take it in phase two.
ORANGE: we don't need the visited network to force the new scheme.
This was noted since there was no support for this.
 
 		noted No    
S3‑180544 Editorial modification on AMF privacy requirement ZTE Corporation pCR Approval
4.1.14.5Editorials
 		Yes
Yes
 		revised No S3‑180976  
S3‑180545 Editorial modification on gNB requirement on (de)activating protection ZTE Corporation pCR Approval
4.1.4.1Userplane open issues
 		Yes
Yes
 		merged No S3‑180942  
S3‑180546 Editorial modification on keys in AMF ZTE Corporation pCR Approval
4.1.2.4Miscellaneous
 		Yes
Yes
 		revised No S3‑180997  
S3‑180547 Editorial modification on SEAF privacy requirement ZTE Corporation pCR Approval
4.1.14.5Editorials
 		Yes
Yes
 		withdrawn Yes    
S3‑180548 Modification on SIDF privacy requirement ZTE Corporation pCR Approval
4.1.14.3SIDF
 		Yes
Yes
 		noted No    
S3‑180549 Modification on UE privacy requirement ZTE Corporation pCR Approval
4.1.14.2SUCI and Schemes
 		Yes
Yes
Apple didn’t agree with ME supporting the null-scheme, as they describe in 580.
 
 
 
 		noted No    
S3‑180550 Modification on Xn handover procedure ZTE Corporation pCR Approval
4.1.3.6Miscellaneous
 		Yes
Yes
 		revised No S3‑180852  
S3‑180551 Enforce common NAS context for multiple registrations in same PLMN ZTE Corporation pCR Approval
4.1.5.7Multi-NAS security
 		Yes
Yes
Ericsson didn’t see it clear why the second Editor's note was removed.
It was agreed to leave both editor's notes.
 
 		revised No S3‑180880  
S3‑180552 Modification on NAS SMC procedure ZTE Corporation pCR Approval
4.1.5.5NAS Security Mode Command
 		Yes
Yes
 		noted No    
S3‑180553 Reply LS on Early Data Transmission C1-175310 LS in  
4.5Security Aspects of Narrowband IOT (CIoT)
 		Yes
Yes
 		noted No    
S3‑180554 LS on Status of Specifications Covering Requirements for IoT Modules C1-175380 LS in  
4.5Security Aspects of Narrowband IOT (CIoT)
 		Yes
Yes
 		noted No    
S3‑180555 Reply LS on security aspects of supporting LTE connected to 5GC C1-180485 LS in  
4.1.15Incoming and outgoing LSes
 		Yes
Yes
 		noted No    
S3‑180556 LS on selectively disabling legacy radio access C1-180711 LS in  
4.1.15Incoming and outgoing LSes
 		Yes
Yes
 		noted No    
S3‑180557 Reply LS on PLMN and RAT selection policies for roaming C1-180761 LS in  
4.1.15Incoming and outgoing LSes
 		Yes
Yes
Vodafone: the CRs have ignored what we had agreed. These CRs are agreed but not approved formally in SA, we cannot accept them at this point. The authentication is SA3's business and not CT1's.
NEC: SA or CT plenary?
Docomo: make it clear what part of TS 33.501 is affected by this issue.
 
 		replied to No    
S3‑180558 Reply LS on SBI Design and its Security Implications C3-180339 LS in  
4.1.15Incoming and outgoing LSes
 		Yes
Yes
 		noted No    
S3‑180559 LS on extension of S6x interface for BEST C4-176388 LS in  
4.2Battery Efficient Security for very low Throughput Machine Type Communication Devices (BEST_MTC_Sec) (Rel-15)
Yes
Yes
 		noted No    
S3‑180560 LS on RAN2 Assumption about DRB ID value range R2-1801649 LS in  
4.1.15Incoming and outgoing LSes
 		Yes
Yes
Docomo: their assumption is correct.
Nokia had tdocs 609 and 610 related to this.
 
 		replied to No    
S3‑180561 LS on security for CU-CP/UP separation R3-180630 LS in  
4.1.15Incoming and outgoing LSes
 		Yes
Yes
 		replied to No    
S3‑180562 Reply to LS on handling concurrent running of security procedures R3-180632 LS in  
4.1.15Incoming and outgoing LSes
 		Yes
Yes
 		noted No    
S3‑180563 Reply LS on User Plane Security Policy R3-180637 LS in  
4.1.15Incoming and outgoing LSes
 		Yes
Yes
 		withdrawn Yes    
S3‑180564 LS on secure storage and processing of subscription credentials S1-173475 LS in  
4.1.15Incoming and outgoing LSes
 		Yes
Yes
 		replied to No    
S3‑180565 [eMCSEC] 33180 R14 GMK management Motorola Solutions Danmark A/S CR Agreement
4.3Mission Critical Security Enhancements (eMCSec) (Rel-15)
 		Yes
Yes
 		revised No S3‑180863  
S3‑180566 [eMCSEC] 33180 R14 key storage and persistence Motorola Solutions Danmark A/S CR Agreement
4.3Mission Critical Security Enhancements (eMCSec) (Rel-15)
 		Yes
Yes
 		revised No S3‑180864  
S3‑180567 [eMCSEC] 33180 R15 GMK management (mirror) Motorola Solutions Danmark A/S CR Agreement
4.3Mission Critical Security Enhancements (eMCSec) (Rel-15)
 		Yes
Yes
 		revised No S3‑180865  
S3‑180568 [eMCSEC] 33180 R15 key storage and persistence (mirror) Motorola Solutions Danmark A/S CR Agreement
4.3Mission Critical Security Enhancements (eMCSec) (Rel-15)
 		Yes
Yes
 		revised No S3‑180866  
S3‑180569 [MONASTERY_SEC] 33180 R15 functional alias(es) Motorola Solutions Danmark A/S CR Agreement
4.7Security Architecture for the Mobile Communication System for Railways (MONASTERY_SEC) (Rel-15)
 		Yes
Yes
 		revised No S3‑180907  
S3‑180570 [MONASTERY_SEC] 33180 R15 multi-talker Motorola Solutions Danmark A/S CR Agreement
4.7Security Architecture for the Mobile Communication System for Railways (MONASTERY_SEC) (Rel-15)
 		Yes
Yes
 		revised No S3‑180927  
S3‑180571 Key Issue 7.x - LTK update via partial Profile Update InterDigital, Inc. pCR Approval
5.2Study on Long Term Key Update Procedures (FS_LTKUP) (Rel-15)
 		Yes
Yes
ORANGE: this is putting requirements for something that is not done in 3GPP.
Vodafone: we can put it in the evaluation clause.
 
 		merged No S3‑180932  
S3‑180572 Collection of clarifications and editorial changes to BEST TS 33.163 Deutsche Telekom AG CR Approval
4.2Battery Efficient Security for very low Throughput Machine Type Communication Devices (BEST_MTC_Sec) (Rel-15)
Yes
Yes
 		revised No S3‑180930 S3‑180029
S3‑180573 Resolving Editor's Notes in clauses 6.2.1 and 6.2.2.1 KPN N.V. pCR Approval
4.1.1.1Miscellaneous
 		Yes
Yes
Only the first change was approved.
 
 		revised No S3‑180868  
S3‑180574 SUCI calculation in the ME Gemalto, IDEMIA, Ericsson pCR Approval
4.1.14.2SUCI and Schemes
 		Yes
Yes
Gemalto commented that this was a subset of the CATT proposal.
 
 		merged No S3‑180968  
S3‑180575 Solution#2 enhancement Gemalto N.V. pCR Approval
5.2Study on Long Term Key Update Procedures (FS_LTKUP) (Rel-15)
 		Yes
Yes
Vodafone: This seems to be part of the solution, given where it is inserted.
ORANGE: no need to add another key.Sending the OTA message is optional.
 
 		revised No S3‑180933  
S3‑180576 Adding conclusion to living document S3-180371 Huawei; Hisilicon other Approval
4.9PLMN RAT selection
 		Yes
Yes
Vodafone: I'm happy with this but deleting the conclusion.
Vodafone:there are a lot pre Rel-8 sIMs cards in the market. You cannot guarantee that the AMF bit is available.
Huawei: this is for 5G.
Vodafone: we agreed with China Mobile to include legacy USIMs in this solution.
 
 		revised No S3‑181002  
S3‑180577 Resolving Editor’s Notes on Input parameters for K'AMF derivation Huawei; Hisilicon pCR Approval
4.1.3.1Key derivations during handovers
 		Yes
Yes
Huawei: the advantage is that you don’t need to derive a new KAMF.ZTE supported this, as they considered this was the simplest way.
Ericsson: you need to signal the GUAMI to the UE first before the connection and this would be redundant, since you have to send it again later.
Samsung preferred the NONCE solution. Qualcomm agreed to go this way to progress.
 
 		noted No    
S3‑180578 Resolving Editor’s Notes on horizontal K'AMF derivation during mobility Huawei; Hisilicon pCR Approval
4.1.3.1Key derivations during handovers
 		Yes
Yes
 		revised No S3‑180953  
S3‑180579 Generation and rotation of subscription temporary identifier Apple (UK) Limited pCR Approval
4.1.14.4Miscellaneous
 		Yes
Yes
ORANGE: this may lead to DoS attacks.
Vodafone agreed: the handset is not the right place where to make the decision whether it needs to be updated.
 
 		noted No    
S3‑180580 Privacy Preservation of SUPI Apple (UK) Limited pCR Approval
4.1.14.2SUCI and Schemes
 		Yes
Yes
Vodafone: we will not provision public keys in every handset.
BT (Alex): HPLMN's choice to support this, it cannot be mandatory.
Ericsson: this is questioning the decision we made about legacy USIMs after long discussions. We already have content in the TS assuming what kind of USIMs we use. I propose to note this.
There wasn't support for this document, so it was noted.
 		noted No    
S3‑180581 Re-discussion on deleting KSEAF from key hierarchy Huawei, Hisilicon, ZTE discussion Endorsement
4.1.1.1Miscellaneous
 		Yes
Yes
Qualcomm: no need to re-open these discussions after what we have agreed.
NEC: there would be a backward compatilibity issue here.
Docomo: keep the Kseaf. KPN, BT, DT agreed.
China Mobile: ask SA2.
BT: SA3 decided to keep it; security issues are dealt here.
The Chair commented that there was major support on keeping the Kseaf.
 
 		noted No    
S3‑180582 Remove the authentication function on SEAF in 5G-AKA Huawei, Hisilicon pCR Approval
4.1.8.15G AKA over 3gpp/non3gpp access
 		Yes
Yes
KPN and Qualcomm disagreed with the changes.
BT: it’s a bit late to introduce a big change in the security architecture.
 
 		noted No    
S3‑180583 Remove the expiry timer in 5G-AKA Huawei, Hisilicon pCR Approval
4.1.8.15G AKA over 3gpp/non3gpp access
 		Yes
Yes
Nokia: the timer was added to avoid the UDM being overloaded with multiple requests.
 
 		merged No S3‑180909  
S3‑180584 Resolve Editor's Note in clause 6.1.3.2 of TS 33.501 Huawei, Hisilicon pCR Approval
4.1.8.15G AKA over 3gpp/non3gpp access
 		Yes
Yes
 		merged No S3‑180910  
S3‑180585 Clarification for SUPI delivery in 5G-AKA Huawei, Hisilicon pCR Approval
4.1.8.15G AKA over 3gpp/non3gpp access
 		Yes
Yes
 		merged No S3‑180911  
S3‑180586 Remove the service network name from the key material used to derive KAUSF Huawei, Hisilicon pCR Approval
4.1.2.4Miscellaneous
 		Yes
Yes
 		noted No    
S3‑180587 Authorization for NAPS Huawei, Hisilicon other Approval
4.4Northbound APIs Security for SCEF - SCS/AS Interworking (NAPS_Sec) (Rel-15)
 		Yes
Yes
 		approved No    
S3‑180588 Threats and potential countermeasures posed due to quantum computing NCSC pCR Approval
5.3Study on Supporting 256-bit Algorithms for 5G (FS_256-Algorithms) (Rel-16)
 		Yes
Yes
 		revised No S3‑180937  
S3‑180589 Assessment of quantum computing impact timelines NCSC pCR  
5.3Study on Supporting 256-bit Algorithms for 5G (FS_256-Algorithms) (Rel-16)
 		Yes
Yes
 		revised No S3‑180938  
S3‑180590 Requirement for SUPI privacy and LI CATT pCR Approval
4.1.14.1SUPI and LI
 		Yes
Yes
Verizon: not acceptable.
BT: it introduces VPLMN control, which is not what we want.
 
 		noted No    
S3‑180591 Solution for SUPI privacy and LI requirement CATT pCR Approval
4.1.14.1SUPI and LI
 		Yes
Yes
Qualcomm: you are including both SUCI and SUPI in your solution, this is the only difference with our solution.
 
 		noted No    
S3‑180592 Privacy requirements updated for clarification CATT pCR Approval
4.1.14.2SUCI and Schemes
 		Yes
Yes
 		revised No S3‑180970  
S3‑180593 UE privacy protection scheme requirements CATT pCR Approval
4.1.14.2SUCI and Schemes
 		Yes
Yes
 		revised No S3‑180971  
S3‑180594 SUCI structure and SUCI generation conditions CATT pCR Approval
4.1.14.2SUCI and Schemes
 		Yes
Yes
Interdigital: Easier for the attacker to grab the SUCI.
Ericsson proposed to remove the extended Home Network Identifier.
ORANGE asked whether there was a definition for the Home Network Identifier. This wasn't clear.
 
 		merged No S3‑180968  
S3‑180595 AMF de-conceal null-scheme SUCI CATT pCR Approval
4.1.14.2SUCI and Schemes
 		Yes
Yes
Docomo: the first requirement is obvious that can be done so we don’t need it as a requirement. The requirement was removed since there was no support for this as for the rest of the document.
 
 
 		noted No    
S3‑180596 Adding context on RRC security mechanisms CATT pCR Approval
4.1.4.3RRC security
 		Yes
Yes
 		merged No S3‑180947  
S3‑180597 Clarification on the scenario when UE has multiple registrations in different PLMNs CATT pCR Approval
4.1.6.1Multiple registrations
 		Yes
Yes
 		revised No S3‑180984  
S3‑180598 Clarifications on the scenario when UE has multiple registrations in same PLMNs CATT pCR Approval
4.1.6.1Multiple registrations
 		Yes
Yes
Ericsson: this is misplaced, it should go somewhere else.
Huawei: temporary identifier, what does it mean?
CATT: GUTI.
 
 		revised No S3‑180985  
S3‑180599 Modifications of N12 message context description CATT pCR Approval
4.1.8.2EAP AKA’ over 3gpp/non3gpp access
 		Yes
Yes
Overlaps with 809.
 
 		merged No S3‑180916  
S3‑180600 Resolving Editor’s notes in clause on EAP-TLS CATT pCR Approval
4.1.8.4Authentication using EAP TLS
 		Yes
Yes
 		merged No S3‑180919  
S3‑180601 Resolving Editor’s note in clause on key setting CATT pCR Approval
4.1.2.4Miscellaneous
 		Yes
Yes
 		merged No S3‑180862  
S3‑180602 Resolving Editor’s note in clause on Subscription temporary identifier CATT pCR Approval
4.1.14.5Editorials
 		Yes
Yes
 		approved No    
S3‑180603 The impaction of 256 bit keys for NG areas and requirement of a longer MAC CATT pCR Approval
5.3Study on Supporting 256-bit Algorithms for 5G (FS_256-Algorithms) (Rel-16)
 		Yes
Yes
NCSC had quite a few issues with the paper.
There were many issues from NCSC and ORANGE and Vodafone commented that a conference call could progress this.
 
 		noted No    
S3‑180604 The impaction of 256 bit keys for NG areas CATT pCR Approval
5.3Study on Supporting 256-bit Algorithms for 5G (FS_256-Algorithms) (Rel-16)
 		Yes
Yes
 		noted No    
S3‑180605 The clarification of the entropy CK and IK CATT pCR Approval
5.3Study on Supporting 256-bit Algorithms for 5G (FS_256-Algorithms) (Rel-16)
 		Yes
Yes
Alf(Docomo): the concept of entropy is used here in a confusing way, although I agree with the meaning.
An editor's note was added for this.
 
 		revised No S3‑180939  
S3‑180606 The clarification of the entropy CK and IK CATT pCR Approval
5.3Study on Supporting 256-bit Algorithms for 5G (FS_256-Algorithms) (Rel-16)
 		Yes
Yes
NCSC had some issues as well that had be to taken offline and brought back in the next meeting.
 
 		noted No    
S3‑180607 Discussion paper on R3-180630 LS on security for CU-CP/UP separation Nokia pCR Approval
4.1.4.2Userplane security
 		Yes
Yes
Huawei and Ericsson: we cannot mandate IPSec here.
It was commented that the discussion included a pCR at the end, so the type was changed.
The sentence with IPSec was modified to require confidentiality and integrity protection in the E1 interface.
 
 		revised No S3‑180850  
S3‑180608 draft_Reply LS to R3-180630 on CU-CP/UP separation Nokia LS out Approval
4.1.4.2Userplane security
 		Yes
Yes
Vodafone: The assumption that VM is in the cloud is irrelevant. We don’t agree with this.Ericsson agreed and added that SA3 should not mandate IPsec.
 
 		revised No S3‑180849  
S3‑180609 Discussion paper on RAN2 LS R2-1801649 on DRB id value range Nokia discussion Endorsement
4.1.4.3RRC security
 		Yes
Yes
 		noted No    
S3‑180610 draft Reply LS to R2-1801649 on RAN2 Assumption about DRB ID value range Nokia LS out Approval
4.1.4.3RRC security
 		Yes
Yes
 		revised No S3‑180848  
S3‑180611 Clean up of ENs in Clause 7.2.1 Authentication for Untrusted non-3GPP Access Nokia, Motorola Mobility, Lenovo pCR Approval
4.1.11.1Miscellaneous
 		Yes
Yes
 		revised No S3‑180940  
S3‑180612 Text for Clause 6.8.1.2.3 crypto separation for n3gpp Nokia pCR Approval
4.1.5.9Miscellaneous
 		Yes
Yes
 		revised No S3‑180884  
S3‑180613 Clean up of ENs in Clause 6.2.3 Handling of User related keys Nokia pCR Approval
4.1.5.9Miscellaneous
 		Yes
Yes
 		revised No S3‑180862  
S3‑180614 Resolving Editors notes 5.4.1 Security Visibility BT plc pCR Agreement
4.1.7.1Miscellaneous
 		Yes
Yes
BT and ORANGE supported this, with modifications.
KPN: not always we have a human with the UE.It depends on the application.
 
 
 		merged No S3‑180987  
S3‑180615 Resolving Editors notes 5.2.9 – Detailed Security Requirements for F1 interface BT plc pCR Agreement
4.1.12.1Miscellaneous
 		Yes
Yes
Telecom Italia: it's supposed to remove an editor's note what it stays. The new text is confusing.
 
 		revised No S3‑180949  
S3‑180616 Resolving Editors notes - 6.9.3 Key handling in mobility registration update - list of parameters to be stored in the UDSF as part of the 5G security context BT plc pCR Agreement
4.1.3.2Security in AMF change between AMF sets
 		Yes
Yes
Ericsson commented that this interface was supposed to be proprietary and that removing the editor's note should be enough.
 
 		revised No S3‑180956  
S3‑180617 Resolving Editors notes - 9.1.3.2 Protection at the network or transport layer – TLS certificate profiles BT plc pCR Approval
4.1.13.3Transport security (intra and inter-PLMN)
 		Yes
Yes
 		revised No S3‑180899  
S3‑180618 Resolving Editors notes 9.1.2.2 - DIAMETER or GTP - Network layer IPsec support mandatory or optional BT plc pCR Agreement
4.1.12.1Miscellaneous
 		Yes
Yes
 		revised No S3‑180950  
S3‑180619 Resolving Editors notes 6.1.3.2 - expiry time of an AV BT plc pCR Agreement
4.1.8.15G AKA over 3gpp/non3gpp access
 		Yes
Yes
 		merged No S3‑180909  
S3‑180620 Resolving Editor’s Note in clause 5.2.4 Huawei, Hisilicon pCR Approval
4.1.12.2Editorials
 		Yes
Yes
 		revised No S3‑180951  
S3‑180621 Corrections on Initiation of authentication procedure Huawei, Hisilicon pCR Approval
4.1.8.7Editorial corrections
 		Yes
Yes
 		revised No S3‑180924  
S3‑180622 Resolving Editor’s Note in clause 6.1.3.1 Huawei, Hisilicon pCR Approval
4.1.8.7Editorial corrections
 		Yes
Yes
Ericsson: not the right reference. It's not currently in TS 24.502.
This was taken offline.
 
 
 		noted No    
S3‑180623 Adding context on NAS integrity mechanisms and deleting Editor’s Note in clauses 6.4.3.1 and 6.4.3.3 Huawei, Hisilicon pCR Approval
4.1.5.4NAS integrity and confidentiality mechanisms
 		Yes
Yes
 		merged No S3‑180876  
S3‑180624 Adding context on NAS confidentiality mechanisms and deleting Editor’s Note in clause 6.4.4.1 Huawei, Hisilicon pCR Approval
4.1.5.4NAS integrity and confidentiality mechanisms
 		Yes
Yes
 		revised No S3‑180877  
S3‑180625 Resolving the Annex on Security handling in mobility (clause 6.9) and deleting Editor’s Note in clauses 6.9.2.3.4 and 6.9.4.5 Huawei, Hisilicon pCR Approval
4.1.3.7Editorials
 		Yes
Yes
 		approved No    
S3‑180626 Corrections on clause number of Annex A Huawei, Hisilicon pCR Approval
4.1.2.5Editorials
 		Yes
Yes
 		revised No S3‑180995  
S3‑180627 Subscription identification procedure Huawei, Hisilicon pCR Approval
4.1.14.4Miscellaneous
 		Yes
Yes
 		merged No S3‑180975  
S3‑180628 Discussion on protect the RR message during idle mobility from EPS to 5GS Huawei, Hisilicon discussion Discussion
4.1.10.1Idle mode 4G-5G
 		Yes
Yes
 		noted No    
S3‑180629 Clean up the EN in 8.2 Huawei, Hisilicon pCR Approval
4.1.10.1Idle mode 4G-5G
 		Yes
Yes
 		merged No S3‑180957  
S3‑180630 Clean up the EN in 6.4.5 Huawei, Hisilicon pCR Approval
4.1.5.7Multi-NAS security
 		Yes
Yes
 		revised No S3‑180879  
S3‑180631 Clean up the EN in 6.7.2 Huawei, Hisilicon pCR Approval
4.1.5.5NAS Security Mode Command
 		Yes
Yes
 		revised No S3‑181006  
S3‑180632 Clean up the EN in 6.9.4.1 Huawei, Hisilicon pCR Approval
4.1.3.6Miscellaneous
 		Yes
Yes
 		approved No    
S3‑180633 Clean up the EN in 8.3 Huawei, Hisilicon pCR Approval
4.1.10.3Handover 5GC-EPS
 		Yes
Yes
 		merged No S3‑180959  
S3‑180634 Clean up the EN in 8.4 Huawei, Hisilicon pCR Approval
4.1.10.4Handover EPS-5GC
 		Yes
Yes
 		merged No S3‑180960  
S3‑180635 Clean up the EN in 8.5 Huawei, Hisilicon pCR Approval
4.1.10.2Idle mode 5G-4G
 		Yes
Yes
 		merged No S3‑180958  
S3‑180636 Clean up the EN in 8.6 Huawei, Hisilicon pCR Approval
4.1.10.5Security context mapping
 		Yes
Yes
 		merged No S3‑180961  
S3‑180637 AS algorithm selection in state transitions between RRC-INACTIVE to RRC-CONNECTED states Huawei, Hisilicon pCR Approval
4.1.4.3RRC security
 		Yes
Yes
 		noted No    
S3‑180638 Key Handling at Transitions between RRC-INACTIVE and RRC-CONNECTED states Huawei, Hisilicon pCR Approval
4.1.4.3RRC security
 		Yes
Yes
 		noted No    
S3‑180639 Key Handling during mobility in RRC-INACTIVE state Huawei, Hisilicon pCR Approval
4.1.4.3RRC security
 		Yes
Yes
 		noted No    
S3‑180640 Security handling for RRC Connection Re-establishment Procedure Huawei, Hisilicon pCR Approval
4.1.4.3RRC security
 		Yes
Yes
 		approved No    
S3‑180641 RRC Security Mechanisms Huawei, Hisilicon pCR Approval
4.1.4.3RRC security
 		Yes
Yes
 		revised No S3‑180947  
S3‑180642 Add Skeleton for Dual Connectivity Huawei, Hisilicon pCR Approval
4.1.4.5Editorials
 		Yes
Yes
Docomo: When are we planning to fill in the text? I'd rather have this as a draftCR/CR in the next meeting.
 
 		noted No    
S3‑180643 Transfer Security policy in Xn HO Huawei, Hisilicon pCR Approval
4.1.4.2Userplane security
 		Yes
Yes
 		revised No S3‑180945  
S3‑180644 Transfer Security policy in N2 HO Huawei, Hisilicon pCR Approval
4.1.4.2Userplane security
 		Yes
Yes
 		revised No S3‑180946  
S3‑180645 UP keys are derived after receiving the security policy Huawei, Hisilicon pCR Approval
4.1.4.2Userplane security
 		Yes
Yes
 		merged No S3‑180944  
S3‑180646 The value Unique NAS connection identifier Huawei, Hisilicon pCR Approval
4.1.5.7Multi-NAS security
 		Yes
Yes
 		revised No S3‑180881  
S3‑180647 GUTIs are used to distinguish different security context from different PLMNs Huawei, Hisilicon pCR Approval
4.1.5.7Multi-NAS security
 		Yes
Yes
Ericsson: you can also use the PLMNid as well, better than the GUTI, that might change in the same PLMN several times. This is more an implementation issue.
Nokia agreed with Ericsson.
 
 		noted No    
S3‑180648 solve re-authentication problem in multi NAS connection Huawei, Hisilicon pCR Approval
4.1.5.7Multi-NAS security
 		Yes
Yes
Qualcomm, Nokia and Ericsson didn’t  agree with the use of timers.
 
 		noted No    
S3‑180649 Initial value of NAS count Huawei, Hisilicon pCR Approval
4.1.5.7Multi-NAS security
 		Yes
Yes
 		noted No    
S3‑180650 Delete EN of UP security agreement Huawei, Hisilicon pCR Approval
4.1.4.1Userplane open issues
 		Yes
Yes
 		merged No S3‑180942  
S3‑180651 Delete EN in section 6.2.2.1 Huawei, Hisilicon pCR Approval
4.1.2.4Miscellaneous
 		Yes
Yes
 		approved No    
S3‑180652 Addressing EN in Key setting clause Huawei, Hisilicon pCR Approval
4.1.2.3Key derivation AS related
 		Yes
Yes
 		noted No    
S3‑180653 Address concurrency issue in multi NAS connection Huawei, Hisilicon pCR Approval
4.1.5.7Multi-NAS security
 		Yes
Yes
 		revised No S3‑180882  
S3‑180654 Delete EN in key handling of state transition Huawei, Hisilicon pCR Approval
4.1.6.1Multiple registrations
 		Yes
Yes
 		approved No    
S3‑180655 pCR to 33.501 - removal of editor's notes on clause content NTT DOCOMO INC. pCR Approval
4.1.17Others
 		Yes
Yes
 		approved No    
S3‑180656 Moving UE handling SUCI to SUCI clause Huawei, Hisilicon, China Mobile pCR Approval
4.1.14.5Editorials
 		Yes
Yes
 		merged No S3‑180978  
S3‑180657 Making Kupint & Kupenc per PDU session. Key hirariechy, who will be taking this? Huawei, Hisilicon discussion Endorsement
4.1.2.3Key derivation AS related
 		Yes
Yes
 		revised No S3‑180839  
S3‑180658 Moving interfaces Xn, N2, and N3 security requirements to a proper clause Huawei, Hisilicon pCR Approval
4.1.2.5Editorials
 		No
Yes
 		revised No S3‑180663  
S3‑180659 UP security keys separation for the case of CU-CP and CU-UP separation. Huawei, Hisilicon pCR Approval
4.1.4.2Userplane security
 		Yes
Yes
Vodafone disagreed with this proposal.
Ericsson: this has UE impact so we disagree with the key separation.
Huawei: we would have here two different entities with the same key for different traffic for the same UE, and this should be communicated to RAN3 in the LS response.
Nokia: the two entities are not visible to the UE.
The Chair commented that the support was leaning to the Nokia proposal.
 
 
 		noted No    
S3‑180660 Retain Key policy on gNB Huawei, Hisilicon pCR Approval
4.1.4.3RRC security
 		No
Yes
 		revised No S3‑180662  
S3‑180661 Update requirements of UP security Huawei, Hisilicon pCR Approval
4.1.4.1Userplane open issues
 		Yes
Yes
Docomo: do we have this concept od deactivation?
It was agreed to remove it.
Ericsson, Qualcomm: the second requirement in 5.1.3.1 is not really a requirement, it’s a procedure.
It was taken offline where to place this second sentence.
 
 		revised No S3‑180942  
S3‑180662 Retain Key policy on gNB Huawei, Hisilicon,Chinamobile pCR Approval
4.1.4.3RRC security
 		Yes
Yes
 		noted No   S3‑180660
S3‑180663 Moving interfaces Xn, N2, and N3 security requirements to a proper clause Huawei, Hisilicon,NEC pCR Approval
4.1.2.5Editorials
 		Yes
Yes
 		approved No   S3‑180658
S3‑180664 Resolving EN on security capability mismatch in 6.7.2 LG Electronics pCR Approval
4.1.5.5NAS Security Mode Command
 		Yes
Yes
 		revised No S3‑180878  
S3‑180665 Discussion on security key for CU-CP UP separation LG Electronics discussion Discussion
4.1.4.2Userplane security
 		Yes
Yes
 		noted No    
S3‑180666 Discussion on SUCI construction scheme LG Electronics discussion Discussion
4.1.14.2SUCI and Schemes
 		Yes
Yes
 		noted No    
S3‑180667 Parameter for SUPI encryption LG Electronics pCR Approval
4.1.14.2SUCI and Schemes
 		Yes
Yes
Vodafone: SAGE's position is that they don’t need to be involved.
Ericsson: not necessary now.
 
 		noted No    
S3‑180668 Draft LS on subscription identifier encryption LG Electronics LS out Approval
4.1.14.2SUCI and Schemes
 		Yes
Yes
 		noted No    
S3‑180669 Resolving Editor’s Note on N3IWF authentication Lenovo, Motorola Mobility pCR Approval
4.1.11.1Miscellaneous
 		Yes
Yes
 		revised No S3‑180941  
S3‑180670 Security requirements for NEF Nokia pCR Approval
4.1.17Others
 		Yes
Yes
 		revised No S3‑180990  
S3‑180671 Security visibility of N3IWF identity confirmation Lenovo, Motorola Mobility pCR Approval
4.1.7.1Miscellaneous
 		Yes
Yes
 		noted No    
S3‑180672 Security for NEF Nokia pCR Approval
4.1.17Others
 		Yes
Yes
 		revised No S3‑180991  
S3‑180673 Resoving Editor’s Note on key generation for Unauthenticated IMS Emergency Sessions during handover Lenovo, Motorola Mobility pCR Approval
4.1.6.5Emergency call
 		Yes
Yes
 		approved No    
S3‑180674 SBA: Removing section on Diameter and GTP Nokia pCR Approval
4.1.13.6Miscellaneous
 		Yes
Yes
 		revised No S3‑180902  
S3‑180675 Adding normative text on SEPP to the security architecture section Nokia pCR Approval
4.1.13.1Interconnect (SEPP related)
 		Yes
Yes
 		revised No S3‑180891  
S3‑180676 Introduction to Application layer security in SEPP Nokia pCR Approval
4.1.13.2Protection of Attributes
 		Yes
Yes
Ericsson: no need to have the overview text. Have the titles as an editor's note as to-do list in the TS.
The Chair proposed to have it in the living document so as not to add another editor's note on the TS.
 
 		revised No S3‑180892  
S3‑180677 Discussion on re-prioritizing SBA security work for Phase 1 Nokia discussion Decision
4.1.13.1Interconnect (SEPP related)
 		Yes
Yes
DT wanted to avoid TLS and go for a viable solution in Rel-16. They didn’t want to enforce a solution that added very little advantages.
Docomo: Application layer between the SEPPs supported on TLS can work in this case. TLS is not the only solution, we need something on top of that.
BT supported this.
 
Vodafone: for me this solution is a backup, while we work on the other solutions. This is better than having no security solution at all.
 
 		noted No    
S3‑180678 Discussion paper on OAuth based service authorization framework for SBA Nokia discussion Approval
4.1.13.4NF-NRF Authentication & Authorization
 		Yes
Yes
 		noted No    
S3‑180679 Adding Emergency Services paragraph for Subscription Identification procedure KPN N.V. pCR Approval
4.1.14.4Miscellaneous
 		Yes
Yes
 		merged No S3‑180975  
S3‑180680 OAuth based service authorization framework for SBA Nokia pCR Approval
4.1.13.4NF-NRF Authentication & Authorization
 		Yes
Yes
 		revised No S3‑180885  
S3‑180681 OAuth based service authorization framework for SBA in roaming scenarios Nokia pCR Approval
4.1.13.4NF-NRF Authentication & Authorization
 		Yes
Yes
 		revised No S3‑180886  
S3‑180682 Discussion paper on Service access authorization for 5G SBA Nokia discussion Endorsement
4.1.13.5NF-NF Authentication & Authorization
 		Yes
Yes
 		revised No S3‑180887  
S3‑180683 Service access authorization based on static configuration Nokia pCR Approval
4.1.13.5NF-NF Authentication & Authorization
 		Yes
Yes
 		withdrawn Yes    
S3‑180684 Proposal and Discussion for Privacy and LI solution KPN, DT, BT, NTT DOCOMO, NEC discussion Approval
4.1.14.1SUPI and LI
 		Yes
Yes
Huawei, Samsung: binding the SUPI is overloading the functionality with another layer of variables.
Ericsson: solution must contain hash+SUPI as endorsed in a previous meeting, and this doesn’t appear in the proposed solution.
Huawei: Hash of the SUPI fails when compared with the hash of the SUPI of the network the connection is terminated.
KPN: go forward to the other two solutions without binding the SUPI.
 
This solution was named key binding.
 
 		noted No    
S3‑180685 Living Document: Security of PLMN/RAT selection policies for roaming Orange other Endorsement
4.9PLMN RAT selection
 		Yes
Yes
 		revised No S3‑180999  
S3‑180686 pCR to TR 33.834 - Updates to clauses 1 to 8 to prepare for approval Vodafone GmbH pCR Agreement
5.2Study on Long Term Key Update Procedures (FS_LTKUP) (Rel-15)
 		Yes
Yes
MCC asked whether the references to GSMA were publicly available. It was commented that the Global Platform ones were not available and this had to be taken offline for discussion with MCC.
 		revised No S3‑180843  
S3‑180687 Resolve EN in 5.10 Orange pCR Approval
4.1.17Others
 		Yes
Yes
MCC commented that instances of 4G should be replaced by LTE in the specification.
 
 		approved No    
S3‑180688 pCR to TR 33.834 - Update to solution 1 to correct references and update the evalustion Vodafone GmbH pCR Agreement
5.2Study on Long Term Key Update Procedures (FS_LTKUP) (Rel-15)
 		Yes
Yes
 		revised No S3‑180844  
S3‑180689 NIA0 support in the AMF Orange pCR Approval
4.1.5.1Requirements
 		Yes
Yes
 		revised No S3‑180873  
S3‑180690 pCR to TR 33.834 - update of reference numbers and conclusion to solution 2 Vodafone GmbH pCR Agreement
5.2Study on Long Term Key Update Procedures (FS_LTKUP) (Rel-15)
 		Yes
Yes
Alf: Remove the sentence on the extra processing power. This sentence was replaced as Docomo suggested.
 
 		revised No S3‑180934  
S3‑180691 USIM storage and usage for primary authentication Orange pCR Approval
4.1.8.15G AKA over 3gpp/non3gpp access
 		Yes
Yes
The Chair proposed a show of hands:
 
Who supports tdoc 691?
Vodafone, BT, TIM, IDEMIA,ORANGE,DT, KPN.
 
USIM in tamper resistant secure hardware?
Qualcomm, Lenovo, Nokia, Samsung, China Mobile, Ericsson, Huawei, Intel, Sprint.
 
Who objects to store the USIM in the UICC tdoc 691?
Samsung, Qualcomm, Intel, Ericsson,Nokia, Huawei.
 
Gemalto: what's the timeline for this? There may be things happening in ETSI SCP.
ORANGE replied that SSP could be included later.  
 		revised No S3‑181008  
S3‑180692 Agenda and notes of SA3 conference call on SBA/N32 security Deutsche Telekom AG other Information
4.1.13.6Miscellaneous
 		Yes
Yes
 		noted No    
S3‑180693 Resolution of EN in 6.1.2 - recognizing null-SUCI KPN N.V. pCR Approval
4.1.14.2SUCI and Schemes
 		Yes
Yes
 		merged No S3‑180925  
S3‑180694 pCR to 33.834 - update of solution evaluation for Solution 3 Vodafone GmbH pCR Agreement
5.2Study on Long Term Key Update Procedures (FS_LTKUP) (Rel-15)
 		Yes
Yes
 		revised No S3‑180935  
S3‑180695 USIM terminology fix Orange pCR Approval
4.1.14.5Editorials
 		Yes
Yes
 		revised No S3‑180977  
S3‑180696 Agenda and notes of joint conference call on SBA/N32 security Deutsche Telekom AG other Information
4.1.13.6Miscellaneous
 		Yes
Yes
 		noted No    
S3‑180697 pCR to 33.834 - Update of reference numbers and solution evaluation for solution 4 Vodafone GmbH pCR Agreement
5.2Study on Long Term Key Update Procedures (FS_LTKUP) (Rel-15)
 		No
Yes
 		withdrawn Yes    
S3‑180698 pCR to 33.834 - removal of template Ki issues and Solutions in preparation for Specification approval Vodafone GmbH pCR Agreement
5.2Study on Long Term Key Update Procedures (FS_LTKUP) (Rel-15)
 		No
Yes
 		withdrawn Yes    
S3‑180699 New key for IPSec in non-3GPP access Ericsson pCR Approval
4.1.11.1Miscellaneous
 		Yes
Yes
 		noted No    
S3‑180700 Agreement for EN on TAU protection in idle mode mobility from 5GS to EPS Ericsson discussion Endorsement
4.1.10.2Idle mode 5G-4G
 		Yes
Yes
 		endorsed No    
S3‑180701 Agreement for EN on KASME generation in idle mode mobility from 5GS to EPS Ericsson discussion Endorsement
4.1.10.2Idle mode 5G-4G
 		Yes
Yes
 		endorsed No    
S3‑180702 Agreement for EN on the need for a NAS SMC in idle mode mobility from 5GS to EPS Ericsson discussion Endorsement
4.1.10.2Idle mode 5G-4G
 		Yes
Yes
 		endorsed No    
S3‑180703 pCR for idle mode mobility from 5GS to EPS Ericsson pCR Approval
4.1.10.2Idle mode 5G-4G
 		Yes
Yes
 		revised No S3‑180958  
S3‑180704 Agreement for EN on inclusion of TAU in idle mode mobility from EPS to 5GS Ericsson discussion Endorsement
4.1.10.1Idle mode 4G-5G
 		Yes
Yes
 		endorsed No    
S3‑180705 Agreement for EN on protection of RR message using mapped security context in idle mode mobility from EPS to 5GS Ericsson discussion Endorsement
4.1.10.1Idle mode 4G-5G
 		Yes
Yes
 		endorsed No    
S3‑180706 Agreement for EN on activation of mapped security context in idle mode mobility from EPS to 5GS Ericsson discussion Endorsement
4.1.10.1Idle mode 4G-5G
 		Yes
Yes
 		endorsed No    
S3‑180707 pCR for idle mode mobility from EPS to 5GS Ericsson pCR Approval
4.1.10.1Idle mode 4G-5G
 		Yes
Yes
 		merged No S3‑180957  
S3‑180708 IW HO from 5G to 4G Ericsson pCR Approval
4.1.10.3Handover 5GC-EPS
 		Yes
Yes
Huawei didn’t agree with the details, but Ericsson replied that this was coming from 33.401 and it wasn't the implementation of a new solution.
 
 		revised No S3‑180959  
S3‑180709 IW HO from 4G to 5G Ericsson pCR Approval
4.1.10.4Handover EPS-5GC
 		Yes
Yes
 		merged No S3‑180960  
S3‑180710 Stepwise way forward for SBA security: SEPP- SEPP security capability negotiation Ericsson pCR Approval
4.1.13.1Interconnect (SEPP related)
 		Yes
Yes
Telecom Italia: does this work if only TLS is used in Rel-15?
Ericsson: yes.
Nokia didn’t agree with steps 0 and 4 in figure 9.1.3.X. Just a secure connection established should be displayed.
BT didn’t agree with this. ORANGE preferred to move this to the living document.
 
 
 		revised No S3‑180893  
S3‑180711 Policies for IE protection at SEPP Ericsson pCR Approval
4.1.13.1Interconnect (SEPP related)
 		Yes
Yes
Deutsche Telekom supported this.
Nokia commented that this was a lot of work and it was better to put it into the living document for further study. There were different options to choose from.
Ericsson preferred to have it in the TS already since they thought that after its approval it would be more difficult to add more content.
MCC commented that it was possible to add this later since the TS was to be approved when it’s completed in its 80%. SBA would have to be added as outstanding work left in the TS cover.
BT preferred to see the whole thing going into the TS. For example CT4 would likely prefer to have this content in Rel-15.
Telecom Italia asked about the living document. The Chair commented that the living document served as a study given that the SBA task came really late to SA3.
 
It was decided to split it into a living document and to the TS.
 
 		noted No    
S3‑180712 TLS for SEPP-IPX communication Ericsson pCR Approval
4.1.13.1Interconnect (SEPP related)
 		Yes
Yes
DT: the use should be optional, not mandatory.
Telecom Italia: in the conference call we had agreed on a different solution from TLS. Why did we do the conference call?
Vodafone: we have talked with IPX providers, they are OK with having direct TLS and not hop-by-hop.
DT: it's really hard to enforce having end-to-end TLS when transitioning to Rel-16.
 
The Chair commented that CT needed a SA3 solution for May, and an exception should be avoided at all costs.
 
It was argued whether gor for "shall be used" or "shall be supported". The second option was chosen.
 
Note from MCC: "Technical standards specify functionality which shall be implemented. They do not specify whether users use that functionality or not".
 		revised No S3‑180890  
S3‑180713 Root key distribution and PKI for SEPP out of scope Ericsson other Approval
4.1.13.1Interconnect (SEPP related)
 		Yes
Yes
 		approved No    
S3‑180714 SBA Authorization Framework Ericsson pCR Approval
4.1.13.4NF-NRF Authentication & Authorization
 		Yes
Yes
DT: no time to define a new functionality for SAF.
ORANGE: colocate this functionality in the NRF.
ORANGE: do we need all these functionalities if we are in the same network domain? The functionality should be supported, optional to use.
 
 		merged No S3‑180885  
S3‑180715 Discussion and pCR for inter-PLMN token-based authorization. Ericsson pCR Approval
4.1.13.4NF-NRF Authentication & Authorization
 		Yes
Yes
 		merged No S3‑180886  
S3‑180716 Annex C (SUCI – ECIES profiles) Ericsson, Vodafone pCR Approval
4.1.14.2SUCI and Schemes
 		Yes
Yes
NIST suggested to change some profiles to make them mandatory.
Vodafone: we don’t believe that a single curve is trusted all around the World. We prefer having five curves.
Huawei: Two curves here are not widely implemented, so we have concerns about this. The curve in Qualcomm's proposal is fine with us.We don’t have a strong opinion on the number of curves.
The Chair commented that there was general support for having two curves.
Qualcomm asked whether it was better to restrict to two curves in Rel-15, and go for the rest in later releases.
Curve A and C were the preferred ones by NIST, NCSC and Vodafone.
 
 
 		revised No S3‑180964  
S3‑180717 Update to Clause 7 – IV entropy Ericsson pCR Approval
5.3Study on Supporting 256-bit Algorithms for 5G (FS_256-Algorithms) (Rel-16)
 		Yes
Yes
ORANGE expressed their concerns on the format of the contributions were making them hard to implement in the TR. Vodafone commented that this would be solved in the next meeting.
approved No    
S3‑180718 Update to Clause 10 – RES and Editorials Ericsson pCR Approval
5.3Study on Supporting 256-bit Algorithms for 5G (FS_256-Algorithms) (Rel-16)
 		Yes
Yes
 		approved No    
S3‑180719 Clarification need of CMPv2 in TS 33.310 Ericsson discussion Decision
4.8CMPv2
 		Yes
Yes
 		noted No    
S3‑180720 Use of fields in CMPv2 Ericsson CR Agreement
4.8CMPv2
 		Yes
Yes
Deutsche Telekom had concerns with this, it wasn't helpful for them.
Vodafone agreed with DT.
Huawei: this is not a problem. After 10 years we haven’t seen any issues.
 
 		postponed No    
S3‑180721 Requirements for the protection of attributes on N32 Deutsche Telekom AG pCR Approval
4.1.13.7Editorials
 		Yes
Yes
 		revised No S3‑180904  
S3‑180722 pCR to 33.834 - Addition of conclusions and removal of Annex A Vodafone GmbH pCR Agreement
5.2Study on Long Term Key Update Procedures (FS_LTKUP) (Rel-15)
 		No
Yes
 		withdrawn Yes    
S3‑180723 Requirement on routing SUCI CATT pCR Approval
4.1.14.3SIDF
 		Yes
Yes
TIM: what’s the value of this new text? ORANGE, Vodafone agreed.
 
 		noted No    
S3‑180724 Derivation of KgNB and KN3IWF Ericsson pCR Approval
4.1.2.3Key derivation AS related
 		Yes
Yes
 		merged No S3‑180995  
S3‑180725 Refine requirements of SIDF CATT pCR Approval
4.1.14.3SIDF
 		Yes
Yes
ORANGE: there is no visited network's UDM. It doesn’t exist.
 
 		noted No    
S3‑180726 Input to horizontal key derivation at AMF change Ericsson pCR Approval
4.1.2.1Key derivation mobility related
 		Yes
Yes
 		noted No    
S3‑180727 pCR to TS33.501 - Session binding to prevent potential 5G-AKA vulnerability Vodafone GmbH pCR Approval
4.1.8.15G AKA over 3gpp/non3gpp access
 		Yes
Yes
NCSC: In Step 5 send more information.
Nokia: This  is presenting a solution against an attack scenario cited by an external paper by researchers. The scenario they cited is not new and it exists even in LTE. But in actual implementations this attack doesn’t happen because of the reliability mechanisms built in to the transport protocol. It may be a good idea to build the transaction identifier in to the authentication protocol, but the current proposal is not correct. When the source AUSF requests Authentication vectors from ARPF/UDM, it is requesting using the SUCI/SUPI it received from the UE. To bind the response it receives from the ARPF/UDM, the response message should contain the SUCI/SUPI from the Request message, not the actual /de-concealed SUPI by the UDM for which the AVs are generated.
 
NEC: having the SUPI go back is a concern and may be subject to IMSI catchers.
It was discussed how to handle comments from parties outside 3GPP (e.g. researchers). The Chair commented that 3GPP was setting up an official procedure to answer to these kind of comments.
 
 		noted No    
S3‑180728 N2-handover with horizontal key derivation Ericsson pCR Approval
4.1.3.2Security in AMF change between AMF sets
 		Yes
Yes
 		revised No S3‑180954  
S3‑180729 Presentation of Solution that is compatible with end-to-end security between SEPPs and mediation services KPN N.V. discussion Discussion
4.1.13.1Interconnect (SEPP related)
 		Yes
Yes
 		noted No    
S3‑180730 pCR to 33.501 – Timing of SUPI Reveal Vodafone GmbH pCR Approval
4.1.8.15G AKA over 3gpp/non3gpp access
 		Yes
Yes
ORANGE preferred the Note here to the option in 585. It was also agreed to have normative text instead of the note.
ORANGE: Do you need to know the SUPI when authenticating from LI perspective?
Mark: no, we are fine with this document.
revised No S3‑180911  
S3‑180731 pCR to living document on SBA (S3-180352) KPN N.V. other Approval
4.1.13.1Interconnect (SEPP related)
 		Yes
Yes
 		approved No    
S3‑180732 pCR based on S3-180729 (E2E between SEPPs with mediation services) KPN N.V. pCR Approval
4.1.13.1Interconnect (SEPP related)
 		Yes
Yes
 		noted No    
S3‑180733 Annex F: the subscriber identity used with key derivation in EAP-AKA’ Ericsson pCR Approval
4.1.8.2EAP AKA’ over 3gpp/non3gpp access
 		Yes
Yes
Qualcomm: Why not using USIP for the calculation in all cases? This was taken offline.
 
 		noted No    
S3‑180734 Privacy with EAP-TLS Ericsson pCR Approval
4.1.8.4Authentication using EAP TLS
 		Yes
Yes
 		merged No S3‑180921  
S3‑180735 Discussion on SoR mechanism NEC Corporation discussion Discussion
4.9PLMN RAT selection
 		Yes
Yes
Vodafone: There are more issues with overloading the authentication. This is just one of the cases.
 		endorsed No    
S3‑180736 5G-ACA when confirmation of RES* is not correct Ericsson pCR Approval
4.1.8.15G AKA over 3gpp/non3gpp access
 		Yes
Yes
Similar to 584, they were merged.
 
 		revised No S3‑180910  
S3‑180737 Security contexts established independently by separate primary Ericsson pCR Approval
4.1.5.7Multi-NAS security
 		Yes
Yes
 		approved No    
S3‑180738 Rules on Concurrent Running of Security Procedures Ericsson pCR Approval
4.1.5.7Multi-NAS security
 		Yes
Yes
Ericsson: we are not closing this discussion, just starting it to trigger the work; this is a huge table that needs further input from companies.
The Chair commented for the minutes that more rules are expected on this topic.
 
 
 		approved No    
S3‑180739 AS security establishment during transition from RM-DEREGISTERED to RM-REGISTERED Ericsson pCR Approval
4.1.6.6Miscellaneous
 		Yes
Yes
 		revised No S3‑180980  
S3‑180740 Content to Clause 6.4.3 on NAS integrity mechanisms Ericsson pCR Approval
4.1.5.4NAS integrity and confidentiality mechanisms
 		Yes
Yes
 		revised No S3‑180876  
S3‑180741 Content to Clause 6.4.4 on NAS Confidentiality mechanisms Ericsson pCR Approval
4.1.5.4NAS integrity and confidentiality mechanisms
 		Yes
Yes
 		merged No S3‑180877  
S3‑180742 Negotiation of NR & LTE algorithms with 5GC Ericsson pCR Approval
4.1.5.3NAS algorithm selection
 		Yes
Yes
It was agreed to add the abreviations of g-NodeB and NG-RAN and so on instead of the definitions (which are in the SA2 and RAN documents).
 
 
 		revised No S3‑180875  
S3‑180743 Updates to SMS over NAS security clause Ericsson pCR Approval
4.1.5.8SMS over NAS
 		Yes
Yes
 		revised No S3‑180905  
S3‑180744 Removal of initial NAS protection (clause 6.4.6) Ericsson pCR Approval
4.1.5.2Protection of initial NAS message
Yes
Yes
Deutsche Telekom didn’t agree with removing this clause. They wanted to see a detail of what Ies to protect and which ones not to protect.
Ericsson: the work here on the IEs hasn’t progressed with contributions, hence we remove it.
Qualcomm: ask SA2 whether we are protecting an IE that is needed.
Huawei: too late to go back to SA2 to ask for any changes, we agree with Ericsson.
The Chair asked for a show of hands:
BT,Nokia,Huawei, China Mobile supported this document.
Against: Deutsche Telekom, Qualcomm, T-Mobile.
 
 		noted No    
S3‑180745 Agreement for NAS security activation for multiple NAS connections Ericsson discussion Endorsement
4.1.5.7Multi-NAS security
 		Yes
Yes
Qualcomm: Not key change but security context change in the last bullet.
 		endorsed No    
S3‑180746 Agenda and notes of conference call on bidding down between 5G releases Ericsson report Information
4.1.2.4Miscellaneous
 		Yes
Yes
 		noted No    
S3‑180747 Coexistence of Phase 1 and 2 AMF with standalone SEAF Ericsson discussion Information
4.1.2.4Miscellaneous
 		Yes
Yes
Discussed in the conference call. Provided for information.
 
 
 		noted No    
S3‑180748 Clause 6.6.2 (userplane security policy) Ericsson pCR Approval
4.1.4.2Userplane security
 		Yes
Yes
 		revised No S3‑180920  
S3‑180749 Editor Note in clause 6.7.4 about the use of AS SMC in DC Ericsson pCR Approval
4.1.4.3RRC security
 		Yes
Yes
 		revised No S3‑180948  
S3‑180750 Clause 6.6.2 (userplane security activation) Ericsson pCR Approval
4.1.4.2Userplane security
 		Yes
Yes
 		revised No S3‑180944  
S3‑180751 Clause 6 (agreements forgotten to get recorded) Ericsson pCR Approval
4.1.4.1Userplane open issues
 		Yes
Yes
 		noted No    
S3‑180752 Clause 6.8.2.1 (key handling – RRC INACTIVE/CONNECTED state transition) Ericsson pCR Approval
4.1.4.3RRC security
 		Yes
Yes
 		noted No    
S3‑180753 Clause 6.8.2.2 (key handling – RRC INACTIVE mobility) Ericsson pCR Approval
4.1.4.3RRC security
 		Yes
Yes
 		noted No    
S3‑180754 [DRAFT] LS on SoR mechanism NEC Corporation LS out Agreement
4.9PLMN RAT selection
 		Yes
Yes
Huawei: no security issue when this authentication method.
NEC: there is a dependency of the VPLMN to implement this functionality and they have no incentive to implement this functionality.
 
 
 		revised No S3‑180998  
S3‑180755 Requirement on SIDF NEC, Nokia, CMCC pCR Approval
4.1.14.3SIDF
 		Yes
Yes
 		revised No S3‑180974  
S3‑180756 Usage and Identification of Key left at AUSF NEC Europe Ltd pCR Approval
4.1.8.7Editorial corrections
 		Yes
Yes
Nokia: keep the editor's note on KAUSF, there are still open issues.
 Ericsson: we cannot agree with this document in the current form.
 		noted No    
S3‑180757 Resolving an EN on randomness of SUCI in Clause 6.12.2 NEC Europe Ltd pCR Approval
4.1.14.2SUCI and Schemes
 		Yes
Yes
 		revised No S3‑180967  
S3‑180758 Resolving EN on UDM Instance selection NEC, CMCC pCR Approval
4.1.14.3SIDF
 		Yes
Yes
 		noted No    
S3‑180759 Resolving EN on Clarification of how AUSF determines a clear text SUPI NEC Europe Ltd pCR Approval
4.1.8.7Editorial corrections
 		Yes
Yes
 		revised No S3‑180925  
S3‑180760 Resolving Editor’s Notes in clause 6.2.2 NEC pCR Approval
4.1.1.1Miscellaneous
 		Yes
Yes
Huawei: we don’t agree with "The KSEAF  shall be stored at the SEAF".
Docomo: take the requirement out of the note. We also need to number the notes.
 
 		revised No S3‑180867  
S3‑180761 discussion paper on embedded routing information in SUCI Vodafone GmbH discussion Agreement
4.1.14.3SIDF
 		Yes
Yes
 
 
 		noted No    
S3‑180762 Resolution of editor’s notes in clause 8.6 NEC Europe Ltd pCR Approval
4.1.10.5Security context mapping
 		Yes
Yes
 		revised No S3‑180961  
S3‑180763 pCR to 33.501 - addition of routing information into SUCI Vodafone GmbH pCR Agreement
4.1.14.3SIDF
 		Yes
Yes
LG,Gemalto, BT,IDEMIA supported this contribution.
 		noted No    
S3‑180764 Revision of S3-180078 SUCI intro and handling - NEC-KPN-Nokia merger Nokia, KPN, NEC pCR Decision
4.1.14.5Editorials
 		Yes
Yes
 		revised No S3‑180978  
S3‑180765 Revision of S3-180077 UDM requirements - key management and privacy - NEC-Nokia merger Nokia, NEC pCR Decision
4.1.14.3SIDF
 		Yes
Yes
ORANGE: this is implementation specific.  Ericsson and Gemalto agreed, there were many implementation details.
 
 		noted No    
S3‑180766 UDM - SIDF discussion Nokia pCR Discussion
4.1.14.3SIDF
 		Yes
Yes
 		noted No    
S3‑180767 UDM - SIDF discussion implemented in pCR Nokia pCR Decision
4.1.14.3SIDF
 		Yes
Yes
ORANGE: the first part mixes implementation, use case, business parts. They didn’t support this contribution.
 
 		noted No    
S3‑180768 Discussion on LI conformity by verification hash with ppt attachment Nokia discussion Discussion
4.1.14.1SUPI and LI
 		Yes
Yes
Huawei: this is error prone if the serving network doesn't use the SUPI from the HPLMN to create a hash.
Interdigital supported this option.
ORANGE: French authorities want to avoid things becoming easier in privacy. 5G should be as difficult as 4G to change the USIM.
 
 		noted No    
S3‑180769 5G AKA with verification hash Nokia, Gemalto, IDEMIA pCR Decision
4.1.14.1SUPI and LI
 		Yes
Yes
Nokia commented that they had a merger of verification hash and key binding solutions.
Some companies were uncomfortable with new solutions presented for this meeting: Qualcomm and Huawei.
Qualcomm: if the hash function falls down it weakens the whole thing. We cannot accept any solution that includes hash verification. Huawei supported this.
BT commented that merging existing solutions should not be a problem since it was common practice. ORANGE agreed.
The Chair commented that there had to be consensus for the merging and it was a normal procedure in 3GPP. Companies were allowed to object a merging of existing solutions, since this meant that the consensus was not reached.
 
The Chair asked for a show of hands:
 
-Tdoc 684 Key binding:
 
Verizon, Docomo, BT, TIM, DT, Juniper, NEC, China Mobile, NCSC, Home Office, NTAC, NIST,KPN.
 
- Tdoc 769 Verification has solution:
 
Gemalto, Interidigital, Lenovo, Nokia, IDEMIA.
 
- Tdoc 963 combined solution:
 
Interdigital, Juniper, T-mobile, Docomo, DT, China Mobile,Lenovo, Nokia, NEC, IDEMIA, Gemalto, Vodafone, KPN, NIST.
 
- Tdoc 818 NAS SMC:
 
Samsung, Ericsson, Qualcomm, Huawei, CATT, Intel, ZTE.
 
Docomo recommended to merge some of these building blocks with consensus.
 
It was pointed out that both tdocs 769 and 818 didn’t have any operator support.
 
ORANGE: TS 33.501 will not be ready for approval if a solution is not decided here.
 
Additional show of hands for who was objecting to the documents:
 
-Tdoc 684:
Nokia, Interdigital, Huawei, Ericsson,CATT.
 
-Tdoc 769:
 
Qualcomm, Ericsson, Huawei, Intel, ZTE, CATT, TIM.
 
-Tdoc 963:
 
Qualcomm, Ericsson, Huawei, ZTE, Intel, CATT.
 
-Tdoc 818 NAS SMC:
 
Interdigital, Lenovo, Nokia, T-Mobile.
 
After offline discussions Qualcomm asked the companies supporting the NAS SMC solution if the key binding solution was acceptable for them in order to go forward.
 
Nokia emphasized to hold their objection against the stand-alone solution "SUPI key binding" because of the issues raised by several companies as summarized here:
 
Samsung – no dedicated error scenario
Huawei – binding is overloading the functionality
Ericsson – agreement from last meeting - solution shall be based on hash – key binding is not a hash
Docomo – should be a cryptographic failure, binding does allow failure in normal operation
Nokia – fraud scenario is not addressed, but operator wants to know, why failure happens
Nokia – full AKA run before failure is discovered
 
 		noted No    
S3‑180770 Clarification on AKA Nokia pCR Decision
4.1.8.7Editorial corrections
 		Yes
Yes
 		noted No    
S3‑180771 Key hierarchy Nokia pCR Decision
4.1.1.1Miscellaneous
 		Yes
Yes
 		revised No S3‑180859  
S3‑180772 Correction to clause 6.1.4 Nokia pCR Decision
4.1.1.2Editorials
 		Yes
Yes
 		revised No S3‑180872  
S3‑180773 Editorial correction to annex A.6 Nokia pCR Decision
4.1.2.5Editorials
 		Yes
Yes
 		approved No    
S3‑180774 Improvement of text in subclause 6.6.2 NEC Europe Ltd pCR Approval
4.1.4.2Userplane security
 		Yes
Yes
 		merged No S3‑180944  
S3‑180775 Justification on the need for security feature bidding down Qualcomm Incorporated discussion Endorsement
4.1.5.9Miscellaneous
 		Yes
Yes
BT and Docomo supported this contribution. Since there seemed to be a general support to this the document was endorsed.
 
 		endorsed No    
S3‑180776 Adding a generic bid down solution to the 5G TS Qualcomm Incorporated pCR Approval
4.1.5.9Miscellaneous
 		Yes
Yes
 		revised No S3‑180883 S3‑180243
S3‑180777 Adding the details to the protection of the initial message clause Qualcomm Incorporated pCR Approval
4.1.5.2Protection of initial NAS message
Yes
Yes
 		noted No    
S3‑180778 Removal of the hashing method from NAS SMC as security covered by the initial NAS message protection Qualcomm Incorporated pCR Approval
4.1.5.2Protection of initial NAS message
Yes
Yes
 		noted No    
S3‑180779 Protecting IMEI in NAS Security Mode Command Qualcomm Incorporated pCR Approval
4.1.14.4Miscellaneous
 		Yes
Yes
 		noted No    
S3‑180780 Corrections and clarification for EDCE5 Qualcomm Incorporated CR Agreement
4.6EPC enhancements to support 5G New Radio via Dual Connectivity (EDCE5) (Rel-15)
 		Yes
Yes
 		revised No S3‑180855  
S3‑180781 Deleting the editor’s note on KAUSF derivation Qualcomm Incorporated pCR Approval
4.1.2.4Miscellaneous
 		Yes
Yes
 		approved No    
S3‑180782 Adding the identifier of KSEAF Qualcomm Incorporated pCR Approval
4.1.1.1Miscellaneous
 		Yes
Yes
There was some disagreement to remove the editor's note on KAUSF and KSEAF needing to be identified. This was considered still an open issue for some companies.
Huawei: when do we need to identify the KSEAF?
Docomo: Once the KAUSF is identified the KSEAF is identified as well, and viceversa.
 
 		revised No S3‑180860  
S3‑180783 Emergency call handling for EDCE5 Qualcomm Incorporated CR Agreement
4.6EPC enhancements to support 5G New Radio via Dual Connectivity (EDCE5) (Rel-15)
 		Yes
Yes
Docomo: Is there any requirement for supporting unauthenticated emergency calls?
 		not pursued No    
S3‑180784 pCR to resolve ENs and update the registration procedure for mobility from EPS to 5GS Qualcomm Incorporated pCR Approval
4.1.10.1Idle mode 4G-5G
 		Yes
Yes
 		revised No S3‑180957  
S3‑180785 pCR to resolve ENs and update the handover procedure from 5GS to EPS over N26 Qualcomm Incorporated pCR Approval
4.1.10.3Handover 5GC-EPS
 		Yes
Yes
 		merged No S3‑180959  
S3‑180786 pCR to resolve ENs and update the handover procedure from EPS to 5GS over N26 Qualcomm Incorporated pCR Approval
4.1.10.4Handover EPS-5GC
 		Yes
Yes
 		revised No S3‑180960  
S3‑180787 pCR to resolve ENs and update the idle mode mobility procedure from 5GS to EPS over N26 Qualcomm Incorporated pCR Approval
4.1.10.2Idle mode 5G-4G
 		Yes
Yes
 		noted No    
S3‑180788 pCR to resolve ENs regarding the triggering of NAS SMC in mobility from 5GS to EPS over N26 Qualcomm Incorporated pCR Approval
4.1.10.2Idle mode 5G-4G
 		Yes
Yes
 		noted No    
S3‑180789 pCR to resolve ENs and update the security context mapping in interworking Qualcomm Incorporated pCR Approval
4.1.10.5Security context mapping
 		Yes
Yes
Huawei: KSEAF doesn't have any value in this case. Ericsson agreed. The involvement of the SEAF is not required in the interworking.
Docomo: Generate a new KSEAF will not lead to a security issue. If the AMF is not trustworthy it can use the redirection to generate the new KSEAF.
 
 		merged No S3‑180961  
S3‑180790 pCR to propose a KAMF derivation function and resolve ENs regarding KAMF derivation Qualcomm Incorporated pCR Approval
4.1.3.1Key derivations during handovers
 		Yes
Yes
Discussed together with 577 and 726. Nokia supported the Downlink count option.
NEC: which downlink count you refer to? There are two.
Qualcomm: the one for the 3GPP access.
 
 		noted No    
S3‑180791 pCR to remove some ENs in Clause 6 that have already been addressed in the present specification or are irrelevant of the present specification Qualcomm Incorporated pCR Approval
4.1.4.1Userplane open issues
 		Yes
Yes
 		merged No S3‑180942  
S3‑180792 Setting EEA7 and EIA7 to enable AMF to force MME to run a NAS SMC Qualcomm Incorporated CR Agreement
4.1.10.2Idle mode 5G-4G
 		Yes
Yes
 		not pursued No    
S3‑180793 Support of privacy schemes and profiles by the UE Qualcomm Incorporated pCR Approval
4.1.14.2SUCI and Schemes
 		Yes
Yes
 		merged No S3‑180964 S3‑180258
S3‑180794 Support for Steering of Roaming UE in 5GS Qualcomm Incorporated pCR Approval
4.9PLMN RAT selection
 		Yes
Yes
The requirements part will be added to the living document.
 
 		merged No S3‑181003  
S3‑180795 Proposed solution and conclusion for PLMN/RAT seleection Qualcomm Incorporated other Approval
4.9PLMN RAT selection
 		Yes
Yes
ORANGE: no update in the USIM.
Qualcomm agreed with this change.
Huawei: It should be optional for the HPLMN according to CT1, this is not the case here.
ORANGE didn’t think this was a major issue.
Vodafone: I object because it ties with authentication.We don’t agree with the role of the UDM here either.
Qualcomm clarified that this worked with any authentication and clarified the role of the UDM.
BT: in CT1 there are companies that don’t want a separate network element. It is mentioned in the LS.
Samsung: they prefer a control plane mechanism.
Qualcom was fine with this.
IDEMIA: why not updating the USIM?
ORANGE: there is no requirement for this.
Vodafone, ORANGE wanted the conclusion to be deleted.
This was agreed.
 
 
 
 		revised No S3‑181000  
S3‑180796 Deleting EN about RES* calculation in 5G AKA Qualcomm Incorporated pCR Approval
4.1.6.4UE handling
 		Yes
Yes
 		approved No    
S3‑180797 Resolving ENs in 5.1.4 Qualcomm Incorporated pCR Approval
4.1.17Others
 		Yes
Yes
GEMALTO: just leave "out of scope", I don’t agree with "determined by the issuer..".
This NOTE was reworded.
Vodafone: I'd rather store the certifications and analize them as part of the provisioning process. We will bring a contribution for this for the next meeting.
 		revised No S3‑180989  
S3‑180798 Resolution for ENs related to Security Visibility Qualcomm Incorporated, Samsung pCR Approval
4.1.7.1Miscellaneous
 		Yes
Yes
 		revised No S3‑180987  
S3‑180799 [eMCSEC] Adding Integrity Key for KMS communications - Correcting XML NCSC CR Agreement
4.3Mission Critical Security Enhancements (eMCSec) (Rel-15)
 		No
Yes
 		withdrawn Yes   S3‑180332
S3‑180800 [eMCSec] 33.180 R15 Interconnection and Interworking media and signaling NCSC CR Agreement
4.3Mission Critical Security Enhancements (eMCSec) (Rel-15)
 		Yes
Yes
 		revised No S3‑180926 S3‑180376
S3‑180801 [eMCSEC] Cleanup of EAR description NCSC CR Agreement
4.3Mission Critical Security Enhancements (eMCSec) (Rel-15)
 		No
Yes
 		withdrawn Yes    
S3‑180802 [eMCSEC] Providing details of EARs into Annex J NCSC CR Agreement
4.3Mission Critical Security Enhancements (eMCSec) (Rel-15)
 		Yes
Yes
 		agreed No    
S3‑180803 [eMCSEC] Clarification of purpose of Inter-domain user service authorisation NCSC CR Agreement
4.3Mission Critical Security Enhancements (eMCSec) (Rel-15)
 		Yes
Yes
 		revised No S3‑180906  
S3‑180804 [eMCSEC] Correction of reference to SA1 specification NCSC CR Agreement
4.3Mission Critical Security Enhancements (eMCSec) (Rel-15)
 		Yes
Yes
 		agreed No    
S3‑180805 Clean up of ENs in Clause 12 Security aspects of NAS over SMS Nokia pCR Approval
4.1.5.8SMS over NAS
 		Yes
Yes
Huawei: this is a security procedure for a SA2 issue.
Ericsson: there is a note on the SA2 spec that this is depending on a solution from CT1, and it’s likely that it will not incorporated in phase two.
 
 		merged No S3‑180905  
S3‑180806 SBA message names in N12 and N13 Ericsson, KPN pCR Approval
4.1.8.7Editorial corrections
 		Yes
Yes
 		approved No    
S3‑180807 Security mechanism for steering of roaming during authentication procedure SAMSUNG other  
4.9PLMN RAT selection
 		Yes
Yes
 		revised No S3‑181001  
S3‑180808 Reply LS on User Plane Security Policy R3-180637 LS in  
4.1.15Incoming and outgoing LSes
 		Yes
Yes
Nokia: We don’t need a policy to enable encripytion from the SMF.
Ericsson commented that they were fine with having that confidentiality would be removed from the UP policy keeping the integrity part. The confidentiality protection will be kept mandatory.
Nokia: this means that we add more signalling.
The LS was noted since this discussion didn’t impact it.
 
 		noted No    
S3‑180809 Authentication related services provided by AUSF Ericsson pCR Approval
4.1.8.7Editorial corrections
 		Yes
Yes
There is an LS to CT4 and SA2 in 814 related to this document.
 
 		revised No S3‑180916  
S3‑180810 AUSF Protecting the Steering of Roaming Information SAMSUNG other  
4.9PLMN RAT selection
 		Yes
Yes
 		approved No    
S3‑180811 Conclusions for Security of PLMN/RAT selection policies for roaming SAMSUNG other  
4.9PLMN RAT selection
 		Yes
Yes
 		noted No    
S3‑180812 pCR Security of PLMN/RAT selection policies for roaming SAMSUNG Electronics Co., Ltd. pCR  
4.9PLMN RAT selection
 		Yes
Yes
 		noted No    
S3‑180813 Authentication related services provided by UDM Ericsson pCR Approval
4.1.8.7Editorial corrections
 		Yes
Yes
 		revised No S3‑180917  
S3‑180814 [DRAFT] LS on authentication related services provided by AUSF and UDM Ericsson LS out Approval
4.1.15Incoming and outgoing LSes
 		Yes
Yes
Nokia: SA3 should not create terminology to be defined in CT3.
Vodafone: we are talking about reservation of the names in 23.502 and used in TS 23.501, but the functionality shouldn’t be moved to TS 23.502.
revised No S3‑180918  
S3‑180815 Corrections to multiple authentication vector text references SAMSUNG pCR  
4.1.8.7Editorial corrections
 		Yes
Yes
 		approved No    
S3‑180816 Resolving Editors' Notes in clause 6.12 KPN N.V. pCR Approval
4.1.14.4Miscellaneous
 		Yes
Yes
 		noted No    
S3‑180817 AUSF informing UDM that a successful or unsuccessful authentication of a subscriber has occurred Ericsson pCR Approval
4.1.8.15G AKA over 3gpp/non3gpp access
 		Yes
Yes
ORANGE: why "The feature to link authentication confirmation to subsequent procedures is optional to support within the home network"?
This was optional to use, not to support.
Nokia: we don’t need this, it is up to the operator.
It was agreed to remove it.
 
 		revised No S3‑180913  
S3‑180818 Clause 6.7.2 (NAS SMC, SUPI from UE for LI) Ericsson, Qualcomm Incorporated, Samsung, Huawei, Hisilicon, Intel pCR Approval
4.1.14.1SUPI and LI
 		Yes
Yes
ORANGE: If the AMF needs to validate the SUPI.. This has to be always done.
Ericsson: comditional because the AMF may know the UE already, so the SUPI verification was done.
Vodafone: serving networks giving auth vectors to third parties is an issue. There is no verification of these auth vectors were in the network were these vectors were created.
Verizon: serving network should only receive a hash,not the SUPI.We agreed this in the last meeting.
Interdigital: Reject should be done at earlier stages, before authentication.
 
 		noted No    
S3‑180819 Resolving Editor's Note on IMEI by changing to PEI KPN N.V. pCR Approval
4.1.17Others
 		Yes
Yes
 		revised No S3‑180993  
S3‑180820 Annex C (SUCI – scheme properties) Ericsson pCR Approval
4.1.14.2SUCI and Schemes
 		Yes
Yes
Huawei: why maximum size? This is implementation specific.
Ericsson: there should be a limit for the max size of the SUCI.
Nokia preferred to have one size for the SUCI instead of this maximum. A scheme identifier only would be preferable.
The maximum size was removed.
Interdigital warned that the scheme identifier may be used to track the SUCI.BT supported this and a note was added for this issue.
 
 
 
 
 
 
 		revised No S3‑180969  
S3‑180821 Clause 6.12.2 (SUCI – behaviours when USIM calculates SUCI) Ericsson, Gemalto, IDEMIA pCR Approval
4.1.14.2SUCI and Schemes
 		Yes
Yes
Huawei: the deletion of the parameters by the ME is implementation specific, no need to mandate this.
Gemalto: you could be changing the UICC from the ME and this could not detect the change. We have a contribution to avoid this happening.
Huawei: any update in the USIM would not be seen by the ME.
Huawei: this update is rare, so not relevant.
 
 
 
 		revised No S3‑180968  
S3‑180822 Clause 6.12.5 (SIDF – size of SUCI) Ericsson pCR Approval
4.1.14.3SIDF
 		Yes
Yes
ORANGE: this will not work, eventually it is implementation specific and we cannot impose requirements on propietary solutions.
Gemalto wasn't happy with the contribution. Nokia either.
 
 
 		noted No    
S3‑180823 Clause 6.12.5 (SIDF – validating calculation of the SUCI) Ericsson, Gemalto pCR Approval
4.1.14.3SIDF
 		Yes
Yes
Nokia: enough to verify the Home network identifier. Why the protection scheme?
ORANGE didn’t support this contribution either.
 
 		noted No    
S3‑180824 Clause 6.12.5 (NF discovery with SUCI) Ericsson pCR Approval
4.1.14.3SIDF
 		Yes
Yes
Ericsson: the motivation behind the contribution is that this is privacy sensitive info that is better not to standardise.
KPN and CATT preferred this solution.
Nokia supported this but wondered why the SUPI needed to be sent.
 
Ericsson pointed out that the difference between the Vodafone and Ericsson's proposal is "Do we standardise the location of the routing information that is sent OTA?".
 
Vodafone rephrased to "are you fine with the routing information being sent OTA?".
 
It was decided to note all documents and take this offline.A conference call was recommended to come back with a combined solution during the next meeting.
 
 
 
 		noted No    
S3‑180825 Removing of Editor’s Notes about SIDF, SUCI and SUPI in clause 3.3 KPN N.V. pCR Approval
4.1.17Others
 		Yes
Yes
 		noted No    
S3‑180826 Clause 6.12.4 (subscription identification procedure) Ericsson pCR Approval
4.1.14.4Miscellaneous
 		Yes
Yes
 		revised No S3‑180975  
S3‑180827 Clauses 6.12.1 and 6.12.2 (Moving SUCI related text from 6.12.1 to 6.12.2) Ericsson pCR Approval
4.1.14.5Editorials
 		Yes
Yes
 		merged No S3‑180978  
S3‑180828 Adding clauses for requirements and procedures for steering of UE in VPLMN Ericsson pCR Approval
4.9PLMN RAT selection
 		Yes
Yes
Vodafone preferred to see this in the next meeting. Docomo agreed, they suggested to work on the requirements instead of adding this into the TS.
 
 		revised No S3‑181003  
S3‑180829 Pre-fetching AVs in 5G-AKA Ericsson pCR Approval
4.1.8.15G AKA over 3gpp/non3gpp access
 		Yes
Yes
 		revised No S3‑180909  
S3‑180830 Definition on subscription credentials IDEMIA pCR Decision
4.1.8.15G AKA over 3gpp/non3gpp access
 		Yes
Yes
ORANGE: the definition is wrong, it is not a subscriber credential.
 
 		revised No S3‑180870  
S3‑180831 Further details on UE behaviour at 5G AKA procedure Ericsson pCR Approval
4.1.8.15G AKA over 3gpp/non3gpp access
 		Yes
Yes
Nokia had doubts on the USIM being able to compute the keys in step 8.
Vodafone clarified that this indeed happens, and also that the text was taken from LTE.
Qualcomm: there is normative text in the note "The ME shall perform additional verifications as described in step 8 in Figure 6.1.3.2-1 in clause 6.1.3.2.".
 
 		revised No S3‑180914  
S3‑180832 Definition on tamper resistant secure hardware component IDEMIA pCR Decision
4.1.8.15G AKA over 3gpp/non3gpp access
 		Yes
Yes
ORANGE: we prefer to have a requirement more than a definition.
Vodafone: ETSI SSP has created an STF to develop specs for the SSP for June.There may be technical issues that would not be accepted, this is the risk. Vodafone is the STF leader and will make sure that this is aligned with SA3 work.
KPN: the note doesn’t help, I prefer ORANGE's option.
Qualcomm didn’t agree with having this proposal.Don't restrict this to the UICC. Samsung and Huawei supported this.
BT: what happens if you have EAP TLS in primary authentication? ORANGE replied that EAP TLS is used in very specific scenarios and should go into an informative annex.We have to make sure that certificates are appropiately stored in the device.
ORANGE: Any secure element that claims to be tamper resistance we will have an inter-operatibility issue and  it will go into conflict with GSMA work in embedded UICCs.
Vodafone: we support that the USIM shall reside in the UICC. It is mandatory in the industry as ORANGE has pointed out.
Vodafone,ORANGE: a 5G spec not putting the USIM in the UICC would not be acceptable for us. BT agreed, but they liked the eUICC concept.
 
 
 
 
 
 		noted No    
S3‑180833 Reply-LS to S3-180564 on secure storage and processing of subscription credentials KPN N.V. LS out Approval
4.1.15Incoming and outgoing LSes
 		Yes
Yes
 		revised No S3‑180851  
S3‑180834 General guidelines for secure protocol design Deutsche Telekom AG pCR Approval
4.1.13.6Miscellaneous
 		Yes
Yes
ORANGE: these are not guidelines, they are requirements.
Ericsson: why have them in the TS when we can just send it to them in a LS? Or at least have it in an informative annex.
Nokia and ORANGE preferred to have this out of the TS. KPN agreed that telling other 3GPP groups what to do was not appropriate for the specification. NOTE from MCC: agree with this.
Docomo: LS send an LS. A 800 series TR could also serve as repository of this kind of text, or ask CT if they have a TR where they can store these guidelines.
 
 		noted No    
S3‑180835 Alignement related to private networks IDEMIA pCR Approval
4.1.8.4Authentication using EAP TLS
 		Yes
Yes
 		revised No S3‑180922  
S3‑180836 Requirements for secure API design for SBA Deutsche Telekom AG pCR Approval
4.1.13.1Interconnect (SEPP related)
 		Yes
Yes
 		noted No    
S3‑180837 SIDF description CATT pCR Approval
4.1.14.3SIDF
 		Yes
Yes
 		noted No    
S3‑180838 Introduction of the Subscription Concealed Identifier to EPC Apple (UK) Limited CR Discussion
4.1.14.4Miscellaneous
 		Yes
Yes
Mark: This doesn’t support LI requirements.
ORANGE: this has a big impact on the network, too many changes to be done.
 		not pursued No    
S3‑180839 Security for CU-CP and CU-UP split Huawei, Hisilicon discussion Endorsement
4.1.4.2Userplane security
 		Yes
Yes
 		noted No   S3‑180657
S3‑180840 Report from SA3#90 MCC report  
1.1Approval of last SA3 meeting report
 		Yes
Yes
Action item for Nokia remains open until next meeting.
 
 		approved No    
S3‑180841 Commenting contribution on S3-180836 - Requirements for secure API design for SBA Nokia discussion Approval
4.1.13.1Interconnect (SEPP related)
 		Yes
Yes
 		noted No    
S3‑180842 Commenting contribution on S3-180834 - General guidelines for secure protocol design Nokia discussion Discussion
4.1.13.6Miscellaneous
 		Yes
Yes
 		noted No    
S3‑180843 pCR to TR 33.834 - Updates to clauses 1 to 8 to prepare for approval Vodafone GmbH pCR Agreement
5.2Study on Long Term Key Update Procedures (FS_LTKUP) (Rel-15)
 		Yes
Yes
 		approved No   S3‑180686
S3‑180844 pCR to TR 33.834 - Update to solution 1 to correct references and update the evalustion Vodafone GmbH pCR Agreement
5.2Study on Long Term Key Update Procedures (FS_LTKUP) (Rel-15)
 		Yes
Yes
 		revised No S3‑181007 S3‑180688
S3‑180845 Integrity protection for SBA over N32 NTT DOCOMO INC. discussion Presentation
4.1.13.2Protection of Attributes
 		Yes
Yes
 		revised No S3‑180898  
S3‑180846 comments Requirements for secure API design for SBA (making text more normative) NTT DOCOMO pCR Approval
4.1.13.1Interconnect (SEPP related)
 		Yes
Yes
 		noted No    
S3‑180847 Agenda WG Chair agenda -
2Approval of Agenda and Meeting Objectives
 		Yes
Yes
 		revised No S3‑180996 S3‑180500
S3‑180848 Reply LS to R2-1801649 on RAN2 Assumption about DRB ID value range Nokia LS out Approval
4.1.4.3RRC security
 		Yes
Yes
 		approved No   S3‑180610
S3‑180849 Reply LS to R3-180630 on CU-CP/UP separation Nokia LS out Approval
4.1.4.2Userplane security
 		Yes
Yes
 		approved No   S3‑180608
S3‑180850 Discussion and pCR on R3-180630 LS on security for CU-CP/UP separation Nokia pCR Approval
4.1.4.2Userplane security
 		Yes
Yes
 		approved No   S3‑180607
S3‑180851 Reply-LS to S3-180564 on secure storage and processing of subscription credentials KPN N.V. LS out Approval
4.1.15Incoming and outgoing LSes
 		Yes
Yes
 		approved No   S3‑180833
S3‑180852 Modification on Xn handover procedure ZTE Corporation,Ericsson pCR Approval
4.1.3.6Miscellaneous
 		Yes
Yes
 		approved No   S3‑180550
S3‑180853 Reply LS on selectively disabling legacy radio technologies S1-180634 LS in discussion
4.1.15Incoming and outgoing LSes
 		Yes
Yes
 		noted No    
S3‑180854 LS on support of Voice Service Continuity from 5G System to UTRAN CS S1-180595 LS in discussion
4.1.15Incoming and outgoing LSes
 		Yes
Yes
It was noted that this was going for Rel-16.
 
 		noted No    
S3‑180855 Corrections and clarification for EDCE5 Qualcomm Incorporated CR Agreement
4.6EPC enhancements to support 5G New Radio via Dual Connectivity (EDCE5) (Rel-15)
 		Yes
Yes
 		agreed No   S3‑180780
S3‑180856 Draft TS 33.501 NTT-Docomo draft TS Approval
4.1.17Others
 		No
Yes
 		left for email approval No    
S3‑180857 Cover sheet TS 33.501 NTT-Docomo TS or TR cover Approval
4.1.17Others
 		No
Yes
It was clarified that PLMN RAT selection depended on CT1 progress on the matter.
 
 		approved No    
S3‑180858 Overview of 5G security architecture Huawei, Hisilicon, China Mobile, CATR, ZTE pCR Approval
4.1.1.1Miscellaneous
 		Yes
Yes
 		approved No   S3‑180509
S3‑180859 Key hierarchy Nokia,Lenovo pCR Decision
4.1.1.1Miscellaneous
 		Yes
Yes
 		approved No   S3‑180771
S3‑180860 Adding the identifier of KSEAF Qualcomm Incorporated pCR Approval
4.1.1.1Miscellaneous
 		Yes
Yes
 		approved No   S3‑180782
S3‑180861 deleting the duplicate ENs about ngKSI Huawei, Hisilicon pCR Approval
4.1.2.4Miscellaneous
 		Yes
Yes
 		revised No S3‑180912 S3‑180519
S3‑180862 Clean up of ENs in Clause 6.2.3 Handling of User related keys Nokia,CATT pCR Approval
4.1.5.9Miscellaneous
 		Yes
Yes
 		approved No   S3‑180613
S3‑180863 [eMCSEC] 33180 R14 GMK management Motorola Solutions Danmark A/S CR Agreement
4.3Mission Critical Security Enhancements (eMCSec) (Rel-15)
 		Yes
Yes
 		agreed No   S3‑180565
S3‑180864 [eMCSEC] 33180 R14 key storage and persistence Motorola Solutions Danmark A/S CR Agreement
4.3Mission Critical Security Enhancements (eMCSec) (Rel-15)
 		Yes
Yes
 		agreed No   S3‑180566
S3‑180865 [eMCSEC] 33180 R15 GMK management (mirror) Motorola Solutions Danmark A/S CR Agreement
4.3Mission Critical Security Enhancements (eMCSec) (Rel-15)
 		Yes
Yes
 		agreed No   S3‑180567
S3‑180866 [eMCSEC] 33180 R15 key storage and persistence (mirror) Motorola Solutions Danmark A/S CR Agreement
4.3Mission Critical Security Enhancements (eMCSec) (Rel-15)
 		Yes
Yes
 		agreed No   S3‑180568
S3‑180867 Resolving Editor’s Notes in clause 6.2.2 NEC pCR Approval
4.1.1.1Miscellaneous
 		Yes
Yes
 		approved No   S3‑180760
S3‑180868 Resolving Editor's Notes in clauses 6.2.1 and 6.2.2.1 KPN N.V. pCR Approval
4.1.1.1Miscellaneous
 		Yes
Yes
 		approved No   S3‑180573
S3‑180869 Resolving Editor’s Note in clause 3.1 and cleaning up some definitions KPN pCR Approval
4.1.1.2Editorials
 		Yes
Yes
 		approved No   S3‑180522
S3‑180870 Definition on subscription credentials IDEMIA pCR Decision
4.1.8.15G AKA over 3gpp/non3gpp access
 		Yes
Yes
 		approved No   S3‑180830
S3‑180871 deleting the duplicate ENs about the Kausf storage Huawei, Hisilicon pCR Approval
4.1.1.2Editorials
 		Yes
Yes
 		approved No   S3‑180518
S3‑180872 Correction to clause 6.1.4 Nokia pCR Decision
4.1.1.2Editorials
 		Yes
Yes
 		approved No   S3‑180772
S3‑180873 NIA0 support in the AMF Orange pCR Approval
4.1.5.1Requirements
 		Yes
Yes
 		approved No   S3‑180689
S3‑180874 Clause 6.8.2.1 (key handling – RRC INACTIVE/CONNECTED state transition) Ericsson pCR Approval
4.1.4.3RRC security
 		No
Yes
 		withdrawn Yes    
S3‑180875 Negotiation of NR & LTE algorithms with 5GC Ericsson pCR Approval
4.1.5.3NAS algorithm selection
 		Yes
Yes
Addressing comments from Qualcomm and Docomo.
 		approved No   S3‑180742
S3‑180876 Content to Clause 6.4.3 on NAS integrity mechanisms Ericsson,Huawei pCR Approval
4.1.5.4NAS integrity and confidentiality mechanisms
 		Yes
Yes
 		approved No   S3‑180740
S3‑180877 Adding context on NAS confidentiality mechanisms and deleting Editor’s Note in clause 6.4.4.1 Huawei, Hisilicon,Ericsson pCR Approval
4.1.5.4NAS integrity and confidentiality mechanisms
 		Yes
Yes
 		approved No   S3‑180624
S3‑180878 Resolving EN on security capability mismatch in 6.7.2 LG Electronics pCR Approval
4.1.5.5NAS Security Mode Command
 		Yes
Yes
 		approved No   S3‑180664
S3‑180879 Clean up the EN in 6.4.5 Huawei, Hisilicon pCR Approval
4.1.5.7Multi-NAS security
 		Yes
Yes
 		approved No   S3‑180630
S3‑180880 Enforce common NAS context for multiple registrations in same PLMN ZTE Corporation pCR Approval
4.1.5.7Multi-NAS security
 		Yes
Yes
 		approved No   S3‑180551
S3‑180881 The value Unique NAS connection identifier Huawei, Hisilicon pCR Approval
4.1.5.7Multi-NAS security
 		Yes
Yes
 		approved No   S3‑180646
S3‑180882 Address concurrency issue in multi NAS connection Huawei, Hisilicon pCR Approval
4.1.5.7Multi-NAS security
 		Yes
Yes
 		approved No   S3‑180653
S3‑180883 Adding a generic bid down solution to the 5G TS Qualcomm Incorporated pCR Approval
4.1.5.9Miscellaneous
 		Yes
Yes
 		approved No   S3‑180776
S3‑180884 Text for Clause 6.8.1.2.3 crypto separation for n3gpp Nokia pCR Approval
4.1.5.9Miscellaneous
 		Yes
Yes
 		approved No   S3‑180612
S3‑180885 OAuth based service authorization framework for SBA Nokia,Huawei,Ericsson pCR Approval
4.1.13.4NF-NRF Authentication & Authorization
 		Yes
Yes
 		approved No   S3‑180680
S3‑180886 OAuth based service authorization framework for SBA in roaming scenarios Nokia,Huawei,Ericsson pCR Approval
4.1.13.4NF-NRF Authentication & Authorization
 		Yes
Yes
 		approved No   S3‑180681
S3‑180887 Discussion paper on Service access authorization for 5G SBA Nokia discussion Endorsement
4.1.13.5NF-NF Authentication & Authorization
 		Yes
Yes
It will go into the living document in 528.
 
 
 		endorsed No   S3‑180682
S3‑180888 Living Document: Security of Service Based Architecture of 5G phase 1 China Mobile Com. Corporation other -
4.1.13.6Miscellaneous
 		Yes
Yes
 		approved No   S3‑180528
S3‑180889 Discussion on re-prioritizing SBA security work for Phase 1 Nokia discussion Decision
4.1.13.1Interconnect (SEPP related)
 		No
Yes
 
 
 		withdrawn Yes    
S3‑180890 TLS for SEPP-IPX communication Ericsson pCR Approval
4.1.13.1Interconnect (SEPP related)
 		Yes
Yes
MCC warned that NOTE 1 was wrong since it contained normative language. Besides, recommending to "use" a particular functionality is language reserved to regulators. The document was approved but MCC commented that they would discuss this internally and may come back with a comment in plenary prior to the approval of the specification.
 		approved No   S3‑180712
S3‑180891 Adding normative text on SEPP to the security architecture section Nokia pCR Approval
4.1.13.1Interconnect (SEPP related)
 		Yes
Yes
 		approved No   S3‑180675
S3‑180892 Introduction to Application layer security in SEPP Nokia pCR Approval
4.1.13.2Protection of Attributes
 		Yes
Yes
 		approved No   S3‑180676
S3‑180893 Stepwise way forward for SBA security: SEPP- SEPP security capability negotiation Ericsson pCR Approval
4.1.13.1Interconnect (SEPP related)
 		Yes
Yes
 		approved No   S3‑180710
S3‑180894 LS on guidelines for secure protocol design Deutsche Telekom LS out Approval
4.1.13.6Miscellaneous
 		Yes
Yes
 		approved No    
S3‑180895 Requirements for secure API design for SBA Deutsche Telekom AG pCR Approval
4.1.13.1Interconnect (SEPP related)
 		No
Yes
 		withdrawn Yes    
S3‑180896 Policies for IE protection at SEPP Ericsson pCR Approval
4.1.13.1Interconnect (SEPP related)
 		No
Yes
 		withdrawn Yes    
S3‑180897 Policies for IE protection at SEPP(content for living document) Ericsson other Approval
4.1.13.1Interconnect (SEPP related)
 		No
Yes
 		approved No    
S3‑180898 Integrity protection for SBA over N32 NTT DOCOMO INC. other Approval
4.1.13.2Protection of Attributes
 		No
Yes
This will go to the living document.
 		approved No   S3‑180845
S3‑180899 Resolving Editors notes - 9.1.3.2 Protection at the network or transport layer – TLS certificate profiles BT plc pCR Approval
4.1.13.3Transport security (intra and inter-PLMN)
 		Yes
Yes
 		approved No   S3‑180617
S3‑180900 9.1.3.4.2 clarification PCR InterDigital, Inc. pCR Approval
4.1.13.4NF-NRF Authentication & Authorization
 		Yes
Yes
 		approved No   S3‑180508
S3‑180901 pCR to resolving authentication Editor’s Notes in section 9.1.3.4 China Mobile Com. Corporation pCR -
4.1.13.4NF-NRF Authentication & Authorization
 		Yes
Yes
 		approved No   S3‑180530
S3‑180902 SBA: Removing section on Diameter and GTP Nokia pCR Approval
4.1.13.6Miscellaneous
 		Yes
Yes
 		approved No   S3‑180674
S3‑180903 LS Reply on SBI Design and its Security Implications C4-182244 LS in discussion
4.1.13.6Miscellaneous
 		Yes
Yes
 		postponed No    
S3‑180904 Requirements for the protection of attributes on N32 Deutsche Telekom AG pCR Approval
4.1.13.7Editorials
 		Yes
Yes
 		approved No   S3‑180721
S3‑180905 Updates to SMS over NAS security clause Ericsson,Nokia pCR Approval
4.1.5.8SMS over NAS
 		Yes
Yes
 		approved No   S3‑180743
S3‑180906 [eMCSEC] Clarification of purpose of Inter-domain user service authorisation NCSC CR Agreement
4.3Mission Critical Security Enhancements (eMCSec) (Rel-15)
 		Yes
Yes
 		agreed No   S3‑180803
S3‑180907 [MONASTERY_SEC] 33180 R15 functional alias(es) Motorola Solutions Danmark A/S CR Agreement
4.7Security Architecture for the Mobile Communication System for Railways (MONASTERY_SEC) (Rel-15)
 		Yes
Yes
 		agreed No   S3‑180569
S3‑180908 ID linkage verification in secondary authentication-v2 Huawei, Hisilicon pCR Approval
4.1.9.3Efficiency / security improvement
 		No
Yes
 		noted No   S3‑180516
S3‑180909 Pre-fetching AVs in 5G-AKA Ericsson,BT,Huawei,Lenovo,NTT-Docomo pCR Approval
4.1.8.15G AKA over 3gpp/non3gpp access
 		Yes
Yes
 		approved No   S3‑180829
S3‑180910 5G-ACA when confirmation of RES* is not correct Ericsson,Huawei pCR Approval
4.1.8.15G AKA over 3gpp/non3gpp access
 		Yes
Yes
 		approved No   S3‑180736
S3‑180911 pCR to 33.501 – Timing of SUPI Reveal Vodafone GmbH,Huawei pCR Approval
4.1.8.15G AKA over 3gpp/non3gpp access
 		Yes
Yes
 		approved No   S3‑180730
S3‑180912 deleting the duplicate ENs about ngKSI Huawei, Hisilicon pCR Approval
4.1.2.4Miscellaneous
 		Yes
Yes
 		revised No S3‑180982 S3‑180861
S3‑180913 AUSF informing UDM that a successful or unsuccessful authentication of a subscriber has occurred Ericsson pCR Approval
4.1.8.15G AKA over 3gpp/non3gpp access
 		Yes
Yes
 		approved No   S3‑180817
S3‑180914 Further details on UE behaviour at 5G AKA procedure Ericsson pCR Approval
4.1.8.15G AKA over 3gpp/non3gpp access
 		Yes
Yes
 		approved No   S3‑180831
S3‑180915 Annex F: the subscriber identity used with key derivation in EAP-AKA’ Ericsson pCR Approval
4.1.8.2EAP AKA’ over 3gpp/non3gpp access
 		No
Yes
 		withdrawn Yes    
S3‑180916 Authentication related services provided by AUSF Ericsson,CATT pCR Approval
4.1.8.7Editorial corrections
 		Yes
Yes
 		approved No   S3‑180809
S3‑180917 Authentication related services provided by UDM Ericsson pCR Approval
4.1.8.7Editorial corrections
 		Yes
Yes
 		approved No   S3‑180813
S3‑180918 LS on authentication related services provided by AUSF and UDM Ericsson LS out Approval
4.1.15Incoming and outgoing LSes
 		Yes
Yes
 		approved No   S3‑180814
S3‑180919 Resolving Editor’s notes related with key derivation for EAP-TLS Huawei, HiSilicon, Qualcomm Incorporated, Ericsson,CATT pCR Approval
4.1.8.4Authentication using EAP TLS
 		Yes
Yes
 		approved No   S3‑180512
S3‑180920 Clause 6.6.2 (userplane security policy) Ericsson,Huawei pCR Approval
4.1.4.2Userplane security
 		Yes
Yes
It was decided to send an LS to RAn2,RAN3 and SA2 to inform them about this document.
 
 
 		approved No   S3‑180748
S3‑180921 Resolving Editor’s notes on Privacy Issues for EAP-TLS Huawei, HiSilicon, Qualcomm Incorporated,Ericsson pCR Approval
4.1.8.4Authentication using EAP TLS
 		Yes
Yes
 		approved No   S3‑180515
S3‑180922 Alignement related to private networks IDEMIA pCR Approval
4.1.8.4Authentication using EAP TLS
 		Yes
Yes
 		approved No   S3‑180835
S3‑180923 General guidelines for secure protocol design (contribution to the living document) Deutsche Telekom other Approval
4.1.13.6Miscellaneous
 		Yes
Yes
 		approved No    
S3‑180924 Corrections on Initiation of authentication procedure Huawei, Hisilicon pCR Approval
4.1.8.7Editorial corrections
 		Yes
Yes
 		approved No   S3‑180621
S3‑180925 Resolving EN on Clarification of how AUSF determines a clear text SUPI NEC Europe Ltd,KPN pCR Approval
4.1.8.7Editorial corrections
 		Yes
Yes
 		approved No   S3‑180759
S3‑180926 [eMCSec] 33.180 R15 Interconnection and Interworking media and signaling NCSC,Motorola Solutions CR Agreement
4.3Mission Critical Security Enhancements (eMCSec) (Rel-15)
 		Yes
Yes
 		agreed No   S3‑180800
S3‑180927 [MONASTERY_SEC] 33180 R15 multi-talker Motorola Solutions Danmark A/S CR Agreement
4.7Security Architecture for the Mobile Communication System for Railways (MONASTERY_SEC) (Rel-15)
 		Yes
Yes
Changing the category given that it is adding new functionality.
Motorola commented that the MONASTERY WID was closed for Rel-15, but a new WID in Rel-16 was being prepared.
 
 		agreed No   S3‑180570
S3‑180928 Draft CR on NAPS-Sec Huawei,HiSilicon,NEC,Samsung draftCR Approval
4.4Northbound APIs Security for SCEF - SCS/AS Interworking (NAPS_Sec) (Rel-15)
 		Yes
Yes
 		approved No    
S3‑180929 Security requirements and procedures for T8 reference point Huawei CR Agreement
4.4Northbound APIs Security for SCEF - SCS/AS Interworking (NAPS_Sec) (Rel-15)
 		Yes
Yes
 		agreed No    
S3‑180930 Collection of clarifications and editorial changes to BEST TS 33.163 Deutsche Telekom AG CR Approval
4.2Battery Efficient Security for very low Throughput Machine Type Communication Devices (BEST_MTC_Sec) (Rel-15)
Yes
Yes
 		agreed No   S3‑180572
S3‑180931 Draft TR 33.834 Vodafone draft TR Approval
5.2Study on Long Term Key Update Procedures (FS_LTKUP) (Rel-15)
 		Yes
Yes
 		approved No    
S3‑180932 Solution for LTK generation InterDigital, Inc. pCR Approval
5.2Study on Long Term Key Update Procedures (FS_LTKUP) (Rel-15)
 		Yes
Yes
 		approved No   S3‑180507
S3‑180933 Solution#2 enhancement Gemalto N.V. pCR Approval
5.2Study on Long Term Key Update Procedures (FS_LTKUP) (Rel-15)
 		Yes
Yes
 		approved No   S3‑180575
S3‑180934 pCR to TR 33.834 - update of reference numbers and conclusion to solution 2 Vodafone GmbH pCR Approval
5.2Study on Long Term Key Update Procedures (FS_LTKUP) (Rel-15)
 		Yes
Yes
 		approved No   S3‑180690
S3‑180935 pCR to 33.834 - update of solution evaluation for Solution 3 Vodafone GmbH pCR Agreement
5.2Study on Long Term Key Update Procedures (FS_LTKUP) (Rel-15)
 		Yes
Yes
 		approved No   S3‑180694
S3‑180936 Draft TR 33.841 Vodafone draft TR Approval
5.3Study on Supporting 256-bit Algorithms for 5G (FS_256-Algorithms) (Rel-16)
 		Yes
Yes
 		approved No    
S3‑180937 Threats and potential countermeasures posed due to quantum computing NCSC pCR Approval
5.3Study on Supporting 256-bit Algorithms for 5G (FS_256-Algorithms) (Rel-16)
 		Yes
Yes
 		approved No   S3‑180588
S3‑180938 Assessment of quantum computing impact timelines NCSC,China Mobile pCR -
5.3Study on Supporting 256-bit Algorithms for 5G (FS_256-Algorithms) (Rel-16)
 		Yes
Yes
 		approved No   S3‑180589
S3‑180939 The clarification of the entropy CK and IK CATT pCR Approval
5.3Study on Supporting 256-bit Algorithms for 5G (FS_256-Algorithms) (Rel-16)
 		Yes
Yes
 		approved No   S3‑180605
S3‑180940 Clean up of ENs in Clause 7.2.1 Authentication for Untrusted non-3GPP Access Nokia, Motorola Mobility, Lenovo pCR Approval
4.1.11.1Miscellaneous
 		Yes
Yes
 		approved No   S3‑180611
S3‑180941 Resolving Editor’s Note on N3IWF authentication Lenovo, Motorola Mobility pCR Approval
4.1.11.1Miscellaneous
 		Yes
Yes
 		approved No   S3‑180669
S3‑180942 Update requirements of UP security Huawei, Hisilicon,ZTE,KPN,Qualcomm pCR Approval
4.1.4.1Userplane open issues
 		Yes
Yes
 		approved No   S3‑180661
S3‑180943 LS on support of user plane encrytption as part of user plane security policy Huawei LS out Approval
4.1.4.2Userplane security
 		Yes
Yes
 		approved No    
S3‑180944 Clause 6.6.2 (userplane security activation) Ericsson,Huawei,NEC pCR Approval
4.1.4.2Userplane security
 		Yes
Yes
 		approved No   S3‑180750
S3‑180945 Transfer Security policy in Xn HO Huawei, Hisilicon,Ericsson, Qualcomm Incorporated pCR Approval
4.1.4.2Userplane security
 		Yes
Yes
 		approved No   S3‑180643
S3‑180946 Transfer Security policy in N2 HO Huawei, Hisilicon,Ericsson, Qualcomm Incorporated, NEC pCR Approval
4.1.4.2Userplane security
 		Yes
Yes
 		approved No   S3‑180644
S3‑180947 RRC Security Mechanisms Huawei, Hisilicon,CATT pCR Approval
4.1.4.3RRC security
 		Yes
Yes
 		approved No   S3‑180641
S3‑180948 Editor Note in clause 6.7.4 about the use of AS SMC in DC Ericsson pCR Approval
4.1.4.3RRC security
 		Yes
Yes
 		approved No   S3‑180749
S3‑180949 Resolving Editors notes 5.2.9 – Detailed Security Requirements for F1 interface BT plc pCR Agreement
4.1.12.1Miscellaneous
 		Yes
Yes
The new text goes away and the editor's note is removed.
approved No   S3‑180615
S3‑180950 Resolving Editors notes 9.1.2.2 - DIAMETER or GTP - Network layer IPsec support mandatory or optional BT plc pCR Agreement
4.1.12.1Miscellaneous
 		Yes
Yes
 		approved No   S3‑180618
S3‑180951 Resolving Editor’s Note in clause 5.2.4 Huawei, Hisilicon pCR Approval
4.1.12.2Editorials
 		Yes
Yes
 		approved No   S3‑180620
S3‑180952 Preventing the use of NIA0 between the UE and sgNodeB Qualcomm CR Agreement
4.6EPC enhancements to support 5G New Radio via Dual Connectivity (EDCE5) (Rel-15)
 		Yes
Yes
 		agreed No    
S3‑180953 Resolving Editor’s Notes on horizontal K'AMF derivation during mobility Huawei; Hisilicon pCR Approval
4.1.3.1Key derivations during handovers
 		Yes
Yes
 		approved No   S3‑180578
S3‑180954 N2-handover with horizontal key derivation Ericsson pCR Approval
4.1.3.2Security in AMF change between AMF sets
 		Yes
Yes
 		approved No   S3‑180728
S3‑180955 N2 handover procedure ZTE Corporation,Ericsson pCR Approval
4.1.3.2Security in AMF change between AMF sets
 		Yes
Yes
 		approved No   S3‑180541
S3‑180956 Resolving Editors notes - 6.9.3 Key handling in mobility registration update - list of parameters to be stored in the UDSF as part of the 5G security context BT plc pCR Agreement
4.1.3.2Security in AMF change between AMF sets
 		Yes
Yes
 		approved No   S3‑180616
S3‑180957 pCR to resolve ENs and update the registration procedure for mobility from EPS to 5GS Qualcomm Incorporated,Ericsson,Huawei pCR Approval
4.1.10.1Idle mode 4G-5G
 		Yes
Yes
 		approved No   S3‑180784
S3‑180958 pCR for idle mode mobility from 5GS to EPS Ericsson,Huawei pCR Approval
4.1.10.2Idle mode 5G-4G
 		Yes
Yes
 		approved No   S3‑180703
S3‑180959 IW HO from 5G to 4G Ericsson,Huawei,HiSilicon,Qualcomm pCR Approval
4.1.10.3Handover 5GC-EPS
 		Yes
Yes
 		approved No   S3‑180708
S3‑180960 pCR to resolve ENs and update the handover procedure from EPS to 5GS over N26 Qualcomm Incorporated,Huawei,Ericsson pCR Approval
4.1.10.4Handover EPS-5GC
 		Yes
Yes
 		approved No   S3‑180786
S3‑180961 Resolution of editor’s notes in clause 8.6 NEC Europe Ltd,Qualcomm,Huawei pCR Approval
4.1.10.5Security context mapping
 		Yes
Yes
 		approved No   S3‑180762
S3‑180962 API-related requirements for the SEPP Deutsche Telekom other Approval
4.1.13.6Miscellaneous
 		Yes
Yes
 		approved No    
S3‑180963 Combined solution: Verification hash and SUPI key binding Nokia, Gemalto, IDEMIA, Interdigital, AT&T, Lenovo discussion discussion
4.1.14.1SUPI and LI
 		No
Yes
See discussion to the different solutions under S3-180769
 
Nokia stated:
It looks like the key binding only has the most support by companies after NAS SMC solution promoters moved to support the key binding solution as stand-alone final LI/Privacy solution. If this assumption is this still correct and NAS SMC solution is not on the table anymore, I think we do not need a voting.
 
Nokia requested to minute the following:
By choosing the key binding solution we are deciding against an agreement that SA3 made in the last meeting and therefore would still like to see, how many companies would support a combined solution, because merged solution (963) was having in the first round of show of hands the most supporters.
 
Another show of hands was done:
Key binding – 965: 23 companies; Merger – 963: 6 companies
 
With this result, Nokia asked to be minuted:
We are not insisting on the combined solution though the objections raised by several companies as minuted under the discussion in S3-180769 against key binding solution are still seen as valid and have not been answered.
 
No voting was needed. Group moved forward with S3-180965.
 		noted No    
S3‑180964 Annex C (SUCI – ECIES profiles) Ericsson, Vodafone,Qualcomm pCR Approval
4.1.14.2SUCI and Schemes
 		No
Yes
It was agreed to use the two curves A and C. Negotiation will be included.
 
 		approved No   S3‑180716
S3‑180965 PCR Proposal and Discussion for Privacy and LI solution KPN pCR Approval
4.1.14.1SUPI and LI
 		Yes
Yes
On the technical vote:
Nokia commented that key binding solution seemed to be the most supported solution, so they decided not to go for a vote.
Nokia: By choosing this solution and not going for a vote we are going against an agreement from the last meeting. They wanted to see how many companies wanted to support the combined solution.
 
Nokia requested to have minuted the following:
With this result, Nokia is not insisting on the combined solution though the objections raised by several companies as minuted under the discussion in S3-180769 against key binding solution are still seen as valid and have not been answered.
 
Nokia: Some companies support key binding alone, some supported combined solution, we want to see how many.
 
Tdoc 965 key binding solution show of hands; support:ing companies:
- Huawei, ORANGE,Docomo, T-Mobile,TIM,DT, NEC, Samsung, China Mobile, Qualcomm, Ericsson, CATT, LG, Intel, KPN, Home Office, NCSC, NTEC, NIST,BT, Airbus,Sprint, ZTE.
 
Tdoc 963 combined solution support:
- Nokia, Interdigital, Lenovo, IDEMIA, Gemalto, AT&T.
 
No voting was needed so the group moved forward with this document.
 
 
 
 
 
 
 
 		approved No    
S3‑180966 5G AKA with verification hash Nokia, Gemalto, IDEMIA pCR Decision
4.1.14.1SUPI and LI
 		No
Yes
 		withdrawn Yes    
S3‑180967 Resolving an EN on randomness of SUCI in Clause 6.12.2 NEC Europe Ltd pCR Approval
4.1.14.2SUCI and Schemes
 		Yes
Yes
 		approved No   S3‑180757
S3‑180968 Clause 6.12.2 (SUCI – behaviours when USIM calculates SUCI) Ericsson, Gemalto, IDEMIA,CATT pCR Approval
4.1.14.2SUCI and Schemes
 		Yes
Yes
 		revised No S3‑181011 S3‑180821
S3‑180969 Annex C (SUCI – scheme properties) Ericsson pCR Approval
4.1.14.2SUCI and Schemes
 		Yes
Yes
 		approved No   S3‑180820
S3‑180970 Privacy requirements updated for clarification CATT pCR Approval
4.1.14.2SUCI and Schemes
 		Yes
Yes
 		approved No   S3‑180592
S3‑180971 UE privacy protection scheme requirements CATT pCR Approval
4.1.14.2SUCI and Schemes
 		Yes
Yes
 		approved No   S3‑180593
S3‑180972 LS on UP security policy handling during handover Ericsson LS out Approval
4.1.4AS Security
 		Yes
Yes
 		approved No    
S3‑180973 Alignment between partial cyphering and hashing method for initial NAS security Qualcomm pCR Approval
4.1.5.2Protection of initial NAS message
No
Yes
 		approved No    
S3‑180974 Requirement on SIDF NEC, Nokia, CMCC pCR Approval
4.1.14.3SIDF
 		Yes
Yes
 		approved No   S3‑180755
S3‑180975 Clause 6.12.4 (subscription identification procedure) Ericsson,Huawei,KPN pCR Approval
4.1.14.4Miscellaneous
 		Yes
Yes
 		approved No   S3‑180826
S3‑180976 Editorial modification on AMF privacy requirement ZTE Corporation pCR Approval
4.1.14.5Editorials
 		Yes
Yes
It was noted that the requirement was changed in another approved contribution.
 
 		approved No   S3‑180544
S3‑180977 USIM terminology fix Orange pCR Approval
4.1.14.5Editorials
 		Yes
Yes
 		approved No   S3‑180695
S3‑180978 Revision of S3-180078 SUCI intro and handling - NEC-KPN-Nokia merger Nokia, KPN, NEC,Ericsson,Huawei,China Mobile pCR Decision
4.1.14.5Editorials
 		Yes
Yes
 		revised No S3‑181010 S3‑180764
S3‑180979 SA3 calendar WG Chair other Information
6Any Other Business
 		Yes
Yes
 		noted No    
S3‑180980 AS security establishment during transition from RM-DEREGISTERED to RM-REGISTERED Ericsson pCR Approval
4.1.6.6Miscellaneous
 		Yes
Yes
 		approved No   S3‑180739
S3‑180981 LS on initial NAS protection Qualcomm LS out Approval
4.1.5.2Protection of initial NAS message
Yes
Yes
 		approved No    
S3‑180982 deleting the duplicate ENs about ngKSI Huawei, Hisilicon pCR Approval
4.1.2.4Miscellaneous
 		Yes
Yes
 		approved No   S3‑180912
S3‑180983 LS on LI SUPI privacy BT LS out Approval
4.1.14.1SUPI and LI
 		Yes
Yes
 		approved No    
S3‑180984 Clarification on the scenario when UE has multiple registrations in different PLMNs CATT pCR Approval
4.1.6.1Multiple registrations
 		Yes
Yes
 		approved No   S3‑180597
S3‑180985 Clarifications on the scenario when UE has multiple registrations in same PLMNs CATT pCR Approval
4.1.6.1Multiple registrations
 		Yes
Yes
Ericsson noted that this part needed some cleaning up.
Nokia commented that this text would have to go somewhere else.
 
 		approved No   S3‑180598
S3‑180986 LS on security context setup Ericsson LS out Approval
4.1.4AS Security
 		Yes
Yes
 		approved No    
S3‑180987 Resolution for ENs related to Security Visibility Qualcomm Incorporated, Samsung,BT pCR Approval
4.1.7.1Miscellaneous
 		Yes
Yes
It was agreed that the content of this document needs to be revised and added to an informative annex.
 
 		approved No   S3‑180798
S3‑180988 33.501 Editorials Ericsson discussion Endorsement
4.1.17Others
 		No
Yes
 		endorsed No    
S3‑180989 Resolving ENs in 5.1.4 Qualcomm Incorporated pCR Approval
4.1.17Others
 		Yes
Yes
 		approved No   S3‑180797
S3‑180990 Security requirements for NEF Nokia pCR Approval
4.1.17Others
 		Yes
Yes
 		approved No   S3‑180670
S3‑180991 Security for NEF Nokia pCR Approval
4.1.17Others
 		Yes
Yes
 		approved No   S3‑180672
S3‑180992 Replacement of the 4G term Ericsson pCR Approval
4.1.17Others
 		Yes
Yes
 		approved No    
S3‑180993 Resolving Editor's Note on IMEI by changing to PEI KPN N.V. pCR Approval
4.1.17Others
 		Yes
Yes
 		approved No   S3‑180819
S3‑180994 Addressing EN in Key setting clause Huawei, Hisilicon pCR Approval
4.1.2.3Key derivation AS related
 		No
Yes
 		withdrawn Yes    
S3‑180995 Corrections on clause number of Annex A Huawei, Hisilicon pCR Approval
4.1.2.5Editorials
 		Yes
Yes
 		approved No   S3‑180626
S3‑180996 Agenda WG Chair agenda -
2Approval of Agenda and Meeting Objectives
 		Yes
Yes
Revised to move the PLMN RAT selection documents to another agenda item.
 
 		approved No   S3‑180847
S3‑180997 Editorial modification on keys in AMF ZTE Corporation pCR Approval
4.1.2.4Miscellaneous
 		Yes
Yes
 		approved No   S3‑180546
S3‑180998 LS on SoR mechanism NEC Corporation LS out Approval
4.9PLMN RAT selection
 		Yes
Yes
 		approved No   S3‑180754
S3‑180999 Living Document: Security of PLMN/RAT selection policies for roaming Orange other Endorsement
4.9PLMN RAT selection
 		Yes
Yes
 		endorsed No   S3‑180685
S3‑181000 Proposed solution and conclusion for PLMN/RAT seleection Qualcomm Incorporated other Approval
4.9PLMN RAT selection
 		Yes
Yes
Huawei: this solution will only work for 5G SIM.
 
 		approved No   S3‑180795
S3‑181001 Security mechanism for steering of roaming during authentication procedure SAMSUNG other -
4.9PLMN RAT selection
 		Yes
Yes
 		approved No   S3‑180807
S3‑181002 Adding conclusion to living document S3-180371 Huawei; Hisilicon other Approval
4.9PLMN RAT selection
 		Yes
Yes
 		approved No   S3‑180576
S3‑181003 Adding clauses for requirements and procedures for steering of UE in VPLMN Ericsson,Qualcomm other Approval
4.9PLMN RAT selection
 		Yes
Yes
Agreed to move it to the living document.
 		approved No   S3‑180828
S3‑181004 Work Plan input from the Rapporteurs MCC other Information
6Any Other Business
 		Yes
Yes
 		noted No   S3‑180501
S3‑181005 resolving editor’s notes on protection the initial NAS message China Mobile Com. Corporation pCR -
4.1.5.2Protection of initial NAS message
Yes
Yes
 		approved No   S3‑180534
S3‑181006 Clean up the EN in 6.7.2 Huawei, Hisilicon pCR Approval
4.1.5.5NAS Security Mode Command
 		Yes
Yes
 		approved No   S3‑180631
S3‑181007 pCR to TR 33.834 - Update to solution 1 to correct references and update the evalustion Vodafone GmbH pCR Agreement
5.2Study on Long Term Key Update Procedures (FS_LTKUP) (Rel-15)
 		Yes
Yes
 		approved No   S3‑180844
S3‑181008 USIM storage and usage for primary authentication Orange pCR Approval
4.1.8.15G AKA over 3gpp/non3gpp access
 		Yes
Yes
 		approved No   S3‑180691
S3‑181009 LS on secure storage and processing of subscription credentials ORANGE LS out Approval
4.1.8.15G AKA over 3gpp/non3gpp access
 		Yes
Yes
 		approved No    
S3‑181010 Revision of S3-180078 SUCI intro and handling - NEC-KPN-Nokia merger Nokia, KPN, NEC,Ericsson,Huawei,China Mobile pCR Decision
4.1.14.5Editorials
 		Yes
Yes
 		approved No   S3‑180978
S3‑181011 Clause 6.12.2 (SUCI – behaviours when USIM calculates SUCI) Ericsson, Gemalto, IDEMIA,CATT pCR Approval
4.1.14.2SUCI and Schemes
 		Yes
Yes
 		approved No   S3‑180968