[{"name":"S2-1811611","title":"LS from SA WG3: LS on security issues on Multi NAS scenarios","source":"SA WG3","contact":"Adrian Escott","contact-id":24089,"tdoctype":"LS in","for":"Information","abstract":"SA WG3 are currently working on the security of being registered on both 3GPP and non-3GPP access in the same PLMN. SA WG3 have found some possible scenarios of 3GPP mobility which can cause the UE and AMF to not share a common security context for the non-3GPP access. The possible problem scenarios identified by SA WG3 are: - UE is registered over non-3GPP access and it then registers over 3GPP access to a new AMF - UE is registered on both 3GPP and non-3GPP accesses and there is a handover or idle mobility on the 3GPP access to a new AMF - UE is registered on non-3GPP and EPC and there is a handover or idle mobility from EPC to 5GC to a new AMF. In the above scenarios, it is possible that the security context for the non-3GPP access become de-synchronised between the UE and AMF, e.g. the source AMF performing a KAMF key derivation as described in clause 6.9.3 of TS 33.501. The AMF would be aware of such a problem. For a UE that is connected mode on the non-3GPP access, a NAS SMC procedure over non-3GPP could align the security contexts. SA WG3 have identified the 5 possible solutions to this issue: 1. The AMF can change both the 3GPP and non-3GPP access security context at the same time in NAS SMC and NASC container signalling 2. The AMF can change the non-3GPP access security context to the same as the 3GPP security context using an indication in Registration Accept message on the 3GPP access. 3. The AMF can signal to the UE in the Registration Accept message on the 3GPP access that there is a security context issue on the non-3GPP access to get the UE to perform a registration over the non-3GPP access. As part of this registration process, the AMF can send a NAS SMC. 4. The UE performs a registration over the non-3GPP access when it is aware of the possible de-synchronization. As part of this registration process, the AMF can send a NAS SMC. 5. Do nothing and let the current signalling sort out the issue by failing the Service Request. SA WG3 asks CT WG1 group to provide feedback (if any) on the possible solutions to the security issues with multiple registrations in the same PLMN described in this LS.","secretary_remarks":"Postponed S2-1810043 from S2#129. Noted in parallel session","agenda_item_sort_order":21,"ainumber":"6.5.4","ainame":"Security related functions and flows","tdoc_agenda_sort_order":11700,"status":"noted","reservation_date":"2018-10-31 19:40:32","uploaded":"2018-11-21 06:04:14","revisionof":"S2-1810043","revisedto":"","release":"Rel-15","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"CT WG1","Cc":"SA WG2","lsoriginalls":"S3-182637","lsreply":"","link":"http:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_129BIS_West_Palm_Beach\/Docs\/S2-1811611.zip","group":"S2","meeting":"S2-129","year":2018,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-1811614","title":"LS from SA WG3: Reply LS on Routing ID","source":"SA WG3","contact":"Alex Leadbeater","contact-id":71428,"tdoctype":"LS in","for":"Action","abstract":"SA WG3 thanks TSG CT for their LS on Routing ID received in S3-182819. SA WG3 would like to provide the following feedback on security requirements for Routing ID. As currently written in 3GPP TS 33.501, SUCI calculation by the ME only occurs if the operators privacy public key, the algorithm to use indicator and the Routing ID are available in the USIM. When the Home network wants to change the Routing ID the USIM must be updated. SA WG3 see the need for the Routing ID management messages to be: - Mandatory - Integrity protected between the Home network and the UE - Mandatory - Replay protected between the Home Network and the UE - Optional - Confidentiality protection between the Home Network and the UE (Note: the Routing ID will be sent in the clear to the Serving Network at next registration anyway). As it is good practice to confirm the change of the Routing ID, any return confirmation message shall be protected to at least the same level of security as the request message and preferably contain some reference from the request message so that the request and confirmation message can be correlated. SA WG3 noted that if the Routing ID becomes corrupted or misaligned, the UE will never recover without some other mechanism either in the UE or the Home network to rectify this situation. SA WG3 requires that any chosen mechanism does not break the security of the USIM. SA WG3 see several potential mechanisms that could be used to update the Routing ID and have commented on them individually. Option 1: Switching between pre-stored values in the USIM In this option multiple Privacy information sets (Routing ID, Algorithm to use and Public key) are stored on the USIM. Specific bits in the AMF part of the AUTN are used to indicate which preprogrammed Privacy information set is to be used from the next time. These could either be in the standardised and\/or proprietary part of the AMF part of the AUTHENTICATE message. As the AMF is integrity and replay protected in the AUTHENTICATION procedures this meets the minimum requirements for the request message and the security is terminated in the USIM. For the confirmation message, and additional parameter encoded in the encrypted part of the SUCI could be used to return the confirmation to the Home Network. In this solution the provisioning of the Privacy Information sets is outside the scope of the specification but is likely to be set at personalisation of the USIM. This solution does not require any specific support from the serving network. This solution does not require any further standardisation but could be enhanced by adding a parameter to the SUCI encrypted part. This solution requires an AUTHENTICATION message to transport the update. Option 2: Management using the New SoR secure packet mechanism This solution re-uses the secure packet SoR mechanism as specified in 3GPP TS 23.122. The solution, as specified in 3GPP TS 23.122 and 3GPP TS 24.501, allows the Home Network to update data in the USIM. The SoR transparent container can contain secured packet as specified in 3GPP TS 31.115. If the SoR transparent container contains a secured packet then the ME shall upload the secured packet to the USIM. This secured packet could contain the relevent commands to update the Routing Information in the USIM and to initiate the REFRESH (File Change Details) to inform the ME that this file has changed. This secure packet should be configured as integrity and replay protected and optionally confidentiality protected. This transport mechanism does not have a means of returning a comfirmation message from the USIM, but from the ME, however a secured confirmation message could be sent from the USIM over another bearer if needed. This option requires an OTA capable USIM.This solution does not require any additional standardisation but does require the visited network to support the SoR mechanisms. Option 3: Management using SIM OTA (3GPP TS 31.125) This solution uses SIM OTA as specified in 3GPP","secretary_remarks":"Postponed S2-1810293 from S2#129. Response drafted in S2-1812466. Final response in S2-1813178","agenda_item_sort_order":21,"ainumber":"6.5.4","ainame":"Security related functions and flows","tdoc_agenda_sort_order":11750,"status":"replied to","reservation_date":"2018-10-31 19:40:32","uploaded":"2018-11-21 06:04:14","revisionof":"S2-1810293","revisedto":"","release":"Rel-15","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"CT WG1, SA WG2","Cc":"TSG CT, CT WG4, CT WG6","lsoriginalls":"S3-183074","lsreply":"S2-1813178","link":"http:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_129BIS_West_Palm_Beach\/Docs\/S2-1811614.zip","group":"S2","meeting":"S2-129","year":2018,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-1811651","title":"[DRAFT] LS Reply to LS on LS on maximum data rate per UE for integrity protection for DRBs for PDU session established in non-3GPP access and transferred to 3GPP access using service request procedure","source":"Qualcomm Europe Inc.(Italy)","contact":"Faccin Stefano","contact-id":60610,"tdoctype":"LS out","for":"Approval","abstract":"To: CT WG1","secretary_remarks":"Response to S2-1811661. Revised in parallel session to S2-1813057.","agenda_item_sort_order":21,"ainumber":"6.5.4","ainame":"Security related functions and flows","tdoc_agenda_sort_order":11860,"status":"revised","reservation_date":"2018-11-15 19:18:10","uploaded":"2018-11-20 13:48:59","revisionof":"","revisedto":"S2-1813057","release":"","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"CT WG1","Cc":"","lsoriginalls":"","lsreply":"","link":"http:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_129BIS_West_Palm_Beach\/Docs\/S2-1811651.zip","group":"S2","meeting":"S2-129","year":2018,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-1811652","title":"UE sending UE Integrity Protection Data Rate capability over any access","source":"Qualcomm Incorporated","contact":"Faccin Stefano","contact-id":60610,"tdoctype":"CR","for":"Approval","abstract":"Summary of change: It is proposed that, even though the UE Integrity Protection Data Rate capability in the 5GSM Capability IE applies only to a 3GPP access, the UE provides the capability in PDU Session Establishment request independently of the access over which the UE sends the request message.","secretary_remarks":"Revised in parallel session to S2-1813056.","agenda_item_sort_order":21,"ainumber":"6.5.4","ainame":"Security related functions and flows","tdoc_agenda_sort_order":11890,"status":"revised","reservation_date":"2018-11-15 19:30:50","uploaded":"2018-11-20 13:48:59","revisionof":"","revisedto":"S2-1813056","release":"Rel-15","crspec":23.501,"crspecversion":"15.3.0","workitem":[{"winame":"5GS_Ph1"}],"crnumber":695.0,"crrevision":"","crcategory":"F","tsg_crp":"","lsreplyto":"","lsto":"","Cc":"","lsoriginalls":"","lsreply":"","link":"http:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_129BIS_West_Palm_Beach\/Docs\/S2-1811652.zip","group":"S2","meeting":"S2-129","year":2018,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-1811653","title":"UE sending UE Integrity Protection Data Rate capability over any access","source":"Qualcomm Incorporated","contact":"Faccin Stefano","contact-id":60610,"tdoctype":"CR","for":"Approval","abstract":"Summary of change: It is proposed that the SMF decide whether to accept or reject the PDU Session request based on the UE Integrity Protection Maximum Data Rate only when the Access Type is 3GPP to ensure that the SMF does not reject a PDU Session Establishment Request over n3GPP from a UE providing the UE Integrity Protection Data Rate capability in the 5GSM Capability IE in the request sent over n3GPP access.","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":11910,"status":"noted","reservation_date":"2018-11-15 19:32:47","uploaded":"2018-11-20 13:48:59","revisionof":"","revisedto":"","release":"Rel-15","crspec":23.502,"crspecversion":"15.3.0","workitem":[{"winame":"5GS_Ph1"}],"crnumber":812.0,"crrevision":"","crcategory":"F","tsg_crp":"","lsreplyto":"","lsto":"","Cc":"","lsoriginalls":"","lsreply":"","link":"http:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_129BIS_West_Palm_Beach\/Docs\/S2-1811653.zip","group":"S2","meeting":"S2-129","year":2018,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-1811655","title":"Support for partial ciphering of initial NAS messages","source":"Qualcomm Incorporated, Ericsson","contact":"Faccin Stefano","contact-id":60610,"tdoctype":"CR","for":"Approval","abstract":"Summary of change: The paper introduces initial NAS security in the 5GS according to SA and SA WG3 decisions. The paper clarifies that if no NAS security context was present when the UE sends the Registration Request, then the UE shall include the full Registration Request message with clear text and non-clear text IEs (if any) in the SMC message.","secretary_remarks":"Revision of (agreed) S2-1811307 from S2-129. Revised in parallel session to S2-1813058.","agenda_item_sort_order":21,"ainumber":"6.5.4","ainame":"Security related functions and flows","tdoc_agenda_sort_order":11950,"status":"revised","reservation_date":"2018-11-15 19:45:14","uploaded":"2018-11-20 13:48:59","revisionof":"S2-1811307","revisedto":"S2-1813058","release":"Rel-15","crspec":23.502,"crspecversion":"15.3.0","workitem":[{"winame":"5GS_Ph1"}],"crnumber":731.0,"crrevision":2.0,"crcategory":"F","tsg_crp":"","lsreplyto":"","lsto":"","Cc":"","lsoriginalls":"","lsreply":"","link":"http:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_129BIS_West_Palm_Beach\/Docs\/S2-1811655.zip","group":"S2","meeting":"S2-129","year":2018,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-1811661","title":"LS from CT WG1: LS on maximum data rate per UE for integrity protection for DRBs for PDU session established in non-3GPP access and transferred to 3GPP access using service request procedure","source":"CT WG1","contact":"Maurice Pope","contact-id":648,"tdoctype":"LS in","for":"Action","abstract":"CT WG1 discussed the following use case: -- Step-1: A UE has registered in both 3GPP access and non-3GPP access to the same PLMN but does not have any PDU session established in either 3GPP access or in non-3GPP access. Step-2: The UE establishes a PDU session in non-3GPP access. According to the current procedures in TS 24.501, the UE does not indicate the maximum data rate per UE for integrity protection for DRBs as the integrity protection for DRBs is specified for 3GPP access only. In the network, the user plane security enforcement information happens to contain the UP integrity protection set to 'Required'. The PDU session is established nevertheless since the user plane security enforcement information applies in NG-RAN (i.e. 3GPP access) only. Step-3: the UE stops being reachable via non-3GPP access and network sends paging over 3GPP access, indicating to re-establish the user-plane resources of PDU session(s) associated with non-3GPP access over 3GPP access. Step-4: based on the paging received in step-3, the UE initiates the service request procedure via 3GPP access and indicates the PDU session established in step-2 in the Allowed PDU session status IE. The network is unable to transfer the PDU session from non-3GPP access to 3GPP access since the user plane security enforcement information for the PDU session contains the UP integrity protection set to 'Required' and the network is unaware of the maximum data rate per UE for user-plane integrity protection supported by the UE. -- CT WG1 was unable to decide how to enable successful transfer of the PDU session from non-3GPP access to 3GPP access in the use case above. Action: CT WG1 would like to ask SA WG2 to take the information above into account and provide stage-2 requirements enabling the use case above, if deemed needed.","secretary_remarks":"Response drafted in S2-1811651. Final response in S2-1813176","agenda_item_sort_order":21,"ainumber":"6.5.4","ainame":"Security related functions and flows","tdoc_agenda_sort_order":11850,"status":"replied to","reservation_date":"2018-11-16 07:43:03","uploaded":"2018-11-21 06:07:13","revisionof":"","revisedto":"","release":"Rel-15","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"SA WG2","Cc":"","lsoriginalls":"C1-186852","lsreply":"S2-1813176","link":"http:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_129BIS_West_Palm_Beach\/Docs\/S2-1811661.zip","group":"S2","meeting":"S2-129","year":2018,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-1811664","title":"LS from CT WG1: Reply LS on maximum output size of SUPI concealment schemes","source":"CT WG1","contact":"Maurice Pope","contact-id":648,"tdoctype":"LS in","for":"Information","abstract":"CT WG1 would like to thank SA WG3 for the LS S3-183142 on maximum output size of SUPI concealment schemes. Regarding the following question in the LS S3-183142: Q1: What are the limitations on the maximum size of scheme output that can be accommodated for NAS signalling? CT WG1 response: The NAS information element used for SUCI can carry 65k octets. However, there is a limitation in rel-15 on the UE to RAN interface in the lower layers of maximum 8188 octets for option 5 and 9k octets for option 2 (PDCP layer). To CT WG1s understanding, for rel-16 RAN WG2 are working on segmenting RRC messages across PDCP frames that may allow for larger NAS messages that can be sent across the UE to RAN interface.","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":11710,"status":"noted","reservation_date":"2018-11-16 07:43:03","uploaded":"2018-11-21 06:07:13","revisionof":"","revisedto":"","release":"Rel-15","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"SA WG3","Cc":"RAN WG2, SA WG2, CT WG4","lsoriginalls":"C1-186992","lsreply":"","link":"http:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_129BIS_West_Palm_Beach\/Docs\/S2-1811664.zip","group":"S2","meeting":"S2-129","year":2018,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-1811666","title":"LS from CT WG1: LS on initial NAS message protection","source":"CT WG1","contact":"Maurice Pope","contact-id":648,"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","agenda_item_sort_order":21,"ainumber":"6.5.4","ainame":"Security related functions and flows","tdoc_agenda_sort_order":11930,"status":"postponed","reservation_date":"2018-11-16 07:43:03","uploaded":"2018-11-21 06:07:13","revisionof":"","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_129BIS_West_Palm_Beach\/Docs\/S2-1811666.zip","group":"S2","meeting":"S2-129","year":2018,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-1811927","title":"Handling UE\/USIM with Misconfigured Routing Indicator","source":"Ericsson","contact":"Shabnam Sultana","contact-id":21207,"tdoctype":"discussion","for":"Agreement","abstract":"Analyses the scenario of Ues with wrong RID and proposes the principles for a possible mechanism to achieve that these UE\/USIMs get connected to the 5GC so they can be updated with a right Routing Indicator later on","secretary_remarks":"Not Handled","agenda_item_sort_order":21,"ainumber":"6.5.4","ainame":"Security related functions and flows","tdoc_agenda_sort_order":11790,"status":"not treated","reservation_date":"2018-11-19 12:17:34","uploaded":"2018-11-20 13:43:50","revisionof":"","revisedto":"","release":"Rel-15","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"","Cc":"","lsoriginalls":"","lsreply":"","link":"http:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_129BIS_West_Palm_Beach\/Docs\/S2-1811927.zip","group":"S2","meeting":"S2-129","year":2018,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-1812099","title":"Update of Default Configured NSSAI and other UE parameters via Control Plane Solution from UDM to AMF with Direct NAS Transport to UE","source":"Qualcomm Incorporated, Telecom Italia, T-Mobile, Verizon, Motorola Mobility, Lenovo, Ericsson","contact":"Faccin Stefano","contact-id":79506,"tdoctype":"CR","for":"Approval","abstract":"Summary of change: A new procedure, derived from the procedure defined for Steering of Roaming in TS 23.122, is added to enable a UDM-triggered update of the parameters in the UE via the AMF using DL NAS Tarnsport. Moreover, the Nudm_SDM_Notification service is extended to enable UDM triggering of updates towards UE(s) for both subscription parameters and other UE parameters generated and to be triggered by the UDM. References to SA WG3 procedures are also added based on approved CR in S3-183742.","secretary_remarks":"Revised in parallel session to S2-1813054.","agenda_item_sort_order":21,"ainumber":"6.5.4","ainame":"Security related functions and flows","tdoc_agenda_sort_order":11760,"status":"revised","reservation_date":"2018-11-20 03:36:01","uploaded":"2018-11-20 13:48:59","revisionof":"S2-1811541","revisedto":"S2-1813054","release":"Rel-15","crspec":23.502,"crspecversion":"15.3.0","workitem":[{"winame":"5GS_Ph1"}],"crnumber":730.0,"crrevision":4.0,"crcategory":"C","tsg_crp":"","lsreplyto":"","lsto":"","Cc":"","lsoriginalls":"","lsreply":"","link":"http:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_129BIS_West_Palm_Beach\/Docs\/S2-1812099.zip","group":"S2","meeting":"S2-129","year":2018,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-1812140","title":"Discussion on Routing ID update","source":"CATT","contact":"Tingfang Tang","contact-id":75747,"tdoctype":"discussion","for":"Discussion","abstract":"Discuss the routing updating for Routing ID update bases on the agreement reached in SA WG2#129 meeting and the solutions provided in CT WG1 #112 bis, and proposes the way forward based on some technical observations.","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":11780,"status":"noted","reservation_date":"2018-11-20 06:21:12","uploaded":"2018-11-20 08:21:24","revisionof":"","revisedto":"","release":"Rel-15","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"","Cc":"","lsoriginalls":"","lsreply":"","link":"http:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_129BIS_West_Palm_Beach\/Docs\/S2-1812140.zip","group":"S2","meeting":"S2-129","year":2018,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-1812342","title":"Clarification on user plane integrity protection considering UL\/DL independent capability","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":"Postponed in parallel session","agenda_item_sort_order":21,"ainumber":"6.5.4","ainame":"Security related functions and flows","tdoc_agenda_sort_order":11920,"status":"postponed","reservation_date":"2018-11-20 11:01:43","uploaded":"2018-11-20 11:39:20","revisionof":"","revisedto":"","release":"Rel-15","crspec":23.501,"crspecversion":"15.3.0","workitem":[{"winame":"5GS_Ph1"}],"crnumber":728.0,"crrevision":"","crcategory":"F","tsg_crp":"","lsreplyto":"","lsto":"","Cc":"","lsoriginalls":"","lsreply":"","link":"http:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_129BIS_West_Palm_Beach\/Docs\/S2-1812342.zip","group":"S2","meeting":"S2-129","year":2018,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-1812460","title":"LS from SA WG3: Reply-LS on maximum output size of SUPI concealment schemes","source":"SA WG3","contact":"Maurice Pope","contact-id":648,"tdoctype":"LS in","for":"Information","abstract":"SA WG3 thanks CT WG1 and CT WG4 for their reply-LSes C1-186992\/S3-183264 and C4-187633\/S3-183273 on maximum output size of SUPI concealment schemes. Taking the feedback from CT WG1 and CT WG4 into account, SA WG3 has agreed the attached CR S3-183692. It states that the maximum size of scheme-output for proprietary protection schemes shall be total of 3000 octets plus size of input. The maximum size of scheme-output was chosen to allow the introduction of quantum-resistant protection schemes.","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":11720,"status":"noted","reservation_date":"2018-11-21 11:02:24","uploaded":"2018-11-21 11:04:40","revisionof":"","revisedto":"","release":"Rel-15","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"CT WG1, CT WG4","Cc":"SA WG2, RAN WG2","lsoriginalls":"S3-183658","lsreply":"","link":"http:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_129BIS_West_Palm_Beach\/Docs\/S2-1812460.zip","group":"S2","meeting":"S2-129","year":2018,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-1812462","title":"LS from SA WG3: Reply LS on Clarifications on SUPI definition and NAI format","source":"SA WG3","contact":"Maurice Pope","contact-id":648,"tdoctype":"LS in","for":"Action","abstract":"SA WG3 thanks SA WG2 for 'Reply LS on Clarifications on SUPI definition and NAI'. SA WG3 agreed on a CR to TS 33.501 in S3-183790 (attached) clarifying that when the SUPI contains Network Specific Identifier, the SUCI shall be in NAI format. SA WG3 would like to note that the format of the SUCI is neither dependent on the authentication method (as the UE needs to send the SUCI in the Registration Request before home network selects the authentication method) nor the type of access network (e.g., non-3GPP access). This means that the UE identity that is provided by the 5G UE as part of EAP-AKA' (e.g. in response to the EAP-Request\/Identity or EAP-Request\/AKA-Identity message) is always a SUCI and is sent in the same format as that was sent in the Registration Request. SA WG3 is also attaching an agreed CR in S3-183237 that updated in change 1 the same clause 6.12.2 in TS 33.501. In addition, as per TS 33.501, the subscription credentials, which includes the SUPI, are stored in the USIM. Action: SA WG2 and CT WG4 are kindly requested to take the above information into account.","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":11740,"status":"noted","reservation_date":"2018-11-21 11:02:24","uploaded":"2018-11-21 11:04:40","revisionof":"","revisedto":"","release":"Rel-15","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"CT WG4, SA WG2","Cc":"CT WG1, CT WG6","lsoriginalls":"S3-183662","lsreply":"","link":"http:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_129BIS_West_Palm_Beach\/Docs\/S2-1812462.zip","group":"S2","meeting":"S2-129","year":2018,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-1812463","title":"LS from SA WG3: LS on initial NAS message protection","source":"SA WG3","contact":"Maurice Pope","contact-id":648,"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","agenda_item_sort_order":21,"ainumber":"6.5.4","ainame":"Security related functions and flows","tdoc_agenda_sort_order":11940,"status":"postponed","reservation_date":"2018-11-21 11:02:24","uploaded":"2018-11-21 11:04:40","revisionof":"","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_129BIS_West_Palm_Beach\/Docs\/S2-1812463.zip","group":"S2","meeting":"S2-129","year":2018,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-1812466","title":"[DRAFT] Reply LS on Routing ID","source":"Orange","contact":"Antoine Mouquet","contact-id":38438,"tdoctype":"LS out","for":"Approval","abstract":"To: SA WG3, CT WG1, CT WG4. CC: TSG CT, CT WG6","secretary_remarks":"Update of e-mail revision 6 of S2-1811550. LATE DOC: Rx 20\/11, 10:00. Response to S2-1811614. Revised in parallel session to S2-1813055.","agenda_item_sort_order":21,"ainumber":"6.5.4","ainame":"Security related functions and flows","tdoc_agenda_sort_order":11800,"status":"revised","reservation_date":"2018-11-21 13:53:19","uploaded":"2018-11-21 14:59:33","revisionof":"S2-1811550","revisedto":"S2-1813055","release":"Rel-15","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"SA WG3, CT WG1, CT WG4","Cc":"TSG CT, CT WG6","lsoriginalls":"","lsreply":"","link":"http:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_129BIS_West_Palm_Beach\/Docs\/S2-1812466.zip","group":"S2","meeting":"S2-129","year":2018,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-1812472","title":"LS from RAN WG3: LS on Security Result Exchange Between NG-RAN and SMF in DC","source":"RAN WG3","contact":"Maurice Pope","contact-id":648,"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","agenda_item_sort_order":21,"ainumber":"6.5.4","ainame":"Security related functions and flows","tdoc_agenda_sort_order":11830,"status":"postponed","reservation_date":"2018-11-21 14:45:10","uploaded":"2018-11-21 14:45:42","revisionof":"","revisedto":"","release":"Rel-15","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"SA WG2, SA WG3","Cc":"","lsoriginalls":"R3-187244","lsreply":"","link":"http:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_129BIS_West_Palm_Beach\/Docs\/S2-1812472.zip","group":"S2","meeting":"S2-129","year":2018,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-1812475","title":"LS from RAN WG3: Enforcement of maximum supported data rate for integrity protection","source":"RAN WG3","contact":"Maurice Pope","contact-id":648,"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","agenda_item_sort_order":21,"ainumber":"6.5.4","ainame":"Security related functions and flows","tdoc_agenda_sort_order":11840,"status":"postponed","reservation_date":"2018-11-21 14:45:10","uploaded":"2018-11-21 14:45:42","revisionof":"","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":"","link":"http:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_129BIS_West_Palm_Beach\/Docs\/S2-1812475.zip","group":"S2","meeting":"S2-129","year":2018,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-1812477","title":"LS from CT WG4: Reply LS on Maximum output size of SUPI concealment schemes","source":"CT WG4","contact":"Maurice Pope","contact-id":648,"tdoctype":"LS in","for":"Information","abstract":"CT WG4 thanks SA WG3 for their LS on Maximum output size of SUPI concealment schemes. CT WG4's view on the questions included in said LS are as follows: Q1: What are the limitations on the maximum size of scheme output that can be accommodated for NAS signalling and interfaces defined by CT WG4? Answer: In the interfaces defined by CT WG4, the Subscription Concealed Identifier (SUCI) is transported in different protocol components: - In HTTP payloads: They are encoded as JSON documents, and the definition of the Information Elements where SUCI may be included (JSON strings) do not specify any upper limit. Based on previous SA WG3 requests, CT WG4 have specified an upper bound on the size of the overall JSON body of HTTP requests and responses of 124,000 octets (see 3GPP TS 29.501, subclause 6.2). - In HTTP URIs: In some SBA interfaces defined by CT WG4, SUCI is used as part of the resource structure in HTTP requests, as a resource path segment. IETF RFC 3986, 'Uniform Resource Identifier (URI): Generic Syntax' does not define any upper limit in URI size. However, specific implementations of client and server HTTP software may impose their own limits (e.g. URI sizes above 2,048 octets, or URIs with path segments above 256 octets, have been found problematic with certain software implementations). In summary, even when there are no clear upper limits defined by the relevant standards used in the protocol definitions under CT WG4's remit, very large sizes of scheme output for SUCI may require specific software tuning and configuration and might result in inter-operability issues.","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":11730,"status":"noted","reservation_date":"2018-11-21 18:22:04","uploaded":"2018-11-21 18:22:19","revisionof":"","revisedto":"","release":"Rel-15","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"SA WG3","Cc":"CT WG1, RAN WG2, SA WG2","lsoriginalls":"C4-187633","lsreply":"","link":"http:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_129BIS_West_Palm_Beach\/Docs\/S2-1812477.zip","group":"S2","meeting":"S2-129","year":2018,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-1813054","title":"Update of Default Configured NSSAI and other UE parameters via Control Plane Solution from UDM to AMF with Direct NAS Transport to UE","source":"Qualcomm Incorporated, Telecom Italia, T-Mobile, Verizon, Motorola Mobility, Lenovo, Ericsson","contact":"Faccin Stefano","contact-id":79506,"tdoctype":"CR","for":"Approval","abstract":"Summary of change: A new procedure, derived from the procedure defined for Steering of Roaming in TS 23.122, is added to enable a UDM-triggered update of the parameters in the UE via the AMF using DL NAS Tarnsport. Moreover, the Nudm_SDM_Notification service is extended to enable UDM triggering of updates towards UE(s) for both subscription parameters and other UE parameters generated and to be triggered by the UDM. References to SA WG3 procedures are also added based on approved CR in S3-183742.","secretary_remarks":"Revision of S2-1812099. 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":11770,"status":"agreed","reservation_date":"2018-11-28 19:58:40","uploaded":"2018-12-03 14:24:37","revisionof":"S2-1812099","revisedto":"","release":"Rel-15","crspec":23.502,"crspecversion":"15.3.0","workitem":[{"winame":"5GS_Ph1"}],"crnumber":730.0,"crrevision":5.0,"crcategory":"C","tsg_crp":"SP-181091","lsreplyto":"","lsto":"","Cc":"","lsoriginalls":"","lsreply":"","link":"http:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_129BIS_West_Palm_Beach\/Docs\/S2-1813054.zip","group":"S2","meeting":"S2-129","year":2018,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-1813055","title":"[DRAFT] Reply LS on Routing ID","source":"SA WG2","contact":"Antoine Mouquet","contact-id":38438,"tdoctype":"LS out","for":"Approval","abstract":"To: SA WG3, CT WG1, CT WG6. CC: TSG CT, CT WG4. Attachments: S2-1812099","secretary_remarks":"Revision of S2-1812466. Revised in parallel session to S2-1813178.","agenda_item_sort_order":21,"ainumber":"6.5.4","ainame":"Security related functions and flows","tdoc_agenda_sort_order":11810,"status":"revised","reservation_date":"2018-11-28 19:58:41","uploaded":"2018-12-03 14:24:37","revisionof":"S2-1812466","revisedto":"S2-1813178","release":"Rel-15","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"SA WG3, CT WG1, CT WG4","Cc":"TSG CT, CT WG6","lsoriginalls":"","lsreply":"","link":"http:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_129BIS_West_Palm_Beach\/Docs\/S2-1813055.zip","group":"S2","meeting":"S2-129","year":2018,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-1813056","title":"UE sending UE Integrity Protection Data Rate capability over any access","source":"Qualcomm Incorporated","contact":"Faccin Stefano","contact-id":60610,"tdoctype":"CR","for":"Approval","abstract":"Summary of change: It is proposed that, even though the UE Integrity Protection Data Rate capability in the 5GSM Capability IE applies only to a 3GPP access, the UE provides the capability in PDU Session Establishment request independently of the access over which the UE sends the request message.","secretary_remarks":"Revision of S2-1811652. 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":11900,"status":"agreed","reservation_date":"2018-11-28 19:58:41","uploaded":"2018-12-03 14:24:38","revisionof":"S2-1811652","revisedto":"","release":"Rel-15","crspec":23.501,"crspecversion":"15.3.0","workitem":[{"winame":"5GS_Ph1"}],"crnumber":695.0,"crrevision":1.0,"crcategory":"F","tsg_crp":"SP-181091","lsreplyto":"","lsto":"","Cc":"","lsoriginalls":"","lsreply":"","link":"http:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_129BIS_West_Palm_Beach\/Docs\/S2-1813056.zip","group":"S2","meeting":"S2-129","year":2018,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-1813057","title":"[DRAFT] Reply LS on maximum data rate per UE for integrity protection for DRBs for PDU session established in non-3GPP access and transferred to 3GPP access using service request procedure","source":"SA WG2","contact":"Faccin Stefano","contact-id":60610,"tdoctype":"LS out","for":"Approval","abstract":"To: CT WG1","secretary_remarks":"Revision of S2-1811651. Revised in parallel session to S2-1813176.","agenda_item_sort_order":21,"ainumber":"6.5.4","ainame":"Security related functions and flows","tdoc_agenda_sort_order":11870,"status":"revised","reservation_date":"2018-11-28 19:58:42","uploaded":"2018-12-03 14:24:38","revisionof":"S2-1811651","revisedto":"S2-1813176","release":"","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"CT WG1","Cc":"","lsoriginalls":"","lsreply":"","link":"http:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_129BIS_West_Palm_Beach\/Docs\/S2-1813057.zip","group":"S2","meeting":"S2-129","year":2018,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-1813058","title":"Support for partial ciphering of initial NAS messages","source":"Qualcomm Incorporated, Ericsson","contact":"Faccin Stefano","contact-id":60610,"tdoctype":"CR","for":"Approval","abstract":"Summary of change: The paper introduces initial NAS security in the 5GS according to SA and SA WG3 decisions. The paper clarifies that if no NAS security context was present when the UE sends the Registration Request, then the UE shall include the full Registration Request message with clear text and non-clear text IEs (if any) in the SMC message.","secretary_remarks":"Revision of S2-1811655. 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":11960,"status":"agreed","reservation_date":"2018-11-28 19:58:42","uploaded":"2018-12-03 14:24:39","revisionof":"S2-1811655","revisedto":"","release":"Rel-15","crspec":23.502,"crspecversion":"15.3.0","workitem":[{"winame":"5GS_Ph1"}],"crnumber":731.0,"crrevision":3.0,"crcategory":"C","tsg_crp":"SP-181090","lsreplyto":"","lsto":"","Cc":"","lsoriginalls":"","lsreply":"","link":"http:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_129BIS_West_Palm_Beach\/Docs\/S2-1813058.zip","group":"S2","meeting":"S2-129","year":2018,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-1813176","title":"Reply LS on maximum data rate per UE for integrity protection for DRBs for PDU session established in non-3GPP access and transferred to 3GPP access using service request procedure","source":"SA WG2","contact":"Faccin Stefano","contact-id":60610,"tdoctype":"LS out","for":"Approval","abstract":"To: CT WG1","secretary_remarks":"Revision of S2-1813057. 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":11880,"status":"approved","reservation_date":"2018-11-30 17:06:26","uploaded":"2018-12-03 14:28:23","revisionof":"S2-1813057","revisedto":"","release":"","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"S2-1811661","lsto":"CT WG1","Cc":"","lsoriginalls":"","lsreply":"","link":"http:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_129BIS_West_Palm_Beach\/Docs\/S2-1813176.zip","group":"S2","meeting":"S2-129","year":2018,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-1813178","title":"Reply LS on Routing ID","source":"SA WG2","contact":"Antoine Mouquet","contact-id":38438,"tdoctype":"LS out","for":"Approval","abstract":"To: SA WG3, CT WG1, CT WG6. CC: TSG CT, CT WG4. Attachments: S2-1813054","secretary_remarks":"Revision of S2-1813055. 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":11820,"status":"approved","reservation_date":"2018-11-30 17:06:28","uploaded":"2018-12-03 14:28:24","revisionof":"S2-1813055","revisedto":"","release":"Rel-15","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"S2-1811614","lsto":"SA WG3, CT WG1, CT WG6","Cc":"TSG CT, CT WG4","lsoriginalls":"","lsreply":"","link":"http:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_129BIS_West_Palm_Beach\/Docs\/S2-1813178.zip","group":"S2","meeting":"S2-129","year":2018,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0}]