Title of invention: communication terminal, core network device, core network node, network node, and key derivation method
Technical field
[0001]
　The present disclosure relates to a communication terminal, a core network device, a core network node, a network node and a key derivation method.
Background technology
[0002]
　In 3GPP (3rd Generation Partnership Project), specifications of a communication system called 5G (hereinafter referred to as 5GS (5G System)) are being studied. 5GS includes 3GPP Access and Non-3GPP Access as access networks. Moreover, Non-3GPP Access includes Trusted Non-3GPP Access and Untrusted Non-3GPP Access. 3GPP Access is a network having devices whose functions or specifications are defined in 3GPP. Non-3GPP Access is a network having devices whose functions or specifications are not defined in 3GPP. In addition, Trusted Non-3GPP Access is a network recognized by communication carriers as a reliable access network. Untrusted Non-3GPP Access is a network that is not recognized as a reliable access network by communication carriers.
[0003]
　Non-Patent Document 1 discloses a handover process between 3GPP Access and Non-3GPP Access.
Prior art documents
Non-patent literature
[0004]
Non-Patent Document 1: 3GPP TR 23.799 V2.0.0 (2016-11)
Summary of the invention
Problems to be Solved by the Invention
[0005]
　Non-Patent Document 1 discloses a handover process between 3GPP Access and Non-3GPP Access. When a UE, which is a communication terminal, establishes multiple connections via 3GPP Access and Non-3GPP Access. Security mechanism is not specified. Therefore, in multiple connections using 3GPP Access and Non-3GPP Access, there is a problem that the security level is lowered.
[0006]
　In view of the above problems, an object of the present disclosure is to prevent a decrease in security level that occurs when establishing multiple connections via 3GPP Access and Non-3GPP Access, a core network device, and a key derivation. To provide a method.
Means for solving the problem
[0007]
　A communication terminal according to a first aspect of the present disclosure is defined between a communication unit that communicates with a gateway device that is arranged upstream of a core network device via Untrusted Non-3GPP Access, and the core network device. From the first security key used for the security processing of the message transmitted using this protocol, the second security used for the security processing of the message transmitted using the protocol defined with the gateway device. And a key derivation unit that derives a key.
[0008]
　A core network device according to a second aspect of the present disclosure is provided between a communication device that communicates with a communication terminal via a gateway device and Untrusted Non-3GPP Access that are arranged in front of the core network device, and the communication terminal. Security processing of a message transmitted using the protocol defined between the communication terminal and the gateway device from the first security key used for the security processing of the message transmitted using the protocol defined in A key derivation unit for deriving a second security key used for the.
[0009]
　A key derivation method according to a third aspect of the present disclosure communicates with a gateway device arranged in front of a core network device via Untrusted Non-3GPP Access, and a protocol defined with the core network device. From the first security key used for the security processing of the message transmitted by using the second security key used for the security processing of the message transmitted using the protocol defined with the gateway device. Derive.
Effect of the invention
[0010]
　According to the present disclosure, there are provided a communication terminal, a core network device, a core network node, a network node and a key derivation method that can prevent a decrease in security level that occurs when establishing multiple connections via 3GPP Access and Non-3GPP Access. Can be provided.
Brief description of the drawings
[0011]
FIG. 1 is a configuration diagram of a communication terminal according to a first embodiment.
FIG. 2 is a configuration diagram of a core network device according to the first embodiment.
FIG. 3 is a configuration diagram of a communication system according to a second exemplary embodiment.
FIG. 4 is a diagram showing a Key hierarchy according to the second exemplary embodiment.
FIG. 5 is a diagram showing a Key hierarchy according to the second exemplary embodiment.
FIG. 6 is a configuration diagram of a communication system according to a second exemplary embodiment.
FIG. 7 is a diagram showing a Key hierarchy according to the second exemplary embodiment.
FIG. 8 is a diagram showing a Key hierarchy according to the second exemplary embodiment.
FIG. 9 is a diagram showing a Key hierarchy according to the second exemplary embodiment.
FIG. 10 is a configuration diagram of a communication system according to a second exemplary embodiment.
FIG. 11 is a diagram showing a Key hierarchy according to the second exemplary embodiment.
FIG. 12 is a diagram showing a Key hierarchy according to the second exemplary embodiment.
FIG. 13 is a diagram showing derivation of a security key according to the second embodiment.
FIG. 14 is a diagram showing derivation of a security key according to the second embodiment.
FIG. 15 is a diagram showing a flow of a process of transmitting information about an access network used by the UE according to the second embodiment.
FIG. 16 is a diagram showing a flow of a process of transmitting information about an access network used by the UE according to the second embodiment.
FIG. 17 is a diagram showing a process of deriving a security key KSEAF according to the second embodiment.
FIG. 18 is a diagram showing a process of deriving a security key KSEAF according to the second embodiment.
FIG. 19 is a diagram showing a process of deriving a security key KSEAF according to the second embodiment.
FIG. 20 is a diagram showing a process of deriving a security key KSEAF according to the second embodiment.
FIG. 21 is a diagram showing a process of deriving a security key KSEAF according to the second embodiment.
FIG. 22 is a diagram showing a process of deriving a security key KSEAF according to the second embodiment.
FIG. 23 is a diagram showing a process of deriving a security key KSEAF according to the second embodiment.
FIG. 24 is a diagram showing a flow of an authentication process regarding the UE 30 according to the third embodiment.
FIG. 25 is a diagram showing a flow of an authentication process regarding the UE 30 according to the third embodiment.
FIG. 26 is a diagram showing a flow of an authentication process regarding the UE 30 according to the third embodiment.
FIG. 27 is a diagram showing the flow of an authentication process regarding the UE 30 according to the third embodiment.
FIG. 28 is a diagram showing a procedure of deriving a security key KAMF* during a handover according to the third embodiment.
FIG. 29 is a diagram showing derivation of a security key according to the third embodiment.
FIG. 30 is a diagram showing a procedure of deriving a security key KAMF* during a handover according to the third embodiment.
FIG. 31 is a diagram showing derivation of a security key according to the third embodiment.
FIG. 32 is a diagram showing a procedure of deriving a security key KAMF* during a handover according to the third embodiment.
FIG. 33 is a diagram showing derivation of a security key according to the third embodiment.
FIG. 34 is a diagram showing a procedure of deriving a security key KAMF* during a handover according to the third embodiment.
FIG. 35 is a diagram showing derivation of a security key according to the third embodiment.
FIG. 36 is a diagram showing a flow of a handover process according to the third embodiment.
FIG. 37 is a diagram showing a flow of a handover process according to the third embodiment.
FIG. 38 is a diagram showing a flow of a handover process according to the third embodiment.
FIG. 39 is a diagram showing a flow of handover processing according to the third exemplary embodiment.
FIG. 40 is a diagram showing the flow of a handover process according to the third embodiment.
FIG. 41 is a diagram showing the flow of a handover process according to the third embodiment.
FIG. 42 is a diagram showing a flow of a handover process according to the third embodiment.
FIG. 43 is a diagram showing a flow of a handover process according to the third embodiment.
FIG. 44 is a diagram showing a flow of handover processing according to the third exemplary embodiment.
FIG. 45 is a diagram showing a flow of a handover process according to the third embodiment.
FIG. 46 is a diagram showing a flow of a handover process according to the third embodiment.
FIG. 47 is a diagram showing a flow of a handover process according to the third embodiment.
FIG. 48 is a diagram showing a flow of a handover process according to the third embodiment.
FIG. 49 is a diagram showing the flow of a handover process according to the third embodiment.
FIG. 50 is a diagram showing a flow of a handover process according to the third embodiment.
FIG. 51 is a diagram showing the flow of a handover process according to the third embodiment.
FIG. 52 is a diagram showing a flow of a handover process according to the third embodiment.
FIG. 53 is a diagram showing a flow of a handover process according to the fourth embodiment.
FIG. 54 is a diagram showing a flow of handover processing according to the fourth embodiment.
FIG. 55 is a diagram showing a flow of handover processing according to the fourth embodiment.
FIG. 56 is a diagram showing a flow of a handover process according to the fourth embodiment.
FIG. 57 is a diagram showing a flow of a handover process according to the fourth embodiment.
FIG. 58 is a diagram showing a flow of a handover process according to the fourth embodiment.
FIG. 59 is a diagram showing a flow of a handover process according to the fourth embodiment.
FIG. 60 is a diagram showing a flow of a handover process according to the fourth embodiment.
FIG. 61 is a configuration diagram of a communication terminal according to each embodiment.
FIG. 62 is a configuration diagram of a core network device according to each embodiment.
[0012]
　(Embodiment 1)
　Hereinafter, an embodiment of the present disclosure will be described with reference to the drawings. First, a configuration example of the communication terminal 10 according to the first exemplary embodiment will be described with reference to FIG. The communication terminal 10 may be a computer device that operates by a processor executing a program stored in a memory. The communication terminal 10 may be a mobile phone terminal, a smartphone terminal, or a tablet terminal. Alternatively, the communication terminal 10 may be an IoT (Internet Of Things) terminal or an MTC (Machine Type Communication) terminal. Alternatively, the communication terminal 10 may be a UE (User Equipment) used as a generic term for communication terminals in 3GPP.
[0013]
　The communication terminal 10 has a communication unit 11 and a key derivation unit 12. The communication unit 11 and the key derivation unit 12 may be software or modules in which processing is executed by the processor executing a program stored in the memory. Alternatively, the communication unit 11 and the key derivation unit 12 may be hardware such as a circuit or a chip.
[0014]
　The communication unit 11 communicates with the gateway device arranged in the preceding stage of the core network device 20 via Untrusted Non-3GPP Access. The core network device 20 is a device arranged in the core network. The gateway device is a device arranged in the core network and having an instance, an interface or a reference point with the Untrusted Non-3GPP Access. The communication unit 11 can also communicate with the core network device 20 via 3GPP Access.
[0015]
　The key derivation unit 12 derives a gateway device security key used for security processing of a message transmitted using a protocol defined with the gateway device. The key derivation unit 12 derives a gateway device security key from a core network device security key used for security processing of a message transmitted using a protocol defined with the core network device.
[0016]
　Next, a configuration example of the core network device 20 according to the first embodiment will be described with reference to FIG. The core network device 20 may be a computer device that operates by a processor executing a program stored in a memory. The core network device 20 may be, for example, a server device.
[0017]
　The core network device 20 has a communication unit 21 and a key derivation unit 22. The communication unit 21 and the key derivation unit 22 may be software or modules in which processing is executed by the processor executing a program stored in the memory. Alternatively, the communication unit 21 and the key derivation unit 22 may be hardware such as a circuit or a chip.
[0018]
　The communication unit 21 communicates with the communication terminal 10 via the gateway device and Untrusted Non-3GPP Access. The key derivation unit 22 is similar to the key derivation unit 12, and detailed description thereof will be omitted.
[0019]
　As described above, the communication terminal 10 and the core network device 20 according to the first embodiment can derive the gateway device security key when performing communication via Untrusted Non-3GPP Access. Specifically, the communication terminal 10 and the core network device 20 can derive the gateway device security key using the core network device security key. As a result, the gateway device security key can be applied to a message transmitted in Untrusted Non-3GPP Access. As a result, even when establishing multiple connections including Untrusted Non-3GPP Access, it is possible to prevent a decrease in security level.
[0020]
　(Second Embodiment)
　Next, a configuration example of a communication system according to the second embodiment will be described with reference to FIG. It is shown that the communication system of FIG. 3 has an HPLMN (Home Public Land Mobile Network) or a VPLMN (Visited Public Land Mobile Network) and a Non-3GPP network. The UE 30 can communicate with the AMF 33 of the HPLMN or VPLMN via both HPLMN or VPLMN and Non-3GPP Access.
[0021]
　The HPLMN or VPLMN includes a 3GPP Access 32, an AMF (Access and Mobility management Function) entity 33 (hereinafter referred to as AMF 33), an SMF (Session Management Function) entity 34 (hereinafter referred to as SMF 34), and a UPF (User Plane Function) entity 35. (Hereinafter referred to as UPF35), AUSF (Authentication Server Function) entity 36 (hereinafter referred to as AUSF36), UDM (Unified Data Management) entity 37 (hereinafter referred to as UDM37), N3IWF (Non-3GPP Inter Working Function) entity 38 (hereinafter referred to as N3IWF38) and a Data Network 39.
[0022]
　Further, a gNB (g Node B) 31 is arranged in the 3GPP Access 32. The gNB 31 corresponds to a base station.
[0023]
　AMF33, SMF34, UPF35, AUSF36, UDM37, and N3IWF38 comprise a core network. The core network formed by the AMF 33, SMF 34, UPF 35, AUSF 36, UDM 37, and N3IWF 38 may be referred to as 5GC (5G Core), for example.
[0024]
　The AMF 33 performs mobility management regarding the UE 30. Furthermore, the AMF 33 cooperates with the AUSF 36 and the UDM 37 to perform an authentication process regarding the UE 30. The SMF 34 performs session management regarding the UE 30. The UPF 35 relays U(User)-Plane data transmitted between the UE 30 and the Data Network 39. The U-Plane data may be referred to as user data.
[0025]
　The N3IWF 38 communicates with the UE 30 via the Untrusted Non-3GPP Access 40. The N3IWF 38 connects different networks to each other and relays control data or C (Control)-Plane data regarding the UE 30 transmitted between the UE 30 and the AMF 33. The different networks may be, for example, HPLM and Non-3GPP Network, or VPLMN and Non-3GPP Network.
[0026]
　An N1 interface is defined between the UE 30 and the AMF 33. An N2 interface is defined between the 3GPP Access 32 and the AMF 33. The N2 interface is also defined between the AMF 33 and the N3IWF 38. An N3 interface is defined between the N3IWF 38 and the UPF 35. The N3 interface is also defined between the gNB 31 and the UPF 35. An N4 interface is defined between the SMF 34 and the UPF 35. An N6 interface is defined between the UPF 35 and the Data Network 39. An N11 interface is defined between the AMF 33 and the SMF 34. An N12 interface is defined between the AMF 33 and the AUSF 36. An N13 interface is defined between the AUSF 36 and the UDM 37. A Y1 interface is defined between the UE 30 and the Untrusted Non-3GPP Access 40. An NWu interface is defined between the UE 30 and the N3IWF 38. The term interface may be paraphrased as an instance or a reference point.
[0027]
　The security key KgNB is used for the security processing regarding the message transmitted between the UE 30 and the gNB 31. The security key Knon-3gpp is used for the security processing regarding the message transmitted between the UE 30 and the N3IWF 38. The security key KAMF is used for the security processing regarding the message transmitted between the UE 30 and the AMF 33.
[0028]
　Next, the Key hierarchy according to the second embodiment will be described with reference to FIG. The Key hierarchy of FIG. 4 is applied to a multiple NAS (Non-Access Stratum) that allows the UE 30 to communicate with the AMF 33 via a plurality of access networks. Moreover, the Key hierarchy of FIG. 4 has shown the security key produced|generated in UE30 and 5GC.
[0029]
　The security key KSEAF is derived from the security key K that has been mutually authenticated between the UE 30 and the AUSF 36. The security key K may be referred to as a long-term key. The security key KSEAF is transmitted to AMF33. The security key KAMF is derived from the security key KSEAF. The security key KNASint used for integrity protection and the security key KNASenc used for encryption are derived from the security key KAMF. The security key KNASint and the security key KNASenc may be referred to as a NAS security key.
[0030]
　The security key KgNB is derived from the security key KAMF. The security key KRRCint, the security key KRRCenc, the security key KUPint, and the security key KUPenc are derived from the security key KgNB. The security key KRRCint and the security key KRRCenc are used to protect the RRC message transmitted between the UE 30 and the 3GPP Access 32. The security key KUPint and the security key KUPenc are used to protect U-Plane data transmitted between the UE 30 and the 3GPP Access 32.
[0031]
　The security key Knon-3gpp is derived from the security key KAMF. The security key Knon-3gpp is used to protect the message transmitted between the UE 30 and the N3IWF 38. The security keys KAMF and KgNB may be updated during handover. Also, the security key Knon-3gpp may be derived from the security key KSEAF.
[0032]
　Next, a Key hierarchy different from that in FIG. 4 will be described with reference to FIG. The Key hierarchy of FIG. 5 differs from the Key hierarchy of FIG. 4 in that the security keys KNAS_N3Gint and KNAS_N3Genc are derived from the security key KAMF.
[0033]
　In an existing network such as LTE (Long Term Evolution), only one NAS connection is established between the UE 30 and the core network. On the other hand, in 5G, multiple connections are established between the UE 30 and 5GC. Specifically, the AMF 33 independently establishes a NAS connection with the UE 30 that communicates via the 3GPP Access 32 and the UE 30 that communicates via the Untrusted Non-3GPP Access 40.
[0034]
　In the Key hierarchy of FIG. 4, the same NAS security key is used for both the NAS connection established through 3GPP Access 32 and the NAS connection established through Untrusted Non-3GPP Access 40.
[0035]
　On the other hand, in the Key hierarchy of FIG. 5, the security keys KNAS_N3Gint and KNAS_N3Genc are derived. Therefore, the NAS security key used in the NAS connection established via the 3GPP Access 32 is different from the NAS security key used in the NAS connection established via the Untrusted Non-3GPP Access 40.
[0036]
　Subsequently, a configuration example of a communication system different from that in FIG. 3 will be described with reference to FIG. FIG. 6 shows that the UE 30 has established multiple connections between VPLMN1 and VPLMN2 or HPLMN. The VPLMN 1 includes gNB 31, 3GPP Access 32, AMF 33, SMF 34, UPF 35, and Data Network 39. VPLMN2 contains AMF51, SMF52, UPF53, N3IWF54, and Data Network55. Further, the AUSF 36 and the UDM 37 may be included in the HPLMN.
[0037]
　FIG. 6 shows that the UE 30 differs between the AMF 33 that establishes the NAS connection via the 3GPP Access 32 and the AMF 51 that establishes the NAS connection via the Untrusted Non-3GPP Access 40.
[0038]
　Next, the Key hierarchy applied in the communication system of FIG. 6 will be described using FIG. 7. 7 is premised on that the UE 30 establishes a NAS connection with the AMF 51 arranged in the HPLMN via the Untrusted Non-3GPP Access 40 in the communication system of FIG.
[0039]
　The security key KSEAF_H and the security key KSEAF_V are derived from the security key K. The security key KSEAF_H is transmitted to the AMF 51. The security key KSEAF_V is transmitted to the AMF 33. The security key derived from each of the security key KSEAF_H and the security key KSEAF_V is the same as that in FIG. 4, and detailed description thereof will be omitted.
[0040]
　FIG. 8 is a Key hierarchy applied in the communication system of FIG. 6, and shows a Key hierarchy different from that of FIG. 7. The Key hierarchy of FIG. 8 differs from the Key hierarchy of FIG. 7 in that the security keys derived from the security keys KSEAF_H and KSEAF_V are the same as those of FIG.
[0041]
　Moreover, FIG. 9 shows the Key hierarchy when the UE 30 has a plurality of VPLMNs that establish multiple connections. The security keys derived after the security keys KSEAF_V1 and KSEAF_V2 are the same as those in FIG. 5, and detailed description thereof will be omitted.
[0042]
　Subsequently, a configuration example of a communication system different from that in FIG. 3 will be described with reference to FIG. FIG. 10 shows that within the HPLMN, the UE 30 has established multiple connections via multiple N3IWFs. Further, FIG. 10 shows that the UE 30 has established multiple connections with the VPLMN1 and has established connections with the VPLMN2.
[0043]
　The UE 30 establishes a NAS connection with the AMF 33_1 via the N3IWF 38_1 in the HPLMN. Further, the UE 30 establishes a NAS connection with the AMF 33_2 via the N3IWF 38_2 in the HPLMN. Further, the UE 30 establishes the NAS connection with the AMF 33_1 and the AMF 33_2 via the 3GPP Access 32 in the HPLMN.
[0044]
　Further, the VPLMN 1 has 3GPP Access 62, AMF 63, N3IWF 64, and Non-3GPP Access 65. The 3GPP Access 62 has gNB61. The VPLMN 2 has a Non-3GPP Access 72 and an AMF 73. The Non-3GPP Access 72 has an N3IWF 71. The UE 30 establishes a NAS connection with the AMF 63 via the 3GPP Access 62. Further, the UE 30 establishes a NAS connection with the AMF 63 via the N3IWF64. Furthermore, the UE 30 establishes a NAS connection with the AMF 73 via the N3IWF 71.
[0045]
　Next, the Key hierarchy applied in the communication system of FIG. 10 will be described using FIG. 11. The security key KSEAF derived from the security key K is transmitted to AMF33_1, AMF33_2, AMF63, and AMF73. Each of AMF33_1, AMF33_2, AMF63, and AMF73 derives a different security key KAMF like the security key KAMF_1 and the security key KAMF_2.
[0046]
　The subsequent derivation of the security key is the same as in FIG. 5, and thus detailed description thereof will be omitted.
[0047]
　The Key hierarchy described so far can be divided into three types shown in FIG. Type 1 is the Key hierarchy described in FIG. Type 2 is the Key hierarchy described in FIG. Type 3 is a Key hierarchy used when the UE 30 establishes multiple connections with the AMF 33 via a plurality of access networks of the same type. The plurality of access networks of the same type may be, for example, a plurality of N3IWF or the like connected to the AMF 33. Specifically, type 3 is a key hierarchy in which security keys KNAS, KgNB, and Knon-3gpp that are different for each of a plurality of N3IWFs are derived from the security key KAMF in the key hierarchy described in FIG.
[0048]
　Next, the derivation of the security key KNAS_N3Genc will be described with reference to FIG. The security key KNAS_N3Genc is output from KDF (Key Derivation Function). The security key KAMF, encryption algorithm identification information (Enc.Algo ID), and AN Identity are input to the KDF. AN Type may be input to KDF instead of AN Identity.
[0049]
　For AN Type, for example, a 2-bit value may be used. Specifically, 00 may indicate 3GPP Access, 01 may indicate Untrusted Non-3GPP Access, and 10 may indicate trusted Non-3GPP Access. Alternatively, a 1-bit value may be used for AN Type. Specifically, 0 may indicate 3GPP Access and 1 may indicate Non-3GPP Access.
[0050]
　FIG. 14 shows the derivation of the security key KNAS_N3Gint. In FIG. 14, an integrity assurance algorithm ID (Int.Algo ID) is used instead of the encryption algorithm ID (Enc.Algo ID) in FIG. Other input parameters are the same as those in FIG.
[0051]
　In FIG. 13 and FIG. 14, when the UE 30 establishes multiple connections with the AMF 33 via a plurality of Non-3GPP Access in one PLMN (HPLMN or VPLMN), N3G_Count may be used as an input parameter to the KDF. In other words, when the AMF 33 sets a plurality of N1 interfaces with the UE 30, N3G_Count may be used.
[0052]
　N3G_Count may be incremented each time one connection is established, that is, each N1 interface is set.
[0053]
　Further, NONCEn3gpp transmitted from the AMF 33 to the UE 30 as a part of the protected NAS SMC (Security Mode Command) message may be used as an input parameter.
[0054]
　In addition, RAND may be used as an input parameter. The RAND may be, for example, Salt “s” used as an input to the same PRNG (Pseudo Random Number Generator) in the UE 30 and the AMF 33. The RAND may be sent from the AMF 33 to the UE 30 as part of the protected NAS SMC message.
[0055]
　Here, a method of synchronizing N3G_Count between the UE 30 and the AMF 33 will be described below.
[0056]
　The N3G_Count may be transmitted between the UE 30 and the AMF 33 by being included in the NAS message that is integrity protected and encrypted. Alternatively, N3G_Count may be included in the NAS message in which only integrity protection is performed and transmitted between the UE 30 and the AMF 33. The NAS message including N3G_Count may be, for example, a NAS SMC message or an N1 message for optimized NAS.
[0057]
　Alternatively, the following method that does not directly transmit N3G_Count may be used between the UE 30 and the AMF 33.
[0058]
　It is premised that the UE 30 and the AMF 33 each hold N3G_Count value. In such a state, the AMF 33 selects an arbitrary value (random number) N. Further, the AMF 33 calculates d=N3G_Count value+N. Alternatively, the AMF 33 may calculate d=N3G_Count value-N or d=N3G_Count value xor N. The value d may be calculated using any calculation method.
[0059]
　Next, the AMF 33 transmits to the UE 30 at least one of N and d and an indicator indicating the calculation method used when calculating d. The indicator indicating the operation method indicates, for example, addition, subtraction, or xor operation. The AMF 33 may transmit at least one of N and d and the indicator to the UE 30 by including them in the NAS message that is integrity protected and encrypted. Alternatively, the AMF 33 may include at least one of N and d and an indicator in the NAS message in which only integrity protection has been performed, and may transmit them to the UE 30.
[0060]
　Next, the UE 30 synchronizes the N3G_Count value with the value received from the AMF 33. Furthermore, the UE 30 derives the security key by using the synchronized N3G_Count value as an input parameter of the KDF.
[0061]
　Next, with reference to FIG. 15, a flow of a process of transmitting information regarding the access network used by the UE 30 will be described. First, the AMF 33 transmits a NAS SMC message to the UE 30 (S11). NAS SMC message is KSI (Key Set Identifier), Replayed UE Security capabilities, Allowed NSSAI (Network Slice Selection Assistance Information), NAS Algorithms, N1-instance-indicator, Parameters to derive NAS integrity and encryption keys, and NAS-MAC ( NAS-Message Authentication Code).
[0062]
　N1 in N1-instance-indicator means N1 instance or N1 interface. That is, N1-instance-indicator indicates the access network used by the UE 30. Alternatively, N1-instance-indicator may indicate an access network that the UE 30 can use.
[0063]
　Parameters to derive NAS integrity and encryption keys may include AN Identity, AN type, N3G_Count, NONCEn3gpp, and RAND.
[0064]
　Next, the UE 30 derives the security keys KAMF, KNASint, and KNASenc using the received parameters (S12). Next, the UE 30 transmits a NAS Security Mode Complete message to the AMF 33 (S13). The NAS Security Mode Complete message includes NAS-MAC and Replayed allowed NSSAI.
[0065]
　When the UE 30 can use multiple Non-3GPP access, the NAS SMC message may include an indicator indicating a specific N1 instance.
[0066]
　Next, with reference to FIG. 16, a flow of a process of transmitting information regarding the access network used by the UE 30, which is different from FIG. 15, will be described. 16, in steps S21 and S23, the N1 message is used instead of the NAS SMC message and the NAS Security Mode Complete message of FIG. The N1 message transmitted in step S21 includes 5G KSI, N1-instance-indicator, Parameters to derive NAS integrity and encryption keys, and N1-MAC.
[0067]
　Further, the N1 message transmitted in step S21 may be protected by using the NAS integrity keys and NAS encryption keys that the AMF 33 has. Further, the N1 message transmitted in step S23 may be protected by using the NAS integrity keys and NAS encryption keys derived in step S22.
[0068]
　Next, a modified example of the process of deriving the security key KSEAF will be described with reference to FIGS. 17 to 23. 17 to 23, modified examples of 5G AKA will be mainly described. 17 to 23 show a security key derivation process on each of the core network side and the UE.
[0069]
　First, the process of deriving the security key KSEAF will be described with reference to FIG. In the UDM 37, an integrity protection key IK (Integrity Key) and an encryption key CK (Cipher Key) are derived from the security key K. Next, the UDM 37 executes 5G-AKA to derive the security key KAUSF from the integrity protection key IK and the encryption key CK. Further, in the UDM 37, KSEAF is derived from the integrity protection key IK and the encryption key CK.
[0070]
　In FIG. 18, in the UDM 37, the security keys KAUSF and KSEAF are derived from the integrity protection key IK and the encryption key CK without executing 5G-AKA.
[0071]
　In FIG. 19, in the UDM 37, the security key KAUSF is derived from the integrity protection key IK and the encryption key CK without executing 5G-AKA. Further, the AUSF 36 derives the security key KSEAF from the security key KAUSF.
[0072]
　In FIG. 20, the security key KAUSF is derived from the security key K in the UDM 37. Next, an integrity protection key IK (Integrity Key) and an encryption key CK (Cipher Key) are derived from the security key KAUSF. Next, in the UDM 37, the security key KSEAF is derived from the integrity protection key IK and the encryption key CK without executing 5G-AKA.
[0073]
　In FIG. 21, the 5G Master Key is derived from the security key K in the UDM 37. Next, in the UDM 37, the security key KAUSF and the security key EKAUSF (Extended KAUSF) are derived by executing 5G-AKA from the 5G Master Key. Next, in the AUSF 36, the security key KSEAF is derived from the security key KAUSF.
[0074]
　In FIG. 22, the UDM 37 executes 5G-AKA from the integrity protection key IK (Integrity Key) and the encryption key CK (Cipher Key), so that the integrity protection key 5G-IK and the encryption key 5G-CK are executed. From, the security key KAUSF is derived. Next, in the AUSF 36, the security keys KASME and EKASME are derived from the integrity protection key 5G-IK and the encryption key 5G-CK. Next, in the AUSF 36, the security key KSEAF is derived from the security key KASME.
[0075]
　FIG. 23 shows that Key Hierarchy supports EAP-TLS (Extensible Authentication Protocol-Transport Layer Security). A key PMK (Pre Master Key) is derived from the security key K by executing EAP-TLS based on PSK (Pre-Shared Key). Next, the keys MSK and EMSK are derived from the key PMK by executing EAP-TLS based on Certificates. Next, the UDM 37 derives the security key KSEAF from the key MSK, and further derives the security key KAUSF from the key MSK. The keys MSK and EMSK may be derived from the security key K by executing EAP-TLS based on PSK. In EAP-TLS based on PSK, the PSK ID is transmitted from the UE in the registration request as part of the UE Security Capabilities. The security key K may be PSK.
[0076]
　As described above, the AMF 33 can share the security key with the UE 30 that is connected via Non-3GPP Access such as Untrusted Non-3GPP Access.
[0077]
　(Embodiment 3)
　Next, the flow of authentication processing regarding the UE 30 will be described using FIG. In FIG. 24, it is assumed that the AUSF 36 holds AVs (Authentication Vectors) used in the authentication process (S30). Further, SEAF/AMF33 indicates that the AMF33 has a SEAF (Security Anchor Function). The ARPF/UDM 37 indicates that the UDM 37 has an ARPF (Authentication credential Repository and Processing Function).
[0078]
　First, the AMF 33 transmits 5G-AIR (5G-Authentication Identifier Request) to the AUSF 36 (S31). 5G-AIR includes SUCI (Subscription Concealed Identifier) ​​regarding the UE 30. Next, the AUSF 36 executes de-concealment of SUCI with the UDM 37 in order to obtain a SUPI (Subscription Permanent Identifier). Specifically, the AUSF 36 transmits SUCI to the UDM 37. Further, the UDM 37 extracts SUPI from SUCI. After that, the UDM 37 transmits SUPI to the AUSF 36.
[0079]
　Next, the AUSF 36 extracts (retrieves) the transformed AV or AV* (S33). transformed AV includes RAND, AUTN, and XRES*. AV* includes RAND, AUTN, XRES*, and security key KSEAF. Next, the AUSF 36 calculates HXRES*(Hash XRES) (S34). For example, AUSF 36 uses SHA-256 as a hash function to calculate HXRES* for XRES*.
[0080]
　Next, the AUSF 36 transmits a 5G-AIA (5G-Authentication Identifier Answer) to the AMF 33 (S35). 5G-AIA includes AV* or transformed AV, AV ID, and HXRES*. AV ID is identification information for identifying AV* or transformed AV.
[0081]
　Next, the AMF 33 transmits Auth-Req to the UE 30 (S36). Auth-Req includes RAND AUTN and AV ID. Next, UE30 acquires RES, CK, and ID from USIM(Universal Subscriber Identity Module) (S37). In other words, RES, CK, and ID are output from the USIM to the ME (Mobile Equipment) that is the main body of the UE 30.
[0082]
　Next, the ME of the UE 30 calculates RES* (S38).
[0083]
　Next, the UE 30 transmits Auth-Res to the AMF 33 (S39). Auth-Res includes RES* and AV ID. Next, the AMF 33 calculates HRES* (S40). For example, the AMF 33 uses SHA-256 as a hash function to calculate HRES* regarding RES*.
[0084]
　Next, the AMF 33 compares HREX* and HXRES* to determine whether HRES* and HXRES* match (S41). When HRES* and HXRES* match, the AMF 33 determines that the UE 30 is a valid UE. Next, the AMF 33 transmits 5G-AC (5G-Authentication Complete) to the AUSF 36 (S42). 5G-AC includes RES* and AV ID.
[0085]
　When the UE 30 is supplied with only one AV, the AV ID may not be included in steps S35, S36, S39, and S42.
[0086]
　Next, with reference to FIG. 25, a flow of an authentication process regarding the UE 30 different from that in FIG. 24 will be described. In FIG. 25, it is assumed that the AMF 33 holds AVs (Authentication Vectors) used in the authentication process (S50).
[0087]
　Since steps S51 and S52 are similar to steps S33 and S34 in FIG. 24, detailed description thereof will be omitted. In steps S51 and S52, the AMF 33 executes the processing described in steps S33 and S34.
[0088]
　Steps S53 to S59 are the same as steps S36 to S42 of FIG. 24, and thus detailed description thereof will be omitted.
[0089]
　Next, with reference to FIG. 26, a flow of an authentication process regarding the UE 30 different from those in FIGS. 24 and 25 will be described. Steps S61 and S62 are similar to steps S31 and S32 of FIG. 24, and detailed description thereof will be omitted.
[0090]
　Next, the AUSF 36 extracts the security key KAUSF corresponding to the UE 30 (S63). Next, the AUSF 36 derives a new security key KSEAF using the security key KAUSF, PLMN ID, PLMN count or SN (Serving Network) count, and SN name (S64). Next, the AUSF 36 calculates XRES using the security keys KAUSF and RAND, and further calculates HXRES (S65).
[0091]
　Next, the AUSF 36 transmits 5G-AIA to the AMF 33 (S66). 5G-AIA includes HXRES, RAND, and indicator for use of KAUSF. Next, the AMF 33 transmits Auth-Req to the UE 30 (S67). Auth-Req includes RAND and Indicator for use of KAUSF.
[0092]
　Next, the UE 30 calculates a new security key KSEAF using the security key KAUSF, PLMN ID, PLMN count or SN count, and SN name (S68). Next, the UE 30 calculates RES using the security keys KAUSF and RAND (S69). Next, the UE 30 transmits Auth-Res to the AMF 33 (S70). Auth-Res includes RES.
[0093]
　Next, the AMF 33 compares HREX and HXRES to determine whether HRES and HXRES match (S72). When the HRES and HXRES match, the AMF 33 determines that the UE 30 is a valid UE. Next, the AMF 33 transmits 5G-AC to the AUSF 36 (S73). 5G-AC includes RES.
[0094]
　Steps S64 and S68 may be omitted. Further, steps S65 and S69 may be omitted when the AUSF 36 requests the XRES from the ARPF (Authentication Credential Repository and Processing Function) entity. Further, the security key KAUSF can be used between PLMNs when it does not depend on SN. When the security key KAUSF depends on SN, the security key KAUSF can be used in PLMN without using the security key KAUSF, PLMN ID, PLMN count or SN count, and SN name.
[0095]
　Next, with reference to FIG. 27, a flow of an authentication process regarding the UE 30 different from those in FIGS. 24 to 26 will be described. First, the UE 30 transmits a Registration Request to the AMF 33 (S81). The Registration Request includes UE ID, UE Security Capabilities with PRF IDs or PMK ID, Auth-method, AN type, Authentication restrictions, Auth-type, Re-auth type, AV ID, and 5G KSI. UE Security Capabilities include Ciphersuites, PFR IDs, and PSK IDs.
[0096]
　Next, the AMF 33 selects a re-authentication option based on the Re-auth type, AN type, and authentication restrictions (S82). Re-auth type performs authentication using transformed AV or AV*, performs authentication using security key KSEAF derived using security key KAUSF, or uses old security key KSEAF. This is information indicating whether or not to perform authentication using the new derived security key KSEAF.
[0097]
　AN type is information indicating the access network. The authentication restrictions are information on the authentication method supported by the UE 30 or the authentication method permitted by the UE 30. For example, the authentication method supported by the UE 30 may be EAP-TLS based on certificates.
[0098]
　Next, the AMF 33 transmits Auth-Req to the UE 30 (S83). Auth-Req includes RAND, AUTN, AV-ID, and Re-auth type. Next, the UE 30 carries out Network authentication (S84). Next, the UE 30 transmits Auth-Res to the AMF 33 (S85). Auth-Res includes RES*. RES* is calculated in step S84.
[0099]
　Next, the AMF 33 carries out UE authentication (S86). Next, the AMF 33 transmits 5G-AC to the AUSF 36 (S87). 5G-AC includes RES* and AV ID.
[0100]
　Next, the procedure for deriving the security key KAMF* during handover will be described with reference to FIG. In the following description, the handover source AMF is referred to as Source AMF33_1 and the handover destination AMF is referred to as Target AMF33_2.
[0101]
　First, the Source AMF 33_1 derives the security key KAMF* using the old security keys KAMF and Count (S91). For example, as shown in FIG. 29, the security key KAMF* is derived by inputting the old security keys KAMF and Count into KDF.
[0102]
　Next, Source AMF33_1 transmits Forward Relocation Request to Target AMF33_2 (S92). The Forward Relocation Request includes 5G-GUTI (Globally Unique Temporary Identifier), AUSF ID, security key KAMF*, UE security capabilities, and Count.
[0103]
　Next, the procedure for deriving the security key KSEAF* during handover will be described with reference to FIG.
[0104]
　First, the Source AMF 33_1 derives the security key KSEAF* using the old security keys KSEAF and Count (S101). For example, as shown in FIG. 31, the security key KSEAF* is derived by inputting the old security keys KSEAF and Count into KDF.
[0105]
　Next, Source AMF33_1 transmits Forward Relocation Request to Target AMF33_2 (S102). The Forward Relocation Request includes 5G-GUTI, AUSF ID, security key KSEAF*, UE security capabilities, and Count.
[0106]
　Next, a procedure for deriving the security key KSEAF* during a handover, which is different from that in FIG. 30, will be described with reference to FIG.
[0107]
　First, Source AMF33_1 transmits Relocation Request to AUSF36 (S111). The Relocation Request contains 5G-GUTI, UE security capabilities, and the old security key KSEAF. Next, the AUSF 36 derives the security key KSEAF* using the old security key KSEAF, PLMN ID, PLMN count or SN count, and SN name (S112). For example, as shown in FIG. 33, the security key KSEAF* is derived by inputting the old security key KSEAF, PLMN ID, PLMN count or SN count, and SN name into KDF.
[0108]
　Next, the AUSF 36 transmits a Forward Relocation Request to the Target AMF 33_2 (S113). The Forward Relocation Request includes 5G-GUTI, security key KSEAF*, UE security capabilities, and Count.
[0109]
　Next, a procedure for deriving the security key KSEAF* during a handover different from that in FIG. 32 will be described with reference to FIG.
[0110]
　First, Source AMF33_1 transmits Relocation Request to AUSF36 (S121). The Relocation Request includes 5G-GUTI and UE security capabilities. Next, the AUSF 36 derives the security key KSEAF* using the old security key KAUSF, PLMN ID, PLMN count or SN count, and SN name (S122). For example, as shown in FIG. 35, the security key KSEAF* is derived by inputting the old security key KAUSF, PLMN ID, PLMN count or SN count, and SN name into KDF.
[0111]
　Next, the AUSF 36 transmits a Forward Relocation Request to the Target AMF 33_2 (S123). The Forward Relocation Request includes 5G-GUTI, security key KSEAF*, UE security capabilities, and Count.
[0112]
　Next, the flow of Handover intra PLMN from 3GPP to non-3GPP access processing will be described using FIG. First, when the gNB 31 determines to start HO (Handover), it generates a HO required message (S131a). The HO required message includes UE's identity and UE's capabilities such as GUTI. Here, when the UE 30 determines to start the HO, the UE 30 may send the HO required message to the gNB 31 (S131b). The HO required message in this case also includes UE's identity and UE's capabilities such as GUTI. In addition, the HO required message transmitted by the UE 30 is protected by the NAS security established in 3GPP Access. Further, the HO required message includes the identification information of the N3IWF to which the UE 30 is connected or has been connected in the past.
[0113]
　Next, the gNB 31 transmits a HO required message to the AMF 33 (S132). AMF relocation may be performed based on the normal HO procedure. Next, the AMF 33 checks whether the UE's capabilities are valid for determining whether to send the HO request (S133). UE's capabilities include security capabilities and access right to the N3IWF 38.
[0114]
　Next, the AMF 33 requests the Source SMF 34_1 to provide the SM (Session Management) context, and the Source SMF 34_1 provides the AMF 33 with the SM context (S134). When the UE 30 has multiple sessions, the AMF 33 requests multiple SMFs to provide the SM context.
[0115]
　Next, the AMF 33 derives the security key KN3IWF for Non-3GPP Access (S135). The security key KN3IWF is transmitted to N3IWF38. Next, the AMF 33 transmits a Create session request to the Target SMF 34_2 based on the received SM context. Furthermore, Target SMF34_2 allocates the resource for a session and transmits Create session response to AMF33 (S136).
[0116]
　Next, the AMF 33 transmits a HO request to the N3IWF 38 (S137). The AMF 33 may select the N3IWF 38 based on the identification information transmitted from the UE 30. The HO request may include information about the session and bearer establishment. Further, the HO request may include a security context, security key identification information (KSI or KSI Set Identifier), information indicating whether the requested security configurations are necessary, and an algorithm used. Security configurations may be information regarding integrity protection and encryption.
[0117]
　Next, the N3IWF 38 may check whether the UE's capabilities and access right are valid to determine whether the relocation request can be accepted (S138).
[0118]
　Next, the N3IWF 38 allocates the resources required for bearer establishment and transmits a HO request ACK to the AMF 33 (S139). Next, the AMF 33 transmits the HO command to the gNB 31 (S140). HO command includes security configurations. The gNB 31 transmits a HO command to the UE 30 (S141). The gNB 31 deletes the security context used in 3GPP Access.
[0119]
　Next, IPsec is established between the UE 30 and the N3IWF 38 (S142). Next, the UE 30 transmits HO complete to the N3IWF 38 (S143). Next, the N3IWF 38 transmits HO notify to the AMF 33 (S144). Next, Bearer and session modification is performed between AMF33, Target SMF34_2, and Target UPF (S145).
[0120]
　Next, a processing flow of Handover intra PLMN from 3GPP to non-3GPP access different from that of FIG. 36 will be described with reference to FIG. In FIG. 37, the process executed in gNB31 of FIG. 36 and the process executed in N3IWF38 are interchanged. Since the other processes are the same as those in FIG. 36, detailed description thereof will be omitted.
[0121]
　Next, the flow of registration processing from 3GPP Access in PLMN 1 to Non-3GPP Access in PLMN 2 when there is no active connection in PLMN 2 will be described using FIG. PLMN1 and PLMN2 indicate that they are different PLMNs. PLMN1 and PLMN2 may be HPLMN or VPLMN.
[0122]
　First, the UE 30 transmits a Registration Request to the Target AMF 33_2 via the N3IWF 38 (S171). Registration Request includes 5G-GUTI, SUCI or SUPI. Further, the Registration Request includes UE security capabilities, Auth-method, AN type, Authentication restrictions, Re-auth type, AV ID, and 5G KSI.
[0123]
　Next, Target AMF33_2 transmits 5G-AIR to AUSF36 (S172). 5G-AIR includes 5G-GUTI, SUCI or SUPI. Furthermore, 5G-AIR includes AV ID and SN name. Next, the AUSF 36 executes de-concealment of SUCI with the UDM 37 in order to obtain a SUPI (Subscription Permanent Identifier) ​​(S173).
[0124]
　Next, the AUSF 36 determines whether a sufficient number of unused AVs are available (S174). If the AUSF 36 determines that a sufficient number of unused AVs are available, the AUSF 36 executes the process of step S176. When the AUSF 36 determines that a sufficient number of unused AVs are not available, the AUSF 36 executes the process of step S175a or S175b.
[0125]
　A step S175a executes Fast re-auth using the security key KAUSF directly used as the security key KSEAF or the security key KSEAF derived from the security key KAUSF. In step S175b, the AUSF 36 executes Full authentication with the UDM 37. A step S176 transmits 5G-AIA to the Target AMF 33_2 (S176). 5G-AIA includes SUPI, SN name, and AVs.
[0126]
　Next, Target AMF33_2 transmits Authentication Request to UE30 (S177). Authentication Request includes RAND and AUTN. Next, the UE 30 derives the security key KSEAF (S178). Next, the UE 30 transmits the Authentication Response to the Target AMF 33_2 (S179). Authentication Response includes RES*.
[0127]
　Next, a flow of registration processing from 3GPP Access in PLMN1 to Non-3GPP Access in PLMN2 when there is no active connection in PLMN2, which is different from FIG. 38, will be described with reference to FIG.
[0128]
　Since step S181 is the same as step S171 of FIG. 38, detailed description thereof will be omitted. Next, the Target AMF 33_2 checks the UE identity (S182). Next, Target AMF33_2 transmits UE identification Request to Source AMF33_1 (S183). The UE identification request includes 5G-GUTI, SUCI, or SUPI. Next, Source AMF33_1 transmits UE identification Response to Target AMF33_2 (S184). The UE identification response includes 5G-GUTI, SUCI, or SUPI, and further includes AUSF ID. The subsequent processing is the same as the processing after step S172 in FIG. 38, and thus detailed description thereof will be omitted.
[0129]
　Next, the flow of handover from 3GPP Access in PLMN1 to Non-3GPP Access in PLMN2 when there is no active connection in PLMN2 will be described using FIG. FIG. 40 shows processing in PLMN1 and processing in PLMN2.
[0130]
　First, the UE 30 transmits a Measurement Report to the gNB 31 (S191). Next, the gNB 31 determines to execute the HO after checking the UE mobility restrictions (S192). Next, the gNB 31 transmits Handover Required to the Source AMF 33_1 (S193). Next, the Source AMF 33_1 derives the security key KSEAF* (S194). Next, Source AMF33_1 transmits Forward Relocation Request to Target AMF33_2 (S195). The Forward Relocation Request includes 5G-GUTI, AUSF I, security key KSEAF*, and UE security capabilities.
[0131]
　Next, the Target AMF 33_2 derives the security key KAMF (S196). Next, the Target AMF 33_2 transmits a Handover Request to the N3IWF 38 (S197). Handover Request includes UE security capabilities and NSSAI.
[0132]
　Next, the N3IWF 38 checks whether the UE 30 supports NSSAI (S198). Next, the N3IWF 38 derives the security key Knon-3gpp (S199). Next, the N3IWF 38 transmits a Handover Request Ack to the Target AMF 33_2 (S200). Next, Target AMF33_2 transmits Forward Relocation Response to Source AMF33_1 (S201). Next, Source AMF33_1 transmits Handover Command to gNB31 (S202). Next, gNB31 transmits Handover Command to UE30 (S203).
[0133]
　Next, the UE 30 derives the security keys KSEAF*, KAMF, and Knon-3gpp (S204). Next, the UE 30 transmits Handover Complete to the N3IWF 38 (S205).
[0134]
　Next, the flow of handover from 3GPP Access in PLMN1 to Non-3GPP Access in PLMN2 when there is no active connection in PLMN2 different from FIG. 40 will be described using FIG. 41 and FIG. FIG. 41 shows processing in PLMN1 and processing in PLMN2.
[0135]
　Steps S211 to S213 are the same as steps S191 to S193 of FIG. 40, and detailed description thereof will be omitted. Next, Source AMF33_1 transmits Relocation Request to AUSF36 (S214). The Relocation Request includes 5G-GUTI, UE security capabilities, and security key KSEAF.
[0136]
　Next, in step S215, the AUSF 36 derives the security key KSEAF. Here, the AUSF 36 refreshes the security key KSEAF as the processing a. Alternatively, the AUSF 36 executes the processing b and subsequent steps. The processing b and c in step S215 and the steps S216a and S216b are the same as the processing a and b in step S174 of FIG. 38 and the steps S175a and S175b, and thus detailed description thereof will be omitted. Further, in step S216b, the security key KSEAF is derived instead of Full authentication.
[0137]
　After the processing b of step 215 and after step S216a or S216b, the AUSF 36 transmits the Forward Relocation Request to the Target AMF 33_2 (S217). The Forward Relocation Request includes the security key KSEAF, SUCI or SUPI, and UE security capabilities.
[0138]
　Next, the Target AMF 33_2 derives the security key KAMF. Next, Target AMF33_2 transmits Handover Request to N3IWF38 (S219).
[0139]
　42, steps S220 to S222 are similar to steps S198 to S200 of FIG. 40, and detailed description thereof will be omitted. Next, the Target AMF 33_2 sends a Forward Relocation Request to the AUSF 36 (S223). Next, the AUSF 36 transmits the Relocation Response to the Source AMF 33_1 (S224).
[0140]
　Steps S225 to S228 are similar to steps S202 to 205 in FIG. 40, and detailed description thereof will be omitted.
[0141]
　Next, the flow of handover from 3GPP Access in PLMN 1 to Non-3GPP Access in PLMN 2 when there is an active connection in PLMN 2 will be described using FIG. Further, gNB31 in PLMN1 is gNB31_1, and gNB in ​​PLMN2 is gNB31_2.
[0142]
　Steps S231 to S234 are the same as steps S211 to S214 of FIG. 41, and detailed description thereof will be omitted. However, in step S234, the Relocation Request includes 5G-GUTI, SUCI, or SUPI, UE security capabilities, and a security key KSEAF.
[0143]
　Next, the AUSF 36 executes de-concealment of SUCI in order to obtain SUPI (Subscription Permanent Identifier) ​​(S235). Next, the AUSF 36 extracts the security key KSEAF or derives the security key KSEAF* for use as a new security key KSEAF (S236).
[0144]
　Next, the AUSF 36 transmits a Forward Relocation Request to the Target AMF 33_2 (S237). The Forward Relocation Request includes a new security key KSEAF, SUCI or SUPI, and UE security capabilities.
[0145]
　Next, the Target AMF 33_2 derives the security key KAMF (S238). Next, the Target AMF 33_2 derives the security key Knon-3gpp (S239). Steps S240 to S248 are similar to step S219 of FIG. 41, step S220 of FIG. 42, and steps S222 to S228, and detailed description thereof will be omitted.
[0146]
　Next, the flow of handover from 3GPP Access in PLMN1 to Non-3GPP Access in PLMN2 when there is an active connection in PLMN2, which is different from FIG. 43, will be described using FIG.
[0147]
　Since steps S251 to S255 are the same as steps S191 to S195 of FIG. 40, detailed description thereof will be omitted. However, in step S255, the Forward Relocation Request includes 5G-GUTI, SUCI, or SUPI, the AUSF ID, the UE security capabilities, and the security key KSEAF*.
[0148]
　Next, Target AMF33_2 extracts the security context corresponding to SUPI or SUCI (S256). Next, the Target AMF 33_2 derives the security key Knon-3gpp (S257).
[0149]
　Since steps S258 to S265 are the same as steps S197, S198, and S200 to S205 in FIG. 40, detailed description thereof will be omitted.
[0150]
　Next, the flow of registration processing from Non-3GPP Access in PLMN1 to 3GPP Access in PLMN2 when there is no active connection in PLMN2 will be described using FIG.
[0151]
　In FIG. 38, the UE 30 transmits a Registration Request to the Target AMF 33_2 via the N3IWF 38. On the other hand, in FIG. 45, in step S271, the UE 30 transmits a Registration Request to the Target AMF 33_2 via the gNB 31. Steps S272 to S279 are similar to steps S172 to S179 of FIG. 38, and detailed description thereof will be omitted.
[0152]
　Next, a flow of registration processing from Non-3GPP Access in PLMN1 to 3GPP Access in PLMN2 when there is no active connection in PLMN2, which is different from FIG. 45, will be described with reference to FIG.
[0153]
　In FIG. 39, the UE 30 transmits a Registration Request to the Target AMF 33_2 via the N3IWF 38. On the other hand, in FIG. 46, in step S281, the UE 30 transmits a Registration Request to the Target AMF 33_2 via the gNB 31. Next, the Target AMF 33_2 checks 5G-GUTI (S282). The processing after step S283 is the same as the processing after step S183 in FIG. 39, and thus detailed description thereof will be omitted.
[0154]
　Next, the flow of handover from Non-3GPP Access in PLMN1 to 3GPP Access in PLMN2 when there is no active connection in PLMN2 will be described using FIG.
[0155]
　Steps S291 to S295 are similar to steps S251 to S255 in FIG. 40, and detailed description thereof will be omitted. However, gNB31 in FIG. 40 is replaced with N3IWF38 in FIG. 47, and N3IWF38 in FIG. 40 is replaced with gNB31 in FIG. The Forward Relocation Request transmitted in step S295 includes 5G-GUTI, AUSF ID, security key KSEAF*, and UE security capabilities.
[0156]
　Next, the Target AMF 33_2 derives the security key KAMF (S296). Next, the Target AMF 33_2 derives the security key KgNB (S297). Steps S298 to S305 are the same as steps S197, S198, and S200 to S205 in FIG. 40, and detailed description thereof will be omitted.
[0157]
　Next, a flow of handover from Non-3GPP Access in PLMN1 to 3GPP Access in PLMN2 when there is no active connection in PLMN2, which is different from FIG. 47, will be described with reference to FIGS.
[0158]
　Steps S311 to S318 are the same as steps S211 to S218 of FIG. 41, and detailed description thereof will be omitted. However, gNB31 in FIG. 41 is replaced with N3IWF38 in FIG. 48, and N3IWF38 in FIG. 41 is replaced with gNB31 in FIG.
[0159]
　Next, the Target AMF 33_2 derives the security key KgNB (S319). Next, turning to FIG. 49, steps S320 to S328 are similar to step S219 of FIG. 41 and step S220 of FIG. 42, and further, steps S222 to S228 of FIG.
[0160]
　Next, the flow of registration processing from Non-3GPP Access in PLMN 1 to 3GPP Access in PLMN 2 when there is an active connection in PLMN 2 will be described using FIG.
[0161]
　Steps S331 to S348 are the same as steps S231 to S248 of FIG. 43, and detailed description thereof will be omitted. However, gNB31_1 and gNB31_2 in FIG. 43 are replaced with N3IWF38_1 and N3IWF38_2 in FIG. Further, N3IWF38 in FIG. 43 is replaced with gNB31 in FIG. Further, in step S339, unlike step S239 in FIG. 43, the Target AMF 33_2 derives the security key KgNB.
[0162]
　Next, the flow of registration processing from Non-3GPP Access in PLMN1 to 3GPP Access in PLMN2 when there is an active connection in PLMN2, which is different from FIG. 50, will be described using FIG.
[0163]
　Steps S351 to S365 are similar to steps S251 to S265 in FIG. 44, and detailed description thereof will be omitted. However, gNB31_1 and gNB31_2 in FIG. 44 are replaced with N3IWF38_1 and N3IWF38_2 in FIG. 51. Furthermore, N3IWF38 in FIG. 44 is replaced with gNB31 in FIG. Further, in step S357, unlike step S257 in FIG. 44, the Target AMF 33_2 derives the security key KgNB.
[0164]
　As described above, by executing the authentication processing according to the third embodiment, it is possible to execute handover between different PLMNs.
[0165]
　(Embodiment 4)
　Next, a flow of processing of UE initiated HO intra PLMN, intra AMF from 3GPP to non-3GPP Access will be described with reference to FIG.
[0166]
　First, the UE 30 transmits Registration request via non-3GPP access to the AMF 33 via the N3IWF 38 (S371). The AMF 33 is also an AMF to which the UE 30 connects via 3GPP access. Registration request via non-3GPP access includes UE's identity and UE's capabilities such as GUTI.
[0167]
　Here, a case where the NAS security keys used in 3GPP access are different from the NAS security keys used in Non-3GPP access will be described. In this case, the Registration request via non-3GPP access is protected by the NAS security keys used in Non-3GPP access. The NAS security keys have already been derived in the UE 30 and the AMF 33.
[0168]
　Also, the NAS security keys used in 3GPP access may be the same as the NAS security keys used in Non-3GPP access. In this case, the Registration request via non-3GPP access is protected by the NAS security keys already used in 3GPP access.
[0169]
　Next, the AMF 33 checks whether the UE's capabilities including the security capabilities are valid and whether the UE 30 has the right to access the core network via the N3IWF 38 (S372). The AMF 33 may request the AUSF 36 for information regarding UE's capabilities and access rights.
[0170]
　Next, the AMF 33 derives the security key Knon-3gpp used in Non-3GPP access (S373).
[0171]
　Next, the AMF 33 transmits a Registration request response to the UE 30 via the N3IWF 38 (S374). The Registration request response contains the identification information of the security key such as security key Knon-3gpp, KSI (Key Set Identifier), information indicating whether security configurations for encryption and integrity protection are required, and the algorithm used. ..
[0172]
　Next, IPsec is established between the UE 30 and the N3IWF 38 by using the security key Knon-3gpp (S375). The UE 30 derives the security key Knon-3gpp from the security key KAMF. Further, the UE 30 transmits Registration complete to the AMF 33 via the N3IWF 38 (S376). Next, a PDU session for Non-3GPP access is established between the UE 30 and the UPF 35 (S377). Security is established between the UE 30 and the N3IWF 38 using IPsec with the security key Knon-3gpp.
[0173]
　Next, the Security context including the security key used between the UE 30 and the gNB 31 is deleted (S378). The UE 30 or the AMF 33 may send a request message to the gNB 31 to delete the Security context.
[0174]
　Next, a flow of processing of UE initiated HO intra PLMN, intra AMF from 3GPP to non-3GPP Access different from that of FIG. 52 will be described with reference to FIG. 53.
[0175]
　First, the UE 30 transmits an HO request to the AMF 33 via the gNB 31 (S381). The HO request contains the N3IWF ID. Steps S382 to S388 are the same as steps S372 to S378 in FIG. 52, and detailed description thereof will be omitted. However, in step S384, an HO response is transmitted instead of the Registration request responsen in step S374 of FIG. Further, in step S386, HO complete is transmitted instead of Registration complete in step S376 of FIG.
[0176]
　Subsequently, a flow of processing of UE initiated HO intra PLMN, inter AMF from 3GPP to non-3GPP Access will be described with reference to FIG. 54.
[0177]
　First, the UE 30 transmits a Registration request via non-3GPP access to the Target AMF 33_2 via the N3IWF 38 (S391). Next, Target AMF33_2 transmits UE context request to Source AMF33_1 (S392). Next, Source AMF33_1 transmits UE context response containing UE's security capabilities regarding UE30 to Target AMF33_2 (S393). Steps S394 to S400 are similar to steps S372 to S378 in FIG. 52, and detailed description thereof will be omitted.
[0178]
　Next, a processing flow of Network initiated HO intra PLMN, inter AMF, from 3GPP to non-3GPP access will be described with reference to FIG. 55. Steps S411 to S414 are similar to steps S151 to S154 of FIG. 37, and detailed description thereof will be omitted.
[0179]
　Next, the Source AMF 33_1 updates the security key KAMF (S415). Next, Source AMF33_1 transmits Relocation request to Target AMF33_2 (S416). Next, Target AMF33_2 checks whether UE's capabilities regarding UE30 are effective in determining whether to transmit a HO request (S417). UE's capabilities include security capabilities and access right to the N3IWF 38. Next, the Target AMF 33_2 derives a security key (S418).
[0180]
　Steps S419 to S422 are the same as steps S156 to 159 of FIG. 37, and detailed description thereof will be omitted. Next, Target AMF33_2 transmits Relocation response to Source AMF33_1 (S423). Steps S424 to S428 are similar to steps S160 to S164 of FIG. 37, and detailed description thereof will be omitted.
[0181]
　Subsequently, a flow of processing of UE initiated HO intra PLMN, intra AMF from non-3GPP to 3GPP access will be described with reference to FIG. Steps S431 to S437 are the same as steps S391, S394 to S396, and S398 to S400 in FIG. 54, and detailed description thereof will be omitted. However, in FIG. 56, the message between the UE 30 and the AMF 33 is transmitted via the gNB 31 instead of the N3IWF 38. Further, in step S435, the UE 30 derives the security key KgNB from the security key KAMF. Moreover, the security between the UE 30 and the gNB 31 is established.
[0182]
　Next, a flow of processing of UE initiated HO intra PLMN, intra AMF from non-3GPP to 3GPP access, which is different from that of FIG. 56, will be described with reference to FIG. 57. First, the UE 30 transmits a HO request to the AMF 33 via the N3IWF 38 (S441). The HO request contains the gNB ID. Steps S442 and S443 are similar to steps S432 and S433 in FIG. 56, and thus detailed description thereof will be omitted.
[0183]
　Next, the AMF 33 transmits the HO response to the UE 30 via the gNB 31 (S444). Next, the UE 30 transmits HO complete to the AMF 33 via the gNB 31 (S445). Steps S446 and S447 are similar to steps S436 and S437 of FIG. 56, and thus detailed description thereof will be omitted.
[0184]
　Subsequently, a flow of processing of UE initiated HO intra PLMN, intra AMF from non-3GPP to 3GPP access will be described with reference to FIG. 54. Since steps S451 to S459 are similar to the processing executed in FIG. 54 except that the processing in step S397 in FIG. 54 is omitted, detailed description thereof will be omitted.
[0185]
　Next, a processing flow of Network Initiated HO intra PLMN, intra AMF from non-3GPP to 3GPP access will be described with reference to FIG. Steps S461 to S474 are the same as steps S151 to S164 of FIG. 37, and detailed description thereof will be omitted. However, in step S465, the AMF 33 derives the security key Knon-3gpp, unlike the case where the security key KgNB is derived in step S155.
[0186]
　Next, a processing flow of Network Initiated HO intra PLMN, intra AMF from non-3GPP to 3GPP access will be described with reference to FIG. In FIG. 60, the process executed in gNB31 of FIG. 55 and the process executed in N3IWF38 are interchanged. The other processes are the same as those in FIG. 55, and detailed description thereof will be omitted.
[0187]
　As described above, in the fourth embodiment, handover between the same PLMNs can be executed.
[0188]
　Subsequently, a configuration example of the communication terminal 10 and the core network device 20 described in the above-described embodiments will be described below.
[0189]
　FIG. 61 is a block diagram showing a configuration example of the communication terminal 10. Radio Frequency (RF) transceiver 1101 performs analog RF signal processing to communicate with AN 50. The analog RF signal processing performed by the RF transceiver 1101 includes frequency up conversion, frequency down conversion, and amplification. The RF transceiver 1101 is coupled with the antenna 1102 and the baseband processor 1103. That is, the RF transceiver 1101 receives the modulation symbol data from the baseband processor 1103, generates a transmission RF signal, and supplies the transmission RF signal to the antenna 1102. The modulation symbol data may be OFDM (Orthogonal Frequency Division Multiplexing) symbol data. The RF transceiver 1101 also generates a baseband reception signal based on the reception RF signal received by the antenna 1102, and supplies this to the baseband processor 1103.
[0190]
　The baseband processor 1103 performs digital baseband signal processing (data plane processing) and control plane processing for wireless communication. Digital baseband signal processing includes (a) data compression/decompression, (b) data segmentation/concatenation, and (c) transmission format (transmission frame) generation/decomposition. Further, digital baseband signal processing includes (d) channel coding/decoding, and (e) modulation (symbol mapping)/demodulation. Further, digital baseband signal processing includes generation of (f) Inverse Fast Fourier Transform (IFFT) OFDM symbol data (baseband OFDM signal). On the other hand, the control plane processing includes communication management of layer 1, layer 2, and layer 3. Layer 1 is, for example, transmission power control. Layer 2 is, for example, radio resource management and hybrid automatic repeat request (HARQ) processing. Layer 3, for example, is signaling for attach, mobility, and call management.
[0191]
　For example, in LTE and LTE-Advanced, digital baseband signal processing by the baseband processor 1103 includes signal processing of Packet Data Convergence Protocol (PDCP) layer, Radio Link Control (RLC) layer, MAC layer, and PHY layer. But it's okay. Further, the control plane processing by the baseband processor 1103 may include processing of Non-Access Stratum (NAS) protocol, RRC protocol, and MAC CE.
[0192]
　The baseband processor 1103 may include a modem processor that performs digital baseband signal processing and a protocol stack processor that performs control plane processing. The modem processor is, for example, a Digital Signal Processor (DSP). The protocol stack processor that performs control plane processing is, for example, a Central Processing Unit (CPU) or a Micro Processing Unit (MPU). In this case, the protocol stack processor that performs the control plane process may be shared with the application processor 1104 described later.
[0193]
　The application processor 1104 is also called a CPU, MPU, microprocessor, or processor core. The application processor 1104 may include a plurality of processors (a plurality of processor cores). The application processor 1104 realizes various functions of the communication terminal 10 by executing the system software program and various application programs read from the memory 1106 or a memory (not shown). The system software program may be, for example, an operating system (OS). The application program may be, for example, a call application, a WEB browser, a mailer, a camera operation application, or a music reproduction application.
[0194]
　In some implementations, the baseband processor 1103 and the application processor 1104 may be integrated on a single chip, as indicated by the dashed line (1105) in FIG. In other words, the baseband processor 1103 and the application processor 1104 may be implemented as one System on Chip (SoC) device 1105. SoC devices are also referred to as system Large Scale Integration (LSI) or chipsets.
[0195]
　The memory 1106 is a volatile memory or a non-volatile memory or a combination thereof. Memory 1106 may include multiple physically independent memory devices. The volatile memory is, for example, Static Random Access Memory (SRAM) or Dynamic RAM (DRAM), or a combination thereof. The non-volatile memory is a mask Read Only Memory (MROM), Electrically Erasable Programmable ROM (EEPROM), flash memory, hard disk drive, or any combination thereof. For example, the memory 1106 may include a baseband processor 1103, an application processor 1104, and an external memory device accessible by the SoC 1105. Memory 1106 may include embedded memory devices integrated within baseband processor 1103, application processor 1104, or SoC 1105. Further, the memory 1106 may include a memory in a Universal Integrated Circuit Card (UICC).
[0196]
　The memory 1106 may store a software module (computer program) including a command group and data for performing processing by the communication terminal 10 described in the above-described embodiments. In some implementations, the baseband processor 1103 or the application processor 1104 may be configured to perform the processing of the communication terminal 10 described in the above embodiments by reading the software module from the memory 1106 and executing the software module. Good.
[0197]
　FIG. 62 is a block diagram showing a configuration example of the core network device 20. Referring to FIG. 62, the core network device 20 includes a network interface 1201, a processor 1202, and a memory 1203. The network interface 1201 is used to communicate with a network node (eg, AN50, SMF30, etc.). The network interface 1201 may include, for example, a network interface card (NIC) compliant with IEEE (Insititute of Electrical and Electronics Engineers) 802.3 series.
[0198]
　The processor 1202 reads the software (computer program) from the memory 1203 and executes the software to perform the processing of the AMF 20 described using the sequence diagram and the flowchart in the above-described embodiment. The processor 1202 may be, for example, a microprocessor, MPU, or CPU. The processor 1202 may include multiple processors.
[0199]
　The memory 1203 is composed of a combination of a volatile memory and a non-volatile memory. Memory 1203 may include storage located remotely from processor 1202. In this case, the processor 1202 may access the memory 1203 via an I/O interface (not shown).
[0200]
　In the example of FIG. 62, the memory 1203 is used to store the software module group. The processor 1202 can perform the processing of the AMF 20 described in the above embodiment by reading these software modules from the memory 1203 and executing them.
[0201]
　As described with reference to FIGS. 61 and 62, each of the processors included in the communication terminal 10 and the core network device 20 in the above-described embodiment has a group of instructions for causing a computer to execute the algorithm described with reference to the drawings. Execute one or more programs including. This program can be stored using various types of non-transitory computer readable media, and can be supplied to a computer. Non-transitory computer readable media include various types of tangible storage media. Examples of non-transitory computer readable media include magnetic recording media, magneto-optical recording media (eg magneto-optical disks), Compact Disc Read Only Memory (CD-ROM), CD-R, CD-R/W, semiconductor memory. Including. The magnetic recording medium may be a flexible disk, a magnetic tape, or a hard disk drive. The semiconductor memory may be, for example, a mask ROM, a Programmable ROM (PROM), an Erasable PROM (EPROM), a flash ROM, or a Random Access Memory (RAM). For example, the program may also be supplied to the computer by various types of transitory computer readable media. Examples of transitory computer-readable media include electrical signals, optical signals, and electromagnetic waves. The transitory computer readable medium can supply the program to the computer via a wired communication path such as an electric wire and an optical fiber, or a wireless communication path.
[0202]
　It should be noted that the present disclosure is not limited to the above-described embodiment, and can be modified as appropriate without departing from the spirit of the present invention. Further, the present disclosure may be implemented by appropriately combining the respective embodiments.
[0203]
　Although the present invention has been described with reference to the exemplary embodiments, the present invention is not limited to the above. Various modifications that can be understood by those skilled in the art can be made to the configuration and details of the present invention within the scope of the invention.
[0204]
　This application claims priority based on Indian application 201711034337, filed September 27, 2017, and incorporates all of its disclosures here.
[0205]
　The whole or part of the exemplary embodiments disclosed above can be described as, but not limited to, the following supplementary notes.
　(Supplementary
　Note 1)
　A message transmitted using a protocol defined between a communication unit that communicates with a gateway device arranged in the preceding stage of a core network device via Untrusted Non-3GPP Access and the core network device. A key derivation unit for deriving a second security key used for security processing of a message transmitted using a protocol defined with the gateway device from a first security key used for security processing of A communication terminal including.
　(Supplementary Note 2) The
　communication unit
　communicates with the first gateway device arranged in the preceding stage of the core network device via the Untrusted Non-3GPP Access, and the Untrusted Non-3GPP Access or the Untrusted Non-3GPP It communicates with a second gateway device arranged in front of the core network device through an Untrusted Non-3GPP Access different from Access, and the
　key derivation unit uses
　the second security key that is different for each gateway device. The communication terminal according to Appendix 1, which is derived.
　(Supplementary Note 3) The
　key derivation unit
　The communication terminal according to appendix 1 or 2, wherein the second security key is derived using identification information of an access network.
　(Supplementary Note 4) The
　key derivation unit stores a
　third security key used for security processing of a NAS message transmitted to and from the core network device via the Untrusted Non-3GPP Access and the gateway device. 4. The communication terminal according to any one of appendices 1 to 3, which is derived from the first security key.
　(Supplementary Note 5) The
　communication unit
　communicates with the first gateway device arranged in the preceding stage of the core network device through the Untrusted Non-3GPP Access, and the Untrusted Non-3GPP Access or the Untrusted Non-3GPP It communicates with a second gateway device arranged in front of the core network device through an Untrusted Non-3GPP Access different from Access, and the
　key derivation unit is configured to communicate with
　the third security key that is different for each gateway device. The communication terminal according to Appendix 4, which derives
　(Supplementary
　note 6)
　The communication terminal according to supplementary note 4 or 5, wherein the key derivation unit derives the third security key using identification information of an access network.
　(Appendix 7)
　A communication unit that communicates with a communication terminal via a gateway device and Untrusted Non-3GPP Access arranged in the preceding stage of the core network device, and
　security of messages transmitted using a protocol defined between the communication terminal A key derivation unit that derives a second security key used for security processing of a message transmitted using a protocol defined between the communication terminal and the gateway device from a first security key used for processing. And a core network device comprising.
　(Supplementary Note 8) The
　communication unit
　communicates with the communication terminal via a first gateway device and the Untrusted Non-3GPP Access, and further, a second gateway device and the Untrusted Non-3GPP Access or the Untrusted Non-GP. 　The core network device according to appendix 7 ,
　wherein the key derivation unit communicates with the communication terminal via Untrusted Non-3GPP Access different from 3GPP Access, and the key derivation unit derives
the second security key different for each gateway device.
　(Supplementary
　note 9)
　The core network device according to supplementary note 7 or 8, wherein the key derivation unit derives the second security key using identification information of an access network.
　(Supplementary Note 10) The
　key derivation unit
　Supplementary Note 7: A third security key used for security processing of a NAS message transmitted between the gateway device and the communication terminal via the Untrusted Non-3GPP Access is derived from the first security key. 10. The core network device according to any one of items 1 to 9.
　(Supplementary Note 11) The
　communication unit
　communicates with the communication terminal via a first gateway device and the Untrusted Non-3GPP Access, and further, a second gateway device and the Untrusted Non-3GPP Access or the Untrusted Non-Access. 　The core network device according to appendix 10 ,
　wherein the key derivation unit communicates with the communication terminal via Untrusted Non-3GPP Access different from 3GPP Access, and the key derivation unit derives
the third security key that is different for each gateway device. ..
　(Supplementary
　note 12)
　The core network device according to supplementary note 10 or 11, wherein the key derivation unit derives the third security key using identification information of an access network.
　(Supplementary
　note 13) Communicates with the gateway device arranged in front of the core network device through Untrusted Non-3GPP Access,
　A message transmitted from the first security key used for security processing of a message transmitted using the protocol defined with the core network device, and a message transmitted with the protocol defined with the gateway device. Key derivation method for deriving a second security key used for the security processing of the.
　(Supplementary Note 14) 　A message
　that communicates with a communication terminal via a gateway device and an Untrusted Non-3GPP Access that are arranged in front of the core network device and that is
transmitted using a protocol defined between the communication terminal and the communication terminal. A key for deriving a second security key used for security processing of a message transmitted using a protocol defined between the communication terminal and the gateway device from a first security key used for security processing Derivation method.
　(Supplementary Note 15)
　A communication unit for accessing a network node via a first type access and a second type
　access, a first NAS connection for the first type access, and a first NAS connection for the second type access. 2 NAS connection, and a control unit for establishing with the network node in the network, the
　parameters specific to each NAS connection are used to realize independent NAS security, and the parameters are the same as those of
　the first type. A communication terminal including a value associated with a unique NAS connection identifier for access and said second type of access.
　(Supplementary note 16)
　A registration unit for registering a communication terminal via a first type access and a second type
　access, a first NAS connection for the first type access and a first NAS connection for the second type access. A communication unit having
　two NAS connections, a control unit for invoking a NAS SMC (Security Mode Command) process via the second type access,
　and a message including an indicator during the NAS SMC process is transmitted to the communication terminal. A core network node comprising a transmitter.
　(Supplementary Note 17)
　A key derivation unit that derives an EMSK (Extended Master Session Key) during EAP-TLS (Extended Master Session Key) authentication processing, and
　a control unit that uses the EMSK to derive a security key. A communication terminal equipped with.
　(Supplementary Note 18)
　An acquisition unit that acquires an EMSK (Extended Master Session Key) during EAP-TLS (Extended Master Session Key) authentication processing, and
　a control unit that uses the EMSK to derive a security key. , Core network nodes.
　(Appendix 19)
　A communication unit for accessing the first network node via the first type access and accessing the second network node for the second
　type access, a first NAS connection for the first type access, and the first NAS connection for the first type access. A connection establishment unit that establishes a second NAS connection for two types of access with the first and second network nodes, and a
　different security context is used for each network node, and each security context is established separately. A communication terminal, comprising: a controller.
　(Supplementary Note 20)
　The communication terminal according to Supplementary Note 19, wherein the first and second network nodes belong to different networks.
　(Supplementary note 21) 　The communication terminal according to Supplementary note 15 or 19,
　wherein the first type of access is 3GPP access and
the second type of access is non-3GPP access.
　(Supplementary note 22)
　A communication terminal
　comprising: a communication unit that transmits a registration request message to a network node; and a key derivation unit that derives a security key using a parameter related to an access type after transmitting the registration request message.
　(Supplementary
　note 23) The communication terminal according to supplementary note 22, wherein the security key is derived using a KDF (Key Derivation Function) to which a parameter related to the access type is input.
　(Supplementary Note 24) A 　network node comprising:
　a communication unit that receives a registration request message from a communication terminal; and
a key derivation unit that derives a security key using a parameter related to an access type after receiving the registration request message.
　(Supplementary
　note 25) The network node according to supplementary note 24, wherein the security key is derived using a KDF (Key Derivation Function) to which a parameter related to the access type is input.
[0206]
　10 the communication terminal
　11 the communication unit
　12 key derivation unit
　20 core network device
　21 communication section
　22 key derivation unit
　30 UE
　31 GNb
　31_1 GNb
　31_2 GNb
　32 3GPP Access
　33 AMF
　33_1 Source AMF
　33_2 Target AMF
　34 SMF
　34_1 Source SMF
　34_2 Target SMF
　35 UPF
　36 AUSF
　37 UDM
　38 N3IWF
　39 Data Network
　40 Untrusted Non-3GPP Access
　51 AMF
　52 SMF
　53 UPF
　54 N3IWF
　55 Data Network
　61 gNB
　62 3GPP Access
　63 AMF
　64 N3IWF
　65 Non-3GPP Access
　71 N3IWF
　72 Non-3GPP Access
　73 AMF
The scope of the claims
[Claim 1]
　For
　the security processing of the message transmitted using the protocol defined between the communication unit that communicates with the gateway device arranged in the preceding stage of the core network device via Untrusted Non-3GPP Access, and the core network device. A communication terminal comprising: a first security key used; and a key derivation unit that derives a second security key used for security processing of a message transmitted using a protocol defined with the gateway device. ..
[Claim 2]
　The communication unit
　communicates with the first gateway device arranged in front of the core network device via the Untrusted Non-3GPP Access, and is different from the Untrusted Non-3GPP Access or the Untrusted Non-3GPP Access. A method of communicating via a Untrusted Non-3GPP Access with a second gateway device arranged in front of the core network device,
　wherein the key derivation unit derives
　the second security key that is different for each gateway device. Item 1. The communication terminal according to Item 1.
[Claim 3]

　The communication terminal according to claim 1, 　wherein the key derivation unit derives the second security key using identification information of an access network.
[Claim 4]
　The key derivation unit uses a
　third security key used for security processing of a NAS message transmitted between the Untrusted Non-3GPP Access and the core network device via the gateway device as the first security key. The communication terminal according to claim 1, wherein the communication terminal is derived from a key.
[Claim 5]
　The communication unit
　communicates with the first gateway device arranged in front of the core network device via the Untrusted Non-3GPP Access, and is different from the Untrusted Non-3GPP Access or the Untrusted Non-3GPP Access. Communicating with a second gateway device arranged in front of the core network device via Untrusted Non-3GPP Access, and the
　key derivation unit derives
　the third security key that is different for each gateway device, The communication terminal according to claim 4.
[Claim 6]

　The communication terminal according to claim 4, 　wherein the key derivation unit derives the third security key using identification information of an access network.
[Claim 7]
　A communication unit that communicates with a communication terminal via a gateway device and Untrusted Non-3GPP Access arranged in the preceding stage of the core network device, and
　security of messages transmitted using a protocol defined between the communication terminal A key derivation unit that derives a second security key used for security processing of a message transmitted using a protocol defined between the communication terminal and the gateway device from a first security key used for processing. And a core network device comprising.
[Claim 8]
　The communication unit
　communicates with the communication terminal via a first gateway device and the Untrusted Non-3GPP Access, and further, the second gateway device and the Untrusted Non-3GPP Access or the Untrusted Non-3GPP Access. 　The core network device according to claim 7 ,
　wherein the key derivation unit communicates with the communication terminal via different Untrusted Non-3GPP Access, and the key derivation unit derives
the second security key different for each gateway device.
[Claim 9]
　9.
　The core network device according to claim 7, wherein the key derivation unit derives the second security key using identification information of an access network.
[Claim 10]
　The key derivation unit uses a
　third security key used for security processing of a NAS message transmitted between the gateway device and the communication terminal via the Untrusted Non-3GPP Access as the first security key. The core network device according to any one of claims 7 to 9, which is derived from the above.
[Claim 11]
　The communication unit
　communicates with the communication terminal via the first gateway device and the Untrusted Non-3GPP Access, and further, the second gateway device and the Untrusted Non-3GPP Access or the Untrusted Non-3GPP Access. 　The core network device according to claim 10 ,
　wherein the key derivation unit communicates with the communication terminal via different Untrusted Non-3GPP Access, and the key derivation unit derives
the third security key different for each gateway device.
[Claim 12]

　The core network device according to claim 10 or 11, 　wherein the key derivation unit derives the third security key using identification information of an access network.
[Claim 13]

　It is used for security processing of a message 　that communicates with a gateway device arranged in the preceding stage of the core network device via Untrusted Non-3GPP Access and is transmitted using a protocol defined with the core network device. A key derivation method for deriving a second security key used for security processing of a message transmitted using the protocol defined with the gateway device from the first security key.
[Claim 14]

　Used for security processing of messages transmitted by 　communicating with a communication terminal via a gateway device and Untrusted Non-3GPP Access arranged in front of the core network device and using a protocol defined with the communication terminal. A key derivation method for deriving a second security key used for security processing of a message transmitted using a protocol defined between the communication terminal and the gateway device from the first security key.
[Claim 15]
　A communication unit for accessing a network node via a first type access and a second type
　access; a first NAS connection for the first type access and a second NAS connection for the second type access;
　A parameter specific to each NAS connection is used to realize independent NAS security , comprising the network node in the network and a controller to establish the parameter, and the
　parameter is the access of the first type and the first type. A communication terminal that includes a value associated with a unique NAS connection identifier for two types of access.
[Claim 16]
　It has a registration unit for registering a communication terminal via a first type access and a second type
　access, a first NAS connection for the first type access and a second NAS connection for the second type access. A communication unit,
　a control unit for activating a NAS SMC (Security Mode Command) process via the second type access, and
　a transmission unit for transmitting a message including an indicator to the communication terminal during the NAS SMC process; A core network node.
[Claim 17]
　A
　communication terminal comprising: a key derivation unit that derives an EMSK (Extended Master Session Key) during EAP-TLS (Extended Master Session Key) authentication processing; and a control unit that uses the EMSK for derivation of a security key. ..
[Claim 18]
　A
　core network node including an acquisition unit that acquires an EMSK (Extended Master Session Key) during EAP-TLS (Extended Master Session Key) authentication processing, and a control unit that uses the EMSK to derive a security key. ..
[Claim 19]
　A communication unit for accessing the first network node via the first type access and accessing the second network node for the second
　type access, a first NAS connection for the first type access, and the first NAS connection for the first type access. A connection establishing unit that establishes a second NAS connection for two types of access with the first and second network nodes, and a
　different security context is used for each network node, and each security context is established separately. A communication terminal, comprising: a controller.
[Claim 20]
　The communication terminal according to claim 19, wherein the first and second network nodes belong to different networks.
[Claim 21]

　The communication terminal according to claim 15 or 19, 　wherein the first type access is 3GPP access, and the second type access is non-3GPP access.
[Claim 22]
　A communication terminal
　comprising: a communication unit for transmitting a registration request message to a network node; and a key derivation unit for deriving a security key using a parameter related to an access type after transmitting the registration request message.
[Claim 23]
　The communication terminal according to claim 22, wherein the security key is derived by using a KDF (Key Derivation Function) to which a parameter related to the access type is input.
[Claim 24]
　A
　network node comprising: a communication unit that receives a registration request message from a communication terminal; and a key derivation unit that derives a security key using a parameter related to an access type after receiving the registration request message.
[Claim 25]
　The network node according to claim 24, wherein the security key is derived using a KDF (Key Derivation Function) into which a parameter related to the access type is input.