Provisioning server selection in a cellular network

Abstract

Apparatus, methods, and systems for selecting provisioning servers in a cellular network are described. One method (500) comprises communication (502) on a network device with a remote unit via a first network function. The method (500) comprises receiving (504) an authentication request from the first network function. The method (500) comprises selecting (506) a provisioning server based on the remote unit's identity, an onboarding profile, a preconfiguration, or a combination thereof. The method (500) comprises transmitting (508) a reply message to the first network function. The reply message includes the address of the provisioning server.

Description

Provisioning server selection in a cellular network Field The subject matter presented in this document generally refers to wireless communications and, more specifically, to the selection of a provisioning server in a cellular network. Background In certain wireless communication networks, security credentials may be used. In such networks, the credentials may not be sufficiently protected. TR23.700-07-040 describes a procedure for adding a device to a subscription owner-independent non-public network (SO-SNPN). TR33.857-040 describes adding a device to an SNPN. Brief summary Methods for selecting a provisioning server in a cellular network are disclosed. Devices and systems also perform the functions of the methods. One implementation of a method includes communicating, on a network device, with a remote unit through a first network function. In some implementations, the method includes receiving an authentication request from the first network function. In certain implementations, the method includes selecting a provisioning server based on a remote unit identity from an onboarding profile, based on a preconfiguration, or a combination thereof. In various implementations, the method includes transmitting a reply message to the first network function. The reply message includes a provisioning server address. An apparatus for selecting a provisioning server in a cellular network includes a network device, the network device comprising a Default Credential Server (DCS). In some embodiments, the network device includes at least one memory and at least one processor coupled with the at least one memory. The processor is configured to cause the network device to communicate with a user equipment (UE) through a first network function comprising an Authentication Server Function (AUSF). In various embodiments, the processor is configured to cause the network device to receive an authentication request from the first network function.In certain embodiments, the processor is configured to have the network device select a provisioning server based on a remote unit identity from an onboarding profile, based on a preconfiguration, or a combination thereof, and to transmit a response message to the first network function for forwarding to the UE through a second network function comprising an access and mobility management function. The response message includes an address of the provisioning server. Another implementation of a method for selecting a provisioning server in a cellular network involves communicating, at a UE, with a first network function. In some implementations, the method includes receiving a registration acceptance message that includes a provisioning server address. In certain implementations, the method includes deriving a provisioning key (KPro) from a master session key (MSK) that takes a permanent device identifier (PEI) from the remote unit as input to a key derivation function (KDF). Another device for selecting a provisioning server in a cellular network includes a UE (Uniform Enabler). In some embodiments, the device includes a transmitter that communicates with a first network function. In various embodiments, the device includes a receiver that receives a registration acceptance message containing a provisioning server address. In certain embodiments, the device includes a processor that derives a provisioning key (KPro) from a master session key (MSK) that takes a permanent equipment identifier (PEI) from the device as input to a key derivation function (KDF). Additional features and embodiments are set forth in the appended claims. Brief description of the figures A more specific description of the embodiments briefly described above will be presented by reference to specific embodiments illustrated in the accompanying drawings. It being understood that these drawings represent only some embodiments and should therefore not be considered limiting of the scope, the embodiments will be described and explained with additional specificity and detail by means of the accompanying drawings, in which: Figure 1 is a schematic block diagram illustrating an implementation of a wireless communication system for provisioning server selection in a cellular network; Figure 2 is a schematic block diagram illustrating an embodiment of an apparatus that can be used for provisioning server selection in a cellular network; Figure 3 is a schematic block diagram illustrating an embodiment of an apparatus that can be used for provisioning server selection in a cellular network; Figure 4 is a schematic block diagram illustrating an implementation of a system for network access authentication with credentials owned by an entity separate from an SNPN; Figure 5 is a flowchart illustrating an implementation of a method for selecting a provisioning server in a cellular network; and Figure 6 is a flowchart illustrating another implementation of a method for selecting a provisioning server in a cellular network. Detailed description As someone skilled in the art will appreciate, aspects of embodiments can materialize as a system, apparatus, method, or program product. Accordingly, embodiments can take the form of a purely hardware embodiment, a purely software embodiment (including firmware, resident software, microcode, etc.), or an embodiment that combines software and hardware aspects, which may all be referred to herein as a "circuit," "module," or "system." Furthermore, embodiments can take the form of a program product materialized on one or more computer-readable storage devices that store machine-readable code, computer-readable code, and / or program code, hereinafter referred to as code. The storage devices may be tangible, non-transient, and / or non-transmittable. The storage devices may not incorporate signals.In one embodiment, storage devices use only signals to access the code. Some of the functional units described in this specification may be labelled as modules to further emphasize their implementation independence. For example, the described embodiments may be implemented as a hardware circuit comprising custom very-large-scale integration (VLSI) circuits or gate arrays, off-the-shelf semiconductors such as logic chips, transistors, or other discrete components. A module may also be implemented on programmable hardware devices such as field-programmable gate arrays, programmable array logic, programmable logic devices, or the like. Modules can also be implemented in code and / or software for execution by various types of processors. An identified code module may, for example, include one or more physical or logical blocks of executable code, which may be organized as an object, procedure, or function. However, the executables of an identified module need not be physically located together; they may include disparate instructions stored in different locations that, when logically combined, comprise the module and achieve its stated purpose. In fact, a code module can be a single instruction, or many instructions, and can even be distributed across several different code segments, among different programs, and in various memory devices. Similarly, operational data can be identified and illustrated herein within modules, and can be realized in any suitable form and organized within any suitable type of data structure. Operational data can be collected as a single data set, or it can be distributed across different locations, even on different computer-readable storage devices. When a module or parts of a module are implemented in software, the software components are stored on one or more computer-readable storage devices. Any combination of one or more computer-readable media may be used. The computer-readable medium may be a computer-readable storage medium. The computer-readable storage medium may be a storage device that stores the code. The storage device may 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 thereof.More specific examples (a non-exhaustive list) of storage devices would include the following: an electrical connection having one or more wires, a laptop floppy disk, a hard disk drive, random access memory ("RAM"), read-only memory ("ROM"), erasable programmable read-only memory ("EPROM" or flash memory), portable compact disc read-only memory ("CD-ROM"), an optical storage device, a magnetic storage device, or any suitable combination thereof. In the context of this document, a computer-readable storage medium may be any tangible medium capable of containing or storing a program for use by or in connection with an instruction-executing system, apparatus, or device. The code to perform operations for realizations can be any number of lines and can be written in any combination of one or more programming languages, including an object-oriented programming language such as Python, Ruby, Java, Smalltalk, C++, or similar, and conventional procedural programming languages ​​such as the C programming language, or similar, and / or machine languages ​​such as assembly languages. The code can run entirely on the user's computer, partly on the user's computer as a standalone software package, partly on the user's computer and partly on a remote computer, or entirely on the server or remote computer.In this latter situation, the remote computer may be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or the connection may be made to an external computer (for example, via the Internet using an Internet service provider). References throughout this specification to "an embodiment," "a form of embodiment," or similar language means that a particular feature, structure, or characteristic described in relation to the embodiment is included in at least one embodiment of the present invention. Therefore, the occurrence of the phrase "in an embodiment," "in a form of embodiment," and similar language throughout this specification may refer to, but does not necessarily refer to, the same embodiment, but means "one or more, but not all, embodiments" unless expressly stated otherwise.The terms "including," "comprising," "having," and variations thereof mean "including but not limited to," unless expressly stated otherwise. An enumerated list of items does not imply that any or all of the items are mutually exclusive, unless expressly stated otherwise. The terms "a," "an," and "the" also mean "one or more," unless expressly stated otherwise. Furthermore, the described features, structures, or characteristics of the implementations may be combined in any appropriate manner. In the following description, numerous specific details are provided, such as programming examples, software modules, user selections, network transactions, database queries, database structures, hardware modules, hardware circuits, hardware chips, etc., to provide a comprehensive understanding of the implementations.However, a person skilled in the relevant art will recognize that the embodiments can be implemented without one or more of the specific details, or with other methods, components, materials, etc. In other cases, widely known structures, materials, or operations are not shown or described in detail to avoid obscuring aspects of an embodiment. Aspects of the embodiments are described below with reference to schematic flowcharts and / or schematic block diagrams of methods, apparatus, systems, and program products according to the embodiments. It is understood that each block in 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.This code can be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions, which are executed through the processor of the computer or other programmable data processing apparatus, create means to implement the functions / acts specified in the block or blocks of the schematic flowcharts and / or schematic block diagrams. The code can also be stored on a storage device that can direct a computer, other programmable data processing apparatus, or other devices to function in a particular way, so that the instructions stored on the storage device produce a manufactured item that includes instructions implementing the function / act specified in the block or blocks of the schematic flowcharts and / or schematic block diagrams. The code can also be loaded into a computer, other programmable data processing device, or other devices to cause a series of operational steps to be performed on the computer, other programmable device, or other devices to produce a computer-implemented process such that the code running on the computer or other programmable device provides processes to implement the functions / acts specified in the block or blocks of the flowcharts and / or block diagrams. The schematic flowcharts and / or schematic block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of devices, systems, methods, and program products according to various embodiments. In this sense, each block in the schematic flowcharts and / or schematic block diagrams can represent a module, segment, or piece of code, which includes one or more executable code instructions to implement the specified logical function(s). It should also be noted that, in some alternative implementations, the functions indicated in the block may occur out of the order shown in the figures. For example, two blocks shown sequentially may, in fact, execute substantially simultaneously, or, sometimes, the blocks may execute in reverse order, depending on the functionality involved. Other steps and methods may be conceived that are equivalent in function, logic, or effect to one or more blocks, or parts thereof, in the illustrated figures. Although various types of arrows and line types may be used in flowcharts and / or block diagrams, it is understood that they do not limit the scope of the corresponding implementations. In fact, some arrows or other connectors may be used to indicate only the logical flow of the represented implementation. For example, an arrow may indicate a waiting or monitoring period of unspecified duration between the listed steps of the represented implementation. It should also be noted that each block in block diagrams and / or flowcharts, and combinations of blocks in block diagrams and / or flowcharts, may be implemented using systems based on special-purpose hardware that perform the specified functions or actions, or combinations of code and special-purpose hardware. The description of the elements in each figure may refer to elements in previous figures. Equal numbers refer to equal elements in all figures, including alternative realizations of equal elements. Figure 1 depicts an embodiment of a wireless communication system 100 for provisioning server selection in a cellular network. In one embodiment, the wireless communication system 100 includes remote units 102 and network units 104. Although a specific number of remote units 102 and network units 104 are depicted in Figure 1, a person skilled in the art will recognize that any number of remote units 102 and network units 104 may be included in the wireless communication system 100. In one embodiment, remote units 102 may include computing devices such as desktop computers, laptops, personal digital assistants (PDAs), tablets, smartphones, smart TVs (e.g., internet-connected TVs), set-top boxes, video game consoles, security systems (including security cameras), vehicle onboard computers, network devices (e.g., routers, switches, modems), aircraft, drones, or similar devices. In some embodiments, remote units 102 include wearable devices such as smartwatches, fitness trackers, head-mounted optical displays, or similar devices.Furthermore, remote units 102 may be referred to as subscriber units, mobile units, mobile stations, users, terminals, mobile terminals, fixed terminals, subscriber stations, UE, user terminals, a device, or by other terminology used in the art. Remote units 102 may communicate directly with one or more network units 104 via communication signals. In certain embodiments, remote units 102 may communicate directly with other remote units 102 via sidelink communication. Network units 104 can be distributed across a geographical region. In certain embodiments, it may also refer to a 104 network unit and / or may include one or more of an access point, an access terminal, a base, a base station, a location server, a core network ("CN"), a radio network entity, a Node B, an evolved Node B ("eNB"), a 5G Node B ("gNB"), a home Node B, a relay node, a device, a core network, an air server, a radio access node, an access point ("AP"), new radio ("NR"), a network entity, an access and mobility management function ("AMF"), a unified data management ("UDM"), a unified data repository ("UDR"), a UDM / UDR, a policy control function ("PCF"), a radio access network ("RAN"), a network segment selection function ("NSSF"), an operations, administration, and management ("OAM"), a function session management ("SMF"),A user plane function ("UPF"), an application function, an authentication server function ("AUSF"), a security anchor function ("SEAF"), a trusted non-3GPP gateway function ("TNGF"), or any other terminology used in the art. Network units 104 are generally part of a radio access network that includes one or more controllers communicatively coupled to one or more corresponding network units 104. The radio access network is generally communicatively coupled to one or more core networks, which may be coupled to other networks, such as the Internet and public switched telephone networks, among others. These and other elements of radio access networks and core networks are not illustrated, but are generally well known to those skilled in the art. In one implementation, the Wireless 100 communication system complies with the NR protocols standardized in the Third Generation Partnership Project ("3GPP"), in which the network unit 104 transmits using an OFDM modulation scheme on the downlink ("DL") and the remote units 102 transmit on the uplink ("UL") using either a single-carrier frequency-division multiple access ("SC-FDMA") or an orthogonal frequency-division multiplexing ("OFDM") scheme. More generally, however, the Wireless 100 communication system can implement some other open or proprietary communication protocol, for example, WiMAX or 802 variants.11 of the Institute of Electrical and Electronics Engineers ("IEEE"), Global System for Mobile Communications ("GSM"), General Packet Radio Service ("GPRS"), Universal Mobile Telecommunications System ("UMTS"), Long-Term Evolution variants ("LTE"), Code Division Multiple Access 2000 ("CDMA2000"), Bluetooth®, ZigBee, Sigfoxx, among other protocols. This disclosure is not intended to be limited to the implementation of any particular wireless communication system architecture or protocol. Network units 104 can serve a number of remote units 102 within a service area, such as a cell or cell sector, via a wireless communication link. The network units 104 transmit DL communication signals to serve the remote units 102 in the time, frequency, and / or space domains. In various embodiments, a remote 102 unit can communicate with a first network function. In some embodiments, the remote 102 unit can receive a registration acceptance message that includes a provisioning server address. In certain embodiments, the remote 102 unit can derive a provisioning key (KPro) from a master session key (MSK) that takes a permanent device identifier (PEI) from the remote unit as input to a key derivation function (KDF). Consequently, the remote 102 unit can be used for provisioning server selection in a cellular network. In certain implementations, a 104 network unit can communicate with a remote unit through a first network function. In some implementations, the 104 network unit can receive an authentication request from the first network function. In certain implementations, the 104 network unit can select a provisioning server based on a remote unit identity from an onboarding profile, based on a preconfiguration, or a combination thereof. In various implementations, the 104 network unit can transmit a reply message to the first network function. The reply message includes a provisioning server address. Consequently, the 104 network unit can be used to provision server selection in a cellular network. Figure 2 represents an embodiment of an appliance 200 that can be used for provisioning server selection in a cellular network. The appliance 200 includes an embodiment of the remote unit 102. The remote unit 102 may also include a processor 202, a memory 204, an input device 206, a display 208, a transmitter 210, and a receiver 212. In some embodiments, the input device 206 and the display 208 are combined into a single device, such as a touchscreen. In certain embodiments, the remote unit 102 may not include an input device 206 and / or a display 208. In various embodiments, the remote unit 102 may include one or more of the processor 202, the memory 204, the transmitter 210, and the receiver 212, and may not include the input device 206 and / or the display 208. In one embodiment, the processor 202 may include any known controller capable of executing computer-readable instructions and / or performing logical operations. For example, the processor 202 may 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 a similar programmable controller. In some embodiments, the processor 202 executes instructions stored in memory 204 to perform the methods and routines described herein. The processor 202 is communicatively coupled to memory 204, input device 206, display 208, transmitter 210, and receiver 212. In one embodiment, memory 204 is a computer-readable storage medium. In some embodiments, memory 204 includes volatile computer storage media. For example, memory 204 may include RAM, which may include dynamic RAM ("DRAM"), synchronous dynamic RAM ("SDRAM"), and / or static RAM ("SRAM"). In some embodiments, memory 204 includes non-volatile computer storage media. For example, memory 204 may include a hard disk drive, flash memory, or any other suitable non-volatile computer storage device. In some embodiments, memory 204 includes both volatile and non-volatile computer storage media. In certain embodiments, memory 204 also stores program code and related data, such as an operating system or other driver algorithms that run on remote drive 102. In one embodiment, input device 206 may include any known computer input device, including a touchpad, button, keyboard, light pen, microphone, or the like. In some embodiments, input device 206 may be integrated with display 208, for example, as a touchscreen or similar touch-sensitive display. In some embodiments, input device 206 includes a touchscreen so that text can be entered using a virtual keyboard displayed on the touchscreen and / or by handwriting on the touchscreen. In some embodiments, input device 206 includes two or more different devices, such as a keyboard and a touchpad. The Display 208, in one embodiment, may include any known electronically controllable display or display device. The Display 208 may be designed to emit visual, audible, and / or haptic signals. In some embodiments, the Display 208 includes an electronic display capable of emitting visual data to a user. For example, the Display 208 may include, but is not limited to, a liquid crystal display (LCD), a light-emitting diode (LED) display, an organic light-emitting diode (OLED) display, a projector, or a similar display device capable of emitting images, text, or the like to a user. As another non-imitative example, the Display 208 may include a wearable display such as a smartwatch, smart glasses, a head-up display, or the like.In addition, the 208 display can be a component of a smartphone, a personal digital assistant, a television, a desktop computer, a laptop computer, a personal computer, a vehicle dashboard, or similar devices. In certain embodiments, the display 208 includes one or more speakers to produce sound. For example, the display 208 may produce an audible alert or notification (for example, a beep or chime). In some embodiments, the display 208 includes one or more haptic devices to produce vibrations, movement, or other haptic feedback. In some embodiments, all or parts of the display 208 may be integrated with the input device 206. For example, the input device 206 and the display 208 may form a touchscreen or a similar touch-sensitive display. In other embodiments, the display 208 may be located near the input device 206. In certain embodiments, transmitter 210 communicates with a first network function. In various embodiments, receiver 212 receives a registration acceptance message that includes a provisioning server address. In certain embodiments, processor 202 derives a provisioning key (KPro) from a master session key (MSK) that takes a permanent device identifier (PEI) from the device as an input to a key derivation function (KDF). Although only one transmitter 210 and one receiver 212 are illustrated, the remote unit 102 can have any suitable number of transmitters 210 and receivers 212. The transmitter 210 and receiver 212 can be any suitable type of transmitter and receiver. In one embodiment, the transmitter 210 and receiver 212 can be part of a transceiver. Figure 3 represents an embodiment of an Apparatus 300 that can be used for provisioning server selection in a cellular network. Apparatus 300 includes an embodiment of Network Unit 104. In addition, Network Unit 104 may include a Processor 302, a Memory 304, an Input Device 306, a Display 308, a Transmitter 310, and a Receiver 312. As can be seen, the Processor 302, Memory 304, Input Device 306, Display 308, Transmitter 310, and Receiver 312 can be substantially similar to the Processor 202, Memory 204, Input Device 206, Display 208, Transmitter 210, and Receiver 212 of Remote Unit 102, respectively. In certain embodiments, transmitter 310 communicates with a remote unit via a first network function. In various embodiments, receiver 312 receives an authentication request from the first network function. In certain embodiments, processor 302 selects a provisioning server based on a remote unit identity from an onboarding profile, based on a preconfiguration, or a combination thereof. Transmitter 310 transmits a reply message to the first network function. The reply message includes a provisioning server address. In certain implementations, a user device (UE) can be joined to a special default credential server (DCS) with default credentials, and then the UE is provisioned with an actual profile. The UE uses the actual profile to access a non-public network (NPN) according to the profile subscription. In some implementations, onboarding access may be protected and unprotected (for example, as an emergency service). In such implementations, the UE may be pre-provisioned with onboarding credentials for an onboarding process from a separate NPN ("SNPN"). Furthermore, the credentials (for example, the profile to be provisioned) may be protected against confidentiality, integrity, and / or reproduction during remote provisioning. In various implementations, pre-provisioned onboarding credentials between a UE and a DCS are used to derive keys to protect the subsequent profile provisioning between the UE and a provisioning server. In certain implementations, a UE is pre-provisioned with onboarding credentials. In such implementations, the UE is identified by a DCS based on a hidden onboarding subscription identifier ("SUCI"). The DCS can unhide the SUCI to a permanent onboarding subscription identifier ("SUPI") and can have knowledge of a corresponding permanent equipment identifier ("PEI") for the UE. The DCS can authenticate the UE based on the onboarding credentials and provide a master session key ("MSK") to an authentication server function ("AUSF") to configure security over the radio interface for the access stratum ("AS") and non-access stratum ("NAS") according to normal procedures. The DCS and the UE can derive a provisioning key that is used to protect the provisioning server profile. Figure 4 is a schematic block diagram illustrating an implementation of a System 400 for network access authentication using credentials owned by an entity separate from an SNPN. The System 400 includes a UE 402, an AMF and / or Security Anchor Function ("SEAF") ("AMF / SEAF") 404, a UDM / UDR 406, an AUSF 408, a DCS 410, and a provisioning server 412. Each System 400 communication may include one or more messages. In an initial communication 414, UE 402 sends a registration request message with a DCS 410 incorporation SUCI as UE 402's identity to AMF / SEAF 404. In a second communication 416, AMF / SEAF 404 detects, based on the scope of a Network Access Identifier ("NAI"), that the registration request message is not from an SNPN subscriber but is for inclusion in DCS 410. AMF / SEAF 404 authorizes the request by verifying the scope of the NAI and whether the SNPN has an active agreement with this DCS 410. AMF / SEAF 404 forwards the request to AUSF 408, which may be preconfigured to handle requests transmitted to an external DCS 410. In a third 418 communication, the AUSF 408 can authorize the registration request by verifying the scope of the NAI and whether the SNPN has an active agreement with this DCS 410. The AUSF 408 identifies the DCS 410 and assumes the role of an Auth, Authorization, and Accounting ("AAA") proxy ("AAA-Proxy") and sends a related AAA message to the DCS 410. The AUSF 408 sends an authentication request with the onboarding SUCI to the DCS 410. The AUSF 408 can include an SNPN ID, a Closed Access Group ("CAG") ID, and / or a service network name in the authentication request. It should be noted that if the DCS 410 supports only DIAMETER or RADIO protocols, the SBI-DIAMETER interoperability functionality can be implemented with the AUSF 408 or the DCS 410, or it can be part of an additional feature. DCS 410 unhide the SUCI to a SUPI and verifies the authentication request based on the username. DCS 410 selects the subscriber profile based on the SUPI and, in a fourth communication, performs Extensible Authentication Protocol (EAP) authentication with UE 402, using the onboarding credentials previously shared between UE 402 and DCS 410. DCS 410 can select the provisioning server based on the onboarding SUPI or a preconfigured provisioning server stored in the onboarding profile. The provisioning server address can be a NAI, a fully qualified domain name (FQDN), or an Internet Protocol (IP) address. In a fifth communication 424, after successful authentication, DCS 410 sends the authentication result, the onboarding SUPI, the MSK and / or validity time and the provisioning server address 412 back in an authentication response to AUSF 408. The AUSF 408 verifies the response and derives the KAUSF from the MSK and KSEAF. The UE 402 is performing the same key derivation accordingly. In a sixth communication 430, the AUSF 408 sends an authentication response to the AMF / SEAF 404 that includes the authentication result of the DCS 410 and the KSEAF, the onboarding SUPI and / or the validity time (e.g., time until onboarding expires and the provisioning server address 412). In a seventh communication 432, the AMF / SEAF 404 performs a NAS security mode command ("SMC") with the UE 402. In an eighth communication 434, after a successful NAS SMC procedure, the AMF / SEAF 404 sends a registration acceptance message that includes the provisioning server address 412. In a ninth communication (436), UE 402 performs a standard Protocol Data Unit (PDU) session establishment procedure to obtain IP connectivity through a UPF. UE 402 can retrieve the provisioning server address (412) from the SMF at this time if it was not provisioned in the NAS registration acceptance message in the eighth communication (434). UE 402 may have limited UP access only to provisioning server 412. UE 402 and DCS 410 derive a KPro provisioning key (438 and 440) in the same way. When a KPro is derived from MSK or KAUSF, one or more of the following parameters, in interchangeable order, can be used to form the S entry to the KDF: FC = 0xYZ, any hexadecimal value, P0 =<serving network name> , L0 = length of<serving network name> , P1 =<NPN ID> , L1 = length of<NPN ID> , P2 =<CAG ID> , L2 = length of<CAG ID> , P3 =<Onboarding SUPI> , L3 = length of<Onboarding SUPI> , P4 =<Provisioning Server Address> , L4 = length of<Provisioning Server Address> , P5 =<Onboarding SUCI> , L5 = length of<Onboarding SUCI> , P6 = <pei>and / or L6 = length of <pei>The entry key is either the MSK or the KAUSF, where KAUSF is the 256 most significant bits of the MSK. It should be noted that reasonable entries may include the onboarding SUPI, PEI, and / or the provisioning server address, including their respective lengths. Key derivation may occur in the mobile equipment ("ME"), the onboarding profile's Universal Subscriber Identity Module ("USIM"), or the Universal Integrated Circuit Card ("UICC"). In a tenth communication (442), DCS 410 provides the provisioning information onboarding SUPI and the KPro provisioning key to provisioning server 412. Provisioning server 412 can be selected based on the address stored in DCS 410 by the onboarding SUPI. Provisioning server 412 can be installed alongside DCS 410. The provisioning server 412 selects the profile 444 based on the incorporation SUPI. In an eleventh communication (446), UE 402 (or ME) establishes an IPSec security association (SA) with provisioning server 412 using KPro. The UICC can initiate the IPSec connection to install the provisioned profile directly as a USIM application. Instead of IPSec, the ME or UICC can establish a Transport Layer Security (TLS) connection with provisioning server 412. Provisioning server 412 can trigger the establishment of the secure connection by contacting the Network Exposure Function (NEF) with the onboarding SUPI to retrieve UE 402's IP address and initiate the secure connection (e.g., IPSec or TLS). All messages can then be protected for confidentiality and integrity through the IPsec tunnel. UE 402 can provide its PEI to provisioning server 412 through the IPSec tunnel if the PEI is not used as an input for KPro bypass.If the PEI is used as input for KPro derivation and the onboarding credentials are leaked to a malicious UE, then KPro would lead to a mismatch and provisioning would fail, since the PEI stored in DCS 410 may not be the same as that of the malicious UE. In a twelfth communication 448, provisioning server 412 provisions the new profile to UE 404 through the IPSec tunnel. In a thirteenth communication 450, provisioning server 412 acknowledges the provisioning result (e.g., success and / or failure) to DCS 410. Provisioning server 412 can provide the PEI to DCS 410, if available. If the PEI was not used as input in the KPro derivation, DCS 410 can check if the PEI received from the provisioning server matches the stored PEI of the onboarding SUPI. If they match, DCS 410 can delete or deactivate the onboarding profile associated with the onboarding SUPI if provisioning was successful. If the PEI was used as input in the KPro derivation, DCS 410 can deactivate or delete the onboarding profile associated with the onboarding SUPI if provisioning was successful. Whether to deactivate or delete the onboarding profile and how to activate or create new onboarding profiles (e.g., via top-level configuration, timer-based, etc.) depends on the local policy at DCS 410.This can prevent subsequent spoofing attacks by malicious UEs from being provisioned with a valid profile if onboarding credentials are compromised. In a fourteenth communication 454, the UE 402 is removed from the onboarding network and can delete or deactivate the onboarding profile. In a fifteenth communication 456, UE 402 selects the NPN according to the provisioned profile and registers with the NPN using the provisioned profile. The selected NPN may be different from or the same as the onboarding NPN. Figure 5 is a flowchart illustrating one implementation of a 500 method for provisioning a server in a cellular network. In some implementations, the 500 method is performed by an appliance, such as the 104 network unit. In other implementations, the 500 method can be performed by a processor executing program code, such as a microcontroller, microprocessor, CPU, GPU, auxiliary processing unit, FPGA, or similar device. In various embodiments, method 500 includes communicating 502 with a remote drive through a first network function. In some embodiments, method 500 includes receiving 504 an authentication request from the first network function. In certain embodiments, method 500 includes selecting 506 a provisioning server based on a remote drive identity from an onboarding profile, based on a preconfiguration, or a combination thereof. In various embodiments, method 500 includes transmitting 508 a reply message to the first network function. The reply message includes a provisioning server address. In certain embodiments, Method 500 further comprises deriving a provisioning key (KPro) from a master session key (MSK) that takes a permanent device identifier (PEI) from the remote unit as input to a key derivation function (KDF). In some embodiments, Method 500 further comprises transmitting a provisioning key message to a second network function, wherein the provisioning key message comprises the KPro and a permanent subscription onboarding identifier (SUPI). In various embodiments, Method 500 further comprises receiving a reply message from the second network function based on the transmission of the provisioning key message. In one embodiment, method 500 further comprises verifying successful provisioning and disabling or deleting an onboarding profile related to the onboarding SUPI. In certain embodiments, the network device comprises a default credential server (DCS). In some embodiments, the remote unit comprises a user computer. In several embodiments, the first network function comprises an authentication server function (AUSF). In one embodiment, the second network function comprises a provisioning server. Figure 6 is a flowchart illustrating another implementation of a 600 method for provisioning a server in a cellular network. In some implementations, the 600 method is performed by a device, such as the 102 remote unit. In other implementations, the 600 method can be performed by a processor executing program code, such as a microcontroller, microprocessor, CPU, GPU, auxiliary processing unit, FPGA, or similar device. In various implementations, method 600 includes communicating 602 with a first network function. In some implementations, method 600 includes receiving 604 a registration acceptance message that includes a provisioning server address. In certain implementations, method 600 includes deriving 606 a provisioning key (KPro) from a master session key (MSK) that takes a permanent device identifier (PEI) from the remote unit as an input to a key derivation function (KDF). In certain embodiments, Method 600 further comprises communicating with a second network function to configure an Internet Protocol (IPSec) security tunnel using the KPro. In some embodiments, the second network function comprises a provisioning server. In various embodiments, the remote unit comprises a user equipment (UE). In one embodiment, the first network function comprises an access and mobility management function. In certain embodiments, Method 600 further comprises transmitting a registration request message before receiving the registration acceptance message. In one embodiment, an apparatus comprises a network device. The apparatus further comprises: a transmitter that communicates with a remote unit via a first network function; a receiver that receives an authentication request from the first network function; and a processor that selects a provisioning server based on a remote unit identity from an onboarding profile, based on a preconfiguration, or a combination thereof, wherein the transmitter transmits a reply message to the first network function, wherein the reply message comprises a provisioning server address. In certain embodiments, the processor derives a provisioning key (KPro) from a master session key (MSK) that takes a permanent device identifier (PEI) from the remote unit as an input to a key derivation function (KDF). In some embodiments, the transmitter transmits a provisioning key message to a second network function, wherein the provisioning key message comprises the KPro and a permanent onboarding subscription identifier (SUPI). In various embodiments, the receiver receives a response message from the second network function based on the transmission of the provisioning key message. In one embodiment, the processor verifies a successful provisioning and disables or deletes an onboarding profile related to the onboarding SUPI. In certain embodiments, the network device comprises a default credential server (DCS). In some embodiments, the remote unit comprises a user computer. In several embodiments, the first network function comprises an authentication server function (AUSF). In one embodiment, the second network function comprises a provisioning server. In one embodiment, a method by a network device comprises: communicating with a remote unit through a first network function; receiving an authentication request from the first network function; selecting a provisioning server based on a remote unit identity from an onboarding profile, based on a preconfiguration, or a combination thereof; and transmitting a reply message to the first network function, wherein the reply message comprises a provisioning server address. In certain embodiments, the method further comprises deriving a provisioning key (KPro) from a master session key (MSK) that takes a permanent equipment identifier (PEI) from the remote unit as an input to a key derivation function (KDF). In some embodiments, the method further comprises transmitting a provisioning key message to a second network function, wherein the provisioning key message comprises the KPro and a permanent onboarding subscription identifier (SUPI). In various embodiments, the method also includes receiving a response message from the second network function based on the transmission of the provisioning key message. In one embodiment, the method further comprises verifying a successful provisioning and deactivating or deleting an onboarding profile related to the onboarding SUPI. In certain embodiments, the network device comprises a default credential server (DCS). In some embodiments, the remote unit comprises a user computer. In several embodiments, the first network function comprises an authentication server function (AUSF). In one embodiment, the second network function comprises a provisioning server. In one embodiment, an apparatus comprises a remote unit. The apparatus further comprises: a transmitter that communicates with a first network function; a receiver that receives a registration acceptance message comprising a provisioning server address; and a processor that derives a provisioning key (KPro) from a master session key (MSK) that takes a permanent equipment identifier (PEI) of the apparatus as an input to a key derivation function (KDF). In certain embodiments, the transmitter communicates with a second network function to set up an Internet Protocol (IP) security tunnel (IPSec) using the KPro. In some implementations, the second network function comprises a provisioning server. In various embodiments, the remote unit comprises a user equipment (UE). In one embodiment, the first network function comprises an access and mobility management function. In certain embodiments, the transmitter transmits a registration request message before receiving the registration acceptance message. In one embodiment, a method of a remote unit comprises: communicating with a first network function; receiving a registration acceptance message comprising a provisioning server address; and deriving a provisioning key (KPro) from a master session key (MSK) that takes a permanent computer identifier (PEI) from the remote unit as an input to a key derivation function (KDF). In certain embodiments, the method also includes communicating with a second network function to configure an Internet Protocol (IP) security tunnel (IPSec) using the KPro. In some implementations, the second network function comprises a provisioning server. In various embodiments, the remote unit comprises a user equipment (UE). In one embodiment, the first network function comprises an access and mobility management function. In certain embodiments, the method also includes transmitting a registration request message before receiving the registration acceptance message. Specific embodiments of the invention may be implemented in other ways. The embodiments described herein should be considered in all respects as illustrative and not restrictive. Therefore, the scope of the invention is indicated by the appended claims, rather than by the foregoing description.< / pei> < / pei>

Claims

1. A network device comprising: at least one memory; and at least one processor coupled with the at least one memory and configured to cause the network device to: communicate with a user equipment (UE) through a first network function comprising an authentication server function (AUSF); receive an authentication request from the first network function; select a provisioning server based on one or more of a UE identity from an onboarding profile or a preconfiguration; and transmit a response message to the first network function for forwarding to the UE through a second network function comprising an access and mobility management function, wherein the response message comprises an address of the provisioning server; wherein the network device comprises a default credential server (DCS) and is configured to operate in association with a standalone non-public network (SNPN). 2.A network device according to claim 1, wherein the at least one processor is configured to cause the network device to derive a provisioning key (KPro) based on a key derivation function (KDF), wherein a master session key (MSK) and a permanent device identifier (PEI) of the UE comprise entries to the KDF.

3. A network device according to claim 2, wherein the at least one processor is configured to cause the network device to transmit a provisioning key message to the provisioning server, wherein the provisioning key message comprises the KPro and a permanent subscription onboarding identifier (SUPI).

4. A network device according to claim 3, wherein the at least one processor is configured to cause the network device to receive a response message from the provisioning server based on the provisioning key message. 5.A network device according to claim 4, wherein at least one processor is configured to cause the network device to verify successful provisioning; and disable or delete an onboarding profile related to the onboarding SUPI. 6.A network device method, the network device comprising a default credential server (DCS) configured to operate in association with a standalone non-public network (SNPN), the method comprising: communicating with a UE through a first network function comprising an authentication server function (AUSF); receiving an authentication request from the first network function; selecting a provisioning server based on one or more UE identities from an onboarding profile or preconfiguration; and transmitting a response message to the first network function for forwarding to the UE through a second network function comprising an access and mobility management function (AMF), wherein the response message comprises an address of the provisioning server. 7.A UE configured to operate in association with a standalone non-public network (SNPN), comprising: at least one memory; and at least one processor coupled with the at least one memory and configured to cause the UE to: communicate with a first network function; receive from an access and mobility management function a registration acceptance message comprising a provisioning server address; and derive a provisioning key (KPro) according to a KDF, wherein an MSK and a PEI of the UE comprise entries to the KDF.

8. A UE according to claim 7, wherein the at least one processor is configured to cause the UE to communicate with a second network function to establish an Internet Protocol (IP) security tunnel (IPSec) using the KPro, wherein the second network function comprises a provisioning server. 9.UE according to claim 7 or 8, wherein the first network function comprises an access and mobility management function.

10. UE according to claim 7, 8, or 9, wherein the at least one processor is configured to cause the UE to transmit a registration request message before receiving the registration acceptance message.

Images