(12) INTERNATIONAL APPLICATION PUBLISHED UNDER THE PATENT COOPERATION TREATY (PCT)
`~.
`
`(19) World Intellectual Property
`Organization
`International Bureau
`
`(43) International Publication Date
`10 September 2020 (10.09.2020)
`
`~y
`
`7
`
`WIPO! PCT
`
`NUMA WAYA OA OUAW
`(10) International Publication Number
`WO2020/179665 Al
`
`(51) International Patent Classification:
`HOAL 9/08 (2006.01)
`
`(21) International Application Number:
`
`PCT/JP2020/0083 14
`
`(22) International Filing Date:
`
`(25) Filing Language:
`
`(26) Publication Language:
`
`28 Febmary 2020 (28.02.2020)
`
`English
`
`English
`
`(30) Priority Data:
`201911008144
`
`1 March 2019 (01.03.2019)
`
`IN
`
`(71) Applicant: NEC CORPORATION[JP/JP]; 7-1, Shiba 5-
`chome, Minato-ku, Tokyo, 1088001 (JP).
`
`IP Law Firm, Asahi
`(74) Agent: TEIRI Takeshi, HIBIKI
`Bldg.5th Floor, 3-33-8, Tsuruya-cho, Kanagawa-ku, Yoko-
`hama-shi, Kanagawa, 2210835 (JP).
`
`(81) Designated States (unless otherwise indicated, for every
`kind ofnational protection available): AE, AG, AL, AM,
`AO, AT, AU, AZ, BA, BB, BG, BH, BN, BR, BW, BY, BZ,
`CA, CH, CL, CN, CO, CR, CU, CZ, DE, DJ, DK, DM, DO,
`DZ, EC, EE, EG, ES, FI, GB, GD, GE, GH, GM, GT, HN,
`HR, HU, ID, IL, IN,IR, IS, JO, JP, KE, KG, KH, KN, KP,
`KR, KW, KZ, LA,LC,LK,LR,LS, LU, LY, MA, MD, ME,
`MG, MK, MN, MW, MX, MY, MZ, NA, NG, NI, NO, NZ,
`OM, PA, PE, PG, PH, PL, PT, QA, RO, RS, RU, RW, SA,
`SC, SD, SE, SG, SK, SL, ST, SV, SY, TH, TJ, TM, TN, TR,
`TT, TZ, UA, UG, US, UZ, VC, VN, WS, ZA, ZM, ZW.
`
`(72)
`
`Inventors: DE KIEVIT Sander; c/o NEC Corporation,
`7-1, Shiba 5-chome, Minato-ku, Tokyo, 1088001 (JP).
`TIWARI Kundan; c/o NEC Technologies India Pvt. Ltd.,
`SP Infocity, Block-A, 9th Floor, Module-2A, 40, MGR
`Salai, Kandanchavadi, Perungudi, Chennai, Tamil Nadu,
`600096 (IN).
`
`(84) Designated States (unless otherwise indicated, for every
`kind of regional protection available): ARIPO (BW, GH,
`GM, KE, LR, LS, MW, MZ, NA, RW, SD, SL, ST, SZ, TZ,
`UG, ZM, ZW), Eurasian (AM, AZ, BY, KG, KZ, RU, TJ,
`TM), European (AL, AT, BE, BG, CH, CY, CZ, DE, DK,
`EE,ES, FI, FR, GB, GR, HR, HU, IE,IS, IT, LT, LU, LV,
`MC, MK, MT, NL, NO, PL, PT, RO, RS, SE, SI, SK, SM,
`
` wo2020/179665A1ITTTANIIIMAC0M0UHEMTATTA
`
`
`
`(54) Title: METHOD FOR SYNCHRONIZATION OF HOME NETWORK KEY
`
`
`
`
`
`
`
`Fig.
`
`10
`
`(57) Abstract: The present disclosure provides a terminal including a memory; and a processor, comprising hardware, configured to
`performa primary authentication between the terminal and a network in 5G for a third party service, derive a security key, Kausr. and
`derive an identifier for the security key from the secuntykey.
`
`[Continuedon next page]
`
`1
`
`APPLE 1008
`
`APPLE 1008
`
`1
`
`

`

`WO 2020/179665 A.J [IMDMNMEAMTAAMINAMUA
`
`TR), OAPI (BF, BJ, CF, CG, Cl, CM, GA, GN, GQ, GW,
`KM, ML, MR, NE, SN, TD, TG).
`
`Published:
`— with international search report (Art. 2](3))
`
`2
`
`

`

`WO 2020/179665
`
`PCT/JP2020/008314
`
`Description
`Title of Invention: METHOD FOR SYNCHRONIZATION OF
`
`HOME NETWORK KEY
`
`Technical Field
`
`[0001]
`
`The present disclosure relates to a method for a mobile terminal and a home
`networkto identify a key and to keep the key synchronized between the home network
`and the mobile terminal, wherein the key is derived for each authentication session
`between the terminal and the homenetwork.
`
`[0002]
`
`Background Art
`In order to authenticate a user equipment (UE) and networkin 5G andto start
`using agreed keys, two separate proceduresare necessary. Thefirst procedureis the
`authentication and key agreement. During this procedure, the UE and network au-
`thenticate each other mutually and can derive someofthe keys higherup in the key
`hierarchy, such as CK and IK, CK' and IK’, Kaus, Ksear, and Kame. The completion of
`such a procedure leads to a non-current(partial) security context in both the UE and
`the network.
`
`[0003]
`
`The second procedure is the NAS SMC (Non Access Stratum Secure Mode
`Command) procedure during which the network informs the UEthat it would like to
`take the keys resulting from the latest authentication into use. As a result of this
`procedure, the non-current security context becomesthe current security context and
`the old security context is removed from memory.
`
`Citation List
`
`Non Patent Literature
`
`[0004]
`
`NPL 1: 3GPP (3rd Generation Partnership Project) TS33.501 V15.3.1
`Summary of Invention
`
`Technical Problem
`
`[0005]
`
`In NPLI, however, the keys that can be part of a (non-current) security context are
`the keys Kame and lowerin the key hierarchy. As such, the Ks; and the Kausare
`never part of a security context. The status of Kgeq- and Kase is therefore undefined,
`meaning that it is unclear whether they have been taken into use or not. Furthermore,
`the network elements handling the Ksgas and the Kaysp (the SEAF and AUSFre-
`spectively) are not informed of a successful NAS SMCprocedure and therefore do not
`know whetherthe key is active or not. On the contrary, the UE takes part in the NAS
`SMCprocedure and therefore knows whenthe non-current security context becomes
`the current security context. As a further complication, the Authentication Server
`
`3
`
`

`

`WO 2020/179665
`
`PCT/JP2020/008314
`
`[0006]
`
`[0007]
`
`[0008]
`
`[0009]
`
`Function (AUSF)resides in the home network whereas the Access and Mobility
`Management Function (AMF)or the Security Anchor Function (SEAF)resides in the
`serving network so that even if the serving network knows whena security contextis
`madethe current one, the AUSF has no meansto be informed.
`
`Thesituation is displayed in Fig. 1. Fig. | illustrates an issue that exists with only
`one AKAand one NAS SMC,accordingto a reference disclosed in NPLI. Initially,
`the UE, AMF, SEAF and AUSFhavenokeysrelating to the UE. After authentication
`and key agreement has been completed, the UE, AMF, SEAF and AUSFall have keys
`resulting from the last Authentication and Key Agreement (AKA). Atthis point in
`time, however, none of these keys is used actively by the network or the UE, whichis
`indicated with the primes. If subsequently, the AMF runs the NAS SMC,the UE and
`the AMF take the keys into use. However, for the SEAF and AUSF,the primes on the
`keys remain because they are uninformed of whether the keys are taken into use.
`In addition to this problem, the following problemsalso can occur:
`- When using 5G AKA,the AUSF will store the Kays¢ already before the authen-
`tication and key agreementhas been successfully completed. As such, any serving
`network that has access to the subscription unique permanentidentifier (SUPDofthe
`UE caneffectively overwrite the key in the AUSF by simply triggering an authen-
`tication.
`
`- When using Extensible Authentication Protocol (EAP) AKA’, the UE will create a
`temporary security context consisting of Kausr, Ksear, and Kaye, and removeit if no
`EAP Success message is received. A serving network can overwrite the Kays; in the
`AUSFbyalmost completing the authentication, but never sending the EAP Success
`message to the UE.
`This poses a further set of problems:
`- For the AUSF and SEAF: if one of the Ksear or Kause is used in subsequent
`procedures, the SEAF and AUSFcannotbe certain that the UE has taken the same key
`
`into use.
`
`- For the UE: if one of the proceduresuse Ksgar Or Kauss and the UE has more than
`one security context, the UE does not know which key has been used.
`- The serving network can overwrite the Kaus in the AUSF whicheffectively renders
`any service relying on the presenceofthis key void.
`In Fig. 2, the key hierarchy as defined in NPL1 is displayed. Fig. 2 illustrates a key
`hierarchy as defined in NPL1. As a result of an authentication and key agreement, this
`key hierarchy is established in the UE and the different network elements indicated in
`the figure. In 5G, there are two authentication protocols, namely 5G AKA and EAP
`AKA’, which is indicated with dashed boxes.
`
`[0010]
`
`From these keys, the following keys and parameters are part of the following
`
`4
`
`

`

`WO 2020/179665
`
`PCT/JP2020/008314
`
`security contexts:
`- 5G Security context: 5G NASSecurity Context, and the 5G Access Stratum (AS)
`Security context for 3GPP access and/or the 5G AS security context for non-3GPP
`access.
`
`- 5G ASsecurity context for 3GPP access: Kyxg, NH (next hop parameter), Kercins K
`recencs Kupints Kupencs Next Hop Chaining Counter parameter (NCC), identifiers for keys,
`the UE security capabilities, the UP security policy, and counters used for replay
`protection.
`- 5G ASsecurity context for non-3GPP access: Kyywe and the cryptographic keys,
`cryptographic algorithms and tunnel security parameters associated with the IPsec
`connection.
`
`- Full 5G NASSecurity context: Kamp, Kyasints Kxasenes WZ@KSI (next generation Key Set
`Identifier), UE security capabilities, uplink and downlink counters.
`- Partial 5G NASSecurity context: Kame, ngKSI, UE security capabilities, uplink and
`downlink NAS COUNTvalues setto 0.
`
`Fig. 3 shows the key derivations with the inputs. Fig. 3 illustrates a key hierarchy
`with key derivation inputs as defined in NPL1.
`Fig. 4 illustrates NAS secure mode command procedure in NPLI. In Fig.4, the
`NAS SMCprocedure is shown, which takes the non-current security context into use.
`The Fig. 4 showsthat the NAS Secure Mode Commandcontains the ngKSI and
`the Anti-Bidding down Between Architectures (ABBA) parameter, which are
`necessary to identify the Kayp and to derive the Kaye respectively. As can be seen from
`the Fig. 4, ciphering and integrity protection is started after the reception of the re-
`spective messagesin the UE and the AMF.Assuch,the keys are being taken into use
`during this procedure.
`Fig. 5 displays the method for establishing a partial security context when using
`EAP AKA‘accordingto the state of the art. Fig. 5 illustrates authentication and key
`agreement procedure for EAP AKA‘ accordingto thestate oftheart.
`Fig. 5 includes following steps.
`1. The UEsendsa registration request message to the SEAFin the mobile
`network. The UEincludesin the registration request message:
`- The Subscription Concealed Identifier (SUCD) calculated from the Subscription
`PermanentIdentifier (SUP) and the home network public key stored in the UE,or:
`- The 5G temporary identifier that was provided to the UE after a previous authen-
`tication and key agreement run by the network.
`2. (Optional) The SEAF, uponreception ofthe registration request or initial NAS
`message from the UE, will determine whetherit knowsthe temporary identifier. If the
`temporary identifier is included butit is not known in the SEAF, the SEAF willinitiate
`
`[0011]
`
`[0012]
`
`[0013]
`
`[0014]
`
`[0015]
`
`[0016]
`
`5
`
`

`

`WO 2020/179665
`
`PCT/JP2020/008314
`
`[0017]
`
`[0018]
`
`[0019]
`
`[0020]
`
`[0021]
`
`[0022]
`
`[0023]
`
`an identification procedure and send an identity request message to the UE.
`3. (Optional) If the UE receives an identity request message, it will respond to the
`SEAF / AMF with an identity response message containing the SUCI.
`4. Uponreception of the identity response message, the SEAFwill initiate the au-
`thentication by sending an authentication request message to the AUSF including the
`SUCI and the Serving Network Name.In 5G, this request is called the
`Nausf_UE_Authentication Authenticate Request.
`5. After reception of the authentication request message, the AUSF will send an
`authentication vector request message indicating a request for an authentication vector
`to the UDM. The AUSF includes the SUCI and the Serving Network Nameinthis
`request. In 5G,this request is called the Nudm_UEAuthentication_Get Request.
`6. After reception of the authentication vector request message, the UDM will
`decide on which authentication method to use (EAP AKA’ or 5G AKA), create an au-
`
`thentication vector and sendit to the AUSF. The authentication vector will contain
`
`RAND, AUTN, XRES, CK’and IK’ in case of EAP AKA’, and send the authentication
`
`vector and the SUPIin the response to the AUSF.In 5G,this messageis the
`Nudm_UEAuthentication_Get Response.
`7. When the AUSF receives the authentication vector, it will send the EAP-
`
`Request/AKA'-Challenge to the SEAF. This message includes the RAND, AUTN.
`8. The SEAF receives the EAP-Request/AKA' Challenge and sends this message
`to the UE. The SEAF also includes the ngKSI and the ABBA parameterso that the K
`amr can be derived by the UEafter successful authentication.
`In step A, the UE will verify the AUTN, andif successful, use the RES and K
`
`stored in the USIM to calculate CK and IK, and from CK and IK, calculate the CK' and
`
`IK’, Kause,; Ksear and Kame. The UE will create a temporary security context in which K
`Auses Ksgar, Kame, ng KSI, and other security context related parameters like counters
`are stored.
`
`[0024]
`
`[0025]
`
`[0026]
`
`9. The UE will return the RES (response) to the SEAF.In 5G,this messageis the
`Authentication Response message.
`10. The SEAF forwards the RES to the AUSF. In 5G, the message that the SEAF
`will use is the Nausf_UEAuthenticationAuthenticate Request message.
`In step B, the AUSF,after receiving the message, will verify the response and if
`correct, store the Kausr.
`
`[0027]
`
`11. If the response was successful, the AUSF will send the EAP Success message
`
`to the SEAF. The AUSFwill also send the Keg, and the SUPI to the SEAFin the
`
`[0028]
`
`same message.
`12. Upon reception of the EAP Success message, the SEAF will calculate the Kame
`after reception of the EAP Success message and forward the Kam; and SUPI to the
`
`6
`
`

`

`WO 2020/179665
`
`PCT/JP2020/008314
`
`[0029]
`
`[0030]
`
`[0031]
`
`[0032]
`
`[0033]
`
`[0034]
`
`[0035]
`
`[0036]
`
`AMF.Also, the SEAF may send the EAP Success message to the UE.
`In step C, if the SEAF send the EAP Success messageto the UE,the UE will
`transform the temporary security context to a current security context including Kausp,
`Ksear and Kame, and store it for later use. If the EAP Success message wasnotsent, but
`the UE receives a NAS SMCata later point in time, the UE will transform the
`temporary security context into a current security context.
`Fig. 6 displays a methodfor establishing a partial security context when using 5G
`AKAaccordingto the state of the art. Fig. 6 illustrates a method for establishing a
`partial security context when using 5G AKAaccordingto the state oftheart.
`Fig. 6 includes followingsteps.
`1. The UE sendsa registration request message to the SEAFin the mobile
`network. The UEincludesin the registration request message:
`- The Subscription Concealed Identifier (SUCD) calculated from the Subscription
`PermanentIdentifier (SUPI) and the home network public key stored in the UE,or:
`- The 5G temporary identifier that was provided to the UE after a previous authen-
`tication and key agreementrun by the network.
`2. (Optional) The SEAF, upon reception of the registration request or initial NAS
`message from the UE, will determine whether it knowsthe temporary identifier. If the
`temporary identifier is included butit is not known in the SEAF,the SEAFwill initiate
`an identification procedure and send an identity request message to the UE.
`3. (Optional) If the UE receives an identity request message, it will respond to the
`SEAF / AMF with an identity response containing the SUCI.
`4. Uponreception of the identity response message, the SEAFwill initiate the au-
`thentication by sending an authentication request message to the AUSF including the
`SUCI and the Serving Network Name.In 5G, this request is called the
`Nausf_UE_Authentication Authenticate Request.
`5. After reception of the authentication request message, the AUSF will send an
`authentication vector request messageindicating a request for an authentication vector
`to the UDM. The AUSF includes the SUCI and the Serving Network Nameinthis
`request. In 5G, this request is called the Nudm_UEAuthentication_Get Request.
`6. After reception of the authentication vector request message, the UDM will
`decide on which authentication method to use (EAP AKA' or 5G AKA), create an au-
`
`thentication vector and send it to the AUSF. The authentication vector will contain
`
`RAND, AUTN, XRES*, Kausp in case of SG AKA’, where XRES* is calculated from
`
`the XRES,the serving network name, and the RANDusing a cryptographic hash
`function, and send the authentication vector and the SUPIin the response to the AUSF.
`In 5G,this message is the Nudm_UEAuthentication_Get Response.
`In step B, after receiving the authentication vector, the AUSF will store or
`
`[0037]
`
`7
`
`

`

`WO 2020/179665
`
`PCT/JP2020/008314
`
`[0038]
`
`[0039]
`
`[0040]
`
`[0041]
`
`[0042]
`
`[0043]
`
`[0044]
`
`[0045]
`
`[0046]
`
`overwrite the Kays according to the state of the art.
`7. After receiving the authentication vector, the AUSF will generate a new authen-
`tication vector by computing the HXRES* from XRES*and Kgpar from Kause. The
`HXRES* is calculated using a hash and XRES*as oneof the inputs. The AUSFsends
`the HXRES*, Ksear, AUTN, and RESto the SEAF.In 5G, this new authentication
`
`vector is returned to the SEAF using the Nausf_UEAuthentication_Authenticate
`Response.
`8. The SEAF receives the authentication vector, extracts RAND and AUTN,and
`
`sends these values in a message to the UE. The SEAFalso includes the ngKSI and the
`ABBAparameterso that the Kays can be derived by the UE after successful authen-
`tication. In 5G, this messageis called the authentication request.
`In step A, the UE will verify the AUTN, andif successful, use the RES and K
`stored in the USIM to calculate CK and IK, and from CK and IK,calculate the Kase,
`
`Ksear and Kame. The UE will create a non-current security context in which Kausp, K
`sears Kame and ngKSI are stored. The UE will also calculate the RES* by using a key
`derivation function with RES, RAND, CK, IK, and serving network nameasaninput.
`Theresulting RES*is returned to the SEAF.
`9. The VE will return the RES* to the SEAF.In 5G, this messageis the Authen-
`lication Response message.
`10. Upon reception of the RES*, the SEAF calculates HRES* and compare with
`HXRES*. If the two values match, the SEAF forwards the RES*to the AUSF.In 5G,
`
`the messagethat the SEAFwill use is the Nausf_UEAuthenticationAuthenticate
`Request message.
`11. If the response was successful, the AUSF will indicate that the authentication
`was successful to the SEAF. The AUSF will also send the SUPI and Kggap to the SEAF
`
`in the same message. In 5G, the message Nausf_UEAuthentication_Authenticate
`Responseis used for this message.
`12. Upon reception of the successindication, the SEAF will calculate the Kamp
`after reception of the success message and forward the Kaye and SUPI to the AMF.
`In view of the problems described above, the present disclosure aims to provide a
`solution to solve at least one of the various problems.
`
`Solution to Problem
`
`The following presents a simplified summary of the subject matter in orderto
`provide a basic understanding of some aspects of subject matter embodiments. This
`summary is not an extensive overview of the subject matter. It is not intended to
`identify key/critical elements of the embodiments or to delineate the scope of the
`subject matter.
`
`8
`
`

`

`WO 2020/179665
`
`PCT/JP2020/008314
`
`[0047]
`
`[0048]
`
`[0049]
`
`[0050]
`
`[0051]
`
`[0052]
`
`[0053]
`
`[0054]
`
`[0055]
`
`[0056]
`[0057]
`
`[0058]
`
`[0059]
`
`[0060]
`
`a
`
`Its sole purposeis to present some concepts of the subject matter in a simplified
`form as a prelude to the more detailed description that is presentedlater.
`In a first aspect of the present disclosure, a terminal is provided, the terminal
`including a memory, and a processor, comprising hardware, configured to perform a
`primary authentication between the terminal and a network in 5G for a third party
`service, derive a security key, Kaysp, and derive an identifier for the security key from
`the security key.
`In a second aspect of the present disclosure, a method is provided, the method
`including performing a primary authentication between the terminal and a network in
`5G for a third party service, deriving a security key, Kause, and deriving an identifier
`for the security key from the security key.
`In a third aspect of the present disclosure, a core network apparatus used in a
`network in 5G is provided, the core network apparatus including amemory, and
`processor, comprising hardware, configured to perform a primary authentication
`between a terminal and the network for a third party service, derive a security key, K
`ausr, and derive an identifier for the security key from the security key.
`Brief Description of Drawings
`The foregoing and further objects, features and advantagesofthe present subject
`matter will become apparent from the following description of exemplary em-
`bodiments with reference to the accompanying drawings, wherein like numerals are
`used to representlike elements.
`It is to be noted, however, that the appended drawings along with the reference
`numerals illustrate only typical embodiments of the present subject matter, and are
`therefore, not to be considered for limiting of its scope, for the subject matter may
`admit to other equally effective embodiments.
`[fig.1]Fig. | illustrates an issue that exists with only one AKA and one NAS SMC,
`according to a reference disclosed in NPL.
`[fig.2]Fig. 2 illustrates a key hierarchy as defined in NPL1.
`[fig.3]Fig. 3 illustrates a key hierarchy with key derivation inputs as defined in NPLI.
`[fig.4]Fig. 4 illustrates NAS secure mode command procedure in NPL.
`[fig.5]Fig. 5 illustrates authentication and key agreement procedure for EAP AKA'
`according to the state of theart.
`[fig.6]Fig. 6 illustrates a method for establishing a partial security context when using
`5G AKAaccordingto the state ofthe art.
`[fig.7]Fig. 7 illustrates a process of SEAFfor creating an identifier for the Ksgar in ac-
`cordance with an embodiment ofthe present disclosure.
`[fig.8]Fig. 8 illustrates a process of marking an authentication as completed in ac-
`
`9
`
`

`

`WO 2020/179665
`
`PCT/JP2020/008314
`
`[0061]
`
`[0062]
`
`[0063]
`
`[0064]
`
`[0065]
`
`[0066]
`
`[0067]
`
`[0068]
`
`[0069]
`
`[0070}
`
`[0071]
`
`[0072]
`
`[0073]
`
`cordance with an embodiment ofthe present disclosure.
`[fig.9]Fig. 9 illustrates a process of changing of status of keys by the UE in accordance
`with an embodimentof the present disclosure.
`[fig.10]Fig. 10 illustrates a network initiated procedure for using the Kausp in ac-
`cordance with an embodiment ofthe present disclosure.
`[fig.11]Fig. 11 illustrates a UE initiated procedure for using the Kausp in accordance
`with an embodimentof the present disclosure.
`[fig.12]Fig. 12 shows a block diagram for a user equipmentin accordance with the
`present disclosure.
`[fig.13]Fig. 13 showsa block diagram for an (R)AN nodein accordance with the
`present disclosure.
`[fig.14]Fig. 14 shows a block diagram for a core network node in accordance with the
`present disclosure.
`Description of Embodiments
`According to an embodimentofthe present disclosure, a method for synchro-
`nization of home networkkey is disclosed, which comprises: storing Kaysp together
`with a Kaysp identifier, inside a UE, for the current, the non-current, and the temporary
`security context; storing the Kausr together, inside the network, with a Kausr identifier;
`and storing, by the AUSF, multiple Kays-'s.
`According to an embodimentofthe present disclosure, usage of the Kays¢ will
`include the identifier of the K,usp in their messages such thatit is known which Kause
`is used.
`
`According to an embodimentof the present disclosure, based on the usage, keys
`may be deleted from memory.
`Further, according to an embodimentof the present disclosure, the method
`comprises:
`calculating an identifier for Kause and Ksea¢ from the keys themselves at both the UE
`and the AUSF and/or SEAF;andstoring said identifier together with the Kausp and K
`SEAF+
`
`Yet, in another embodimentof the present disclosure, the method comprises:
`storing multiple identifiers and keys; and keeping the status for each key that has been
`derived.
`
`In an embodiment of the present disclosure, there is a set of criterion basis of
`whichit is determined which keysare to be deleted.
`In an embodimentof the present disclosure, the serving network causes a synchro-
`nization error between the Kyysp in the UE and the one in the AUSF.
`
`[0074]
`
`In an embodiment of the presentdisclosure, the Kausp protects or encrypts in-
`
`10
`
`10
`
`

`

`WO 2020/179665
`
`PCT/JP2020/008314
`
`formation exchange between the AUSFand the UE.
`In an embodimentofthe present disclosure, the AUSF and SEAFstore a key
`referenced by the UE, such as a key for a specific application or a bootstrapping key
`that is used in later procedures to derive a further key.
`In an embodimentof the present disclosure, a UE is disclosed, wherein the VE
`includesa transceivercircuit which is operable to transmit signals to and to receive
`signals from the connected node(s) via one or more antenna.
`In an embodimentof the present disclosure, a (R)AN nodeis disclosed, the (RJ)AN
`node includes a transceiver circuit which is operable to transmit signals to and to
`receive signals from connected UE(s) via one or more antennaandto transmit signals
`to and to receive signals from other network nodes(either directly or indirectly) via a
`network interface, a controller that controls the operation of the (R)AN node in ac-
`cordance with a memory.
`In an embodimentofthe present disclosure, a core network is disclosed, the core
`network node includesa transceiver circuit which is operable to transmit signals to and
`to receive signals from other nodes (including the UE) via a networkinterface. A
`controller controls the operation of the core network node in accordance with software
`stored in a memory.
`In an embodimentof the present disclosure, the core network nodeis at least one
`of: an AMF, a SMF, a SEAF, an AUSF, an UPF, an UDM, an ARPF,SIDF, a PCF, an
`
`AF etc.
`
`These and other objects, embodiments and advantagesof the present disclosure
`will become readily apparent to those skilled in the art from the following detailed de-
`scription of the embodiments having referenceto the attached figures, the disclosure
`not being limited to any particular embodimentsdisclosed.
`Exemplary embodiments nowwill be described with reference to the ac-
`companying drawings. The disclosure may, however, be embodied in manydifferent
`forms and should not be construed as limited to the embodimentsset forth herein;
`
`rather, these embodimentsare provided so that this disclosure will be thorough and
`complete, and will fully convey its scope to those skilled in the art. The terminology
`used in the detailed description of the particular exemplary embodimentsillustrated in
`the accompanying drawingsis not intended to be limiting. In the drawings,like
`numbersrefer to like elements.
`
`It is to be noted, however, that the reference numerals in claims illustrate only
`typical embodiments of the present subject matter, and are therefore, not to be
`considered for limiting of its scope, for the subject matter may admit to other equally
`effective embodiments.
`
`oon
`The specification may refer to "an",
`
`"one" or "some" embodiment(s) in several
`
`[0075]
`
`[0076]
`
`[0077]
`
`[0078]
`
`[0079]
`
`[0080]
`
`[0081]
`
`[0082]
`
`[0083]
`
`11
`
`11
`
`

`

`WO 2020/179665
`
`PCT/JP2020/008314
`
`[0084]
`
`[0085]
`
`[0086]
`
`[0087]
`
`[0088]
`
`locations. This does not necessarily imply that each such reference is to the same em-
`bodiment(s), or that the feature only applies to a single embodiment. Single features of
`different embodiments may also be combined to provide other embodiments.
`As used herein, the singular forms "a", "an" and "the" are intended to include the
`plural forms as well, unless expressly stated otherwise. It will be further understood
`that the terms "includes", "comprises", "including" and/or "comprising" when used in
`this specification, specify the presenceof stated features, integers, steps, operations,
`elements, and/or components, but do not preclude the presenceor addition of one or
`more other features, integers, steps, operations, elements, components, and/or groups
`thereof. It will be understood that when an elementis referred to as being "connected"
`or "coupled" to another element, it can be directly connected or coupled to the other
`element or intervening elements maybe present. Furthermore, "connected" or
`"coupled" as used herein may include operatively connected or coupled. As used
`herein, the term "and/or" includes any and all combinations and arrangements of one or
`more of the associated listed items.
`
`Unless otherwise defined,all terms (including technical and scientific terms) used
`herein have the same meaning as commonly understood by oneofordinary skill in the
`art to which this disclosure pertains. It will be further understood that terms, such as
`those defined in commonlyused dictionaries, should be interpreted as having a
`meaningthat is consistent with their meaningin the context of the relevant art and will
`not be interpreted in an idealized or overly formal sense unless expressly so defined
`herein.
`
`The figures depict a simplified structure only showing some elements and
`functional entities, all being logical units whose implementation may differ from what
`is shown. The connections shownare logical connections; the actual physical con-
`nections may be different. It is apparent to a person skilled in the art that the structure
`may also comprise other functions andstructures.
`Also,all logical units described and depicted in the figures include the software
`and/or hardware components required for the unit to function. Further, each unit may
`comprise within itself one or more components which are implicitly understood. These
`components maybe operatively coupled to each other and be configured to com-
`municate with each other to perform the function of the said unit.
`The central idea of this embodimentof the present application is to calculate an
`identifier for Kause and Kse4r from the keys themselves at both the UE and the AUSF
`and/or SEAF andstorethis identifier together with the Kausp and Kggar. This em-
`bodiment works as follows.
`
`[0089]
`
`The steps herein refer to Fig. 5. It is assumedthat the UEthatis being au-
`thenticated corresponds to IMSI1. The following steps are performed.
`
`12
`
`12
`
`

`

`WO 2020/179665
`
`PCT/JP2020/008314
`
`[0090]
`
`Steps 1-8 are unchanged from Fig. 5 and werefer to the description with Fig. 5. In
`step A, the UE now performsthe following.
`In step A, in addition to creating a temporary security context, the UE also creates
`an identifier for the Kausp by using a key derivation function as follows:
`- KTause = KDF(Kause, "KI"), and
`
`- KIsear = KDF(Ksgar, "KI"),
`
`Wherethe KI stands for Key Identifier and the subscript indicates for which keyitis
`used, and the KDFstandsfor the key derivation function. The "KI" inputtextis a
`string, but could also be a number. Additional values, like the RAND, RES, serving
`network name, etc. could also be included in the key derivation function. The UE
`stores this pair of KIs and Keysseparately. In this storage, the VE may also markthat
`these keys are the result of an authentication run that was not yet completed. The UE
`may also store a timestamp of when the key wasderived (not shownin table 1). The
`storage of the keysat this point in time could look as follows:
`Table 1
`
`
`
`
`
`
`
`
`
`Type of Key
`
`KI
`
`Key
`
`Authentication
`result?
`
`SEAF
`| KIseari
`Kseari
`Not completed
`AUSF
`| KIausr
`Kausri
`Not completed
`
`[0091]
`
`Steps 9 and 10 are unchanged from Fig. 5. In step B, the AUSF performs the
`following.
`In step B, the AUSF starts with creating anidentifier for the Kause by using a key
`derivation function as follows:
`
`- KTuse > KDF(Kause. "KI")
`
`Wherethe KI stands for Key Identifier and the subscript indicates for which keyit is
`used, and the KDFstandsfor the key derivation function. The "KI" inputtext is a
`string, but could also be a number. Additional values, like the RAND, RES, serving
`network name, etc. could also be included in the key derivation function. The AUSF
`stores this pair of KIs and Keys togetherin a storage. In this storage, the AUSF may
`also mark that these keys have been usedornot in subsequent procedures. The AUSF
`mayalso store a timestamp of when the key was derived (not shownin table 2). The
`storage of the keys at this point in time could look as follows:
`Table 2
`
`
`
`
`
`
`
`
`Identity (IMSI)
`Kl
`Key
`Used?
`
`IMSI1
`| KTausri_imsit
`Kausriist!
`No
`IMSI2
`Klausri_imsi2
`Kausri_imsi2
`Yes
`
`Note that the AUSF can also use the SUPI instead of the IMSI as an identifier.
`
`[0092]
`
`Step 11 is unchanged from Fig. 5. After the reception of the messagein step 11,
`
`13
`
`13
`
`

`

`WO 2020/179665
`
`PCT/JP2020/008314
`
`the SEAF mayalso create a storage of the keys as follows in a new step D as shown in
`Fig. 7. Fig. 7 illustrates a process of SEAF for creating an identifier for the Ksgag in ac-
`cordance with an embodiment ofthe present disclosure.
`In step D, the SEAF createsan identifier for the Ksp,- by using a key derivation
`function as follows:
`
`- KIsear = KDF(Kegar, "KI")
`
`Where the KI stands for Key Identifier and the subscript indicates for which keyit is
`used, and the KDFstandsfor the ke