DETAILED DESCRIPTION

[0161] In the following, a preferred embodiment of the invention will be described applied to a Global System for Mobile Communications (GSM) telecommunications network. For authenticating a mobile node to a packet data network, Subscriber Identity Module (SIM) cards normally used for authenticating GSM subscribers GSM networks are utilised. During authentication process, the SIM and the GSM telecommunications network communicate across the packet data network rather than the GSM telecommunications network.

[0162] The actual type of the telecommunications network is irrelevant. GSM is used as an example, but the network type could as well be Universal Mobile Telecommunications System (UMTS) or GSM with General Packet Radio Service (GPRS). Actually, GPRS can be understood as an extension to GSM rather than an independent network in the sense that GPRS operates using GSM radio access network and GSM authentication methods.

[0163] The invention will be described using three examples. Example 1 relates to a mobile IP implementation, where existing mobile IP extensions are utilised. Example 2 relates to a wireless LAN environment with roaming from one sub-network to another sub-network. Example 3 relates to generation of IKE keys for Internet nodes.

EXAMPLE 1

Mobile IP

[0164] In the preferred embodiment of the invention, mobile nodes are identified by an International Mobile Subscriber Identity (IMSI) in the form of a string of digits. The IMSI is by definition a unique subscription identifier consisting of a national mobile subscriber identity and a mobile country code. For example, in the GSM, the IMSI is represented by bytes fewer than the number of digits in the IMSI.

[0165] The IMSI is transmitted in mobile IP messages as a Network Access Identifier (NAI). The NAI is in form of imsi@sonera.fi (for example “1234567@sonera.fi”) or imsi@gsm.org (for example “1234567@gsm.org”). Hence, the NAI carries an identity (for example as text or as an identifier number) of the mobile telecommunications network whose subscriber the mobile node is and an identification of the domain of the mobile node. This allows recognising the telecommunications network directly from the NAI.

[0166] The latter of those two examples of NAI, the gsm.org domain, is an example on an upper level domain that is adapted to seek for the appropriate domain relating to the relevant GSM telecommunications network operator.

[0167] The forming of the NAI from the IMSI allows later determination by the packet data network of the relevant GSM telecommunications network operator, based on the NAI alone. This removes need to maintain at the packet data network any local database mapping together different telecommunications network operators and their subscribers.

[0168] In general, identifying mobile nodes with NAIs is known to a person ordinarily skilled in mobile IP. An NAI extension can be included in a Registration Request or a Registration Reply, both of which are described later.

[0169] Operation of the SIM card in the GSM telecommunications network will now be explained. In GSM, there are known authentication algorithms which are referred to as A3 and A8. These algorithms run on the SIM and in the GSM telecommunications network. These algorithms and a GSM shared secret K _i are known by the SIM and the GSM telecommunications network operator, which typically stores them in an HLR (Home Location Register) of a Mobile services Switching Centre (MSC).

[0170] In authentication, the GSM telecommunications network operator generates a challenge RAND that is a 128 bit random code, which is to be used as a challenge, a corresponding 64 bit GSM session key Kc and a 32 bit signed response SRES for verifying the response to the challenge. The 64 bit session GSM session key Kc is generated by the A8 algorithm as A8(K _i ,RAND) and the 32 bit long SRES is generated by the A3(K _i ,RAND). The combination RAND, SRES and Kc is generally referred to as a GSM triplet. The GSM telecommunications network operator sends the RAND to its subscriber (GSM telephone), the RAND is received by the subscriber and the subscriber passes it to the SIM, which reproduces SRES and Kc. Then the SIM responds to the challenge by sending the SRES. The operator receives the SRES and can confirm the identity of the SIM. The GSM telecommunications network operator can also verify that it shares a Kc with the SIM. Then the Kc can then be used to encrypt data traffic over a GSM radio channel. The advantage of this challenge-response mechanism is that Kc never need be sent over the GSM radio channel and thus it cannot be eavesdropped.

[0171] FIG. 1 shows a communication system 10 comprising a mobile IP network MIP having an IP networking compliant mobile node MT according to a preferred embodiment of the invention. The mobile node MT is typically a laptop computer with a wireless network adapter and software for networking. A plurality of mobile nodes MT can be attached to the MIP. The mobile node MT comprises a keyboard KB, a Subscriber Identity Module SIM_B, a first radio block RF 1 (A PCMCIA Wireless LAN adapter) for communicating with a radio access point over a WLAN radio channel, (optionally) a second radio block RF 2 (A PCMCIA GSM adapter) for communicating with a GSM network GSM_B, a master processing unit MPU (for example a microprocessor or digital signal processor) for controlling the aforementioned blocks and a memory MEM 1 containing a first software SW 1 for operating the MPU.

[0172] The MIP comprises a plurality of Access Points AP for providing the MT with a wireless connection, a Public Access Controller PAC for controlling the APs and a Foreign Authentication, Authorisation and Accounting server FAAA.

[0173] The GSM network GSM_B is a home GSM network of the SIM_B. The GSM_B comprises a Home Authentication, Authorisation and Accounting server HAAA, which has a subscriber data database comprising accounting and authorisation data the subscribers of the GSM_B. These data include the IMSI and GSM shared secret K _i for each subscriber.

[0174] The MIP is connected to the GSM_B by a GSM Authentication Gateway GAGW. The GAGW is a server and it has a memory MEM 2 for storing a second software SW 2 and a central processor CPU for controlling the operation of the server by executing the second software SW 2 . The GAGW couples together a server in the GSM_B and a server in the MIP. These servers are designated as a home AAA server HAAA (AAA refers to Authentication, Authorisation and Accounting) and as a foreign AAA server FAAA. The PAC can also function as a mobility agent MA. If the MIP is the home network of the MT, then the PAC is also a Home Agent HA of the MT. Otherwise the PAC belongs to a foreign network and the PAC can be referred to as a Foreign Agent FA. HAAA is located in the GSM_B and FAAA is located in the MIP. Communication between the two AAA servers occurs by means of a suitable AAA protocol. The AAA protocol is not described here.

[0175] An overview of the authentication process will now be briefly described. In order to authenticate a mobile node for a packet data network, a shared session key K is generated both in the MT and in the FAAA server. Authentication is carried out using GSM_B and its SIM, SIM_B. In this case the authentication procedure will be similar to that described above in relation to a basic GSM network. Authentication utilises the K _i which is present on the SIM_B and in the GSM_B.

[0176] The SIM_B is accessed by providing the MT (for example a laptop computer with a wireless local area network adapter) with a SIM card reader. Alternatively, the MIP does not directly access the K _i of the GSM_B, but receives a RAND relating to the SIM_B. This RAND is sent to the MT and the RESP is verified against the RESP that the telecommunications network has produced. Authentication can be further improved by using multiple RANDs in order to generate an authentication key which is more secure than just one Kc.

[0177] FIG. 2 shows a shared session key exchange procedure of the system of FIG. 1 . In the following, the procedure is briefly summarised and then described in more detail.

[0178] 1. The MT sends to the FAAA a Network Access Identifier NAI and a protection code MT_RAND (also known in Mobile IP terminology as nonce) generated by the MT. The MT_RAND remains the same during an authentication session and it is meant to hinder replay attacks. The MT_RAND is typically a random number or based on time (a timestamp with certain resolution).

[0179] 2. The FAAA sends to the HAAA an initial identification message containing the IMSI or NAI of the MT, and the MT_RAND.

[0180] 3. The HAAA retrieves n GSM triplets, each comprising a RAND, a Kc, and a SRES. Then, the HAAA computes the K=H(n*Kc,MT_RAND) for the MT. Here n is an integer greater than or equal to 1, * represents the number of parameters (n*Kc refers to n different Kcs) and H ( ) represents a one-way hash function. The HAAA also computes a value SIGNrand which is calculated from MAC(K,n*RAND,MT_RAND), where MAC denotes a message authentication code. SIGNrand is a cryptographic checksum to verify that the n RANDs really originate from an entity that has access to the K _i (as K is derived from that). The checksum also indicates if the n RANDs indeed are generated during the same authentication session because the MT_RAND changes from one authentication session to another.

[0181] 4. The HAAA sends the n RANDs, the SIGNrand and optionally the IMSI to the FAAA. The IMSI itself need not be used if another session identifier has been sent with the IMSI in step 1 of this procedure. In this case, this session identifier would be used instead of the IMSI.

[0182] 5. The FAAA sends at least one RAND and SIGNrand to the MT.

[0183] 6. Using the i stored on the SIM_B, the MT calculates the K. Using the K, the n RANDs and the MT_RAND, the MT then tests SIGNrand. If SIGNrand is correct, the MT generates a copies of the n SRESs (one for each RAND). The MT computes a cryptographic checksum SIGNsres=HASH2(K,n*SRES) for the K and the SRESs.

[0184] 7. The MT sends the SIGNsres to the FAAA. In the MT, the calculation of the K is the same as the calculation of the K in the HAAA.

[0185] 8. The FAAA sends the SIGNsres to the HAAA.

[0186] 9. The HAAA verifies that SIGNsres is valid by checking that the equation SIGNsres=HASH2(K,n*SRES) applies with the values the MT has received. The HAAA sends the result (whether the SIGNsres is valid) to the FAAA. If the SIGNsres is valid, the HAAA sends also the K to the FAAA.

[0187] 10.Authentication is complete and the FAAA and the MT share the K.

[0188] The FAAA is functionally connected to several HAAAs and the FAAA selects the correct HAAA based on the domain part of the user's NAI, for example “sonera.fi”. The HAAA uses a HAAA-HAAA protocol to send the initial identification message to the correct HAAA or to GSM infrastructure such as a Mobile Switching Centre (MSC). According to an alternative embodiment, the FAAA is configured to communicate with a single HAAA and always sends the message in step 1 to that HAAA.

[0189] The procedure of FIG. 2 will now be described. It starts by a message Registration Request that contains a New Session Key Request extension. This and the following extensions are explained later, referring to FIGS. 3 to 6 . The IMSI can be transmitted in a Network Access Identifier (NAI) extension. The New Session Key Request extension contains a maximum key lifetime and a random number MT_RAND picked by the MT. When the MA receives the Registration Request with the New Session Key Request extension, it sends the NAI (containing the IMSI) and MT_RAND to the HAAA. If the MA is a home agent operated by a GSM telecommunications network operator, the home agent typically has a direct access to GSM triplets. In an embodiment of the invention, a number of triplets are retrieved in advance in order to speed up the registration. Once the HAAA has obtained n GSM triplets for the MT by whatever means, it calculates the new K and an authenticator SIGNrand, as described above.

[0190] The MA then sends a Registration Reply with a New Session Key Reply extension to the MT. The Registration Reply contains the MT_RAND and the SIGNrand, so that the MT is able to verify that the RANDs are current and that they were generated by the GSM infrastructure. The Registration Reply also contains the remaining key lifetime, which can be equal to, or smaller than, the key lifetime proposed by the MT.

[0191] If the MT and the MA do not share a security context, the authentication of the first Registration Request and the Registration Reply will fail. The reply code in the Registration Reply is “mobile node failed authentication” or “identification mismatch”. In mobile IP, an authentication extension is used. The authentication extension has a special value for a security parameter index (SPI) field, meaning “New Session Key Exchange”. The SPI and the IP address of the MT are used as an index for managing authentication procedures regarding different mobile nodes. The authentication extension has also a field for an authenticator, that is typically a MAC code. The authenticator can be empty. Thus, if the MA does not support authentication according to the present invention, it will simply reply with the reply code “Mobile node failed authentication”. If the MA is a foreign agent, the MT should omit the authentication extension altogether.

[0192] After receiving the Registration Reply with the New Session Key Reply extension, the MT is able to verify the validity of the SIGNrand. If the SIGNrand is valid, the MT generates the key K and the SIGNsres and creates a new security context for the MA or, if such already exists, updates the context with the new K. This key will used as the Mobile IP authentication key in subsequent registration messages.

[0193] The MT includes the SIGNsres in an SRES extension in the next registration request it sends to the MA. The MA sends the SIGNsres to the HAAA, which verifies it and sends an indication to the MA. If the SIGNsres is valid, the HAAA also sends the K to the MA. Now the MA can create/update the security context for the MT.

[0194] If the MA is the FA, the K could now be distributed to all the foreign agents in the visited domain.

[0195] Since the MA may need to get the SRES extension quickly, it is advantageous that the MT sends the Registration Request with the SRES extension immediately after reception of the RAND.

[0196] The security context created by the K exchange mechanism described above has an SPI. Here, another well-known SPI is used for the SIM-generated security context. A value is reserved for the SPI “SIM-generated security context” and for the SPI “new session key exchange”.

[0197] According to the preferred embodiment, the default algorithm in Mobile IP authentication is keyed MD5 in prefix+suffix mode. In this mode, an authentication digest for a message is calculated by running MD5 over the following stream of bytes: a first occurrence of the K and the protected fields from the Registration Request and a second occurrence the K.

[0198] The authentication digest is transmitted in an authentication extension as shown in FIG. 3 . FIG. 3 shows an exemplary bit map as a table of bits, wherein each row has four octets. There are three kinds of authentication extensions: a mandatory Mobile-Home authentication extension used between the MT and the home agent, an optional Mobile-Foreign authentication extension used between the MT and the foreign agent and an optional Foreign-Home authentication extension used between the FA and the HA. All these extensions have the same format. SPI is an opaque identifier. An authenticator (that verifies the recipient of the message) of the authentication extension maps the SPI and the peer's IP address to a security context in the mobility security association database. The security context contains a key, the algorithm and other security parameters. The authenticator field contains the message digest.

[0199] In Mobile IP authentication according to the preferred embodiment, the security contexts (including the K) are generated by using the SIM_B. Because the RANDs are generated by the GSM_B, for example by the HAAA, the MT needs first to send its IMSI to the MA with which it is registering. Then the MA is able to use the FAAA-HAAA protocol in order to obtain GSM authentication information for the MT (as described above) and use this information for generating the K, with the MT. After the K has been generated, the MT is able to register with/through the MA. The K can be used for several subsequent registrations. However, there is a lifetime for this K and before the lifetime expires, a new K can be generated by a similar procedure.

[0200] The K exchange messages between the MT and the MA are transmitted as extensions to the Registration Request and Registration Reply. Three new extensions to registration messages between the MT and the MA are needed in order to agree upon the K. These extensions are a New Session Key Request extension, a New Session Key Reply extension and an SRES extension.

[0201] Typically, the MT knows that its HA supports the authentication according to the present invention. However, the MT may not know which authentication method or methods the FA supports. To test whether the FA supports the authentication method according to the invention, the MT includes the New Session Key Request extension for the foreign agent in the first Registration Reply and omits the Mobile-Foreign authentication extension. The New Session Key Request extension is optional. If the FA does not support it, the FA should ignore it and remove it before forwarding the request to the HA. When the MT receives the Registration Reply, it implements the following logic:

[0202] If the Registration Reply contains a New Session Key Reply extension and the reply code from the FA is the error code “mobile node failed authentication”, the FA supports authentication according to the present invention. If the New Session Key Reply is valid, the MT creates a security context for the FA and includes an SRES extension for the FA in the next Registration Request.

[0203] If the FA did not set the reply code to an error code and the Registration Reply does not contain a New Session Key Reply extension and the reply code from the FA is not set, the FA does not support the authentication but alternatively allows registrations without Mobile-Foreign authentication. The MT can carry out subsequent registrations with the FA without any authentication extensions being required.

[0204] If the Registration Reply does not contain a New Session Key Reply extension and the reply code from the foreign agent is the error code “mobile node failed authentication”, the FA does not support authentication according to the present invention and so requires a different kind of authentication. In this case, if the MT has only the authentication functionality according to the present invention, it cannot register with the FA.

[0205] When the FAAA receives a Registration Request from a mobile node with which the FA does not share a security context, the FA has the following options:

[0206] If there is an invalid Mobile-Foreign authentication extension in the Registration Request, the FA replies with the error code “mobile node failed authentication”. This is the standard Mobile IP behaviour.

[0207] If the Registration Request does not contain a Mobile-Foreign authentication extension and if the local policy does not require Mobile-Foreign authentication, the FA forwards the Registration Request to the HA. The FA does not include a New Session Key Reply extension in the Registration Reply even if there was a New Session Key Request extension in the Registration Request. This is the standard Mobile IP behaviour. This configuration could be useful, for example, in corporate access zones.

[0208] If the local policy in the FA requires Mobile-Foreign authentication, and there is no Mobile-Foreign Authentication extension nor New Session Key Request extension in the Registration Request, the FA replies with the error code “mobile node failed authentication”. This is the standard Mobile IP behaviour.

[0209] If the local policy in the FA requires Mobile-Foreign authentication, and the Registration Request contains a New Session Key Request extension and no Mobile-Foreign Authentication extension, then the FA does not forward the Registration Request to the home agent but instead replies with the error code “mobile node failed authentication” and includes a New Session Key Reply extension in the Registration Reply. If the MT then sends another Registration Request with a valid SRES extension and a valid Mobile-Foreign Authentication extension, the FA forwards the request to the HA.

[0210] Only certain GSM subscribers are authorised to register through a particular MA. User authorisation may be done in any of the following entities:

[0211] the GSM infrastructure. The GSM telecommunications network (MSC/HLR) may support authentication according to the present invention for certain subscribers only.

[0212] the HAAA. The HAAA may be configured with a list of authorised IMSIs. The HAAA may have a separate list for each access controller with which it is connected. This allows the HAAA to decide which subscribers are authorised users of a certain MA. If the HA is operated by the GSM telecommunications network operator, the HAAA may conveniently store this kind of authorisation information.

[0213] the FAAA. If a corporation operates the FAAA, for example for its employees, the corporation might want to control which GSM subscribers are allowed to register with the FAAA. In this case, the MA needs to maintain a list of authorised GSM subscribers. The MA also needs to see the IMSI in cleartext. If public key cryptography is used between the MS and HAAA to protect the IMSI, the HAAA may need to send the cleartext IMSI to the MA so that the MA can check whether the MT is authorised to register to the FAAA.

[0214] The new session key exchange extensions are normal (non-critical) extensions, preferably stored in an MT-AAA authentication extension. Alternatively, the session vendor-specific extensions can be used. If the receiver of the Registration Request does not recognise the extension, the extension is skipped.

[0215] Session key exchange between the MT and the FA is independent of the K exchange between the MT and the HA. Thus, a Registration Request contains any one of the following:

[0216] A New Session Key Request extension for the FA,

[0217] a New Session Key Request extension for the HA,

[0218] a New Session Key Request extension for both the FA and the HA,

[0219] an SRES extension for the FA,

[0220] an SRES extension for the HA,

[0221] an SRES extension for both the FA and the HA,

[0222] a New Session Key Request extension for the FA and an SRES extension for the HA, and

[0223] an SRES extension for the FA and a New Session Key Request for the HA.

[0224] Typically, the Registration Reply contains any one of the following:

[0225] a New Session Key Reply extension from the FA,

[0226] a New Session Key Reply extension from the HA, and

[0227] a New Session Key Reply extension from both the FA and the HA.

[0228] The format of the New Session Key Request Extension is shown in FIG. 4 . The MT may place the New Session Key Request Extension with a sub-type 1 (MT-FA) after the Mobile-Home authentication extension and before the Mobile-Foreign authentication extension (if present). The FA must remove this extension from the request before forwarding the request to the HA.

[0229] The MT may place the New Session Key Request extension with a sub-type 2 (MT-HA) before the Mobile-Home authentication extension.

[0230] As can be seen from FIG. 4 , the format of the New Session Key Request Extension is as follows: 1

[0231] This is an example on use of a vendor specific extension. Alternatively, another type of mobile IP specified extension can be used.

[0232] The format of the New Session Key Reply Extension is shown in FIG. 5 . The FA may insert the New Session Key Reply extension with sub-type 1 (MT-FA) in a Registration Reply after the Mobile-Home authentication extension (if present) and before the Mobile-Foreign authentication extension (if present). The HA may insert the New Session Key Reply with sub-type 2 (MT-HA) in a Registration Reply before the Mobile-Home authentication extension.

[0233] As can be seen from FIG. 5 , the format of the New Session Key Reply Extension is as follows: 2

[0234] The format of the SRES extension is shown in FIG. 6 . The MT may place the SRES extension with sub-type 1 (MT-FA) in a Registration Request after the Mobile-Home authentication extension and before the Mobile-Foreign authentication extension (if present). The FA must remove this extension before forwarding the Registration Request to the HA.

[0235] The MT may place the SRES extension with sub-type 2 (MT-HA) in a Registration Request before the Mobile-Home authentication extension.

[0236] As can be seen from FIG. 6 , the format of the SRES extension is as follows: 3

[0237] In another embodiment of the invention, the shared session key exchange messages between the MT and the FA are transmitted by extending agent discovery messages to include IMSIs and RANDs.

[0238] In yet another alternative embodiment, an opaque authenticator field is used in the authentication extension. The beginning of this extension is used for sending RANDs, key lifetimes and other shared session key exchange parameters. The key exchange parameters are included in the calculation of the authenticator.

[0239] If the parameters are transmitted in a separate extension before the authentication extension, the data for key exchange becomes automatically included in the computation of the authentication extension. Furthermore, using separate extensions makes the system easier to implement. The authenticator is the result of the MAC function, for example a SIGNrand as computed according to step 2.

[0240] In a further embodiment, instead of using well-known SPIs for the SIM-generated security contexts, SPIs are communicated in the new shared session key exchange messages.

EXAMPLE 2

A Wireless LAN

[0241] FIG. 7 shows an architecture of a mobile communication system according to another embodiment of the invention. The system comprises a mobile node MT that is a data terminal, two public Wireless IP access networks (WISPs) WISP 1 and WISP 2 , the Internet INET, a first GSM telecommunications network GSM_A and a second GSM telecommunications network GSM_B connected to a GSM core GSMCORE.

[0242] The public wireless IP access networks (WISP 1 ,WISP 2 ) offer wireless broadband IP services to allow the MT to roam in public hot spots, such as hot spots located, for example, to hotels and airports. Each WISP can be operated either by a GSM telecommunications network operator or by a private ISP with a roaming agreement with a GSM telecommunications network operator. The roaming agreement is essential for SIM authentication.

[0243] The MT functions as a mobile node. It can connect to a WISP. The MT can also roam from one network to another using a known technique. In WLAN, the roaming from one WLAN hot spot to another is referred to as WLAN roaming service. The WISPs have access to the Internet INET.

[0244] The MT has an equipment part ME and SIM_B provided for use with the second GSM telecommunications network GSM_B. The MT may not be a GSM compliant mobile station. In this case a user of the MT can access the second GSM telecommunications network GSM_B by providing a GSM mobile station with the SIM_B. Indeed, in this example, the MT is a laptop computer equipped with a WLAN adapter card (not shown) and a smart card reader (not shown) that can use the SIM_B. Alternatively, the MT is a device having a GSM mobile station part for communicating with GSM telecommunications networks and a WLAN terminal part for communicating with WLANs.

[0245] Both GSM telecommunications networks GSM_A and GSM_B comprise respective Mobile Switching Centres MSC 1 and MSC 2 . The GSM core couples these MSCs together. Furthermore, the first GSM telecommunications network has a GSM/GPRS Authentication and Billing GateWay (GAGW) coupling it to the Internet INET. The GAGW is the GSM telecommunications network operator's entity which provides the GSM authentication services to WISPs and collects charging information.

[0246] GSM_B is connected to the GSMCORE and can further be connected through the GSMCORE and the GAGW to the WISP 1 (to which the MT is connected) and to the MT for authentication and billing purpose as will be described in more detail later.

[0247] A GSM/GPRS -SIM based user mobility management functionality (user authentication and billing) can be used for public WLAN access zone authentication and billing functions. The SIM based authentication provides a relatively trustworthy verification of the subscriber's identity (authentication) for charging of the use. The GSM core GSMCORE provides roaming services for a GSM mobile station roaming between various operator networks. Advantageously, the roaming service is implemented using existing SIM cards and the GSM infrastructure. Consequently, the WISP roaming should not require any extra security keys from the MT. Furthermore, all the GSM users who obtained WLAN roaming service from their home operator have requisite the MT, SIM and necessary roaming software to be able to access the public network. A home operator provides the roaming MT with SIM_B for authenticating with it. GSM_B is alternatively a GSM telecommunications network supporting GPRS.

[0248] The operation of the system of FIG. 7 will now be described. The user has a GSM agreement with the operator of the GSM_B that is the user's home network operator. The network operator B has signed a roaming agreement with the operator A of GSM_A. The GSM telecommunications network operator A has partner arrangements with the operators of WISP 1 and WISP 2 , referred to, respectively, as operators C and D. The roaming user with the SIM_B may roam from WISP 1 to WISP 2 . Both WISPs send authentication request messages to the operator of GSM_A. The GSM core network roaming functionality is used for relaying the authentication messages to the subscriber's home operator (operator of GSM_B). The architecture allows users of either GSM telecommunications network to roam with their MTs between WISPs, although the WISPs have direct connection only to operator A network GSM_A.

[0249] A roaming user need not have a pre-established customer relationship with a WISP. Instead, the roaming user may rely on his customer relationship with his home GSM telecommunications network in order to provide authentication and billing in the WLAN. WISP access is charged to the roaming user's GSM bill via a GSM telecommunications network operators' authentication gateway.

[0250] Here, these roaming services are used for allowing an MT to be authenticated and charged using a SIM both for accessing the GSM core as well as public IP access networks. The GSM telecommunications network operator bills the user for both the authenticating/roaming services and for the use of public IP access networks. Then, the GSM telecommunications network operator reimburses the use of public IP access networks for their operators.

[0251] In an alternative embodiment of the invention, the GSM telecommunications network operator may provide the subscriber with a WISP roaming SIM, which does not allow use of the GSM radio services. Such a dedicated SIM can be used to authenticate and debit services provided by a WLAN.

[0252] As is known from the GSM, the home GSM network stores customer information, such as authentication codes and user identity. Typically, this information is stored in a GSM Home Location Register (HLR) of an MSC. The GSM telecommunications network operator provides the IP based authentication and charging interface for one or several WISP operators, possibly also or only for corporate access solutions.

[0253] The GAGW supports seamless roaming between various GSM telecommunications network operators. The WISPs send all the authentication and billing information to the GAGW. The GAGW uses GSM core signaling known from GSM to convey the authentication and billing information to the corresponding home GSM telecommunications network operator. The signalling of billing information between different GSM telecommunications networks can be arranged in a manner similar to conventional roaming of a mobile telephone in a foreign GSM telecommunications network. In this case, the foreign GSM telecommunications network charges the home GSM telecommunications network for its service in arranging the telephone call.

[0254] In the system of FIG. 7 , the home operator stores the charging records and sends the bill to the user. The WISP generates a billing record describing the billed services. The billing can be based on any of the known principles or combination of them, for example on flat rate, usage time, number of packets or access bandwidth. The GSM network (GAGW) transmits the WISP originated records to the existing GSM billing system.

[0255] The MT supports authentication by using a SIM card. In an alternative embodiment, the MT supports one or more other authentication mechanisms, for example smart card authentication for corporate network access. Such an MT contains authentication software and the smart card but need not have keys for public access or any other security association.

[0256] FIG. 8 shows significant functional blocks of the system of FIG. 7 . FIG. 8 only shows a single WISP although it is understood that more than one WISP and more than one GSM telecommunications network may be present. FIG. 8 shows three important functional elements of the system: the MT, a Public Access Controller PAC and the GPRS/GSM Authentication and Billing Gateway GAGW. The GAGW is a dedicated entity of the GSM telecommunications network that interfaces the GSM/GPRS network with an IP network (for example, the Internet or a wide area IP network). The GAGW also offers the necessary WLAN-cellular roaming functions, in particular those related to authentication and billing services.

[0257] The PAC is the WISP's network entity which controls access from the radio access network to the Internet services. In this example, the PAC allocates an IP address to the MT and authenticates the MT before connection to the Internet is established. The PAC relays the authentication messages between the MT and the GAGW, collects the billing record and sends it to GAGW. The PAC also relays user data traffic between the MT and the Internet.

[0258] The SIM authentication is a complementary service for the PAC and the PAC supports additionally other authentication mechanisms such as password based authentication.

[0259] The interfaces of the system will now be described.

[0260] The MT-PAC interface is an IP based interface that is provided with authentication functionality. The authentication is designed so that it can be embedded in a well-known standard IP protocol or implemented as an extension to the existing protocol. The MT and PAC are identified using their IP addresses in this interface.

[0261] The PAC-GAGW interface is an IP based interface that uses a suitable authentication protocol. Typically, a single GAGW supports several PACs simultaneously. The GAGW identifies various PACs by using their IP addresses. In this interface, the MT identification is based on an IMSI code stored on the SIM_B.

[0262] The GAGW-HLR interface is implementation and vendor specific. The GAGW hides the cellular infrastructure from PACs. Therefore, the PAC-GAGW interface is always the same although the underlying cellular network may be of a different type (GSM, GPRS) or provided by a different vendor.

[0263] FIG. 9 shows the major signalling steps of the system of FIGS. 7 and 8 . The process of authenticating the MT to the PAC is typically triggered when the MT attempts to connect to the public access network. In this case, the MT acquires an IP address via a dynamic host configuration protocol (DHCP) server (not shown). The DHCP protocol and appropriate servers are well known in the art. The authentication has to be completed before the network beyond the PAC can be accessed. The MT triggers the authentication by roaming software. In an alternative embodiment, the authentication is automatically triggered when the MT tries to access to the network using SIM authentication and the roaming application is running.

[0264] An overview of the authentication is next explained by reference to the messages used during the authentication process:

[0265] 301. The MT communicates with the PAC to connect to the WISP 1 and to obtain an IP address from a DHCP server.

[0266] 302. The PAC sends information concerning the supported authentication mechanisms, such as SIM authentication, Public Key Infrastructure (PKI) or pre-shared key.

[0267] 303. The MT detects that SIM authentication is supported. The ME requests the IMSI from the SIM_B.

[0268] 304. The SIM_B responds to the IMSI request 303 by sending the IMSI to the ME.

[0269] 305. The MT forms a Network Access Identifier that is the IMSI in a Network Access Identifier (NAI) format, as explained in beginning of description of the example 1. The MT establishes a dynamic security association with the PAC, for example using Diffie-Hellman, and sends the NAI encrypted over the temporary secure channel. In an alternative embodiment, the NAI is sent as cleartext without encryption.

[0270] 306. The PAC decrypts the NAI, and forwards it in a data packet, again encrypted, to the GAGW over the secure PAC-GAGW interface. The IP address of the GAGW is statically configured in the PAC. A secure channel is formed between the PAC and the GAGW using their previously arranged shared secret.

[0271] 307. The GAGW verifies that the data packet came from a valid PAC, decrypts the packet, checks the NAI, extracts the IMSI and sends the IMSI with an authentication request to the nearest MSC. Next, the MSC analyses the IMSI to find out the home HLR of the subscriber indicated by the IMSI. Then, the MSC forwards the authentication request to the home HLR.

[0272] 308. The home HLR forms a set of one or more GSM authentication triplets (RAND, SRES, Kc) and sends the set to the originator MSC which forwards the set to the GAGW.

[0273] 309. The GAGW forms a packet containing the RANDs and a cryptographic checksum of the RANDs, generated using at least the Kcs. The GAGW preserves the SRESs for later use in a subsequent step 314.

[0274] 310. The PAC decrypts the packet and relays the RANDs and the cryptographic checksum to the MT.

[0275] 311. The MT inputs the RANDs to the SIM_B, which calculates corresponding Kc and SRES values.

[0276] 312. The MT checks that the Kcs match with the cryptographic checksum given by the PAC. If they match, the MT knows that the PAC has a connection to the HLR and so the PAC can be trusted.

[0277] 313. The MT generates a cryptographic checksum for the SRESs with Kcs and sends the checksum to the PAC.

[0278] 314. The PAC relays the checksum of the SRES to the GAGW. The GAGW checks whether the checksum matches with the SRESs it received from the MSC in step 308. If it matches, the GAGW sends an acknowledge message ACK to the PAC. If it does not match, then the GAGW sends a negative acknowledge NACK to the PAC.

[0279] 315. If the PAC receives a positive acknowledge message ACK confirming successful authentication, it completes the authentication by opening the access to the Internet. If the PAC receives a negative acknowledge message NACK, it refuses to open access to the Internet.

[0280] In an alternative embodiment, the IMSI is used in the preceding steps instead of the NAI.

[0281] The following tables list the parameters that are carried between elements of the system: 4

[0282] 5

[0283] 6

[0284] Advantageously, an optional user_class parameter is used for defining the quality of service, for example the maximum bandwidth for a particular user.

[0285] FIG. 10 shows a detailed signalling chart of an authentication of the system of FIGS. 7 and 8 . The chart presents the following steps:

[0286] (Step 401) The MT sends an MT originated authentication starting request MT_PAC_AUTHSTART_REQ containing the NAI having the IMSI. The request typically also contains a protection code MT_RAND (known also as nonce in the context of mobile IP).

[0287] (Step 402) The PAC receives the MT_PAC_AUTHSTART_REQ from the MT and requests for GSM triplets by sending to the GAGW a message PAC_GAGW_AUTHSTART_REQ, also containing the NAI and the MT_RAND.

[0288] (Step 403) The GAGW obtains the GSM triplets from the home GSM telecommunications network. One triplet suffices, but the GSM telecommunications network may return a plurality of triplets, in which case either some of the triplets are discarded or stored for later use, or more advantageously, they all are used to generate a stronger key. The home GSM telecommunications network is recognised using the NAI.

[0289] (Step 404) The GAGW generates K, using an encryption algorithm, of at least the GSM session key(s) Kc. Advantageously, the MT_RAND is also used in the encryption. The GAGW encrypts the GSM RAND(s) of the GSM triplets, computes a cryptographic checksum, or a Message Authentication Code MAC, based on the RAND(s) and the K, and prepares an authentication start response message GAGW_PAC_AUTHSTART_RESP. The encryption between the GAGW and the PAC is based on their own shared secret.

[0290] (Step 411) The GAGW sends to the PAC an authentication start response message GAGW_PAC_AUTHSTART_RESP containing the RANDs, the MAC, the MT_RAND, a billing information code and a billing information MAC computed for the billing information code. Typically, the authentication start response message additionally contains a field for a session timeout parameter for determining the validity period of the new K to be generated and a field for the state of the session.

[0291] (Step 412) The PAC forwards to the MT the authentication start response message GAGW_PAC_AUTHSTART_RESP as a PAC_MT_AUTHSTART_RESP message.

[0292] (Step 413) The MT tests with the SIGNrand that the parameters carried by the GAGW_PAC_AUTHSTART_RESP and by the PAC_MT_AUTHSTART_RESP indeed originate from the GSM telecommunications network.

[0293] (Step 414) The MT handles the billing information it received from the GAGW. Typically, it provides the user with information relating to the price of the service requested by the user. Usually, this price is based on at least one of the following: a flat rate fee, a time based billing, number of data packets sent to or from the MT, and the Quality of Service QoS. The MT then asks the user whether the service should be obtained with the price given. The MT receives an answer from the user.

[0294] (Step 415) The MT generates a MAC of the SRESs to be used for responding to the GAGW.

[0295] (Step 416) The MT generates then an access secret Kpac_MT using at least the Kcs.

[0296] (Step 421) The MT generates and sends an MT_PAC_AUTHANSWER_REQ message to the PAC. The message contains in the state field an answer of the user showing whether the user accepted the billing for the service, the MAC of the SRESs, a MAC of the billing code, and the MT_RAND (as all the messages sent during an authenticating session).

[0297] (Step 422) The PAC generates a PAC_GAGW_AUTHANSWER_REQ containing the data of the MT_PAC_AUTHANSWER_REQ message and additionally the NAI and the IP address of the PAC.

[0298] (Step 423) The GAGW tests the MAC of the SRESs to verify that the data sent by the MT carried by the PAC_GAGW_AUTHANSWER_REQ has not been tampered with.

[0299] (Step 424) If the GAGW gets a positive answer to the test of the previous step, it generates the access key Kpac_MT in a manner similar to that used by the MT in step 416 and then proceeds to the step 431.

[0300] (Step 431) The GAGW sends to the PAC a message GAGW_PAC_AUTHANSWER_RESP_OK. The message contains the MT_RAND and codes filter_id, Kpac_MT and SIGNresult. The filter_id code is optional and indicates the user class of the subscriber. This can be used in defining a QoS, for example a high quality connection for more paying business users. The SIGNresult is a MAC of the data in the message for ultimately verifying to the MT that the reply from the GAGW is not altered on the way to the MT.

[0301] (Step 441) The PAC responds to the GAGW by a PAC_GAGW_STARTBILLING_REQ message requesting the GAGW to start the billing. The message contains the NAI and a session ID (the MT_RAND).

[0302] (Step 442) The GAGW checks the answer from the MT for verifying that the MT has permitted the billing.

[0303] (Step 451) If the MT has permitted the billing, the GAGW sends to the PAC a message GAGW_PAC-STARTBILLING_RESP_OK to indicate the start of billing.

[0304] (Step 452) The PAC sends to the MT a PAC_MT_AUTHANSWER_RESP_OK message containing the SIGNresult.

[0305] (Step 453) The MT receives the PAC_MT_AUTHANSWER_RESP_OK message and checks the SIGNresult it contains. If the SIGNresult is correct, the MT can inform the user of the start of billing.

[0306] The MAC of the billing code is computed at least using the Kcs so that the PAC cannot tamper with the billing code.

[0307] In the message PAC_MT_AUTHANSWER_RESP_OK, the MT is notified of the term of the authentication. The MT re-authenticates itself before the authentication term expires. If it does not re-authenticate, the connection of the MT to the PAC is released and the MT can authenticate itself again.

[0308] Advantageously, the MT receives billing information and decides how to handle it. Advantageously, the user of the MT can define a billing information handling policy. This policy can be used to define, for example, that no billing information is presented to the user in a re-authentication or normal authentication case. The handling of the billing information does not affect the protocol of messaging between the different entities (MT, PAC, GAGW, MSC and HLR).

[0309] FIGS. 11 a and 11 b form together a flow chart showing the functionality of the PAC during the authentication. In this figure, all of the blocks relate to the PAC except those that are marked as “MT” or “GAGW”. The drawing will be described by referring to each of the blocks by their reference sign.

[0310] The operation starts from block 501 . The MT requests authentication from the PAC by sending an MT_PAC_AUTHSTART_REQ message containing the MT_RAND and the NAI to the PAC, thus triggering the authentication process there (block 511 ). The PAC maps (block 512 ) an IP address MT_IP for the MT. The PAC checks first whether it already has an IP address mapped for that NAI. If it has, it retrieves the mapping from a database record (block 513 ). Otherwise it obtains an IP address and stores it with the NAI to a database for future use.

[0311] After mapping (block 512 ) of the IMSI with an IP address, the PAC relays (block 514 ) the NAI to the GAGW (block 541 ) in a PAC_GAGW_AUTHSTART_REQ message. The GAGW responds (block 542 ) by a GAGW_PAC_AUTHSTART_RESP message containing a random number RAND to be used as a challenge. In block 515 , The PAC receives the challenge and maps a session ID code SESSION_ID to the MT_IP. Next, the PAC updates the database record (block 516 ) by storing the SESSION_ID with the MT_IP and the IMSI. Then, the PAC sends (block 517 ) the challenge RAND to the MT in a PAC_MT_AUTHSTART_RESP message. The MT receives (block 502 ) the message, generates and responds (block 503 ) with an MT_PAC_AUTHANSWER_REQ message containing a cryptographic checksum SIGN_SRES corresponding to the challenge and the challenge itself. The PAC receives the SIGN_SRES and relays (block 518 ) it to the GAGW which checks (block 543 ) whether it is correct. The GAGW returns (block 544 ) to the PAC a GAGW_PAC_AUTHANSWER_RESP message to inform the PAC whether the SIGN_SRES is correct. Alternatively, the GAGW may compute the correct SIGN_SRES and return it to the PAC so that the PAC itself verifies whether the MT generated SIGN_SRES is correct. In either case, the PAC verifies (block 519 ) the response from the GAGW and decides (block 520 ) next actions based on the response. If the response is positive, that is successful authentication, then the PAC proceeds to block 523 to start billing. Otherwise, the execution proceeds to block 521 . There, a NACK is sent as a PAC_MT_AUTH_ANSWER_RESP_ERR to the MT to indicate an error in the authentication and the SESSION_ID is removed (block 522 ) from the record in which it was stored.

[0312] Next, the steps related to billing are explained. In block 523 , a message PAC_GAGW_STARTBILLING_REQ is sent to the GAGW. The message informs the GAGW the possibility to apply charges to the account of the user of the MT to be added in a GSM invoice. The GAGW receives (block 547 ) this message and replies with a message GAGW_PAC_STARTBILLING_RESP as a confirmation. The message is verified (block 524 ) by the PAC, and in case of a denial instead of confirmation, the PAC returns to block 521 . Otherwise, (block 526 ) an acknowledge message PAC_MT_AUTHSTART_RESP_OK is sent to the MT to confirm the start of possible billing and a timer is started.

[0313] In the next phase, the PAC remains idle and provides periodical billing updates. These updates are triggered by debited events, such as transmission or reception of data packets. The PAC may combine the charges and, only after a certain period of time or after reaching of a certain triggering amount of charge, perform a billing update corresponding to the lump sum thus gathered. When billing an event, the PAC sends a PAC_GAGW_UPDATEBILLING_REQ to notify the GAGW about the billing update. The GAGW receives (block 547 ) this message and responds (block 548 ) by a receipt message GAGW_PAC_UPDATEBILLING_RESP. The PAC receives (block 528 ) the receipt and checks (block 529 ) if it is positive. If the receipt is negative, the PAC prevents (block 532 ) MT for transferring data packets to and from the WISP, sends a billing stop to the GAGW, and sends (block 533 ) an authentication request to the MT for its re-authentication. On the other hand, if the receipt is positive in block 529 , the PAC checks (block 530 ) the timer to detect a session timeout. If a timeout is detected, the PAC continues to block (block 532 ) and proceeds as described above. If no timeout is detected, the PAC operation returns to block 527 .

[0314] FIGS. 12 a to 12 d form together a flow chart showing the functionality of the GSM/GPRS Authentication and billing Gateway (GAGW) during authentication in the system of FIG. 7 . The flow chart shown in FIGS. 11 a and 11 b illustrated the functionality of the PAC and here the same procedure is considered from the GAGW's point of view. The procedure starts from block 601 . The PAC sends to the GAGW the PAC_GAGW_AUTHSTART_REQ message containing the IMSI and the domain name of the MT (defined by the SIM_B). The GAGW checks (block 611 ) whether the MT is already authenticated. If yes, then an authentication validity timer (described later) is stopped (block 613 ) and existing user information is used (block 615 ). Otherwise, a temporary user ID is allocated to the MT identified by the IMSI and the subscriber's data (IMSI and corresponding user ID) is stored (block 619 ) in a record of a database.

[0315] Then, the MT authentication is started (block 621 ). The GAGW requests (block 623 ) the GSM triplets from the home GSM telecommunications network of the subscriber by a GAGW_MSC_DATA_REQ message sent to the closest MSC 681 . The MSC responds (block 682 ) by an MSC_GAGW_DATA_RESP message containing one or more GSM triplets and additionally information concerning whether or not the MSC allows billing for the use of the PAC by that user. The GAGW verifies (block 627 ) the response. If the user is not authorised to the billing service, or alternatively, if the reply timer expires (block 625 ), the GAGW sends (block 629 ) an authorisation error message GAGW_PAC_AUTHSTART_RESP_ERROR to the PAC (block 602 ). Otherwise, the timer has not expired and the verification of the response is positive and the procedure continues from block 633 . The GAGW retrieves from the database (block 635 ) the MT_RAND and at least one GSM triplet associated to the subscriber being authenticated. Then the GAGW calculates a SIGNrand using a hash function and the Kc and RAND of (each of) the GSM triplet(s) used. This certain number of Kcs is denoted by n*Kc. Here, the asterisk does not refer to a multiplication but to the number of different valued parameters Kc. The same applies to all the other occurrences of asterisk as well. For multiplication, a dot “·” is used instead of an asterisk. As the MSC typically provides one to four different GSM triplets in response to one request, one or more triplets can be used for authentication. By using two or more triplets instead of just one, enhanced security is obtained because the keys are longer and the recurring period, in which the same key is used again, increases. This further allows increase of the validity term of the au