User authentication and authorisation in a communications system

USER AUTHENTICATION AND AUTHORISATION IN A COMMUNICATIONS SYSTEM

The present invention relates to user authentication and authorization in a communication system, and more particularly, although not essential, to a method and apparatus in which a user is authenticated and authorized for a network application technology of a communication system.

Existing second-generation cellular radio communication systems, such as GSM, are in the process of being added and, to some extent, being replaced by third-generation systems. These include the 3G system known as Universal Mobile Telecommunications System (UMTS). Security is a key element of the UMTS standard and is not dependent on second-generation system security, while at the same time ensuring compatibility with GSM, facilitating GSM to UMTS migration and facilitating handover between GSM and UMTS access networks. The design of authentication and key agreement (AKA) for UMTS (3G TS 33.102) is intended to satisfy at least the objectives of the subscriber being authenticated to the access network and securing user data over the wireless link. .

The AKA protocol involves three communication parties: the Authentication Center (AuC) of the user's home environment, the Visitor Location Register (VLR) of the user's Serving Network (SN) and his or her UMTS Subscriber Identity Module (USIM). The user himself represented by The security key is shared by AuC and USIM. Upon receipt of the authentication data request by the HE, the AuC generates an array of (n) authentication vectors. This arrangement is then sent to the SN and is good for n authentication attempts by the user. The SN selects the next vector in the array and sends any component of the vector to the USIM. This allows the USIM to verify the SN, compute the session key, and generate a response. The latter is returned as an SN that compares the response with the expected response contained in the selected vector. If they match, the SN assumes that the authentication exchange has completed successfully. The session keys established thereafter are transmitted by the USIM and transmitted by the VLR to the Serving Radio Network Controller (RNC) of the UMTS Radio Access Network (UTRAN).

There are cases where authentication and authorization are required at the application level rather than just at the network level. In many cases, it may be desirable or even necessary to compute the data at the application layer. The computation may take into account the case where, for example, encrypted video data is "broadcast" from a web server to subscribers of a broadcast service. Subscribers must first authenticate themselves with the web server, and then are provided with a key to decrypt the broadcast data. Rather than providing an entirely separate mechanism to facilitate such application layer security, it has been proposed that such security be "bootstrap" onto a 3GPP authentication infrastructure including AuC, USIM, and 3GPP AKA protocols. This approach at least initially predicts that the application function on the network side is under the control of the access network operator, although it need not be the case that some other trust relationship exists between the access operator and the operator of the network in which the application function is located.

3GPP TS 33.220 discloses a general Bootstrapping Architecture (GBA) mechanism to bootstrap authentication and key matching procedures for application security over 3GPP AKA mechanisms. The new procedure introduces a network-based function known as the Bootstrapping Server Function (BSF) located on the user's HE. The BSF communicates with the Home Subscriber Subsystem (HSS), AuC, to obtain an authentication vector upon request. The interface between BSF and HSS is known as the Zh interface. A functional entity that implements an application function on the network side is called a network application function (NAF). The NAF communicates with the BSF via the Zn interface (eg, using the DIAMETER protocol). The interfaces between user equipment (UE), BSF and NAF are called Ub and Ua interfaces respectively and use Hypertext Transfer Protocol (HTTP).

Assume that the GBA is used with a given NAF and that the UE must configure the HTTP Digest AKA mechanism with the BSF over the Ub interface as the required keys do not yet exist. (As part of this process, the BSF may modify the vector obtained from the HSS. As a result, the UE may be authenticated by the BSF and provided with the necessary security keys. In addition, the UE is provided with a transaction identifier (TI) Then this TI is provided by UE to NAF via Ua interface.NAF sends TI to BSF and in turn receives related security keys.After that, UE and NAF can use Ua interface as security method.

Although use of the Ub interface is not expected to be frequent (note. The same keying material can be reused with several different NAFs, each new NAF uses a common TI to request a keying element from the BSF. ), and when they are used, time is consumed. For example, 10 round trips are included, assuming HTTP Digest is used on the Ua interface. In addition, the UE must use two separate transport layers to communicate with both NAF and BSF, resulting in a high level of transport layer resources.

It is an object of the present invention to overcome or at least alleviate the disadvantages mentioned above. This objective is achieved by efficiently combining the two interfaces into one, allowing multiple authentication and authorization procedures to proceed simultaneously.

According to a first aspect of the present invention, there is provided a method of authenticating a client to two or more servers, all coupled via a communication network, wherein the client and the first server process a shared secret, the Way:

authenticating a client to a first server using the shared encryption key, wherein signaling related to an authentication process is transmitted between the client and the first server via a second server;

generating a session key at the client and the first server and providing the session key to the second server; and

authenticating the client to the second server using the session key.

Advantageously, the method comprises authenticating a second server to the first server and providing said session key from the first server to the second server after such authorization.

According to a second aspect of the present invention, there is provided a method of operating an authentication server in a communication system, the method comprising:

relaying authentication signaling between a client and an additional authentication server, wherein the client and the additional authentication server share an encryption key; and

receiving a session key from the additional authentication server, and authenticating the client using the session key.

According to a third aspect of the present invention, there is provided a method of operating an authentication server in a communication system, the method comprising:

exchanging signaling with the client via an additional server to authenticate the client terminal;

generating a session key using an encryption key shared between a client and the first server; and

and transmitting the session key to the second server.

According to a fourth aspect of the present invention, there is provided a method of operating a client terminal coupled to a communication network, the method comprising:

exchanging signaling with a first server via a second server to authenticate a client terminal to the first server;

generating a session key using a shared secret key between a client terminal and the first server; and

and receiving an authentication challenge from the second server, and generating an authentication response using the session key.

The steps of the invented method need not be performed in a particular order. In particular, the method steps may overlap.

According to a fifth aspect of the present invention, there is provided a method of authenticating a client to two or more servers, all coupled via a communication network, wherein the client and the first server process a shared encryption key, the method comprising:

transmitting an authentication request from a client to the first server via a second server;

generating a first authentication challenge using the shared encryption key when the first server receives the request, and transmitting the challenge to a second server;

sending the first challenge to a second server, generating a second authentication challenge at the second server, and sending the first and second challenges from the second server to the client;

When the client receives the challenge, generating a first challenge response and a session key as a first challenge using the shared encryption key, and generating a second challenge response as a second challenge using the session key step;

transmitting the challenge response to the second server and transmitting the first challenge response to the first server;

Authenticating the client in the first server using the first challenge response and the shared encryption key, generating the session key in the first server when the client is authenticated, and transmitting the session key to the second server step; and

authenticating the client at the second server using the second challenge response and the session key.

According to a sixth aspect of the present invention, there is provided a method for authenticating a user equipment to a network application function of a communication network, the method comprising:

sending an access request from the user equipment to the network application function;

determining at the network application function that the response relates to an authentication that must be performed by some other function within the network;

forwarding the request to the other function;

returning a challenge from the other function to the network application function;

transmitting the challenge to the user equipment together with the challenge generated by the network application function;

sending the challenge responses from the user equipment to the network application function, and forwarding the response regarding the challenge of the other function to the other function; and

verifying the validity of the response in the network application function and the other function.

According to a seventh aspect of the present invention, there is provided a method for authenticating a client to two or more servers all coupled via a communication network, wherein the client and the first server process a shared encryption key, the method comprising:

sending an authentication request from a client to an authentication server, the request including an authentication header identifying a domain different from where the authentication server is located;

recognizing, at the authentication server, that the request is directed to another domain and forwarding an authentication header to an authentication server of the domain; and

upon receipt of the authentication request at the second above-mentioned authentication server, authenticating the first above-mentioned authentication server, authenticating the client, and providing the first above-mentioned authentication server with means for authenticating the client.

Criteria for the authentication or access request passed from an intermediate server to an additional server include delivery of the entire request message as received or delivery of only a portion thereof. It also covers the possibility that the request will be converted from the received format to another format. It is only important that the nature of the request is maintained.

Another aspect of the invention relates to user equipment and an authentication server for use in such a method.

1 is a flow diagram of signaling regarding a simultaneous authentication procedure in the general case;

Fig. 2 is a flow diagram of signaling related to a simultaneous authentication procedure applied to a Generic Bootstrapping Architecture;

Fig. 3 is a flow diagram related to a modified concurrent authentication procedure for the general case; and

Fig. 4 is a flow diagram of signaling related to a modified concurrent authentication procedure applied to universal bootstrapping;

The present invention provides a "simultaneous" authentication mechanism for a user and/or user device, wherein the entitlement for the second authentication procedure results from the entitlement of the first authentication procedure before the first authentication procedure is completed. The second authentication procedure is then completed upon completion of the first authentication procedure.

The client and the authentication server (AUS) share the encryption key (S). The client contacts a (second) server, and the server must authenticate the client. However, the server does not share its own credentials with the client. The client, server and AUS agree to reuse the existing encryption key (S). 1 shows the signaling steps involved in the process.

1) The client sends a request to the server. The request contains authentication method specific information indicating that the server maintained by the AUS can authenticate the client by reusing the encryption key (S).

2) The server recognizes that the information from the AUS can be reused, and passes the authentication method specific information to the AUS. The server and the AUS mutually authenticate each other at the initiation of communication.

3) If the AUS cooperates with the server, the AUS generates an AUS challenge and transmits the challenge to the server.

4) The server relays the AUS-challenge (first authentication method) to the client and adds its own server-challenge (second authentication method). At this stage, the server may remain unqualified with respect to the client.

5) The client receives two challenges. It prepares a response to the AUS-challenge using the shared encryption key (S). The client then obtains the server-specific key element from the encryption key (S) to prepare a response to the second challenge. The client requests mutual authentication from the server to ensure that the server processes the same key. This will prove to the client that AUS trusts the server, and the obtained key is provided to the server. The client sends both an AUS-response and a server response to the server.

According to the characteristics of the first authentication method, the client may authenticate the AUS in this step. For example, this may be possible with UMTS AKA, EAP AKA and HTTP Digest AKA mechanisms. This can alternatively be performed in step 9) below.

6) The server stores the server response and tunnels the AUS-response to the AUS. At the same time, the server requests a server-specific key element (obtained from the encryption key S) related to the server-challenge.

7) AUS authenticates the client using the AUS-response and shared encryption key (S). After that, it prepares the same key element from S, which the client does in step 5), and sends this key element to the server. AUS can also specify a lifetime for these key elements and provide them to the server. If the client's authentication fails, AUS responds with an authentication failure message rather than returning a key element.

8) The server authenticates the client using the server-response from step 6) and the key element received from step 7). If authentication is successful, the server will provide the service to the client.

9) The client authenticates the server using the server-response and the key element obtained from S. According to the characteristics of the first authentication method, the client may also authenticate the AUS at this stage. For example, this would be the case with HTTP Digest, where the client requests a response message (eg, 200OK) to include an Authentication-Info header to authenticate the AUS.

The client and the AUS may have a static policy on the time period when the obtained key is valid. This policy can be configured in the client at the same time the encryption key (S) is defined. However, there may be several methods for granting a key lifetime, for example, to encode a policy in some parameter of the authentication message.

Note that in this general case, it is difficult to specify whether the client identity has been reused or regenerated. Identity approval will depend on the specific application.

A first exemplary implementation of the present invention will now be described with reference to Fig. 2, which shows a subscriber owned 3G mobile terminal (UE) communicating with some radio access network (not shown in the figure). where the UE has already been authenticated to the radio access network and the services provided by the network using the 3GPP AKA procedure (including authentication of the subscriber's home environment and the exchange of signaling between the serving nodes of the access network as described above) Assume you are authorized to use it. Also shown in FIG. 1 is a Network Authentication Function (NAF) and a Bootstrapping Server Function (BSF). The location of the NAF is not critical for the purposes of this discussion, although it may be operated and controlled by, for example, the operator of the radio access network. The BSF is typically located within the subscriber's home environment. As described above, the UE communicates with the NAF through the Ua interface and with the BSF through the Ub interface.

A subscriber owning a terminal (UE) wants to use the service and wants to have access controlled by the NAF. Such a service may be a real-time or streaming video broadcast from a web server. Typically, the NAF needs to know who the subscriber is claiming to be, and a billing relationship can be established for the subscriber. To do this, the NAF must contact the subscriber's home environment. A procedure that is considerably simplified compared to the conventional approach will now be described. This procedure takes the 3GPP GBA standards TS 33.220 (v6.2.0) and TS 24.109 (v6.0.0) as its basis.

The optimal procedure assumes that Hypertext Transfer Protocol (HTTP) is used on the Ua interface, although other protocols may also be possible. The procedure includes the following steps:

1) The UE sends an HTTP request (typically HTTP GET) to the NAF via the Ua interface. If the UE supports the GBA optimal procedure, it will include the authorization header used by the Ub interface in these HTTP messages. This authorization header contains the "realm" of the BSF and the user identity. For personal reasons, the user identity may not be an identity (IMSI or IMPI) associated with a typical Ub interface. Rather, the identity may be an identity related to an already valid Ua interface, ie, a B-TID. The request may also include other authorization headers, and in particular may include authorization headers related to NAF.

The UE may determine, for example, that it attempts to use the GBA optimization procedure if any security key lifetime appears to have expired or that it attempts to use the GBA optimization procedure by default if the UE does not know whether a GBA procedure is used. have.

2) If the HTTP request contains authorization headers used in the Ub interface, NAF will recognize that these headers are for a realm other than itself. Based on the header information, the NAF may pass the header information or a related part thereof to the BSF via the Zn interface, for example using the DIAMETER protocol.

If NAF doesn't support GBA optimization, it should ignore the authorization header because it's for some other realm. Although NAF supports GBA optimization, NAF may also make a policy decision not to use GBA optimization. [Note that in this case, the NAF does not directly challenge the UE with the HTTP 401 Authorization Challenge, so it assumes that the UE and the NAF share a valid password.] The NAF also implements a bootstrap procedure via the Ub interface. It can respond to the initiating message.

Upon receipt of the HTTP protocol from the NAF, the BSF verifies whether the NAF is authorized to use the optimized GBA procedure. For example, a BSF can use TLS and authenticate a NAF that certifies authorization data from a local database.

3) If authorization is granted, BSF returns HTTP Digest AKA to NAF in DIAMETER protocol message. The challenge includes, for example, a new identity for the UE, B-TID2 in the preferred parameter. Also, the challenge includes only a "hint" by which the UE can configure B-TID2, and the UE and the BSF can know the rules for configuring the identity from the hint. The BSF may be about the B-TID back to the subscriber's IMSI/IMPI, thereby selecting the correct AKA challenge.

4) The HTTP 401 response message from the NAF to the UE contains two authorization challenges, one from the BSF and the other from the NAF. caution. At this stage, the NAF may remain stateless, ie it may "forget" the UE.

5) The UE authenticates the home network using the Digest AKA challenge (generated in BSF). The UE generates a new GBA-related keying element based on the HTTP Digest AKA challenge and other relevant information. The UE then constructs a NAF specific key using the B-TID2 and associated keying element, and uses this information to generate a response to the second authentication challenge (towards the NAF). A second HTTP request is sent by the UE towards the NAF and includes two authorization headers, one for the NAF and one for the BSF.

6) NAF "tunnels" the AKA response to the BSF (ie, the BSF Authorization Header). At the same time, it requests a keying element related to the B-TID2 identity.

7) The BSF authenticates the UE according to the Digest AKA procedure. It then configures the same keying element as the UE (step 5), and returns the relevant keys to the NAF. If the AKA authentication fails, the BSF returns an error message to the NAF.

8) When the NAF receives the appropriate keying element from the BSF, the NAF may authenticate the UE using the second authorization header included in the second HTTP request (step 5). The NAF then facilitates delivery of the requested service to the UE.

An alternative parallel authentication mechanism will now be described for a detailed implementation in general terms first.

Fig. 3 shows the components of a communication system as described above, wherein a client and an authentication server (AUS) share an encryption key (S). Steps 1) to 3) are the same as described above with reference to FIG. However, in step 4), after the server receives the AUS challenges to the client, it forwards them to the client without adding any challenges of its own.

The client receives the challenge, obtains the server specific key elements from the shared encryption key (S) and uses them to prepare to respond to the AUS challenge. A client requests a mutual authorization from AUS using a server-specific key element (obtained from S). This will prove to the client that AUS trusts the server, and therefore the server specific key element is obtained from S. The client sends an AUS-response to the server in step 5). Referring to the procedure of Fig. 1, according to the characteristics of the first authentication method, the client may already authenticate the AUS at this stage.

In step 6), the server tunnels the AUS response to the AUS, while itself maintains a copy of the response. At the same time, the server requests a server specific key element (obtained from S) from the AUS. On the other hand, the server does not need this key element in the ongoing authentication process and can be used to authenticate the client later.

AUS prepares the same key element as the shared encryption key (S) prepared by the client in step 5), and authenticates the client using the AUS response and the obtained key element. AUS prepares an authentication iteration using the server-specific key element and sends it to the server in step 7). AUS indicates to the server that the client is authenticated and sends the key element to the server. Again, the AUS can specify a lifetime for the new key element and provide it to the server. If authentication for the client fails, AUS does not return a key element, but repeats with an authentication failure message. Note that AUS does not prepare the authentication iteration, but instead returns the key element to the server, allowing the server to prepare the authentication iteration.

The server receives the authentication indication and key element from the AUS. If authentication is successful, the server will provide the service to the client. The server passes the authentication iteration to the client in step 8). The server may test the AUS response sent by the client in step 5) using the key returned by the AUS (although not required as the server may rely on the authentication provided by the AUS).

In step 9), the client authenticates the server using the key element obtained from the shared encryption key S and the authentication iteration. This will prove to the client that AUS trusts the server. Based on the characteristics of the authentication method, the client may also authenticate the AUS at this stage. For example, this would be the case using the HTTP Digest mechanism.

A detailed implementation of this general procedure is used in the Ua interface. The procedure is shown in FIG. Steps 1) to 3) are as described above with reference to FIG. 2 . However, in step 4), the NAF forwards a 401 response message towards the UE, indicating an authentication challenge from the BSF without any challenge generated by the NAF.

The UE authenticates the BSF using the Digest AKA challenge (from the BSF). The UE generates a new GBA-related keying element based on the HTTP Digest AKA challenge and other relevant information. The UE uses this keying element and other relevant information (eg, the identity of the NAF) to obtain the NAF specific keys, and then uses the NAF specific keys as passwords when preparing the HTTP Digest AKA response towards the BSF. The UE includes the client nonce in the HTTP Digest AKA response and sends the response towards the NAF in step 5).

This UE behavior violates the standard behavior in RFC 3310 (HTTP Digest AKA) when responding to an HTTP Digest AKA challenge. The password used in HTTP Digest AKA must be "RES", not a NAF specific key. However, this exceptional procedure ensures that the NAF identity is bound by the authentication process.

In step 6), the NAF tunnels the AKA response to the BSF. At the same time, the NAF requests a keying element related to the UE (eg identified by IMSI/IMPI or new B-TID). The BSF configures the same NAF specific keying element as the UE done in step 5). The BSF then authenticates the UE (Digest AKA response) using the NAF specific key. The BSF prepares a 200 OK message using the NAF specific key and client nonce, and sends it to the NAF in step 7). The message may contain a new identity for the UE, ie B-TID2. The message may only contain a hint as to how the UE may configure identity B-TID2 (a new identity may be assigned in step 3) or step 7).

The BSF also sends the relevant key to the NAF along with an indication that the UE has been successfully authenticated. If the NAF has not yet discovered a new identity B-TID2, the BSF also returns the information to the NAF. If the AKA authentication fails, the BSF returns an error message to the NAF.

In step 8), the NAF delivers a 200 OK message to the UE. The NAF stores the NAF specific key, eg to authenticate the UE in case of the next access request. The NAF is now ready to provide the service to the UE. In step 9), the UE may authenticate the NAF based on the receipt of the 200 OK message and the NAF specific key. This can indirectly authenticate the NAF, since the BSF also obtains the NAF specific key, and the UE authenticates the BSF.

It will be apparent to those skilled in the art that various modifications may be made in the above-described embodiments without departing from the scope of the present invention.