Method and apparatus for privacy protection using scalable authentication protocol security in 5G system

Abstract

An apparatus for performing authentication in a 5G core network receives an authentication request including a ciphertext of a user equipment (UE) credential with bit padding; transmitting a request to decrypt the ciphertext, the request being transmitted to an authentication and authorization function; receiving a plaintext with bit-filled UE credentials; transmitting the plaintext with the bit-filled UE credentials to a de-hiding function to remove the bit-filled of the decrypted text; receiving a plaintext of the de-populated UE credentials; transmitting the de-filled UE credential to an authentication and authorization function for authentication; and receiving authentication of the UE credentials.

Description

[0001] Cross - Reference to Related Applications

[0002] This application claims the benefit of U.S. Provisional Patent Application No. 63 / 422,199, filed on November 3, 2022, and U.S. Provisional Patent Application No. 63 / 433,315, filed on December 16, 2022, the entire contents of which are incorporated herein by reference. Brief Description of the Drawings

[0003] A more detailed understanding can be obtained from the following detailed description given by way of example in conjunction with the accompanying drawings. The figures in these drawings are exemplary like the detailed description. Therefore, the drawings and the detailed description should not be considered restrictive, and other equally valid examples are possible and expected. In addition, the same reference numerals (“ref”) in each figure (“FIG”) indicate the same elements, and in which:

[0004] Figure 1A is a system diagram showing an example communication system in which one or more disclosed embodiments can be implemented;

[0005] Figure 1B is a system diagram showing an example wireless transmit / receive unit (WTRU) that can be used in the Figure 1A shown communication system according to an embodiment;

[0006] Figure 1C is a system diagram showing an example radio access network (RAN) and an example core network (CN) that can be used in the Figure 1A shown communication system according to an embodiment;

[0007] Figure 1D is a system diagram showing another example RAN and another example CN that can be used in the Figure 1A shown communication system according to an embodiment;

[0008] Figure 2 is a high - level block diagram showing a basic padding operation according to some embodiments;

[0009] Figure 3 is a signal flow diagram for obfuscating the length of identities and / or parameters during EAP - TLS SNPN authentication (without AAA) according to some embodiments;

[0010] Figure 4A 、 4B 、4C, 4D, and 4E include signal flow diagrams for obfuscating the length of identities and / or parameters during EAP - TTLSSNPN authentication using an AAA server according to some embodiments;

[0011] Figure 5A 、5B , 5C, and 5D include signal flow diagrams for obfuscating the length of identities and / or parameters during EAP-TTLS SNPN authentication using an AAA server according to other embodiments; and

[0012] Figure 6 is an example flowchart of a method implemented by a 5G core network device according to the principles of the present disclosure. Detailed Description

[0013] Introduction

[0014] In the following detailed description, numerous specific details are set forth to provide a thorough understanding of the embodiments and / or examples disclosed herein. However, it will be understood that such embodiments and examples may be practiced without some or all of these specific details. In other instances, well-known methods, procedures, components, and circuits have not been described in detail so as not to obscure the following description. Additionally, embodiments and examples not specifically described herein may be practiced in lieu of or in combination with the embodiments and other examples explicitly, implicitly, and / or inherently described, disclosed, or otherwise provided (collectively referred to as "provided") herein.

[0015] Example communication system

[0016] Figure 1A is a diagram illustrating an example communication system 100 in which one or more disclosed embodiments may be implemented. The communication system 100 may be a multi-access system that provides content such as voice, data, video, messaging, broadcasting, etc. to a plurality of wireless users. The communication system 100 may enable a plurality of wireless users to access such content by sharing system resources including wireless bandwidth. For example, the communication system 100 may employ one or more channel access methods such as code division multiple access (CDMA), time division multiple access (TDMA), frequency division multiple access (FDMA), orthogonal FDMA (OFDMA), single carrier FDMA (SC-FDMA), zero-tail unique word DFT spread OFDM (ZT UWDTS-s OFDM), unique word OFDM (UW-OFDM), resource block filtered OFDM, filter bank multi-carrier (FBMC), etc.

[0017] As Figure 1AAs shown, the communication system 100 may include wireless transmit / receive units (WTRUs) 102a, 102b, 102c, 102d, a radio access network (RAN) 104 / 113, a core network (CN) 106 / 115, a public switched telephone network (PSTN) 108, the Internet 110, and other networks 112, but it should be understood that the disclosed embodiments contemplate any number of WTRUs, base stations, networks, and / or network elements. Each of the WTRUs 102a, 102b, 102c, 102d may be any type of device configured to operate and / or communicate in a wireless environment. By way of example, the WTRUs 102a, 102b, 102c, 102d (any of which may be referred to as a “station” and / or “STA”) may be configured to transmit and / or receive wireless signals and may include a user equipment (UE), a mobile station, a fixed or mobile subscriber unit, a subscription-based unit, a pager, a cellular phone, a personal digital assistant (PDA), a smart phone, a laptop computer, a netbook, a personal computer, a wireless sensor, a hotspot or Mi-Fi device, an Internet of Things (IoT) device, a watch or other wearable device, a head-mounted display (HMD), a vehicle, a drone, a medical device and application (e.g., remote surgery), an industrial device and application (e.g., a robot and / or other wireless devices operating in an industrial and / or automation processing chain environment), a consumer electronic device, a device operating on a commercial and / or industrial wireless network, etc. Any of the WTRUs 102a, 102b, 102c, and 102d may be interchangeably referred to as a UE.

[0018] The communication system 100 may also include base station 114a and / or base station 114b. Each of the base stations 114a, 114b may be any type of device configured to wirelessly interface with at least one of the WTRUs 102a, 102b, 102c, 102d to facilitate access to one or more communication networks, such as the CN 106 / 115, the Internet 110, and / or other networks 112. By way of example, the base stations 114a, 114b may be a base transceiver station (BTS), a Node B, an eNode-B, a home Node B, a home eNode-B, a gNB, an NR Node B, a site controller, an access point (AP), a wireless router. Although the base stations 114a, 114b are each depicted as a single element, it should be understood that the base stations 114a, 114b may include any number of interconnected base stations and / or network elements.

[0019] Base station 114a may be part of RAN 104 / 113, which may also include other base stations and / or network elements (not shown), such as base station controllers (BSCs), radio network controllers (RNCs), relay nodes, etc. Base station 114a and / or base station 114b may be configured to transmit and / or receive wireless signals on one or more carrier frequencies, which may be referred to as cells (not shown). These frequencies may be in licensed spectrum, unlicensed spectrum, or a combination of licensed and unlicensed spectrum. A cell may provide coverage of wireless services to a specific geographical area, which may be relatively fixed or may vary over time. A cell may also be divided into cell sectors. For example, the cell associated with base station 114a may be divided into three sectors. Thus, in one embodiment, base station 114a may include three transceivers, i.e., one transceiver for each sector of the cell. In one embodiment, base station 114a may employ multiple-input multiple-output (MIMO) technology and may utilize multiple transceivers for each sector of the cell. For example, beamforming may be used to transmit and / or receive signals in a desired spatial direction.

[0020] Base stations 114a, 114b may communicate with one or more of WTRUs 102a, 102b, 102c, 102d via air interface 116, which may be any suitable wireless communication link (e.g., radio frequency (RF), microwave, centimeter wave, millimeter wave, infrared (IR), ultraviolet (UV), visible light, etc.). Any suitable radio access technology (RAT) may be used to establish air interface 116.

[0021] More specifically, as described above, communication system 100 may be a multi-access system and may employ one or more channel access schemes, such as CDMA, TDMA, FDMA, OFDMA, SC-FDMA, etc. For example, base station 114a in RAN 104 / 113 and WTRUs 102a, 102b, 102c may implement a wireless technology such as Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access (UTRA), which may use Wideband CDMA (WCDMA) to establish air interface 116. WCDMA may include communication protocols such as High-Speed Packet Access (HSPA) and / or Evolved HSPA (HSPA+). HSPA may include High-Speed Downlink Packet Access (HSDPA) and / or High-Speed Uplink Packet Access (HSUPA).

[0022] In one embodiment, the base station 114a and the WTRUs 102a, 102b, 102c may implement a radio technology such as evolved UMTS terrestrial radio access (E-UTRA), which may use long term evolution (LTE) and / or LTE-Advanced (LTE-A) and / or LTE-A Pro to establish an air interface 116.

[0023] In one embodiment, the base station 114a and the WTRUs 102a, 102b, 102c may implement a radio technology such as NR radio access, which may use new radio (NR) to establish an air interface 116.

[0024] In an embodiment, the base station 114a and the WTRUs 102a, 102b, 102c may implement multiple radio access technologies. For example, the base station 114a and the WTRUs 102a, 102b, 102c may implement LTE radio access and NR radio access together, for example, using the dual connectivity (DC) principle. Thus, the air interface utilized by the WTRUs 102a, 102b, 102c may be characterized by multiple types of radio access technologies and / or transmissions to / from multiple types of base stations (e.g., eNBs and gNBs).

[0025] In other embodiments, the base station 114a and the WTRUs 102a, 102b, 102c may implement radio technologies such as IEEE 802.11 (i.e., Wi-Fi (Wireless Fidelity)), IEEE 802.16 (i.e., WiMAX (Worldwide Interoperability for Microwave Access)), CDMA2000, CDMA2000 1X, CDMA2000 EV-DO, Interim Standard 2000 (IS-2000), Interim Standard 95 (IS-95), Interim Standard 856 (IS-856), Global System for Mobile Communications (GSM), Enhanced Data Rates for GSM Evolution (EDGE), GSM EDGE (GERAN), etc.

[0026] For example, Figure 1AThe base station 114b therein can be a wireless router, a home Node B, a home eNode-B, or an access point, and can utilize any suitable RAT to facilitate wireless connection in a local area, such as a commercial venue, a home, a vehicle, a campus, an industrial facility, an air corridor (e.g., for drones), a road, etc. In one embodiment, the base station 114b and the WTRUs 102c, 102d can implement a radio technology such as IEEE 802.11 to establish a wireless local area network (WLAN). In one embodiment, the base station 114b and the WTRUs 102c, 102d can implement a radio technology such as IEEE 802.15 to establish a wireless personal area network (WPAN). In yet another embodiment, the base station 114b and the WTRUs 102c, 102d can utilize a cellular-based RAT (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, LTE-A Pro, NR, etc.) to establish a pico cell or a femto cell. As Figure 1A shown, the base station 114b can have a direct connection to the Internet 110. Thus, it may not be required for the base station 114b to access the Internet 110 via the CN 106 / 115.

[0027] The RAN 104 / 113 can communicate with the CN 106 / 115, and the CN 106 / 115 can be any type of network configured to provide voice, data, applications, and / or voice over Internet protocol (VoIP) services to one or more of the WTRUs 102a, 102b, 102c, 102d. The data can have different quality of service (QoS) requirements, such as different throughput requirements, latency requirements, error tolerance requirements, reliability requirements, data throughput requirements, mobility requirements, etc. The CN 106 / 115 can provide call control, billing services, location-based services, prepaid calls, Internet connection, video distribution, etc. and / or perform advanced security functions, such as user authentication. Although not shown in Figure 1A it, it should be understood that the RAN 104 / 113 and / or the CN 106 / 115 can communicate directly or indirectly with other RANs employing the same RAT as the RAN 104 / 113 or a different RAT. For example, in addition to being connected to the RAN 104 / 113 that may utilize NR radio technology, the CN 106 / 115 can also communicate with another RAN (not shown) employing GSM, UMTS, CDMA2000, WiMAX, E-UTRA, or WiFi radio technology.

[0028] CN 106 / 115 can also be used as a gateway for the WTRU 102a, 102b, 102c, 102d to access the PSTN 108, the Internet 110, and / or other networks 112. The PSTN 108 can include a circuit-switched telephone network that provides plain old telephone service (POTS). The Internet 110 can include a global system of interconnected computer networks and devices that use common communication protocols such as the Transmission Control Protocol (TCP), the User Datagram Protocol (UDP), and / or the Internet Protocol (IP) in the TCP / IP Internet protocol suite. The network 112 can include wired and / or wireless communication networks owned and / or operated by other service providers. For example, the network 112 can include another CN connected to one or more RANs, which can employ the same RAT or a different RAT as the RAN 104 / 113.

[0029] Some or all of the WTRU 102a, 102b, 102c, 102d in the communication system 100 can include multimodal capabilities (e.g., the WTRU 102a, 102b, 102c, 102d can include multiple transceivers for communicating with different wireless networks over different wireless links). For example, Figure 1A the WTRU 102c shown in can be configured to communicate with a base station 114a that can employ a cellular-based radio technology and with a base station 114b that can employ IEEE802 radio technology.

[0030] Figure 1B is a system diagram showing an example WTRU 102. As Figure 1B shown, among other things, the WTRU 102 can include a processor 118, a transceiver 120, a transmit / receive element 122, a speaker / microphone 124, a keypad 126, a display / touchpad 128, a non-removable memory 130, a removable memory 132, a power supply 134, a Global Positioning System (GPS) chipset 136, and / or other peripherals 138. It should be understood that the WTRU 102 can include any sub-combination of the foregoing elements while remaining consistent with the embodiments.

[0031] The processor 118 can be a general-purpose processor, a dedicated processor, a conventional processor, a digital signal processor (DSP), multiple microprocessors, one or more microprocessors associated with a DSP core, a controller, a microcontroller, an application specific integrated circuit (ASIC), a field programmable gate array (FPGA) circuit, any other type of integrated circuit (IC), a state machine, etc. The processor 118 can perform signal encoding, data processing, power control, input / output processing, and / or any other functions that enable the WTRU 102 to operate in a wireless environment. The processor 118 can be coupled to the transceiver 120, and the transceiver 120 can be coupled to the transmit / receive element 122. Although Figure 1B the processor 118 and the transceiver 120 are depicted as separate components, it should be understood that the processor 118 and the transceiver 120 can be integrated together in an electronic package or chip.

[0032] The transmit / receive element 122 can be configured to transmit signals to or receive signals from a base station (e.g., base station 114a) via the air interface 116. For example, in one embodiment, the transmit / receive element 122 can be an antenna configured to transmit and / or receive RF signals. In one embodiment, the transmit / receive element 122 can be a transmitter / detector configured to transmit and / or receive IR, UV, or visible light signals, for example. In yet another embodiment, the transmit / receive element 122 can be configured to transmit and / or receive both RF and optical signals. It should be understood that the transmit / receive element 122 can be configured to transmit and / or receive any combination of wireless signals.

[0033] Although the transmit / receive element 122 is depicted as a single element in Figure 1B the WTRU 102 can include any number of transmit / receive elements 122. More specifically, the WTRU 102 can employ MIMO technology. Thus, in one embodiment, the WTRU 102 can include two or more transmit / receive elements 122 (e.g., multiple antennas) for transmitting and receiving wireless signals via the air interface 116.

[0034] The transceiver 120 can be configured to modulate the signals to be transmitted by the transmit / receive element 122 and demodulate the signals received by the transmit / receive element 122. As described above, the WTRU 102 can have multi-modal capabilities. Thus, the transceiver 120 can include multiple transceivers for enabling the WTRU 102 to communicate via multiple RATs, such as NR and IEEE 802.11.

[0035] The processor 118 of the WTRU 102 can be coupled to a speaker / microphone 124, a keypad 126, and / or a display / touchpad 128 (e.g., a liquid crystal display (LCD) display unit or an organic light emitting diode (OLED) display unit), and can receive user input data therefrom. The processor 118 can also output user data to the speaker / microphone 124, the keypad 126, and / or the display / touchpad 128. In addition, the processor 118 can access information from and store data in any type of suitable memory, such as non-removable memory 130 and / or removable memory 132. The non-removable memory 130 can include random access memory (RAM), read-only memory (ROM), a hard disk, or any other type of memory storage device. The removable memory 132 can include a subscriber identity module (SIM) card, a memory stick, a secure digital (SD) memory card, etc. In other embodiments, the processor 118 can access information from and store data in a memory that is not physically located on the WTRU 102, such as on a server or a home computer (not shown).

[0036] The processor 118 can receive power from a power supply 134 and can be configured to distribute and / or control power to other components in the WTRU 102. The power supply 134 can be any suitable device for powering the WTRU 102. For example, the power supply 134 can include one or more dry cell batteries (e.g., nickel cadmium (NiCd), nickel zinc (NiZn), nickel metal hydride (NiMH), lithium ion (Li-ion), etc.), a solar cell, a fuel cell, etc.

[0037] The processor 118 can also be coupled to a GPS chipset 136, which can be configured to provide location information (e.g., longitude and latitude) about the current location of the WTRU 102. In addition to, or instead of, the information from the GPS chipset 136, the WTRU 102 can receive location information from a base station (e.g., base stations 114a, 114b) via an air interface 116, and / or determine its location based on the timing of signals received from two or more nearby base stations. It should be understood that the WTRU 102 can obtain location information by any suitable location determination method while remaining consistent with the embodiments.

[0038] The processor 118 can also be coupled to other peripherals 138, which can include one or more software and / or hardware modules that provide additional features, functions, and / or wired or wireless connections. For example, the peripherals 138 can include an accelerometer, an electronic compass, a satellite transceiver, a digital camera (for photos and / or videos), a universal serial bus (USB) port, a vibration device, a television transceiver, a hands-free headset, Modules, FM radio units, digital music players, media players, electronic game player modules, Internet browsers, virtual reality and / or augmented reality (VR / AR) devices, activity trackers, etc. Peripheral 138 may include one or more sensors, which may be one or more of a gyroscope, an accelerometer, a Hall effect sensor, a magnetometer, an orientation sensor, a proximity sensor, a temperature sensor, a time sensor; a geographical location sensor; an altimeter, a light sensor, a touch sensor, a magnetometer, a barometer, an attitude sensor, a biometric sensor, and / or a humidity sensor.

[0039] The WTRU 102 may include a full-duplex radio for which the transmission and reception of some or all signals (e.g., associated with a particular subframe for both uplink (e.g., for transmission) and downlink (e.g., for reception)) may be concurrent and / or simultaneous. The full-duplex radio may include an interference management unit 139 to reduce and / or substantially eliminate self-interference through hardware (e.g., a choke) or through signal processing by a processor (e.g., a separate processor (not shown) or by processor 118). In one embodiment, the WTRU 102 may include a half-duplex radio for which the transmission and reception of some or all signals (e.g., associated with a particular subframe for uplink (e.g., for transmission) or downlink (e.g., for reception)).

[0040] Figure 1C Is a system diagram showing the RAN 104 and the CN 106 according to an embodiment. As described above, the RAN 104 may communicate with the WTRU 102a, 102b, 102c via the air interface 116 using E-UTRA radio technology. The RAN 104 may also communicate with the CN 106.

[0041] The RAN 104 may include eNode-Bs 160a, 160b, 160c, but it should be understood that the RAN 104 may include any number of eNode-Bs while remaining consistent with the embodiment. The eNode-Bs 160a, 160b, 160c may each include one or more transceivers for communicating with the WTRU 102a, 102b, 102c via the air interface 116. In one embodiment, the eNode-Bs 160a, 160b, 160c may implement MIMO technology. Thus, for example, the eNode-B 160a may use multiple antennas to transmit wireless signals to and / or receive wireless signals from the WTRU 102a.

[0042] Each of eNode-Bs 160a, 160b, and 160c may be associated with a specific cell (not shown) and may be configured to handle radio resource management decisions, handover decisions, user scheduling in the uplink (UL) and / or downlink (DL), etc. As Figure 1C shown, eNode-Bs 160a, 160b, and 160c may communicate with each other via the X2 interface.

[0043] Figure 1C The CN 106 shown in may include a Mobility Management Entity (MME) 162, a Serving Gateway (SGW) 164, and a Packet Data Network (PDN) Gateway (or PGW) 166. Although each of the foregoing elements is described as part of the CN 106, it should be understood that any of these elements may be owned and / or operated by an entity other than the CN operator.

[0044] The MME 162 may be connected to each of the eNode-Bs 162a, 162b, and 162c in the RAN 104 via the S1 interface and may act as a control node. For example, the MME 162 may be responsible for authenticating users of the WTRUs 102a, 102b, 102c, bearer activation / deactivation, selecting a specific serving gateway during the initial attachment of the WTRUs 102a, 102b, 102c, etc. The MME 162 may provide control plane functions for handover between the RAN 104 and other RANs (not shown) employing other radio technologies such as GSM and / or WCDMA.

[0045] The SGW 164 may be connected to each of the eNode-Bs 160a, 160b, and 160c in the RAN 104 via the S1 interface. The SGW 164 may generally route and forward user data packets to / from the WTRUs 102a, 102b, 102c. The SGW 164 may perform other functions such as anchoring the user plane during handover between eNode-Bs, triggering paging when DL data is available for the WTRUs 102a, 102b, 102c, managing and storing the context of the WTRUs 102a, 102b, 102c, etc.

[0046] The SGW 164 may be connected to the PGW 166, which may provide the WTRUs 102a, 102b, 102c with access to a packet-switched network such as the Internet 110 to facilitate communication between the WTRUs 102a, 102b, 102c and IP-enabled devices.

[0047] CN 106 can facilitate communication with other networks. For example, CN 106 can provide the WTRUs 102a, 102b, 102c with access to a circuit-switched network such as the PSTN 108 to facilitate communication between the WTRUs 102a, 102b, 102c and traditional landline communication devices. For example, CN 106 can include, or communicate with, an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) that acts as an interface between CN 106 and the PSTN 108. Additionally, CN 106 can provide the WTRUs 102a, 102b, 102c with access to other networks 112, which can include other wired and / or wireless networks owned and / or operated by other service providers.

[0048] Although the WTRU is described as a wireless terminal in Figures 1A - 1D it is contemplated that in some representative embodiments, such a terminal may use (e.g., temporarily or permanently) a wired communication interface to the communication network.

[0049] In a representative embodiment, another network 112 can be a WLAN.

[0050] A WLAN in infrastructure basic service set (BSS) mode can have an access point (AP) for the BSS and one or more stations (STAs) associated with the AP. The AP can have access to or an interface with a distributed system (DS) or another type of wired / wireless network that conveys traffic to and / or from the BSS. Traffic destined for an STA from outside the BSS can reach the STA through the AP and can be delivered to the STA. Traffic from an STA to a destination outside the BSS can be sent to the AP to be delivered to the corresponding destination. For example, traffic between STAs within the BSS can be sent through the AP, where the source STA can send the traffic to the AP and the AP can deliver the traffic to the destination STA. Traffic between STAs within the BSS can be considered and / or referred to as peer traffic. Peer traffic can be sent between a source and destination STA (e.g., directly between them) using direct link setup (DLS). In some representative embodiments, DLS can use 802.11e DLS or 802.11z tunnel DLS (TDLS). A WLAN using independent BSS (IBSS) mode may not have an AP, and STAs within the IBSS or using the IBSS (e.g., all STAs) can communicate directly with each other. The IBSS communication mode is sometimes referred to herein as an "ad-hoc" communication mode.

[0051] When operating in 802.11ac infrastructure mode or a similar mode of operation, an AP can transmit beacons on a fixed channel, such as the primary channel. The primary channel can be of a fixed width (e.g., a 20 MHz wide bandwidth) or a width dynamically set by signaling. The primary channel can be the operating channel of the BSS and can be used by STAs to establish a connection with the AP. In some representative embodiments, Carrier Sense Multiple Access with Collision Avoidance (CSMA / CA) can be implemented, such as in 802.11 systems. For CSMA / CA, STAs including the AP (e.g., each STA) can sense the primary channel. If a particular STA senses / detects and / or determines that the primary channel is busy, that particular STA can back off. One STA (e.g., only one station) can transmit at any given time within a given BSS.

[0052] High Throughput (HT) STAs can communicate using 40 MHz wide channels, e.g., by combining the primary 20 MHz channel with an adjacent or non - adjacent 20 MHz channel to form a 40 MHz wide channel.

[0053] Very High Throughput (VHT) STAs can support 20 MHz, 40 MHz, 80 MHz, and / or 160 MHz wide channels. 40 MHz and / or 80 MHz channels can be formed by combining consecutive 20 MHz channels. A 160 MHz channel can be formed by combining eight consecutive 20 MHz channels or by combining two non - consecutive 80 MHz channels, which can be referred to as an 80 + 80 configuration. For the 80 + 80 configuration, after channel coding, the data can pass through a segment parser, which can split the data into two streams. Inverse Fast Fourier Transform (IFFT) processing and time - domain processing can be performed separately on each stream. The streams can be mapped to two 80 MHz channels, and the data can be transmitted by the transmitting STA. At the receiver of the receiving STA, the operation of the above 80 + 80 configuration can be reversed, and the combined data can be sent to the Media Access Control (MAC).

[0054] 802.11af and 802.11ah support sub-1GHz operation modes. The channel operating bandwidth and carriers are reduced in 802.11af and 802.11ah as compared to those used in 802.11n and 802.11ac. 802.11af supports 5MHz, 10MHz, and 20MHz bandwidths in the TV white space (TVWS) spectrum, and 802.11ah uses the non-TVWS spectrum to support 1MHz, 2MHz, 4MHz, 8MHz, and 16MHz bandwidths. According to a representative embodiment, 802.11ah may support metering type control / machine type communication, such as MTC devices in a macro coverage area. The MTC devices may have certain capabilities, for example, limited capabilities, including supporting (e.g., only supporting) certain and / or limited bandwidths. The MTC devices may include a battery with a battery life above a threshold (e.g., to maintain a very long battery life).

[0055] WLAN systems (such as 802.11n, 802.11ac, 802.11af, and 802.11ah) that can support multiple channels and channel bandwidths include channels that can be designated as primary channels. The primary channel may have a bandwidth equal to the maximum common operating bandwidth supported by all STAs in the BSS. The bandwidth of the primary channel may be set and / or limited by the STA that supports the minimum bandwidth operation mode among all STAs operating in the BSS. In an example of 802.11ah, for an STA that supports (e.g., only supports) the 1MHz mode (e.g., an MTC type device), the primary channel may be 1MHz wide, even if the AP and other STAs in the BSS support 2MHz, 4MHz, 8MHz, 16MHz, and / or other channel bandwidth operation modes. Carrier sensing and / or network allocation vector (NAV) settings may depend on the state of the primary channel. If the primary channel is busy transmitting to the AP, for example, due to an STA (only supporting the 1MHz operation mode), the entire available frequency band may be considered busy, even if most of the band remains idle and may be available.

[0056] In the United States, the available frequency band that 802.11ah can use ranges from 902MHz to 928MHz. In Korea, the available frequency band is from 917.5MHz to 923.5MHz. In Japan, the available frequency band is from 916.5MHz to 927.5MHz. The total bandwidth available for 802.11ah is 6MHz to 26MHz, depending on the country code.

[0057] Figure 1DIt is a system diagram showing RAN 113 and CN 115 according to an embodiment. As described above, RAN 113 can communicate with WTRUs 102a, 102b, 102c via air interface 116 using NR radio technology. RAN 113 can also communicate with CN 115.

[0058] RAN 113 can include gNBs 180a, 180b, 180c, but it should be understood that RAN 113 can include any number of gNBs while remaining consistent with the embodiment. gNBs 180a, 180b, 180c can each include one or more transceivers for communicating with WTRUs 102a, 102b, 102c via air interface 116. In one embodiment, gNBs 180a, 180b, 180c can implement MIMO technology. For example, gNBs 180a, 180b can utilize beamforming to transmit signals to / from gNBs 180a, 180b, 180c. Thus, for example, gNB 180a can use multiple antennas to transmit wireless signals to / from WTRU 102a. In one embodiment, gNBs 180a, 180b, 180c can implement carrier aggregation technology. For example, gNB 180a can transmit multiple component carriers (not shown) to WTRU 102a. A subset of these component carriers can be on unlicensed spectrum while the remaining component carriers can be on licensed spectrum. In one embodiment, gNBs 180a, 180b, 180c can implement coordinated multi-point (CoMP) technology. For example, WTRU 102a can receive coordinated transmissions from gNB 180a and gNB 180b (and / or gNB 180c).

[0059] WTRUs 102a, 102b, 102c can communicate with gNBs 180a, 180b, 180c using transmissions associated with scalable numerology. For example, the OFDM symbol interval and / or the OFDM subcarrier interval can be different for different transmissions, different cells, and / or different parts of the radio transmission spectrum. WTRUs 102a, 102b, 102c can use subframes or transmission time intervals (TTIs) of various or scalable lengths (e.g., containing a variable number of OFDM symbols and / or having a continuously variable absolute time length) to communicate with gNBs 180a, 180b, 180c.

[0060] gNB 180a, 180b, 180c can be configured to communicate with WTRUs 102a, 102b, 102c in stand-alone configuration and / or non-stand-alone configuration. In stand-alone configuration, WTRUs 102a, 102b, 102c can communicate with gNB 180a, 180b, 180c without accessing another RAN (e.g., such as eNode-Bs 160a, 160b, 160c). In stand-alone configuration, WTRUs 102a, 102b, 102c can utilize one or more of gNB 180a, 180b, 180c as a mobility anchor. In stand-alone configuration, WTRUs 102a, 102b, 102c can communicate with gNB 180a, 180b, 180c using signals in the unlicensed band. In non-stand-alone configuration, WTRUs 102a, 102b, 102c can communicate / connect with gNB 180a, 180b, 180c while also communicating / connecting with another RAN such as eNode-Bs 160a, 160b, 160c. For example, WTRUs 102a, 102b, 102c can implement the DC principle to communicate with one or more of gNB 180a, 180b, 180c and one or more of eNode-Bs 160a, 160b, 160c substantially simultaneously. In non-stand-alone configuration, eNode-Bs 160a, 160b, 160c can act as the mobility anchor for WTRUs 102a, 102b, 102c, and gNB 180a, 180b, 180c can provide additional coverage and / or throughput for serving WTRUs 102a, 102b, 102c.

[0061] Each of gNB 180a, 180b, 180c can be associated with a specific cell (not shown) and can be configured to handle radio resource management decisions, handover decisions, user scheduling in the uplink (UL) and / or downlink (DL), network slice support, dual connectivity, interworking between NR and E-UTRA, routing user plane data to user plane functions (UPFs) 184a, 184b, routing control plane information to access and mobility management functions (AMFs) 182a, 182b, etc. As Figure 1D shown, gNB 180a, 180b, 180c can communicate with each other via the Xn interface.

[0062] Figure 1DThe illustrated CN 115 may include at least one AMF 182a, 182b, at least one UPF 184a, 184b, at least one session management function (SMF) 183a, 183b, and may include data networks (DN) 185a, 185b. Although each of the foregoing elements is described as part of the CN 115, it should be understood that any of these elements may be owned and / or operated by an entity other than the CN operator.

[0063] The AMF 182a, 182b may be connected to one or more gNBs 180a, 180b, 180c in the RAN 113 via the N2 interface and may act as a control node. For example, the AMF 182a, 182b may be responsible for authenticating users of the WTRU 102a, 102b, 102c, supporting network slicing (e.g., handling different PDU sessions with different requirements), selecting a particular SMF 183a, 183b, managing the registration area, terminating NAS signaling, mobility management, and so on. The AMF 182a, 182b may use network slicing in order to customize the CN support for the WTRU 102a, 102b, 102c based on the type of service used by the WTRU 102a, 102b, 102c. For example, different network slices may be established for different use cases, such as services that rely on ultra-reliable low-latency (URLLC) access, services that rely on enhanced massive mobile broadband (eMBB) access, services for machine type communication (MTC) access, and so on. The AMF 182a, 182b may provide control plane functions for handover between the RAN 113 and other RANs (not shown) that employ other radio technologies, such as LTE, LTE-A, LTE-A Pro, and / or non-3GPP access technologies such as WiFi.

[0064] The SMF 183a, 183b may be connected to the AMF 182a, 182b in the CN 115 via the N11 interface. The SMF 183a, 183b may also be connected to the UPF 184a, 184b in the CN 115 via the N4 interface. The SMF 183a, 183b may select and control the UPF 184a, 184b and configure the routing of traffic through the UPF 184a, 184b. The SMF 183a, 183b may perform other functions, such as managing and allocating UE IP addresses, managing PDU sessions, controlling policy enforcement and QoS, providing downlink data notifications, and so on. The PDU session type may be IP-based, non-IP-based, Ethernet-based, and so on.

[0065] UPF 184a and 184b can be connected to one or more gNBs 180a, 180b, 180c in the RAN 113 via the N3 interface, which can provide the WTRUs 102a, 102b, 102c with access to a packet switched network (such as the Internet 110) to facilitate communication between the WTRUs 102a, 102b, 102c and IP-enabled devices. UPF 184a, 184b can perform other functions such as routing and forwarding packets, implementing user plane policies, supporting multi-homed PDU sessions, handling user plane QoS, buffering downlink packets, providing mobility anchoring, etc.

[0066] The CN 115 can facilitate communication with other networks. For example, the CN 115 can include an IP gateway (such as an IP Multimedia Subsystem (IMS) server) that serves as an interface between the CN 115 and the PSTN 108, or can communicate with the IP gateway. In addition, the CN 115 can provide the WTRUs 102a, 102b, 102c with access to other networks 112, which can include other wired and / or wireless networks owned and / or operated by other service providers. In one embodiment, the WTRUs 102a, 102b, 102c can be connected to local data networks (DNs) 185a, 185b via the N3 interface to the UPF 184a, 184b and the N6 interface between the UPF 184a, 184b and the DNs 185a, 185b.

[0067] In view of Figures 1A - 1D and Figures 1A - 1D the corresponding descriptions, one or more or all of the functions described herein for one or more of the following: WTRUs 102a-d, base stations 114a-b, eNode-Bs 160a-c, MME 162, SGW 164, PGW 166, gNBs 180a-c, AMFs 182a-b, UPFs 184a-b, SMFs 183a-b, DNs 185a-b and / or any other devices described herein can be performed by one or more emulation devices (not shown). The emulation devices can be one or more devices configured to emulate one or more or all of the functions described herein. For example, the emulation devices can be used to test other devices and / or simulate network and / or WTRU functions.

[0068] A simulation device can be designed to implement one or more tests of other devices in a laboratory environment and / or an operator network environment. For example, one or more simulation devices can perform one or more or all functions while being fully or partially implemented and / or deployed as part of a wired and / or wireless communication network in order to test other devices within the communication network. One or more simulation devices can perform one or more or all functions while being temporarily implemented / deployed as part of a wired and / or wireless communication network. For testing purposes, the simulation device can be directly coupled to another device, and / or can use over-the-air wireless communication to perform the test.

[0069] One or more simulation devices can perform one or more functions, including all functions, rather than being implemented / deployed as part of a wired and / or wireless communication network. For example, the simulation device can be used to test test scenarios in a laboratory and / or a non-deployed (e.g., test) wired and / or wireless communication network in order to implement the test of one or more components. One or more simulation devices can be test devices. The simulation device can transmit and / or receive data using direct RF coupling and / or wireless communication via an RF circuit (e.g., which can include one or more antennas).

[0070] The examples provided herein do not limit the applicability of the subject matter to other wireless technologies, e.g., using the same or different principles that may apply.

[0071] As explained herein, a wireless transmit / receive unit (WTRU) can be an example of a user equipment (UE). Thus, the terms “UE” and “WTRU” can be used herein within the same scope.

[0072] Authentication in 5G

[0073] The authentication schemes supported by the 5G system include Extensible Authentication Protocol Transport Layer Security (EAP-TLS) and Extensible Authentication Protocol Tunneled Transport Layer Security (EAP-TTLS).

[0074] When using some EAP-based methods, such as EAP-TLS and EAP-TTLS, an Anonymous Subscribed Hidden Identifier (SUCI) can be used and the actual Subscribed Permanent Identifier (SUPI) can be sent after establishing an EAP secure channel (e.g., a TLS tunnel). Encryption can be performed using a cipher, such as Advanced Encryption Standard in Galios / Counter Mode (AESGCM), Advanced Encryption Standard-Counter with Cipher Block Chaining-Message Authentication Code (AES CCM), or Advanced Encryption Standard-Counter with Cipher Block Chaining (AES CBC).

[0075] 3GPP is currently studying the privacy aspects of the subscription identifier 3GPP TR 33.870 v0.4.0. When using the current authentication procedures above (e.g., EAP-TLS and EAP-TTLS), the following problems exist.

[0076] The length of the SUPI of the NAI type will be available to passive eavesdroppers who can leak the SUPI privacy.

[0077] The IETF RFC5246 Transport Layer Security (TLS) protocol states: "Any protocol designed to be used over TLS must be carefully designed to counter all possible attacks on it. In practice, this means that protocol designers must know what security properties TLS provides and does not provide, and cannot safely rely on the latter. In particular, note that the type and length of the records are not protected by encryption".

[0078] That is, the procedures described in clauses B, U, and I of 3GPP TS 33.501 will leak the privacy of the WTRU identifier based on the potential exposure of its length.

[0079] Therefore, when transmitted as part of the EAP-TLS / EAP-TTLS authentication protocol, the existing privacy protection of the SUPI in the NAI format needs to be enhanced.

[0080] Currently, 3GPP TS 33.501 supports the authentication of Standalone Non-Public Networks (SNPNs) using EAP-TLS and EAP-TTLS. However, the lengths of the identities (e.g., certificates) and / or parameters (e.g., credentials, tokens, passwords) are not protected, and when using length-preserving encryption algorithms, the encrypted values will allow attackers to collect the differences (or "sameness") in the lengths of the identities and / or parameters, and leak privacy-related information, namely the so-called privacy "breadcrumbs". In addition, when the length of the password is known to the attacker, performing password cracking attacks, such as brute-force attacks, will be much easier.

[0081] A method of obscuring the lengths of identities and / or parameters in the ciphertext within the EAP-TLS and EAP-TTLS tunnels is desirable for protecting against privacy leaks or the strength of credentials / passwords / tokens.

[0082] Security enhancement

[0083] The embodiments described herein address the need to obscure the lengths of identities and / or parameters during the authentication of SNPNs using EAP-TLS and EAP-TTLS with and without an Authentication, Authorization, and Accounting (AAA) server.

[0084] The embodiments described herein are based on the principle that using random padding will remedy privacy attacks, in which an attacker can observe the ciphertext length protected by an EAP-TLS or EAP-TTLS tunnel and assume that the ciphertext length corresponds to the plaintext length.

[0085] Figure 2 is a high-level block diagram showing the basic operation according to these principles. As shown, the identities and / or parameters in the ciphertext within the EAP-TLS and EAP-TTLS tunnels (210) are fed into a padding algorithm (220) that pads the information to an unpredictable length and thus does not reveal information about the actual length of the identities and / or parameters in the ciphertext within the EAP-TLS and EAP-TTLS tunnels. An exemplary padding process can be found in PCT patent publication WO2023 / 059773 titled “Methods, Architectures, Apparatuses and Systems for Concealing Data”.

[0086] Next, the padded information is encrypted for transmission (230). At the receiving node, the information is decrypted (240) and de-padded (250) to reveal the original identities, credentials, parameters, etc. (260).

[0087] The embodiments described herein make the lengths of the encrypted identities, credentials, and parameters unpredictable and thus remedy the possibility of privacy attacks by basing on the observation of lengths and establishing a connection with the lengths of the ciphertext transmitted within, for example, an EAP-TLS / EAP-TTLS secure tunnel.

[0088] Example based on WTRU and network for obfuscating identity and / or parameter lengths during EAP - TLS SNPN authentication (without AAA) Length

[0089] The first embodiment applies the principles herein described above to provide WTRU- and network-based means to obfuscate the lengths of identities and / or parameters during EAP-TLS SNPN authentication (without AAA) using padding of certificates before TLS encryption.

[0090] Figure 3A and Figure 3B describes the first embodiment. Note that Figure 3 is based on and modifies B.2.1.1-1 found in 3GPP TS 33.501 Annex B: Initial authentication using the EAP-TLS authentication procedure over a 5G network. Figure 3A and Figure 3B The terms steps and messages in can be used interchangeably.

[0091] Initially, the WTRU 301 sends a registration request message 3-1 to the Security Anchor Function (SEAF), containing the SUCI or "anonymous" as the Network Access Identifier (NAI) user name if the SUPI is in NAI format and anonymous authentication is selected. If the SUPI is in NAI format, only the user name part of the NAI is encrypted using the selected protection scheme and included in the SUCI together with the realm part in the NAI required for routing to the Unified Data Management (UDM).

[0092] Privacy considerations are described in clause B.2.2 of annex B of 3GPP TS 33.501.

[0093] Next, the SEAF sends a Nausf_UE Authentication_Authenticate Request message 3-2 to the Authentication Server Function (AUSF) 305. The message includes the SUCI and the serving network name (as described in clause 6.1.1.4 of 3GPP TS 33.501). If the SUPI in NAI format is selected and anonymous authentication is selected, the user name of the NAI is used as "anonymous" or left blank.

[0094] Then, the AUSF sends a Nudm_UE Authentication_Get Request 3-3 containing the SUCI and the serving network name to the UDM 307. The general rules selected by the UDM apply.

[0095] If the SUCI is received in the message, the Subscription Identifier Deconcealment Function (SIDF) within the UDM 307 deconceals the SUCI to the SUPI. Then, the UDM selects the primary authentication method, as indicated by 3-4 in Figure 3.

[0096] If the UDM 307 selects to use EAP-TLS, it sends the SUPI and an indicator of selecting EAP-TLS to the AUSF in the Nudm_UE Authentication_Get Response 3-5.

[0097] Using the received SUPI and indicator, the AUSF 305 selects EAP-TLS as the authentication method. The AUSF sends a Nausf_UE Authentication_Authenticate Response message 6-6 containing an EAP-Request / EAP-TLS [TLS Start] message to the SEAF 303.

[0098] The SEAF 303 forwards the EAP-Request / EAP-TLS [TLS Start] to the WTRU 301 in the authentication request message 3-7. This message also includes the key set identifier (ngKS) and the inter-architecture anti-bidding (ABBA) parameter. In fact, the SEAF 303 should always include the ngKSI and ABBA parameters in all EAP authentication request messages. The ngKSI will be used by the WTRU and the AMF to identify the partial native security context that will be created if the authentication is successful. The SEAF shall set the ABBA parameter as defined in Appendix A.7.1 of 3GPP TS 33.501. During the EAP authentication, the values of the ngKSI and ABBA parameters sent by the SEAF to the WTRU shall not change.

[0099] After receiving the EAP-TLS [TLS-Start] message from the SEAF, the WTRU replies to the SEAF 303 with an EAP-Response / EAP-TLS [Client_Hello] in the authentication response message 3-8. The content of the TLS Client_Hello is defined in the TLS specification of the TLS version in use.

[0100] The EAP framework supports the negotiation of EAP methods. If the WTRU does not support EAP-TLS, it should follow the rules described in 3GPP Request for Comments (RFC) 3748 Extensible Authentication Protocol (EAP) to negotiate another EAP method. In the 5G system, the UDM usually knows which EAP methods and credentials the subscriber supports and, therefore, may never use EAP-based negotiation.

[0101] The SEAF 303 forwards the EAP-Response / EAP-TLS [Client Hello] message to the AUSF 305 in the Nausf_UE Authentication_Authentication Request 3-9.

[0102] The AUSF 305 replies to the SEAF 303 with an EAP-Request / EAP-TLS in the Nausf_UE Authentication_Authentication Response 3-10. This EAP-Request / EAP-TLS also includes information elements such as Server_Hello, Server_Certificate, Server_Key_Exchange, Certificate_Request, Server_Hello_Done. These information elements are defined in the RFC of the corresponding TLS version in use.

[0103] The SEAF 303 forwards the EAP-Request / EAP-TLS message with Server_Hello and other information elements to the WTRU via the authentication request message 3-11. This message also includes the ngKSI and ABBA parameters. The SEAF shall set the ABBA parameter as defined in Appendix A.7.1 of 3GPP TS33.501.

[0104] Between 3-12, the WTRU 301 authenticates the server with the received Message 11.

[0105] The WTRU needs to be pre-configured with the WTRU certificate and a certificate that can be used to verify the server certificate.

[0106] Between 3-13, the WTRU 301 applies padding to the entire WTRU X.509 certificate. This can be extended to include any of the following in plaintext: identifiers, parameters, credentials, tokens, etc.

[0107] If the TLS server authentication is successful, the WTRU replies with an EAP-Response / EAP-TLS in the authentication response message 3-14, which also contains information elements such as client_certificate, client_key_exchange, client_certificate_verify, change_cipher_spec, client_finished, etc. Privacy considerations are described in clause B.2.1.2 of 3GPP TS 33.501.

[0108] The SEAF 303 forwards the message with the EAP-Response / EAP-TLS message (with the client_certificate and other information elements) to the AUSF 305 in the Nausf_UE Authentication_Authenticate Request 3-15.

[0109] The AUSF 305 sends a Nudm_UE Authentication_Get Request 3-16 containing the SUCI (identity, parameters, credentials, tokens, etc.) and the serving network name to the UDM 307. The general rules selected by the UDM apply.

[0110] Between 3-17, the SIDF depads the information padded in step 13 into plaintext, including identity, parameters, credentials, tokens, etc.

[0111] The SIDF located within the UDM unhides the SUCI (if the SUCI is received in the message) or the identity, parameters, credentials, tokens, etc. from the SUPI. Then, the UDM selects the primary authentication method and transmits this information to the AUSF 305 in the Nudm_UE Authentication_Get Response 3-18.

[0112] Between 3-19, the AUSF 305 authenticates the WTRU based on the received message. The AUSF verifies that the client certificate provided by the WTRU belongs to the subscriber identified by the SUPI. If the subscriber identifier in the SUPI does not match, the AUSF does not accept the client certificate. If the AUSF has successfully verified the message, the AUSF proceeds to step 3-19, otherwise it returns an EAP-Failure.

[0113] The AUSF needs to be pre-configured with the root certificate or any intermediate certificate authority (CA) certificate that can be used to verify the WTRU certificate. The deployment of the Certificate Revocation List (CRL) and the Online Certificate Status Protocol (OCSP) is described in clause B.2.2

[0114] The AUSF 305 sends an EAP-Request / EAP-TLS message with Change_Cipher_Spec and Server_Complete to the SEAF 303 in Nausf_UE Authentication_Authentication Response 3-20

[0115] The SEAF 303 forwards the EAP-Request / EAP-TLS message from step 20 to the WTRU 301 in the Authentication Request message 3-21. This message also includes the ngKSI and ABBA parameters. The SEAF shall set the ABBA parameters as defined in appendix A.7.1 of 3GPP TS 33.501

[0116] The WTRU 301 sends an empty EAP-TLS message to the SEAF in the Authentication Response message 3-22

[0117] The SEAF 303 also forwards the EAP-Response / EAP-TLS message to the AUSF 305 in Nausf_UE Authentication_Authentication Request 3-23

[0118] The AUSF 305 uses the most significant 256 bits of the Extended Master Session Key (EMSK) as the Authentication Server Function Key (K AUSF ) and then calculates K AUSF as described in appendix A.6 of 3GPP TS 33.501. The AUSF 305 sends an EAP-Success message together with the SUPI and the derived anchor key to the SEAF 303 in Nausf_UE Authentication_Authentication Response 3-24 SEAF

[0119] The SEAF 303 forwards the EAP-Success message to the WTRU 301 in the N1 message 25 and the authentication process is completed. This message also includes the ngKSI and ABBA parameters. The SEAF shall set the ABBA parameters as defined in appendix A.7.1 of 3GPP TS 33.501. Then, the SEAF derives K SEAF from K AMF , the ABBA parameters and the SUPI according to appendix A.7 of 3GPP TS 33.501, and provides the ngKSI and the KAMF to the AMF

[0120] Upon receiving the EAP-Success message 3-25, the WTRU 301 derives the EMSK and uses the most significant 256 bits of the EMSK as K AUSF ​, and then calculates K in the same manner as the AUSF SEAF . The WTRU derives K SEAF from K, the ABBA parameter, and the SUPI according to Appendix A.7 of 3GPP TS 33.501 AMF .

[0121] Note that step / message 3-25 may be a NAS security mode command or an authentication result.

[0122] The inclusion of the ABBA parameter is to enable downgrade protection for security features that may be introduced in the future.

[0123] Note that as an implementation option, after receiving an EAP message that permits the calculation of EMSK, the WTRU may create a temporary security context as described in step / message 3-25. When the WTRU receives EAP success, it converts this temporary security context into a partial security context. If the EAP authentication fails, the WTRU removes the temporary security context.

[0124] Example based on WTRU and network for obfuscating identity and / or parameter lengths during EAP - TTLS SNPN authentication using an AAA server and a UDM containing SIDF Length

[0125] The second embodiment applies the principles herein described above to provide a WTRU- and network-based solution to pad with variable length parameters before TTLS encryption to obfuscate the identity and / or the length of the parameters during EAP-TTLS SNPN authentication leveraging an AAA server.

[0126] Figure 4A 、 4B 、4C, 4D, and 4E together include a signal flow diagram depicting an exemplary implementation of this embodiment. Note that Figure 4A 、 4B 、4C, 4D, and 4E are based on Figure U.2-1 from Appendix U of 3GPP TS 33.501: Main Authentication Using EAP-TTLS and AAA. Figures 4A - 4E The terms step and message may be used interchangeably herein.

[0127] Prior to Figure 4A 、 4B and the activities depicted in 4C, the WTRU is configured with a trust anchor required to authenticate the certificate of the EAP-TTLS server running on the AUSF. Additionally, the WTRU is configured with the credentials required to authenticate to the AAA server.

[0128] Figure 4A 、 4B 、Steps or messages 4-1 through 4-17 in 4C, 4D, and 4E are the same as steps / messages 1-17 in clause B.2.2.1 of Appendix B of 3GPP TS 33.501 (Figure 3A and 3B Based on this, but with significant modifications), except that: in Figure 4A In step 4-1, a SUPI in NAI format, i.e., username@realm, is used. In step 4-2, the AMF / SEAF 403 sends an authentication request. In step 4-3, the AUSF 405 sends an authentication request to the UDM / SIDF 407. In step 4-4, the UDM / SIDT makes an authentication method selection. In step 4-5, the UDM 407 selects EAP-TTLS as the authentication method. In steps 4-6 to 4-17, the EAP-TTLS phase 1 is executed between the AUSF 405 and the WTRU 401. The EAP-type is set to EAP-TTLS, and the WTRU authentication using the TLS client certificate is skipped. Since the TLS client certificate is not used in EAP-TTLS, the WTRU does not need to be configured with a WTRU certificate.

[0129] Then, at 4-18, the WTRU401 applies padding to the username and password in accordance with MS-CHAP-v2 used as an example in Appendix U of TS 33.501. This padding can be applied to the plaintext of any one of identity, parameters, credentials, tokens, passwords, etc.

[0130] After the successful completion of the EAP-TTLS phase 1, the WTRU 401 performs the EAP-TTLS phase 2 authentication via the network slice specific authentication and authorization (NSSAAF) using the AAA specified in IETF RFC 5281 Extensible Authentication Protocol Transport Layer Security, as shown in messages 4-19 and 4-20. The phase 2 authentication method used is outside the scope of this document, but MS-CHAPv2 is depicted here as an example to show that if the phase 2 authentication method is non-EAP, the Nnssaaf_AIW_authentication service provided by the NSSAAF carries the AVP. As cited in section 14.1.11 of IETF RFC 5281, allowing the use of the phase 2 (inner) authentication method outside the tunnel protocol results in a man-in-the-middle (MitM) vulnerability. Therefore, it is assumed that the WTRU is not allowed to use the phase 2 authentication method outside the TLS tunnel (i.e., the WTRU does not respond to requests for phase 2 authentication outside the TLS tunnel). In an environment where it is not possible to prevent the use of the phase 2 authentication outside the tunnel protocol, the EAP-TTLS implementation needs to address this vulnerability by using EAP channel binding or password binding of the tunnel-based Extensible Authentication Protocol (EAP) method described in the requirements of IETF RFC 6678.

[0131] In step 4-21, the AUSF sends a request to decrypt the ciphertext protected by the TLS tunnel leading to the NSSAAF. The ciphertext includes identity, parameters, credentials, tokens, etc.

[0132] In step 4-22, the NSSAAF sends an AAA request to decrypt the ciphertext protected by the TLS tunnel to the AAA. The ciphertext includes identity, parameters, credentials, tokens, etc.

[0133] In step 4-23, the AAA decrypts the padded ciphertext protected by the TLS tunnel. The ciphertext includes identity, parameters, credentials, tokens, etc.

[0134] In step 4-24, the AAA replies to the NSSAAF with the padded plaintext of the identity, parameters, credentials, tokens, etc.

[0135] In step 4-25, the NSSAAF proxy-transmits the padded plaintext of the identity, parameters, credentials, tokens, etc. to the AUSF.

[0136] In step 4-26, the AUSF 405 forwards the padded plaintext received in step 25, which includes identity, parameters, credentials, tokens, etc., to the SIDF 407 for depadding.

[0137] In 4-27, the SIDF 407 depads the information padded in step 18 into plaintext. The plaintext includes identity, parameters, credentials, tokens, etc.

[0138] In 4-28, the SIDF 407 forwards the depadded information and the parameters and identity ready for use to the AUSF 405.

[0139] Steps 4-29 to 4-40 are pre-existing steps in Annex U of 3GPP TS 33.501 and will not be described in detail here. In steps 4-29 to 4-36, MS-CHAP2 is used as an example internal authentication method according to Annex U of 3GPP TS 33.501. (Note that this step is added only because the initial call flow description (steps 18-40) is interrupted by the insertion of steps 4-21 to 4-28.)

[0140] After successful completion of the EAP-TTLS phase 2 authentication, except for setting the EAP-type to EAP-TTLS in the EAP response message from the WTRU 401 to the AUSF 405, the remaining processes (i.e., steps 4-37 to 4-40) are the same as steps 18-21 in clause B.2.1.1 of Annex B of 3GPP TS33.501.

[0141] Example based on WTRU and network for obfuscating identity and / or parameter lengths during EAP - TTLS SNPN authentication using an AAA server with a depadding function Length

[0142] Figure 5A and 5B 5C and 5D together include a signal flow diagram depicting an exemplary implementation of another embodiment. This embodiment is similar to Figure 4A and 4B the embodiments of 4C, 4D, and 4E, but the depopulation function is at the AAA instead of the UDM / SIDF, which provides a simpler process. Figures 5A - 5D The terms steps and messages in

[0143] Figure 5A and 5B Steps 5-1 to 5-20 in the embodiments of 5C and 5D are the same as those in Figure 4A and 4B 4C, 4D, and 4E and will not be described again here.

[0144] In this embodiment, the depopulation function resides in the AAA 511 instead of the UDM 507. Thus, at 5-21, the AUSF 505 forwards the information filled in step 5-18 to the NSSAAF 509 in plaintext, including identity, parameters, credentials, tokens, etc.

[0145] At 5-22, the NSSAAF forwards the information in an AAA protocol message to the AAA 411.

[0146] At 5-23, the depopulation function at the AAA depopulates the information filled in step 18 into plaintext, which includes identity, parameters, credentials, tokens, etc.

[0147] Then, steps 5-24 to 5-33 are substantially the same as steps 4-26 to 4-35 in Figure 4A and 4B 4C and will not be described again here.

[0148] Figure 6 is an example flowchart depicting a method according to the principles of the present disclosure. For example, Figure 6 method 600 of Figure 6 can represent the events depicted in the set of FIG. 4 from the perspective of a 5G core system component (e.g., an authentication server function (AUSF) 405). However, this method functionality can reside in any suitable 5G core component. Here,

[0149] In Figure 6In step 605, the core network device receives an authentication request that includes a ciphertext of user equipment (UE) credentials with bit-padding. In one example, the core network device receives the authentication request from a security anchor function (SEAF) within an access and mobility management function (AMF). In one example, the core network device may receive an authentication request that includes an Extensible Authentication Protocol Transport Layer Security (EAP-TTLS) request.

[0150] In step 610, the core network device transmits a request to decrypt the ciphertext, and the decryption request may be transmitted to an authentication and authorization function. In one example, the core network device transmits a request to decrypt a ciphertext of user equipment (UE) credentials with bit-padding, and the ciphertext may include encrypted text of one or more of the following: the identity of a WTRU with bit-padding, parameters, credentials, and tokens. In one example, the core network device transmits the request to decrypt the ciphertext to a slice-specific authentication and authorization function (NSSAAF), where the ciphertext is protected by a Transport Layer Security (TLS) tunnel.

[0151] In step 615, the core network device receives the decrypted ciphertext from the authentication and authorization function, and the decrypted ciphertext includes the plaintext of WTRU credentials with bit-padding.

[0152] In 620, the core network device transmits the plaintext of the WTRU credentials with bit-padding to a dehiding function to remove the bit-padding of the decrypted text. In one example, the core network device transmits the plaintext of the WTRU credentials with bit-padding to a subscription identifier dehiding function (SIDF) within a unified data management (UDM) function to remove the bit-padding of the decrypted text.

[0153] In 625, the core network device receives the plaintext of the de-padded WTRU credentials from the dehiding function.

[0154] In 630, the core network device transmits the de-padded WTRU credentials to the authentication and authorization function for authentication. Here, the core network device seeks authentication of the WTRU from a network authentication function.

[0155] In step 635, if the authentication is successful, the core network device receives the authentication of the de-padded WTRU credentials from the network. Here, the core network device receives an Extensible Authentication Protocol Transport Layer Security (EAP-TTLS) authentication of the de-padded WTRU credentials.

[0156] Conclusion

[0157] Although features and elements are provided above in specific combinations, it will be understood by those skilled in the art that each feature or element can be used alone or in combination with other features and elements. The present disclosure is not limited to the specific embodiments described in this application, which are intended to illustrate various aspects. Without departing from the spirit and scope of the present invention, many modifications and changes may be made, as will be apparent to those skilled in the art. Any element, action or instruction used in the description of this application should not be interpreted as being critical or necessary to the present invention unless explicitly provided as such. According to the foregoing description, in addition to the methods and devices listed here, functionally equivalent methods and devices within the scope of the present disclosure are apparent to those skilled in the art. Such modifications and changes are intended to fall within the scope of the appended claims. The present disclosure is limited only by the terms of the appended claims and the full scope of equivalents to which these claims are assigned. It should be understood that the present disclosure is not limited to a specific method or system.

[0158] For simplicity, the foregoing embodiments are discussed with respect to terminology and structure of devices having infrared capabilities (i.e., infrared transmitters and receivers). However, the embodiments discussed are not limited to these systems, but can be applied to other systems using other forms of electromagnetic waves or non-electromagnetic waves (such as sound waves).

[0159] It should also be understood that the terminology used herein is for the purpose of describing specific embodiments only and is not intended to be limiting. As used herein, the term "video" or the term "image" may refer to any of a snapshot, a single image, and / or a plurality of images displayed on a time basis. As another example, when referred to herein, the term "user equipment" and its abbreviation "UE", the term "remote" and / or the term "head-mounted display" and its abbreviation "HMD" may represent or include (i) a wireless transmission and / or reception unit (WTRU); (ii) any one of a plurality of embodiments of a WTRU; (iii) a device having wireless capabilities and / or wired capabilities (e.g., tetherable), which is particularly configured with some or all of the structure and functionality of a WTRU; (iii) a device having wireless capabilities and / or wired capabilities configured with less than all of the structure and functionality of a WTRU; or (iv) the like. References herein Figures 1A - 1D Details of an example WTRU are provided that may represent any WTRU described herein. As another example, various embodiments disclosed above and below are described as utilizing a head mounted display. Those skilled in the art will recognize that devices other than head mounted displays may be utilized and that some or all of the present disclosure and various disclosed embodiments may be modified accordingly without undue experimentation. Examples of such other devices may include drones or other devices configured to stream information to provide an adapted reality experience.

[0160] In addition, the methods provided herein can be implemented in a computer program, software, or firmware that is included in a computer-readable medium for execution by a computer or a processor. Examples of computer-readable media include electrical signals (transmitted via a wired or wireless connection) and computer-readable storage media. Examples of computer-readable storage media include, but are not limited to, read-only memory (ROM), random access memory (RAM), registers, cache memory, semiconductor memory devices, magnetic media such as internal hard disks and removable disks, magneto-optical media, and optical media such as CD-ROM disks and digital versatile disks (DVDs). A processor associated with the software can be used to implement a radio frequency transceiver for use in a WTRU, UE, terminal, base station, RNC, MME, EPC, AMF, or any host computer.

[0161] Variations of the methods, devices, and systems provided above are possible without departing from the scope of the present invention. Given the various embodiments that can be applied, it should be understood that the illustrated embodiments are merely examples and should not be considered as limiting the scope of the appended claims. For example, the embodiments provided herein include a handheld device that can include or be used in conjunction with any suitable voltage source that provides any suitable voltage, such as a battery, etc.

[0162] In addition, in the embodiments provided above, processing platforms, computing systems, controllers, and other devices that include a processor are mentioned. These devices can include at least one central processing unit (“CPU”) and a memory. In accordance with the practice of those skilled in the art of computer programming, references to symbolic representations of actions and operations or instructions can be performed by various CPUs and memories. Such actions and operations or instructions can be referred to as being “executed,” “computer-executed,” or “CPU-executed.”

[0163] Those of ordinary skill in the art will understand that the actions and symbolic representations of operations or instructions include the manipulation of electrical signals by a CPU. The electrical system represents data bits that can result in the ultimate conversion or reduction of electrical signals and maintain the data bits in a memory location in the memory system, thereby reconfiguring or otherwise changing the operation of the CPU and other processing of the signals. The memory location that maintains the data bits is a physical location that has a particular electrical, magnetic, optical, or organic property corresponding to or representing the data bits. It should be understood that the embodiments are not limited to the above platforms or CPUs, and other platforms and CPUs can support the methods provided.

[0164] The data bits can also be maintained on a computer-readable medium, including magnetic disks, optical disks, and any other volatile (e.g., random access memory (RAM)) or non-volatile (e.g., read-only memory (ROM)) mass storage system readable by a CPU. The computer-readable medium can include cooperative or interconnected computer-readable media that are specifically present on a processing system or distributed among multiple interconnected processing systems, which can be local or remote to the processing system. It should be understood that the embodiments are not limited to the above-mentioned memories, and other platforms and memories can support the provided methods.

[0165] In an illustrative embodiment, any operations, processes, etc. described herein can be implemented as computer-readable instructions stored on a computer-readable medium. The computer-readable instructions can be executed by a processor of a mobile unit, a network element, and / or any other computing device.

[0166] There is little difference between the hardware and software implementations of aspects of the system. The use of hardware or software is generally (but not always, as in some cases, the choice between hardware and software may become important) a design choice representing a cost-versus-efficiency trade-off. There can be various means for implementing the processes and / or systems and / or other technologies described herein (e.g., hardware, software, and / or firmware), and the preferred means can vary with the environment in which the process and / or system and / or other technology is deployed. For example, if the implementer determines that speed and accuracy are of utmost importance, the implementer can select a tool that is primarily hardware and / or firmware. If flexibility is of utmost importance, the implementer may choose a primarily software implementation. Alternatively, the implementer can select some combination of hardware, software, and / or firmware.

[0167] The foregoing detailed description has set forth various embodiments of devices and / or processes using block diagrams, flowcharts, and / or examples. Insofar as such block diagrams, flowcharts, and / or examples include one or more functions and / or operations, those skilled in the art will recognize that each function and / or operation in such block diagrams, flowcharts, or examples can be implemented, individually and / or collectively, by a variety of hardware, software, firmware, or virtually any combination thereof. In an embodiment, several parts of the subject matter described herein can be implemented by application specific integrated circuits (ASICs), field programmable gate arrays (FPGAs), digital signal processors (DSPs), and / or other integrated formats. However, those skilled in the art will recognize that some aspects of the embodiments disclosed herein can be equivalently implemented, in whole or in part, in integrated circuits, as one or more computer programs running on one or more computers (e.g., as one or more programs running on one or more computer systems), as one or more programs running on one or more processors (e.g., as one or more programs running on one or more microprocessors), as firmware, or as virtually any combination thereof, and designing the circuitry and / or writing the code for the software and / or firmware would be well within the skill of one of ordinary skill in the art in light of this disclosure. Further, those skilled in the art will appreciate that the mechanisms of the subject matter described herein can be distributed in a variety of forms as a program product, and illustrative embodiments of the subject matter described herein apply regardless of the particular type of signal bearing medium used to actually effect the distribution. Examples of signal bearing media include, but are not limited to, the following: recordable type media such as floppy disks, hard disk drives, CDs, DVDs, digital tape, computer memory, etc., and transmission type media such as digital and / or analog communication media (e.g., fiber optic cables, waveguides, wired communication links, wireless communication links, etc.).

[0168] Those skilled in the art will recognize that in the art, it is common to describe devices and / or processes in the manner set forth herein and then integrate the devices and / or processes so described into a data processing system using engineering practices. That is, at least a portion of the devices and / or processes described herein can be integrated into a data processing system through a reasonable amount of experimentation. Those skilled in the art will recognize that a typical data processing system can generally include one or more of the following: a system unit enclosure, a video display device, memories such as volatile and non-volatile memories, processors such as microprocessors and digital signal processors, computing entities such as operating systems, drivers, graphical user interfaces, and applications, one or more interaction devices such as touchpads or screens, and / or a control system including feedback loops and control motors (e.g., feedback for sensing position and / or speed, control motors for moving and / or adjusting components and / or quantities). A typical data processing system can be implemented using any suitable commercially available components, such as those commonly found in data computing / communication and / or network computing / communication systems.

[0169] The subject matter described herein is sometimes shown including different components within or connected to different other components. It should be understood that such described architectures are merely examples and that in fact many other architectures can be implemented that achieve the same functionality. In a conceptual sense, any arrangement of components that achieves the same functionality is effectively "associated" such that the desired functionality can be achieved. Thus, any two components that are combined to achieve a particular functionality can be considered "associated" with each other such that the desired functionality is achieved, regardless of the architecture or intermediate components. Similarly, any two components so associated can also be considered "operably connected" or "operably coupled" to each other to achieve the desired functionality, and any two components that can be so associated can also be considered "operably coupled" to each other to achieve the desired functionality. Specific examples of operable coupling include, but are not limited to, components that physically mate and / or physically interact and / or components that wirelessly interact and / or wirelessly interact and / or components that logically interact and / or can logically interact.

[0170] Regarding the use of substantially any plural and / or singular terms herein, those skilled in the art can appropriately translate from plural to singular and / or from singular to plural depending on the context and / or application. For clarity, various singular / plural permutations may be set forth herein.

[0171] Those skilled in the art will understand that, generally, the terms used herein, particularly the terms used in the appended claims (e.g., the subject matter of the appended claims), are generally intended to be "open" terms (e.g., the term "comprising" should be interpreted as "comprising but not limited to", the term "having" should be interpreted as "having at least", the term "including" should be interpreted as "including but not limited to", etc.) and / or "permissive" terms (e.g., the terms "is" and / or "are" can be interpreted as "can" and / or "may", the term "relates to" can be interpreted as "can relate to" and / or "may relate to", the term "receives" can be interpreted as "can receive" and / or "may receive", the term "supports" can be interpreted as "can support" and / or "may support", the term "docks" can be interpreted as "can dock" and / or "may dock", the term "transmits" can be interpreted as "can dock" and / or "may dock", "can transmit" and / or "may transmit", the term "sends" can be interpreted as "can send" and / or "may send", the term "does not relate to" (and / or similar terms) can be interpreted as "can not relate to" and / or "may not relate to", the term "does not receive" (and / or similar terms) can be interpreted as "can not receive" and / or "may not receive", the term "does not support" (and / or similar terms) can be interpreted as "can not support" and / or "may not support", the term "does not dock" (and / or similar terms) can be interpreted as "can not dock" and / or "may not dock", the term "does not transmit" (and / or similar terms) can be interpreted as "can not transmit" and / or "may not transmit", the term "does not send" (and / or similar terms) can be interpreted as "can not send" and / or "may not send", etc.). Those skilled in the art will further understand that if the intention is to introduce a specific number of elements recited in the claim, such intention will be expressly recited in the claim, and if there is no such recitation, there is no such intention. For example, in the case where only one item is intended, the term "single" or similar language may be used. For the sake of understanding, the appended claims and / or the description hereinbelow may include the use of the introductory phrases "at least one" and "one or more" to introduce the elements recited in the claim. However, the use of such phrases should not be construed as implying that the introduction of an element recited in the claim by the indefinite article "a" or "an" limits any particular claim including such introduced element to an embodiment including only one such recited element, even when the same claim includes the introductory phrase "one or more" or "at least one" as well as the indefinite article such as "a" or "an" (e.g., "a" and / or "an" should be interpreted as meaning "at least one" or "one or more"). This also applies to the use of the definite article used to introduce the elements recited in the claim.In addition, even if the specific quantity recited in the introduced claim is explicitly recited, those skilled in the art will recognize that such recitation should be construed as meaning at least the recited quantity (e.g., a simple recitation of "two recitations" without any other modifiers means at least two recitations, or two or more recitations). Further, in those cases similar to the convention of "at least one of A, B, and C, etc.", generally, such a construction is intended to enable those skilled in the art to understand the convention (e.g., "a system having at least one of A, B, and C" will include, but not be limited to, systems having A alone, B alone, C alone, A and B together, A and C together, B and C together, and / or A, B, and C together, etc.). In those cases similar to the convention of "at least one of A, B, or C, etc.", generally, such a construction is intended to enable those skilled in the art to understand the convention (e.g., "a system having at least one of A, B, or C" will include, but not be limited to, systems having A alone, B alone, C alone, A and B together, A and C together, B and C together, and / or A, B, and C together, etc.). Those skilled in the art will further understand that, whether in the specification, the claims, or the drawings, any disjunctive word and / or phrase that actually represents two or more alternative terms should be understood as being intended to include the possibility of one of the terms, either term, or both terms. For example, the phrase "A or B" will be understood to include the possibility of "A" or "B" or "A and B". Further, as used herein, the term "any" followed by a list of multiple items and / or multiple categories of items is intended to include, individually or in combination with other items and / or other categories of items, "any one", "any combination", "any plurality", and / or "any combination of a plurality" of the items and / or categories of items. Further, as used herein, the term "set" is intended to include any number of items, including zero. Further, as used herein, the term "quantity" is intended to include any number, including zero. And the term "plurality" used herein is intended to be synonymous with "a plurality".

[0172] In addition, in cases where the features or aspects of the present disclosure are described in terms of a Markush group, those skilled in the art will recognize that the present disclosure is also thereby described in terms of any single member or subgroup of members of the Markush group.

[0173] As those skilled in the art will appreciate, for any and all purposes, such as to provide a written description, all ranges disclosed herein also include any and all possible sub-ranges and combinations of sub-ranges thereof. Any listed range can be readily viewed as being fully described and capable of being divided into at least equal halves, thirds, quarters, fifths, tenths, etc. As a non-limiting example, each range discussed herein can be readily broken down into a lower third, middle third, and upper third, etc. Those skilled in the art will also understand that all language such as "up to", "at least", "greater than", "less than", etc., includes the recited numbers and refers to ranges that can then be broken down into the sub-ranges as described above. Finally, as those skilled in the art will understand, a range includes each individual member. Thus, for example, a group having 1 - 3 cells refers to a group having 1, 2, or 3 cells. Similarly, a group having 1 - 5 cells refers to a group having 1, 2, 3, 4, or 5 cells, and so on.

[0174] In addition, the claims should not be construed as limited to the provided order or elements, unless stated otherwise. Further, the use of the term "means for" in any claim is intended to reference a means-plus-function claim format, and any claim without the term "means for" does not have such an intent.

[0175] By way of example, suitable processors include general-purpose processors, dedicated processors, conventional processors, digital signal processors (DSPs), multiple microprocessors, one or more microprocessors associated with a DSP core, controllers, microcontrollers, application specific integrated circuits (ASICs), application specific standard products (ASSPs), field programmable gate array (FPGA) circuits, any other type of integrated circuit (IC), and / or state machines.

[0176] A WTRU may be used in conjunction with modules implemented in hardware and / or software, the modules including software defined radio (SDR) and other components such as cameras, video camera modules, videophones, speakerphones, vibrating devices, speakers, microphones, television transceivers, hands-free headsets, keyboards, modules, frequency modulation (FM) radio units, near field communication (NFC) modules, liquid crystal display (LCD) display units, organic light emitting diode (OLED) display units, digital music players, media players, video game player modules, Internet browsers, and / or any wireless local area network (WLAN) or ultra-wideband (UWB) module.

[0177] Although various embodiments have been described in the context of communication systems, it is contemplated that these systems may be implemented in software on a microprocessor / general purpose computer (not shown). In certain embodiments, one or more functions of the various components may be implemented in software that controls the general purpose computer.

[0178] Furthermore, although the invention has been illustrated and described herein with reference to specific embodiments, the invention is not intended to be limited to the details shown. Rather, various modifications may be made in the equivalents scope and realm of the claims and without departing from the invention.

Claims

1. A device for performing authentication in a 5G core network, the device being configured to: Receive an authentication request, the authentication request including a ciphertext of user equipment (UE) credentials with bit padding; Transmit a request to decrypt the ciphertext, the decryption request being transmitted to an authentication and authorization function; Receive the decrypted ciphertext from the authentication and authorization function, the decrypted ciphertext including the plaintext of the UE credentials with bit padding; Transmit the plaintext of the UE credentials with bit padding to a de-hiding function to remove the bit padding of the decrypted text; Receive the plaintext of the de-padded UE credentials; Transmit the de-padded UE credentials to the authentication and authorization function for authentication; And Receive the authentication of the UE credentials.

2. The device according to claim 1, wherein the device is an authentication server function (AUSF) in a 5G core system.

3. The device according to claim 1, wherein the device receives the authentication request from a security anchor function (SEAF).

4. The device according to claim 3, wherein SEAF is within an access and mobility management function (AMF).

5. The device according to claim 1, wherein the device receives an Extensible Authentication Protocol Transport Layer Security (EAP-TTLS) request.

6. The device according to claim 1, wherein in the ciphertext of the UE credentials with bit padding, the encrypted text includes one or more of the following: the identity of the UE including bit padding, parameters, credentials, and tokens.

7. The device according to claim 1, wherein the authentication and authorization function is a network slice specific authentication and authorization function (NSSAAF).

8. The device according to claim 1, wherein the request to decrypt the ciphertext includes a request to decrypt the ciphertext of at least one of the user equipment identity, parameters, credentials, and tokens, and the user equipment identity, parameters, credentials, and tokens are cryptographically protected by a Transport Layer Security (TLS) tunnel to the authentication and authorization function.

9. The device according to claim 1, wherein the device transmits the plaintext of the UE credentials with bit padding to a subscription identifier de-hiding function (SIDF) to remove the bit padding of the decrypted text.

10. The device according to claim 6, wherein SIDF is in a unified data management (UDM) function in the 5G core network.

11. The device according to claim 1, wherein the device receives an Extensible Authentication Protocol Transport Layer Security (EAP-TTLS) authentication of the de-padded UE credentials.

12. A method performed by a network device of a 5G core network, the method including: Receive an authentication request, the authentication request including a ciphertext of user equipment (UE) credentials with bit padding; Transmit a request to decrypt the ciphertext, the decryption request being transmitted to an authentication and authorization function; Receive the decrypted ciphertext from the authentication and authorization function, the decrypted ciphertext including the plaintext of the UE credentials with bit padding; Transmit the plaintext of the UE credentials with bit padding to a de-hiding function to remove the bit padding of the decrypted text; Receive the plaintext of the de-padded UE credentials; Transmit the de-padded UE credentials to the authentication and authorization function for authentication; and Receive authentication of the de-padded UE credentials.

13. The method according to claim 12, wherein the method is performed by an Authentication Server Function (AUSF) in a 5G core system.

14. The method according to claim 12, wherein receiving the authentication request includes receiving the authentication request from a Security Anchor Function (SEAF) within an Access and Mobility Management Function (AMF).

15. The method according to claim 12, wherein receiving the authentication request includes receiving an Extensible Authentication Protocol Transport Layer Security (EAP-TTLS) request.

16. The method according to claim 12, wherein transmitting the request to decrypt the ciphertext includes transmitting the request to decrypt the ciphertext of the UE credentials with bit padding, the ciphertext including the encrypted text of one or more of the following: the identity of the UE including bit padding, parameters, credentials, and tokens.

17. The method according to claim 12, wherein transmitting the request to decrypt the ciphertext includes transmitting the request to a Network Slice Specific Authentication and Authorization Function (NSSAAF), wherein the ciphertext is protected by a Transport Layer Security (TLS) tunnel.

18. The method according to claim 12, wherein transmitting the plaintext of the UE credential with bit-padding to the de-hiding function to remove the bit-padding of the decrypted text comprises: Transmit the plaintext with bit padding to a Subscription Identifier De-hiding Function (SIDF) within a Unified Data Management (UDM) function to remove the bit padding of the decrypted text.

19. The method according to claim 12, wherein receiving the authentication of the de-padded UE credentials includes receiving an Extensible Authentication Protocol Transport Layer Security (EAP-TTLS) authentication of the de-padded UE credentials.

20. A non-transitory computer-readable medium comprising instructions that, when executed by a computer, perform the method according to any one of claims 12-19.

Images