WO2020201051A1

WO2020201051A1 - Methods and apparatus for enabling end-to-end data protection

Info

Publication number: WO2020201051A1
Application number: PCT/EP2020/058652
Authority: WO
Inventors: David Castellanos Zamora; Maria Cruz BARTOLOMÉ RODRIGO
Original assignee: Telefonaktiebolaget Lm Ericsson (Publ)
Priority date: 2019-03-29
Filing date: 2020-03-27
Publication date: 2020-10-08

Abstract

Embodiments described herein relate to methods and apparatus for enabling end-to-5 end data protection between a wireless device and the home network. A method, in an authentication function comprises performing an authentication procedure with the wireless device to generate a first security key for use in end-to-end protection between the home network and the wireless device; and transmitting a notification to a network function in the home network, wherein the notification comprises an indication of the 10 first security key and an identification associated with the wireless device. Figure 4 to accompany Abstract

Description

METHODS AND APPARATUS FOR ENABLING END-TO-END DATA PROTECTION

Technical Field

Embodiments described herein relate to methods and apparatus for enabling end-to- end data protection between a wireless device and the home network. In particular, the methods and apparatus described herein allow for a stateless Authentication Server Function.

Backqround

Figure 1 illustrates an example of a 5G service based architecture (SBA) 100. The SBA 100 comprises different function entities referred to as Network Functions (NFs).

In this example, the SBA 100 comprises a Network Slice Selection Function (NSSF), a Network Exposure Function (NEF), a Network Repository Function (NRF), a Policy Control Function (PCF), a Unified Data Management (UDM) function, an Application Function (AF), an Authentication Server Function (AUSF), a Access and Mobility Management Function (AMF), a Session Management Function (SMF) and a User Plane Function (UPF). A User Equipment (UE) may then connect to this 5G core network via the Radio Access Network (RAN). It will be appreciated that not all possible NFs are depicted.

The SBA is therefore a system architecture in which the system functionality is achieved by a set of NFs providing services to other authorized NFs to access their services. Control Plane (CP) Network Functions in the 5G System architecture are based on SBA.

A NF service is one type of capability exposed by a NF (NF Service Producer) to other authorized NFs (NF Service Consumer) through a service-based interface (SBI). A NF service may support one or more NF service operation(s). A service- based interface represents how the set of services is provided or exposed by a given NF. This is the interface where the NF service operations are invoked, and it is based on HTTP/2 protocol. The Authentication Server Function (AUSF) and the Unified Data Management (UDM) function are key NFs within the 5GC SBA Framework that support primary authentication of users or wireless devices accessing the 5G core network. The AUSF acts as authentication server while the UDM acts as authentication repository and processing function (i.e. storing user credentials and generating Authentication and Key Agreement (AKA) authentication vectors).

Figure 2 illustrates an example of a primary authentication process between a wireless device 200 and the core network.

In step 201 the wireless device 200 initiates a non-Access Stratum (NAS) signaling procedure with the 5G core network, for example by transmitting the signaling to the AMF 210. The NAS signaling includes the UE id in the form of a Subscription Concealed Identifier (SUCI), in case of initial registration, or a temporal user identity (GUTI), in case of subsequent requests.

In step 202, the AMF 210 initiates a primary authentication procedure. For this, the AMF contacts the AUSF 220 using Nausf_UEAUthenticate_Request.

In step 203, the AUSF 220 contacts the UDM 230 to request a suitable AKA Authentication Vector.

In step 204, the UDM 230 generates a suitable AKA Authentication Vector according to the wireless device’s 200 subscription profile.

In step 205, the UDM 230 de-conceals the SUCI if needed and provides the SUPI together with the AV to the AUSF 220.

In step 206, the AUSF 220 executes the AKA procedure with the wireless device 200. As a result, the wireless device 200 and the AMF 210 agree on a first security key, Kausf, used to derive further security keys for NAS and AS protection.

In step 207, a second security key, Ksauf, is generated shared between the UE and the AUSF 220. The second security key, Ksauf, may be used in subsequent procedures invoked by UDM 230. The storage of this key in the UE and AUSF may be optional. In step 208, the AUSF 220 informs the UDM 230 about the result of the authentication procedure.

In step 209, the UDM 230 uses the result of the authentication procedure to improve Home Network control of authentication result, e.g. to bind the authentication status of the UE for the authorization of subsequent UE procedures with UDM.

To provide this functionality, the UDM 230 may use subscription data (including authentication data) that may be stored in a Unified Data Repository, UDR, in a wireless device context. In this case, the UDM may implement the application logic and may not require internal storage for storing information relating to the wireless devices. Several different UDMs may then serve the same wireless device in different transactions by retrieiving the appropriate information from the UDR.

Figure 3 illustrates a data storage architecture. In particular Figure 3 illustrates how multiple different UDMs, (UDM1 301 and UDM2 302) may communication with a UDR 300 to retrieve information relating to the wireless device, for example subscription data, policy data, structured data for exposure, and application data, over the Nudr interface.

Figure 3 also illustrates how the PCF 303 and NEF 304 are also possible NF consumers of Nudr data management services provided by the U DR 300.

In this example therefore, the use of the UDR 300 allows the UDRs 301 and 302 to be completely“stateless” (i.e. to not store information relating to the wireless device), where the "compute" resource is decoupled from the "storage" resource. All the data required for the business logic of the UDMs 301 and 302 (static subscription data and dynamic UE context information) is stored in the UDR 300.

However, in Figure 2, the AUSF 220 is not defined as consumer of the UDR in the 5G core network, mainly because the AUSF 220 receives AKA authentication vectors from UDM 230 but it does not require the handling of subscription data as such. The AUSF 220 has also very little requirements regarding user state handling as well. During the execution of the AKA procedure between the AUSF 220 and the wireless device 200 ( i.e. step step 206 in Figure 2), the exchange of multiple messages is involved. The same instance of the AUSF 220 needs to be used and it is required to keep some sort of transient wireless device context during the execution of this step. After successful or unsuccessful execution of the AKA procedure, the AUSF 220 can discard the transient wireless device context used for the execution of this step.

Flowever, the AUSF 220 may in some circumstances be required to maintain the wireless device context. For example, in circumstances where the AUSF is required to keep the Kausf for future use (this is optional in step 207 see figure 2), or after the AMF 210 has received subscription data for the wireless device 200 from the UDM 230, the AMF 210 may propagate wireless device tracing requirements to the AUSF 220 in subsequent authentication request and the AUSF 220 may be required to store the wireless device tracing requirements.

This may therefore require the AUSF 220 to store a wireless device context for the wireless device 200, making the AUSF 220 a stateful NF.

The need for the AUSF 220 to keep a state for the wireless device 200 presents the following problems:

The UDM 230 may be required to know which is the AUSF instance (as there may be multiple) that is storing the Kausf for a particular wireless device. In Figure 2, this is resolved by UDM 230 storing the AUSF ID received in step 8 of Figure 2.

Flowever, the AMF 210 does not currently store the AUSF ID in its internal wireless device context. Therefore, during execution of any subsequent primary authentication procedures, the AMF 210 (the same AMF or another AMF after intra 5GC Mobility procedure) may select another AUSF instance. This will result in the new AUSF instance generating and storing a new Kausf for the wireless device 200, which is different than the one stored in the AUSF 220 which then becomes obsolete. Eventually, there may be multiple AUSF instances storing multiple obsolete wireless device contexts for the same wireless device, each having obsolete Kausf keys. No method has been defined in 3GPP specifications to clean up these obsolete Kausf keys. In a similar way as for the Kausf, the AMF 210 may provide wireless device tracing requirements for a given wireless device to multiple AUSF instances, resulting in the same information being maintained and replicated multiple times.

Summary

According to some embodiments there is provided a method, in an authentication function, in a home network for enabling end-to-end data protection between a wireless device and the home network. The method comprises performing an authentication procedure with the wireless device to generate a first security key for use in end-to-end protection between the home network and the wireless device; and transmitting a notification to a network function in the home network, wherein the notification comprises an indication of the first security key and an identification associated with the wireless device.

According to some embodiments there is provided a method in a Unified Data Repository, UDR, in a home network for enabling end-to-end protection between a wireless device and the home network. The method comprises receiving a request to update a wireless device context in the UDR, wherein the wireless device context comprises a first security key and wherein the request comprises an indication of a second security key for use in end-to-end protection between the home network and a wireless device, and an identification associated with the wireless device; and updating, in the UDR, the wireless device context to replace the first security key with the second security key, wherein the wireless device context corresponds to the identification associated with the wireless device.

According to some embodiments there is provided a method in a Unified Data Management, UDM, function for enabling end-to-end protection between a wireless device and the home network. The method comprises receiving a notification from a first Authentication Server Function, AUSF, in the home network, wherein the notification comprises an indication of a first security key for use in end-to-end protection between the home network and the wireless device and an identification associated with the wireless device; and transmitting a request to a Unified Data Repository, UDR, to update a wireless device context with the first security key, wherein the wireless device context corresponds to the identification associated with the wireless device.

According to some embodiments there is provided an authentication function, in a home network for enabling end-to-end data protection between a wireless device and the home network. The AUSF comprises processing circuitry configured to perform an authentication procedure with the wireless device to generate a first security key for use in end-to-end protection between the home network and the wireless device; and transmit a notification to a network function in the home network, wherein the notification comprises an indication of the first security key and an identification associated with the wireless device.

According to some embodiments there is provided a Unified Data Repository, UDR, in a home network for enabling end-to-end protection between a wireless device and the home network. The UDR comprises processing circuitry configured to: receive a request to update a wireless device context in the UDR, wherein the wireless device context comprises a first security key and wherein the request comprises an indication of a second security key for use in end-to-end protection between the home network and a wireless device, and an identification associated with the wireless device; and update, in the UDR, the wireless device context to replace the first security key with the second security key, wherein the wireless device context corresponds to the identification associated with the wireless device.

According to some embodiments there is provided a Unified Data Management, UDM, function for enabling end-to-end protection between a wireless device and the home network. The UDM function comprises processing circuitry configured to: receive a notification from a first Authentication Server Function, AUSF, in the home network, wherein the notification comprises an indication of a first security key for use in end-to- end protection between the home network and the wireless device and an identification associated with the wireless device; and transmit a request to a Unified Data Repository, UDR, to update, with a wireless device context with the first security key, wherein the wireless device context corresponds to the identification associated with the wireless device. Brief Description of the Drawings

For a better understanding of the embodiments, and to show how they may be put into effect, reference will now be made, by way of example only, to the accompanying drawings, in which:-

Figure 1 illustrates an example of a 5G service based architecture (SBA);

Figure 2 illustrates an example of a primary authentication process between a wireless device and the core network;

Figure 3 illustrates a data storage architecture;

Figure 4 illustrates an example signalling diagram for enabling end-to-end data protection between a wireless device and the home network;

Figure 5 illustrates an example signalling diagram for enabling end-to-end data protection between a wireless device and the home network;

Figure 6 illustrates a method in an Authentication Server Function, AUSF, in a home network for enabling end-to-end data protection between a wireless device and the home network;

Figure 7 illustrates a method in a Unified Data Repository, UDR, in a home network for enabling end-to-end protection between a wireless device and the home network;

Figure 8 illustrates a method in a Unified Data Management function, UDM, in a home network for enabling end-to-end protection between a wireless device and the home network;

Figure 9 illustrates an Authentication Server Function (AUSF) comprising processing circuitry (or logic);

Figure 10 illustrates a Unified Data Repository, (UDR) comprising processing circuitry (or logic); Figure 1 1 illustrates a Unified Data Management function, (UDM) comprising processing circuitry (or logic).

Description

Generally, all terms used herein are to be interpreted according to their ordinary meaning in the relevant technical field, unless a different meaning is clearly given and/or is implied from the context in which it is used. All references to a/an/the element, apparatus, component, means, step, etc. are to be interpreted openly ,as referring to at least one instance of the element, apparatus, component, means, step, etc., unless explicitly stated otherwise. The steps of any methods disclosed herein do not have to be performed in the exact order disclosed, unless a step is explicitly described as following or preceding another step and/or where it is implicit that a step must follow or precede another step. Any feature of any of the embodiments disclosed herein may be applied to any other embodiment, wherever appropriate. Likewise, any advantage of any of the embodiments may apply to any other embodiments, and vice versa. Other objectives, features and advantages of the enclosed embodiments will be apparent from the following description.

Some of the embodiments contemplated herein will now be described more fully with reference to the accompanying drawings. Other embodiments, however, are contained within the scope of the subject matter disclosed herein, the disclosed subject matter should not be construed as limited to only the embodiments set forth herein; rather, these embodiments are provided by way of example to convey the scope of the subject matter to those skilled in the art.

Embodiments described herein provide a methods and apparatus in a service based architecture to support a stateless Authentication Server Function (AUSF). In particular methods are provided to make use of the Unified Data Repository (UDR) to store wireless device context information. The wireless device context information may then be accessed by a Unified data Management (UDM) function or the AUSF so that subsequent authentication related procedures may make use of any available AUSF instance. The wireless device context information used by the AUSF can be kept up to date in an optimal and effective manner as it is centralized in the UDR.

Wireless device context information may comprise the following fields, for example:

Some advantages of providing the AUSF as a stateless function are that stateless applications are normally easier to implement (as there is no state handling required), easier to be addressed (as there is no stickiness from client point of view so future interactions may use a different instance), and they have higher network resilience (as failure in one instance is not a problem as any other available instance will be able to take over).

Figure 4 illustrates an example signalling diagram for enabling end-to-end data protection between a wireless device 420 and the home network 400. In this example, existing service based architecture and interfaces are utilised.

In step 401 , the wireless device 420 and a first AUSF 430 perform an authentication procedure to generate a first security key, Kausf#1 , for use in end-to-end protection between the home network 400 and the wireless device 420. For example step 401 may comprise a procedure similar to the procedure outlined in step 201 to 207 of Figure 2 described above.

The Kausf#1 may be defined as shared Key between wireless device and the AUSF 430 in the home network derived during primary authentication in the 5G core. Kausf#1 may be used to protect information exchanged between the wireless device and the home network via control plane signalling (e.g. Steering of Roaming information). In step 402, the first AUSF 430 transmits a notification, Nudm UEAuth ResultConf, to a UDM function 440 in the home network 400. The notification Nudm UEAuth ResultConf, comprises an indication of the first security key, Kausf#1 and an identification associated with the wireless device 420. The identification associated with the wireless device 420 may comprise a Subscription Concealed Identifier (SUCI) and/or a Subscription Permanent Identifier (SUPI), or any other suitable identifier used to identify the wireless device 420 or a subscription of (a user of) the wireless device 401 .

The notification, Nudm UEAuth ResultConf, may also comprise an indication of the result of the primary authentication procedure performed in step 401. For example, in some circumstances the UDM function 440 may only allow completion of the registration of the wireless device 420 if the result of the authentication is that the authentication has been properly completed.

In step 403, the UDM 440 transmits a request, Nudr DM Update, to a Unified Data Repository, UDR 450, to request that the UDR update with the first security key a stored wireless device context corresponding to the identification associated with the wireless device. The UDR 450 may store a plurality of wireless device contexts each being associated with different identifications that are in turn associated with the respective wireless devices. The request Nudr DM Update may therefore comprise the identification associated with the wireless device (for example the SUPI and/or SUCI), the authentication result, and the first security key, Kausf#1 .

The UDR 450 may then update the stored wireless device context that corresponds to the identification associated with the wireless device with the first security key Kausf#1. In some examples, the UDR 450 may also update the stored wireless device context with the authentication result.

In step 404, a subsequent primary authentication procedure takes place. In this example, the wireless device 420 and a second AUSF 460 perform an authentication procedure to generate a second security key, Kausf#2, for use in end-to-end protection between the home network 400 and the wireless device 420. For example step 404 may comprise a procedure similar to the procedure outlined in step 201 to 207 of Figure 2 described above. In step 405, the second AUSF 460 transmits a notification, Nudm UEAuth ResultConf, to the UDM function 440 in the home network 400. It will be appreciated that the notification may be transmitted to a different UDM instance in the home network. The notification Nudm UEAuth ResultConf, comprises an indication of the second security key, Kausf#2 and an identification associated with the wireless device 420. The identification associated with the wireless device 420 may comprise a Subscription Concealed Identifier (SUCI) or a Subscription Permanent Identifier (SUPI), or any other suitable identifier used to identify the wireless device 420 or a subscription of (a user of) the wireless device 401 .

The notification, Nudm UEAuth ResultConf, may also comprise an indication of the result of the primary authentication procedure performed in step 404. For example, in some circumstances, the UDM function 440 may only allow completion of the registration of the wireless device 420 if the result of the authentication is that the authentication has been properly completed.

In step 406, the UDM 440 transmits a request, Nudr DM Update, to a Unified Data Repository, UDR 450, to request that the UDR update with the second security key a stored wireless device context corresponding to the identification associated with the wireless device. The request Nudr DM Update may therefore comprise the identification associated with the wireless device (for example the SUPI and/or SUCI) the authentication result, and the second security key, Kausf#1.

The UDR 450, due to the procedure in step 403, already has a wireless device context stored associated with the identification received in the request in step 406. In this case therefore, the UDR 450 may, in response to the request in step 406, update the wireless device context corresponding to the identification associated with the wireless device, to replace the first security key Kausf#1 with the second security key Kausf#2. In some examples, the UDR 450 will also update the wireless device context with the authentication result received as part of the request in step 406.

It should be noted that the first AUSF 430 and second AUSF 460 do not need to send their AUSF ID to the UDM 440 and the UDM 440 does not need to store the AUSF ID in UDR 450 anymore since the purpose of the procedure is to make the AUSF stateless. Therefore, in subsequent procedures where the UDM 440 needs to make use of AUSF services that require access to the wireless device context information, the UDM 440 may select any available AUSF instance (e.g. the first AUSF 430 or the second AUSF 460) regardless of whether the wireless device 420 was last authenticated in different AUSF instance. By storing the wireless device context information and the security key generated by the first and second AUSF in the UDR 450, the first AUSF 430 and second AUSF 460 can release any wireless device context information from their internal storage freeing resources for other tasks.

In step 407, a subsequent wireless device procedure is initiated in which there is a requirement for the UDM 440 to authenticate to the wireless device. In this example, the UDM 440 is given as an example for this step, however, it will be appreciated that any instance of UDM may need to initiate a procedure with the wireless device, and therefore a second UDM may perform step 407.

The main purpose of the Kausf security key is to enable e2e protection between the wireless device and the home network. For example, the Kausf may be used to protect the delivery of information from the UDM 440 to the wireless device 420 via a Control Plane mechanism. An example of such information or data is Steering of Roaming (SoR) information for which the receiving AUSF instance may generate a MAC based on the Kausf key. Then the UDM 440 provides the SoR information including the MAC provided by the AUSF.

In step 408, responsive to the requirement to authenticate the wireless device (for example to transmit SoR information to the wireless device), the UDM 440 transmits a security key request, Nudr DM Query, to the UDR 450, wherein the security key request, Nudr DM Query, indicates the identification associated with the wireless device (for example, the SUCI/SUPI).

The UDR 450 receives the security key request and selects the security key stored with the identification indicated in the security key request. In this example, as the subsequent primary authentication procedure took place in step 404, and in step 405 to 407 the security key stored in the wireless device context in the UDR was updated from the first security key Kausf#1 to the second security key Kausf#2, the UDR 450 will retrieve the second security key Kausf#2 from storage and will transmit the second security key Kausf#2 to the UDM 440. It will be appreciated that the UDR 450 will retrieve from storage the security key that was generated in the latest primary authentication procedure associated with the identification indicated in the received security key request.

In step 409, the UDM 440 transmits a request to an AUSF instance to authenticate the wireless device, wherein the request comprises the identification associated with the wireless device and the second security key. In this example the request, Nsauf_SoRProtection_ProtectReq is sent to the first AUSF 430. It will however be appreciated that any AUSF instance may be selected at this stage as the request itself comprises the necessary information (e.g. the second security key Kausf#2) for the selected AUSF instance to perform the protection. The AUSF instance selected may be the same as the AUSF instance that generated the last generated security key, or may be a different AUSF instance.

In step 410, the first AUSF 430 performs the authentication (in this example data protection) using the second security key Kausf#2 received in step 409. For example, the first AUSF 430 may generate a Message Authentication Code (MAC) based on the second security key Kausf#2. In some examples therefore, a security key for a particular wireless device used by an AUSF instance to perform the data protection may be the same as a security key generated by that AUSF instance for the particular wireless device. In some examples, however, a security key for a particular wireless device used by an AUSF instance to perform the data protection may be the different from a security key generated by that AUSF instance for that particular wireless device.

In step 41 1 , the first AUSF 430 may transmit the MAC to the UDM 440 for use in transmitting the data to the wireless device 420.

Figure 5 illustrates an example signalling diagram for enabling end-to-end data protection between a wireless device 420 and the home network 400. In particular, this example updates the existing architecture in the 5G core network by enabling a direct access for the AUSF to the UDR.

In step 501 , the wireless device 420 and a first AUSF 430 perform an authentication procedure to generate a first security key, Kausf#1 , for use in end-to-end protection between the home network 400 and the wireless device 420. For example step 501 may comprise a procedure similar to the procedure outlined in step 201 to 207 of Figure 2 described above. In step 502, the first AUSF 430 transmits a request, Nudr DM Update, to a Unified Data Repository, UDR 450, to request that the UDR 450 update a wireless device context corresponding to the identification associated with the first wireless device with the first security key Kausf. The request Nudr DM Update may therefore comprise the identification associated with the wireless device (for example the SUPI and/or SUCI), the authentication result, and the first security key, Kausf#1.

The UDR 450 may then update the wireless device context that corresponds to the identification associated with the wireless device with the first security key Kausf#1 . In some examples, the UDR 450 may also update the stored wireless device context with the authentication result.

In step 503, a subsequent primary authentication procedure takes place. In this example, the wireless device 420 and a second AUSF 460 perform an authentication procedure to generate a second security key, Kausf#2, for use in end-to-end protection between the home network 400 and the wireless device 420. For example step 503 may comprise a procedure similar to the procedure outlined in step 201 to 207 of Figure 2 described above.

In step 504, the first AUSF 430 transmits a request, Nudr DM Update, to a Unified Data Repository, UDR 450, to request that the UDR 540 update a stored wireless device context corresponding to the identification associated with the first wireless device with the second security key, Kausf#2. The request Nudr DM Update may therefore comprise the identification associated with the wireless device (for example the SUPI and/or SUCI), the authentication result, and the second security key, Kausf#1 .

The UDR 450, due to the procedure in step 502, already has a wireless device context stored that is associated with the identification received in the request in step 504. In this case therefore, the UDR 450 may, in response to the request in step 504, update the wireless device context corresponding to the identification associated with the wireless device, to replace the first security key Kausf#1 with the second security key Kausf#2. In some examples, the UDR 450 will also update the wireless device context with the authentication result received as part of the request in step 504. It should be noted that the first AUSF 430 and second AUSF 460 do not need to send their AUSF ID to the UDM 440 and the UDM 440 does not need to store the AUSF ID in UDR 450 anymore since the purpose of the procedure is to make the AUSF stateless. Therefore, in subsequent procedures where the UDM 440 needs to make use of AUSF services that require access to the wireless device context information, the UDM 440 may select any available AUSF instance (e.g. the first AUSF 430 or the second AUSF 460) regardless of whether the wireless device 420 was last authenticated in different AUSF instance. By storing the wireless device context information and the security key generated by the first and second AUSF in the UDR 450, the first AUSF 430 and second AUSF 460 can release any wireless device context information from their internal storage freeing resources for other tasks.

In step 505, a subsequent wireless device procedure is initiated in which there is a requirement for the UDM 440 to authenticate the wireless device. In this example, the UDM 440 is given as an example for this step, however, it will be appreciated that any instance of UDM may need to initiate a procedure with the wireless device, and therefore a second UDM may perform step 505.

In step 506, the UDM 440 retrieves information related to the authentication status of the user from the UDR 450. For example, the subsequent wireless device procedure initiated in step 505 may only be allowed to continue if the wireless device is properly authenticated.

In step 507, responsive to the requirement to authenticate the wireless device (in this example to deliver protected data), the UDM 440 transmits a request, Nsauf_SoRProtection_ProtectReq, to an AUSF instance to authenticate the wireless device, wherein the request comprises the identification associated with the wireless device. In this example, the request, Nsauf_SoRProtection_ProtectReq, is transmitted to the first AUSF 430. However, as the AUSF instances are stateless, any AUSF instance may be selected in this step as the selected AUSF instance is able to retrieve the necessary information (e.g. the latest security key for the wireless device) from the UDR 450. The AUSF instance selected may be the same as the AUSF instance that generated the last generated security key, or may be a different AUSF instance.

In step 508, the first AUSF instance transmits a security key request, Nudr DM Query, to the UDR 450, wherein the security key request, Nudr DM Query, indicates the identification associated with the wireless device (for example, the SUCI/SUPI) that was received in step 507.

The UDR 450 receives the security key request and selects the security key stored with the identification indicated in the security key request. In this example, as the subsequent primary authentication procedure took place in step 503, and in step 504 the security key stored in the wireless device context in the UDR 450 was updated from the first security key Kausf#1 to the second security key Kausf#2, the UDR 450 will retrieve the second security key Kausf#2 from storage and will transmit the second security key Kausf#2 to the UDM 440. It will be appreciated that the UDR 450 will retrieve from storage whatever key is associated with the identification indicated in the received security key request. In some examples therefore, a security key for a particular wireless device retrieved by an AUSF instance from the UDR may be the same as a security key generated by that AUSF instance for the particular wireless device, in other words Kausf#1 and Kausf#2 may be the same. In some examples, however, a security key for a particular wireless device retrieved by an AUSF instance from the UDR may be the different from a security key generated by that AUSF instance for that particular wireless device.

In step 509, the first AUSF 430 performs the data protection using the second security key Kausf#2 received in step 409. For example, the first AUSF 430 may generate a Message Authentication Code (MAC) based on the second security key Kausf#2.

In step 510, the first AUSF 430 may transmit the MAC to the UDM 440 for use in transmitting the data to the wireless device 420.

In this example, the use of direct access from the first AUSF 430 or the second AUSF 460 to the UDR 450 also facilitates the first and/or second AUSF to retrieve trace requirements relevant for the wireless device directly from the UDR 450 without the information needing to be propagated from the UDR 450 to the AUSF instance via the UDM 440 and the AMF 470. For example, an AUSF instance may be configured to transmit a request to the UDR to retrieve tracing information for the wireless device.

In some examples it will be appreciated that the UDM 440 may not be stateless and may locally store the Kausf key. In this example, the UDM 440 interactions with the UDR 450 are not required.

Figure 6 illustrates a method in an authentication function, for example an Authentication Server Function (AUSF), in a home network for enabling end-to-end data protection between a wireless device and the home network. The AUSF may comprise the first AUSF 430 or the second AUSF 460 as described above.

In step 601 , the AUSF performs an authentication procedure with the wireless device to generate a first security key (e.g. Kausf#1 or Kausf#2) for use in end-to-end protection between the home network and the wireless device.

In step 602, the AUSF transmits a notification to a network function in the home network, wherein the notification comprises an indication of the first security key and an identification associated with the wireless device (e.g. SUCI and/or SUPI).

In some examples, the network function comprises a first Unified Data Management, UDM, function, for example the UDM 440 as illustrated in Figure 4. In this example, the notification may comprise the notification Nudm UEAuth ResultConf as described with reference to Figure 4.

In some examples, the network function comprises a Unified Data Repository (UDR), for example the UDR 450 as illustrated in Figure 5. In these examples, the notification may comprise the request Nudr DM Updated as described with reference to Figure 5.

Figure 7 illustrates a method in a Unified Data Repository, UDR, in a home network for enabling end-to-end protection between a wireless device and the home network. The UDR may comprise the UDR 450 illustrated in Figures 4 and 5. In step 701 , the UDR receives a request to update a wireless device context in the UDR. The wireless device context comprises a first security key (e.g. Kausf#1 ). The request comprises an indication of a second security key (e.g. Kausf#2) for use in end- to-end protection between the home network and a wireless device, and an identification associated with the wireless device (e.g. SUCI and/or SUPI).

In some examples, the request in step 701 is received from a first Unified Data Management, UDM, function. For example, the request may comprise the request Nudr DM Update transmitted by the UDM 440 in step 406 of Figure 4.

In some examples, the request in step 701 is received from an Authentication Server Function, AUSF. For example, the request may comprise the request Nudr DM Update transmitted by the second AUSF 460 in step 504 of Figure 5.

In step 702, the UDR updates, in the UDR, the wireless device context to replace the first security key (e.g. Kausf#1 ) with the second security key (e.g. Kausf#2), wherein the wireless device context corresponds to the identification associated with the wireless device in the UDR.

Figure 8 illustrates a Unified Data Management, UDM, function for enabling end-to-end protection between a wireless device and the home network. The UDM may comprise the UDM 440 illustrated in Figures 4 and 5.

In step 801 , the UDM receives a notification from a first Authentication Server Function, AUSF, in the home network, wherein the notification comprises an indication of a first security key (e.g. Kausf#1 ) for use in end-to-end protection between the home network and the wireless device and an identification associated with the wireless device. For example, the notification may comprise the notification Nudm UEAuth ResultConf illustrated in Figure 4.

In step 802, the UDM transmits a request to a Unified Data Repository, UDR, to update, a wireless device context with the first security key (e.g. Kausf#1 ), wherein the wireless device context corresponds to the identification associated with the wireless device. For example, the request may comprise the Nudr DM Update in steps 403 and 406 of Figure 4. Figure 9 illustrates an authentication function 900 comprising processing circuitry (or logic) 901 . The authentication function 900 may comprise an Authentication Server Function (AUSF) or any other suitable authentication function. The processing circuitry 901 controls the operation of the AUSF 900 and can implement the method described herein in relation to an AUSF 900. The processing circuitry 901 can comprise one or more processors, processing units, multi-core processors or modules that are configured or programmed to control the AUSF 900 in the manner described herein. In particular implementations, the processing circuitry 901 can comprise a plurality of software and/or hardware modules that are each configured to perform, or are for performing, individual or multiple steps of the method described herein in relation to the AUSF 900.

Briefly, the processing circuitry 901 of the AUSF 900 is configured to perform an authentication procedure with the wireless device to generate a first security key (e.g. Kausf#1 ) for use in end-to-end protection between the home network and the wireless device; and transmit a notification to a network function in the home network, wherein the notification comprises an indication of the first security key (e.g. Kausf#1 ) and an identification associated with the wireless device.

In some embodiments, the AUSF 900 may optionally comprise a communications interface 902. The communications interface 902 of the AUSF 900 can be for use in communicating with other nodes, such as other virtual nodes. For example, the communications interface 902 of the AUSF 900 can be configured to transmit to and/or receive from other nodes requests, resources, information, data, signals, or similar. The processing circuitry 901 of the AUSF 900 may be configured to control the communications interface 902 of the AUSF 900 to transmit to and/or receive from other nodes requests, resources, information, data, signals, or similar.

Optionally, the AUSF 900 may comprise a memory 903. In some embodiments, the memory 903 of the AUSF 900 can be configured to store program code that can be executed by the processing circuitry 901 of the AUSF 900 to perform the method described herein in relation to the AUSF 900. Alternatively or in addition, the memory 903 of the AUSF 900, can be configured to store any requests, resources, information, data, signals, or similar that are described herein. The processing circuitry 901 of the AUSF 900 may be configured to control the memory 903 of the AUSF 900 to store any requests, resources, information, data, signals, or similar that are described herein. Figure 10 illustrates a Unified Data Repository (UDR) 1000 comprising processing circuitry (or logic) 1001 . The processing circuitry 1001 controls the operation of the UDR 1000 and can implement the method described herein in relation to an UDR 1000. The processing circuitry 1001 can comprise one or more processors, processing units, multi-core processors or modules that are configured or programmed to control the UDR 1000 in the manner described herein. In particular implementations, the processing circuitry 1001 can comprise a plurality of software and/or hardware modules that are each configured to perform, or are for performing, individual or multiple steps of the method described herein in relation to the UDR 1000.

Briefly, the processing circuitry 1001 of the UDR 1000 is configured to receive a request to update a wireless device context in the UDR, wherein the wireless device context comprises a first security key (e.g. Kausf#1 ) and wherein the request comprises an indication of a second security key (e.g. Kausf#2) for use in end-to-end protection between the home network and a wireless device, and an identification associated with the wireless device; and update, in the UDR, the wireless device context to replace the first security key (e.g. Kausf#1 ) with the second security key (e.g. Kausf#2), wherein the wireless device context corresponds to the identification associated with the wireless device.

In some embodiments, the UDR 1000 may optionally comprise a communications interface 1002. The communications interface 1002 of the UDR 1000 can be for use in communicating with other nodes, such as other virtual nodes. For example, the communications interface 1002 of the UDR 1000 can be configured to transmit to and/or receive from other nodes requests, resources, information, data, signals, or similar. The processing circuitry 1001 of the UDR 1000 may be configured to control the communications interface 1002 of the UDR 1000 to transmit to and/or receive from other nodes requests, resources, information, data, signals, or similar.

Optionally, the UDR 1000 may comprise a memory 1003. In some embodiments, the memory 1003 of the UDR 1000 can be configured to store program code that can be executed by the processing circuitry 1001 of the UDR 1000 to perform the method described herein in relation to the UDR 1000. Alternatively or in addition, the memory 1003 of the UDR 1000, can be configured to store any requests, resources, information, data, signals, or similar that are described herein. The processing circuitry 1001 of the UDR 1000 may be configured to control the memory 1003 of the UDR 1000 to store any requests, resources, information, data, signals, or similar that are described herein

Figure 11 illustrates a Unified Data Management Function (UDM) 1 100 comprising processing circuitry (or logic) 1 101 . The processing circuitry 1 101 controls the operation of the UDM 1 100 and can implement the method described herein in relation to an UDM 1 100. The processing circuitry 1 101 can comprise one or more processors, processing units, multi-core processors or modules that are configured or programmed to control the UDM 1 100 in the manner described herein. In particular implementations, the processing circuitry 1 101 can comprise a plurality of software and/or hardware modules that are each configured to perform, or are for performing, individual or multiple steps of the method described herein in relation to the UDM 1 100.

Briefly, the processing circuitry 1 101 of the UDM 1 100 is configured to: receive a notification from a first Authentication Server Function, AUSF, in the home network, wherein the notification comprises an indication of a first security key (e.g. Kausf#1 ) for use in end-to-end protection between the home network and the wireless device and an identification associated with the wireless device; and transmit a request to a Unified Data Repository, UDR, to update a wireless device context with the first security key (e.g. Kausf#1 ), wherein the wireless device context corresponds to the identification associated with the wireless device.

In some embodiments, the UDM 1 100 may optionally comprise a communications interface 1 102. The communications interface 1 102 of the UDM 1 100 can be for use in communicating with other nodes, such as other virtual nodes. For example, the communications interface 1 102 of the UDM 1 100 can be configured to transmit to and/or receive from other nodes requests, resources, information, data, signals, or similar. The processing circuitry 1 101 of the UDM 1 100 may be configured to control the communications interface 1 102 of the UDM 1 100 to transmit to and/or receive from other nodes requests, resources, information, data, signals, or similar.

Optionally, the UDM 1 100 may comprise a memory 1 103. In some embodiments, the memory 1 103 of the UDM 1 100 can be configured to store program code that can be executed by the processing circuitry 1 101 of the UDM 1 100 to perform the method described herein in relation to the UDM 1 100. Alternatively or in addition, the memory 1 103 of the UDM 1 100, can be configured to store any requests, resources, information, data, signals, or similar that are described herein. The processing circuitry 1 101 of the UDM 1 100 may be configured to control the memory 1 103 of the UDM 1 100 to store any requests, resources, information, data, signals, or similar that are described herein.

There is therefore provided methods and apparatus for enabling end-to-end protection between a wireless device and the home network, whilst also allowing for a stateless AUSF.

It should be noted that the above-mentioned embodiments illustrate rather than limit the invention, and that those skilled in the art will be able to design many alternative embodiments without departing from the scope of the appended claims. The word “comprising” does not exclude the presence of elements or steps other than those listed in a claim,“a” or“an” does not exclude a plurality, and a single processor or other unit may fulfil the functions of several units recited in the claims. Any reference signs in the claims shall not be construed so as to limit their scope.

Claims

1. A method, in an authentication function (430, 460), in a home network for enabling end-to-end data protection between a wireless device and the home network, the method comprising:

performing an authentication procedure with the wireless device to generate a first security key for use in end-to-end protection between the home network and the wireless device (601 ); and

transmitting a notification to a network function in the home network, wherein the notification comprises an indication of the first security key and an identification associated with the wireless device (602).

2. The method as claimed in claim 1 wherein the network function comprises a first Unified Data Management, UDM, function (440).

3. The method as claimed in claim 1 wherein the network function comprises a Unified Data Repository, UDR, (450).

4. The method as claimed in claim 3 wherein the notification (502) comprises a request to update a wireless device context in the UDR with the first security key, wherein the wireless device context corresponds to the identification associated with the wireless device.

5. The method as claimed in any preceding claim further comprising:

receiving a request (507) from a second Unified Data Management, UDM, function to authenticate the wireless device, wherein the request comprises an identification associated with the wireless device;

transmitting a security key request (508) to a Unified Data Repository, UDR, to retrieve a second security key associated with the wireless device in the UDR, wherein the security key request comprises the identification associated with the wireless device;

receiving the second security key from the UDR; and

authenticating the wireless device using the second security key.

6. The method as claimed in any one of claims 1 to 4 further comprises: receiving a request from a second Unified Data Management, UDM, function to authenticate to the wireless device, wherein the request comprises an identification associated with the wireless device and a second security key; and

authenticating the wireless device using the second security key.

7. The method as claimed in claim 5 or 6 wherein the second security key is the same as the first security key.

8. The method as claimed in claim 5 or 6 wherein the second security key is different from the first security key.

9. The method as claimed in claim 3 further comprising:

transmitting a request to the UDR to retrieve tracing information for the wireless device.

10. A method in a Unified Data Repository, UDR (450), in a home network for enabling end-to-end protection between a wireless device and the home network, the method comprising:

receiving a request to update a wireless device context in the UDR, wherein the wireless device context comprises a first security key and wherein the request comprises an indication of a second security key for use in end-to-end protection between the home network and a wireless device, and an identification associated with the wireless device (701 ); and

updating, in the UDR, the wireless device context to replace the first security key with the second security key, wherein the wireless device context corresponds to the identification associated with the wireless device (702).

1 1 . The method as claimed in claim 10 wherein the request is received from a first Unified Data Management, UDM, function (440).

12. The method as claimed in claim 10 wherein the request is received from an Authentication Server Function, AUSF (430).

13. The method as claimed in any one of claims 10 to 12 further comprising: receiving a security key request (409, 507) from a network function in the home network wherein the security key request indicates the identification associated with the wireless device; and

selecting the second security key associated with the identification associated with the wireless device in the wireless device context; and

transmitting the second security key to the network function.

14. The method as claimed in claim 13 wherein the network function comprises an Authentication Server Function, AUSF.

15. The method as claimed in claim 13 wherein the network function comprises a second Unified Data Management, UDM, function (440).

16. A method in a Unified Data Management, UDM, function (440) for enabling end- to-end protection between a wireless device and the home network, the method comprising:

receiving a notification from a first Authentication Server Function, AUSF, in the home network, wherein the notification comprises an indication of a first security key for use in end-to-end protection between the home network and the wireless device and an identification associated with the wireless device (801 ); and

transmitting a request to a Unified Data Repository, UDR, to update a wireless device context with the first security key, wherein the wireless device context corresponds to the identification associated with the wireless device (802).

17. The method as claimed in claim 16 further comprising :

responsive to a requirement to authenticate to the wireless device, transmitting (408) a security key request to the UDR, wherein the security key request indicates the identification associated with the wireless device;

receiving a second security key from the UDR; and

transmitting (409) a request to a second Authentication Server Function, AUSF, to authenticate to the wireless device, wherein the request comprises an identification associated with the wireless device and the second security key.

18. The method as claimed in claim 17 wherein the first AUSF and the second AUSF are the same.

19. The method as claimed in claim 17 wherein the first AUSF and the second AUSF are different.

20. The method as claimed in any one of claims 17 to 19 wherein the first security key and the second security key are the same.

21 . The method as claimed in any one of claims 17 to 19 wherein the first security key and the second security key are different.

22. An authentication function (430, 460), in a home network for enabling end-to-end data protection between a wireless device (420) and the home network, the AUSF comprising processing circuitry configured to:

perform an authentication procedure with the wireless device to generate a first security key for use in end-to-end protection between the home network and the wireless device; and

transmit a notification to a network function in the home network, wherein the notification comprises an indication of the first security key and an identification associated with the wireless device.

23. The authentication function as claimed in claim 22 wherein the network function comprises a first Unified Data Management, UDM, function (440).

24. The authentication function as claimed in claim 22 wherein the network function comprises a Unified Data Repository, UDR (450).

25. The authentication function as claimed in claim 24 wherein the notification comprises a request to update in the UDR a wireless device context with the first security key, wherein the wireless device context corresponds to the identification associated with the wireless device.

26. The authentication function as claimed in any one of claims 22 to 25 wherein the processing circuitry is further configured to:

receive a request from a second Unified Data Management, UDM, function to authenticate to the wireless device, wherein the request comprises an identification associated with the wireless device; transmit a security key request to a Unified Data Repository, UDR, to retrieve a second security key associated with the wireless device in the UDR, wherein the security key request comprises the identification associated with the wireless device; receive the second security key from the UDR; and

authenticate the wireless device using the second security key.

27. The authentication function as claimed in any one of claims 22 to 25 wherein the processing circuitry is further configured to:

receive a request from a second Unified Data Management, UDM, function to authenticate to the wireless device, wherein the request comprises an identification associated with the wireless device and a second security key; and

authenticate the wireless device using the second security key.

28. The authentication function as claimed in claim 26 or 27 wherein the second security key is the same as the first security key.

29. The authentication function as claimed in claim 26 or 27 wherein the second security key is different from the first security key.

30. The authentication function as claimed in claim 24 further comprising:

31 . A Unified Data Repository, UDR, (450) in a home network for enabling end-to- end protection between a wireless device (420) and the home network (400), the UDR comprising processing circuitry configured to:

receive a request to update a wireless device context in the UDR, wherein the wireless device context comprises a first security key and wherein the request comprises an indication of a second security key for use in end-to-end protection between the home network and a wireless device, and an identification associated with the wireless device; and

update, in the UDR, the wireless device context to replace the first security key with the second security key, wherein the wireless device context corresponds to the identification associated with the wireless device.

32. The UDR as claimed in claim 31 wherein the request is received from a first Unified Data Management, UDM, function (440).

33. The UDR as claimed in claim 31 wherein the request is received from an Authentication Server Function, AUSF (430, 460).

34. The UDR as claimed in any one of claims 31 to 33 wherein the processing circuitry is further configured to:

receive a security key request from a network function in the home network wherein the security key request indicates the identification associated with the wireless device; and

select the second security key associated with the identification associated with the wireless device in the wireless device context; and

transmit the second security key to the network function.

35. The UDR as claimed in claim 34 wherein the network function comprises an Authentication Server Function, AUSF (430, 460).

36. The UDR as claimed in claim 34 wherein the network function comprises a second Unified Data Management, UDM, function.

37. A Unified Data Management, UDM, function (440) for enabling end-to-end protection between a wireless device (420) and the home network (400), the UDM function comprising processing circuitry configured to:

receive a notification from a first Authentication Server Function, AUSF, (430, 460) in the home network, wherein the notification comprises an indication of a first security key for use in end-to-end protection between the home network and the wireless device and an identification associated with the wireless device; and

transmit a request to a Unified Data Repository, UDR, (450) to update, with a wireless device context with the first security key, wherein the wireless device context corresponds to the identification associated with the wireless device.

38. The UDM function as claimed in claim 37 wherein the processing circuitry is further configured to: responsive to a requirement to authenticate to the wireless device, transmit a security key request to the UDR, wherein the security key request indicates the identification associated with the wireless device;

receive a second security key from the UDR; and

transmit a request to a second Authentication Server Function, AUSF, to authenticate to the wireless device, wherein the request comprises an identification associated with the wireless device and the second security key.

39. The UDM function as claimed in claim 38 wherein the first AUSF and the second AUSF are the same.

40. The UDM function as claimed in claim 38 wherein the first AUSF and the second AUSF are different.

41 . The UDM function as claimed in any one of claims 38 to 40 wherein the first security key and the second security key are the same.

42. The UDM function as claimed in any one of claims 38 to 40 wherein the first security key and the second security key are different.