[{"name":"S2-1900005","title":"LS from RAN WG2: Reply LS on initial NAS security agreements","source":"RAN WG2","contact":"Masato Kitazoe","contact-id":29801,"tdoctype":"LS in","for":"Information","abstract":"RAN WG2 would like to thank SA WG3 on their LS on initial NAS security agreements. RAN WG2 noticed SA WG3 stated that 'SA WG3 interpret the guidance given by SA plenary means that RAN specifications shall only include S-NSSAI ciphered in RRC layer'. RAN WG2 would like to inform SA WG3 that in the current RRC specifications, the list of S-NSSAIs can only be sent in RRCConnectionSetupComplete (LTE\/5GC) and RRCSetupComplete (NR), i.e. 'Msg5' during RRC connection establishment procedure, without any encryption. It should be noted that the list of S-NSSAI is included in the above messages only if upper layer provides the information to RRC. RAN WG2 also would like to point out that release-15 specification is frozen and backwards incompatible change cannot be made any more.","secretary_remarks":"Postponed S2-1811619 from S2#129BIS. Noted in parallel session","agenda_item_sort_order":21,"ainumber":"6.5.4","ainame":"Security related functions and flows","tdoc_agenda_sort_order":12450,"status":"noted","reservation_date":"2018-12-19 08:47:10","uploaded":"2018-12-19 10:07:34","revisionof":"S2-1811619","revisedto":"","release":"Rel-15","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"SA WG3","Cc":"SA WG2, CT WG1, RAN WG3, TSG SA","lsoriginalls":"R2-1816022","lsreply":"","link":"http:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_130_Kochi\/Docs\/S2-1900005.zip","group":"S2","meeting":"S2-130","year":2019,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-1900007","title":"LS from CT WG1: LS on initial NAS message protection","source":"CT WG1","contact":"Mahmoud Watfa","contact-id":72074,"tdoctype":"LS in","for":"Action","abstract":"CT WG1 thanks SA WG3 for their LS on initial NAS message protection. CT WG1 would like to inform SA WG3\/SA WG2 about the progress made regarding the protection of initial NAS messages. 1. Agreements on initial NAS message protection Summary of the agreements: A. At initial registration with no 5G NAS security context, the UE sends a Registration Request with cleartext IEs only. The UE then sends the complete Registration Request message (with cleartext IEs and non-cleartext IEs) in a NAS container as part of the Security Mode Complete message. B. At registration with a 5G NAS security context, the UE sends a Registration Request with cleartext IEs and, if the UE needs to send non-cleartext IEs, a NAS container which contains a complete Registration Request message (with cleartext IEs and non-cleartext IEs). The UE ciphers the NAS container. C. If the Security Mode Command is received during a registration procedure, the UE always sends the complete Registration Request message in a NAS container as part of the Security Mode Complete i.e. the UE does not perform a check on the HASH that is received in the Security Mode Command. D. During a service request procedure, the UE sends a Service Request message with cleartext IEs and, if the UE needs to send non-cleartext IEs, a NAS container which contains a complete Service Request message (with cleartext IEs and non-cleartext IEs). The UE ciphers the NAS container. 2. On the cleartext IEs CT WG1 has agreed that all the mandatory IEs in the initial NAS messages (Registration Request, Service Request, and Deregistration Request) are cleartext IEs. For optional IEs, CT WG1 has not concluded on the complete list of cleartext IEs. The list will be updated after discussions are finalized in SA WG2. The agreements described above can be found in the attached documents. Action: CT WG1 kindly requests SA WG3\/SA WG2 to take the above into account and provide feedback if needed. Action: CT WG1 kindly requests SA WG2 to inform CT WG1 about the complete list of cleartext IEs when possible.","secretary_remarks":"Postponed S2-1811666 from S2#129BIS. Replied by S2-1811568? Noted in parallel session","agenda_item_sort_order":21,"ainumber":"6.5.4","ainame":"Security related functions and flows","tdoc_agenda_sort_order":12460,"status":"noted","reservation_date":"2018-12-19 08:47:10","uploaded":"2018-12-19 10:07:34","revisionof":"S2-1811666","revisedto":"","release":"Rel-15","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"SA WG3, SA WG2","Cc":"","lsoriginalls":"C1-186995","lsreply":"","link":"http:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_130_Kochi\/Docs\/S2-1900007.zip","group":"S2","meeting":"S2-130","year":2019,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-1900020","title":"LS from SA WG3: LS on initial NAS message protection","source":"SA WG3","contact":"Adrian Escott","contact-id":24089,"tdoctype":"LS in","for":"Information","abstract":"SA WG3 thank CT WG1 for the liaison statement (C1-186995\/S3-183268) on initial NAS security. SA WG3 observe that the CT WG1 agreed CR proposes some changes to the stage 2 description of initial NAS security in TS 33.501. These changes are as follows: - Updated the Cleartext IEs to include the Additional GUTI based on the SA WG2 and CT WG1 feedback - The complete initial NAS message is included in the NAS Security Mode Complete message when the UE needs to include IEs from the initial NAS message in the NAS Security Mode Complete message - UE automatically includes the complete initial NAS message in the NAS Security Mode Complete message in the case when the UE sends the initial NAS message without a security context - HASH check is no longer needed to decide what is sent in the NAS Security Mode Complete message as it is now always the complete NAS message that is included - The complete initial NAS message is included in the NAS container that ciphered and sent in the initial message along with the cleartext IEs when the UE has a 5G security context As the complete initial NAS message is now returned to the AMF in the NAS Security Mode Complete message, there is no need for the HASH check at all as HASH check was intended to provide an integrity check for the IEs in the initial NAS message. SA WG3 have removed the HASH calculation and introduced a generic flag explicitly requesting the complete initial NAS message rather than including the HASH in the NAS Security Mode Command message. It is left to CT WG1 whether to use the HASH IE or a different IE to trigger the inclusion of the complete initial NAS message in the NAS Security Mode Complete.","secretary_remarks":"Postponed S2-1812463 from S2#129BIS. Noted in parallel session","agenda_item_sort_order":21,"ainumber":"6.5.4","ainame":"Security related functions and flows","tdoc_agenda_sort_order":12470,"status":"noted","reservation_date":"2018-12-19 08:47:11","uploaded":"2018-12-19 10:07:34","revisionof":"S2-1812463","revisedto":"","release":"Rel-15","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"CT WG1","Cc":"SA WG2","lsoriginalls":"S3-183741","lsreply":"","link":"http:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_130_Kochi\/Docs\/S2-1900020.zip","group":"S2","meeting":"S2-130","year":2019,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-1900021","title":"LS from RAN WG3: LS on Security Result Exchange Between NG-RAN and SMF in DC","source":"RAN WG3","contact":"Li Yang","contact-id":43509,"tdoctype":"LS in","for":"Action","abstract":"During UE mobility, the target NG-RAN node needs to provide the new security result\/status to SMF, via 'Handover Request Acknowledge Transfer' and 'Path Switch Request Transfer' containers. Based on similar principle, RAN WG3 discussed the issue about Security Result exchange between NG-RAN node and SMF in DC scenarios as below: If the security policy for a PDU session includes 'IP (Integrity Protection) preferred', then it is possible for IP to be configured or not configured in dual connectivity, depending on the NG-RAN termination node. For example, when the PDU session changes its termination node, i.e. MN -> SN or SN -> MN, then the new terminating NG-RAN node will decide its new security status. Some companies think that the SMF always needs to know the latest security result\/status for any concerned PDU session with 'IP preferred' (including changes from DC operation) , and the usage of that is up to SMF implementation. If so, it would follow that the MN should report the updated Security Result to SMF, i.e. via PDU SESSION RESOURCE MODIFY INDICATION message in the use case described above. Action: RAN WG3 kindly asks SA WG2 to confirm above understanding and provide feedback on the need to keep SMF updated on the security status of PDU sessions with 'IP preferred'.","secretary_remarks":"Postponed S2-1812472 from S2#129BIS. Response drafted in S2-1900140. Final response in S2-1901386","agenda_item_sort_order":21,"ainumber":"6.5.4","ainame":"Security related functions and flows","tdoc_agenda_sort_order":12330,"status":"replied to","reservation_date":"2018-12-19 08:47:11","uploaded":"2018-12-19 10:07:34","revisionof":"S2-1812472","revisedto":"","release":"Rel-15","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"SA WG2, SA WG3","Cc":"","lsoriginalls":"R3-187244","lsreply":"S2-1901386","link":"http:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_130_Kochi\/Docs\/S2-1900021.zip","group":"S2","meeting":"S2-130","year":2019,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-1900022","title":"LS from RAN WG3: Enforcement of maximum supported data rate for integrity protection","source":"RAN WG3","contact":"Luis Lopes","contact-id":47178,"tdoctype":"LS in","for":"Action","abstract":"RAN WG3 has defined signalling support to enable the SMF to communicate the User Plane Security Enforcement information to the NG-RAN, including also the maximum supported data rate per UE for integrity protection, as part of PDU session related signalling. RAN WG3 understands that the NG-RAN may use this information when deciding whether to accept the establishment of resources for a PDU session, or QoS flow. RAN WG3 also understands that the NG-RAN enforces the maximum rate limit for the set of all radio bearers for which integrity protection is activated (post-admission). Further internal NG-RAN signalling has been defined for this purpose. RAN WG3 has discussed such enforcement and noted that uplink traffic policing becomes complex and\/or inefficient in certain cases e.g. when (for multiple PDU sessions), there is a mix of bearers with and without integrity protection activated. A possible solution for the above would be to leave such policing to the UE, while NG-RAN handles admission control and DL enforcement. Question: Could the limiting of the uplink data rate (according to the maximum integrity protected bit rate) be performed by the concerned UE itself (assuming the RAN already performs admission control)?. Action: RAN WG3 kindly asks SA WG2 and RAN WG2 to address the question raised above.","secretary_remarks":"Postponed S2-1812475 from S2#129BIS. Response drafted in S2-1900177. Final response in S2-1901249","agenda_item_sort_order":21,"ainumber":"6.5.4","ainame":"Security related functions and flows","tdoc_agenda_sort_order":0,"status":"replied to","reservation_date":"2018-12-19 08:47:11","uploaded":"2018-12-19 10:07:34","revisionof":"S2-1812475","revisedto":"","release":"Rel-15","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"SA WG2, RAN WG2","Cc":"SA WG3","lsoriginalls":"R3-187267","lsreply":"S2-1901249","link":"http:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_130_Kochi\/Docs\/S2-1900022.zip","group":"S2","meeting":"S2-130","year":2019,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-1900026","title":"LS from GSMA 5GJA: User Plane Security for 5GC Roaming","source":"GSMA 5GJA","contact":"Scott Bailey","contact-id":71585,"tdoctype":"LS in","for":"Action","abstract":"Description: 5GJA welcomes the Release 15 specifications for the SEPP in 3GPP to protect the HTTP-based signalling via the N32 reference point between VPMN and HPMN when both PMNs are using the service-based 5G Core Network. Based on discussion in 5GJA#5 on 7th November 2018, 5GJA also sees a need for security enforcement between UPFs in the VPMN and HPMN via the N9 reference point, to protect the PMN core network. This applies to the Roaming 5G System architecture - Home Routed scenario. The PMN needs to distinguish valid incoming traffic on N9 that belongs to a successfully initiated subscriber session through N32, from any other traffic, where the PMN would only accept the former. 5GJA expects that a solution is flexible enough to allow different levels of protection, ranging from no protection at all, to providing only integrity protection, and to providing integrity protection and confidentiality. Any solution proposed, must take into account impacts to processing capabilities and end-to-end delay. Without N9 security policy enforcement being implemented, the GTP-U tunnels will be exposed to the IPX data roaming transport solutions contravening GSMA guidelines, putting PMNs core at risk. Currently, GSMA PRD's IR.77, IR.88, FS.20 and IR.34 require 'application aware' security policy enforcement for International Roaming using IPX and for MVNO\/MVNE use cases that involve direct connection. Action: TSG SA and its associated working groups SA WG2 and SA WG3 are kindly requested to provide feedback on the requirements to deliver security enforcement on the N9 reference point, and also when such specifications providing a solution will be made available.","secretary_remarks":"Postponed","agenda_item_sort_order":21,"ainumber":"6.5.4","ainame":"Security related functions and flows","tdoc_agenda_sort_order":12320,"status":"postponed","reservation_date":"2018-12-19 11:46:38","uploaded":"2018-12-19 11:47:59","revisionof":"","revisedto":"S2-1901410","release":"","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"TSG SA, SA WG2, SA WG3","Cc":"","lsoriginalls":"5GJA05_118","lsreply":"","link":"http:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_130_Kochi\/Docs\/S2-1900026.zip","group":"S2","meeting":"S2-130","year":2019,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-1900030","title":"LS from CT WG1: LS on new 5G-GUTI allocation","source":"CT WG1","contact":"Lin Shu","contact-id":43310,"tdoctype":"LS in","for":"Information","abstract":"CT WG1 observed below SA WG3 description in TS 33.501 subclause 6.12.3 to mandate the AMF to allocate a new 5G-GUTI: 'Upon receiving Registration Request message of type 'initial registration' or 'mobility registration update' from a UE, the AMF shall send a new 5G-GUTI to the UE in Registration Accept message. Upon receiving network triggered Service Request message from the UE (i.e., Service Request message sent by the UE in response to a Paging message), the AMF shall use a UE Configuration Update procedure to send a new 5G-GUTI to the UE. This UE Configuration Update procedure shall be used before the current NAS signalling connection is released, i.e., it need not be a part of the Service Request procedure because doing so delays the Service Request procedure.' The above green text restricts the AMF to only include the new 5G-GUTI in the Registration Accept message. However, it is CT WG1's understanding that while it can be mandatory for the AMF to allocate a new 5G-GUTI during the registration procedure with Registration Request message of type 'initial registration' or 'mobility registration update', the AMF is also allowed to use another means to allocate and send a new 5G-GUTI to the UE. As an example, this can be done by initiating a UE Configuration Update procedure and include the new 5G-GUTI in the Configuration Update Command message before sending the Registration Accept message. Hence, CT WG1 kindly requests SA WG3 to update their specification to mandate the AMF sending a new 5G-GUTI to the UE during the registration procedure rather than in the Registration Accept message, upon receiving the Registration Request message of type 'initial registration' or 'mobility registration update' from a UE. Furthermore, the above yellow text only covers the network triggered service request procedure triggered by the paging for a UE in 5GMM-IDLE mode over 3GPP access while the network triggered service request procedure can be also triggered by notification procedure as below: (1) The UE is in 5GMM-CONNECTED mode over non-3GPP access and in 5GMM-IDLE mode over 3GPP access when the UE is not in MICO mode. (2) The AMF decides to send a NOTIFICATION message over non-3GPP access to the UE instead of paging the UE over 3GPP access. (3) The UE initiates a service request procedure over 3GPP access as response to the AMF. It is noteworthy that in step (2) the AMF can decide to page UE instead of sending a NOTIFICATION message over non-3GPP access even if the UE is in 5GMM CONNECTED mode over non-3GPP access. Question: CT WG1 would like to check with SA WG3 that during the network triggered service request procedure triggered by the notification procedure, is the AMF mandated to allocate a new 5G-GUTI to the UE as well?","secretary_remarks":"Noted in parallel session","agenda_item_sort_order":21,"ainumber":"6.5.4","ainame":"Security related functions and flows","tdoc_agenda_sort_order":12530,"status":"noted","reservation_date":"2018-12-19 11:46:38","uploaded":"2018-12-19 11:47:59","revisionof":"","revisedto":"","release":"Rel-15","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"SA WG3","Cc":"SA WG2","lsoriginalls":"C1-188921","lsreply":"","link":"http:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_130_Kochi\/Docs\/S2-1900030.zip","group":"S2","meeting":"S2-130","year":2019,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-1900031","title":"LS from CT WG1: LS on protection of initial NAS messages","source":"CT WG1","contact":"Mahmoud Watfa","contact-id":72074,"tdoctype":"LS in","for":"Information","abstract":"CT WG1 thanks TSG SA for their LS on the guidance on initial NAS message protection. CT WG1 would like to inform TSG SA about the following CT WG1 work progress on initial NAS message protection in Release 15: - the necessary changes ensuring that minimal information is sent in the clear at the NAS layer have been concluded in accordance with SA WG2 and SA WG3. The detailed CT WG1 agreements on initial NAS message protection can be found in the attached documents. CT WG1 will update its specification accordingly if further stage 2 requirements arise.","secretary_remarks":"Noted in parallel session","agenda_item_sort_order":21,"ainumber":"6.5.4","ainame":"Security related functions and flows","tdoc_agenda_sort_order":12480,"status":"noted","reservation_date":"2018-12-19 11:46:38","uploaded":"2018-12-19 11:47:59","revisionof":"","revisedto":"","release":"Rel-15","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"TSG SA","Cc":"TSG CT, SA WG3, SA WG2","lsoriginalls":"C1-188925","lsreply":"","link":"http:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_130_Kochi\/Docs\/S2-1900031.zip","group":"S2","meeting":"S2-130","year":2019,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-1900050","title":"LS from ETSI TC LI: Reporting All Cell IDs in 5G","source":"ETSI TC LI","contact":"Gerald McQuaid","contact-id":25351,"tdoctype":"LS in","for":"Action","abstract":"Lawful Interception standards have provided for the reporting of the location of a target of interception, if lawfully authorized, since 2G standards were developed. 3G systems and 4G systems continued to support this requirement and at a minimum were able to report the Cell Id of the respective 2G, or 3G, or 4G Cell to which the target (UE) was attached and utilizing for mobile services. With Dual\/Multi Connectivity the UE will be attached to two or more cells, but only the master cell ID is reported to the core network. This means that the secondary cell id(s) to which the UE is actually attached is not currently known to the core network. In case of multi-connectivity, the handover information (e.g., change of secondary cell ID) is also not transmitted to the core network. For LI purposes, the requirement is for the service provider to report the cell ID(s) to which the UE is actually attached, i.e., the secondary cell ID(s) as well as the master cell ID, for mobile services (e.g., internet access services, VoNR). This requirement is not currently fulfilled for Dual\/Multi Connectivity. ETSI TC LI is kindly requesting 3GPP to develop a mechanism to ensure that the all serving cells (including the secondary cell ID(s) and the master cell ID of the cell(s)) attached to by a UE are available to the core network.","secretary_remarks":"Postponed.","agenda_item_sort_order":21,"ainumber":"6.5.4","ainame":"Security related functions and flows","tdoc_agenda_sort_order":12540,"status":"postponed","reservation_date":"2018-12-20 10:54:29","uploaded":"2018-12-20 10:54:53","revisionof":"","revisedto":"S2-1901419","release":"","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"SA WG2, CT WG1, CT WG 3, RAN WG3, SA WG3-LI","Cc":"","lsoriginalls":"LI(18)R45019r1","lsreply":"","link":"http:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_130_Kochi\/Docs\/S2-1900050.zip","group":"S2","meeting":"S2-130","year":2019,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-1900139","title":"Clarification of user plane security enforcement between NG-RAN and SMF in Dual Connectivity scenario","source":"ZTE, Qualcom (?)","contact":"Tricci So","contact-id":44974,"tdoctype":"CR","for":"Approval","abstract":"Summary of change: In case of dual connectivity, when the PDU session termination node is going to be changed and the target termination node cannot fulfil the User Plane Security Enforcement requirement when the Integrity Protection is set to 'Required', the Master NG-RAN node releases the existing PDU session with the source termination node. If the Integrity Protection is set to 'Preferred', the target termination node notifies the SMF for the change security status. the SMF handling of the PDU session with respect to the security status is up to SMF implementation decision.","secretary_remarks":"Confirm sources!. Revised in parallel session to S2-1901146.","agenda_item_sort_order":21,"ainumber":"6.5.4","ainame":"Security related functions and flows","tdoc_agenda_sort_order":12340,"status":"revised","reservation_date":"2019-01-13 09:01:10","uploaded":"2019-01-15 08:21:34","revisionof":"","revisedto":"S2-1901146","release":"Rel-16","crspec":23.501,"crspecversion":"15.4.0","workitem":[{"winame":"5GS_Ph1"}],"crnumber":762.0,"crrevision":"","crcategory":"F","tsg_crp":"","lsreplyto":"","lsto":"","Cc":"","lsoriginalls":"","lsreply":"","link":"http:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_130_Kochi\/Docs\/S2-1900139.zip","group":"S2","meeting":"S2-130","year":2019,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-1900140","title":"[DRAFT] LS Response on Security Result Exchange Between NG-RAN and SMF in DC","source":"ZTE Wistron Telecom AB","contact":"Tricci So","contact-id":44974,"tdoctype":"LS out","for":"Approval","abstract":"LS Response on Security Result Exchange Between NG-RAN and SMF in DC","secretary_remarks":"Response to S2-1900021. Revised in parallel session to S2-1901147.","agenda_item_sort_order":21,"ainumber":"6.5.4","ainame":"Security related functions and flows","tdoc_agenda_sort_order":12370,"status":"revised","reservation_date":"2019-01-13 09:23:19","uploaded":"2019-01-15 08:21:34","revisionof":"","revisedto":"S2-1901147","release":"Rel-16","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"RAN WG3, SA WG3","Cc":"","lsoriginalls":"","lsreply":"","link":"http:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_130_Kochi\/Docs\/S2-1900140.zip","group":"S2","meeting":"S2-130","year":2019,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-1900177","title":"[DRAFT] LS Response on Enforcement of maximum supported data rate for integrity protection","source":"Qualcomm Tech. Netherlands B.V","contact":"Faccin Stefano","contact-id":79506,"tdoctype":"LS out","for":"Approval","abstract":"To: RAN WG3, RAN WG2. CC: SA WG3","secretary_remarks":"Response to S2-1900022. Revised in parallel session to S2-1901202.","agenda_item_sort_order":21,"ainumber":"6.5.4","ainame":"Security related functions and flows","tdoc_agenda_sort_order":12420,"status":"revised","reservation_date":"2019-01-14 00:14:32","uploaded":"2019-01-15 04:19:11","revisionof":"","revisedto":"S2-1901202","release":"","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"RAN WG3, RAN WG2","Cc":"SA WG3","lsoriginalls":"","lsreply":"","link":"http:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_130_Kochi\/Docs\/S2-1900177.zip","group":"S2","meeting":"S2-130","year":2019,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-1900212","title":"Clarification on user plane integrity protection for UE UL\/DL capabilities","source":"OPPO","contact":"Jianhua Liu","contact-id":72698,"tdoctype":"CR","for":"Approval","abstract":"Summary of change: This CR is to update the stage-2 related description to cover the independent UL and DL maximum supported data rate.","secretary_remarks":"Noted in parallel session","agenda_item_sort_order":21,"ainumber":"6.5.4","ainame":"Security related functions and flows","tdoc_agenda_sort_order":12550,"status":"noted","reservation_date":"2019-01-14 06:32:57","uploaded":"2019-01-15 11:33:23","revisionof":"","revisedto":"","release":"Rel-15","crspec":23.501,"crspecversion":"15.4.0","workitem":[{"winame":"5GS_Ph1"}],"crnumber":779.0,"crrevision":"","crcategory":"F","tsg_crp":"","lsreplyto":"","lsto":"","Cc":"","lsoriginalls":"","lsreply":"","link":"http:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_130_Kochi\/Docs\/S2-1900212.zip","group":"S2","meeting":"S2-130","year":2019,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-1900213","title":"Clarification on user plane integrity protection for UE UL\/DL capabilities","source":"OPPO","contact":"Jianhua Liu","contact-id":72698,"tdoctype":"CR","for":"Approval","abstract":"Summary of change: This CR is to update the stage-2 related description to cover the independent UL and DL maximum supported data rate.","secretary_remarks":"Noted in parallel session","agenda_item_sort_order":21,"ainumber":"6.5.4","ainame":"Security related functions and flows","tdoc_agenda_sort_order":12560,"status":"noted","reservation_date":"2019-01-14 06:37:37","uploaded":"2019-01-15 11:33:23","revisionof":"","revisedto":"","release":"Rel-15","crspec":23.501,"crspecversion":"15.4.0","workitem":[{"winame":"5GS_Ph1"}],"crnumber":780.0,"crrevision":"","crcategory":"F","tsg_crp":"","lsreplyto":"","lsto":"","Cc":"","lsoriginalls":"","lsreply":"","link":"http:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_130_Kochi\/Docs\/S2-1900213.zip","group":"S2","meeting":"S2-130","year":2019,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-1900333","title":"Correction to the initial NAS message protection","source":"NEC","contact":"Iskren Ianev","contact-id":59515,"tdoctype":"CR","for":"Approval","abstract":"Summary of change: Aligns initial Registration Request and initial Service Request messages with the CT WG1 spec updates in relation to the initial NAS message protection.","secretary_remarks":"Revised in parallel session to S2-1901203.","agenda_item_sort_order":21,"ainumber":"6.5.4","ainame":"Security related functions and flows","tdoc_agenda_sort_order":12490,"status":"revised","reservation_date":"2019-01-14 18:31:16","uploaded":"2019-01-15 11:51:03","revisionof":"","revisedto":"S2-1901203","release":"Rel-15","crspec":23.502,"crspecversion":"15.4.1","workitem":[{"winame":"5GS_Ph1"}],"crnumber":910.0,"crrevision":"","crcategory":"F","tsg_crp":"","lsreplyto":"","lsto":"","Cc":"","lsoriginalls":"","lsreply":"","link":"http:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_130_Kochi\/Docs\/S2-1900333.zip","group":"S2","meeting":"S2-130","year":2019,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-1900335","title":"Correction to the initial NAS message protection","source":"NEC","contact":"Iskren Ianev","contact-id":59515,"tdoctype":"CR","for":"Approval","abstract":"Rel-16 mirror CR: Summary of change: Aligns initial Registration Request and initial Service Request messages with the CT WG1 spec updates in relation to the initial NAS message protection.","secretary_remarks":"Not needed as will be implemented by Rel-15 CR in S2-1900333. Not Handled","agenda_item_sort_order":21,"ainumber":"6.5.4","ainame":"Security related functions and flows","tdoc_agenda_sort_order":12520,"status":"not treated","reservation_date":"2019-01-14 18:40:10","uploaded":"2019-01-15 11:51:49","revisionof":"","revisedto":"","release":"Rel-16","crspec":23.502,"crspecversion":"15.4.1","workitem":[{"winame":"5GS_Ph1"}],"crnumber":912.0,"crrevision":"","crcategory":"A","tsg_crp":"","lsreplyto":"","lsto":"","Cc":"","lsoriginalls":"","lsreply":"","link":"http:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_130_Kochi\/Docs\/S2-1900335.zip","group":"S2","meeting":"S2-130","year":2019,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-1901146","title":"Clarification of user plane security enforcement between NG-RAN and SMF in Dual Connectivity scenario","source":"ZTE, Qualcom Incorporated","contact":"Tricci So","contact-id":44974,"tdoctype":"CR","for":"Approval","abstract":"Summary of change: In case of dual connectivity, when the PDU session termination node is going to be changed and the target termination node cannot fulfil the User Plane Security Enforcement requirement when the Integrity Protection is set to 'Required', the Master NG-RAN node releases the existing PDU session with the source termination node. If the Integrity Protection is set to 'Preferred', the target termination node notifies the SMF for the change security status. the SMF handling of the PDU session with respect to the security status is up to SMF implementation decision.","secretary_remarks":"Revision of S2-1900139. Revised in parallel session to S2-1901247.","agenda_item_sort_order":21,"ainumber":"6.5.4","ainame":"Security related functions and flows","tdoc_agenda_sort_order":12350,"status":"revised","reservation_date":"2019-01-23 02:05:20","uploaded":"2019-01-28 09:47:55","revisionof":"S2-1900139","revisedto":"S2-1901247","release":"Rel-16","crspec":23.501,"crspecversion":"15.4.0","workitem":[{"winame":"5GS_Ph1"}],"crnumber":762.0,"crrevision":1.0,"crcategory":"F","tsg_crp":"","lsreplyto":"","lsto":"","Cc":"","lsoriginalls":"","lsreply":"","link":"http:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_130_Kochi\/Docs\/S2-1901146.zip","group":"S2","meeting":"S2-130","year":2019,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-1901147","title":"LS Response on Security Result Exchange Between NG-RAN and SMF in DC","source":"SA WG2","contact":"Tricci So","contact-id":44974,"tdoctype":"LS out","for":"Approval","abstract":"To: RAN WG3, SA WG3. Attachments: S2-1901146","secretary_remarks":"Revision of S2-1900140. Revised in parallel session to S2-1901248.","agenda_item_sort_order":21,"ainumber":"6.5.4","ainame":"Security related functions and flows","tdoc_agenda_sort_order":12380,"status":"revised","reservation_date":"2019-01-23 02:05:21","uploaded":"2019-01-28 09:47:55","revisionof":"S2-1900140","revisedto":"S2-1901248","release":"Rel-16","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"RAN WG3, SA WG3","Cc":"","lsoriginalls":"","lsreply":"","link":"http:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_130_Kochi\/Docs\/S2-1901147.zip","group":"S2","meeting":"S2-130","year":2019,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-1901202","title":"[DRAFT] LS Response on Enforcement of maximum supported data rate for integrity protection","source":"SA WG2","contact":"Faccin Stefano","contact-id":79506,"tdoctype":"LS out","for":"Approval","abstract":"To: RAN WG3, RAN WG2. CC: SA WG3","secretary_remarks":"Revision of S2-1900177. Revised in parallel session to S2-1901249.","agenda_item_sort_order":21,"ainumber":"6.5.4","ainame":"Security related functions and flows","tdoc_agenda_sort_order":12430,"status":"revised","reservation_date":"2019-01-23 04:23:55","uploaded":"2019-01-29 14:08:05","revisionof":"S2-1900177","revisedto":"S2-1901249","release":"","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"RAN WG3, RAN WG2","Cc":"SA WG3","lsoriginalls":"","lsreply":"","link":"http:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_130_Kochi\/Docs\/S2-1901202.zip","group":"S2","meeting":"S2-130","year":2019,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-1901203","title":"Correction to the initial NAS message protection","source":"NEC, Ericsson","contact":"Iskren Ianev","contact-id":59515,"tdoctype":"CR","for":"Approval","abstract":"Summary of change: Aligns initial Registration Request and initial Service Request messages with the CT WG1 spec updates in relation to the initial NAS message protection.","secretary_remarks":"Revision of S2-1900333. Revised in parallel session to S2-1901250.","agenda_item_sort_order":21,"ainumber":"6.5.4","ainame":"Security related functions and flows","tdoc_agenda_sort_order":12500,"status":"revised","reservation_date":"2019-01-23 04:23:55","uploaded":"2019-01-29 14:08:06","revisionof":"S2-1900333","revisedto":"S2-1901250","release":"Rel-15","crspec":23.502,"crspecversion":"15.4.1","workitem":[{"winame":"5GS_Ph1"}],"crnumber":910.0,"crrevision":1.0,"crcategory":"F","tsg_crp":"","lsreplyto":"","lsto":"","Cc":"","lsoriginalls":"","lsreply":"","link":"http:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_130_Kochi\/Docs\/S2-1901203.zip","group":"S2","meeting":"S2-130","year":2019,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-1901247","title":"Clarification of user plane security enforcement between NG-RAN and SMF in Dual Connectivity scenario","source":"ZTE, Qualcom Incorporated","contact":"Tricci So","contact-id":44974,"tdoctype":"CR","for":"Approval","abstract":"Summary of change: In case of dual connectivity, when the PDU session termination node is going to be changed and the target termination node cannot fulfil the User Plane Security Enforcement requirement when the Integrity Protection is set to 'Required', the Master NG-RAN node releases the existing PDU session with the source termination node. If the Integrity Protection is set to 'Preferred', the target termination node notifies the SMF for the change security status. the SMF handling of the PDU session with respect to the security status is up to SMF implementation decision.","secretary_remarks":"Revision of S2-1901146. This CR was agreed","agenda_item_sort_order":21,"ainumber":"6.5.4","ainame":"Security related functions and flows","tdoc_agenda_sort_order":12360,"status":"agreed","reservation_date":"2019-01-24 13:07:19","uploaded":"2019-01-29 14:08:23","revisionof":"S2-1901146","revisedto":"","release":"Rel-15","crspec":23.501,"crspecversion":"15.4.0","workitem":[{"winame":"5GS_Ph1"}],"crnumber":762.0,"crrevision":2.0,"crcategory":"F","tsg_crp":"SP-190154","lsreplyto":"","lsto":"","Cc":"","lsoriginalls":"","lsreply":"","link":"http:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_130_Kochi\/Docs\/S2-1901247.zip","group":"S2","meeting":"S2-130","year":2019,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-1901248","title":"LS Response on Security Result Exchange Between NG-RAN and SMF in DC","source":"SA WG2","contact":"Tricci So","contact-id":44974,"tdoctype":"LS out","for":"Approval","abstract":"To: RAN WG3, SA WG3. Attachments: S2-1901146","secretary_remarks":"Revision of S2-1901147. Revised to S2-1901386.","agenda_item_sort_order":21,"ainumber":"6.5.4","ainame":"Security related functions and flows","tdoc_agenda_sort_order":12390,"status":"revised","reservation_date":"2019-01-24 13:07:20","uploaded":"2019-01-29 14:08:23","revisionof":"S2-1901147","revisedto":"S2-1901386","release":"Rel-16","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"RAN WG3, SA WG3","Cc":"","lsoriginalls":"","lsreply":"","link":"http:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_130_Kochi\/Docs\/S2-1901248.zip","group":"S2","meeting":"S2-130","year":2019,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-1901249","title":"LS Response on Enforcement of maximum supported data rate for integrity protection","source":"SA WG2","contact":"Faccin Stefano","contact-id":79506,"tdoctype":"LS out","for":"Approval","abstract":"To: RAN WG3, RAN WG2. CC: SA WG3","secretary_remarks":"Revision of S2-1901202. Agreed in parallel session This was Block approved","agenda_item_sort_order":21,"ainumber":"6.5.4","ainame":"Security related functions and flows","tdoc_agenda_sort_order":12440,"status":"approved","reservation_date":"2019-01-24 13:07:21","uploaded":"2019-01-29 14:08:23","revisionof":"S2-1901202","revisedto":"","release":"","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"S2-1900022","lsto":"RAN WG3, RAN WG2","Cc":"SA WG3","lsoriginalls":"","lsreply":"","link":"http:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_130_Kochi\/Docs\/S2-1901249.zip","group":"S2","meeting":"S2-130","year":2019,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-1901250","title":"Correction to the initial NAS message protection","source":"NEC, Ericsson","contact":"Iskren Ianev","contact-id":59515,"tdoctype":"CR","for":"Approval","abstract":"Summary of change: Aligns initial Registration Request and initial Service Request messages with the CT WG1 spec updates in relation to the initial NAS message protection.","secretary_remarks":"Revision of S2-1901203. Agreed in parallel session. This was Block approved","agenda_item_sort_order":21,"ainumber":"6.5.4","ainame":"Security related functions and flows","tdoc_agenda_sort_order":12510,"status":"agreed","reservation_date":"2019-01-24 13:07:21","uploaded":"2019-01-29 14:08:23","revisionof":"S2-1901203","revisedto":"","release":"Rel-15","crspec":23.502,"crspecversion":"15.4.1","workitem":[{"winame":"5GS_Ph1"}],"crnumber":910.0,"crrevision":2.0,"crcategory":"F","tsg_crp":"SP-190157","lsreplyto":"","lsto":"","Cc":"","lsoriginalls":"","lsreply":"","link":"http:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_130_Kochi\/Docs\/S2-1901250.zip","group":"S2","meeting":"S2-130","year":2019,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-1901386","title":"LS Response on Security Result Exchange Between NG-RAN and SMF in DC","source":"SA WG2","contact":"Tricci So","contact-id":44974,"tdoctype":"LS out","for":"Approval","abstract":"To: RAN WG3, SA WG3. Attachments: S2-1901247","secretary_remarks":"Revision of S2-1901248. Approved","agenda_item_sort_order":21,"ainumber":"6.5.4","ainame":"Security related functions and flows","tdoc_agenda_sort_order":12400,"status":"approved","reservation_date":"2019-01-25 12:26:15","uploaded":"2019-01-29 14:18:10","revisionof":"S2-1901248","revisedto":"","release":"Rel-16","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"S2-1900021","lsto":"RAN WG3, SA WG3","Cc":"","lsoriginalls":"","lsreply":"","link":"http:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_130_Kochi\/Docs\/S2-1901386.zip","group":"S2","meeting":"S2-130","year":2019,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0}]