GB2413035A

GB2413035A - Identity authentication in a mobile network

Info

Publication number: GB2413035A
Application number: GB0407905A
Authority: GB
Inventors: Vesa Torvinen; Vesa Lehtovirta; Bengt Sahlin; Karl Norrman
Original assignee: LM Ericsson Oy AB; Ericsson AB
Current assignee: LM Ericsson Oy AB; Ericsson AB
Priority date: 2004-04-08
Filing date: 2004-04-08
Publication date: 2005-10-12
Anticipated expiration: 2024-04-08
Also published as: GB0407905D0; GB2413035B

Abstract

A method of authenticating a request for session keys sent from a Network Authentication Function of a visited network to a Bootstrapping Server Function of a home network in respect of User Equipment, UE, the request comprising a transaction identifier. The method comprises, at the Bootstrapping Server Function, comparing a UE identification part of the transaction identifier with a value generated by applying a one-way function to an Authentication and Key Agreement key previously agreed between the UE and the Bootstrapping Server Function as part of an Authentication and Key Agreement procedure, and if the values agree, progressing the request by sending appropriate session keys to the Network Authentication Function, otherwise denying the request.

Description

24 3035 Identity Authentication in a Mobile Network

Field of the Invention

The present invention relates to identity authentication in a mobile network and more particularly to a method of authenticating transaction identifiers in a Generic Bootstrapping Architecture.

Background to the Invention

The Generic Bootstrapping Architecture (GBA) is discussed in the 3GPP Technical Specification TS 33.220. GBA provides a mechanism whereby a client terminal (UK) can be authenticated to a Network Authentication Function, and secure session keys obtained for use between the client terminal and the Network Authentication Function.

This process bootstraps upon the known Authentication and Key Agreement (AKA) procedure which allows a client terminal to be authenticated to a Bootstrapping Server Function (BSF) of the client's home network, and establishes secure keys for subsequent communications. In particular, the AKA procedure establishes session keys that are afterwards applied between the client terminal and the operator-controlled Network Application Function (NAF). When a client terminal and NAF wish to obtain session keys from the BSF, the NAF sends a transaction identifier to the BSF, the transaction identifier containing an index which the BSF uses to identify the client terminal and appropriate keys.

GBA (Release 6) has mainly been built under an assumption that NAF is located in the home network. However, there are already use cases when NAF may be located in a visited network, e.g. Multimedia Broadcast/Multicast Service MBMS. In such "roaming" scenarios, the BSF (in the home network) cannot be sure that NAF in the visited network and which is requesting keying material, is really talking to the UK.

The only verification carried out by the BSF is based on the validity of the transaction identifier. The transaction identifier is an identifier comprising a prefix portion which uniquely identifies the client terminal and a suffix portion which uniquely identifies the BSF to which the client terminal belongs. Providing that a BSF receives a valid transaction identifier, the BSF will return keying material to the requesting NAF.

It will be appreciated that anybody who is able to monitor UE-BSF interactions will be able to construct a valid transaction identifier (currently specified as RANDBSF_servers_domain_name, where "RAND" is a random value generated during the AKA procedure). This is not a problem if only authorized NAFs have access to the BSF, or if all NAFs and BSFs use some underlying security mechanism such as TLS or IPsec. However, it might be expected that 3G networks will be more open than this in the future, and that the current GBA will therefore not be sufficiently secure.

Summary of the Invention

An object of the present invention is to enable the BSF to know that a client terminal is really involved with a NAF at the time the NAF makes a key material request.

According to a first aspect of the present invention there is provided

Brief Description of the Drawings

Figure I illustrates a simplified GBA model.

Detailed Description of Certain Embodiments

This document proposes an enhancement to the GBA transaction identifier. Instead of using RAND alone as the "username" (i.e. prefix part) in transaction identifier, the following identifier structures are considered: Including the AKA session key (CK) in the identifier. However, in order to avoid revealing the session key to unauthorized parties, a one-way hash function is applied to the session key. The resulting binary output will in some cases be encoded to text format, e.g. by using base64 encoding, suitable for transmission over the network.

In order to be able to use the same keying material for other purposes, the key should be concatenated with a "key mask", for example a static string, before applying as an input to the hash function.

An example of a more secure transaction identifier is therefore: Base64_encoded[hash(key-mask I CK)]@,BSF_servers_domain_name where keymask is a static string such as "3GPP-bootstrapping". It will be appreciated that as an alternative to the AKA session key CK, the key TK may be used. A combination of the keys CK and IK may be used.

A possible disadvantage of this transaction identifier is that it can be used only once. If for example communication with a NAF is not successful, the same transaction identifier cannot be re-used securely with other NAFs because the transaction identifier may have been revealed to unauthorized parties. In order to allow re-use of the same transaction identifier with several NAFs securely, the derivation should include some proof of freshness, for example a counter value or time-stamp. The counter or timestamp value could be generated by the client terminal, and be included both in the hash function and in clear text in the transaction identifier. The BSF checks the freshness of transaction identifier for example by checking that the time in the time-stamp is fresh, or by maintaining a register of already used counter values.

An example of a more secure transaction identifier that is not restricted to one use only is: counter. Base64_encoded[hash(counterl key-mask! CK)]@, BSF_servers_domain_name Use of such a transaction identifier will require the provision at the BSF of pre- generated hash values for all possible values of counter. A search is then conducted to see if the received hash value matches one of the pre- generated values. To overcome this problem, the transaction identifier may also include a clear text parameter that will identify the subscription and/or end-user public identity. As well as allowing the BSF to identify the right password effectively, this approach may also be used for indicating under which public identity the client terminal is authenticated. If clear text identification information is not included, the implementation becomes complex.

A possible identifier structure is one which includes a base64 encoded RAND value - in the same way that it is currently specified, i.e.: co unter. Base 64_encoded[hash (co unterl key- mask! CK)]. Base 64_encoded[RAND]@, BSF_servers_domain_name This document proposes an enhancement to the transaction identifier in order to further secure GBA infrastructure in roaming scenarios. The use of this solution could be mandatory in GBA, or alternatively the use of it could be limited to roaming scenarios.

Note, however, that the solution has potential also for other uses, e.g. simple "single- sign-on" solution (each transaction identifier is essentially "a ticket" or one-time password that can be sent in clear text).

The enhanced format of the transaction identifier could provide more freedom for the design of the GBA roaming model. For example, a client terminal may not need to maintain a parallel POP context to home network if the BSF in the visited network can act as a Diameter proxy. A NAP in the visited network, on the other hand, could help the client terminal to locate a BSF in the visited network (e.g. via the use of HTTP re- direct commands).

Claims

Claims 1. A method of authenticating a request for session keys sent from

a Network Authentication Function to a Bootstrapping Server Function in respect of User Equipment, UK, the request comprising a transaction identifier, the method comprising, at the Bootstrapping Server Function: comparing a UE identification part of the transaction identifier with a value generated by applying a one-way function to an Authentication and Key Agreement key previously agreed between the UE and the Bootstrapping Server Function as part of an Authentication and Key Agreement procedure, and if the values agree, progressing the request by sending appropriate session keys to the Network Authentication Function, otherwise denying the request.
2. A method according to claim 1, wherein the Network Authentication Function is located in a visited network, and the Bootstrapping Server Function is located in a home network of the UK.
3. A method according to claim 1, wherein said UE identification part of the transaction identifier is compared with a value generated by applying a one-way function to said Authentication and Key Agreement key and to one or more further values.
4. A method according to claim 3, wherein a further value is a key mask.
5. A method according to claim 4, wherein the key mask is a static string which is known to both the UE and the Bootstrapping Server Function.
6. A method according to any one of claims 3 to 5, wherein a further value acts as a proof of freshness.
7. A method according to claim 6, wherein the proof of freshness is a counter which is included in plain text form in the transaction identifier.
8. A method according to any one of the preceding claims, wherein said one-way function is a hash function.
9. A method according to any one of the preceding claims and comprising decoding said UE identification part of the transaction identifier using a Base64 decoding process.
10. A method according to any one of the preceding claims, the transaction identifier comprising an index, wherein the Bootstrapping Server Function uses said index to identify the value to be used for said comparison from a set of stored values
11. A method according to claim 10, wherein said index is a RAND parameter previously agreed between the UE and the Bootstrapping Server Function in connection with the Authentication and Key Agreement procedure.
12. A method of enabling authentication of a request for session keys sent from a Network Authentication Function to a Bootstrapping Server Function, UK, the request comprising a transaction identifier, the method comprising, at the UK: generating a transaction identifier having a UE identification part generated by applying a one-way function to an Authentication and Key Agreement key previously agreed between the UE and the Bootstrapping Server Function as part of an Authentication and Key Agreement procedure, and sending the transaction identifier to the Network Authentication Function.
13. A method according to claim 12, wherein the Network Authentication Function is located in a visited network, and the Bootstrapping Server Function is located in a home network of the UE
14. A method according to claim 12 or 13, wherein said UE identification part is generated by applying a one-way function to an Authentication and Key Agreement key and one or more further values.
15. A method according to claim 14, wherein a further value corresponds to a static string which is known to both the UE and the Bootstrapping Server Function.
16. A method according to claim 14 or IS, wherein a further value is a counter which is included in plain text form in the transaction identifier, the UE incrementing the counter for each new session.
17. A method according to any one of claims 14 to 16, wherein said oneway function is a hash function.
18. A method according to any one of the preceding claims and comprising encoding said UE identification part of the transaction identifier using a Base64 encoding.
19. A method according to any one of claims 14 to 18 and comprising including an index in the transaction identifier.

A method according to claim 19, wherein said index is a RAND parameter previously agreed between the UE and the Bootstrapping Server Function in connection with the Authentication and Key Agreement procedure.