Generic Bootstrapping Architecture (GBA) Signaling to Indicate the Need for Key Renegotiation

Abstract

In an embodiment method for supporting pre-shared key (PSK) renegotiation, a user equipment (UE) may generate a request message including a first bootstrapping transaction identifier (B-TID), a first PSK namespace identifying a first bootstrapping procedure supported by the UE, and a first correlated PSK namespace indicating that PSK renegotiation is supported by the UE for the first bootstrapping procedure, and transmit the request message to a network device. In response to determining that PSK renegotiation is required for the UE, the network device may determine an indication of PSK renegotiation for the first correlated PSK namespace, generate a response message including the indication of PSK renegotiation for the first correlated PSK namespace, and transmit the response message to the UE. In response, the UE may perform a bootstrapping procedure to obtain a second B-TID and a second (i.e., new) session key (Ks).

Description

[Technical field]

[0001] (CROSS REFERENCE TO RELATED APPLICATIONS)

[0001] This application claims the benefit of priority to U.S. patent application Ser. No. 63 / 273,997, filed October 31, 2021, entitled "Generic Bootstrapping Architecture (GBA) Signaling To Indicate Need For Key Renegotiation," the entire contents of which are incorporated herein by reference for all purposes. [Background technology]

[0002]

[0002] Fifth generation (5G) New Radio (NR) and other communication technologies enable ultra-reliable, low-latency communication with user equipment (UE), such as wireless devices. One application of such communication systems is to provide various services to the UE. Some applications and services may employ or require communication security to provide one or more features. Summary of the Invention

[0003]

[0003] Various aspects include a method performed by a processor of a user equipment (UE) for securing communications. Various aspects may include a method performed by a processor of the UE for providing a generic bootstrapping architecture (GBA) to support key renegotiation. Various aspects may include a method performed by a processor of the UE for supporting pre-shared key (PSK) renegotiation. Various aspects may include generating a first request message including a first bootstrapping transaction identifier (B-TID), a first PSK namespace identifying a first bootstrapping procedure supported by the UE, and a first correlated PSK namespace indicating that PSK renegotiation is supported by the UE for the first bootstrapping procedure, and sending the first request message to a network application function (NAF).

[0004] Various aspects may further include receiving a response message from the NAF indicating the first correlated PSK namespace, and performing a bootstrapping procedure to obtain a second B-TID and a session key (Ks) based on receiving the response message. In some aspects, performing the bootstrapping procedure may include re-performing the first bootstrapping procedure to obtain the second B-TID and the second session key (Ks). Some aspects may further include generating a second request message including the second B-TID and the first correlated PSK namespace, and sending the second request message to the NAF. In some aspects, the indication of the first correlated PSK namespace may be the first correlated PSK namespace. In some aspects, the indication of the first correlated PSK namespace may be an index of the first correlated PSK namespace, or a position of the first correlated PSK namespace in a list.

[0005]

[0005] Various aspects may further include communicating with the NAF using the second Ks.

[0006]

[0006] In some aspects, the first request message may further include a second PSK namespace identifying a second bootstrapping procedure supported by the UE and a second correlated PSK namespace indicating that PSK renegotiation is supported by the UE for the second bootstrapping procedure.

[0007] In some aspects, the first request message may be a client-initiated hello message.

[0008]

[0008] Further aspects include a UE having a processor configured to perform one or more operations of any of the methods summarized above. Further aspects include a processing device for use in a UE configured with processor-executable instructions for performing any of the operations of any of the methods summarized above. Further aspects include a non-transitory processor-readable storage medium storing processor-executable instructions configured to cause a processor of the UE to perform any of the operations of the methods summarized above. Further aspects include a UE having means for performing the functions of any of the methods summarized above. Further aspects include a system-on-chip for use in a UE including a processor configured to perform one or more operations of any of the methods summarized above.

[0009]

[0009] Various aspects include a method performed by a processor of a network device to secure communications. Various aspects may include a method performed by a processor of the network device for providing a GBA to support key renegotiation. Various aspects may include a method performed by a processor of the network device to support pre-shared key (PSK) renegotiation. In some aspects, the network device may be a Network Application Function (NAF) server. Various aspects may include receiving, by a network device from a user equipment (UE), a first request message including a first bootstrapping transaction identifier (B-TID), a first PSK namespace identifying a first bootstrapping procedure supported by the UE, and a first correlated PSK namespace indicating that PSK renegotiation is supported by the UE for the first bootstrapping procedure, determining that PSK renegotiation is required for the UE after receiving the first request message, determining an indication of PSK renegotiation for the first correlated PSK namespace in response to determining that PSK renegotiation is required for the UE, generating a response message including the indication of PSK renegotiation for the first correlated PSK namespace, and transmitting the response message to the UE. In some aspects, the indication of the first correlated PSK namespace may be an indication of the first correlated PSK namespace. In some aspects, the indication of the first correlated PSK namespace may be an index of the first correlated PSK namespace or a position of the first correlated PSK namespace in a list.

[0010]

[0010] Various aspects may further include receiving, by the network device, a second request message from the UE including the second B-TID and the first correlated PSK namespace.

[0011]

[0011] Various aspects may further include communicating with the UE using a session key (Ks) obtained from a bootstrapping security function (BSF) using the second B-TID.

[0012]

[0012] In some aspects, the first request message may further include a second PSK namespace identifying a second bootstrapping procedure supported by the UE, and a second correlated PSK namespace indicating that PSK renegotiation is supported by the UE for the second bootstrapping procedure. In some aspects, determining that PSK renegotiation is required for the UE after receiving the first request message may include selecting a first bootstrapping procedure supported by the UE from a selection of a first bootstrapping procedure supported by the UE and a second bootstrapping procedure supported by the UE, determining that PSK renegotiation is required for the first bootstrapping procedure, and determining an indication of the first correlated PSK namespace in response to selecting the first bootstrapping procedure supported by the UE. In some aspects, the indication of the first correlated PSK namespace may be the first correlated PSK namespace. In some aspects, the indication of the first correlated PSK namespace may be an index of the first correlated PSK namespace or a position of the first correlated PSK namespace in a list.

[0013] In some aspects, the response message may be a server initiated hello message.

[0014]

[0014] Further aspects include a network device having a processor configured to perform one or more operations of any of the methods summarized above. Further aspects include a processing device for use in a network device configured with processor-executable instructions for performing any of the operations of any of the methods summarized above. Further aspects include a non-transitory processor-readable storage medium having stored thereon processor-executable instructions configured to cause a processor of the network device to perform any of the operations of the methods summarized above. Further aspects include a network device having means for performing the functions of any of the methods summarized above. Further aspects include a system-on-chip for use in a network device including a processor configured to perform one or more operations of any of the methods summarized above. [Brief description of the drawings]

[0015]

[0015] The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate exemplary embodiments and, together with the general description provided above and the detailed description provided below, serve to explain features of the various embodiments. [Figure 1A]

[0016] FIG. 1 is a system block diagram illustrating an exemplary communication system suitable for implementing any of the various embodiments. [Figure 1B]

[0017] FIG. 1 is a system block diagram illustrating an example split base station architecture for a wireless communication system suitable for implementing any of the various embodiments. [Diagram 2]

[0018] FIG. 1 is a component block diagram illustrating an exemplary computing and wireless modem system suitable for implementing any of the various embodiments. [Diagram 3]

[0019] FIG. 2 is a component block diagram illustrating a software architecture including radio protocol stacks for user and control planes in wireless communications suitable for implementing any of the various embodiments. [Figure 4]

[0020] FIG. 1 is a system block diagram illustrating an example system for bootstrap application security suitable for use with various embodiments. [Diagram 5]

[0021] 1 is a process flow diagram illustrating a method performed by a processor of a UE for supporting PSK renegotiation in accordance with various embodiments. [Figure 6]

[0022] FIG. 1 is a process flow diagram illustrating a method performed by a processor of a network device to support PSK renegotiation, according to various embodiments. [Figure 7]

[0023] FIG. 1 is a component block diagram of a network device suitable for use in various embodiments. [Figure 8]

[0024] FIG. 2 is a component block diagram of a UE suitable for use in the various embodiments. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0016]

[0025] Various embodiments are described in detail with reference to the accompanying drawings. Wherever possible, the same reference numbers are used throughout the drawings to refer to the same or like parts. References made to specific examples and implementations are for illustrative purposes only and do not limit the scope of the claims.

[0017]

[0026] Various embodiments enable pre-shared key (PSK) renegotiation in a Generic Bootstrapping Architecture (GBA). In various embodiments, a user equipment (UE) and a network device, such as a network application function (NAF) server, can communicate information that enables the NAF to indicate when PSK renegotiation is required for the bootstrapping procedure, such as one or more GBA methods, e.g., Mobile Equipment (ME)-based GBA (GBA_ME), GBA with Universal Integrated Circuit Card (UICC)-based extensions (GBA_U), Second Generation (2G) GBA, GBA_Digest (method using Session Information Protocol (SIP) digest credentials for GBA), etc.

[0018]

[0027] The UE may include a PSK identity correlated with the PSK namespace in a request message sent to a network device, such as a NAF server, which, if selected by the NAF, indicates that a bootstrapping procedure should be re-performed by the UE to update the session key before completing the GBA procedure with the NAF. Including a PSK namespace in the request message indicating that a PSK renegotiation should be performed by the UE for the bootstrapping procedure may enable a network device, such as a NAF server, to select a bootstrapping procedure to use with the UE to establish a secure communication link. Additionally, including a PSK namespace in the request message indicating that a PSK renegotiation should be performed by the UE for the bootstrapping procedure may indicate that a PSK renegotiation needs to be performed by simply returning an indication of the PSK namespace, such as a copy of the PSK namespace itself, an index of the PSK namespace, or the position of the PSK namespace in a list of PSK namespaces.

[0019]

[0028] In various embodiments, a network device, such as a NAF server, may indicate to a user equipment (UE) that a new bootstrapping is required by sending a response message including an indication of PSK renegotiation correlated with a PSK namespace associated with a selected bootstrapping procedure, such as a GBA method (e.g., GBA_ME, GBA_U, 2G GBA, GBA_Digest, etc.). The indication of PSK renegotiation correlated with a PSK namespace associated with a selected bootstrapping procedure may be an indication of a PSK namespace associated with the selected bootstrapping procedure itself. The indication of PSK renegotiation correlated with a PSK namespace associated with a selected bootstrapping procedure may be an index of a PSK namespace associated with the selected bootstrapping procedure. The indication of PSK renegotiation correlated with a PSK namespace associated with a selected bootstrapping procedure may be a position of the PSK namespace associated with the selected bootstrapping procedure in a list, such as a list of PSK namespaces.

[0020]

[0029] By including an indication of PSK renegotiation correlated with a PSK namespace associated with a bootstrapping procedure in the response message, the UE may be prompted to perform a bootstrapping negotiation to obtain a new bootstrapping transaction identifier (B-TID) and a new session key (Ks) for the selected bootstrapping procedure indicated by the indication, and then perform the bootstrapping procedure with a network device, such as a NAF server, using the new B-TID and the new Ks to establish secure communication. A network device, such as a NAF server, indicating to a UE the need for key renegotiation using a particular GBA method may enable the network device to ensure that the Ks used by the UE are fresh. A network device, such as a NAF server, indicating to a UE the need for key renegotiation using a particular GBA method may enable the network device to verify that a valid credential, such as a valid smart card, is available to the UE.

[0021]

[0030] The terms “user equipment” and “UE” are used herein to refer to wireless devices, wireless router devices, wireless appliances, cellular telephones, smartphones, portable computing devices, personal or mobile multimedia players, laptop computers, tablet computers, smartbooks, ultrabooks, palmtop computers, wireless email receivers, multimedia Internet enabled cellular telephones, medical devices and equipment, biometric sensors / devices, augmented reality (XR) headsets (e.g., virtual reality (VR), mixed reality (MR), or augmented reality (AR) headsets), smart watches, smart clothing, smart glasses, smart wristbands, smart jewelry (e.g., The term "wireless" is used to refer to any one or all of endpoint or user devices, including wearable devices including wearable devices (e.g., smart rings and smart bracelets), entertainment devices (e.g., wireless game controllers, music and video players, satellite radios, etc.), wireless network-enabled Internet of Things (IoT) devices including smart meters / sensors, industrial manufacturing equipment, large and small machinery and appliances for home or business use, wireless communication elements in autonomous and semi-autonomous vehicles, wireless devices fixed or embedded in various mobile platforms, global positioning system devices, and similar electronic devices that contain memory, wireless communication components, and programmable processors.

[0022]

[0031] The term "system on chip" (SOC) is used herein to refer to a single integrated circuit (IC) chip that includes multiple resources or processors integrated on a single substrate. A single SOC may include circuits for digital, analog, mixed signal, and radio frequency functions. A single SOC may also include any number of general purpose or special purpose processors (digital signal processors, modem processors, video processors, etc.), memory blocks (ROM, RAM, flash, etc.), and resources (timers, voltage regulators, oscillators, etc.). A SOC may also include software for controlling the integrated resources and processors, as well as for controlling peripheral devices.

[0023]

[0032] The term "system in package" (SIP) may be used herein to refer to a single module or package that includes multiple resources, computing units, cores, or processors on two or more IC chips, substrates, or SOCs. For example, a SIP may include a single substrate on which multiple IC chips or semiconductor dies are stacked in a vertical configuration. Similarly, a SIP may include one or more multi-chip modules (MCMs) on which multiple ICs or semiconductor dies are packaged in a singulated substrate. A SIP may also include multiple independent SOCs packaged in close proximity, coupled to each other via high-speed communication circuits, such as on a single motherboard or within a single wireless device. The proximity of the SOCs facilitates high-speed communication and sharing of memory and resources.

[0024]

[0033] As used herein, the terms "network," "system," "wireless network," "cellular network," and "wireless communications network" may interchangeably refer to some or all of a wireless network of a carrier associated with a wireless device and / or a subscription on a wireless device. The techniques described herein may be used for various wireless communications networks, such as Code Division Multiple Access (CDMA), Time Division Multiple Access (TDMA), FDMA, Orthogonal FDMA (OFDMA), Single Carrier FDMA (SC-FDMA), and other networks. In general, any number of wireless networks may be deployed in a given geographic area. Each wireless network may support at least one radio access technology that may operate on one or more frequencies or ranges of frequencies. For example, a CDMA network may implement Universal Terrestrial Radio Access (UTRA) (including the Wideband Code Division Multiple Access (WCDMA) standard), CDMA2000 (including the IS-2000, IS-95, and / or IS-856 standards), and the like. In another example, a TDMA network may implement GSM Enhanced Data Rates for GSM Evolution (EDGE). In another example, the OFDMA network may implement Evolved UTRA (E-UTRA) (including the LTE standard), Institute of Electrical and Electronics Engineers (IEEE) 802.11 (Wi-Fi), IEEE 802.16 (WiMAX), IEEE 802.20, Flash-OFDM, etc. Wireless networks using the LTE standard may be referenced, and thus the terms "Universal Terrestrial Radio Access," "E-UTRAN," and "eNodeB" may also be used interchangeably herein to refer to wireless networks. However, such references are provided by way of example only and do not exclude wireless networks using other communication standards. For example, although various third generation (3G), fourth generation (4G), and fifth generation (5G) systems are described herein, such systems are referenced by way of example only and future generation systems (e.g., sixth generation (6G) or higher systems) may be used instead in various examples.

[0025]

[0034] Some applications and services may use or require communication security to provide one or more features. For example, the Generic Bootstrapping Architecture (GBA) may provide a mechanism that uses a protocol such as the 3rd Generation Partnership Project (3GPP) Authentication and Key Agreement (AKA) to establish a shared secret between the UE and the network device. In some approaches, the UE and the network device share a single shared secret for all communications by all services and applications.

[0026]

[0035] Various embodiments include methods and computing devices configured to perform the methods for securing communications between a UE and a network device by providing a GBA to support key renegotiation. Various embodiments include methods and computing devices configured to secure communications between a UE and a network device that supports PSK renegotiation.

[0027]

[0036] The GBA bootstrapping procedure allows for deriving keys for the UE using mobile subscription security material to provide security at the application level. For example, in the GBA architecture, a bootstrapping server function (BSF) may communicate with the UE over a Ub interface and with the NAF over a Zn interface. As used herein, "Ub" refers to the UE-BSF interface for bootstrapping. As used herein, "Zn" refers to the BSF-NAF interface for Generic Authentication Architecture (GAA) applications. The BSF may be a network entity in an operator's network that authenticates the UE and provides keys to the NAF. The NAF may be an application with which the UE establishes or attempts to establish secure communications, such as secure communications according to the Transport Layer Security (TLS) protocol version 1.3 (TLS 1.3) defined in Internet Engineering Task Force (IETF) Request for Comments (RFC) 8446. The BSF may authenticate the UE utilizing a Home Subscriber Server (HSS), which may hold subscriber data enabling UE authentication. In an example bootstrapping procedure, the UE may perform a Digest AKA protocol with the BSF. The bootstrapping procedure may result in the UE and the BSF having a common bootstrapping transaction identifier (B-TID) and key (Ks). The B-TID may identify Ks.

[0028]

[0037] After the UE performs a bootstrapping procedure with the BSF, the UE may send the B-TID to the NAF in a request message, such as a client-initiated hello message (e.g., ClientHello message as used herein). The NAF may request a key from the BSF using the B-TID received from the UE. The BSF may generate a NAF-specific key (e.g., Ks_NAF as used herein) from the Ks generated during the bootstrapping procedure with the UE and send the NAF-specific key to the NAF. The derivation of Ks_NAF may use a NAF Identifier (ID), which may consist of a Fully Qualified Domain Name (FQDN) of the NAF and a Ua Security Protocol Identifier. The Ua Security Protocol Identifier may ensure that different keys are generated for different protocols and that each key is used exactly once. As used herein, "Ua" refers to the UE-NAF interface for GAA applications. The FQDN may ensure that the key is unique to the NAF.

[0029]

[0038] Some NAFs may be configured to support bootstrapping renegotiation, for example to perform PSK renegotiation. The UE may send the initial (or current) B-TID to the NAF after already performing the bootstrapping procedure with the BSF. The NAF may forward the B-TID to the BSF to obtain Ks for secure communication with the UE. However, in some circumstances, the NAF may determine that the key received from the BSF is not suitable for use in secure communication. For example, the NAF may determine that the B-TID is out of date, the NAF may be configured to always request a renegotiation first, or the NAF may determine that a bootstrapping renegotiation is necessary for any other reason. In conventional systems, especially those employing TLS 1.3 using GBA keys, there is no way for the NAF to indicate to the UE the need for a new key and thus the need for the UE to obtain an updated key from the BSF.

[0030]

[0039] Various embodiments provide a mechanism by which the NAF can efficiently inform the UE that PSK renegotiation is required before the UE can establish a secure communication link with the NAF using a GBA procedure. In various embodiments, the UE can indicate to a network device, such as the NAF, that PSK renegotiation is supported by the UE for one or more bootstrapping procedures, such as one or more GBA methods (e.g., GBA_ME, GBA_U, 2G GBA, GBA_Digest, etc.) and / or one or more other bootstrapping procedures, by including in the listed bootstrapping procedures an additional procedure that correlates to the supported procedure that requires key refresh. In other words, for at least one (or each) of the supported bootstrapping procedures, a corresponding bootstrapping renegotiation procedure can be included in the list of (supported) bootstrapping procedures.

[0031]

[0040] In various embodiments, the NAF may reference a list of bootstrapping procedures to inform the UE of both the selected bootstrapping procedure and the need for the UE to refresh keys before performing operations to establish a secure communication link with the NAF. For example, the NAF may select a bootstrapping procedure by name to indicate the selected bootstrapping method, or the NAF may select an index value of the bootstrapping procedure, or the NAF may select a position of the bootstrapping procedure in the list. This allows a network device, such as a NAF server, to indicate to the UE that it wishes to use a selected bootstrapping method and that the UE needs to refresh keys for that method by simply providing a corresponding indication (e.g., a namespace of the procedure indicating the need for a new key correlated to the selected bootstrapping method, an index number of the procedure indicating the need for a new key correlated to the selected bootstrapping method, or a position in the list of procedures indicating the need for a new key correlated to the selected bootstrapping method).

[0032]

[0041] In various embodiments, the UE may send a request message to a network device, such as a NAF server, that includes PSK namespaces indicating supported bootstrapping procedures along with associated B-TIDs and (correlated) PSK namespaces indicating PSK renegotiation for each supported bootstrapping procedure. The inclusion of the (additional or correlated) PSK namespaces and B-TIDs may enable a network device, such as a NAF server, to select a bootstrapping procedure for PSK renegotiation to use with the UE, and may indicate that the UE needs to renegotiate keys so that fresh keys are used for the selected bootstrapping procedure.

[0033]

[0042] In various embodiments, a network device, such as a NAF server, may indicate to the UE that a new bootstrapping is required by sending a response message that includes an indication of PSK renegotiation that is correlated to (or corresponds to) a PSK namespace associated with a selected bootstrapping procedure, such as a GBA method (e.g., GBA_ME, GBA_U, 2G GBA, GBA_Digest, etc.). For example, the indication may be the PSK namespace itself, an index of the PSK namespace, or the position of the PSK namespace in a list. Indicating a PSK renegotiation that is correlated to a PSK namespace associated with a selected bootstrapping procedure may enable the UE to perform the indicated bootstrapping procedure and obtain a new B-TID and a new session key (Ks) for establishing secure communications with the network device.

[0034]

[0043] In various embodiments, the UE may indicate a (correlated) PSK identity for each supported GBA method to indicate a renegotiation for that GBA method. For example, when the PSK identity (or correlated PSK namespace) "3GPP-bootstrapping" is indicated by the UE as supported, an indication "3GPP-bootstrapping-renegotiation" may be included as the correlated PSK identity indicating that a new session key (Ks) is required for bootstrapping using the "3GPP-bootstrapping" method. Similar correlated PSK identities (or namespaces) may be included for other GBA methods.

[0035]

[0044] In embodiments where multiple GBA methods are indicated as supported by the UE for bootstrapping renegotiation, a GBA method or methods different from the one originally used for the previous bootstrapping procedure (e.g., initial bootstrapping procedure, most recent bootstrapping procedure, etc.) may be available for bootstrapping renegotiation. The UE may indicate such one or more GBA methods different from the one originally used for the previous bootstrapping procedure by providing, in the request message sent to the NAF, an indication of such additional (or correlated) PSK identity (or correlated PSK namespace) for the one or more GBA methods different from the one originally used for the previous bootstrapping procedure in addition to an indication of the PSK identity (or PSK namespace) for the previous bootstrapping procedure originally used.

[0036]

[0045] In various embodiments, the NAF may select an indication of an additional (or correlated) PSK identity (e.g., the additional PSK identity itself, an index of the additional PSK identity, the position of the additional PSK identity in the list, etc.), such as a correlated PSK identity (e.g., "3GPP-bootstrapping-renegotiation"), to indicate that a new bootstrapping is required to be performed in order to use this particular selected GBA keying method (e.g., to use "3GPP-bootstrapping"). Because the selected GBA method of keying may be different from the one originally used for a previous bootstrapping procedure (e.g., initial bootstrapping procedure, most recent bootstrapping procedure, etc.), a new bootstrapping performed by the UE with the BSF may be required to obtain a fresh session key for use in the selected GBA method. A network device such as the NAF may send a response message to the UE such as a server-initiated Hello message (referred to herein as a ServerHello message) that includes an indication of additional PSK identities (e.g., namespace, index, location, etc.), such as a correlated PSK identity (e.g., "3GPP-bootstrapping-renegotiation"), for the purpose of indicating that a new bootstrapping is required to be performed by the UE with the BSF to obtain a fresh session key to be used in a selected GBA method of establishing secure communication with the UE (e.g., to use "3GPP-bootstrapping"). In this way, the network device may send to the UE a key identifier that indicates the need for regeneration of a key for use with a selected bootstrapping procedure, such as a particular GBA method, rather than indicating the (fresh) key itself.

[0037]

[0046] In various embodiments, in response to receiving a response message such as a ServerHello message that includes an indication of additional PSK identities (e.g., namespace, index, location, etc.) such as a correlated PSK identity (e.g., "3GPP-bootstrapping-renegotiation") to indicate that a new bootstrapping run is required to use this particular GBA keying method (e.g., to use "3GPP-bootstrapping"), the UE can renegotiate one or more keys with the BSF to obtain a new B-TID and a new session key (Ks) for use in the identified GBA procedure with the network device, such as a NAF server. In various embodiments, the UE can resend the PSK identity and new B-TID associated with the GBA method to the network device, such as a NAF server, in a request message requesting establishment of a secure communications session.

[0038]

[0047] In various embodiments, when the UE contacts the NAF by sending a request message for a secure communication session, such as a ClientHello message, the UE may indicate to the NAF that the UE supports TLS with PSK authentication. The UE may indicate in the ClientHello message that it supports an authentication method other than PSK. The UE may send the hostname of the NAF using a server name indication (such as a server_name extension to the ClientHello message via a TLS extension). The UE may use a GBA-based shared secret for TLS with PSK authentication by providing the B-TID to the NAF in the ClientHello message. If the UE does not have a valid GBA-based shared secret, the UE first obtains the GBA-based shared secret by performing a bootstrapping procedure with the BSF over the Ub reference point.

[0039]

[0048] The PSK identity in the ClientHello may include a prefix indicating a PSK identity namespace (such as "3GPP-bootstrapping-uicc", "3GPP-bootstrapping", and / or "3GPP-bootstrapping-digest") and an associated B-TID associated with that bootstrapping method. In various embodiments, for each of these included identifiers (e.g., PSK identity namespaces such as "3GPP-bootstrapping-uicc", "3GPP-bootstrapping", and / or "3GPP-bootstrapping-digest"), additional PSK identity namespaces may be included to enable requests for fresh session keys. For example, if the PSK identity namespace "3GPP-bootstrapping-uicc" is included, the correlated PSK identity namespace "3GPP-bootstrapping-uicc-renegotiation" may be included, if the PSK identity namespace "3GPP-bootstrapping-digest" is included, the PSK identity namespace "3GPP-bootstrapping-digest-renegotiation" may be included, and / or if the PSK identity namespace "3GPP-bootstrapping" is included, the PSK identity namespace "3GPP-bootstrapping-renegotiation" may be included. Similarly, the PSK identity namespace of the actual key to be correlated and renegotiation support indicating the PSK identity namespace pair may be included for other authentication methods. The prefix (or namespace) "3GPP-bootstrapping" may be used in the PSK identity to indicate that the UE accepts that the AKA-based Ks_(ext)_NAF is used to establish the TLS session key. The prefix (or namespace) "3GPP-bootstrapping-uicc" may be used in the PSK identity to indicate that the UE accepts that Ks_int_NAF may be used to establish a TLS session key.The prefix (or namespace) "3GPP-bootstrapping-digest" may be used in the PSK identity to indicate that the UE accepts that the GBA_Digest based Ks_NAF may be used to establish the TLS session key. Similarly, a correlation prefix (or namespace) with "renegotiation" appended or some other appended indication may be used in the PSK identity to indicate that renegotiation is supported for the correlation GBA method. The ClientHello message may include prefixes for the authentication methods that the UE supports.

[0040]

[0049] In various embodiments, a network device such as a NAF may determine whether to have the UE perform a new bootstrapping procedure for a particular method. In response to the network device determining that the UE should perform a new bootstrapping to obtain a fresh session key for a particular GBA method, the network device may return an indication of renegotiation (e.g., namespace, index, location, etc.) of the selected PSK identity (or bootstrapping procedure) in a ServerHello message responding to the UE. In response to receiving an indication of renegotiation (e.g., namespace, index, location, etc.) of the selected PSK identity (or bootstrapping procedure), the UE may treat the ServerHello message as a request to retry the bootstrapping operation (e.g., as a HelloRetryRequest) and perform a new bootstrapping operation with the BSF to obtain a fresh session key (Ks) and a fresh B-TID for the indicated bootstrapping method. Once bootstrapping is complete, the UE may send a new ClientHello message to the NAF that includes only the PSK identity namespace and new B-TID of the selected bootstrapping method. If the NAF attempts to establish a TLS tunnel using PSK authentication (either in response to the original ClientHello or a ClientHello sent after fresh bootstrapping), the NAF may select one of the PSK identities and indicate the selected PSK identity in the ServerHello message, for example, by indicating the namespace, index, or position in a list of the selected PSK identity. After the UE sends a Finished message and the NAF receives a Finished message from the UE, the UE and the NAF may use application-level communication over the TLS tunnel using the fresh session key.

[0041]

[0050] Various embodiments enable the UE and the network device to agree on a unique key for each application or service for the UE without exchanging secret or secure information, such as a private key. As a result, various embodiments improve the operation of the UE, the network device, and the communications system by improving the security of communications between the UE and the network device.

[0042]

[0051] FIG 1A is a system block diagram illustrating an exemplary communication system 100. The communication system 100 may be a 5G New Radio (NR) network, or any other suitable network, such as a Long Term Evolution (LTE) network. Although FIG 1A illustrates a 5G network, later generation networks may include the same or similar elements. Thus, references to a 5G network or 5G network elements in the following description are for illustrative purposes and are not intended to be limiting.

[0043]

[0052] The communication system 100 may include a heterogeneous network architecture including a core network 140 and various UEs (shown as UEs 120a-120e in FIG. 1A). The communication system 100 may also include various network devices 142a, such as various network servers including a NAF server, a BSF, an HSS, a subscriber locator function (SLF) server, and the like. The communication system 100 may also include several base stations (shown as BS 110a, BS 110b, BS 110c, and BS 110d) and other network entities. A base station is an entity that communicates with UEs and may also be referred to as a Node B (NodeB), an LTE evolved Node B (eNodeB or eNB), an access point (AP), a radio head, a transmit / receive point (TRP), a new radio base station (NR BS), a 5G Node B (NB), a next generation Node B (gNodeB or gNB), and the like. Each base station may provide communication coverage for a particular geographic area. In 3GPP, the term "cell" can refer to a coverage area of ​​a base station, a base station subsystem serving this coverage area, or a combination thereof, depending on the context in which the term is used. The core network 140 can be any type of core network, such as an LTE core network (e.g., an evolved packet core (EPC) network), a 5G core network, etc.

[0044]

[0053] The base stations 110a-110d may provide communication coverage for a macro cell, a pico cell, a femto cell, another type of cell, or a combination thereof. A macro cell may cover a relatively large geographic area (e.g., a few kilometers in radius) and may allow unrestricted access by UEs with a service subscription. A pico cell may cover a relatively small geographic area and may allow unrestricted access by UEs with a service subscription. A femto cell may cover a relatively small geographic area (e.g., a home) and may allow restricted access by UEs that have an association with the femto cell (e.g., UEs in a Closed Subscriber Group (CSG)). A base station for a macro cell may be referred to as a macro BS. A base station for a pico cell may be referred to as a pico BS. A base station for a femto cell may be referred to as a femto BS or a home BS. In the example shown in Figure 1, base station 110a may be a macro BS for macro cell 102a, base station 110b may be a pico BS for pico cell 102b, and base station 110c may be a femto BS for femto cell 102c. Base stations 110a-110d may support one or more (e.g., three) cells. The terms "eNB", "base station", "NR BS", "gNB", "TRP", "AP", "node B", "5G NB", and "cell" may be used interchangeably herein.

[0045]

[0054] In some examples, the cells may not be stationary and the geographic areas of the cells may move according to the location of the mobile base station. In some examples, the base stations 110a-110d may be interconnected to each other and to one or more other base stations or network nodes (not shown) in the communication system 100 through various types of backhaul interfaces, such as direct physical connections, virtual networks, or combinations thereof, using any suitable transport network.

[0046]

[0055] The base stations 110a-110d may communicate with the core network 140 over wired or wireless communication links 126. The UEs 120a-120e may communicate with the base stations 110a-110d over wireless communication links 122.

[0047]

[0056] Wired communications link 126 may use a variety of wired networks (such as Ethernet, TV cable, telephone, fiber optics, and other forms of physical network connections) that may use one or more wired communications protocols, such as Ethernet, Point-to-Point Protocol, High Level Data Link Control (HDLC), Advanced Data Communications Control Protocol (ADCCP), and Transmission Control Protocol / Internet Protocol (TCP / IP).

[0048]

[0057] The communication system 100 may also include a relay station (such as relay BS 110d). A relay station is an entity that can receive a transmission of data from an upstream station (e.g., a base station or a UE) and send a transmission of data to a downstream station (e.g., a UE or a base station). A relay station may also be a wireless device (e.g., a UE) that can relay a transmission for another UE. In the example shown in FIG. 1, relay station 110d may communicate with base station 110a and UE 120d to facilitate communication between base station 110a and UE 120d. A relay station may also be referred to as a relay base station, a relay base station, a repeater, etc.

[0049]

[0058] The communications system 100 may be a heterogeneous network including different types of base stations, e.g., macro base stations, pico base stations, femto base stations, relay base stations, etc. These different types of base stations may have different transmit power levels, different coverage areas, and may have different impacts on interference in the communications system 100. For example, macro base stations may have high transmit power levels (e.g., 5-40 watts), whereas pico base stations, femto base stations, and relay base stations may have lower transmit power levels (e.g., 0.1-2 watts).

[0050]

[0059] A network controller 130 may couple to a set of base stations and provide coordination and control for these base stations. The network controller 130 may communicate with the base stations via a backhaul. The base stations may also communicate with each other directly or indirectly, e.g., via wireless or wireline backhaul.

[0051]

[0060] The UEs 120a, 120b, 120c may be dispersed throughout the communications system 100, and each UE may be fixed or mobile. A UE may also be called an access terminal, a terminal, a mobile station, a subscriber unit, a station, a wireless device, etc.

[0052]

[0061] The macro base station 110a may communicate with the core network 140 over wired or wireless communication links 126. The UEs 120a, 120b, 120c may communicate with the base stations 110a-110d over wireless communication links 122.

[0053]

[0062] The wireless communication links 122 and 124 may include multiple carrier signals, frequencies, or frequency bands, each of which may include multiple logical channels. The wireless communication links 122 and 124 may use one or more radio access technologies (RATs). Examples of RATs that may be used in the wireless communication links include 3GPP LTE, 3G, 4G, 5G (such as NR), GSM, Code Division Multiple Access (CDMA), Wideband Code Division Multiple Access (WCDMA), Worldwide Interoperability for Microwave Access (WiMAX), Time Division Multiple Access (TDMA), and other mobile telephony communication technology cellular RATs. Further examples of RATs that may be used in one or more of the various wireless communication links in the communication system 100 include medium-range protocols such as Wi-Fi, LTE-U, LTE-Direct, LAA, MuLTEfire, and relatively short-range RATs such as ZigBee, Bluetooth, and Bluetooth Low Energy (LE).

[0054]

[0063] Some wireless networks (e.g., LTE) use orthogonal frequency division multiplexing (OFDM) on the downlink and single-carrier frequency division multiplexing (SC-FDM) on the uplink. OFDM and SC-FDM partition the system bandwidth into multiple (K) orthogonal subcarriers, also commonly referred to as tones, bins, etc. Each subcarrier may be modulated with data. Generally, modulation symbols are sent in the frequency domain with OFDM and in the time domain with SC-FDM. The spacing between adjacent subcarriers may be fixed, or the total number of subcarriers (K) may be dependent on the system bandwidth. For example, the subcarrier spacing may be 15 kHz and the minimum resource allocation (called a "resource block") may be 12 subcarriers (or 180 kHz). Thus, the nominal fast file transfer (FFT) size may be equal to 128, 256, 512, 1024, or 2048 for a system bandwidth of 1.25, 2.5, 5, 10, or 20 megahertz (MHz), respectively. The system bandwidth may also be partitioned into subbands. For example, a subband may cover 1.08 MHz (i.e., 6 resource blocks), and there may be 1, 2, 4, 8, or 16 subbands for a system bandwidth of 1.25, 2.5, 5, 10, or 20 MHz, respectively.

[0055]

[0064] Although the description of some implementations may use terminology and examples related to LTE technology, some implementations may be applicable to other wireless communication systems, such as New Radio (NR) or 5G networks. NR may utilize OFDM with cyclic prefix (CP) on the uplink (UL) and downlink (DL) and may include support for half-duplex operation using time division duplex (TDD). A single component carrier bandwidth of 100 MHz may be supported. An NR resource block may span 12 subcarriers with a subcarrier bandwidth of 75 kHz for a duration of 0.1 milliseconds (ms). Each radio frame may consist of 50 subframes with a length of 10 ms. Thus, each subframe may be 0.2 ms in length. Each subframe may indicate a link direction (i.e., DL or UL) for data transmission, and the link direction per subframe may be dynamically switched. Each subframe may include DL / UL data as well as DL / UL control data. Beamforming may be supported, and the beam direction may be dynamically configured. Multiple-input multiple-output (MIMO) transmission with precoding may also be supported. MIMO configurations in the DL may support up to eight transmit antennas with multi-layer DL transmission of up to eight streams and up to two streams per UE. Multi-layer transmission with up to two streams per UE may be supported.

[0056]

[0065] Aggregation of multiple cells may be supported with up to eight serving cells. Alternatively, NR may support an air interface other than an OFDM-based air interface.

[0057]

[0066] Some UEs may be considered machine-type communication (MTC) UEs or evolved or enhanced machine-type communication (eMTC) UEs. MTC UEs and eMTC UEs include, for example, a robot, a drone, a remote device, a sensor, a meter, a monitor, a location tag, etc., that may communicate with a base station, another device (e.g., a remote device), or some other entity. A wireless computing platform may provide, for example, connectivity for or to a network (e.g., a wide area network such as the Internet or a cellular network) via a wired or wireless communication link. Some UEs may be considered Internet of Things (IoT) devices or may be implemented as NB-IoT (narrowband Internet of Things) devices. UEs 120a-120e may be included within a housing that houses components of UEs 120a-120e, such as a processor component, a memory component, similar components, or a combination thereof.

[0058]

[0067] In general, any number of communication systems and any number of wireless networks may be deployed in a given geographic area. Each communication system and wireless network may support a particular radio access technology (RAT) and may operate on one or more frequencies. The RAT may also be referred to as a radio technology, an air interface, etc. The frequencies may also be referred to as a carrier, a frequency channel, etc. Each frequency may support a single RAT in a given geographic area to avoid interference between communication systems of different RATs. In some cases, 4G / LTE and / or 5G / NR RAT networks may be deployed. For example, a 5G non-standalone (NSA) network may utilize both a 4G / LTE RAT on the 4G / LTE RAN side of a 5G NSA network and a 5G / NR RAT on the 5G / NR RAN side of a 5G NSA network. Both the 4G / LTE RAN and the 5G / NR RAN may connect to each other and to a 4G / LTE core network (e.g., an evolved packet core (EPC) network) within the 5G NSA network. Other example network configurations may include a 5G Standalone (SA) network in which a 5G / NR RAN connects to a 5G core network.

[0059]

[0068] In some implementations, two or more UEs (e.g., shown as UE 120a and UE 120e) may communicate directly (e.g., without using base station 110a-110d as an intermediary to communicate with each other) using one or more sidelink channels. For example, UEs 120a-120e may communicate using peer-to-peer (P2P) communication, device-to-device (D2D) communication, vehicle-to-everything (V2X) protocols (which may include vehicle-to-vehicle (V2V) protocols, vehicle-to-infrastructure (V2I) protocols, or similar protocols), mesh networks, or similar networks, or combinations thereof. In this case, UEs 120a-120e may perform scheduling operations, resource selection operations, and other operations described elsewhere herein as being performed by base stations 110a-110d.

[0060]

[0069] FIG. 1B is a system block diagram illustrating an example separated base station 160 architecture that may be part of a communication system (e.g., communication system 100), such as a 5G (or later generation) network, suitable for implementing any of the various embodiments. With reference to FIG. 1A and FIG. 1B, the separated base station 160 architecture may include one or more central units (CUs) 162 that may directly communicate with a core network 180 via a backhaul link or indirectly communicate with the core network 180 through one or more separated base station units (e.g., a near real-time (near RT) RAN intelligent controller (RIC) 164 via an E2 link, or a non-real-time (non-RT) RIC 168 associated with a service management and orchestration (SMO) framework 166, or both). The CUs 162 may communicate with one or more distributed units (DUs) 170 via respective midhaul links, such as an F1 interface. The DUs 170 may communicate with one or more radio units (RUs) 172 via respective fronthaul links. The RUs 172 may communicate with each UE 120 via one or more radio frequency (RF) access links. In some implementations, a UE may be served by multiple RUs 172 simultaneously.

[0061]

[0070] Each of the units (i.e., CU 162, DU 170, RU 172), as well as near-RT RIC 164, non-RT RIC 168, and SMO framework 166, may include or be coupled to one or more interfaces configured to receive or transmit signals, data, or information (collectively, signals) over a wired or wireless transmission medium. Each of the units, or an associated processor or controller that provides instructions to the unit's communication interface, may be configured to communicate with one or more of the other units over a transmission medium. For example, the units may include a wired interface configured to receive or transmit signals to one or more of the other units over a wired transmission medium. Furthermore, the units may include a wireless interface, which may include a receiver, transmitter, or transceiver (such as a radio frequency (RF) transceiver) configured to receive or transmit or transmit signals over a wireless transmission medium to one or more of the other units.

[0062]

[0071] In some aspects, the CU 162 may host one or more higher layer control functions. Such control functions may include Radio Resource Control (RRC), Packet Data Convergence Protocol (PDCP), Service Data Adaptation Protocol (SDAP), etc. Each control function may be implemented with an interface configured to communicate signals with other control functions hosted by the CU 162. The CU 162 may be configured to handle user plane functions (i.e., Central Unit-User Plane (CU-UP)), control plane functions (i.e., Central Unit-Control Plane (CU-CP)), or a combination thereof. In some implementations, the CU 162 may be logically divided into one or more CU-UP units and one or more CU-CP units. The CU-UP units, when implemented in an O-RAN configuration, may communicate bidirectionally with the CU-CP units via an interface, such as an E1 interface. The CU 162 may be implemented to communicate with the DU 170, as needed, for network control and signaling.

[0063]

[0072] The DU 170 may correspond to a logical unit including one or more base station functions for controlling the operation of one or more RUs 172. In some aspects, the DU 170 may host one or more of a Radio Link Control (RLC) layer, a Medium Access Control (MAC) layer, and one or more upper physical (PHY) layers (such as modules for forward error correction (FEC) encoding and decoding, scrambling, modulation and demodulation, etc.), at least in part according to a functional division such as that defined by the 3rd Generation Partnership Project (3GPP). In some aspects, the DU 170 may further host one or more lower PHY layers. Each layer (or module) may be implemented with an interface configured to communicate signals with other layers (and modules) hosted by the DU 170 or with a control function hosted by the CU 162.

[0064]

[0073] The lower layer functions may be implemented by one or more RUs 172. In some deployments, the RUs 172 controlled by the DU 170 may correspond to logical nodes hosting RF processing functions, or low PHY layer functions (such as performing fast Fourier transform (FFT), inverse FFT (iFFT), digital beamforming, physical random access channel (PRACH) extraction and filtering, etc.), or both, based at least in part on a functional division such as a lower layer functional division. In such an architecture, the RU(s) 172 may be implemented to handle over-the-air (OTA) communications with one or more UEs 120. In some implementations, real-time and non-real-time aspects of control and user plane communications with the RU(s) 172 may be controlled by the corresponding DU 170. In some scenarios, this configuration may enable the DU(s) 170 and the CU 162 to be implemented in a cloud-based radio access network (RAN) architecture, such as a vRAN architecture.

[0065]

[0074] The SMO framework 166 may be configured to support RAN deployment and provisioning of non-virtualized and virtualized network elements. For non-virtualized network elements, the SMO framework 166 may be configured to support deployment of dedicated physical resources for RAN coverage requirements, which may be managed via an operation and maintenance interface (such as an O1 interface). For virtualized network elements, the SMO framework 166 may be configured to interact with a cloud computing platform (such as an open cloud (O-cloud) 176) to perform network element lifecycle management (such as instantiating virtualized network elements) via a cloud computing platform interface (such as an O2 interface). Such virtualized network elements may include, but are not limited to, the CU 162, the DU 170, the RU 172, and the near-RT RIC 164. In some implementations, the SMO framework 166 may communicate with hardware aspects of a 4G RAN, such as the open eNB (O-eNB) 174, via an O1 interface. Additionally, in some implementations, the SMO framework 166 can communicate directly with one or more RUs 172 via an O1 interface. The SMO framework 166 can also include a non-RT RIC 168 configured to support the functionality of the SMO framework 166.

[0066]

[0075] The non-RT RIC 168 may be configured to include logic functions that enable non-real-time control and optimization of RAN elements and resources, artificial intelligence / machine learning (AI / ML) workflows including model training and updates, or policy-based guidance of applications / features in the near-RT RIC 164. The non-RT RIC 168 may be coupled to the near-RT RIC 125 or may communicate with the near-RT RIC 164 (e.g., via an A1 interface). The near-RT RIC 164 may be configured to include logic functions that enable near real-time control and optimization of RAN elements and resources via one or more CUs 162, one or more DUs 170, or both, and data collection and action via an interface connecting the O-eNB to the near-RT RIC 164 (e.g., via an E2 interface).

[0067]

[0076] In some implementations, the non-RT RIC 168 may receive parameters or external enrichment information from an external server to generate the AI / ML models deployed to the near-RT RIC 164. Such information may be utilized by the near-RT RIC 164 or may be received at the SMO framework 166 or the non-RT RIC 168 from non-network data sources or from network functions. In some examples, the non-RT RIC 168 or the near-RT RIC 164 may be configured to adjust RAN behavior or performance. For example, the non-RT RIC 168 may employ the AI / ML models to monitor long-term trends and patterns regarding performance and take corrective action through the SMO framework 166 (e.g., reconfiguration via O1) or through the creation of RAN management policies (e.g., A1 policies).

[0068]

[0077] 2 is a component block diagram illustrating an exemplary computing and wireless modem system 200 suitable for implementing any of the various embodiments. The various embodiments may be implemented on a number of single-processor and multi-processor computer systems, including systems on a chip (SOC) or systems in a package (SIP).

[0069]

[0078] 1A-2, the illustrated exemplary computing system 200 (which may be a SIP in some embodiments) includes two SOCs 202, 204 coupled to a clock 206, a voltage regulator 208, and a wireless transceiver 266 configured to transmit and receive wireless communications to and from a UE, such as a base station 110a, via an antenna (not shown). In some implementations, the first SOC 202 may operate as a central processing unit (CPU) of the UE that executes instructions of a software application program by performing arithmetic, logical, control, and input / output (I / O) operations specified by the instructions. In some implementations, the second SOC 204 may operate as a dedicated processing unit. For example, the second SOC 204 may operate as a dedicated 5G processing unit responsible for managing high volume, high speed (e.g., 5 Gbps), or very high frequency short wavelength (e.g., 28 GHz mmWave spectrum) communications.

[0070]

[0079] The first SOC 202 may include a digital signal processor (DSP) 210, a modem processor 212, a graphics processor 214, an application processor 216, one or more coprocessors 218 (such as a vector coprocessor) connected to one or more of the processors, memory 220, custom circuitry 222, system components and resources 224, an interconnect / bus module 226, one or more temperature sensors 230, a thermal management unit 232, and a thermal power envelope (TPE) component 234. The second SOC 204 may include a 5G modem processor 252, a power management unit 254, an interconnect / bus module 264, multiple mmWave transceivers 256, memory 258, and various additional processors 260, such as application processors, packet processors, etc.

[0071]

[0080] Each processor 210, 212, 214, 216, 218, 252, 260 may include one or more cores, and each processor / core may perform operations independent of the other processors / cores. For example, the first SOC 202 may include a processor that executes a first type of operating system (e.g., FreeBSD, LINUX, OS X, etc.) and a processor that executes a second type of operating system (e.g., MICROSOFT WINDOWS 10, etc.). Additionally, any or all of the processors 210, 212, 214, 216, 218, 252, 260 may be included as part of a processor cluster architecture (e.g., a synchronous processor cluster architecture, an asynchronous or heterogeneous processor cluster architecture, etc.).

[0072]

[0081] The first SOC 202 and the second SOC 204 may include various system components, resources, and custom circuits for managing sensor data, analog-to-digital conversion, wireless data transmission, and performing other specialized operations, such as processing encoded audio and video signals for decoding data packets and rendering in a web browser. For example, the system components and resources 224 of the first SOC 202 may include power amplifiers, voltage regulators, oscillators, phase-locked loops, peripheral bridges, data controllers, memory controllers, system controllers, access ports, timers, and other similar components used to support the processor and software client running on the UE. The system components and resources 224, or custom circuits 222, may also include circuits for interfacing with peripheral devices, such as cameras, electronic displays, wireless communication devices, external memory chips, etc.

[0073]

[0082] The first SOC 202 and the second SOC 204 may communicate via an interconnect / bus module 250. The various processors 210, 212, 214, 216, 218 may be interconnected to one or more memory elements 220, system components and resources 224, and custom circuitry 222, as well as a thermal management unit 232, via an interconnect / bus module 226. Similarly, the processor 252 may be interconnected to a power management unit 254, an mmWave transceiver 256, memory 258, and various additional processors 260, via an interconnect / bus module 264. The interconnect / bus modules 226, 250, 264 may include an array of reconfigurable logic gates or implement a bus architecture (CoreConnect, AMBA, etc.). Communication may occur through advanced interconnects such as high-performance networks on chips (NoCs).

[0074]

[0083] The first SOC 202 or the second SOC 204 may further include an input / output module (not shown) for communicating with resources external to the SOC, such as a clock 206 and a voltage regulator 208. Resources external to the SOC (e.g., clock 206, voltage regulator 208) may be shared by two or more of the internal SOC processors / cores.

[0075]

[0084] In addition to the exemplary SIP 200 described above, some implementations may be implemented in a wide variety of computing systems, which may include a single processor, multiple processors, multi-core processors, or any combination thereof.

[0076]

[0085] 3 is a component block diagram illustrating a software architecture 300 including radio protocol stacks for user and control planes in wireless communications suitable for implementing any of the various embodiments. With reference to FIGS. 1A-3, a UE 320 may implement the software architecture 300 to facilitate communication between the UE 320 (e.g., UEs 120a-120e, 200) and a network device 350 (e.g., network device 142a) of a communications system (e.g., 100). In various embodiments, layers in the software architecture 300 may form logical connections with corresponding layers in the software of the network device 350. The software architecture 300 may be distributed among one or more processors (e.g., processors 212, 214, 216, 218, 252, 260, etc.). Although illustrated with respect to one radio protocol stack in a multi-SIM (Subscriber Identity Module) UE, software architecture 300 may include multiple protocol stacks, each associated with a different SIM (such as two protocol stacks associated with two SIMs in a dual-SIM wireless communication device). Although described below with respect to an LTE communication layer, software architecture 300 may support any of a variety of standards and protocols for wireless communication and / or may include additional protocol stacks supporting any of a variety of standards and protocols for wireless communication.

[0077]

[0086] The software architecture 300 may include a non-access stratum (NAS) 302 and an access stratum (AS) 304. The NAS 302 may include functions and protocols to support packet filtering, security management, mobility control, session management, and traffic and signaling between a UE's SOC (e.g., SOC 204) and its core network 140. The AS 304 may include functions and protocols to support communication between a SOC (e.g., SOC 204) and supported access network entities (e.g., base stations). Specifically, the AS 304 may include at least three layers (Layer 1, Layer 2, and Layer 3), each of which may include various sublayers.

[0078]

[0087] In the user and control plane, Layer 1 (L1) of the AS 304 may be the physical layer (PHY) 306, which may oversee functions that enable transmission or reception over the air interface via a wireless transceiver (e.g., 266). Examples of such physical layer 306 functions may include cyclic redundancy check (CRC) attachment, coding blocks, scrambling and descrambling, modulation and demodulation, signal measurement, MIMO, etc. The physical layer may include various logical channels, including a physical downlink control channel (PDCCH) and a physical downlink shared channel (PDSCH).

[0079]

[0088] In the user and control planes, Layer 2 (L2) of the AS 304 may carry the link between the UE 320 and the network device 350 over the physical layer 306. In some implementations, Layer 2 may include a Medium Access Control (MAC) sublayer 308, a Radio Link Control (RLC) sublayer 310, a Packet Data Convergence Protocol (PDCP) sublayer 312, and a Service Data Adaptation Protocol (SDAP) 317 sublayer, each of which forms a logical connection that terminates at the network device 350.

[0080]

[0089] In the control plane, Layer 3 (L3) of the AS 304 may include a Radio Resource Control (RRC) sublayer 3. Although not shown, the software architecture 300 may include additional Layer 3 sublayers, as well as various upper layers above Layer 3. In some implementations, the RRC sublayer 313 may provide functions including broadcasting system information, paging, and establishing and releasing RRC signaling connections between the UE 320 and the network device 350.

[0081]

[0090] In various embodiments, the SDAP sublayer 317 may provide mapping between quality of service (QoS) flows and data radio bearers (DRBs). In various implementations, the PDCP sublayer 312 may provide uplink functions including multiplexing between different radio bearers and logical channels, sequence numbering, handover data processing, integrity protection, ciphering, and header compression. In the downlink, the PDCP sublayer 312 may provide functions including in-order delivery of data packets, duplicate data packet detection, integrity verification, decryption, and header recovery.

[0082]

[0091] In the uplink, the RLC sublayer 310 may provide segmentation and concatenation of upper layer data packets, retransmission of lost data packets, and automatic repeat request (ARQ). In the downlink, the RLC sublayer 310 functions may include reordering of data packets to compensate for out-of-order reception, reassembly of upper layer data packets, and ARQ.

[0083]

[0092] In the uplink, the MAC sublayer 308 may provide functions including multiplexing between logical and transport channels, random access procedures, logical channel priorities, and Hybrid ARQ (HARQ) operations. In the downlink, MAC layer functions may include channel mapping within a cell, demultiplexing, discontinuous reception (DRX), and HARQ operations.

[0084]

[0093] While the software architecture 300 may provide functionality for transmitting data over a physical medium, the software architecture 300 may further include at least one host layer 314 for providing data transfer services to various applications in the UE 320. In some implementations, the application-specific functionality provided by the at least one host layer 314 may provide an interface 206 between the software architecture and a general-purpose processor.

[0085]

[0094] In other implementations, software architecture 300 may include one or more upper logical layers (transport, session, presentation, application, etc.) that provide host layer functionality. For example, in some implementations, software architecture 300 may include a network layer (such as an Internet Protocol (IP) layer) in which a logical connection terminates at a Packet Data Network (PDN) Gateway (PGW). In some implementations, software architecture 300 may include an application layer in which a logical connection terminates at another device (such as an end user device, a server, etc.). In some implementations, software architecture 300 may further include a hardware interface 316 between physical layer 306 and communications hardware (such as one or more radio frequency (RF) transceivers) in AS 304.

[0086]

[0095] 4 is a system block diagram illustrating an example system 400a for bootstrapping application security suitable for use in various embodiments. With reference to FIG. 1A-FIG. 4, the system 400a may include a UE 402, a NAF 404, a BSF 406, a Home Subscriber Server (HSS) 408, and a Subscriber Locator Function (SLF) 410.

[0087]

[0096] In various embodiments, the UE 402 and the BSF 406 may perform authentication operations to authenticate the UE to the BSF. In some embodiments, negotiation between the BSF 406 and the UE 402 may perform authentication operations over a Ub interface and may use a protocol such as AKA. The UE 402 may communicate with the NAF 404 over a Ua interface. In various embodiments, the UE 402 and the NAF 404 may not have a prior security association. The UE 402 may generate a first session key, e.g., Ks_NAF. The NAF 404 may receive the first session key (e.g., Ks_NAF) from the BSF 406 over a Zn interface.

[0088]

[0097] The HSS 408 may act as a database or other suitable data storage that may store user authentication credentials for the UE 402, such as a User Security Set (USS) (e.g., GBA User Security Set (GUSS)). In some embodiments, the HSS 408 may map the user authentication credentials to a private identity, such as an IP Multimedia Private Identity (IMPI). The HSS 408 may communicate this and other information to the BSF 406 over a Zh interface. The SLF 410 may store and provide information to identify the HSS 408 that stores information related to the UE 402 (i.e., related to a particular UE). The BSF 406 and the SLF 410 may communicate over a Dz interface.

[0089]

[0098] In some embodiments, the UE 402 may perform a bootstrapping operation with the BSF 406 over a Ub interface, such as various GBA methods (e.g., GBA_ME, GBA_U, 2G GBA, GBA_Digest, etc.). The bootstrapping procedure by the UE 402 may include a procedure in which an AKA-based Ks_(ext)_NAF is generated (e.g., a GBA-based authentication identified by the PSK identifier (namespace) "3GPP-bootstrapping"), a procedure in which a Ks_int_NAF is generated (e.g., a GBA-based authentication identified by the PSK identifier (namespace) "3GPP-bootstrapping-uicc"), and a procedure in which a GBA_Digest-based Ks_NAF is generated (e.g., a GBA-based authentication identified by the PSK identifier (namespace) "3GPP-bootstrapping-digest"). In some embodiments, the bootstrapping procedure performed by UE 402 may be an original (or initial) bootstrapping procedure to obtain an initial (or first) B-TID and an initial (or first) key (Ks), or may be a fresh (e.g., renegotiation-related) bootstrapping procedure to obtain a new (or fresh) B-TID and a new (or fresh) Ks.

[0090]

[0099] 5 is a process flow diagram illustrating a method 500 that may be performed by a processor of a UE for supporting PSK renegotiation, according to various embodiments. With reference to FIGS. 1A-5, the operations of method 500 may be performed by a processor (e.g., processors 210, 212, 214, 216, 218, 252, 260, etc.) of a UE (e.g., 120a-120e, 320, 402). With reference to FIGS. 1A-5, the means for performing the operations of method 500 may be one or more processors of the UE (e.g., 120a-120e, 320, 402), such as one or more of processors 210, 212, 214, 216, 218, 252, 260, and / or one or more transceivers, such as transceivers 256, 266.

[0091]

[0100] In block 502, the processor may perform operations including performing a bootstrapping procedure with the BSF to obtain a first B-TID and a first Ks. For example, the bootstrapping procedure performed may be an original (or initial) bootstrapping procedure to obtain the first B-TID and the first Ks. For example, the operations of block 502 may include bootstrapping and / or other authentication procedures described with reference to FIG. 4. Means for performing the operations of block 502 may include the processors 210, 212, 214, 216, 218, 252, 260 and the transceivers 256, 266.

[0092]

[0101] In block 504, the processor may perform operations including generating a request message including a first B-TID, at least one PSK namespace identifying a bootstrapping procedure supported by the UE (such as a bootstrapping procedure used to generate a key (Ks) associated with the first B-TID), and at least one correlated PSK namespace indicating that PSK renegotiation is supported by the UE for the bootstrapping procedure. As an example of the operations in block 504, the first request message may include a first bootstrapping transaction identifier (B-TID), a first PSK namespace identifying a first bootstrapping procedure supported by the UE, and a first correlated PSK namespace indicating that PSK renegotiation is supported by the UE for the first bootstrapping procedure. Means for performing the operations of block 504 may include the processors 210, 212, 214, 216, 218, 252, 260, and the transceivers 256, 266.

[0093]

[0102] Optionally, the first request message generated in block 504 may include additional PSK namespaces identifying additional bootstrapping procedures supported by the UE, such as one, two, or more additional bootstrapping procedures supported by the UE. Optionally, the first request message generated in block 504 may include additional correlated PSK namespaces, such as one, two, or more additional correlated PSK namespaces, indicating that PSK renegotiation is supported by the UE for any additional bootstrapping procedures. Each indicated PSK namespace may have its own respective correlated PSK namespace when PSK renegotiation is supported by the UE for the bootstrapping procedure of the indicated PSK namespace. As an example, the first request message may include a first B-TID, a first PSK namespace identifying a first bootstrapping procedure supported by the UE, a first correlated PSK namespace indicating that PSK renegotiation is supported by the UE for the first bootstrapping procedure, a second PSK namespace identifying a second bootstrapping procedure supported by the UE, a second correlated PSK namespace indicating that PSK renegotiation is supported by the UE for the second bootstrapping procedure, and a second B-TID associated with the second bootstrapping method.

[0094]

[0103] In some embodiments, the first request message generated at block 504 may be a ClientHello message. The PSK identity in the ClientHello message may include a prefix indicating the respective PSK identity namespace and B-TID. Non-limiting examples of the prefixes include "3GPP-bootstrapping-uicc", "3GPP-bootstrapping", and / or "3GPP-bootstrapping-digest". The prefix "3GPP-bootstrapping" may be used in the PSK identity to indicate that the UE accepts that the AKA-based Ks_(ext)_NAF is used to establish the TLS session key. The prefix "3GPP-bootstrapping-uicc" may be used in the PSK identity to indicate that the UE accepts that the Ks_int_NAF is used to establish the TLS session key. The prefix "3GPP-bootstrapping-digest" is used in the PSK identity to indicate that the UE accepts that the GBA_Digest-based Ks_NAF is used to establish the TLS session key. In various embodiments, in addition to each of these included identifiers (e.g., PSK identity namespaces such as "3GPP-bootstrapping-uicc", "3GPP-bootstrapping", and / or "3GPP-bootstrapping-digest"), at least one additional (or correlated) PSK identity namespace may be included to enable the NAF to request fresh bootstrapping.For example, if the PSK identity namespace "3GPP-bootstrapping-uicc" is included then the correlated PSK identity namespace "3GPP-bootstrapping-uicc-renegotiation" can be included, if the PSK identity namespace "3GPP-bootstrapping-digest" is included then the correlated PSK identity namespace "3GPP-bootstrapping-digest-renegotiation" can be included, and / or if the PSK identity namespace "3GPP-bootstrapping" is included then the correlated PSK identity namespace "3GPP-bootstrapping-renegotiation" can be included. Similarly, the PSK identity namespace of the correlated actual key and renegotiation support indicating the PSK identity namespace pair can be included for other bootstrapping methods.

[0095]

[0104] In block 506, the processor may perform operations including sending a request message to a network entity, such as a NAF server. For example, the request message may be sent to attempt to establish a TLS tunnel to the network entity. Means for performing the operations of block 506 may include the processors 210, 212, 214, 216, 218, 252, 260 and the transceivers 256, 266.

[0096]

[0105] In block 507, the processor may optionally perform operations including receiving a response message from a network entity, such as a NAF server. For example, the response message may be a ServerHello message from the NAF. The means for performing the operations of block 507 may include the processors 210, 212, 214, 216, 218, 252, 260, and the transceivers 256, 266.

[0097]

[0106] In decision block 508, the processor may perform operations including determining whether an indication of a correlated PSK namespace (correlated to the PSK renegotiation) is included in the received response message. For example, the response message may be a ServerHello message from the NAF. The indication of the correlated PSK namespace may be the correlated PSK namespace itself included in the received response message. The indication of the correlated PSK namespace may be an index of the correlated PSK namespace included in the received response message. The indication of the correlated PSK namespace may be a position of the correlated PSK namespace in a list. The processor may parse the response message to determine whether an indication (e.g., namespace, index, position, etc.) in the response message is an indication of a correlated PSK namespace (correlated to the PSK renegotiation) or an indication of a selected PSK namespace (selected supported bootstrapping procedure). An indication (e.g., namespace, index, position, etc.) that is an indication of a correlated PSK namespace may indicate that a response message including an indication of a correlated PSK namespace has been received. An indication that is an indication of the selected PSK namespace (e.g., namespace, index, location, etc.) may indicate that a response message was not received that includes an indication of the correlated PSK namespace. Means for performing the operations of decision block 508 may include processors 210, 212, 214, 216, 218, 252, 260 and transceivers 256, 266.

[0098]

[0107] In response to determining that the response message does not include an indication of the correlated PSK namespace (e.g., namespace, index, location, etc.) (i.e., decision block 508="no"), the processor may perform operations in block 510 including communicating with a network element (e.g., a NAF server) using the first session key Ks. For example, if the response message includes an index of the PSK (rather than the PSK namespace), this may indicate that secure communications may proceed using the current key. Means for performing the operations of block 510 may include processors 210, 212, 214, 216, 218, 252, 260, and transceivers 256, 266.

[0099]

[0108] In response to determining that the response message includes an indication of the correlated PSK namespace (e.g., namespace, index, location, etc.) (i.e., decision block 508="yes"), the processor may perform operations including performing an indicated bootstrapping procedure (i.e., a supported bootstrapping procedure associated with the correlated PSK namespace) with the BSF to obtain a second (i.e., new or fresh) B-TID and a second (i.e., new or fresh) Ks in block 512. The processor may perform operations including performing an indicated bootstrapping procedure with the BSF to obtain a second (i.e., new) B-TID and a second (i.e., new) Ks based on receiving the response message. For example, the bootstrapping procedure performed may be a new (or fresh) bootstrapping procedure to obtain a second (i.e., new) B-TID and a second (i.e., new) Ks. For example, the operations of block 512 may include PSK renegotiation and bootstrapping procedures and / or other authentication procedures performed at a subsequent time to result in a second (i.e., new) B-TID and a second (i.e., new) Ks in the UE. Means for performing the operations of block 512 may include processors 210, 212, 214, 216, 218, 252, 260 and transceivers 256, 266.

[0100]

[0109] In block 514, the processor may perform operations including generating a second request message including the second (i.e., new) B-TID and a PSK namespace. As an example, the PSK namespace may be a PSK namespace corresponding to a GBA method resulting in the second (i.e., new) B-TID and the second (i.e., new) Ks. As another example, the PSK namespace may be a first PSK namespace identifying a first bootstrapping procedure supported by the UE. As another example, the second request message may be a second ClientHello message. Means for performing the operations of block 504 may include the processor 210, 212, 214, 216, 218, 252, 260, and the wireless transceiver 266.

[0101]

[0110] In block 516, the processor may perform operations including sending a second request message to a network entity (e.g., a NAF server). For example, the second request message may be sent to attempt to establish a TLS tunnel to the NAF. Means for performing the operations of block 516 may include the processors 210, 212, 214, 216, 218, 252, 260 and the transceivers 256, 266.

[0102]

[0111] In block 518, the processor may perform operations including communicating with a network entity (e.g., a NAF server) over a secure communication session using the second (i.e., new) Ks. Means for performing the operations of block 518 may include the processors 210, 212, 214, 216, 218, 252, 260 and the transceivers 256, 266.

[0103]

[0112] FIG. 6 is a process flow diagram illustrating a method 600 that may be performed by a processor of a network entity (e.g., a NAF server) for securing communication with a UE, according to various embodiments. With reference to FIGS. 1A-6, the operations of the method 600 may be performed by a processor (e.g., processors 210, 212, 214, 216, 218, 252, 260, 432, etc.) of a network device (e.g., 142a, 350). In various embodiments, the operations of the method 600 may be performed in combination with the operations of the method 500 (FIG. 5A). With reference to FIGS. 1A-6, the means for performing the operations of the method 600 may be one or more processors of the network device (e.g., 142a, 350), such as one or more of the processors 210, 212, 214, 216, 218, 252, 260, and / or one or more transceivers, such as the transceivers 256, 266.

[0104]

[0113] In block 602, the processor may perform operations including receiving a request message from the UE including a B-TID, at least one PSK namespace identifying a bootstrapping procedure supported by the UE, and at least one correlated PSK namespace indicating that PSK renegotiation is supported by the UE for the bootstrapping procedure. For example, a first request message may include a first B-TID, a first PSK namespace identifying a first bootstrapping procedure supported by the UE, and a first correlated PSK namespace indicating that PSK renegotiation is supported by the UE for the first bootstrapping procedure. Means for performing the operations of block 602 may include the processor 210, 212, 214, 216, 218, 252, 260, and the wireless transceiver 266.

[0105]

[0114] Optionally, the first request message received at block 602 may include additional PSK namespaces identifying additional bootstrapping procedures supported by the UE, such as one, two, or more additional bootstrapping procedures supported by the UE. Optionally, the first request message received at block 602 may include additional correlated PSK namespaces, such as one, two, or more additional correlated PSK namespaces, indicating that PSK renegotiation is supported by the UE for any additional bootstrapping procedures. Each indicated PSK namespace may have its own respective correlated PSK namespace when PSK renegotiation is supported by the UE for the bootstrapping procedure of the indicated PSK namespace. As an example, the first request message may include a first B-TID, a first PSK namespace identifying a first bootstrapping procedure supported by the UE, a first correlated PSK namespace indicating that PSK renegotiation is supported by the UE for the first bootstrapping procedure, a second PSK namespace identifying a second bootstrapping procedure supported by the UE, and a second correlated PSK namespace indicating that PSK renegotiation is supported by the UE for the second bootstrapping procedure.

[0106]

[0115] In some embodiments, the first request message received at block 602 may be a ClientHello message. The PSK identifier in the ClientHello may include prefixes indicating a respective PSK identity namespace, such as "3GPP-bootstrapping-uicc", "3GPP-bootstrapping", and / or "3GPP-bootstrapping-digest", as well as prefixes indicating additional (or correlated) PSK identity namespaces, such as "3GPP-bootstrapping-uicc-renegotiation", "3GPP-bootstrapping-digest-renegotiation", and / or "3GPP-bootstrapping-renegotiation", as described with reference to block 504 of method 500 (FIG. 5).

[0107]

[0116] In decision block 604, the processor may perform operations including determining whether PSK renegotiation is required for the UE. For example, the processor may determine whether a key associated with the B-TID is overaged to determine whether PSK renegotiation is required (e.g., an overaged key may indicate that PSK renegotiation is required). As another example, the processor may request PSK renegotiation by default as a security measure to ensure that the UE has access to security credentials to support the renegotiation. Means for performing the operations of block 602 may include the processors 210, 212, 214, 216, 218, 252, 260, and the transceivers 256, 266.

[0108]

[0117] In response to a determination that PSK renegotiation is not required (i.e., decision block 604="No"), the processor may perform operations in block 606 including completing a GBA procedure to obtain a first session key Ks from the BSF, responding (e.g., in a ServerHello message) to the UE indicating the selected GBA method and initiating communications with the UE using the first session key Ks. For example, PSK renegotiation may not be required and communications with the UE may proceed using the current key. Means for performing the operations of block 606 may include the processors 210, 212, 214, 216, 218, 252, 260 and the transceivers 256, 266.

[0109]

[0118] In response to a determination that PSK renegotiation is required (i.e., decision block 604="yes"), the processor may perform operations including determining an indication of a correlated PSK namespace (correlated to PSK renegotiation) correlated (or corresponding) to the selected PSK namespace in block 608. The indication of the correlated PSK namespace correlated to the selected PSK namespace may be an indication of the correlated PSK namespace itself. The indication of the correlated PSK namespace may be an index of the correlated PSK namespace. The indication of the correlated PSK namespace may be a position of the correlated PSK namespace in a list of PSK namespaces. For example, the NAF may determine an index of the correlated PSK namespace correlated to a bootstrapping procedure (identified by the selected PSK namespace) that the NAF supports and that the UE supports. Means for performing the operations of block 608 may include the processor 210, 212, 214, 216, 218, 252, 260, and the transceiver 256, 266.

[0110]

[0119] At block 610, the processor may perform operations including generating a response message including an indication of the correlated PSK namespace (e.g., namespace, index, location, etc.). For example, the response message may be a ServerHello message including the index of the correlated PSK namespace. Means for performing the operations of block 610 may include processors 210, 212, 214, 216, 218, 252, 260 and transceivers 256, 266.

[0111]

[0120] In block 612, the processor may perform operations including transmitting a response message to the UE. Means for performing the operations of block 612 may include the processors 210, 212, 214, 216, 218, 252, 260 and the transceivers 256, 266.

[0112]

[0121] In block 614, the processor may perform operations including receiving a second request message from the UE. For example, the second request message may be sent to attempt to establish a TLS tunnel to the NAF. As an example, the second request message from the UE may be a ClientHello message that includes a PSK namespace corresponding to the selected GBA method along with a second (i.e., new) B-TID. The means for performing the operations of block 614 may include the processors 210, 212, 214, 216, 218, 252, 260, and the transceivers 256, 266.

[0113]

[0122] In block 616, the processor may perform operations including completing the GBA procedure and obtaining a second (or new) session key Ks from the BSF based on the new B-TID, responding to the UE (e.g., with a ServerHello message) to indicate the selected GBA method, and initiating communication with the UE using the new Ks. Means for performing the operations of block 616 may include processors 210, 212, 214, 216, 218, 252, 260 and transceivers 256, 266.

[0114]

[0123] FIG. 7 is a component block diagram of a network device 700 (e.g., a NAF server) suitable for use in various embodiments. Such a network device (e.g., network device 142a, 350) may include at least the components shown in FIG. 7. With reference to FIGS. 1A-7, the network device 700 may typically include a processor 701 coupled to a volatile memory 702 and a large capacity non-volatile memory such as a disk drive 708. The network device 700 may also include a peripheral memory access device 706, such as a floppy disk drive, a compact disk (CD) drive, or a digital video disk (DVD) drive, coupled to the processor 701. The network device 700 may also include a network access port 704 (or interface) coupled to the processor 701 for establishing a data connection with a network, such as the Internet, or a local area network coupled to other system computers and servers. The network device 700 may include one or more antennas 707 for transmitting and receiving electromagnetic radiation, which may be connected to a wireless communication link. The network device 700 may include additional access ports, such as USB, Firewire, Thunderbolt, etc., for coupling to peripherals, external memory, or other devices.

[0115]

[0124] FIG. 8 is a component block diagram of a UE 800 suitable for use in various embodiments. With reference to FIGS. 1A-8, various embodiments may be implemented in various UEs 800 (e.g., UEs 120a-120e, 320, 402), an example of which is illustrated in FIG. 8 in the form of a smartphone. The UE 800 may include a first SOC 202 (e.g., SOC-CPU) coupled to a second SOC 204 (e.g., a 5G-enabled SOC). The first SOC 202 and the second SOC 204 may be coupled to an internal memory 816, a display 812, and a speaker 814. Additionally, the UE 800 may include an antenna 804 for transmitting and receiving electromagnetic radiation, which may be connected to a wireless transceiver 266 coupled to one or more processors in the first SOC 202 and / or the second SOC 204. The UE 800 may include a menu selection button or rocker switch 820 for receiving user input.

[0116]

[0125] The UE 800 may include a voice encoding / decoding (CODEC) circuit 810 that digitizes voice received from a microphone into data packets suitable for wireless transmission and decodes the received voice data packets to generate analog signals that are provided to a speaker to generate voice. One or more of the processors, wireless transceiver 266, and codec 810 in the first SOC 202 and second SOC 204 may include digital signal processor (DSP) circuitry (not separately shown).

[0117]

[0126] The processors of the network device 700 and the UE 800 may be any programmable microprocessor, microcomputer, or one or more multiple processor chips that may be configured by software instructions (applications) to perform various functions, including those of some implementations described below. In some UEs, multiple processors may be provided, such as one processor in the SOC 204 dedicated to wireless communication functions and one processor in the SOC 202 dedicated to running other applications. Software applications may be stored in the memory 702, 816 before they are accessed and loaded into the processor. The processors may include sufficient internal memory to store application software instructions.

[0118]

[0127] As used in this application, terms such as "component," "module," and "system" are intended to include computer-related entities, such as, but not limited to, hardware, firmware, a combination of hardware and software, software, or software in execution, configured to perform a particular operation or function. For example, a component may be, but is not limited to, a process running on a processor, a processor, an object, an executable, a thread of execution, a program, or a computer. By way of example, both an application running on a UE and the UE may be referred to as a component. One or more components may reside within a process or thread of execution, and a component may be localized on one processor or core or distributed among two or more processors or cores. In addition, these components may execute from various non-transitory computer-readable media on which various instructions or data structures are stored. Components may communicate by local or remote processes, function or procedure calls, electronic signals, data packets, memory reads / writes, and other known network, computer, processor, or process related communication methods.

[0119]

[0128] A number of different cellular and mobile communication services and standards are available or are contemplated in the future, all of which may implement and benefit from the various embodiments. Such services and standards include, for example, 3rd Generation Partnership Project (3GPP), Long Term Evolution (LTE) systems, third generation wireless mobile communication technologies (3G), fourth generation wireless mobile communication technologies (4G), fifth generation wireless mobile communication technologies (5G), and later generations of 3GPP technologies, Global System for Mobile Communications (GSM), Universal Mobile Telecommunications System (UMTS), 3GSM, General Packet Radio Service (GPRS), Code Division Multiple Access (CDMA) systems (e.g., cdmaOne, CDMA1020), Enhanced Data Rates for GSM Evolution (EDGE), Advanced Mobile Phone System (AMPS), Digital AMPS (IS-136 / TDMA), Evolution Data Optimized (EV-DO), digital enhanced cordless telecommunications (DECT), Worldwide Interoperability for Microwave Access (WiMAX), Wireless Local Area Networks (WLAN), Wi-Fi Protected Access I & II (E&I), and the like. II (WPA, WPA2), and Integrated Digital Enhanced Network (iDEN). Each of these technologies involves, for example, the transmission and reception of voice, data, signaling, and / or content messages. It should be understood that any reference to terminology and / or technical details relating to a particular telecommunications standard or technology is for illustrative purposes only and does not limit the scope of the claims to any particular communications system or technology unless specifically recited in the claim language.

[0120]

[0129] The various embodiments shown and described are provided merely as examples to illustrate various features of the claims. However, features shown and described with respect to any given embodiment are not necessarily limited to the associated embodiment, and may be used with or combined with other embodiments shown and described. Furthermore, the claims are not limited by any one exemplary embodiment. For example, one or more of the methods and operations described herein may be replaced by or combined with one or more operations of the methods and operations.

[0121]

[0130] Example implementations are described in the following paragraphs. Although some of the following examples are described with respect to example methods, further example implementations may include the example methods described in the following paragraphs implemented by a UE or network device including a processor configured with processor-executable instructions for performing the operations of the methods of the following examples, the example methods described in the following paragraphs implemented by a UE or network device including means for performing the functions of the methods of the following examples. The example methods described in the following paragraphs may be implemented as a non-transitory processor-readable storage medium storing processor-executable instructions configured to cause a processor of a UE or network device to perform the operations of the methods of the following examples.

[0122]

[0131] Example 1. A method performed by a user equipment (UE), such as a method for supporting pre-shared key (PSK) renegotiation performed by a processor of the UE, comprising: generating a first request message, the first request message including a first bootstrapping transaction identifier (B-TID), a first PSK namespace identifying a first bootstrapping procedure supported by the UE, and a first correlated PSK namespace indicating that PSK renegotiation is supported by the UE for the first bootstrapping procedure; and sending the first request message to a network application function (NAF); A method comprising:

[0123]

[0132] Example 2. The method of example 1, further comprising: receiving a response message from the NAF including an indication of the first correlated PSK namespace; and performing a bootstrapping procedure to obtain a second B-TID and a session key (Ks) based on receiving the response message.

[0124]

[0133] Example 3. The method of example 2, wherein performing the bootstrapping procedure includes re-performing the first bootstrapping procedure to obtain a second B-TID and a second session key (Ks).

[0125]

[0134] Example 4. The method of any of Examples 2 or 3, further comprising: generating a second request message including a second B-TID and the first correlated PSK namespace; and sending the second request message to the NAF.

[0126]

[0135] Example 5. The method of any one of Examples 2 to 4, wherein the indication of the first correlated PSK namespace is the first correlated PSK namespace in the response message.

[0127]

[0136] Example 6. The method of any one of Examples 2 to 5, wherein the indication of the first correlated PSK namespace is an index of the first correlated PSK namespace or a position of the first correlated PSK namespace in a list.

[0128]

[0137] Example 7. The method of any one of Examples 1 to 6, further comprising communicating with the NAF using a second Ks.

[0129]

[0138] Example 8. The method of any one of Examples 1 to 7, wherein the first request message further includes a second PSK namespace identifying a second bootstrapping procedure supported by the UE, and a second correlated PSK namespace indicating that PSK renegotiation is supported by the UE for the second bootstrapping procedure.

[0130]

[0139] Example 9. The method of any one of Examples 1 to 8, wherein the first request message is a client-initiated hello message.

[0131]

[0140] Example 10. A method performed by a network device, such as a method performed by a network device to support pre-shared key (PSK) renegotiation executed by a processor of the network device, comprising: receiving, by the network device, a first request message from a user equipment (UE), the first request message including a first bootstrapping transaction identifier (B-TID), a first PSK namespace identifying a first bootstrapping procedure supported by the UE, and a first correlated PSK namespace indicating that PSK renegotiation is supported by the UE for the first bootstrapping procedure; determining that PSK renegotiation is required for the UE after receiving the first request message; in response to determining that PSK renegotiation is required for the UE, determining an indication of PSK renegotiation for the first correlated PSK namespace; generating a response message including an indication of the first correlated PSK namespace; and transmitting the response message to the UE.

[0132]

[0141] Example 11. The method of example 10, wherein the indication of the first correlated PSK namespace is the first correlated PSK namespace.

[0133]

[0142] Example 12. The method of example 10, wherein the indication of the first correlated PSK namespace is an index of the first correlated PSK namespace or is a position of the first correlated PSK namespace in a list.

[0134]

[0143] Example 13. The method of any one of Examples 10 to 12, further comprising receiving, by the network device from the UE, a second request message including only the second B-TID and the first correlation PSK namespace.

[0135]

[0144] Example 14. The method of example 13, further comprising: communicating with the UE using a session key (Ks) obtained from a bootstrapping security function (BSF) using the second B-TID.

[0136]

[0145] Example 15. The first request message further includes a second PSK namespace identifying a second bootstrapping procedure supported by the UE, and a second correlated PSK namespace indicating that PSK renegotiation is supported by the UE for the second bootstrapping procedure, and determining that PSK renegotiation is required for the UE after receiving the first request message includes selecting a first bootstrapping procedure supported by the UE from a selection of the first bootstrapping procedure supported by the UE and the second bootstrapping procedure supported by the UE, determining that renegotiation is required for the first bootstrapping procedure, and determining an indication of the first correlated PSK namespace in response to selecting the first bootstrapping procedure supported by the UE. The method according to any one of Examples 10 to 14.

[0137]

[0146] Example 16. The method of any one of Examples 10 to 15, wherein the response message is a server-initiated hello message.

[0138]

[0147] Example 17. The method of any one of Examples 10 to 16, wherein the network device is a Network Application Function (NAF) server.

[0139]

[0148] The above method descriptions and process flow diagrams are provided as illustrative examples only and do not require or imply that the operations of the various embodiments must be performed in the order presented. As will be appreciated by one of ordinary skill in the art, the order of operations in the above-described embodiments may be performed in any order. Words such as "thereafter," "then," and "next" do not limit the order of operations. These words are used to guide the reader through the method descriptions. Furthermore, any reference to a claim element in the singular, for example using the articles "a," "an," or "the," should not be construed as limiting the element to the singular.

[0140]

[0149] The various exemplary logical blocks, modules, components, circuits, and algorithmic operations described in connection with the embodiments disclosed herein may be implemented as electronic hardware, computer software, or a combination of both. To clearly illustrate this interchangeability of hardware and software, the various exemplary components, blocks, modules, circuits, and operations have been described above generally in terms of their functionality. Whether such functionality is implemented as hardware or software depends on the particular application and design constraints imposed on the overall system. Those skilled in the art may implement the described functionality in various ways for each particular application, but such implementation decisions should not be interpreted as causing a departure from the scope of the claims.

[0141]

[0150] The hardware used to implement the various example logic, logic blocks, modules, and circuits described in connection with the embodiments disclosed herein may be implemented or performed using general purpose processors, digital signal processors (DSPs), application specific integrated circuits (ASICs), field programmable gate arrays (FPGAs) or other programmable logic devices, discrete gate or transistor logic, discrete hardware components, or any combination thereof designed to perform the functions described herein. A general purpose processor may be a microprocessor, but alternatively, the processor may be any conventional processor, controller, microcontroller, or state machine. A processor may also be implemented as a combination of receiver smart objects, e.g., a combination of a DSP and a microprocessor, multiple microprocessors, one or more microprocessors in conjunction with a DSP core, or any other such configuration. Alternatively, some operations or methods may be performed by circuitry specific to a given function.

[0142]

[0151] In one or more embodiments, the functions described may be implemented in hardware, software, firmware, or any combination thereof. If implemented in software, the functions may be stored as one or more instructions or codes on a non-transitory computer-readable or processor-readable storage medium. The operations of the methods or algorithms disclosed herein may be embodied in a processor-executable software module or processor-executable instructions that may reside on a non-transitory computer-readable or processor-readable storage medium. A non-transitory computer-readable or processor-readable storage medium may be any storage medium that may be accessed by a computer or processor. By way of example and not limitation, such non-transitory computer-readable or processor-readable storage medium may include RAM, ROM, EEPROM, FLASH memory, CD-ROM or other optical disk storage, magnetic disk storage or other magnetic storage smart objects, or any other medium that may be used to store desired program code in the form of instructions or data structures and that may be accessed by a computer. Disk and disc as used herein include compact disc (CD), laser disc, optical disc, digital versatile disc (DVD), floppy disk, and Blu-ray disc, where disks typically reproduce data magnetically and discs reproduce data optically using lasers. Combinations of the above are also included within the scope of non-transitory computer-readable and processor-readable media. Furthermore, operations of a method or algorithm may be present as one or any combination or set of code and / or instructions on a non-transitory processor-readable storage medium and / or a non-transitory computer-readable storage medium, which may be incorporated into a computer program product.

[0143]

[0152] The foregoing description of the disclosed embodiments is provided to enable any person skilled in the art to make or use the claims. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be applied to other embodiments without departing from the scope of the claims. Thus, the present disclosure is not intended to be limited to the embodiments shown herein, but is to be accorded the widest scope consistent with the following claims and the principles and novel features disclosed herein.

Claims

1. 1. A method performed by a user equipment (UE), comprising: generating a first request message, the first request message comprising: a first bootstrapping transaction identifier (B-TID); and a first pre-shared key (PSK) identity including a prefix indicating a PSK namespace, the PSK namespace identifying a first bootstrapping procedure supported by the UE; a first correlation PSK identity including a prefix indicating a correlation PSK namespace, the correlation PSK namespace indicating that PSK renegotiation is supported by the UE for the first bootstrapping procedure; generating a sending the first request message to a Network Application Function (NAF); A method comprising:

2. receiving a response message from the NAF including an indication of the first correlated PSK namespace; performing a bootstrapping procedure to obtain a second B-TID and a session key (Ks) based on receiving the response message; The method of claim 1 further comprising:

3. 3. The method of claim 2, wherein performing the bootstrapping procedure includes re-performing the first bootstrapping procedure to obtain the second B-TID and a second session key (Ks).

4. generating a second request message including the second B-TID and the first correlated PSK namespace; sending the second request message to the NAF; The method of claim 2 further comprising:

5. The method of claim 2 , wherein the representation of the first correlated PSK namespace is the first correlated PSK namespace.

6. 3. The method of claim 2, wherein the indication of the first correlated PSK namespace is an index of the first correlated PSK namespace or a position of the first correlated PSK namespace in a list.

7. communicating with the NAF using the second Ks; The method of claim 2 further comprising:

8. the first request message: a second PSK namespace identifying a second bootstrapping procedure supported by the UE; and a second correlated PSK namespace indicating that PSK renegotiation is supported by the UE for the second bootstrapping procedure; and The method of claim 1 further comprising:

9. The method of claim 1 , wherein the first request message is a client-initiated hello message.

10. 1. A method performed by a network device, comprising: receiving, by the network device, a first request message from a user equipment (UE), the first request message comprising: a first bootstrapping transaction identifier (B-TID); and a first pre-shared key (PSK) identity including a prefix indicating a PSK namespace, the PSK namespace identifying a first bootstrapping procedure supported by the UE; a first correlation PSK identity including a prefix indicating a correlation PSK namespace, the correlation PSK namespace indicating that PSK renegotiation is supported by the UE for the first bootstrapping procedure; receiving, determining that PSK renegotiation is required for the UE after receiving the first request message; determining an indication of the first correlated PSK namespace in response to determining that PSK renegotiation is required for the UE; and generating a response message including the indication of the first correlated PSK namespace; sending the response message to the UE; A method comprising:

11. A user equipment (UE), A transceiver; a processor coupled to the transceiver; wherein the processor: a first request message, a first bootstrapping transaction identifier (B-TID); and a first pre-shared key (PSK) identity including a prefix indicating a PSK namespace, the PSK namespace identifying a first bootstrapping procedure supported by the UE; a first correlation PSK identity including a prefix indicating a correlation PSK namespace, the correlation PSK namespace indicating that PSK renegotiation is supported by the UE for the first bootstrapping procedure; generating a first request message including: sending the first request message to a Network Application Function (NAF) via the transceiver; It is configured as follows: User Equipment (UE).

12. the processor: receiving a response message from the NAF including an indication of the first correlated PSK namespace; performing a bootstrapping procedure to obtain a second B-TID and a session key (Ks) based on receiving the response message; further configured as follows: The UE of claim 11.

13. 13. The UE of claim 12, wherein the processor is further configured to perform another bootstrapping procedure by re-performing the first bootstrapping procedure to obtain the second B-TID and a second session key (Ks).

14. 1. A network device, comprising: a processor, the processor comprising: A first request message from a user equipment (UE), comprising: a first bootstrapping transaction identifier (B-TID); and a first pre-shared key (PSK) identity including a prefix indicating a PSK namespace, the PSK namespace identifying a first bootstrapping procedure supported by the UE; a first correlation PSK identity including a prefix indicating a correlation PSK namespace, the PSK namespace indicating that PSK renegotiation is supported by the UE for the first bootstrapping procedure; receiving a first request message including: After receiving the first request message, determine that PSK renegotiation is required for the UE; In response to determining that PSK renegotiation is required for the UE, determine a PSK renegotiation indication for the first correlated PSK namespace; generating a response message including the indication of the first correlated PSK namespace; sending the response message to the UE; configured to perform an operation for Network devices.

15. 1. A non-transitory processor-readable storage medium having stored thereon processor-executable instructions configured to cause a processor of a user equipment (UE) to perform operations, the operations comprising: generating a first request message, the first request message comprising: a first bootstrapping transaction identifier (B-TID); and a first pre-shared key (PSK) identity including a prefix indicating a PSK namespace, the PSK namespace identifying a first bootstrapping procedure supported by the UE; a first correlation PSK identity including a prefix indicating a correlation PSK namespace, the correlation PSK namespace indicating that PSK renegotiation is supported by the UE for the first bootstrapping procedure; generating a sending the first request message to a Network Application Function (NAF); Including, A non-transitory processor-readable storage medium.

Images