ES2616499T3 - Devices and method for authentication in heterogeneous IP networks - Google Patents

Abstract

A system for authenticating and authorizing network services comprising: a mobile device, said mobile device being configured to determine a type of network access upon receipt of an information message indicating at least one type of network access; create a startup message that contains at least one user identity; and encapsulating the start message in an authentication message compatible with an access network that is identified in the information message, said system further comprising: an access controller for reading the encapsulated message from the mobile device and forwarding the encapsulated message to an authentication server that is identified in the encapsulated message.

Description

image 1

DESCRIPTION

Devices and method for authentication in heterogeneous IP networks

5 Background of the invention:

Field of the invention:

The present invention relates to a system and a method for authenticating and authorizing network services.

Description of the related technique:

In future 3G (third generation) system architectures, network services can be provided through many different network access methods, for example CDMA2000 (Code Division Multiple Access,

15 version 2000, Multiple Access by Code Division, version 2000), network based on non-cellular IP, LAN (Local Area Network) Wireless 802.11, Bluetooth or Ethernet. However, in 3GPP2, mobile devices are currently only able to access network services using CDMA2000 access methods. Therefore, in order to provide network services more reliably and efficiently, there is a need to allow mobile devices the ability to authenticate through different types of access networks such that different access networks can Authorize services.

There is no universal authentication process to authenticate a user (terminal) in any type of network access technology. And this makes it difficult to gain access and mobility of sessions in a multiple access scenario. An exchange of messages between the network and the mobile station is necessary, to allow a

25 provision of service in a generic IP network, cellular or non-cellular, to use the same authority. However, there is a problem that it is necessary for the terminal to use some other method to authenticate itself with the operator's network and receive service if it is not using the CDMA2000 cellular network.

Similar problems occur when using a RUIM microplate that contains a user's identity for the use of mobile cell phones in CDMA networks, similar to how SIM (Subscriber Identity Module) cards contain the Identity of a user in the GSM networks (Global System for Mobile communication, Global System for Mobile communications). RUIM is described in 3GPP2 document C.S00230.

35 For example, if the terminal is using a Bluetooth or WLAN radio (Wireless LAN, Wireless LAN) for its connections, for example, with the Internet, and is using the same registration identity from the RUIM module, it needs a Separate non-cellular protocol to achieve this, which is the problem addressed by the present application.

The document "Dynamic Network Interface Selection in Multi Homed Mobile Host", XP010626772 describes an interface selection mechanism for multi-base mobile hosts. This mechanism allows dynamic decision making during the operation of a mobile device.

US 2003/119481 A1 discloses a method of how a terminal equipment can select a network

45 private public land mobile. In detail, the terminal equipment selects a public mobile network by means of a comparison of a received public land mobile network identifier and public land mobile identifiers that are stored in the terminal equipment.

Summary of the invention:

The objective underlying the present invention is to provide a possibility for a mobile device to authenticate through different types of access networks.

The present objective is achieved by means of a system as set forth in claim 1, such a method.

55 as set forth in claim 14, an access control device as set forth in claim 22, or by a subscriber device as set forth in claim 29.

Therefore, according to the invention, the mobile device receives information regarding a type of network access (this information message may be an explicit message sent to the mobile device or it may be information found generally available on the network). The mobile device creates a startup message that contains the user identity and sends it in an authentication message to an access controller. The access controller evaluates the startup message and forwards it to the correct authentication server.

Therefore, it is necessary for the mobile device to address only one access controller, which forwards the message from

65 authentication to the correct authentication server. That is, it is not necessary for the mobile device to find how the authentication server is to be achieved.

image2

In addition, a plurality of authentication servers for different services can also be provided. In accordance with the prior art as described above, the mobile device would have to send a plurality of authentication messages to all the different authentication servers whose services are to be used. In contrast to the above, in accordance with the present invention, the mobile device only has to send

5 a start message in which a plurality of authentication messages that correspond to the authentication servers are encapsulated.

Therefore, the authentication procedure is simplified. In addition, the traffic load on the network is also reduced because only a single start message is required despite the use of a plurality of services.

Some advantageous developments are defined in the dependent claims.

For example, the information message may indicate an extensible authentication protocol (EAP) support. 15 The information message can be issued when the mobile device enters a network.

The start message may contain a client identifier option message and an extensible authentication protocol support identity option message, wherein said messages contain information regarding at least one of client type, identity User information and information on how to approach the customer within the core IP network (referred to in the following also as core address information).

A protocol between the mobile device and the access network may comprise at least one of 25 network layer protocols such as UDP, ICMP, ICMPv6 or link layer protocols such as IEEE 802.1x, IEEE 802.11i and a Bluetooth profile.

An authentication mechanism that is applied may comprise an extensible authentication protocol (EAP).

An authentication mechanism that is applied can be an authentication mechanism that uses a removable User Identity Module (RUIM) that applies a Cellular Authentication and Voice Encryption algorithm. , Or an applicable USIM that applies the AKA algorithm

35 Brief description of the drawings:

Figure 1 shows a reference model of CDMA2000 multiple access network in accordance with the embodiments of the invention;

Fig. 2A and 2B a signal flow according to a first example of a first embodiment of the invention;

a device means for determining a type of network access upon receipt of an information message indicating at least one type of network access, to create a startup message containing at least one identity

45, and to encapsulate the start message in an authentication message compatible with an access network that is identified in the information message; and an access controller to read the encapsulated message from the mobile device means and to forward the encapsulated message to an authentication server that is identified in the encapsulated message.

In addition, the present invention proposes a system for authenticating and authorizing network services, in which the network comprises a mobile device and an authentication control function, in which the mobile device comprises determining means for determining a type of access. network via the mobile device, upon receipt of an information message indicating at least one type of network access; creation means for creating a start message containing at least one user identity; and ones

55 encapsulation means for encapsulating the start message in an authentication message compatible with an access network that is identified in the information message; and the access controller means comprise reading means to read the encapsulated message from the mobile device and to forward the message to an authentication server that is identified in the encapsulated message.

In connection with this, it is noted that the message that is read by the access controller is encapsulated in another type of message, which the access controller will send, accordingly, to the authentication server. The invention also proposes an access control device comprising:

65 receiving means for receiving a start message in which an authentication message is encapsulated, processing means for reading the encapsulated message, and forwarding means for forwarding the encapsulated message to an authentication server that is identified in The encapsulated message.

image3

5 Likewise, in this case, the message that is read by the access controller can be encapsulated in another type of message for sending to the authentication server. In addition, the invention proposes a subscriber device comprising:

determining means for determining a type of network access upon receipt of an information message indicating at least one type of network access; creation means for creating a start message containing at least one user identity; encapsulation means for encapsulating the start message in an authentication message compatible with an access network that is identified in the information message; and a means of sending to send the start message to an access control device.

In addition, the invention proposes a routing device comprising creation means for creating an information message indicating at least one type of network access, and sending means for sending the information message to a subscriber device.

Brief description of the drawings:

Figure 1 shows a reference model of CDMA2000 multiple access network in accordance with the embodiments of the invention;

Figure 2A and 2B a signal flow according to a first example of a first embodiment of the invention;

Fig. 3A and 3B a signal flow according to a second example of the first embodiment of the invention;

Figure 4A and 4B a signal flow according to a first example of a second embodiment of the invention;

5A and 5B a signal flow according to a second example of the second embodiment of the invention, and

Figures 6A, 6B and 6C an access controller, a mobile station and a usable router in accordance with the embodiments of the invention.

Detailed description of the preferred embodiments:

As described above, according to the invention, there is provided a system to authenticate and authorize network services, comprising: a router to issue a router advertisement containing indicating a type of network access and an extensible authentication protocol support; a mobile device that

45 upon receipt of the router announcement determines the type of network access and creates a startup message that contains a client identifier option message and an EAP identity option message (Extensible Authentication Protocol) , which contain client type, user identity and core address information, additionally encapsulates the start message in an IPv4 or IPv6 protocol compatible with an access network that is identified in the router announcement, for example UDP, ICMPv6 (Internet Control Message Protocol version 6, Internet Control Message Protocol version 6 (for IPv6)), or a link layer protocol such as IEEE 802.1x, IEEE 802.11i or a suitable Bluetooth profile, and an access controller for reading the encapsulated message from the mobile and forward the message je encapsulated to an authentication server that is identified in the encapsulated message.

55 Several authentication mechanisms can be used. In the following description of preferred embodiments, the authentication mechanism of EAPAKA (Authentication and Key Agreement) using a USIM (Universal Subscriber Identity Module) (the Universal Subscriber Identity Module) (the Universal Subscriber Identity Module) is used as examples. first embodiment) and an authentication mechanism using RUIM (Removable User Identity Module) that applies a CAVE algorithm (Cellular Authentication and Voice Encryption, Cellular Authentication and Voice Encryption) (the second embodiment).

A first embodiment refers to a combined use of CDMA2000 cellular and non-cellular packet data networks and, in particular, refers to user authentication and service authorization using a Universal Subscriber Identity Module (USIM, Universal Subscriber Identity Module) when communicating through

65 multiple types of access networks using the EAPAKA specification. This capability is useful for automating key management by leveraging the existing key infrastructure for non-data authentication, as shown by similar methods in other cellular environments. User authentication and service authorization allows the cellular operator to provide the user with various types of access network, while maintaining a unified service provision, user-based network access management and roaming authentication, while taking advantage of all this authentication / accounting / billing infrastructure

image4

5 existing. The benefit can be summed up as a smart card based CDMA2000 authentication unification for multiple access methods.

The embodiment describes a form of network access, mobility signaling, and other service authentication for WLAN / CDMA2000 users. In particular, according to the first embodiment, a multiple access scheme is provided in which the network authentication from the WLAN, as well as mobility management signaling protection, uses the special combination of AAAv6 protocols ( Authentication, Authorization and Accounting for Ipv6, Authentication, Authorization and Accounting for Ipv6), EAPAKA (Extensible Authentication Protocol Authentication and Key Agreement, Extensible Authentication Protocol and Key Agreement) and Radius, as well as the specific multiple access architecture of CDMA2000 for the

15 method presented.

As described above, in accordance with the first embodiment, the problem that the terminal needs to use some other method to authenticate itself with the operator's network and receive service if it is not required must be solved. You are using the CDMA2000 cellular network. In accordance with the present embodiment, the

The problem is overcome by defining a method to authenticate a user using the EAPAKA specification to be executed through any access technology and medullary provided that the user has a USIM that contains the user's identity, as will be described in The following in detail.

According to the first embodiment, the EAPAKA authentication mechanism (as defined in J. Arkko,

25 H. Haverinen. EAP AKA Authentication (work in progress), Internet Draft (draftarkkopppexteapaka10.txt), Internet Engineering Task Force, June 2003, for example) is applied to authenticate a user on the network that is using any technology network access Therefore, mutual authentication, network authorization and service provision are achieved through an interaction between multiple parties (but not limited to) the following entities: terminal, USIM (Universal Subscriber Identity Module, Identity Module

30 Universal Subscriber), Access Controller, Authentication Gateway and Authentication Center (AuC, Home Location Register, the AuC is located in the HLR)) of the CDMA2000 network. In the following, this is described in detail how this can be achieved.

Figure 1 shows a reference model of CDMA2000 multiple access network, in which also

35 provide, in particular, the access controller (AC) and the Authentication Server (AS).

In the upper left of Figure 1, a visited access provider network (in particular, the service network) is shown. A source radio network (RN) is connected to a service PDSN via a RANPDSN interface (RP interface). A10 and A11 are interfaces for control messages that are defined in CDMA2000. The PDSN (Packet Data Serving Network) acts as a foreign agent, and provides access to the Internet, intranets and Wireless Application Protocol (WAP) servers for mobile stations and the like. The source RN is also connected to a Mobile Services Switching Center (MSC) through

45 of an A1 interface.

The MSC is connected to the mobile provider's own access provider network through an SS7 network. The own access provider network comprises a Own Position Register (HLR) and an Authentication Center (AuC), which is necessary according to the realizations that

50 are described in the following.

In the central left part of Figure 1, a target visited access provider network is shown, with which a mobile station can be connected. The target access provider network comprises a target RN and a target PDSN, which are connected via an RP interface similar to what it is in the provider network of

55 service access accessed. Both PDSNs are also connected to an IP network (Internet Protocol version 4 (IPv4, Internet Protocol version 4) and / or Internet Protocol version 6 (IPv6, Internet Protocol version 6)). For this connection, a Pi interface is defined in CDMA2000. The service PDSN is also connected to an AAAL (Local AAA, Authentication, Authorization and Accounting), AAA (Authentication, Authorization and Accounting) Local server), which also has access to the IP network.

60 On the right side of Figure 1, the own access provider network described above is shown, an own IP network that is connected to the IP network and comprising an AAAH (Home AAA, Own AAA), and an intermediary network comprising an AAA server. In addition, the Own Agent (HA) is illustrated, which can be arranged in the IP network itself, in a private network or in the access provider network

65 own.

image5

An additional access possibility for the mobile station is shown in the lower left part of Figure 1, in which an additional target visited access provider network is illustrated. This is the scenario for the embodiments described in the following. In the present case, the mobile station connects to a target WLAN (Wireless Local Area Network). The WLAN is connected by means of a

5 IP interface with an Access Controller (AC) that will be described in more detail later. The AC is connected to an Access Server (AS), which provides a connection to the IP network and also to the own access provider network, in particular with the AuC of the own access provider network.

The new functionalities (that is, the devices comprising the new functionalities) according to the embodiments described in the following are indicated by striped boxes. That is, these new functionalities are found in the AC and the AS. Additionally, optionally, the AS can be provided in the AAAH of the home IP network.

15 The terminal is a device that needs to be able to access all types of IP networks, including the IP network that is part of the cellular network and also the OWLAN access network (Operator Wireless LAN, Wireless Operator LAN ). It is also necessary for the terminal to be able to execute the AKA algorithms by having a USIM. And it is also necessary for this to execute the IPv6 protocol. If MIPv6 is used, this process can also be used to dynamically create Security Associations between the Agent and the terminal. The EAPAKA specification shows how AKA authentication can be performed using EAP messages. In accordance with the present embodiment, it is described how this specification can be used for authentication irrespective of access technology.

When the terminal enters a network capable of this functionality, it receives an Announcement from

25 Router (RA), which includes a support indication, for example, a router or agent announcement option from the local AC (Access controller) that indicates this type of AAA support ( Authentication, Authorization and Accounting, Authentication, Authorization and Accounting). This initiates authentication, key generation and service provision in accordance with the present embodiment.

EAP messages are encapsulated either in AAAv6 messages or in the WLAN link layer (such as in IEEE 802.1x, IEEE 802.11i or in a suitable Bluetooth profile message, in PPP EAP encapsulation, or in any appropriate last hop PANA protocol message, as normalized in the future) when these are exchanged between the terminal and the access controller, which is the network element responsible for controlling users' access to the network. IP. If AAAv6 is used, the initial EAP / AKA identity message goes

35 in the EAP Identity message in the AAAv6 message.

Between the access controller and the Authentication Server, EAP messages are carried in a core network protocol such as Diameter or Radius. The CA determines the IP address of the Authentication Server by assigning it from the IMSI (International Mobile Subscriber Identity) and the domain. The Authentication Server has a logical interface with the HLR / Authentication Center (AuC) through the MSC. This acts as a gateway between the MAP protocol (SS7 network) and the authentication protocols used in IP.

A scenario for authenticating the user in an OWLAN network in accordance with the present embodiment is described in the following with message flows.

one.

The terminal sends an access request message (which could be an AAAv6 Request message or any other message to request a network access) to the access controller. The EAP Response / AKA Identity message is inserted in this message. It is also necessary that there is a provision to pass the user NAI in this message.

2.

The access controller picks up the EAP message and places it in a request message (which could be a Diameter AA Request message or a Radius Access Request message) that is sent in the core network to the Authentication Server (AS, Authentication Server). For example, in Diameter, the EAP message would be found in the EAP payload AVP. The access controller resolves which AS the

55 request, based on the domain part of the user NAI.

3. Upon receipt of the message, the AS first identifies the AuC that contains the authentication information for the user. This could be based on the user part of the user NAI. For example, if the user NAI that is used is of the IMSI @ domain form, then the IMSI can be used to identify the user HLR / AuC. This requests the UMTS authentication quintet from the AuC. This quintet consists of five values, namely, a) a RAND network test, b) a response expected by the XRES user, c) a CK encryption key, d) an IK integrity key and e) a token AUTN network authentication. By obtaining these values, it creates the attributes AT_RAND (a random number), AT_AUTN (an authorization vector) and AT_MAC (message authentication code). This calculates and stores the AT_RES value for later use. This creates the EAP / AKA Request / Commissioning message

65 Test containing the value of AT_RAND, the value of AT_AUTN and the value of AT_MAC. Finally, it sends a message, containing the EAP / AKA Request / Test message in it and the NAI that identifies the user (in the User Name attribute), to the AC. The message could be a Diameter AA Response message or a Radius Access Test message. If this is a Diameter message, the EAP message is carried in the EAP payload AVP.

image6

4. The AC sends a message to the terminal containing the EAP / AKA Request / Test Request. This can be

5 a message from AAAv6 or any other network access protocol in use between the terminal and the access controller.

5. When the terminal receives this message, it first extracts the EAP / AKA Request / Test message. This then uses the AKA to calculate the values of AT_RES, giving the values of AT_RAND and AT_MAC that are received within the EAP / AKA / Test 10 Request as an input to the AKA. This also calculates the value of AT_AUTN and compares it with the AT_AUTN that is received in the EAP / AKA / Test Request. If these values match, the EAP / AKA Request / Test message is authenticated successfully, otherwise the authentication message fails. If the values have coincided, it creates and sends a message (AAAv6) to the AC containing the EAP / AKA / Test Response message. The EAP / AKA / Test Response message contains the value of

15 AT_RES calculated.

6.

The AC sends a request message again (Diameter AA Request / Radius Access Request). This time, it contains the EAP / AKA / Test Response.

7.

When the AS receives this message, it compares the value of AT_RES that it had previously calculated with the value of AT_RES in the EAP message received. If the values match, the authentication

AKA 20 succeeds; otherwise, authentication fails. Depending on the result, it sends either an Access Acceptance or an Access Rejection message (in the case of Radius). For Diameter, it sends an AA Response message with the result in the AVP Result Code.

8. Upon receipt of this message, the AC knows whether the authentication was successful or not. The Ac sends the appropriate response message to the terminal. When the terminal receives this message, the access network authentication of

25 OWLAN is complete. If the authentication was successful, the AC will apply a filtering rule that allows packets that are sent from the authenticated terminal to pass.

Next, the above procedure is described in some more detail by referring to the signal flow diagram shown in Figures 2A and 2B. The signal flow diagram illustrates the signals that are

30 exchange between the terminal (term, that is, the UE), the Authentication Center (AC) and the Authentication Server (AS).

In step 2A, the terminal receives a Router Announcement (either unsolicited or requested) from the AC. The Router Announcement (RA) includes the AAA Test Option that contains

35 Local Testing. Before sending the following message, the terminal must have acquired an assigned IP address (in the case of an IPv4 address from, for example, a DHCP server (Dynamic Host Configuration Protocol, Dynamic Computer Configuration Protocol Main) In the case of an IPv6 address, this could be a self-configured address).

40 In step 2B, the terminal deduces from the presence of an AAA indicator in the Router Announcement that an AAA access authentication is necessary. The terminal begins the authentication sequence by sending an AAA Request message (indicated by RQ1) to the AC. The AAA Request contains an AAA Client Identifier Option (indicated in the signal flow diagram as cID) as well as an option that carries the EAP Identity message. Both the AAA Client Identifier Option

45 as the EAP Identity message contains the user's NAI (IMSI @ domain).

In step 2C, the AC obtains the address of the AS from the NAI that is contained in the AAA Client Identifier Option (using a DNS, if necessary) and sends an AAA Request message (AR, AAA Request ) To AS. The AR contains the EAP Identity message (in the EAP payload attribute) and the NAI (in the attribute of

50 User Name) that is received in the AAA Client Identifier Option in step B.

In the 2D stage, the AS performs the following upon receipt of the AR message in stage 2C:

Based on the IMSI part of the NAI, the AS identifies the AuC that contains the authentication information for the user.

This question and get a quintet of UMTS authentication from the AuC. This consists of 5 values:

a) a RAND network test, b) a response expected by the XRES user, c) a CK encryption key, d) an IK integrity key and e) an AUTN network authentication token.

60

This calculates the values AT_RAND (a random number), AT_AUTN (an authorization vector) and AT_MAC (message authentication code).

This calculates and stores the AT_RES value for later use (obtained from the XRES).

This creates the EAP / AKA Request / Test message containing the value of AT_RAND, the value 65 of AT_AUTN and the value of AT_MAC.

image7

This sends an Access Test (AA) message, which contains the EAP / AKA Request / Test (in the specific attribute of the 3GPP2 manufacturer) and the NAI that identifies the user (in the attribute of User Name), to the AC.

5 In step 2E, the AC sends an AAA Response message (RP2), which contains the EAP Request (ERq in the signal flow diagram) / AKA / Test in the AAAv6 Inserted Data Option, an AAA Client Identifier Option containing the NAI and an AAAv6 Test Option, to the terminal. The AAAv6 Test Option contains a Local Test value that is set by the AC.

In stage 2F, the terminal performs the following upon receipt of the AAA Response in stage 2E:

This uses the AKA to calculate the AT_RES values, giving the AT_RAND and AT_MAC values that are received within the EAP / AKA / Test Request as an input to the AKA.

15 This calculates the AT_AUTN value as specified in AKA.

This compares the calculated AT_AUTN value with the value that is received in the EAP / AKA Request / Test. If the values match, the EAP / AKA Request / Test message is authenticated successfully, otherwise the authentication message fails.

It sends an AAA Request message (RQ3), which contains the Local Test in an AAAv6 Test Option, an AAA Client Identifier Option (NAI of the IMSI @ domain form) and a message of EAP Response (ER, EAP Response) / AKA / Testing in the AAAv6 Inserted Data Option, to the AC. The EAP / AKA / Test Response contains the calculated AT_RES value.

25 In step 2G, the CA sends an AAA Request (AR) message to the AS (which is identified by the NAI). The AR message contains the EAP / AKA / Test Response (in the specific attribute of the 3GPP2 manufacturer) and the NAI (in the User Name attribute) that is received in the AAA Client Identifier Option of the AAA Application.

In step 2H, the AS performs the following upon receipt of the AR message in stage 2G:

This compares the value of AT_RES that it has calculated in step D with the value of AT_RES that is

contained in the EAP / AKA Response / Test. If the values match, the authentication of AKA 35 is successful; otherwise, authentication fails.

If authentication is successful, it sends an AA message, which contains the NAI that identifies the user (in the User Name attribute) to the AC. If authentication has failed, then it sends the Access Rejection message to the AC.

In stage 2I, the AC knows, upon receipt of the AA message in stage 2H, that the AKA authentication succeeded. The AC sends an AAA Response message (indicated by RP3 in Figure 2A) with the Code field set to indicate SUCCESS (the value 0), to the terminal. When the terminal receives this message, the OWLAN access network authentication has been achieved. If the authentication was successful, the AC will apply a filtering rule that allows packets that are sent from the authenticated terminal to pass.

45 The following describes how to establish general authentication for mobility bindings according to the first embodiment.

one.

The sequence begins with the terminal by sending a request message (AAAv6, WLAN link layer or any other network access protocol) to the Own Agent (HA, Home Agent). The request contains the user's NAI (IMSI @ domain) as well as an EAP / AKA / Identity Response message inserted.

2.

The HA picks up the EAP message and places it in a request message (which could be a Diameter AA Request message or a Radius Access Request message) that is sent in the core network to the Server

Authentication Server (AS) 55. For example, in Diameter, the EAP message would be found in the EAP payload AVP. The HA resolves to which AS the request should go based on the domain part of the user NAI, because the domain part of the NAI indicates the domain in which the AS resides.

3. Upon receipt of the message, the AS first identifies the AuC that contains the authentication information for the user. This could be based on the user part of the user NAI. For example, if the user NAI that is used is of the IMSI @ domain form, then the IMSI can be used to identify the user HLR / AuC. This requests the UMTS authentication quintet from the AuC. This quintet consists of five values, namely, a) a RAND network test, b) a response expected by the XRES user, c) a CK encryption key, d) an IK integrity key and e) a token AUTN network authentication.

65 By obtaining these values, it creates the attributes AT_RAND (a random number), AT_AUTN (an authorization vector) and AT_MAC (message authentication code). This calculates and stores the AT_RES values and the session key K for later use. This creates the EAP / AKA Request / Test message containing the value of AT_RAND, the value of AT_AUTN and the value of AT_MAC. Finally, it sends a message, which contains the EAP / AKA Request / Test message in it and the NAI that identifies the user (in the User Name attribute), to the HA. The message could be a

image8

5 Diameter AA Response message or a Radius Access Test message. If this is a Diameter message, the EAP message is carried in the EAP payload AVP.

4. The HA sends a message to the terminal containing the EAP / AKA / Test Request. This can be

a message from AAAv6 or any other network access protocol in use between the terminal and the access controller.

5. When the terminal receives this message, it first extracts the EAP / AKA Request / Test message. This then uses the AKA to calculate the values of AT_RES, giving the values of AT_RAND and AT_MAC that are received inside the EAP / AKA Request / Test 15 as an entry to the AKA. Then, this calculates the K value. This also calculates the value of AT_AUTN and compares it to the AT_AUTN that is received in the EAP / AKA / Test Request. If these values match, the EAP / AKA Request / Test message is authenticated successfully, otherwise the authentication message fails. If the values have coincided, it creates and sends a message (AAAv6) to the HA containing the EAP / AKA / Test Response message. The Reply Message from

20 EAP / AKA / Test contains the calculated AT_RES value. The terminal stores the K value for future use for the Security Association (SA) with the HA.

6. The HA sends a request message again (Diameter AA Request / Radius Access Request).

This time, it contains the EAP / AKA / Test Response. 25

7. When the AS receives this message, it compares the value of AT_RES that it had previously calculated with the value of AT_RES in the received EAP message. If the values match, AKA authentication succeeds; otherwise, authentication fails. Depending on the result, it sends either an Access Acceptance or an Access Rejection message (in the case of Radius). For Diameter,

30 this sends an AA Response message with the result in the AVP Result Code. This also sends a Key Distribution AVP because it is necessary for it to carry the authentication key from BU to the HA and the Authorization Life Time AVP that has the associated lifetime of the BU authentication key .

35 8. Upon receipt of this message, the HA knows whether the authentication was successful or not. This creates a Security Association with the terminal in order to authenticate the Binding Updates. This associates the authentication key K with this SA and initializes the life of the same as it is received in the message. The HA sends the appropriate response message to the terminal. When the terminal receives this message, the BU authentication key setting is complete.

40 In the following, the above procedure is described in more detail by referring to the signal flow diagram shown in Figures 3A and 3B.

In step 3A, the terminal implicitly receives a knowledge that its HA is capable of performing a

45 AKA authentication. Before sending the following message, the terminal must have acquired an assigned IPv4 address, for example, with DHCP.

In step 3B, the terminal deduces from its static knowledge with its own network that a link authentication is necessary. The terminal starts the authentication sequence by sending a

50 AAA Request message (indicated by RQ1 in Figure 3A) to the HA. The AAA Request contains an AAA Client Identifier Option (cID) as well as an option that carries the EAP Response and the EAP Identity message (ERs / EAPIdentity). Both the AAA Client Identifier Option and the EAP Identity message contain the user's NAI (IMSI @ domain).

55 In step 3C, the HA obtains the address of the AS from the NAI that is contained in the AAA Client Identifier Option (using a dynamic name server (DNS), if necessary) and sends a message from AAA Request (AR, AAA Request) to the AS. The AR contains the EAP Identity message (in the EAP payload attribute) and the NAI (in the User Name attribute) that is received in the AAA Client Identifier Option in step B.

60 In the 3D stage, the AS performs the following upon receipt of the AR message in step 3B:

This observes, from the Reason field of the EAP / Identity Response that the session key that is

established with this procedure, it will be used for Client-assisted authentication (therefore, the latter does not have to send the password later to any other than the one that acts as the assistance).

image9

Based on the IMSI part of the NAI, the AS identifies the AuC that contains the authentication information for the user.

This question and get a quintet of UMTS authentication from the AuC. 5

This calculates the values AT_RAND (a random number) and AT_AUTN (an authorization vector) and AT_MAC (message authentication code).

This calculates and stores the AT_RES and K values for later use. 10

This creates the EAP / AKA Request / Test Request that contains the value of AT_RAND, the value of AT_AUTN and the value of AT_MAC.

This sends an Access Test (AC) message, which contains the Request for

15 EAP / AKA / Test (in the specific attribute of the 3GPP2 manufacturer) and the NAI that identifies the user (in the User Name attribute), to the HA.

In step 3E, the HA sends an AAA Response message (indicated by RP2 in the figure), which contains the EAP / AKA Request / Test in the AAAv6 Inserted Data Option, an Option to

20 AAA Client Identifier and an AAAv6 Test Option, to the terminal. The AAA Client Identifier Option contains the NAI that identifies the user and the AAAv6 Test Option contains a Local Test Value that is set by the HA.

In step 3F, the terminal performs the following upon receipt of the AAA Response in step 3E: 25

This uses the AKA to calculate the value of AT_RES and the value of K, giving the value of AT_RAND that is received inside the EAP / AKA / Test Request as an input to the AKA.

This compares the calculated AT_AUTN value with the value received in the EAP / AKA Request / Commissioning

30 Test If the values match, the EAP / AKA Request / Test message is authenticated successfully, otherwise the authentication message fails.

It stores the K key for the purpose of using it for the Security Association with the HA.

35 This stores the lifetime of the Security Association with the HA in order to be able to deduce, when it is to be renewed.

It sends an AAA Request (RQ3) message, which contains the Local Test in an AAAv6 Test Option, an AAA Client Identifier Option (NAI of the IMSI @ domain form) and a

40 Response message from EAP / AKA / Test in the AAAv6 Inserted Data Option, to the HA. The EAP / AKA / Test Response contains the calculated SRES value.

In step 3G the HA sends an AR message to the AS (which is identified by the NAI). The AR message contains the EAP / AKA / Test Response (in the specific attribute of the 3GPP2 manufacturer) and the NAI (in the 45 User Name attribute) that is received in the AAA Client Identifier Option .

In step 3H, the AS performs the following upon receipt of the AR message in step 3F:

This compares the value of AT_RES that it has calculated in step 3C with the value of AT_RES that is

50 contained in the EAP / AKA Response / Test. If the values match, the AKA authentication succeeds, otherwise the authentication fails.

This sends an AA message to the HA. The AA message contains the BU authentication key in a manufacturer-specific attribute, the NAI that identifies the user in the User Name attribute and the BU authentication key lifetime in another manufacturer-specific attribute. The key life time field

55 is set by the AS to the value 259200 (3 days), for example.

In step 3I: the HA creates or renews the Security Association to be used with the terminal to authenticate the Binding Updates, associates the K key as the authentication key with it and initializes the lifetime for the SA according to the value that is received in the key life time attribute. Then, HA 60 sends an AAA Response message (RP3), which contains an AAA Generalized Key Response Option and the Code field set to indicate SUCCESS (the value 0), to the terminal. The AAA Generalized Key Response Option does not contain the K key, but the life time field is adjusted to the value that is received in the key life time attribute and the value of the Key SPI field is set to indicate the Security Association between the HA and the terminal. When the terminal receives this message, the procedure of

65 General BU authentication key setting is complete.

image10

In step 3J, for the Mobile IPv4 application, the terminal will form the Mobile Own Authentication Extension in the IPv4 Mobile Registration Request (RREQ), using the BSAs, as created from the key material . The HA will automatically apply the BSA corresponding to the MNHA Authentication Extension when the RREQ message authentication is performed.

5 For the IPv6 Mobile application, the terminal will send IPSec protected binding updates to the HA, so that the IPSec security associations manipulated by RUIM will be automatically applied to the package sent. When the HA receives the packet, its IPSec module automatically knows the SA that it can then apply to the incoming mobility header packet. This package can be

10 the Mobile IPv6 HOTI or the Link Update message.

In step 3K, for the application of Mobile IPv4, the HA will apply the Mobile Own Authentication Extension in the Registration Response (RREP) of IPv4 Mobile built, using the BSAs, as created from the material of keys received from the AS. The terminal will then automatically apply the

15 BSA corresponding to the MNHA Authentication Extension when the message authentication of the received RREP is performed.

For the IPv6 Mobile application, the HA IPSec module will automatically protect the BAck message sent using the SA (s) manipulated by RUIM. So when a header packet is received from

20 mobility secured by IPSec from HA, the terminal automatically applies the IPSec security association manipulated by RUIM for the opposite direction compared to that used in step N.

This completes a flow of successful mobility signaling protection application protocol. With applications other than IPv6 / Mobile IP base registers, this type of procedure can be used to

25 manipulate any IPsec SA.

In the following, a second embodiment of the present invention is described.

Similar to the first embodiment, the second embodiment is directed to the field of combined use of data networks by

30 cellular and non-cellular CDMA2000 packages and, in particular, refers to user authentication and service authorization using a Removable User Identity Module (RUIM) when communicating across multiple types of networks of access. Although there is currently no protocol to perform RUIM authentication through non-cellular IP networks, this capability is useful for automating key management, taking advantage of the existing key infrastructure for non-authentication.

35 of data, as shown by similar methods in other cellular environments. User authentication and service authorization allows the cellular operator to provide the user with various types of access network, while maintaining a unified service provision, user-based network access management and roaming authentication, while taking advantage of all this of the existing authentication / accounting / billing infrastructure. The benefit can be summarized as a unification of

40 CDMA2000 authentication based on smart card for multiple access methods.

According to the second embodiment, various protocols are combined to provide a key distribution and multiple access authentication mechanism based on RUIM, which can be executed over IP at different link layers. The system, which uses various encapsulation messages in different phases, allows the 45 network elements to exchange data so that both the terminal equipment and the operator network can execute the CAVE algorithm (Cellular Authentication and Voice Encryption, Authentication Cellular and Voice Encryption) of CDMA2000 for IP-based cellular and non-cellular packet data services. By using the exchanged data and the results of the CAVE algorithm, the terminal and the access network can authenticate each other, and obtain secure keys that can be used for applications of a limited time, such

50 as network access authorization or roaming signaling authentication message protection. It is noted that the CAVE algorithm is further described in ANSITIA / EIA41, "Cellular Radio Telecommunications Intersystem Operations", 1997, for example.

The terminal can perform authenticated IP-based sessions through heterogeneous network types,

55 including CDMA2000, 802.11 Wireless LAN, Bluetooth or Ethernet. The access network can be point to point, or point to multipoint. The terminal can combine the execution of this method with Mobile IPv6, or it can execute it through a simple IPv6 access, one without mobility support.

In non-cellular cases, according to the present second embodiment, a uniform method is provided for

60 that the mobile equipment and the operator network communicate with each other through any network capable of IP, and securely exchange credentials and establish a service provision, regardless of the characteristics of the underlying network used. The method, as described, is linked to the existing CDMA2000 method by sharing only the registration identity, so that using this method, operators are not required to reorganize each technology, but can take advantage of this method.

65 more generic when a specific link layer mechanism is not used. By adding a few network elements, as described in the present invention, the operator can take advantage of its existing CDMA2000 service infrastructure with little or no change in existing network elements.

image11

In the following, the procedure according to the second embodiment is described in more detail.

5 The implementation is directed to mobile phones or other mobile devices (referred to in the foregoing herein as ME or mobile equipment), which have IP-based communication capabilities, usually through links wireless, and that has the RUIM module. The embodiment can also be used with fixed devices at startup but it is most useful with mobile devices. The realization allows mutual authentication, a network authorization and a service provision through an interaction between multiple parties that involve (but not limited to) the following entities: ME, RUIM (which is considered a separate entity under its internal processor , Non-volatile memory, and private data and algorithms), Access Controller, Authentication Gateway, and Authentication Center (AuC, Home Location Register) of the CDMA2000 network, similar as it is in the first embodiment.

15 At the moment when the ME enters a network capable of GRASP functionality (General RUIM Authentication and Service Provisioning, General RUIM Authentication and Service Provision, the protocol example described in the present second embodiment), The ME receives a Router Announcement, which includes a GRASP support indication, for example, a router or agent announcement option from the local CA indicating this type of AAA support. This initiates authentication, key generation and service provision as described in the present invention. Next, the ME responds to the AC with the EAP / RUIM / Start message containing a Client Identifier option and an EAP Identity message. Both options contain the user identity (IMSI @ domain), which is constructed from the user's IMSI in the RUIM, at the boot time of ME and the domain in an additional file in the RUIM or in the

25 non-volatile memory of the ME. This identity EAP message is encapsulated in IP / IPv6 as an access link AAA message. The access link AAA message can be found, for example, in UDP or ICMPv6 messages, as described in a case of better implementation in Appendix A for IPv4 and IPv6, respectively, in a layer encapsulation of link, such as in IEEE 802.1x, IEEE 802.11i or in a suitable Bluetooth profile message, in PPP EAP encapsulation, or in any appropriate last hop PANA protocol message, as normalized in the future).

The AC determines the IP address of the Authentication Server by assigning it from the IMSI and the domain, and forwards the AAA message to the IP core using, for example, RADIUS, or any other core AAA protocol such as DIAMETER, for its encapsulation transport. So the message is

35 received by the AS which then comes into contact with the AuC / HLR.

The AS may be an AAA server that communicates directly or through the service MSC with the AuC / HLR that uses SS7 or A1 messaging that emulates voice circuit authentication. In other words, the AS would have a functionality to communicate with the AuC / HLR. With this choice of architecture, the existing CDMA network can remain unchanged, only one AS must be added. This is the non-intrusive overlay approach.

Alternatively, an approach with a more compact integration would lead to changes in the CDMA2000 network. The AS can be an AAA client / broker (RADIUS) in the PDSN, which forwards the authentication to a server

45 of AAA Own (AAAH, Home AAA) modified with respect to the conventional in the core network by CDMA2000 packages. The latter requires that the AAAH have the functionality to communicate with the AuC / HLR, a modification to the CDMA2000 packet core. The last choice of architecture would give the possibility of using RUIM authentication for data sessions by native CDMA2000 packets through a PDSN, as is currently done with EAPCHAP, or EAPPAP, because those authentications end at the end of the PPP session in the PDSN, and give rise to an exchange of RADIUS messages with the AAAH server. In other words, this last alternative would act as an intermediary in the non-cellular RUIM authentications through the PDSN or directly with the AAA server itself, or would transfer cellular PPPRUIM authentications to the same endpoint, using RADIUS client capabilities of extended PDSN. The extension would be the capacity of EAPRUIM and its assignment to RADIUS messages, reusing potential use of

55 non-cellular RADIUS messaging for the method described.

When the AS receives a record, it proceeds to recover a randomized handling material from the AuC, in the form of a RAND or RANDU (depending on the global or unique nature of the authentication being performed), and returns this information randomized as a test to the ME, in the form of an EAP / RUIM / Test message containing a customer ID option, inside an AAA Response (which is transported through RADIUS).

Now, the ME has received random testing (RAND) from the AS, and is ready to execute the CAVE algorithm in order to authenticate itself and generate encryption keys for the session. The ME sends a

65 instruction to the RUIM to start the Execution CAVE algorithm, and provide the ESN (electronic serial number, determined telephone serial number, and ME boot time), RAND / RANDU, type

of rand (unique or global, depending on what was supplied), and the PIN number, if necessary, for this RUIM. Then, the ME executes Get Response, to get the RUIM to pass the AUTHR or AUTHU (global or single test response) output to the ME.

5 After the ME has received the test response, it sends it to the AC in a similar package as described above, but this is an EAP / RUIM / Start with the Commissioning message. a Local Test, Customer ID, and an inserted data option that contains the test response material. Then, the AC consults the address of the AS as in the previous stage, and forwards the message via RADIUS. The AS obtains the message, and determines with which AuC / HLR to contact by performing

10 of an assignment query based on the IMSI and the Domain that are received in the secondary identity option, and also retrieves its stored session state based on the IMSI @ domain. The AS proceeds to verify the authenticity of the client by recovering CAVE credentials from the AuC / HLR, executing the CAVE algorithm and comparing the response received from the ME with the response received from of the AuC / HLR.

15 If the responses received from the ME and the AuC are the same, the AS forwards the session key and the success code back to the AC in another EAP message. Upon receipt of this EAP message, the CA grants access to the ME and saves the session key for use during the session. This occurs, for example, through the functionality of the core AAA client in the AC. This manipulates an IPSec security association or associations with ME

20 in the AC, or create a firewall rule to grant access to the network for the ME.

Then, the AC transmits the message back to the ME, which is inserted in the last hop AAA protocol as previously described (for example, in ICMPv6), with the secondary key option removed. Therefore, the key is not transmitted through the last jump, which may be unsafe, and the ME uses the key that this

25 obtained in the RUIM, and the AC uses the key that is transmitted back from the AS through RADIUS.

Next, the above procedure is described in more detail by referring to the signal flow diagram shown in Figures 4A and 4B. It is noted that this signal flow is similar to that shown in Figures 2A and 2B, so that abbreviations and the like that are described in

30 connection with figures 2A and 2B.

In step 4A, the terminal receives a Router Announcement (either unsolicited or requested) from the AC. The Router Advertisement (RA) includes an indicator that indicates AAA support. Before sending the following message, the terminal must have acquired an assigned IPv4 address, for example, with

35 DHCP.

In step 4B, the terminal deduces from the presence of an AAA indicator in the Router Announcement that an AAA access authentication is necessary. The terminal begins the authentication sequence by sending an AAA Request message (RQ1) to the AC. The AAA Request contains an Option of 40 AAA Customer Identifier as well as an option that carries the EAP Identity message. Both the AAA Client Identifier Option and the EAP Identity message contain the user's NAI (IMSI @ domain).

In step 4C, the AC obtains the address of the AS from the NAI that is contained in the AAA Client Identifier Option (using a DNS, if necessary) and sends an AAA Request message (AR, AAA Request ) To

45 AS. The AR contains the EAP Identity message (in the EAP payload attribute) and the NAI (in the User Name attribute) that is received in the AAA Client Identifier Option in step B.

In step 4D, the AS performs the following upon receipt of the AR message in step 4C:

50 This creates an EAP / RUIM Request / Start Request message indicating the start of the RUIM authentication procedure.

This sends an AAA Answer (AA) message, which contains the EAP / RUIM / Start Request (in the EAP payload attribute) and the NAI that identifies the user (in the User Name attribute ), a the C.

In step 4E, the AC sends an AAA Response message (RP1), which contains the EAP / RUIM / Start Request in the One Inserted Data Option and an AAA Client Identifier Option to the terminal. The AAA Client Identifier Option contains the NAI that identifies the user.

60 In step 4F, the terminal sends an AAA Request message (RQ1), which contains an AAA Client Identifier Option containing the NAI (IMSI @ domain) and an AAA Inserted Data Option that carries a message EAP / RUIM / Start Response. The EAP / RUIM / Start Response Reason field is set to 0 (zero), which indicates that the session key will not be used for anything (only CAVE authentication is performed).

65 In step 4G, the AC obtains the address of the AS from the NAI that is contained in the AAA Client Identifier Option (using a DNS, if necessary) and sends an AAA Request message (AR, AAA Request) to the AS. The AR contains the EAP / RUIM / Start Response message and the NAI (in the manufacturer-specific Radius attribute fields), as received in the AAA Client Identifier Option in step 4F.

image12

5 In step 4H, the AS performs the following upon receipt of the AR message in step G:

Based on the IMSI part of the NAI, the AS identifies the AuC that contains the authentication information for

the user. 10 Ask this question and get two authentication triplets from Cave from the AuC.

This calculates the MAC_RAND and MAC_AUTHR values such as AT_RAND and AT_MAC, which are specified in H. Haverinen “EAP SIM Authentication (work in progress)” Internet Draft (drafthaverinenpppexteapsim10.txt), Internet Engineering Task Force, February of 2003, for example, for this EAPRUIM.

15 This stores the MAC_AUTHR value for later use.

This creates the EAP / RUIM Request / Test message that contains the MAC_RAND value and two RAND values (which are obtained from the authentication triplets).

This sends an AAA Answer message, which contains the EAP / R Request

UIM / Test and the NAI that identifies the user (in the specific Radius attribute fields of the manufacturer), to the AC.

In step 4I, the CA sends an AAA Response message (RP2), which contains the EAP / RUIM Request / Test in the AAA Inserted Data Option, an AAA Client Identifier Option that contains the NAI

25 In step 4J, the terminal performs the following upon receipt of the AAA Response in step 4I:

This uses the RUIM to calculate two AUTHR / AUTHU values, giving the two RAND values that are received inside the EAP / RUIM Request / Test as an entry to the RUIM module.

30 This calculates the MAC_RAND and MAC_AUTHR values such as the AT_RAND and the AT_MAC specified in the document referenced above by H. Haverinen “EAP SIM Authentication (work in progress)” Internet draft (drafthaverinenpppexteapsim10. txt), Internet Engineering Task Force, February 2003, for example.

This compares the calculated MAC_RAND value with the value that is received in the EAP / R Request

35 UIM / Test. If the values match, the EAP / RUIM Request / Test message is authenticated successfully, otherwise the authentication message fails.

This sends an AAA Request message (RQ3) that contains an AAA Client Identifier Option (NAI of the IMSI @ domain form) and an EAP / RUIM / Test Response message in the Inserted Data Option of AAA, to AC. The EAP / RUIM / Test Response contains the value of

40 MAC_AUTHR calculated.

In step 4K, the AC sends an AR message to the AS (which is identified by the NAI). The AR message contains the EAP / RUIM / Test Response and the NAI (in a manufacturer-specific Radius attribute field) as received in the AAA Client Identifier Option of the AAA Request.

45 In step 4L, the AS performs the following upon receipt of the AR message in step K:

This compares the value of MAC_AUTHR that it has calculated in step 4D with the value of MAC_AUTHR

which is contained in the EAP / RUIM / Test Response. If the values match, the CAVE authentication is successful; otherwise, authentication fails.

This sends an AA message, which contains the NAI that identifies the user (in a Radius attribute field), to the AC and the Result Code that indicates success (Response Message Attribute in AA) or failure (Attribute Response Message in an Access Rejection message) of the authentication, to the AC.

55 In step 4M, the AC knows, upon receipt of the AA message in step 4L, whether CAVE authentication succeeded or not. If the authentication was successful, the AC sends an AAA Response message with the Code field set to indicate SUCCESS (the value 0), to the terminal. When the terminal receives this message, the OWLAN access network authentication has been achieved.

60 If authentication was successful, the CA will apply a filtering rule that allows packets that are sent from the authenticated terminal to pass. Alternatively, there may be an entry, or pair of entries, of network access IPsec that is created between the terminal and the AC with this application (or other application code), using the same type of a manipulation mechanism such as explained for the IPv6 / IP Mobile application hereafter.

In a second case according to the second embodiment, a signaling flow is described between the MS, the HA and the AS, which uses access link signaling (NAAP, PPPLCP or the like) and spinal link signaling (Radius or DIAMETER) and EAPRUIM as end-to-end signaling. The combined signaling is shown in Figures 5A and 5B.

image13

5 In step 5A, the terminal implicitly receives knowledge that its HA is capable of performing RUIM authentication. Before sending the following message, the terminal must have acquired an assigned IPv4 address, for example, with DHCP.

10 In step 5B, the terminal deduces from its static knowledge with its own network that a link authentication is necessary. The terminal begins the authentication sequence by sending an AAA Request message (RQ1) to the HA. The AAA Request contains an AAA Client Identifier Option as well as an option that carries the EAP Identity message. Both the AAA Client Identifier Option and the EAP Identity message contain the user's NAI (IMSI @ domain).

15 In step 5C, the HA obtains the address of the AS from the NAI that is contained in the AAA Client Identifier Option (using a DNS, if necessary) and sends an AAA Request message (AR, AAA Request) to the AS. The AR contains the EAP Identity message (in the EAP payload attribute) and the NAI (in the User Name attribute) that is received in the AAA Client Identifier Option in step 5B.

20 In step 5D, the AS performs the following upon receipt of the AR message in step C:

This creates an EAP / RUIM Request / Start Request message that indicates the start of the procedure

RUIM authentication. In order to do this, the AS also contacts the AuC (Authentication 25 Center).

This sends an AAA Answer (AA) message, which contains the EAP / RUIM / Start Request (in the EAP payload attribute) and the NAI that identifies the user (in the User Name attribute ), To HA.

30 In step 5E, the HA sends an AAA Response message (RP1), which contains the EAP / RUIM Request / Start Request in the Inserted Data Option and an AAA Client Identifier Option to the terminal. The AAA Client Identifier Option contains the NAI that identifies the user.

In step 5F, the terminal sends an AAA Request message (RQ2), which contains an AAA Client Identifier Option containing the NAI (IMSI @ domain) and an AAA Inserted Data Option that carries a message EAP / RUIM / Start Response. The EAP / RUIM / Start Response Reason field is set to 2 (10 in binary), which indicates that the session key will be used for own registration protection (CAVE authentication will be done after stage I and IPSec security associations are created

40 to protect mobility headings with HA after stage M).

In step 5G, the HA obtains the address of the AS from the NAI that is contained in the AAA Client Identifier Option (using a DNS, if necessary) and sends an AAA Request message (AR, AAA Request ) To AS. The AR contains the EAP / RUIM / Start Response message and the NAI (in the Radius attribute fields

45 specific to the manufacturer), as received in the AAA Customer Identifier Option in step F.

In step 5H, the AS performs the following upon receipt of the AR message in step G:

Based on the IMSI part of the NAI, the AS identifies the AuC that contains the authentication information for the user.

This question and get as many authentication triplets of Cave from the AuC as necessary. This is determined by the key length of the CAVE algorithm and the IPSec Encryption Profile Id that is used (one from the set as defined in IKE (Internet Key Exchange) v2 ). This profile ID is communicated in the EAP package.

55 This calculates the MAC_RAND and MAC_AUTHR values such as AT_RAND and AT_MAC, which are specified in the document referenced above by H. Haverinen “EAP SIM Authentication (work in progress)” Internet draft (drafthaverinenpppexteapsim10 .txt), Internet Engineering Task Force, February 2003, for example, for this EAPRUIM.

This stores the MAC_AUTHR value for later use.

60 This creates the EAP / RUIM Request / Test message that contains the MAC_RAND value and two RAND values (obtained from authentication triplets).

This sends an AAA Response message (AA), which contains the EAP / RUIM / Test Request and the NAI that identifies the user (in the manufacturer's specific Radius attribute fields), to the HA.

65 In step 5I, the HA sends an AAA Response message (RP2), which contains the EAP / RUIM Request / Test in the AAA Inserted Data Option, an AAA Client Identifier Option containing the NAI.

image14

5 In step 5J, the terminal performs the following upon receipt of the AAA Response in step 51:

This uses the RUIM to calculate two AUTHR / AUTHU values, giving the two RAND values that are received inside the EAP / RUIM Request / Test as an entry to the Run_CAVE algorithm in the RUIM module.

10 This calculates the MAC_RAND and MAC_AUTHR values such as AT_RAND and AT_MAC, which are specified in the document referenced above by H. Haverinen “EAP SIM Authentication (work in progress)” Internet draft (drafthaverinenpppexteapsim10 .txt), Internet Engineering Task Force, February 2003, for example.

This compares the calculated MAC_RAND value with the value that is received in the EAP / R Request

15 UIM / Test. If the values match, the EAP / RUIM Request / Test message is authenticated successfully, otherwise the authentication message fails.

It sends an AAA Request message (RQ3), which contains an AAA Client Identifier Option (NAI in the form IMSI @ domain) and an EAP / RUIM / Test Response message in the Inserted Data Option from AAA, to HA. The EAP / RUIM / Test Response contains the value of

20 MAC_AUTHR calculated.

In step 5K, the HA sends an AR message to the AS (which is identified by the NAI). The AR message contains the EAP / RUIM / Test Response and the NAI (in a manufacturer-specific Radius attribute field) as received in the AAA Client Identifier Option of the AAA Request.

25 In step 5L, the AS performs the following upon receipt of the AR message in step K:

This compares the value of MAC_AUTHR that it has calculated in step 5D with the value of MAC_AUTHR

which is contained in the EAP / RUIM / Test Response. If the values match, then the CAVE authentication is successful; otherwise, authentication fails.

This sends an AA message, which contains the NAI that identifies the user (in a Radius attribute field) to the HA and the Result Code that indicates success (Response Message Attribute in AA) or failure (Attribute of Authentication Message in AA) of the authentication, and a key response (Encryption Profile Id, key or keys, lifetime) to the HA.

35 In step 5M, the HA knows upon receipt of the AA message in step 5L, whether CAVE authentication succeeded or not. If the authentication was successful, the HA sends an AAA Response message (RP3) with the Code field set to indicate SUCCESS (the value 0) to the terminal. When the terminal receives this message, the OWLAN's own manipulation and registration authorization is performed. If RUIM authentication succeeded, the HA

40 will manipulate

for the IPv4 Mobile application, a Binding Security Association (BSA) to be used with the MNHA Authentication Extension for the appropriate Mobile IPv4 status from the key material obtained when it is obtained run the Run_CAVE algorithm on the R

45 UIM.

For the IPv6 Mobile application, two IPSec security associations with the SADB from the key material obtained when the Run_CAVE algorithm is executed in the RUIM. These SAs (Security Associations) are set up for incoming and outgoing mobility (MIPv6) or registration (MIPv4) header packets with the terminal, and with the other parameters as identified by

50 the IPSec Encryption Profile Id used. Possibly, this action uses the Pfkey interface of the IPSec module, therefore not requiring any special interface between the RUIM manipulation daemon and the IPSec module.

In step 5N, for the Mobile IPv4 application, the terminal will form the Mobile Own Authentication Extension in

55 The Registration Request (RREQ) of IPv4 Mobile, using the BSAs, as created from the key material. The HA will automatically apply the BSA corresponding to the MNHA Authentication Extension when the RREQ message authentication is performed.

In addition, in step 5N, for the IPv6 Mobile application, the terminal will send linkage updates

60 protected with IPSec to the HA, so that the IPSec security associations manipulated by RUIM will be automatically applied to the package sent. When the HA receives the packet, its IPSec module automatically knows the SA that it can then apply to the incoming mobility header packet. This package can be the Mobile IPv6 HOTI (Home Test Init) or the Link Update message (BU).

65 In step 5O, for the Mobile IPv4 application, the HA will apply the Mobile Own Authentication Extension in the Registration Response (RREP) of the built IPv4 Mobile, using the BSAs, as created from the material of keys received from the AS. The terminal will then automatically apply the BSA corresponding to the MNHA Authentication Extension when the message authentication of the

image15

5 RREP received.

In addition, for the Mobile IPv6 application, the HA IPSec module, in step 5O, will automatically protect the BAck message (Binding Acknowledgment) sent using the SA (s) manipulated by RUIM. Then, when a mobility header packet secured by IPSec is received from the HA, the terminal automatically applies the IPSec security association manipulated by RUIM for the opposite direction compared to that used in step N.

This completes a flow of successful mobility signaling protection application protocol. With applications other than IPv6 / Mobile IP base registers, this type of procedure can be used to

15 manipulate any IPsec SA.

The invention, as described in the previous embodiments, can be implemented in a software or inserted hardware system or microplate elements, which are executed in various network entities that are involved in the exchange. Some important functionalities of the implementation in a terminal are: access to an API for conventional RUIM functions, and the ability to build arbitrary IP packets that include encapsulated addresses. In the Access controller, some important functions are packet encapsulation and uncapsulation in access AAA messages, such as UDP or ICMPv6 and core AAA messages, such as RADIUS or DIAMETER messages, for example, adapting from the application of NASREQ (as described in P. Calhoun, W. Bulley, A. Rubens, J. Haag, G. Zorn. Diameter

25 NASREQ Application (work in progress). Internet Draft (draftietfaaadiameternasreq08.txt), Internet Engineering Task Force, November 2001, for example). This would also reuse the generic packet filtering capabilities of an access router, Network Access Server or PDSN, depending on where the access authentication service point for the method is located.

The best mode of implementation of the second embodiment is outlined in Figure 1. This would be to implement the functionality of the terminal in a mobile device, which interconnects with the physical support of RUIM (in the case of the second embodiment) as well as with the network . The functionality would send and receive GRASP protocol messages with the IP access router, access server or base station with which the mobile device connects through the radio network. When the mobile device has received messages from the network elements that

35 provide input information (a test, or RAND) to the authentication algorithm, this will access the RUIM to execute the CAVE algorithm. This generates, at the local level, a response and a secret shared with the network.

In the network, the invention can be implemented by means of additional software in the access router / WLAN base station, to accept messages encapsulated from the mobile equipment, and re-encapsulate them in the server-based RADIUS protocol, for transit back to the operator's network. An optional Own Mobile IP Agent with additional software is added to the operator's network, and additionally a gateway (AS or AAAH) is used to translate messages between RADIUS and the SS7 messages of CDMA2000. In this way, the security of the CAVE protocol is limited to the limits of the ME and the AuC / HLR, and the infrastructure

The existing CDMA2000 network is reused for authentication and authorization, possibly even for billing and accounting. Therefore, no changes are needed in IP or CDMA2000 networks, or minimal changes are needed.

The functional implementation can take place in various locations of the operating systems, for example in the OS (Operating System) cores, or on a user-level software, depending on the specific details of the implementation.

In the following, the network elements that are involved are described concisely when referring to Figures 6A to 6C. It is noted that only those members that are necessary for the description of

In the previous embodiments, Figure 6A shows an access controller (AC) according to the previous embodiments. The access controller 1 comprises reception means 1a, which receive an authentication message in which a start message is described which has been described above. In addition, the access controller comprises processing means 1b. The processing means 1b reads the encapsulated start message (for example, a client identifier option message and an EAP (Extensible Authentication Protocol) message, containing client type, identity user and core address information, as described above). Then, the encapsulated message is forwarded by means of forwarding means 1c to an authentication server that is identified in the encapsulated message.

65 Figure 6B shows a mobile terminal 2. It is noted that the mobile terminal is only an example for a subscriber device. The mobile terminal 2 comprises determination means 2a that determine an access type of

network upon receipt of an information message (i.e., an RA router announcement that has been described above) indicating at least one type of network access. In addition, the mobile terminal 3 comprises creation means 2b that create the start message as described above. An encapsulation means 2c of the mobile station 2 encapsulates the start message in a compatible authentication message

5 with an access network that is identified in the information message, and sending means 2d of the mobile station 2 send the start message to an access controller.

Figure 6c shows a router 3 as used in the previous embodiments. Router 3 comprises creation means 3a that create the information message described in what

10 above, that is, a Router Announcement. A sending means 3b of the router 3 sends the information message to a subscriber device. It is noted that the router 3 and the access controller 1 can be arranged in a unit (as in accordance with the embodiments described above).

The invention is not limited to the embodiments described above, but may vary within the scope of the claims.

For example, the above embodiments may be freely combined, such that both the EAPAKA authentication mechanism using a USIM and an authentication using RUIM based on the CAVE algorithm are used.

20 A protocol between the mobile device and the access network may comprise at least one of the network layer protocols such as UDP, ICMP, ICMPv6 and link layer protocols such as IEEE 802.1x, IEEE 802.1 li and a Bluetooth profile. In addition, there are the following variations of the embodiments that have been described in the foregoing:

25

1. Reuse of the EAPSIM method The method, in which an authentication mechanism is a mechanism that uses RUIM (as described above with respect to the second embodiment, for example), is inserted in the same encapsulation protocol than in the SIM method, which is called EAPSIM. This use is reuse

30 of the EAPSIM protocol to carry RUIM-based authentication with the CAVE algorithm. An indication of the alternate use of EAPSIM can be indicated using a field reserved in the EAPSIM protocol, or alternatively, an additional attribute, call this ATRUIM.

2. Location of the network side termination for smart card algorithms The network side termination point of the algorithm that corresponds to the one running on the card

35 intelligent (AKA or CAVE secret algorithm), could be found, in principle, either in the HLR / AuC, or located together with the AAA Proprietary AAAH server (Figure 1). In the previous case, there is an interface, call this G_h, through which the AAA server itself propagates dialogues for the triplet / quintuplet with the smart card algorithm in question, which uses a cellular network protocol through G_h . In addition, it is noted that the mobile device or terminal is only an example for a subscriber terminal. Be

40 notes that the term "mobile" not only means that the mobile terminal is connected to a network through a radio link, but also a terminal that can be connected to different network access means through fixed cables , for example. For example, this may include a computer that can be connected to fixed network terminals such as a computer that can be connected to a fixed network in hotel rooms, trains and the like.

Four. Five

Claims (29)

image 1 1. A system to authenticate and authorize network services comprising: 5 a mobile device, said mobile device being configured to determine a type of network access upon receipt of an information message indicating at least one type of network access; create a startup message that contains at least one user identity; and encapsulate the start message in an authentication message compatible with an access network that is 10 identifies in the information message, said system further comprising: an access controller to read the encapsulated message from the mobile device and forward the encapsulated message to an authentication server that is identified in the encapsulated message.

The system according to claim 1, further comprising:

a router to issue the information message, wherein the information message includes a router announcement.

The system according to claim 1, wherein the information message indicates an extensible authentication protocol (EAP) support.

4. The system according to claim 1, wherein the access controller is adapted to issue the Information message when the mobile device enters the network. 25 5. The system according to claim 1, wherein the startup message contains a client identifier option message and an extensible authentication protocol support identity option message, wherein said messages contain information relating to At least one of type of client, user identity and core address information. 30 6. The system according to claim 1, wherein a protocol between the mobile device and the access network comprises at least one of UDP, ICMPv6, IEEE 802.1x, IEEE 802.11i and a Bluetooth profile. 7. The system according to claim 1, wherein an authentication mechanism that is applied comprises an extensible authentication protocol (EAP). 8. The system according to claim 1, wherein an authentication mechanism that is applied is an authentication mechanism using a removable user identity module (RUIM) that applies a Cellular Authentication and Voice Encryption algorithm ( CAVE). 40

9.

The system according to claim 1, wherein the access controller is provided in an Own Agent of the mobile device.

10.

The system according to claim 2, wherein the router comprises

45 creation means for creating the information message indicating the at least one type of network access, and sending means for sending the information message to a subscriber device. 11. The system according to claim 10, wherein the information message includes an announcement of router. fifty 12. The system according to claim 2, wherein the information message indicates an extensible authentication protocol (EAP) support. 13. The system according to claim 2, wherein the router is part of the access control device. 14. A method for authenticating and authorizing network services, in which the network comprises a mobile device and an authentication control function, the method comprising determining a type of network access by the mobile device, upon receipt of a message of information 60 indicating at least one type of network access; create a start message that contains at least one user identity, encapsulate the start message in an authentication message compatible with an access network that is identified in the information message, and read, via an access controller, the message encapsulated from the mobile device and forward the message 65 encapsulated to an authentication server that is identified in the encapsulated message. 19 image2 15. The method according to claim 14, wherein the network additionally comprises a router, which issues the information message, wherein the information message comprises a router announcement. 16. The method according to claim 14, wherein the information message indicates a support for extensible authentication protocol (EAP). 17. The method according to claim 14, wherein the information message is issued when the mobile device enters the network. The method according to claim 14, wherein the start message contains a client identifier option message and an extensible authentication protocol support identity option message, which contain at least one of type of customer, user identity and core address information. 19. The method according to claim 14, wherein a protocol between the mobile device and the access network is at least one of UDP, ICMPv6, IEEE 802.1x, IEEE 802.11 i and a Bluetooth profile. 20. The method according to claim 14, wherein an authentication mechanism that is applied comprises an extensible authentication protocol (EAP). The method according to claim 14, wherein an authentication mechanism that is applied comprises an authentication mechanism using a removable user identity module (RUIM) that applies a Cellular Authentication and Voice Encryption algorithm. (CAVE). 22. The method according to claim 14, wherein the access controller function is provided in an Own Agent (HA) of the mobile device. 23. An access control device comprising: receiving means for receiving a start message that is encapsulated in a message of 30 authentication, the authentication message being compatible with an access network that is identified in an information message, processing means for reading the encapsulated message, and forwarding means for forwarding the encapsulated message to an authentication server that is Identify in the encapsulated message. 35 24. The access control device according to claim 23, wherein the start message contains a client identifier option message and an extensible authentication protocol support identity option message, wherein said messages They contain information related to at least one of the type of client, user identity and core address information. 40

25.

The access control device according to claim 23, wherein the access control device is provided in an Own Agent of a mobile device that has sent the start message.

26.

The access control device according to claim 23, further comprising

45 sending means for sending the information message to a subscriber device indicating at least one type of network access. 27. The access control device according to claim 26, wherein the information message includes a router ad. fifty 28. The access control device according to claim 26, wherein the information message indicates an extensible authentication protocol (EAP) support. 29. The access control device according to claim 26, wherein the information message is issued when the mobile device enters a network. 30. A subscriber device comprising: determination means for determining a type of network access upon receipt of a message from 60 information indicating at least one type of network access; creation means for creating a start message containing at least one user identity; encapsulation means for encapsulating the start message in an authentication message compatible with an access network that is identified in the information message; and a means of sending to send the start message to an access control device. 65 twenty image3 31. The subscriber device according to claim 30, wherein the subscriber device is a mobile device. 32. The subscriber device according to claim 30, wherein the information message indicates an extensible authentication protocol (EAP) support. 33. The subscriber device according to claim 30, wherein the information message is issued when the subscriber device enters a network. The subscriber device according to claim 30, wherein the start message contains a client identifier option message and an extensible authentication protocol support identity option message, wherein said messages contain information relating to at least one of the type of client, user identity and core address information. The subscriber device according to claim 30, wherein an authentication mechanism that is applied is an authentication mechanism that uses a removable user identity module (RUIM) that applies a Cellular Authentication and Encryption algorithm of Voice (CAVE). twenty-one