Supporting remote unit re-authentication

Abstract

Apparatus, methods, and systems are disclosed for supporting remote unit reauthentication. One apparatus (700) includes a network interface (740) that receives (905) a first authentication message for reauthenticating a remote unit and a processor (705) that validates (910) a first domain name. The first domain name identifies a key management domain name and an associated gateway function that holds a reauthentication security context. Here, the first authentication message includes a NAI that includes a first username and the first domain name. The processor (705) verifies (915) the first authentication message using at least the first username and generates (920) a second authentication message in response to successfully verifying the first authentication message. Via the network interface (740), the processor (705) responds (925) to the first authentication message by sending the second authentication message.

Description

TECHNICAL FIELD

[0001] The subject matter disclosed herein relates generally to supporting re-authentication of a UE with a trusted non-3GPP gateway function ("TNGF"). BACKGROUND

[0002] The following abbreviations and acronyms are herewith defined, at least some of which are referred to within the following description.

[0003] 3GPP ("3rd Generation Partnership Project"), 5G Core Network ("5GC"), 5G Access Network ("5G-AN"), Access and Mobility Management Function ("AMF"), Access Point Name ("APN"), Access Layer ("AS"), Access Network Information ("ANI"), Application Programming Interface ("API"), Authentication and Key Protocol ("AKA"), Authentication Server Function ("AUSF"), Authentication Token ("AUTN"), Authentication Vector ("AV"), Transformed Authentication Vector ("AV"), Data Network Name ("DNN"), Downlink ("DL"), Enhanced Mobile Broadband ("eMBB"), Evolved Node B ("eNB"), Evolved Packet Core ("EPC"), Evolved UMTS Terrestrial Radio Access Network ("E-UTRAN"), Extended Master Session Key ("EMSK"), Extensible Authentication Protocol ("EAP"), EAP Re-authentication Protocol ("ERP"), Globally Unique Temporary UE Identifier (GUID) Home Network Identifier (“GUTI”), Home Subscriber Server (“HSS”), Internet Key Exchange (“IKE”), Internet Key Exchange Version 2 (“IKEv2”), Internet Protocol (“IP”), IP Key Exchange (“IPX”), IP Multimedia Subsystem (“IMS”, also known as “IP Multimedia Core Subsystem”), IP Security (“IPsec”, which refers to protocols, algorithms, and key management methods), Inter-PLMN User Plane Security (“IPUPS”), Long Term Evolution (“LTE”), LTE-A Advanced (“LTE-A”), Master Session Key (“MSK”), Media Access Control (“MAC”), Mobile Network Operator (“MNO”), Mobility Management Entity (“MME”), Non-Access Stratum (“NAS”), Narrowband (“NB”), Network Functions (“NF”), Network Access Identifier (“NAI”), Next Generation (e.g., 5G) Node B (“gNB”), Next Generation (i.e., 5G)Fifth Generation) Radio Access Network (“NG-RAN”), New Radio (“NR”), Policy Control Function (“PCF”), Packet Data Network (“PDN”), Packet Data Unit (“PDU”), PDN Gateway (“PGW”), Public Land Mobile Network (“PLMN”), Quality of Service (“QoS”), Radio Access Network (“RAN”), Radio Access Technology (“RAT”), Radio Resource Control (“RRC”), Receive (“Rx”), Reauthentication Integrity Key (“rIK”), Reauthentication Master Session Key (“rMSK”), Reauthentication Root Key (“rRK”), Security Anchor Function (“SEAF”), Security Mode Command (“SMC”), Single-Network Slice Selection Assistance Information (“S-NSSAI”), Serving Gateway (“SGW”), Serving Network Identifier (“SN Id”), Serving Network Name (“SNN”), Sequence Number (“SEQ”), Session Management Function (“SMF”), Subscription Concealed Identifier (“SUCI”), Subscription Permanent Identifier (“SUPI”), Subscription Identifier Deconcealing Function (“SIDF”), Transmission Control Protocol (“TCP”), Transmit (“Tx”), Trusted Non-3GPP Access Network (“TNAN”), Trusted Non-3GPP Access Point (“TNAP”), Trusted Non-3GPP Gateway Function (“TNGF”), Unified Data Management (“UDM”), Unified Data Repository (“UDR”), User Entity / Equipment (Mobile Terminal) (“UE”), Uplink (“UL”), User Plane (“UP”), User Plane Function (“UPF”), Universal Mobile Telecommunication System (“UMTS”), Universal Subscriber Identity Module (“USIM”), User Datagram Protocol (“UDP”), User Location Information (“ULI”), Wireless Local Area Network (“WLAN”), Worldwide Interoperability for Microwave Access (“WiMAX”), and Expected Response (“XRES”).

[0004] In certain embodiments, a UE can access a 5G Core (“5GC”) network via a gateway function in a Trusted Non-3GPP Access Network (“TNAN”). SUMMARY

[0005] A method of a UE, e.g., to support remote unit reauthentication, includes sending a first authentication message to a network function to authenticate a remote unit with a mobile communication network and receiving a second authentication message from the network function in response to the first authentication message. Here, the first authentication message contains an indicator that the remote unit supports an EAP Reauthentication Protocol ("ERP") and the second authentication message contains a key management domain name that indicates a set of network functions that are capable of sharing a reauthentication security context of a device for performing the ERP. The method includes deriving a reauthentication security context in response to a successful authentication with the mobile communication network and locally storing the received key management domain name and the derived reauthentication security context for subsequent reauthentication with the mobile communication network.

[0006] A method of a TNGF, e.g., to support remote unit reauthentication, includes receiving a first authentication message for reauthenticating a remote unit. Here, the first authentication message includes a NAI that contains a first username and a first domain name, where the first username includes a key identifier. The method includes verifying the first authentication message using at least a reauthentication integrity key (rIK) from a security context identified by the first username. Here, the first domain name identifies a key management domain name and associated network functions that hold a reauthentication security context. The method includes generating a second authentication message in response to successfully verifying the first authentication message and responding to the first authentication message by sending the second authentication message.

[0007] A method of a target TNGF, e.g., to support remote unit reauthentication, includes receiving a first authentication message for reauthenticating a remote unit. Here, the first authentication message includes a NAI that contains a first username and a first domain name, where the first username includes a key identifier. The method includes verifying the first domain name and determining from TNGF identification information indicated as part of the first domain name and the first username that a reauthentication security context for the remote unit is held by a source gateway function. Here, the first domain name identifies a key management domain name and associated network functions that hold a reauthentication security context. The method includes forwarding the first authentication message to the source gateway function and receiving the reauthentication security context from the source gateway function. The method includes generating a second authentication message in response to receiving the reauthentication security context and sending the second authentication message to the remote unit.

[0008] One method of TNAP, e.g., to support remote unit reauthentication, includes receiving a first key management domain name from a gateway function during association between an access point and the gateway function, the key management domain name forwarded to a remote unit for reauthentication. The method includes receiving a first authentication message for reauthentication of the remote unit and determining that the key management domain name does not match. Here, the first authentication message includes a key management domain name non-match indicator or a NAI containing a first username and a first domain name, where the first domain name identifies a second key management domain name and an associated gateway function that holds a reauthentication security context for the remote unit. The method includes rejecting reauthentication of the remote unit in response to the determined non-match and triggering an initial authentication by the remote unit in response to the rejected reauthentication. BRIEF DESCRIPTION OF DRAWINGS

[0009] A more particular description of the embodiments briefly described above will be rendered by reference to specific embodiments illustrated in the drawings. It is to be understood that these drawings are only a depiction and as such are not to be considered limiting of the scope, which will be described and explained with additional specificity and detail by the use of the accompanying drawings in which:

[0010] Figure 1 is a block diagram illustrating one embodiment of a wireless communication system to support remote unit reauthentication;

[0011] Figure 2A is a signal flow diagram illustrating one embodiment of a 5G registration procedure over a trusted non-3GPP access network;

[0012] Figure 2B is Figure 2A a continuation of the process depicted in

[0013] Figure 2C is Figure 2B a continuation of the process depicted in

[0014] Figure 3A is a signal flow diagram illustrating one embodiment of a first solution for remote unit reauthentication;

[0015] Figure 3B is Figure 3A a continuation of the process depicted in

[0016] Figure 4A is a signal flow diagram illustrating one embodiment of a second solution for remote unit reauthentication;

[0017] Figure 4B is Figure 4A a continuation of the process depicted in

[0018] Figure 4C is Figure 4Bcontinuation of the process depicted;

[0019] Figure 5 is a signal flow diagram illustrating one embodiment of a third solution for remote unit reauthentication;

[0020] Figure 6 is a block diagram illustrating one embodiment of a user equipment device that supports remote unit reauthentication;

[0021] Figure 7 is a block diagram illustrating one embodiment of a network equipment device that supports remote unit reauthentication;

[0022] Figure 8 is a flow diagram illustrating one embodiment of a first method for supporting remote unit reauthentication;

[0023] Figure 9 is a flow diagram illustrating one embodiment of a second method for supporting remote unit reauthentication;

[0024] Figure 10 is a flow diagram illustrating one embodiment of a third method for supporting remote unit reauthentication; and

[0025] Figure 11 is a flow diagram illustrating one embodiment of a fourth method for supporting remote unit reauthentication. DETAILED DESCRIPTION

[0026] As those skilled in the art will appreciate, the various aspects of the embodiments can be embodied as a system, device, method or program product. Accordingly, the embodiments can take the form of an entirely hardware embodiment, an entirely software embodiment (including firmware, resident software, micro-code, etc.) or an embodiment combining software and hardware aspects that can all generally be referred to herein as a "circuit," "module" or "system."

[0027] For example, disclosed embodiments can be implemented as a hardware circuit comprising custom very large scale integration ("VLSI") or gate array circuitry, an off-the-shelf semiconductors such as logic chips, transistors, or other discrete components. Disclosed embodiments can also be implemented in programmable hardware devices such as field programmable gate arrays, programmable array logic, programmable logic devices or the like. As another example, disclosed embodiments can include one or more physical or logical blocks of executable code, which may, for example, be organized as an object, procedure, or function.

[0028] Furthermore, embodiments can take the form of a program product embodied in one or more computer readable storage devices having machine readable code, computer readable code, and / or program code embodied thereon. The storage devices can be tangible, non-transitory, and / or non-transmission. The storage devices can not embody signals. In a certain embodiment, the storage devices only employ signals for accessing code.

[0029] Any combination of one or more computer readable medium can be utilized. The computer readable medium can be a computer readable storage medium. The computer readable storage medium can be a storage device storing the code. The storage device can be, for example, but not limited to, an electronic, magnetic, optical, electromagnetic, infrared, holographic, micromechanical, or semiconductor system, apparatus, or device, or any suitable combination of the foregoing.

[0030] More specific examples (a non-exhaustive list) of the storage device would include the following: an electrical connection having one or more wires, a portable computer diskette, a hard disk, a random access memory ("RAM"), a read-only memory ("ROM"), an erasable programmable read-only memory ("EPROM" or Flash memory), a portable compact disc read-only memory ("CD-ROM"), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing. In the context of this document, a computer readable storage medium can be any tangible medium that can contain, or store a program for use by or in connection with an instruction execution system, apparatus, or device.

[0031] Reference throughout this specification to "one embodiment", "an embodiment", or similar language means that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment. Thus, appearances of the phrases "in one embodiment", "in an embodiment", and similar language throughout this specification may, but not always, signify the same embodiment, or a different embodiment, unless expressly specified otherwise. The terms "including", "comprising", "having" and variations thereof mean "including but not limited to", unless expressly specified otherwise. Lists of items, unless expressly specified otherwise, mean one or more items, but not the only items. Unless expressly specified otherwise, the terms "one", "a", and "the" do not preclude the existence of more than one.

[0032] As used herein, a list with a conjunction of “and / or” includes any single item in the list or a combination of items in the list. For example, a list of A, B and / or C includes only A, only B, only C, a combination of A and B, a combination of B and C, a combination of A and C, or a combination of A, B, and C. As used herein, a list using the terminology “one or more of’ includes any single item in the list or a combination of items in the list. For example, one or more of A, B and C includes only A, only B, only C, a combination of A and B, a combination of B and C, a combination of A and C, or a combination of A, B, and C. As used herein, a list using the terminology “one of’ includes one and only one of any single item in the list. For example, “one of A, B, and C” includes only A, only B, or only C and excludes combinations of A, B, and C. As used herein, “a member selected from the group consisting of A, B, and C” includes one and only one of A, B, or C and excludes combinations of A, B, and C. As used herein, “a member selected from the group consisting of A, B, and C and combinations thereof’ includes only A, only B, only C, a combination of A and B, a combination of B and C, a combination of A and C, or a combination of A, B, and C.

[0033] Furthermore, features, structures or characteristics of the described embodiments can be combined in any suitable manner. In the following description, numerous specific details are provided, such as examples of programming, software modules, user selections, network transactions, database queries, database structures, hardware modules, hardware circuits, hardware chips, etc., to provide a thorough understanding of the embodiments. One skilled in the relevant art will recognize, however, that the embodiments can be practiced without one or more of the specific details, or with other methods, components, materials, and so forth. In other instances, well-known structures, materials, or operations are not shown or described in detail in order to avoid obscuring aspects of the embodiments.

[0034] Aspects of the embodiments are described below with reference to schematic flowcharts and / or schematic block diagrams of methods, apparatuses, systems, and program products according to the embodiments. It will be understood that each block of the schematic flowcharts and / or schematic block diagrams, and combinations of blocks in the schematic flowcharts and / or schematic block diagrams, can be implemented by code. The code can be provided to a processor of a general purpose computer, special purpose computer, or other programmable data processing apparatus to produce a machine, such that the

[0035] The code can also be stored in a storage device that can direct a computer, other programmable data processing apparatus, or other devices to function in a particular manner, such that the instructions stored in the storage device produce an article of manufacture including instructions which implement the function / act specified in the schematic flowchart diagrams and / or schematic block diagrams.

[0036] The code can also be loaded onto a computer, other programmable data processing apparatus, or other devices to cause a series of operational steps to be performed on the computer, other programmable apparatus or other devices to produce a computer implemented process such that the code which execute on the computer or other programmable apparatus provide processes for implementing the functions / acts specified in the schematic flowchart diagrams and / or schematic block diagrams.

[0037] The schematic flowcharts and / or schematic block diagrams in the drawings show the architecture, functionality, and operation of possible implementations of apparatuses, systems, methods and program products according to various embodiments. In this regard, each block in the schematic flowcharts and / or schematic block diagrams can represent a module, segment, or portion of code, which comprises one or more executable instructions for implementing the specified logical functions.

[0038] It should also be noted that in some alternative implementations, the functions noted in the blocks can occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently or the blocks can sometimes be executed in the reverse order, depending upon the functionality involved. Other steps and methods can be conceived that are equivalent in function, logic, or effect to those illustrated, with the

[0039] The description of elements in each figure can refer to elements of previous figures. Like reference numbers in all figures indicate like elements, including alternative embodiments of the same element.

[0040] Methods, apparatuses, and systems are disclosed for supporting remote unit reauthentication. A UE can access a 5G core ("5GC") network via a trusted non-3GPP gateway function ("TNGF") in a trusted non-3GPP access network ("TNAN"). When the UE wants to exchange NAS messages with the 5GC via the TNAN, an EAP-5G session is initiated between the UE and the TNGF, and the NAS messages are transported through the EAP-5G session. This enables the UE to perform various 5G NAS procedures, such as a registration procedure and a service request procedure, via trusted non-3GPP access.

[0041] EAP re-authentication protocol ("ERP") is currently supported in communication networks to re-authenticate a UE with a local ER server (based on a previously generated security context) if the UE attempts to reconnect to the same service / home network. However, if there is UE mobility between ER servers, ERP currently does not support sharing of re-authentication security context among ER servers. Thus, when a UE moves to an area served by a different ER server, the UE has to perform a full authentication with the core network, resulting in unnecessary delay of UE attach time and complexity of the network.

[0042] An EAP extension for ERP is specified in IETF RFC 6696. According to RFC 6696, Extensible Authentication Protocol ("EAP") is an authentication framework that supports multiple authentication methods.

[0043] The EAP key hierarchy defines two keys to be derived by all key generating EAP methods: a Master Session Key ("MSK") and an Extended MSK ("EMSK"). In the most common deployment scenario, the EAP peer and EAP server authenticate each other through a third party called EAP authenticator. The EAP authenticator or an entity controlled by the EAP authenticator enforces access control. When a peer moves from one authenticator to another, it is desirable to avoid a full EAP authentication to support fast handover. A full EAP exchange with another run of the EAP method can take several round trips and significant time to complete, resulting in increased handover time. Key sharing across authenticators is sometimes used as a practical solution to reduce handover time. However, in this case, compromise of one authenticator leads to compromise of key material established via other authenticators.

[0044] To enable low latency handover, the present disclosure specifies an EAP re- authentication extension (ERX) to use EAP for efficient re-authentication. The EAP re- authentication protocol (ERP) supports re-authentication of a peer with valid unexpired key material from a previously performed EAP authentication, independent of the EAP authentication method used.

[0045] ERP uses a rRK (re-authentication root key), which is derived by the AUSF (EAP server) from the EMSK and provided to the TNGF through an implicit bootstrap procedure during initial authentication of the UE. As discussed in further detail below, the rRK is used to derive a rIK (re-authentication integrity key) and at least one rMSK (re-authentication master session key). In various embodiments, the ERP keys are derived during an EAP exchange (i.e., during initial UE full authentication). Moreover, the ERP exchange for UE re-authentication is between the UE, an EAP re-authentication authenticator ("ER authenticator"), and an EAP server ("ER server"), as discussed below in FIGS. 3-4.

[0046] When the UE moves from a source TNAP to a target TNAP within the area of the same TNGF, no full authentication needs to be performed. Instead, the UE is re-authenticated by the TNGF (ER server) and a fresh rMSK key is derived by the TNGF and provided to the target / new TNAP to establish over-the-air security between the UE and the target TNAP. In a 5G system supporting ERP, the UE performs the role of the peer, the TNAP performs the role of the ER authenticator, and the TNGF performs the role of the ER server (i.e., local ER server). Note that in the 5G system, the AUSF takes the role of the back-end authentication server (i.e., EAP server).

[0047] The present disclosure describes solutions to support re-authentication during UE mobility between two TNGFs (ER servers) and to mitigate security vulnerabilities due to static rIK leakage by introducing a dynamic rIK (also referred to as fresh rIk) for each ERP run to integrity protect the ERP message exchange. The present disclosure describes solutions to control the sharing of the re-authentication security context of a UE among one or more TNGFs or TNANs using a key management domain, thereby reducing the overhead caused by a domain-specific root re-authentication key (DSRK) that requires the EAP server to participate in re-authenticating the UE for each mobility between different ER server domains resulting in message exchange overhead.

[0048] According to a first solution, the 5G system is enhanced to support re-authentication of a UE using trusted non-3GPP access in a 5G network. The first solution includes a first phase described below with reference to Figures 2A to 2C and a second phase described below with reference to Figures 3A to 3B and Figures 4A to 4C The first phase is an ERP implicit bootstrapping procedure phase that occurs during initial full authentication. The second phase is a re-authentication phase using ERP. Note that the second phase considers two types of UE mobility: A) intra-TNGF re-authentication (UE mobility within the same TNGF between two TNAPs) and B) inter-TNGF re-authentication (UE mobility between two TNGFs). Intra-TNGF re-authentication is described below with reference to Figures 3A to 3B Inter-TNGF re-authentication is described below with reference to Figures 4A to 4C .

[0049] Figure 1A wireless communication system 100 for supporting remote unit reauthentication according to embodiments of the present disclosure is depicted. In one embodiment, the wireless communication system 100 includes at least one remote unit 105, at least one trusted non-3GPP access network (“TNAN”) 120, and a mobile core network 140 in a PLMN. The TNAN 120 can be composed of at least one base unit 121. The remote unit 105 can communicate with the TNAN 120 using a non-3GPP communication link in accordance with a radio access technology deployed by the TNAN 120. Although Figure 1 A particular number of remote units 105, base units 121, TNANs 120, and mobile core networks 140 are depicted in the middle, but one of skill in the art will recognize that any number of remote units 105, base units 121, TNANs 120, and mobile core networks 140 can be included in the wireless communication system 100.

[0050] In one implementation, the wireless communication system 100 is in compliance with a 5G system specified in 3GPP specifications. More generally, however, the wireless communication system 100 can implement some other open or proprietary communication network, such as LTE / EPC (referred to as “4G”), or WiMAX, among other networks. The present disclosure is not intended to be limited to the implementation of any particular wireless communication system architecture or protocol.

[0051] In one embodiment, the remote unit 105 can include a computing device, such as a desktop computer, a laptop computer, a personal digital assistant (“PDA”), a tablet computer, a smart phone, a smart television (e.g., a television with internet connectivity), a smart appliance (e.g., an appliance with internet connectivity), a set-top box, a game console, a security system (including security cameras), a vehicle computer, a network device (e.g., a router, switch, modem), or the like. In some embodiments, the remote unit 105 includes a wearable device, such as a smart watch, fitness band, optical head-mounted display, or the like. Moreover, the remote unit 105 can be referred to as a UE, a subscriber unit, a mobile device, a mobile station, a user, a terminal, a mobile terminal, a fixed terminal, a subscriber station, a user terminal, a wireless transmit / receive unit (“WTRU”), a device, or by other terminology used in the art.

[0052] The remote unit 105 can communicate directly with one or more of the base units 121 in the TNAN 120 via uplink (“UL”) and downlink (“DL”) communication signals. Moreover, the UL and DL communication signals can be carried on the communication links 113. Note that the TNAN 120 is an intermediate network that provides the remote unit 105 with access to the mobile core network 140.

[0053] The base units 121 can serve a number of remote units 105 within a serving area, for example, a cell or a cell sector, via a communication link 113. The base units 121 can communicate directly with one or more remote units 105 via communication signals. Typically, the base units 121 transmit DL communication signals to serve the remote units 105 in the time, frequency, and / or spatial domains. Additionally, the DL communication signals can be carried over the communication links 113. The communication links 113 can be any suitable carrier in a licensed or unlicensed radio frequency spectrum. The communication links 113 facilitate communication between one or more remote units 105 and / or one or more base units 121.

[0054] As described above, the TNAN 120 supports a secure signaling interface and interworking with a 5G core network. The TNAN includes at least one TNGF; in the depicted embodiment, the TNAN 120 includes a first TNGF (“TNGF-1”) 125 and a second TNGF (“TNGF-2”) 127. In certain embodiments, the TNAN 120 supports a Tn interface between TGNFs in the TNAN 120.

[0055] The base units 121 can be distributed over a geographic region. In certain embodiments, the base units 121 can also be referred to as trusted non-3GPP access points (“TNAP”), access terminals, access points, bases, base stations, relay nodes, devices, or by any other terminology used in the art. The base units 121 are generally part of a radio access network (“RAN”), such as the TNAN 120, which can include one or more controllers communicably coupled to one or more corresponding base units 121. These and other elements of radio access network are not illustrated but are familiar to those having ordinary skill in the art. The base units 121 connect to the mobile core network 140 via the TNAN 120.

[0056] In some embodiments, the remote units 105 communicate with application servers (or other communication peers) via a network connection with the mobile core network 140. For example, an application (e.g., web browser, media client, telephone / VoIP application) in a remote unit 105 can trigger the remote unit 105 to establish a PDU session (or other data connection) with the mobile core network 140 using the TNAN 120. To establish the PDU session, the remote unit 105 must register with the mobile core network.

[0057] In one embodiment, the mobile core network 140 is a 5G core (“5GC”) or an evolved packet core (“EPC”), which can be coupled to data networks, such as the Internet and private data networks, among other data networks. A remote unit 105 can have a subscription or other account with the mobile core network 140. The present disclosure is not intended to be limited to the implementation of any particular wireless communication system architecture or protocol.

[0058] The mobile core network 140 includes several network functions (“NFs”). As depicted, the mobile core network 140 includes at least one user plane function (“UPF”) 141. The mobile core network 140 also includes multiple control plane functions, including but not limited to an access and mobility management function (“AMF”) 143, a session management function (“SMF”) 145, and a policy control function (“PCF”) 147. In certain embodiments, the mobile core network 140 can also include a unified data management function (“UDM”) 149, an authentication server function (“AUSF”), a network repository function (“NRF”) (used by the various NFs to discover each other and to communicate with each other over APIs), or other NFs defined for a 5G core.

[0059] In various embodiments, the mobile core network 140 supports different types of mobile data connections and different types of network slices, where each mobile data connection utilizes a particular network slice. Each network slice includes a set of CP and UP network functions, where each network slice is optimized for a particular type of service or traffic class. For ease of illustration, different network slices are not shown in Figure 1 but their support is assumed. In one example, each network slice includes an SMF and a UPF, but the various network slices share the AMF 143, the PCF 147, and the UDM. In another example, each network slice includes an AMF, an SMF, and a UPF. Although a particular number and type of network functions are depicted in Figure 1 the mobile core network 140, one of skill in the art will recognize that any number and type of network functions can be included in the mobile core network 140.

[0060] In various embodiments, the remote unit 105 sends an ERP support indicator when registering / authenticating with the mobile core network 140 via the TNAN 120. Because the remote unit 105 supports ERP, the TNGF-1 125 performs an ERP bootstrap procedure during initial authentication, as described below with reference to Figures 2A to 2C . Thereafter, as mobility of the remote unit 105 causes it to connect to a new base unit 121 in the TNAN 120, the remote unit re-authenticates using ERP, as described below with reference to Figures 3A to 3B and Figures 4A to 4CSaid. If the remote unit 105 leaves the key management domain (i.e., an area in which security keys can be shared with a different TNGF), the initial authentication will be performed again, as described below with reference to Figure 5 Said.

[0061] Figures 2A to 2C A procedure 200 for UE registration and authentication for trusted non-3GPP access networks according to embodiments of the disclosure is depicted. The procedure 200 involves a UE 205 (e.g., one embodiment of the remote unit 105), a TNAN 210 (e.g., one embodiment of the TNAN 120) including a TNAP 211 and a TNGF 213 (e.g., one embodiment of the TNGF 123), and a 5G core network 215 (e.g., one embodiment of the mobile core network 140). In the most typical case, the trusted non-3GPP access network 210 is a WLAN access network compliant with IEEE 802.11 specifications.

[0062] The procedure 200 starts with Figure 2A In step 1, the UE 205 selects a PLMN and a TNAN 210 for connecting to this PLMN by using the trusted non-3GPP access network selection procedure currently specified in TS 23.501, clause 6.3.12. During this procedure, the UE 205 discovers a TNAN 210 with which a PLMN supports trusted connectivity (e.g., “5G connectivity”). A layer-2 (“L2”) connection is established between the UE 205 and the TNAP 210 (see connection 220). In the case of IEEE 802.11, this step corresponds to the 802.11 association. In the case of PPP, this step corresponds to the PPP LCP negotiation. In other types of non-3GPP access (e.g., Ethernet), this step can not be needed.

[0063] In steps 2-3, an EAP authentication procedure is initiated. EAP messages (see message exchanges 222, 224) can be encapsulated into layer-2 packets, e.g., into IEEE 802.3 / 802. lx packets, into IEEE 802.11 / 802. lx packets, into PPP packets, etc. The UE 205 provides an NAI that triggers the TNAP 211 to send an AAA request to the TNGF 213. Note that there is an AAA interface between the TNAP 211 and the TNGF 213. Between the TNAP 211 and the TNGF 213, EAP packets are encapsulated into AAA messages.

[0064] As Step 4, the UE 205 receives an L2 EAP-Request / 5G-Start message from the TNGF 213 (see messaging 226). In Step 5, the UE 205 responds to the TNGF 213 with an L2 message (see messaging 228). The L2 message encapsulates an EAP-5G Response message (EAP-Response / 5G-NAS) containing AN parameters (AN-Params) and a NAS Registration Request (NAS-PDU[Registration Request]). If the UE 205 supports ERP, the L2 message includes an ‘ERP Support Flag’ sent to the TNGF 213 with the L2 message as part of the AN parameters in the AN message or as a separate information element in the AN message.

[0065] The UE 205 includes the ‘ERP Support Flag’ to indicate to the TNGF 213 acting as an ER server that the UE 205 supports ERP. In such embodiments, the TNGF 213 can be determined based on the received ‘ERP Support Flag’ and initiate an implicit ERP bootstrap procedure with the EAP authentication message to obtain a reauthentication security context for subsequent reauthentication of the UE 205. The use of the ‘ERP Support Flag’ prevents unnecessary ERP implicit bootstrap procedure initiation at the TNGF 213 and saves network resources if the UE 205 does not support ERP.

[0066] In the absence of the ‘ERP Support Flag’ indication from the UE 205, if the TNGF 213 supports ERP and expects to support reauthentication using ERP, the TNGF 213 initiates an implicit ERP bootstrap procedure with the core network to receive a reauthentication security context from an EAP server (AUSF 217) in the 5GC 215 without knowing whether the UE 205 is capable of ERP support. If the UE 205 does not support ERP, the EAP-Initiate / Re-auth-Start message sent by the authenticator (TNAP 211) to the UE 205 will be silently discarded by the UE 205, causing further waste of resources.

[0067] At step 6a, the TNGF 213 selects an AMF, i.e., the AMF / SEAF 216 in the 5GC 215, and determines to initiate an ERP bootstrapping procedure (see block 230). At step 6b, the TNGF 213 sends an N2 message to the AMF / SEAF 216 (see messaging 232). If the ‘ERP support flag’ is received from the UE 205 and if the TNGF 213 supports ERP, the TNGF 213 includes an ‘ERP key request’ in the N2 message to initiate an implicit bootstrapping procedure and forwards the registration request received from the UE 205 to the AMF / SEAF 216. Alternatively, if the ‘ERP support flag’ is not received from the UE 205 at the TNGF 213 or if the TNGF 213 does not support ERP, in either case, the TNGF 213 does not include an ‘ERP key request’ in the N2 message and does not perform an ERP implicit bootstrapping procedure.

[0068] At step 7, the UE 205 and the AMF / SEAF 216 in the 5GC 215 exchange additional NAS messages over the EAP-5G session (see messaging 234). Examples of additional NAS messages include, but are not limited to, those related to NAS authentication of the UE 205.

[0069] At step 8a, the AMF 216 in the 5GC 215 sends the received ‘ERP key request’ to the AUSF 217 in the 5GC 215 along with an authentication request (“SBI”) in a AAA key request / Service-based interface in the AAA interface (see messaging 236). In optional step 8b, additional EAP message exchanges are performed between the UE 205 and the AUSF 217 in the 5GC 215 if needed (see messaging 238). The AUSF 217 in the 5GC 215 further sends (see messaging 237) an authentication data request to the UDM 218 in the 5GC 215 and receives an authentication vector (i.e., EAP-AKA’ AV), an authentication method indication, and a SUPI from the UDM 218 in the 5GC 215. The EAP-AKA’ AV consists of a RAND, an AUTN, an XRES, a CK’, and an IK’.

[0070] In response to receiving the 'ERP Key Request' from the AMF / SEAF 216 in the 5GC 215, the AUSF 217 in the 5GC 215 generates a reauthentication security context including a derived rRK, an EMSK name, and an rRK lifetime. The rRK serves as a reauthentication root key and the EMSK name (Keyname) serves as a key identifier for the rRK due to the subject matter disclosed herein. The rRK lifetime is assigned by the AUSF 217 in the 5GC 215 and defines the validity or lifetime of the rRK key. Upon expiration of the rRK lifetime, the TNGF 213 of the TNAN 210 acting as an ER server attempts to perform a full authentication.

[0071] The rRK is derived using a key derivation function ("KDF") (see block 250). In a first option, the EMSK, the SUPI, and the serving network name / home network ID ("SNN / HNID") are used as parameters to the KDF. For example, the rRK can be derived using a key derivation function ("KDF", i.e., a cryptographic hash function) and the following equation:

[0072] rRK = KDF(EMSK, SUPI, SNN / HNID | rRK Label | '\0' | Length) Equation 1

[0073] As used herein, the parameter "rRK Label" refers to a string (e.g., an 8-bit ASCII string). The rRK Label can be pre-assigned by an authority such as a standards organization. The Length field refers to the length (e.g., in octets) of the derived key (i.e., the rRK in Equation 1). In various embodiments, the Length field can be encoded as specified in IETF RFC 5295. Note that (EMSK), (SUPI), and (SNN / HNID | rRK Label | '\0' | Length) are three inputs to the KDF, where the '|' operator indicates concatenation. Here, the value '\0' can be used to show separation between the various inputs and the Length.

[0074] In a second option, the K AUSF , SUPI, SNN / HNID are used as parameters to the KDF.

[0075] For example, the rRK can be derived using a key derivation function and the following equation:

[0076] rRK = KDF(K AUSF , SUPI, SNN / HNID | rRK Label | '\0' | Length)

[0077] Equation 2

[0078] Note that (K AUSF), (SUPI), and (SNN / HNID | rRK-Tag | '\0' | Length) are three inputs to the KDF, where the '|' operator indicates concatenation. Here, the value '\0' can be used to show separation between the various inputs and the length. The length field refers to the length (e.g., in octets) of the derived key (i.e., rRK in Equation 2).

[0079] In either embodiment, the home network ID ("HNID") can include the MCC and MNC of the IMSI / NAI. The SNN is the serving network name containing the serving network identifier ("SNID") and the 5G code. Further, if the rRK is generated from the EMSK, the derivation of the corresponding key identifier EMSKname (see block 250) is performed using the KDF with the EAP session-ID, SUPI, SNN / HNID, and EMSK as parameters, e.g., using the following equation to derive:

[0080] EMSKname = KDF(EAP session-ID, SUPI, SNN / HNID, "EMSK" | '\0' | Length) Equation 3

[0081] Note that (EAP session-ID), (SUPI), (SNN / HNID), and (EMSK | rRK-Tag | '\0' | Length) are four inputs to the KDF, where the '|' operator indicates concatenation. Here, the value '\0' can be used to show separation between the various inputs and the length. The length field refers to the length (e.g., in octets) of the derived parameter (i.e., EMSKname in Equation 3).

[0082] If the rRK is derived from the K AUSF AUSF", e.g., using the following equation to derive:

[0083] Kausfname = KDF(EAP session-ID, SUPI, SNN / HNID, "K_AUSF" | '\0' | Length) Equation 4

[0084] The subsequent re-authentication procedures can use the Keyname Kausfname in place of the Keyname EMSKname accordingly. Note that (EAP session-ID), (SUPI), (SNN / HNID), and (K AUSFThe four inputs to the KDF are `|rRKlabel|'\0'|length)`, where the `|` operator indicates a concatenation. The value `\0` can be used to indicate the separation between various inputs and the length. The length field refers to the length (e.g., in octets) of the derived parameter (i.e., `Kausfname` in Equation 4).

[0085] In 5GC 215, AUSF 217 provides the SEAF in 5GC 215 with a freshly generated re-authentication security context (consisting of rRK, EMSKname or Kausfname, and rRK lifetime) along with the SEAF key and the EAP success flag in the AAA key response message, shown here alongside the AMF in 5GC 215. SEAF 216 in 5GC 215 forwards the re-authentication security context to AMF 216 in 5GC 215 based on the local policy used for the re-authentication security context, along with the AMF key (derived from the SEAF key) and the key management domain name. AMF 216 in 5GC 215 locally stores the re-authentication security context until a successful NAS security mode command (e.g., NAS SMC) procedure is executed using UE 205.

[0086] In step 9, AMF 216 in UE 205 and 5GC 215 exchange additional NAS messages via an EAP-5G session (see Message Passing 242 to 248). Figure 2B Examples of additional NAS messages include, but are not limited to, those involving NAS authentication or re-authentication. In step 10, after successful authentication, a security key 'K' is created in UE 205 and AMF 216 in 5GC 215. TNGF '. K TNGF In step 10a, AMF 216 in 5GC 215 is transferred to TNGF 213 in TNAN 210 (within the N2 initial context setting request, see message passing 252).

[0087] Additionally, after successful UE authentication and NAS SMC, AMF 216 in 5GC 215 sends (see message passing 252) a re-authentication security context (e.g., rRK, EMSKname, rRK lifetime) along with the corresponding key management domain name and K in the N2 Initial Context Setting Request message. TNGF Note that TNGF 213 may already have a pre-configured key management domain name; in this case, the N2 Initial Context Setup Request message can exclude the key management domain name.

[0088] At step 10b, the TNGF 213 in the TNAN 210 locally stores (see block 254) the received re-authentication security context (e.g., rRK, EMSKname, rRK lifetime) and the key management domain name (if provided by the AMF / SEAF as no possible pre-configuration at the TNGF). Alternatively, based on the association of the TNGF in the TNAN 210 with the TNAP 211, the TNGF 213 can be pre-provisioned / pre-configured with the key management domain name (“KM-Domain-Name”) by the operator or by other means outside the scope of the present disclosure.

[0089] The KM-Domain-Name used herein indicates a group of TNGF 213 and TNAP 211 in the TNAN 210 that can share the same re-authentication security context to perform ERP-based re-authentication for a UE 205 that is accessing the 5G core network service 215 via a designated group of TNGF 213 in the TNAN 210. The KM-Domain-Name remains the same for all TNGF 213 in the TNAN 210 that share the same re-authentication security context. Figures 2A to 2C The bootstrap procedure illustrated in the middle plays a major role in sharing the re-authentication security context of the UE among the TNGF 213 in the TNAN 210 that belong to the same key management domain to ensure the security level of the UE 205 re-authentication security context.

[0090] Upon receiving the TNGF keys from the AMF 216 in the 5GC 215 at step 10a, the TNGF 213 in the TNAN 210 sends (see messaging 260, Figure 2C ) to the UE 205 an EAP-Request / 5G-Notification packet containing the “TNGF contact information” which includes the IP address of the TNGF 213, the TNGF-ID, and the KM-Domain-Name.

[0091] The TNGF 213 derives (see block 256) a dynamic re-authentication integrity key (“rIK”) using a KDF to securely exchange and verify the ERP messages with the rRK, the KM-Domain-Name, a sequence number (SEQ) (initialized to ‘0’ or ‘1’ during the EAP full authentication and incremented for each ERP run related use) and a rRK label as parameters - for example, using the following formula:

[0092] rIK = KDF(rRK, KM-Domain-Name, SEQ, rIK label | ‘\0’ | cipher suites | length) Equation 5

[0093] It should be noted that (rRK), (KM-Domain-Name), (SEQ), and (rIK-Label | '0' | Cipher Suite | Length) are four inputs to the KDF, where the'|'operator indicates concatenation. The parameter "rIK-Label" as used herein refers to a string (e.g., an 8-bit ASCII string). Here, the value '0' can be used to show separation between various inputs and lengths. The Length field refers to the length (e.g., in octets) of the derived key (i.e., rIK in Equation 5).

[0094] The TNGF 213 in the TNAN 210 locally stores the received re-authentication security context (e.g., rRK, EMSKname, lifetime, and key management domain) along with the derived rIK (see block 258) if any, to the UE context.

[0095] The UE 205, now or after receiving the EAP success at step 10f, derives the re-authentication security context, e.g., EMSKname, rRK, and dynamic re-authentication integrity key ("rIK") (see blocks 262, 264), to securely exchange and verify ERP messages using a KDF with rRK, KM-Domain-Name, and rIK-Label as parameters - e.g., derived using Equation 5, similar to the TNGF 213 in the TNAN 210.

[0096] The UE 205 locally stores the received TNGF ID, TNGF IP address, and KM-Domain-Name to support subsequent re-authentication (see block 266). The TNAP 211 in the TNAN 210 is a trusted entity. The TNGF 213 in the TNAN 210 generates a K TNAP and transmits it from the TNGF 213 to the TNAP 211 along with the KM-Domain-Name at step 10c (e.g., within a AAA message).

[0097] The UE 205 sends (see messaging 268) an EAP-Request / 5G-Notification message to the TNGF 213 in the TNAN 210. After receiving the EAP-Response / 5G-Notification packet from the UE 205, the TNGF 213 in the TNAN 210 sends (see messaging 270) a message containing an EAP-Success packet along with the TNAP key to the TNAP 211 in the TNAN 210. The TNAP 211 forwards (see messaging 272) the packet containing the EAP-Success in an L2 message to the UE 205.

[0098] In step 11, the UE 205 and the TNAP 211 in the TNAN 210 derive security keys and establish a security association to protect subsequent traffic according to the applied non-3- GPP technology using the common TNAP key. In the case of IEEE 802.11, for example, K TNAP is the Pairwise Master Key (“PMK”) and a 4-way handshake (see IEEE 802.11) is performed to establish a security context between the TNAP 211 in the TNAN 210 (e.g., a WLAN AP) and the UE 205, which is used to protect over-the-air unicast and multicast traffic. Messages between the UE 205 and the TNAP 211 in the TNAN 210 are encrypted and integrity protected from this step onward.

[0099] Figures 3A to 3B A procedure for 5G re-authentication over trusted non-3GPP access networks according to embodiments of the disclosure is depicted. The procedure 300 involves a UE 205 (e.g., one embodiment of the remote unit 105), a first / current TNAP 301, a second / new / target TNAP 303 in the TNAN 210, and a TNGF 213.

[0100] TNGF -intra mobility as used herein is defined as the mobility of the UE 205 between two TNAPs 301, 303 connected to a single / same TNGF 213 in the TNAN 210. Since the UE 205 can have previously authenticated with the TNAN 210 via the same TNGF 213 and the TNGF 213 possesses the re-authentication security context, as derived during the ERP implicit bootstrapping procedure, as described above with reference to the procedure 200 shown in Figures 2A to 2C The ERP-based re-authentication will be sufficient for the network to provide access to the UE 205 without performing a full authentication again, thereby avoiding multiple distinct interactions with the 5GC core network 215 and reducing handover latency, as described below and illustrated in the procedure 300 shown in Figures 3A to 3B The procedure 300 provides a re-authentication that reduces the conventional re-authentication complexity in the TNAN 210 in this way.

[0101] As shown in Figure 3A In step 0, an IPsec security association (“SA”) connection (see connection 309) is established between the UE 205, the current TNAP 301, the new / target TNAP 303 in the TNAN 210, and the TNGF 213. In step 1, the ERP exchange is triggered by the new / target TNAP 303 (e.g., an ER authenticator) by sending an EAP-5G start message (see EAP-Init / Re-auth Start message 311) with a key management domain name (“KM-Domain Name”) to the UE 205.

[0102] Both the UE 205 and the TNGF 213 can have a locally stored instance of the UE context (i.e., re-authentication security context), including the EMSKname, rRK, rIK, KM-Domain name, and TNGF ID / IP address (see block 305 for the UE 205 and block 306 for the TNGF 213). Thus, in step 2, the UE 205 verifies that the locally stored KM-Domain name is the same as received from the new / target TNAP 303. If so, the UE 205 forms a Keyname-NAI as EMSKname@Domain-name (see block 313) and sends (see messaging 315) an EAP-Initiate / Re- authenticate message to the new / target TNAP 303 (e.g., ER authenticator). As used herein, "Keyname-NAI" refers to an NAI (i.e., having the form "username@realm") where the username portion refers to a key identifier (i.e., Keyname) that points to a security key (e.g., EMSKname that points to an EMSK). Note that in alternative embodiments, the Keyname-NAI can have the form Kausfname@Domain-name instead of EMSKname@Domain-name, as discussed above.

[0103] The Domain name used in the Keyname-NAI field (i.e., Keyname-NAI = Keyname@Domain-name) is generated by the UE 205 using the values for the TNGF information and KM-Domain name as follows: TNGF-ID.KM-Domain name (see block 317). If the UE 205 includes a previously derived rIK related to the KM-Domain name (as explained above and shown in block 307), it uses the rIK to integrity protect the ERP exchange between the UE 205 and the TNGF 213 (e.g., ER server).

[0104] If the UE 205 does not have a locally stored instance of a previously derived rIK, a static or fresh rIK (if the UE determines to derive a fresh rIK) can be derived by the UE 205. A static rIK, e.g., one that does not change for each ERP run, can be derived using the following equation as a KDF:

[0105] rIK = KDF(rRK, KM-Domain name, rIK label | 'V0' | cipher suites | length) Equation 6

[0106] Note that (rRK), (KM-Domain name), and (rIK label | '0' | encryption suite | length) are three inputs to the KDF, where the'|'operator indicates concatenation. Here, the value '0' can be used to show separation between the various inputs and length. The length field refers to the length (e.g., in octets) of the derived key (i.e., rIK in Equation 6).

[0107] Note that if a static rIK is used, rIK leakage would compromise all subsequent reauthentication security between the same UE and the same or different TNGF. Thus, a fresh rIK can be derived using the KDF according to Equation 5 above, e.g., for each ERP run.

[0108] Note that a sequence number ("SEQ") is used as a parameter for generating a fresh rIK for each ERP run or when needed. The SEQ is incremented as an input to the key derivation after each use to ensure freshness of the key. The EAP-Initiate / Re- authenticate message sent by the UE 205 (see messaging 315) contains the EMSKname@Domain-name and additionally contains the SEQ associated with the rIK, encryption suite, and authentication tag (e.g., MAC1).

[0109] In Step 3, the new / target TNAP 303 (e.g., ER authenticator) processes the message and sends (see messaging 321) an AAA message to the TNGF 213 (e.g., ER server) by forwarding (see block 319) the received EAP-Initiate / Re-auth message based on the domain part of the NAI (i.e., Domain-name). The TNGF information (e.g., TNGF IP address or TNGF ID) in the domain part of the NAI (e.g., Domain-name) helps the new / target TNAP 303 to forward the message to the correct TNGF 213 if it is reachable.

[0110] In Step 4, the TNGF 213 (e.g., ER server) verifies (see block 323) the domain name and validity of the ERP message by checking the EMSKname in the username part of the NAI and performing integrity check of the ERP message (see block 325, Figure 3B ) using the SEQ associated with the rIK. If the verification is successful, the UE 205 is successfully authenticated. If the TNGF 213 does not have the rIK in its local memory, the TNGF 213 retrieves the reauthentication security context associated with the EMSKname and derives the rIK (as explained above and illustrated in block 328) to verify the integrity of the received ERP message.

[0111] If the re-authentication is successful, the TNGF 213 (e.g., ER server) generates a fresh rMSK (see blocks 327 and 328) and provides the rMSK along with an EAP-Complete / Re-auth message containing EMSKname@Domain-name, a sequence number (SEQ), a cipher suite, and a MAC2 to the new / target TNAP 303 (e.g., ER authenticator) in a AAA response message (see step 5, messaging 329). The MAC2 is an authentication tag used to integrity protect the ERP messages sent from the TNGF 213 to the UE 205. The rMSK is generated using a KDF with the rRK, the trusted access code, the rMSK label, and the SEQ as parameters - e.g., derived using the following equation:

[0112] rMSK = KDF(rRK, trusted access code, rMSK label |'\0' | SEQ | length) Equation 7

[0113] Note that (rRK), (trusted access code), and (rMSK label |'\0' | SEQ | length) are the three inputs to the KDF, where the'|'operator indicates concatenation. As used herein, the parameter "rMSK label" refers to a string (e.g., an 8-bit ASCII string). Here, the value'\0' can be used to show separation between the various inputs and the length. The length field refers to the length (e.g., in octets) of the derived key (i.e., rMSK in Equation 7).

[0114] The new / target TNAP 303 (e.g., ER authenticator) retrieves the rMSK and forwards (see messaging 331) the EAP-Complete / Re-auth message to the UE 205.

[0115] In step 6, the UE 205 verifies (see block 333) the MAC2 using the SEQ associated with the rIK and derives (see blocks 335 and 336) a rMSK for the TNGF 213 similar to that described in step 4c. Alternatively, the UE 205 and TNGF 213 can derive and use fresh rIKs for the MAC 1 and MAC 2 calculations, respectively, based on the described implementation by using the most recent SEQ number as an input as described above with respect to steps 4a-b. When the rIKs are derived and used, the associated SEQs can be incremented accordingly at the UE 205 and TNGF 213.

[0116] In step 7, the UE 205 and the new / target TNAP 303 (e.g., ER authenticator) use the freshly derived rMSK (e.g., TNAP key) to derive security keys according to the applied non-3GPP technology and establish (see messaging 337) a security association, e.g., IPsec SA, to protect subsequent traffic (see connection 339) between the UE 205, the new / target TNAP 303, and the TNGF 213.

[0117] Figures 4A to 4C A procedure for 5G reauthentication over trusted non-3GPP access networks according to embodiments of the disclosure is depicted. The procedure 400 involves a UE 205 (e.g., one embodiment of the remote unit 105), a first / current TNAP 301 in the TNAN 210, a second / new / target TNAP 303, a source TNGF 401, and a target TNGF 403.

[0118] Inter-TNGF mobility is defined as mobility of the UE 205 between two TNAPs 301, 303 connected to two different TNGFs 401, 403. If the two TNGFs 401, 403 belong to the same operator’s network, e.g., the TNAN 210, and if the source TNGF 401 and the target TNGF 403 are connected with a Tn interface, the UE 205 can be reauthenticated using ERP based on the reauthentication security context available to the source TNGF 401 (see blocks 402, 404).

[0119] As Figures 4A to 4C As shown in FIG. 4A, in step 0, an IPsec security association (“SA”) connection (see connection 405) is established between the UE 205, the current TNAP 301 in the TNAN 210, the new / target TNAP 303, and the source TNGF 401. In step 1, the ERP exchange is triggered by the new / target TNAP 303 (e.g., ER authenticator) by sending an EAP-Initiate / Re-auth-Start message (see messaging 407) with a key management domain name (“KM-DN”) to the UE 205.

[0120] Both the UE 205 and the source TNGF 401 can have a locally stored instance of the UE context (i.e., re-authentication security context), including the EMSKname, rRK, rIK, KM-Domain name, and TNGF ID / IP address (see block 402 for the UE 205 and block 404 for the TNGF 213). Thus, in step 2, the UE 205 verifies (see block 409) that the locally stored KM-Domain name is the same as received from the new / target TNAP 303. If so, the UE 205 forms the Keyname-NAI as EMSKname@Domain-name and sends (see messaging 411) an EAP-Initiate / Re- authenticate message to the new / target TNAP 303 (e.g., ER authenticator).

[0121] The Domain name here includes only the previously authenticated / re-authenticated TNGFs 401 info, i.e., for the TNGF ID or TNGF IP address, as only the TNGF 401 contains the re-authentication security context for the UE 205. The Domain name used in the NAI realm is generated by the UE 205 using the TGF info and the value of the KM-Domain name as follows: TNGF-ID.KM-Domain name. If the UE 205 contains a previously derived rIK related to the KM-Domain name (as explained above and shown in block 307), it uses the rIK to integrity protect the ERP exchange between the UE 205 and the TNGF 401 (e.g., ER server).

[0122] If the UE 205 does not have a locally stored instance of a previously derived rIK, a static or fresh rIK (if the UE determines to derive a fresh rIK) can be derived by the UE 205. A static rIK, e.g., an rIK that does not change for each ERP run, is derived using the KDF according to Equation 6 above. A fresh rIK, e.g., an rIK that is generated for each ERP run or as needed, is derived using the KDF according to Equation 5 above. Note that a sequence number (“SEQ”) is used as a parameter for generating fresh rIKs for each ERP run or as needed. The SEQ is incremented as an input to key derivation after each use to ensure freshness of keys such as rIKs and session keys. The EAP-Initiate / Re-auth message sent by the UE 205 (see messaging 411) contains the EMSKname@Domain-name and additionally contains the SEQ associated with the rIK, the cipher suite, and an authentication tag (e.g., MAC1).

[0123] In step 3, the new TNAP 303 (e.g., ER authenticator) processes the message, e.g., as in IETF RFC 6696, and finds that the source TNGF 401 specified in the domain name is not reachable for the new TNAP 303 (see block 413). The new TNAP 303 forwards the received EAP-Init / Re-Auth message and sends (see message passing 415) an AAA message to the new target TNGF 403 (e.g., ER server) based on the KM-Domain name.

[0124] Alternatively, the TNGF information (e.g., TNGP IP address or ID) in the domain part (e.g., domain name) of the NAI helps the new / target TNAP 303 to forward the message to the correct TNGF 403 if it is reachable, and in that case the procedure is similar to the TNGF- in mobility described above.

[0125] The target TNGF 403 (e.g., ER server 2) verifies the KM-Domain name and based on the EMSKname in the NAI username, finds that the TNGF 403 does not have any re- authentication security context for the UE 205 on its side. However, the target TNGF 403 determines from the NAI domain part that the domain name contains the TNGF IP address and / or TNGF ID of the source TNGF 401 with which the target TNGF 403 has a Tn interface. The target TNGF 403 determines to forward (see message passing 417) the EAP-Init / Re-Auth message in the re- authentication data request over the Tn interface to the source TNGF 401.

[0126] In step 4, Figure 4B , the source TNGF 401 verifies (see block 419) the domain name in the received NAI domain part by checking the EMSKname in the username part of the NAI and performs an integrity check of the ERP message using the SEQ associated with the rIK, and checks (see block 421) the validity of the ERP message. If a static rIK is used based on the UE 205 and TNGF 401 implementation, the source TNGF 401 uses a locally stored (as explained above derived) static rIK associated with the SEQ and EMSKname.

[0127] Alternatively, a fresh rIK (as explained above derived) is used by the UE 205 and the source TNGF 401 based on the operator's implementation, e.g., TNAN 210 configuration / implementation. The source TNGF derives and uses the rIK associated with the received SEQ by retrieving the re-authentication security context associated with the EMSKname, thereby verifying the integrity of the received ERP message.

[0128] In step 5, if the verification of MAC1 is successful and if the received KM-Domain matches the locally stored KM-Domain, the source TNGF 401 provides the reauthentication security context (e.g., rRK, rIK, SEQ, rRK lifetime) to the target TNGF 403 in a Tn Reauthentication Data Response message (see messaging 423).

[0129] In step 6, if the reauthentication security is successfully received, the target TNGF 403 locally stores the reauthentication security context (e.g., rRK, rIK (can be fresh or static rIK), EMSKname, lifetime, SEQ, updated domain name). In addition, the target TNGF 403 (e.g., ER authenticator) generates or derives (see blocks 425 and 426) a fresh rMSK, e.g., by incrementing the SEQ value and using Equation 7, as specified above, and updates (see block 427) the domain portion of the KeyName-NAI, e.g., the domain name, with its TNGF IP address and / or ID.

[0130] In step 7, the target TNGF 403 provides the new rMSK to the new / target TNAP 303 (e.g., ER authenticator) in an AAA Response message (see messaging 429), along with an EAP- Finish / Reauthentication message containing the updated EMSKname@Domain-name (where the updated EMSKname@Domain-name contains the target TNGF 403 information in the domain portion, as it currently holds the reauthentication security context), a sequence number ("SEQ"), a cipher suite, and a MAC2. MAC2 is an authentication tag used to integrity protect the ERP message sent from the target TNGF 403 to the UE 205.

[0131] The new / target TNAP 303 (e.g., ER authenticator) retrieves the rMSK and forwards (see messaging 431) the EAP-Finish / Reauthentication containing the updated KeyName-NAI: EMSKname@Domain-name, a sequence number ("SEQ"), a cipher suite, and a MAC2 to the UE 205. As shown by block 433, since the rRK is now available in TNGF 2, the EMSKname@Domain-name should point to the target TNGF 403.

[0132] In step 8, Figure 4C, the UE 205 verifies (see block 435) MAC2 using the SEQ associated with rIK and derives a fresh rMSK similar to the target TNGF 403 (see blocks 437 and 438), e.g., using Equation 7, as specified above. The UE 205 further verifies the domain name in the received KeyName.NAI and, if it is different from the locally stored domain name, the UE 205 saves the recently received domain name along with the re-authentication security context and deletes the old (previously stored) domain name from its memory.

[0133] Alternatively, the UE 205 and the target TNGF 403, based on implementation, can derive and use a fresh rIK for MAC 1 and MAC 2 computation, respectively, by using the SEQ number as input, as explained above. Whenever a rIK is derived and used, the associated SEQ is incremented accordingly at the UE 205 and the target TNGF 403.

[0134] In step 9, the UE 205 and the new / target TNAP 303 (e.g., an ER authenticator) use the freshly derived rMSK (e.g., TNAP key) to derive security keys according to the applied non-3GPP technology and establish (see messaging 439) a security association, e.g., an IPsec SA, to protect subsequent traffic (see connection 441) between the UE 205, the new / target TNAP 303, and the TNGF 403.

[0135] Figure 5 A procedure 500 for an EAP-5G session over a trusted non-3GPP access network is depicted in accordance with an embodiment of the present disclosure. The procedure 500 involves a UE 205 (e.g., one embodiment of the remote unit 105), a TNAN 210 (e.g., one embodiment of the TNAN 120) including a current TNAP 301, a target TNAP 303, and a TNGF 213 (e.g., one embodiment of the TNGF 123), and a 5G core network 215 (e.g., one embodiment of the mobile core network 140). In the most typical case, the trusted non-3GPP access network 210 is a WLAN access network compliant with the IEEE 802.11 specification.

[0136] The key management domain as defined above plays a major role only in controlling the sharing of the UE’s re-authentication security context among TNGFs 213 belonging to the same key management domain. If the UE 205 moves to a different TNAP 303 connected to a new TNGF 213 belonging to a different key management domain, the new TNGF 213 will not be provided the re-authentication security context by the old TNGF 213 whose key management domain is different.

[0137] Accordingly, the UE 205 is unable to perform re-authentication with the new TNGF 213 belonging to a different key management domain using its locally stored re- authentication security context. Therefore, an initial full authentication is triggered with the new TNAP 303 and the new TNGF 213 belonging to a different key management domain. Figure 5 It is described how key management domain control can be imposed by the TNAN 210 and the UE 205 to ensure the security and reliability of re-authentication security contexts among a group of network functions / entities forming a key management domain.

[0138] As shown in Figure 5 FIG. 2, in step 0, an IPsec Security Association (“SA”) connection is established between the UE 205, the current TNAP 301 in the TNAN 210, the new / target TNAP 303, and the TNGF 213 (see connection 503). In step 1, an ERP exchange is triggered by the new / target TNAP 303 (e.g., an ER authenticator) by sending an EAP-Initiate / Re- authentication Start message with a key management domain name (“KM-Domain Name”) to the UE 205 (see messaging 505).

[0139] The UE 205 can have a locally stored instance of a UE context (i.e., a UE re- authentication security context) including the EMSKname, the rRK, the rIK, the KM-Domain Name, and the TNGF ID / IP address (see block 501). As such, the UE 205 verifies (see block 507) whether the locally stored KM-Domain Name is the same as received from the new / target TNAP 303. If not, the UE 205 sends a ‘domain mismatch indicator’ (alternatively, can be referred to as a KM-Domain Mismatch Indicator / Flag) to the target TNAP 303 in an EAP-Initiate / Re-authentication message (see messaging 509).

[0140] In step 3, the new / target TNAP 303, in response to the received ‘domain mismatch indicator’, triggers (see block 511) an initial EAP full authentication (e.g., primary authentication) for the UE 205 with the 5G core network 215 via the associated TNGF 213.

[0141] In step 4, the new / target TNAP 303 sends an EAP-Request / 5G-Start message to the UE 205 over L2 (see messaging 513) to initiate the primary authentication. In step 5, the primary authentication (see 515) follows the procedure 200 described above with reference to Figures 2A to 2C

[0142] Figure 6 ​One embodiment of a user equipment apparatus 600 in accordance with embodiments of the present disclosure is depicted. The user equipment apparatus 600 can be one embodiment of the remote unit 105 and / or the UE 205. Furthermore, the user equipment apparatus 600 can include a processor 605, a memory 610, an input device 615, an output device 620, a transceiver 625. In some embodiments, the input device 615 and the output device 620 are combined into a single device, such as a touch screen. In certain embodiments, the user equipment apparatus 600 does not include any input device 615 and / or output device 620.

[0143] As depicted, the transceiver 625 includes at least one transmitter 630 and at least one receiver 635. Here, the transceiver 625 communicates with a mobile core network (e.g., 5GC) via an access network. Additionally, the transceiver 625 can support at least one network interface 640. Here, the at least one network interface 640 facilitates communications with a TNGF (e.g., using an “NWt” interface). Additionally, the at least one network interface 640 can include interfaces for communicating with an AMF, an SMF, and / or a UPF.

[0144] In one embodiment, the processor 605 can include any known controller capable of executing computer-readable instructions and / or capable of performing logical operations. For example, the processor 605 can be a microcontroller, a microprocessor, a central processing unit (“CPU”), a graphics processing unit (“GPU”), an auxiliary processing unit, a field programmable gate array (“FPGA”), or similar programmable controller. In some embodiments, the processor 605 executes instructions stored in the memory 610 to perform methods and routines described herein. The processor 605 is communicatively coupled to the memory 610, the input device 615, the output device 620, and the transceiver 625.

[0145] In various embodiments, the processor 605 controls the user equipment apparatus 600 to implement the UE behaviors described above. In some embodiments, the processor 605 sends (via the transceiver 625) a first authentication message to a network function to authenticate with a mobile communication network. Here, the first authentication message contains an indicator that the apparatus supports ERP. The processor 605 receives (via the transceiver 625) a second authentication message from the network function in response to the first authentication message, where the second authentication message contains a key management domain name that indicates a set of network functions that are capable of sharing a reauthentication security context of the apparatus for performing ERP. In response to a successful authentication with the mobile communication network, the processor 605 derives a reauthentication security context and locally stores (in the memory 610) the received key management domain name and the derived reauthentication security context for subsequent reauthentication with the mobile communication network.

[0146] In some embodiments, the network function comprises a gateway function of a mobile communication network (i.e., a TNGF in the TNAN) that obtains a reauthentication security context for subsequent reauthentication of the device in response to the first authentication message including an ERP indicator.

[0147] In some embodiments, the derived reauthentication security context includes an rRK and a key identifier for the rRK (i.e., EMSKname and / or Kausfname). In such embodiments, the rRK is derived based on an EMSK, a SUPI, and a serving network name (i.e., 5G: Serving Network ID) using a key derivation function. Alternatively, the rRK is derived based on an authentication server function key (i.e., AUSF key), a SUPI, and a serving network name using a key derivation function.

[0148] In certain embodiments, in response to deriving the rRK based on the EMSK, the processor 605 derives a key identifier for the rRK (i.e., “EMSKname”) based on at least the SUPI and the serving network name using a key derivation function. In other embodiments, in response to deriving the rRK based on the AUSF key, the processor 605 derives a key identifier for the rRK (i.e., “Kausfname”) based on the SUPI, the serving network name, and the AUSF key using a key derivation function, wherein the Kausfname is used for subsequent reauthentication procedures.

[0149] In some embodiments, the processor 605 further receives a third authentication message from a new access point of the mobile communication network in response to the user equipment device 600 connecting to the new access point in the TNAN. Here, the third authentication message includes a second key management domain name.

[0150] In certain embodiments, the processor 605 derives a reauthentication integrity key (i.e., “rIK”) for securely exchanging and verifying ERP messages with the network function, wherein the processor 605 derives the rIK at least in part from the key management domain name and a sequence number (i.e., “SEQ”). In such embodiments, the processor 605 can further increment the received SEQ prior to deriving the rIK using the SEQ.

[0151] In certain embodiments, the processor 605 verifies whether the second key management domain name matches a locally stored key management domain name associated with the reauthentication security context. In such embodiments, the processor 605 further generates an NAI and sends a fourth authentication message containing the NAI to the new access point in response to verifying that the second key management domain name matches the locally stored key management domain name, the generated NAI being locally stored at the device for subsequent reference.

[0152] In certain embodiments, the NAI is generated based on a key identifier for the rRK (i.e., "EMSKname") and a domain name that is generated using an identifier for a network gateway function previously authenticated in the TNAN and a key management domain name, such that the NAI has the form "EMSKname@Domain-name".

[0153] In some embodiments, the processor 605 further receives, from the new access point, a fifth authentication message including an updated NAI, and verifies that the domain name for the updated NAI matches the locally stored domain name. In certain embodiments, the processor 605 deletes the currently locally stored domain name and locally stores the updated domain name and re-authentication security context in response to verifying that the domain name for the updated NAI matches the locally stored domain name.

[0154] In some embodiments, the processor 605 sends, to the new access point, a domain mismatch indicator in the EAP-Initiate / Re-auth message in response to failing to verify that the received key management domain name matches the locally stored key management domain name, to trigger an initial EAP full authentication of the apparatus.

[0155] In one embodiment, the memory 610 is a computer readable storage medium. In some embodiments, the memory 610 includes both volatile and nonvolatile computer storage media. For example, the memory 610 can include both a volatile computer storage medium and a nonvolatile computer storage medium. In some embodiments, the memory 610 includes a volatile computer storage medium, but not a nonvolatile computer storage medium. In some embodiments, the memory 610 includes a nonvolatile computer storage medium, but not a volatile computer storage medium.

[0156] In some embodiments, the memory 610 stores data relating to supporting remote unit re-authentication, e.g., stores security keys, IP addresses, etc. In certain embodiments, the memory 610 also stores program code and related data, such as an operating system ("OS") or other controller algorithms operating on the user equipment apparatus 600 and one or more software applications.

[0157] In one embodiment, input device 615 can include any known computer input device, including a touch panel, buttons, a keyboard, a stylus, a microphone, or the like. In some embodiments, input device 615 can be integrated with output device 620, e.g., as a touch screen or similar touch-sensitive display. In some embodiments, input device 615 includes a touch screen such that text can be input using a virtual keyboard displayed on the touch screen and / or by handwriting on the touch screen. In some embodiments, input device 615 includes two or more different devices, such as a keyboard and a touch panel.

[0158] In one embodiment, output device 620 can include any known electronically controllable display or display device. Output device 620 can be designed to output visual, audible, and / or tactile signals. In some embodiments, output device 620 includes an electronic display capable of outputting visual data to a user. For example, output device 620 can include, but is not limited to, an LCD display, a LED display, an OLED display, a projector, or similar display device capable of outputting images, text, etc., to a user. As another non-limiting example, output device 620 can include a wearable display such as a smart watch, smart glasses, a heads-up display, or the like. Further, output device 620 can be a component of a smart phone, a personal digital assistant, a television, a table computer, a notebook (laptop) computer, a personal computer, a vehicle dashboard, or the like.

[0159] In certain embodiments, output device 620 includes one or more speakers for producing sound. For example, output device 620 can produce an audible alert or notification (e.g., a beep or chime). In some embodiments, output device 620 includes one or more haptic devices for producing vibrations, motion, or other haptic feedback. In some embodiments, all or portions of output device 620 can be integrated with input device 615. For example, input device 615 and output device 620 can form a touch screen or similar touch-sensitive display. In other embodiments, all or portions of output device 620 can be located near input device 615.

[0160] As discussed above, transceiver 625 communicates with one or more network functions of a mobile communication network via one or more access networks. Transceiver 625 operates under the control of processor 605 to transmit and to receive messages, data, and other signals. For example, processor 605 can selectively activate the transceiver (or portions thereof) at special times to facilitate transmission and reception of messages.

[0161] The transceiver 625 can include one or more transmitters 630 and one or more receivers 635. Although only one transmitter 630 and one receiver 635 are illustrated, the user equipment apparatus 600 can have any suitable number of transmitters 630 and receivers 635. Further, the transmitter(s) 630 and the receiver(s) 635 can be any suitable type of transmitters and receivers. In one embodiment, the transceiver 625 includes a first transmitter / receiver pair for communicating with a mobile communication network over licensed radio spectrum and a second transmitter / receiver pair for communicating with a mobile communication network over unlicensed radio spectrum.

[0162] In certain embodiments, the first transmitter / receiver pair for communicating with a mobile communication network over licensed radio spectrum and the second transmitter / receiver pair for communicating with a mobile communication network over unlicensed radio spectrum can be combined into a single transceiver unit, e.g., a single chip that performs functions used with both licensed and unlicensed radio spectrum. In some embodiments, the first transmitter / receiver pair and the second transmitter / receiver pair can share one or more hardware components. For example, certain transceivers 625, transmitters 630, and receivers 635 can be implemented as physically separate components that access shared hardware resources and / or software resources, such as, for example, the network interface 640.

[0163] In various embodiments, one or more transmitters 630 and / or one or more receivers 635 can be implemented and / or integrated into a single hardware component, such as a multi-transceiver chip, a system-on-a-chip, an ASIC, or other type of hardware component. In some embodiments, one or more transmitters 630 and / or one or more receivers 635 can be implemented and / or integrated into a multi-chip module. In some embodiments, other components, such as the network interface 640, or other hardware components / circuitry, can be integrated into a single chip with any number of transmitters 630 and / or receivers 635. In such embodiments, the transmitters 630 and receivers 635 can be logically configured as a transceiver 625 that uses more one common control signal, or implemented as modular transmitters 630 and receivers 635 implemented in the same hardware chip or multi-chip module.

[0164] Figure 7One embodiment of a network equipment apparatus 700 is depicted in accordance with embodiments of the present disclosure. In some embodiments, the network equipment apparatus 700 can be one embodiment of a TNGF (i.e., TNGF1 and / or TNGF2). In other embodiments, the network equipment apparatus 700 can be one embodiment of an AMF. Further, the network equipment apparatus 700 can include a processor 705, a memory 710, an input device 715, an output device 720, a transceiver 725. In some embodiments, the input device 715 and the output device 720 are combined into a single device, such as a touch screen. In certain embodiments, the network equipment apparatus 700 does not include any input device 715 and / or output device 720.

[0165] As depicted, the transceiver 725 includes at least one transmitter 730 and at least one receiver 735. Here, the transceiver 725 communicates with one or more remote units 105. Additionally, the transceiver 725 can support one or more network interfaces 740 for communication with one or more other network elements. For example, the network interfaces 740 can support the X2 interface Figure 1 The NWt, N2, and N3 interfaces depicted in FIG. 9. In some embodiments, the transceiver 725 supports a first interface for communications with a RAN node, a second interface for communications with one or more network functions in a mobile core network (e.g., 5GC), and a third interface for communications with a remote unit (e.g., a UE).

[0166] In one embodiment, the processor 705 can include any known controller or processor capable of executing computer program instructions and / or capable of performing logical operations. For example, the processor 705 can be a microcontroller, a microprocessor, a central processing unit (“CPU”), a graphics processing unit (“GPU”), an auxiliary processing unit, a field programmable gate array (“FPGA”), or similar programmable controller. In some embodiments, the processor 705 executes instructions stored in the memory 710 to perform methods and routines described herein. The processor 705 is communicatively coupled to the memory 710, the input device 715, the output device 720, and the first transceiver 725.

[0167] In various embodiments, the processor 705 controls the network equipment apparatus 700 to implement the above-described TNGF behavior. In some embodiments, the processor 705 receives a first authentication message for re authenticating a remote unit (i.e., UE), where the first authentication message includes a Keyname-NAI containing a first username (e.g., Keyname or other key identifier) and a first domain name. Here, the first domain name identifies a key management domain name and an associated gateway function that holds a re-authentication security context. The processor 705 validates the first domain name and verifies the first authentication message using at least a re-authentication integrity key (“rIK”) from a security context identified by the first username. The processor 705 generates a second authentication message in response to successfully verifying the first authentication message and responds to the first authentication message by sending the second authentication message via the network interface 740.

[0168] In some embodiments, the first authentication message contains a first sequence number (i.e., “SEQ”) and a first message authentication code, where the processor 705 authenticates the remote unit using the first message authentication code. In some embodiments, the first username includes a key identifier for a re-authentication root key (i.e., “rRK”). In certain embodiments, the processor 705 generates a fresh session key in response to verifying the first authentication message, where the fresh session key is derived using at least the rRK and a trusted non-3GPP access code as inputs to a key derivation.

[0169] In some embodiments, the processor 705 determines whether a re-authentication integrity key (i.e., “rIK”) is stored in local memory. In certain embodiments, the processor 705 derives a new rIK using at least the rRK, a key management domain name, and a received SEQ number in response to the rIK not being stored in local memory or receiving a different SEQ value that is higher than a locally stored SEQ, where the fresh rIK is used to authenticate the first message authentication code. In certain embodiments, the second authentication message contains a second message authentication code that is derived using the fresh rIK, where the remote unit authenticates the second apparatus using the second message authentication code.

[0170] In some embodiments, the first authentication message is received from a gateway function that serves the remote unit. In such embodiments, the second authentication message includes a re-authentication security context and is sent to the gateway function. In certain embodiments, the re-authentication security context contains the rRK, the rIK, the SEQ, and a rRK lifetime parameter. In other embodiments, the first authentication message is received from an access point that serves the remote unit. In such embodiments, the second authentication message is sent to the remote unit via the serving access point.

[0171] In some embodiments, the processor 705 receives a registration request from a remote unit, the registration request indicating that the remote unit supports ERP. In such embodiments, the processor 705 sends a gateway identifier and a key management domain name to the remote unit during a registration procedure for the remote unit.

[0172] In various embodiments, the processor 705 controls the network equipment apparatus 700 to implement the above-described TNGF-2 behavior. In such embodiments, the processor 705 receives a first authentication message for re-authenticating a remote unit (i.e., a UE), where the first authentication message includes a Keyname-NAI that includes a first username (e.g., a Keyname or other key identifier) and a first domain name. Here, the first domain name identifies a key management domain name and an associated gateway function that holds a re-authentication security context. The processor 705 validates the first domain name and determines from the NAI (e.g., from TNGF identification information indicated as part of the first domain name and the first username) that the re-authentication security context for the remote unit is held by a source gateway function (i.e., TNGF-1). The processor 705 forwards the first authentication message to the source gateway function based on associated gateway function contact information available as part of the first domain name and receives the re-authentication security context from the source gateway function. The processor 705 generates a second authentication message in response to receiving the re-authentication security context and sends the second authentication message to the remote unit.

[0173] In some embodiments, the processor 705 updates the NAI (e.g., the domain name portion of the Keyname-NAI) to point to the apparatus in response to receiving the re-authentication security context, where the second authentication message includes the updated NAI. In some embodiments, the first username includes a key identifier for a re-authentication root key (i.e., “rRK”), where the processor 705 generates a fresh session key in response to receiving the re-authentication security context, and where the fresh session key is derived using at least the rRK and a trusted non-3GPP access code as inputs to a key derivation.

[0174] In some embodiments, the second authentication message includes a message authentication code derived using the re-authentication security context, where the remote unit uses the second message authentication code to authenticate the apparatus. In some embodiments, the re-authentication security context includes an rRK, a fresh re-authentication integrity key (i.e., “rIK”), a sequence number (i.e., “SEQ”), and a re-authentication root key lifetime parameter.

[0175] In various embodiments, the processor 705 controls the network equipment apparatus 700 to implement the TNAP behavior described above. In some embodiments, the processor 705 receives a first KM-domain name from a gateway function during association between the access point and the gateway function, the first key management domain name being forwarded to a remote unit (i.e., UE) for reauthentication. The processor 705 receives a first authentication message for reauthenticating the remote unit. In one embodiment, the first authentication message includes a key management domain name mismatch indicator. In another embodiment, the first authentication message includes a NAI (i.e., Keyname-NAI) that includes a first username and a first domain name, where the first domain name identifies a second KM-domain name and an associated gateway function that holds a reauthentication security context for the remote unit.

[0176] The processor 705 determines that the key management domain names do not match based on the first authentication message. In some embodiments, the processor 705 determines that the key management domain names do not match includes identifying that the first authentication message includes a key management domain name mismatch indicator. In other embodiments, the processor 705 determines that the key management domain names do not match by examining the Keyname-NAI and identifying that the second KM-domain name does not match the first KM-domain name.

[0177] The processor 705 rejects the reauthentication of the remote unit in response to the determined mismatch and triggers an initial authentication with the remote unit in response to the rejected reauthentication.

[0178] In one embodiment, the memory 710 is a computer readable storage medium. In some embodiments, the memory 710 includes both volatile and nonvolatile computer storage media. For example, the memory 710 can include both a RAM, including dynamic RAM (“DRAM”), synchronous dynamic RAM (“SDRAM”), and / or static RAM (“SRAM”), and nonvolatile computer storage media. In some embodiments, the memory 710 includes nonvolatile computer storage media. For example, the memory 710 can include a hard disk drive, flash memory, or any other suitable nonvolatile computer storage device. In some embodiments, the memory 710 includes both volatile and nonvolatile computer storage media.

[0179] In some embodiments, the memory 710 stores data relating to supporting remote unit reauthentication, such as storing security keys, IP addresses, UE contexts, and the like. In certain embodiments, the memory 710 also stores program code and related data, such as an operating system (“OS”) or other controller algorithms and one or more software applications that operate on the network equipment apparatus 700.

[0180] In one embodiment, input device 715 can include any known computer input device, including a touch panel, buttons, a keyboard, a stylus, a microphone, or the like. In some embodiments, input device 715 can be integrated with output device 720, e.g., as a touch screen or similar touch-sensitive display. In some embodiments, input device 715 includes a touch screen such that text can be input using a virtual keyboard displayed on the touch screen and / or by handwriting on the touch screen. In some embodiments, input device 715 includes two or more different devices, such as a keyboard and a touch panel.

[0181] In one embodiment, output device 720 can include any known electronically controllable display or display device. Output device 720 can be designed to output visual, audible, and / or tactile signals. In some embodiments, output device 720 includes an electronic display capable of outputting visual data to a user. For example, output device 720 can include, but is not limited to, an LCD display, an LED display, an OLED display, a projector, or similar display device capable of outputting images, text, etc., to a user. As another, non-limiting, example, output device 720 can include a wearable display such as a smart watch, smart glasses, a heads-up display, or the like. Further, output device 720 can be a component of a smart phone, a personal digital assistant, a television, a table computer, a notebook (laptop) computer, a personal computer, a vehicle dashboard, or the like.

[0182] In certain embodiments, output device 720 includes one or more speakers for producing sound. For example, output device 720 can produce an audible alert or notification (e.g., a beep or chime). In some embodiments, output device 720 includes one or more haptic devices for producing vibrations, motion, or other tactile feedback. In some embodiments, all or portions of output device 720 can be integrated with input device 715. For example, input device 715 and output device 720 can form a touch screen or similar touch-sensitive display. In other embodiments, all or portions of output device 720 can be located near input device 715.

[0183] As discussed above, transceiver 725 can communicate with one or more remote units and / or with one or more interworking functions that provide access to one or more PLMNs. Transceiver 725 can also communicate with one or more network functions (e.g., in mobile core network 140). Transceiver 725 operates under the control of processor 705 to transmit and to receive messages, data, and other signals. For example, processor 705 can selectively activate the transceiver (or portions thereof) at particular times in order to transmit and to receive messages.

[0184] The transceiver 725 can include one or more transmitters 730 and one or more receivers 735. In certain embodiments, the one or more transmitters 730 and / or the one or more receivers 735 can share transceiver hardware and / or circuitry. For example, the one or more transmitters 730 and / or the one or more receivers 735 can share antennas, antenna tuners, amplifiers, filters, oscillators, mixers, modulators / demodulators, power supplies, and so on. In one embodiment, the transceiver 725 implements multiple logical transceivers using different communication protocols or protocol stacks, while using common physical hardware.

[0185] Figure 8 One embodiment of a method 800 for supporting remote unit reauthentication, in accordance with embodiments of the disclosure, is depicted. In various embodiments, the method 800 is performed by a UE, such as the remote unit 105, the UE 205, and / or the user equipment apparatus 600, described above. In some embodiments, the method 800 is performed by a processor, such as a microcontroller, a microprocessor, a CPU, a GPU, an auxiliary processing unit, a FPGA, or the like.

[0186] The method 800 begins and sends 805 a first authentication message to a network function to authenticate a remote unit with a mobile communication network, the first authentication message containing an indicator that the remote unit supports ERP. The method 800 includes receiving 810 a second authentication message from the network function in response to the first authentication message, wherein the second authentication message contains a key management domain name that indicates a set of network functions that are capable of sharing a reauthentication security context of a device for performing ERP.

[0187] The method 800 includes deriving 815 a reauthentication security context in response to a successful authentication with the mobile communication network. The method 800 includes locally storing 820 the received key management domain name and the derived reauthentication security context for subsequent reauthentication with the mobile communication network. The method 800 ends.

[0188] Figure 9 One embodiment of a method 900 for supporting remote unit reauthentication, in accordance with embodiments of the disclosure, is depicted. In various embodiments, the method 900 is performed by a TNGF, such as the TNGF-l 115, the TNGF-2 117, the TNGF 213, the TNGF-l 401, and / or the network equipment apparatus 700, described above. In some embodiments, the method 900 is performed by a processor, such as a microcontroller, a microprocessor, a CPU, a GPU, an auxiliary processing unit, a FPGA, or the like.

[0189] The method 900 begins and receives 905 a first authentication message for re authenticating a remote unit, where the first authentication message includes a NAI that includes a first username and a first realm name. The method 900 includes verifying 910 the first realm name, where the first realm name identifies a key management realm name and an associated gateway function that holds a re authentication security context.

[0190] The method 900 includes verifying 915 the first authentication message using at least the re authentication security context indicated by the first username. The method 900 includes generating 920 a second authentication message in response to successfully verifying the first authentication message. The method 900 includes responding 925 to the first authentication message by sending the second authentication message. The method 900 ends.

[0191] Figure 10 One embodiment of a method 1000 for supporting remote unit re authentication is depicted in accordance with an embodiment of the present disclosure. In various embodiments, the method 1000 is performed by a target TNGF, such as the TNGF-2 117, TNGF-2 403, described above, and / or the network equipment apparatus 700. In some embodiments, the method 1000 is performed by a processor, such as a microcontroller, a microprocessor, a CPU, a GPU, an auxiliary processing unit, a FPGA, or the like.

[0192] The method 1000 begins and receives 1005 a first authentication message for re authenticating a remote unit, where the first authentication message includes a NAI that includes a first username and a first realm name. The method 1000 includes verifying 1010 the first realm name, where the first realm name identifies a key management realm name and an associated gateway function that holds a re authentication security context.

[0193] The method 1000 includes determining 1015 from the NAI that the re authentication security context for the remote unit is held by a source gateway function. The method 1000 includes forwarding 1020 the first authentication message to the source gateway function. The method 1000 includes receiving 1025 the re authentication security context from the source gateway function.

[0194] The method 1000 includes generating 1030 a second authentication message in response to receiving the re authentication security context. The method 1000 includes sending 1035 the second authentication message to the remote unit. The method 1000 ends.

[0195] Figure 11One embodiment of a method 1100 for supporting remote unit reauthentication is depicted in accordance with embodiments of the present disclosure. In various embodiments, the method 1100 is performed by a non-3GPP access point, such as the base unit 100, the TNAP-1 211, the TNAP-2 303, and / or the network equipment apparatus 700 described above. In some embodiments, the method 1100 is performed by a processor, such as a microcontroller, a microprocessor, a CPU, a GPU, an auxiliary processing unit, a FPGA, or the like.

[0196] The method 1100 begins and receives 1105 a first key management domain name from a gateway function during an association between the access point and the gateway function, the key management domain name being forwarded to a remote unit for reauthentication.

[0197] The method 1100 includes receiving 1110 a first authentication message for reauthenticating the remote unit, wherein the first authentication message includes a key management domain name mismatch indicator and / or a NAI containing a first username and a first domain name, wherein the first domain name identifies a second key management domain name and an associated gateway function that holds a reauthentication security context for the remote unit.

[0198] The method 1100 includes determining 1115 a key management domain name mismatch. The method 1100 includes rejecting 1120 reauthentication of the remote unit in response to the determined mismatch. The method 1100 includes triggering 1125 an initial authentication with the remote unit in response to the rejected reauthentication. The method 1100 ends.

[0199] In accordance with embodiments of the present disclosure, a first apparatus for supporting remote unit reauthentication is disclosed herein. The first apparatus can be implemented by a UE, such as the remote unit 105, the UE 205, and / or the user equipment apparatus 600. The first apparatus comprises:

[0200] a transceiver that communicates with a mobile communication network using a trusted non-3GPP access network, TNAN, and a processor that sends a first authentication message to a network function to authenticate with the mobile communication network, the first authentication message containing an indicator that the apparatus supports ERP. Via the transceiver, the processor receives a second authentication message from the network function in response to the first authentication message, wherein the second authentication message contains a key management domain name that indicates a set of network functions that can share a reauthentication security context of the apparatus for performing ERP. In response to successful authentication with the mobile communication network, the processor derives the reauthentication security context and locally stores the received key management domain name and the derived reauthentication security context for subsequent reauthentication with the mobile communication network.

[0201] In some embodiments, the network function comprises a gateway function of a mobile communication network, the gateway function obtaining the reauthentication security context for subsequent reauthentication of the device in response to the first authentication message including the ERP indicator.

[0202] In some embodiments, the derived reauthentication security context comprises a reauthentication root key (i.e.,“rRK”) and a key identifier for the rRK. In one embodiment, the rRK is derived based on the EMSK, the SUPI, and the serving network name / home network ID using a key derivation function. In another embodiment, the rRK is derived based on the AUSF key, the SUPI, and the serving network name / home network ID using a key derivation function.

[0203] In certain embodiments, in response to deriving the rRK based on the EMSK, a key identifier for the rRK (i.e.,“EMSKname”) is derived based on at least the SUPI and the serving network name / home network ID using a key derivation function. In certain embodiments, in response to deriving the rRK based on the AUSF key, a key identifier for the rRK (i.e.,“Kausfname”) is derived based on the SUPI, the serving network name / home network ID, and the AUSF key using a key derivation function, wherein the Kausfname is used for subsequent reauthentication procedures.

[0204] In some embodiments, the processor further receives, from the new access point of the mobile communication network, a third authentication message in response to the device connecting to the new access point in the TNAN, the third authentication message including a second key management domain name.

[0205] In certain embodiments, the processor further derives a fresh reauthentication integrity key (i.e.,“rIK”) for securely exchanging and verifying ERP messages with the network function, the RIK being derived at least in part from the key management domain name and a sequence number (i.e.,“SEQ”). In such embodiments, the processor can further increment the received SEQ prior to deriving the fresh rIK using the SEQ.

[0206] In certain embodiments, the processor further verifies whether the second key management domain name matches a locally stored key management domain name associated with the reauthentication security context. In such embodiments, the processor further generates a NAI and sends a fourth authentication message containing the NAI to the new access point in response to verifying that the second key management domain name matches the locally stored key management domain name, the generated NAI being locally stored in the device for subsequent reference.

[0207] In certain embodiments, the NAI in the form of Keyname-NAI is generated based on a rRK-based key identifier (i.e., "EMSKname") and a domain name generated using an identifier of a network gateway function previously authenticated in the TNAN and a key management domain name, such that the NAI has the form of "EMSKname@Domain-name".

[0208] In some embodiments, the processor further receives, from the new access point, a fifth authentication message including an updated NAI, and verifies that a domain name for the updated NAI matches the locally stored domain name. In certain embodiments, the processor further deletes the currently locally stored domain name and locally stores the updated domain name and the reauthentication security context in response to verifying that the domain name for the updated NAI matches the locally stored domain name.

[0209] In some embodiments, the processor sends, to the new access point, a domain mismatch indicator in an EAP-Initiate / Re-auth message in response to verifying that the received key management domain name fails to match the locally stored key management domain name, to trigger an initial EAP full authentication of the device.

[0210] Disclosed herein, in accordance with embodiments of the disclosure, is a first method for supporting remote unit reauthentication. The first method can be performed by a UE, such as the remote unit 105, the UE 205, and / or the user equipment apparatus 600. The first method includes sending, to a network function, a first authentication message to authenticate the UE with a mobile communication network and receiving, from the network function, a second authentication message in response to the first authentication message. Here, the first authentication message contains an indicator that the UE supports ERP and the second authentication message contains a key management domain name that indicates a set of network functions that can share a reauthentication security context of the UE for performing ERP. The first method includes deriving a reauthentication security context in response to a successful authentication with the mobile communication network and locally storing the received key management domain name and the derived reauthentication security context for subsequent reauthentication with the mobile communication network.

[0211] In some embodiments, the network function includes a gateway function of the mobile communication network that obtains the reauthentication security context for subsequent reauthentication of the device in response to the first authentication message including the ERP indicator.

[0212] In some embodiments, the derived re-authentication security context includes a re-authentication root key (i.e.,“rRK”) and a key identifier for the rRK. In one embodiment, the rRK is derived using a key derivation function based on the EMSK, the SUPI, and the serving network name / home network ID. In another embodiment, the rRK is derived using a key derivation function based on the AUSF key, the SUPI, and the serving network name / home network ID.

[0213] In certain embodiments, in response to deriving the rRK based on the EMSK, the key identifier for the rRK (i.e.,“EMSKname”) is derived using a key derivation function based on at least the SUPI and the serving network name / home network ID. In certain embodiments, in response to deriving the rRK based on the AUSF key, the key identifier for the rRK (i.e.,“Kausfname”) is derived using a key derivation function based on the SUPI, the serving network name / home network ID, and the AUSF key, where the Kausfname is used for a subsequent re-authentication procedure.

[0214] In some embodiments, the first method further includes receiving, from the new access point of the mobile communication network, a third authentication message in response to the device connecting to the new access point in the TNAN, the third authentication message including a second key management domain name.

[0215] In certain embodiments, the first method further includes deriving a fresh re- authentication integrity key (i.e.,“rIK”) for securely exchanging and verifying ERP messages with the network function, the rIK being derived at least in part from the key management domain name and a sequence number (i.e.,“SEQ”). In such embodiments, the first method can further include incrementing the received SEQ prior to deriving the fresh rIK using the SEQ.

[0216] In certain embodiments, the first method further includes verifying whether the second key management domain name matches a locally stored key management domain name associated with the re-authentication security context. In such embodiments, in response to verifying that the second key management domain name matches the locally stored key management domain name, the first method further includes generating an NAI and sending a fourth authentication message containing the NAI to the new access point, the generated NAI being locally stored in the device for subsequent reference.

[0217] In certain embodiments, the NAI is generated based on the key identifier for the rRK (i.e.,“EMSKname”) and a domain name, the domain name being generated using an identifier for a network gateway function used for a previous authentication in the TNAN and a key management domain name, such that the NAI has the form“EMSKname@Domain-name”.

[0218] In some embodiments, the first method further includes receiving a fifth authentication message including an updated NAI from the new access point and verifying that the domain name for the updated NAI matches the locally stored domain name. In certain embodiments, in response to verifying that the domain name for the updated NAI matches the locally stored domain name, the first method includes deleting the currently locally stored domain name and locally storing the updated domain name and the reauthentication security context.

[0219] In some embodiments, the first method includes sending a domain mismatch indicator to the new access point in the EAP-Initiate / Re-auth message in response to failing to verify that the received key management domain name matches the locally stored key management domain name to trigger an initial EAP full authentication of the remote unit.

[0220] According to embodiments of the present disclosure, disclosed herein is a second apparatus for supporting remote unit reauthentication. The second apparatus can be implemented by a TNGF such as the TNGF-1 115, the TNGF-2 117, the TNGF 213, the TNGF-1 401 and / or the network equipment apparatus 700. The second apparatus includes a network interface that communicates with a mobile communication network and a processor that receives a first authentication message for reauthenticating a remote unit (i.e., UE), where the first authentication message includes a NAI containing a first username and a first domain name. The processor verifies the first domain name and authenticates the first authentication message using at least a reauthentication security context indicated by the first username. Here, the first domain name identifies a key management domain name and an associated gateway function that holds the reauthentication security context. The processor generates a second authentication message in response to successfully authenticating the first authentication message and responds to the first authentication message by sending the second authentication message via the network interface.

[0221] In some embodiments, the first authentication message contains a first sequence number (i.e., “SEQ”) and a first message authentication code, where the processor authenticates the remote unit using the first message authentication code. In some embodiments, the first username includes a key identifier for a reauthentication root key (i.e., “rRK”). In certain embodiments, the processor generates a fresh session key in response to authenticating the first authentication message, where the fresh session key is derived using at least the rRK and a trusted non-3GPP access code as inputs to a key derivation.

[0222] In some embodiments, the processor determines whether a reauthentication integrity key (i.e., "rIK") is stored in local memory. In certain embodiments, the processor derives a fresh rIK using at least the rRK, the key management domain name, and the received SEQ number in response to the rIK not being stored in local memory or a different SEQ number being received that is higher than the locally stored SEQ, where the fresh rIK is used to authenticate a first message authentication code. In certain embodiments, the second authentication message contains a second message authentication code derived using the fresh rIK, where the remote unit uses the second message authentication code to authenticate the second device.

[0223] In some embodiments, the first authentication message is received from a gateway function serving the remote unit. In such embodiments, the second authentication message includes a reauthentication security context and is sent to the gateway function. In certain embodiments, the reauthentication security context contains the rRK, the rIK, the SEQ, and a rRK lifetime parameter. In other embodiments, the first authentication message is received from an access point serving the remote unit. In such embodiments, the second authentication message is sent to the remote unit via the serving access point.

[0224] In some embodiments, the processor receives a registration request from the remote unit, the registration request indicating that the remote unit supports ERP. In such embodiments, the processor sends a gateway identifier and a key management domain name to the remote unit during a registration procedure for the remote unit.

[0225] According to embodiments of the present disclosure, disclosed herein is a second method for supporting remote unit reauthentication. The second method can be implemented by a TNGF such as TNGF-1 115, TNGF-2 117, TNGF 213, TNGF-1 401, and / or network device 700. The second method includes receiving a first authentication message for reauthenticating a remote unit (i.e., UE). Here, the first authentication message includes a NAI containing a first username and a first domain name. The second method includes verifying the first domain name and authenticating the first authentication message using at least a reauthentication security context indicated by the first username. Here, the first domain name identifies a key management domain name and an associated gateway function that holds the reauthentication security context. The second method includes generating a second authentication message in response to successfully authenticating the first authentication message and responding to the first authentication message by sending the second authentication message.

[0226] In some embodiments, the first authentication message includes a first sequence number (i.e., “SEQ”) and a first message authentication code, where the TNGF uses the first message authentication code to authenticate the remote unit. In some embodiments, the first username includes a key identifier for a reauthentication root key (i.e., “rRK”). In certain embodiments, the second method further includes generating a fresh session key in response to verifying the first authentication message, where the fresh session key is derived using at least the rRK and the trusted non-3GPP access code as inputs to a key derivation.

[0227] In some embodiments, the second method includes determining whether a reauthentication integrity key (i.e., “rIK”) is stored in local memory. In certain embodiments, the second method further includes deriving a fresh rIK using at least the rRK, a key management domain name, and a received SEQ number in response to the rIK not being stored in local memory or receiving a different SEQ of a higher value than a locally stored SEQ, where the fresh rIK is used to authenticate the first message authentication code. In certain embodiments, the second authentication message includes a second message authentication code derived using the fresh rIK, where the remote unit uses the second message authentication code to authenticate the TNGF.

[0228] In some embodiments, the first authentication message is received from a gateway function serving the remote unit. In such embodiments, the second authentication message includes a reauthentication security context and is sent to the gateway function. In certain embodiments, the reauthentication security context includes the rRK, the rIK, the SEQ, and an rRK lifetime parameter. In other embodiments, the first authentication message is received from an access point serving the remote unit. In such embodiments, the second authentication message is sent to the remote unit via the serving access point.

[0229] In some embodiments, the second method further includes receiving a registration request from the remote unit, the registration request indicating that the remote unit supports ERP. In such embodiments, the second method further includes sending a gateway identifier and a key management domain name to the remote unit during a registration procedure for the remote unit.

[0230] According to embodiments of the present disclosure, disclosed herein is a third apparatus for supporting remote unit reauthentication. The third apparatus can be implemented by a target TNGF, such as TNGF-2 117, TNGF-2 403, and / or network equipment apparatus 700. The third apparatus includes a network interface that communicates with a mobile communication network, and a processor that receives a first authentication message for reauthenticating a remote unit (i.e., UE), where the first authentication message includes a NAI that includes a first username and a first realm name. The processor verifies the first realm name and determines from the NAI that a reauthentication security context for the remote unit is held by a source gateway function. Here, the first realm name identifies a key management realm name and an associated gateway function that holds the reauthentication security context. The processor forwards the first authentication message to the source gateway function and receives the reauthentication security context from the source gateway function. The processor generates a second authentication message in response to receiving the reauthentication security context and sends the second authentication message to the remote unit.

[0231] In some embodiments, the processor updates the NAI to point to the apparatus in response to receiving the reauthentication security context, where the second authentication message includes the updated NAI. In some embodiments, the first username includes a key identifier for a reauthentication root key (i.e., “rRK”), where the processor generates a fresh session key in response to receiving the reauthentication security context, and where the fresh session key is derived using at least the rRK and a trusted non-3GPP access code as inputs to a key derivation.

[0232] In some embodiments, the second authentication message includes a message authentication code derived using the reauthentication security context, where the remote unit uses the second message authentication code to authenticate the apparatus. In some embodiments, the reauthentication security context includes the rRK, a fresh reauthentication integrity key (i.e., “rIK”), a sequence number (i.e., “SEQ”), and a reauthentication root key lifetime parameter.

[0233] Disclosed herein, according to embodiments of the disclosure, is a third method for supporting remote unit reauthentication. The third method includes can be implemented by a target TNGF, such as TNGF-2 117, TNGF-2 403, and / or network equipment apparatus 700. The third method includes receiving a first authentication message for reauthenticating a remote unit. Here, the first authentication message includes a NAI that includes a first username and a first realm name. The third method includes verifying the first realm name and determining from the NAI that a reauthentication security context for the remote unit is held by a source gateway function. Here, the first realm name identifies a key management realm name and an associated gateway function that holds the reauthentication security context. The third method includes forwarding the first authentication message to the source gateway function and receiving the reauthentication security context from the source gateway function. The third method includes generating a second authentication message in response to receiving the reauthentication security context and sending the second authentication message to the remote unit.

[0234] In some embodiments, the third method includes updating the NAI to point to the apparatus in response to receiving the reauthentication security context, where the second authentication message includes the updated NAI. In some embodiments, the first username includes a key identifier for a reauthentication root key (i.e., “rRK”), where the third method includes generating a fresh session key in response to receiving the reauthentication security context, and where the fresh session key is derived using at least the rRK and a trusted non-3GPP access code as inputs to a key derivation.

[0235] In some embodiments, the second authentication message includes a message authentication code derived using the reauthentication security context, where the remote unit uses the second message authentication code to authenticate the apparatus. In some embodiments, the reauthentication security context includes an rRK, a fresh reauthentication integrity key (i.e., “rIK”), a sequence number (i.e., “SEQ”), and a reauthentication root key lifetime parameter.

[0236] According to embodiments of the present disclosure, disclosed herein is a fourth apparatus for supporting remote unit reauthentication. The fourth apparatus can be implemented by a non-3GPP access point, such as base unit 100, TNAP 211, TNAP-2 303, and / or network equipment apparatus 700. The fourth apparatus includes a transceiver that communicates with a remote unit, and a processor that receives a key management domain name from a gateway function during an association between the access point and the gateway function, the key management domain name being forwarded to the remote unit for reauthentication. The processor receives a first authentication message for reauthenticating the remote unit. Here, the first authentication message includes one of: a key management domain name mismatch indicator and a NAI containing a first username and a first domain name, where the first domain name identifies the key management domain name and an associated gateway function that holds a reauthentication security context for the remote unit. The processor determines that the key management domain name does not match based on the first authentication message. The processor rejects the reauthentication of the remote unit in response to the determined mismatch and triggers an initial authentication with the remote unit in response to the rejected reauthentication.

[0237] According to embodiments of the present disclosure, disclosed herein is a fourth method for supporting remote unit reauthentication. The fourth method can be implemented by a non-3GPP access point, such as base unit 100, TNAP 211, TNAP-2 303, and / or network equipment apparatus 700. The fourth method includes receiving a key management domain name from a gateway function during an association between the access point and the gateway function, the key management domain name being forwarded to the remote unit for reauthentication. The fourth method includes receiving a first authentication message for reauthenticating the remote unit and determining that the key management domain name does not match. Here, the first authentication message includes one of: a key management domain name mismatch indicator and a NAI containing a first username and a first domain name, where the first domain name identifies the key management domain name and an associated gateway function that holds a reauthentication security context for the remote unit. The fourth method includes determining that the key management domain name does not match based on the first authentication message. The fourth method includes rejecting the reauthentication of the remote unit in response to the determined mismatch and triggering an initial authentication with the remote unit in response to the rejected reauthentication.

[0238] Embodiments can be practiced in other specific forms. The described embodiments are to be considered in all respects only as illustrative and not restrictive. The scope of the application is, therefore, indicated by the appended claims rather than by the foregoing description. All changes that come within the meaning and range of equivalency of the claims are to be embraced within their scope.

Claims

1. A gateway device comprising: a memory; and a processor coupled with the memory and configured to cause the gateway device to: receive a first authentication message for re-authenticating a user equipment (UE), wherein the first authentication message comprises a first sequence number (SEQ), a first message authentication code for authenticating the UE, and a network access identifier (NAI) containing a first username and a first domain name; verify the first domain name, the first domain name identifying a key management domain name and a related gateway function that holds a re-authentication security context; verify the first authentication message using at least the re-authentication security context indicated by the first username; generate a second authentication message in response to successfully verifying the first authentication message; and send the second authentication message in response to the first authentication message. the first username comprises a key identifier for a re-authentication root key (rRK), wherein the processor is configured to cause the gateway device to generate a fresh session key in response to verifying the first authentication message, wherein the fresh session key is derived using at least the rRK and a trusted access code as inputs to key derivation.

2. The gateway device of claim 1, wherein, the processor is configured to cause the gateway device to determine whether a re-authentication integrity key (rIK) is stored in local memory, wherein the processor is configured to cause the gateway device to derive a fresh rIK for authenticating the first message authentication code in response to the rIK not being stored in local memory or the first SEQ having a higher value than a locally stored SEQ, wherein the fresh rIK is derived using at least a re-authentication root key (rRK), the key management domain name, and the first SEQ.

3. The gateway device of claim 1, wherein, the second authentication message comprises a second message authentication code for authenticating the gateway device, wherein the second message authentication code is derived using the fresh rIK.

4. The gateway device of claim 3, wherein, the first authentication message is received from a serving access point associated with the UE, wherein the second authentication message is sent to the UE via the serving access point.

5. The gateway device of claim 1, wherein, the first authentication message is received from a target gateway function serving the UE, wherein the second authentication message includes the re-authentication security context and is sent to the target gateway function.

6. The gateway device of claim 1, wherein, the re-authentication security context contains a re-authentication root key (rRK), a re-authentication integrity key (rIK), a corresponding SEQ, and a re-authentication root key lifetime parameter.

7. The gateway device of claim 1, wherein, the processor is configured to cause the gateway device to receive a registration request from the UE, the registration request indicating that the UE supports an extended authentication protocol (EAP) re-authentication protocol (ERP), wherein the processor is configured to cause the gateway device to send a gateway identifier and the key management domain name to the UE during a registration procedure of the UE.

8. The gateway device of claim 1, wherein, 9. A method performed by a gateway function, the method comprising: ​ receiving a first authentication message for re-authenticating a UE, wherein the first authentication message includes a first sequence number SEQ, a first message authentication code for authenticating the UE, and a network access identifier NAI containing a first username and a first domain name; verifying the first domain name, the first domain name identifying a key management domain name and an associated gateway function that holds a re-authentication security context; validating the first authentication message using at least the re-authentication security context indicated by the first username; generating a second authentication message in response to successfully validating the first authentication message; and responding to the first authentication message by sending the second authentication message.

10. The method of claim 9, further comprising: determining whether a re-authentication integrity key rIK is stored in local memory; and deriving a fresh rIK for authenticating the first message authentication code in response to determining that the rIK is not stored in local memory or that the first SEQ has a higher value than a locally stored SEQ, wherein the rIK is derived using at least a re-authentication root key rRK, the key management domain name, and the first SEQ.

11. The method of claim 9, wherein, the re-authentication security context includes a re-authentication root key rRK, a re-authentication integrity key rIK, a sequence number SEQ, and a re-authentication root key lifetime parameter.

12. A target gateway apparatus comprising: a memory; and a processor coupled with the memory and configured to cause the target gateway apparatus to: receive a first authentication message for re-authenticating a user equipment UE, wherein the first authentication message includes a first sequence number SEQ, a first message authentication code for authenticating the UE, and a network access identifier NAI containing a first username and a first domain name; verify the first domain name, the first domain name identifying a key management domain name and an associated gateway function that holds a re-authentication security context; determine from the NAI that the re-authentication security context for the UE is held by a source gateway function; forward the first authentication message to the source gateway function; receive the re-authentication security context from the source gateway function; generate a second authentication message in response to receiving the re-authentication security context; and send the second authentication message to the UE. the processor is configured to cause the target gateway apparatus to update the NAI to point to the target gateway apparatus in response to receiving the re-authentication security context, wherein the second authentication message includes the updated NAI. the first username includes a key identifier for a re-authentication root key rRK, wherein the processor is configured to cause the target gateway apparatus to generate a fresh session key in response to receiving the re-authentication security context, wherein the fresh session key is derived using at least the rRK and a trusted access code as inputs to key derivation.

13. The target gateway device of claim 12, wherein, ​ 14. The target gateway device of claim 12, wherein, ​ 15. The target gateway device of claim 12, wherein, The second authentication message includes a second message authentication code for authenticating the target gateway device, wherein the second message authentication code is derived using the re-authentication security context.

16. The target gateway device of claim 12, wherein, The re-authentication security context includes a re-authentication root key rRK, a re-authentication integrity key rIK, a corresponding SEQ, and a re-authentication root key lifetime parameter.

17. A method performed by a target gateway function, the method comprising: receiving a first authentication message for re-authenticating a user equipment, UE, wherein the first authentication message includes a first sequence number, SEQ, a first message authentication code for authenticating the UE, and a network access identifier, NAI, containing a first username and a first domain name; verifying the first domain name, the first domain name identifying a key management domain name and a related gateway function that holds a re-authentication security context; determining from the NAI that the re-authentication security context for the UE is held by a source gateway function; forwarding the first authentication message to the source gateway function; receiving the re-authentication security context from the source gateway function; generating a second authentication message in response to receiving the re-authentication security context; and sending the second authentication message to the UE.

18. The method of claim 17, wherein, The second authentication message includes a second message authentication code for authenticating the target gateway function, wherein the second message authentication code is derived using the re-authentication security context.

19. The method of claim 17, wherein, The first username includes a key identifier for a re-authentication root key rRK, the method further comprising generating a fresh session key in response to receiving the re-authentication security context, wherein the fresh session key is derived using at least the rRK and a trusted access code as inputs to key derivation.

20. The method of claim 17, wherein, The re-authentication security context includes a re-authentication root key rRK, a re-authentication integrity key rIK, a corresponding SEQ, and a re-authentication root key lifetime parameter.

Images