JP2008547248A - Apparatus, method and computer program for providing mobile node identifiers with authentication preferences in generalized bootstrapping architecture (GBA) - Google Patents

Abstract

In one non-limiting exemplary aspect, sending a first message to a wireless network (WN) that includes a list of authentication mechanisms supported by the node and a corresponding identifier associated with each authentication mechanism; Determining at WN at least the authentication mechanism to be used for strapping based on the list received from the node; including in the second message transmitted to the node information including the determined authentication mechanism with a corresponding identifier Is provided. The method further includes at least protecting a list of authentication mechanisms supported by the node and a corresponding identifier, and transmitting a second message including at least the list of authentication mechanisms and the corresponding identifier to the network. The method further includes receiving from the network a second response message that is at least partially integrity protected including an indication of the selected authentication mechanism and a corresponding identifier.
[Selection] Figure 8

Description

  Non-limiting exemplary embodiments of the present invention relate generally to communication systems, communication methods, and communication devices, and more particularly to authentication and related techniques used in communication systems.

background

Here the following definitions are used:
3GPP Third Generation Partnership Project
AAA authentication, authorization and accounting
GAA Generic Authentication Architecture
GBA Generic Bootstrapping Architecture
BSF Bootstrapping Server Function
AKA Authentication and Key Agreement
IM IP Multimedia (IP Multimedia)
ISIM IM Service Identity Module
NAI Network Access Identifier
MN Mobile Node
UE User Equipment
EV-DO Evolution Data Only

  The aim of 3GPP GBA (see 3GPP TS 33.220 “GAA: GBA”, attached as Annex A to US Provisional Patent Application No. 60 / 759,487 above) is for application security through the 3GPP AKA mechanism. Specifying a mechanism for bootstrapping authentication and key sharing. GBA is going to be introduced in 3GPP2, and besides AKA, bootstraps based on legacy key materials such as SMEKEY (for CDMA1x system) and MN-AAA Key (for CDMA1x EV-DO system) will be standardized. As a result, when operating in a 3GPP2 system, the MN may support or be required to support more than one authentication and bootstrap mechanism. Therefore, a technique is required for the MN and the network to match the algorithm set used in the bootstrap. The same is needed for future terminals that support both 3GPP and 3GPP2 networks so that 3GPP terminals can use GBA when roaming 3GPP2 networks (and vice versa). In addition, operators can deploy both 3GPP and 3GPP2 networks in the same geographic location. In such a case, the terminal must also negotiate with the network the bootstrap mechanism to use.

  3GPP supports the AKA protocol with only one authentication and bootstrap mechanism, namely the digest AKA mechanism and the algorithm defined by 3GPP. The use of AKA with digest authentication is defined in Digest AKA (see IETF RFC 3310 “Digest AKA”, attached as Annex B to the above provisional US application 60 / 759,487) )

  Since both legacy and non-legacy terminals need to be supported, 3GPP2 supports various bootstrap mechanisms on the network side.

  The MN may support a plurality of authentication and key generation mechanisms (AKA, MN-AAA, CAVE, etc.) or may have a plurality of secrets prepared in advance. In 3GPP2, a mechanism selection procedure is defined. The MN is instructed to insert a list of supported authentication mechanisms into the payload of the first message sent to the BSF, so that the authentication mechanism preferred by the BSF can be selected. When BSF chooses an authentication and key generation mechanism, BSF contacts the correct database to obtain authentication data. For example, when the MN supports MN-AAA in addition to other mechanisms and the BSF selects MN-AAA, the BSF contacts the H-AAA and acquires a challenge.

  In addition, the MN has one or more identifiers. For example, when the MN has an ISIM application, the MN has a private identifier. When the MN is an EV-DO terminal, the MN has an NAI. When the MN is a 1x terminal, the MN has an identifier such as IMSI.

When the MN first contacts the BSF by sending an HTTP GET request (3GPP2 S.P0109-0, Version 0.6, 2005, attached as Attachment C to the above US Provisional Application No. 60 / 759,487) This is a problem because it was instructed to insert an identifier into the request, based on "Generic Bootstrapping Architecture (GBA) Framework", December 8, cause. Many of the identifiers can only be used with specific authentication and key generation mechanisms (for example, private identifiers can only be used with AKA, IMSI can only be used with CAVE, and EV-DO NAI can only be used with MN-AAA) Therefore, the MN implicitly selects an authentication mechanism in advance by selecting one of the identifiers and including it in the GET request. In the state where one specific identifier has already been inserted, the BSF must select a mechanism that can use the identifier together. Alternatively, the mapping of the various identifiers of the MN may need to be accessible by the BSF, but this approach may not be desirable for several reasons.
U.S. Provisional Patent Application No. 60 / 759,487 IETF RFC 3310 “Digest AKA” 3GPP2 S.P0109-0, Version 0.6, December 8, 2005, "Generic Bootstrapping Architecture (GBA) Framework"

Abstract

  The present invention, based on its non-limiting exemplary embodiment, sends a first message comprising a list of authentication mechanisms supported by a node and a corresponding identifier associated with each authentication mechanism to a wireless network (WN: receiving at the wireless network; determining at WN the authentication mechanism to be used for bootstrapping based at least on the list received from the node; and information including the determined authentication mechanism with a corresponding identifier to the node Including in a second message to be transmitted.

  The present invention further provides a computer program integrated into a computer readable medium according to its non-limiting exemplary embodiments. Execution of this computer program by the node's data processor sends a first message to the wireless network (WN) comprising a list of authentication mechanisms supported by the node and a corresponding identifier associated with each authentication mechanism. And receiving from the WN a first response message that includes information associated with the authentication mechanism selected by the WN from the list provided by the node in the first message, along with a corresponding identifier.

  The present invention further provides a device that includes a data processor combined with a transmitter and a receiver, according to its non-limiting exemplary embodiment. The data processor sends a first message comprising a list of authentication mechanisms supported by the device and a corresponding identifier associated with each authentication mechanism to the network via the transmitter and selected from the list by the network Is operable to receive a first response message from the network via the receiver that includes information associated with the authenticated authentication mechanism, along with a corresponding identifier.

  The present invention further provides a computer program integrated into a computer readable medium in accordance with its non-limiting exemplary embodiment. Execution of this computer program by a wireless network element (WNE) data processor comprises a first comprising a list of authentication mechanisms supported by the node and a corresponding identifier associated with each authentication mechanism. An operation for receiving a message from the node; an operation for determining an authentication mechanism to be used for bootstrapping based at least on a list received from the node; a first response message including information about the determined authentication mechanism and a corresponding identifier; And receiving from the node an at least partially integrity-protected second message that includes at least a list of authentication mechanisms supported by the node and a corresponding identifier in an integrity-protected form. Including actions.

  The present invention further provides a network device comprising a data processor combined with a transmitter and a receiver, according to its non-limiting exemplary embodiment. The data processor is operable to receive from the node via the receiver a first message comprising a list of authentication mechanisms supported by the node and a corresponding identifier associated with each authentication mechanism. The data processor determines an authentication mechanism to be used for bootstrapping based at least in part on the list received from the node, and sends a first response message that includes information about the determined authentication mechanism and a corresponding identifier It is further operable to transmit to the node via the machine. The data processor is further operative to receive an at least partially integrity-protected second message from the node that includes a list of authentication mechanisms supported by the node and a corresponding identifier in an integrity-protected form. Is possible.

  Furthermore, the present invention provides a device based on its non-limiting exemplary embodiment. Means for sending a first message to the network comprising a list of authentication mechanisms supported by the device and a corresponding identifier associated with each authentication mechanism; and an authentication mechanism selected by the network from the list. Means for receiving from the network a first response message including the described information and a corresponding identifier. The device further includes means for protecting the integrity of the list of authentication mechanisms supported by the device and sending a second message, at least partially integrity protected, to the network, the second message comprising: It includes a list of authentication mechanisms supported by the device and a corresponding identifier associated with each authentication mechanism in a integrity protected form.

  In addition, the present invention provides a network device based on its non-limiting exemplary embodiment. The network device includes means for receiving a first message from a node comprising a list of authentication mechanisms supported by the node and a corresponding identifier associated with each authentication mechanism, an authentication mechanism used for bootstrapping, Means for selecting based at least in part on the list received from the node, and means for transmitting to the node a first response message that includes information about the selected authentication mechanism and a corresponding identifier. The receiving means is further operable to receive from the node a second message that is at least partially integrity protected, including a list of authentication mechanisms supported by the node and a corresponding identifier associated with each authentication mechanism. It is.

  In addition, the present invention provides a system having a device connected to a network device, based on its non-limiting exemplary embodiment. The device includes a data processor associated with the transmitter and the receiver, the data processor comprising a first list of authentication mechanisms supported by the device and a corresponding identifier associated with each authentication mechanism. The message is operable to be sent to the network device via the transmitter. The network device includes a data processor coupled to the transmitter and receiver, the data processor being operable to select an authentication mechanism from the list. The device receives from the network device via the receiver a first response message that includes information about the authentication mechanism selected from the list by the network device and a corresponding identifier. The device's data processor at least partially protects the integrity of the authentication mechanisms supported by the device and the integrity of the corresponding identifier and sends the second message to the network device via the transmitter. This second message includes a list of authentication mechanisms and corresponding identifiers.

  In addition, the present invention, according to its non-limiting exemplary embodiment, sends a first message to the network comprising a list of authentication mechanisms supported by the device and a corresponding identifier associated with each authentication mechanism. A method is provided that includes: transmitting; and receiving from the network a first response message that includes information about the authentication mechanism selected by the network from the list, along with a corresponding identifier.

Detailed description

  Non-limiting exemplary embodiments of the present invention are generally directed to authentication, and in particular to 3GPP general purpose bootstrapping architecture (GBA) as defined in 3GPP and also introduced in 3GPP2. FIG. 1 shows a general, non-limiting bootstrapping reference architecture. Figure 1 shows a Home Subscriber System (HSS) 2, a Home Location Register (HLR) 4, an Access, Authentication and Billing (AAA) server 6, BSF 8, and network application functions ( A network application function (NAF) 10 and a user equipment / mobile node (MN) 12 and the interfaces between these components are shown. It is assumed that appropriate transmitters (Tx: transmitter) and receivers (Rx: receiver) are used to communicate information and messages between MN12, BSF8 and other network components. The non-limiting exemplary embodiment of the present invention mainly deals with procedures related to the Ub interface between the MN 12 and the BSF 8 where the bootstrap is performed. Note that the mobile terminal is called a user equipment (UE) in 3GPP, and is called a mobile node (MN) in 3GPP2. These terms shall be used interchangeably in this patent application without loss of generality, in addition they shall be further generalized and referred to as devices or nodes.

  A non-limiting exemplary embodiment of the present invention provides a mechanism for negotiating supported mechanisms / algorithms for bootstrapping between the MN 12 and the network.

  The non-limiting exemplary embodiment of the present invention provides a solution for the MN 12 and network component (BSF8) to agree on the authentication and bootstrap mechanism used in GBA (3GPP2 environment), in addition Defines how the mechanism can be incorporated into existing 3GPP procedures. MN12 is expected to have a list 11 of supported authentication and bootstrap mechanisms, for example by storing list 11 in a memory (MEM) 12A connected to a data processor (DP) 12B The In addition, the storage device 12A is assumed to include program code that causes the DP 12B to operate in accordance with various embodiments of the present invention. Further, the BSF 8 is also assumed to include a storage device (MEM) 8A connected to a data processor (DP) 8B. Storage device 8A is assumed to contain program code that causes DP 8B to operate in accordance with various embodiments of the present invention.

  In general, various embodiments of the MN 12 include cellular phones, personal digital assistants (PDAs) having wireless communication functions, portable computers having wireless communication functions, digital cameras having wireless communication functions, etc. Image capture device, game device with wireless communication function, music storage / playback device with wireless communication function, Internet device with wireless Internet access and browsing, and a combination of such functions A portable unit or a portable terminal may be included, but is not limited thereto. In other embodiments, the node can wirelessly communicate with the network via a wireless link because a wired connection via cable or wiring may be used instead, such as one or both of electrical and optical interconnects. The transmitter and receiver may not be included.

  Storage devices 8A and 12A may be of any type suitable for a local technical environment, including semiconductor-based storage devices, magnetic storage devices and magnetic storage systems, optical storage devices and optical storage systems, fixed storage devices and removable storage devices Etc., and may be implemented using any suitable data storage technique. Data processors 8B and 12B may be of any type suitable for a local technology environment, including, but not limited to, general purpose computers, special purpose computers, microprocessors, digital signal processors (DSPs), and multicore processors One or more of the processors based on the structure may be included.

  In general, exemplary embodiments of the present invention may be implemented by computer software executable by a data processor of MN12, such as DP12B, or by hardware circuitry, or a combination of software and hardware circuitry. . In addition, embodiments of the present invention may be implemented by computer software executable by a BSF8 data processor, such as DP8B, by hardware circuitry, or by a combination of software and hardware circuitry.

  First, filed September 21, 2005, “Method, Apparatus and Computer Program Product Providing Bootstrapping Mechanism Selection in Generic in Bootstrapping Architecture (GBA). Reference is made to US patent application Ser. No. 11 / 232,494 by Gabor Bajko and Tat Keung Chan, entitled “Bootstrapping Architecture (GBA)”. Which is hereby incorporated by reference as if it had been fully rewritten herein. U.S. Patent Application No. 11 / 232,494 is attached to the above-mentioned U.S. Provisional Patent Application No. 60 / 759,487 as Attachment D, and is filed June 13, 2005, U.S. Claims priority under 35 USC 35 (35U.SC) 119 (e) of US Provisional Patent Application No. 60 / 692,855 filed June 21, 2005 (referenced several times below) The entire disclosure of which is incorporated herein by reference.

  Before discussing further exemplary embodiments of the present invention, the content disclosed in US patent application Ser. No. 11 / 232,494 will be discussed for better understanding. In this connection, reference is made below to FIGS.

  A bootstrap procedure according to a non-limiting embodiment disclosed in US patent application Ser. No. 11 / 232,494 includes the following steps in an exemplary embodiment, which are described in further detail below in connection with FIG. Explained.

A. In the initial bootstrap request, the MN 12 indicates to the BSF 8 a list 11 of supported authentication mechanisms in the request. The MN 12 also includes a user identifier.

B. BSF8 is based on list 11 and other information received from MN12 (non-limiting examples include the mechanisms supported by BSF8 itself and the user profile retrieved based on the user identifier) Determine the authentication mechanism used for bootstrapping. Subsequently, BSF 8 proceeds with the selected authentication mechanism, which typically involves responding with an authentication challenge. In addition, BSF8 includes the instructions of the selected authentication mechanism in the response.

C. The MN 12 sends a new HTTP request to the BSF 8 including a response to the challenge generated based on the selected authentication mechanism. This message also includes the original list 11 of authentication mechanisms supported by the MS 12, but this time the integrity is protected.

D. BSF8 confirms whether the response to the challenge is correct, and if the response matches the expected response, the MN authentication is considered successful. If the authentication is successful and the list 11 received in step C is the same as that in step A, the BSF 8 responds to the MN using an HTTP success response. This response message may also include an indication of the selected authentication mechanism whose integrity is protected.

E. The MN 12 may receive a success response and confirm that the selected authentication mechanism is as instructed.

  Typically, the first two messages (steps A and B) cannot be protected because the two parties have not authenticated each other, so the MITM attacker can intercept message A and The authentication mechanism may be deleted, leaving only the weak authentication mechanism (s) in the BSF8 selection list. This leads to a “bid-down” attack, and even if both parties (eg, BSF8 and MN12) support stronger authentication mechanisms, the bootstrap procedure must be based on something more vulnerable. The procedure according to the non-limiting embodiment disclosed in US patent application Ser. No. 11 / 232,494 has MN 12 retransmit the list in a form protected in step C so that BSF 8 Eliminate this kind of “bid-down” attack by allowing MITM attacks to be detected if the lists of A and C do not match.

Various aspects of the non-limiting embodiment disclosed in US patent application Ser. No. 11 / 232,494 will now be described in more detail, but in 3GPP, the Ub interface (between MN12 and BSF8) is HTTP digest authentication. based on. The same mechanism is adopted in 3GPP2. For example, digest AKA is used for 3GPP and 3GPP2 AKA, while bootstrap for CDMA1x and CDMA EV-DO systems uses HTTP digest authentication with password-protected Diffie-Hellman (SMEKEY and MN-AAA Key respectively) (3GPP contribution: “Bootstrapping procedures for CDMA1x and CDMA1x EV-DO Systems”), 3GPP2 TSG- S WG4, Portland, May 2005). In other words, possible authentication and bootstrap mechanisms include at least the following:

3GPP AKA (algorithm is not specified, operator specific);
3GPP2 AKA (an algorithm that requires SHA-1);
Bootstrap based on SMEKEY; and
Bootstrap based on MN-AAA Key.

  In the future, more authentication mechanisms will be available and can easily be included in the MN-BSF selection procedure.

  For each authentication mechanism, it is better to embed the list of supported authentication mechanisms and the selected authentication mechanism in the payload of the HTTP message in the digest authentication header so that it is not necessary to standardize digest variants in the IETF. It is preferable to conveying information.

  FIG. 2 shows the message sequence of the GBA bootstrap procedure with authentication mechanism selection, which is described in detail as follows.

1. MN12 sends the first bootstrap request to BSF8 in HTTP GET format. The MN 12 includes the user identifier in the Authorization header. In addition, a list of supported authentication mechanisms ([A, B, C], etc.) is included in the HTTP payload.

2. When BSF8 receives the bootstrap request, it extracts a list of supported authentication mechanisms from the payload. Based on the extracted authentication mechanism, the list of authentication mechanisms supported by the BSF 8 itself, the user profile (read based on the user identifier), and possibly other information, the BSF 8 determines the authentication mechanism to use for bootstrapping.

3. BSF8 sends an HTTP 401 Unauthorized response to MN12. This response includes appropriate information based on the selected authentication mechanism. For example, if 3GPP AKA is selected, the WWW-Authenticate header includes an AKA parameter according to IETF RFC 3310 “Digest AKA”. In addition, the payload contains an indication of the selected authentication mechanism (A in this case). In addition, the quality of protection (qop) of digest authentication is set to “auth-int”, indicating that integrity protection of the payload is required.

4. MN 12 reads the selection of BSF 8 from the payload, and continues the authentication process according to this selection. This generally involves calculating a response based on the received challenge and some shared secret.

5. The MN 12 sends a new bootstrap request to the BSF 8 in the HTTP GET format together with the response calculated according to the selected authentication mechanism. Further, the payload includes the original list of authentication mechanisms supported by the MN 12. Since qop is set to "auth-int", this original list is included in the digest response calculation, thus protecting the integrity.

6. BSF 8 first verifies that the list shown in the payload matches that received in step 2. Only if a match is confirmed, BSF 8 continues to authenticate based on the selected mechanism. This generally involves verifying the received digest response and calculating the server response for server side authentication purposes.

7. BSF8 responds with an HTTP 200 OK message indicating successful authentication and bootstrap operation. This message also contains the digest response calculated by the BSF. Further, this message may include an instruction of the selected authentication mechanism for reference by the MN 12. This directive is also integrity protected by setting qop to "auth-int".

8. The MN 12 should confirm that the selected authentication mechanism is indeed the same as that indicated in Step 3. Note that this mechanism works perfectly even if the selected authentication mechanism is not included in the HTTP 200 OK response.

9. Both BSF 8 and MN 12 obtain a bootstrap key based on the selected authentication and bootstrap mechanism.

FIG. 3 shows a scenario when the MITM attacker 14 attempts a bid-down attack as described above. The following is a description of each step in FIG.

1. Same as step 1 in Figure 2. The original list 11 includes, for example, three supported mechanisms: A, B and C.

1a. Message 1 is intercepted by MITM attacker 14. The original list 11 is replaced with a list containing only mechanism C. Mechanism C appears to be the most vulnerable of the three supported.

2. BSF8 extracts a list containing only mechanism C, and as a result selects C to proceed.

3. Same as step 3 in Figure 2. Mechanism C is indicated.

4. MN12 believes that BSF8 has selected mechanism C and proceeds accordingly.

5. Same as step 5 in Figure 2. MN 12 advances mechanism C, but MITM attacker 14 cannot make any changes to the message because it includes [A, B, C] of the original list whose integrity is protected in the payload.

6. BSF 8 finds that it is not the same as the one received in step 2 while checking the received list. BSF 8 determines that a bid-down attack has been made and, as a result, aborts the bootstrap procedure using an HTTP 403 Forbidden message.

  Alternatively, the BSF 8 may detect this attack if the list received in step 2 does not match that shown in the user profile and again decide to abort the bootstrap procedure. This is illustrated in steps 1, 2 and 3 of FIG.

  Further, according to a non-limiting embodiment disclosed in U.S. Patent Application No. 11 / 232,494, at least one embodiment is that the bootstrap procedure of the selected authentication mechanism does not complete the request / response until 3 It relates to cases where rounds are required. For example, a bootstrap based on digest AKA requires two rounds of request / response to complete. The previous embodiment also describes the case where the bootstrap based on SMEKEY and MN-AAA Key may require two rounds of request / response, but there may be cases where more than three rounds of request / response are required. I think that the. In such cases, the non-limiting embodiments disclosed in US patent application Ser. No. 11 / 232,494 still apply. This scenario is illustrated in Figure 5 and is described as follows.

1. In the first bootstrap request, the MN 12 indicates a list of supported authentication mechanisms ({A, B, C}, etc.) to the BSF 8 in the request. The MN 12 also includes a user identifier. In many cases, it is assumed that this list is not protected.

2. BSF8 determines the authentication mechanism used for bootstrapping based on the list and other information received from MN12 (such as the mechanism supported by BSF8 itself and the user profile read based on the user identifier). decide. As a non-limiting example, in FIG. 5, it is assumed that mechanism A is chosen.

3. Next, BSF8 proceeds with the selected authentication mechanism, which typically involves responding with an authentication challenge. BSF 8 also includes an indication of the selected authentication mechanism (in this example, mechanism A) in this response. Again, this indication appears to be unprotected.

  From here onward, MN12 and BSF8 continue the selected mechanism (for example, mechanism A as shown in FIG. 5). As mentioned above, different mechanisms may require different rounds of message exchange (request / response, etc.) to complete the bootstrap procedure. For example, the digest AKA mechanism requires another request / response after step 3 to completion. On the other hand, bootstrap based on CAVE and MN-AAA Key may require more rounds. According to an exemplary embodiment of the invention, in one of these subsequent messages, the MN 12 again sends the original list 11 (sent in message 1), which is protected (integrity). Protection). On the other hand, the BSF 8 may resend the selected mechanism (sent in message 3), but this is protected (eg integrity protection). Note that even if the MN 12 transmits the original list 11 again in a protected state, whether or not the BSF 8 transmits the selected mechanism again in a protected state is optional (but preferable). If such a parameter is sent again in a protected state, the other party confirms that the transmitted parameter is the same as the original received parameter, and the original sent unprotected. Detects all attempts by MITM attackers to change their parameters. In the following description, integrity protection is employed as an exemplary technique for protecting parameters. Of course, the parameters may be encrypted.

4. Still referring to FIG. 5, the MN 12 calculates a response according to mechanism A in step 4.

5-6. As explained, there may be multiple rounds of request / response between MN12 and BSF8. In some of these rounds, the selected mechanism may not be able to provide the required integrity protection. For this reason, the MN 12 and the BSF 8 may not be able to transmit the integrity-protected parameter.

7. At some point in the bootstrap procedure, MN 12 should be able to send a message containing integrity-protected data. For example, assume that MN 12 can send such a message in message 7. In that case, the MN 12 includes the original list 11 (in this example, the list {A, B, C}) represented by P [{A, B, C}] in FIG.

8. Upon receiving the message, BSF 8 verifies that the integrity-protected list is the same as the list originally sent by MN 12 in message 1. If they are not the same, the BSF 8 may stop the operation by sending an error response to the MN 12 (not shown). Alternatively, the BSF 8 may stop the operation without notification.

9. At certain points in the bootstrap procedure, BSF 8 should be able to send messages containing integrity protected data. For example, assume that BSF 8 can send such a message in message 9. The BSF may include a selected mechanism (mechanism A in this example) with integrity protection, represented by P [A] in FIG.

10. Upon receipt of the message, MN 12 verifies that the selected mechanism whose integrity is protected is the same as that originally sent by BSF 8 in message 2. If they are not the same, the MN 12 may stop the operation by sending an error message to the BSF 8 (not shown). Alternatively, the MN 12 may stop the operation without notification.

11. If successful, both parties can obtain the bootstrap key Ks according to the selected bootstrap mechanism.

  It should be noted that steps 7 and 8, and 9 and 10 (if any) need not be in the order described and need not be consecutive messages. In other words, BSF8 may send a message with integrity protected parameters (selected mechanism) first, and later MN12 will send integrity protected parameters (supported mechanism) An accompanying message may be sent. In addition, there may be additional rounds of messages before and after the integrity protected message is sent.

  In the following description, an exemplary using HTTP digest authentication (FIG. 6) and plain HTTP transport (FIG. 7) in accordance with the non-limiting embodiment disclosed in US patent application Ser. No. 11 / 232,494. An implementation is provided. It should be noted that the non-limiting exemplary embodiments disclosed in US patent application Ser. No. 11 / 232,494 are not limited by these two examples, but may be implemented using other transport / authentication mechanisms. It is possible as well (for example, Extensible Authentication Protocol (EAP)). In the following description, the parameters required for mechanism negotiation (the list of supported mechanisms 11 sent by MN 12 and the selected mechanism sent by BSF 8) are listed in the HTTP message payload. It is assumed that it will be sent. However, these parameters may instead be conveyed in the appropriate headers within the HTTP message.

HTTP Digest Authentication In this exemplary implementation, HTTP digest authentication with password protected Diffie-Hellman is used for bootstrapping. Using MS_AUTH and / or BS_AUTH, the default password (such as "11 ... 1") is used as the digest password, and mutual authentication between MN12 and BSF8 is password protected Diffie-Hellman It may be based substantially on the mechanism. Details of the password-protected Diffie-Hellman mechanism are based on the WKEY (Wireless LAN Key) generation procedure described in the 3GPP2 wireless LAN interconnect specification (2005 (See Section 7.1.1 of 3GPP2 X.P0028 “Wireless LAN interworking”, attached as Attachment D to US Provisional Patent Application No. 60 / 692,855, filed June 21, 2000) .

  Figure 6 shows one exemplary implementation of bootstrap mechanism negotiation, with the selected mechanism being CAVE, and the bootstrap procedure using this CAVE is a total of three rounds of HTTP Requires a request / response. The bootstrap scenario based on MN-AAA Key is also very similar and will not be described in further detail.

The following is a more detailed description of the steps shown in FIG.

1. MN12 sends an HTTP GET request to BSF8. A user identifier of the format “IMSI@realm.com” is included in the Authorization header as the user name. In addition, the user sends a list 11 of supported bootstrap / authentication mechanisms in the payload (eg, MN12 supports CAVE and two other mechanisms, B and C, {CAVE , B, C}).

2. BSF8 reads a list of supported mechanisms from the payload and makes a decision based on the list, username, user profile, and / or other information. In this non-limiting example, BSF 8 selects CAVE as the bootstrap mechanism. From this point on, bootstrap is based on this selected mechanism, CAVE. BSF8 generates a 32-bit RAND challenge value.

3. BSF8 sends an HTTP 401 response to MN12. RAND is base64 encoded and conveyed in the nonce field of the WWW-Authenticate header. The field “qop-options” is set to “auth-int”. The payload also includes an indication that CAVE is the selected mechanism.

4. MN 12 extracts the selected mechanism from the payload and proceeds accordingly. In CAVE, the RAND challenge value received by the GBA function is transmitted to the R-UIM terminal or 1X terminal as a simulated global challenge.

5. The 1X terminal (or R-UIM) responds to the global challenge with AUTHR and SMEKEY. As a result, AUTHR and SMEKEY are delivered to the GBA function.

6. GBA function sets MS_PW to SMEKEY. In addition, the GBA function generates a secret random number “x” for the Diffie-Hellman method. Furthermore, the GBA function also generates a 32-bit random number CRAND used as a client nonce for digest authentication.

7. MN 12 sends another HTTP GET request to BSF 8 with an appropriate Authorization header. The digest response is assumed to be calculated using RFC2617 (attached as Attachment C to US Provisional Application No. 60 / 692,855 filed June 21, 2005) using a default password. CRAND is base64 encoded and conveyed in the cnonce field. The HTTP payload includes AUTHR and MS_RESULT, ie, g ^x mod p protected with a hash of SMEKEY with MS_PW = SMEKEY.

8. BSF8 confirms that the received MS_RESULT is not zero. The BSF 8 functioning as the VLR transmits AUTHREQ to the HLR / AC 4 ′. AUTHREQ includes RAND, SYSACCTYPE = GAA access and AUTHR parameters. All ESN parameters are set to zero. The SYSCAP parameter is set to indicate that the Authentication parameter was requested for this system access (bit-A = 1) and that signaling message encryption is supported by the system (bit-B = 1). All other bits of the SYSCAP parameter are preferably set to zero.

9. HLR / AC4 'confirms AUTHR and generates SMEKEY.

10. HLR / AC4 'responds with a TIA-41 AUTHREQ containing the SMEKEY parameter. If the authentication fails, AUTHREQ includes only an access denial instruction.

11. BSF8 authenticates MN12 by confirming the digest response using the default password. If successful, BSF8 sets BS_PW = SMEKEY and generates a secret random number “y” for the Diffie-Hellman method.

12. BSF8 generates 128-bit Ks. In addition, by obtaining the base64 encoded RAND value from step 3 and the BSF8 server name, a B-TID (Bootstrapping Transaction Identifier) value is also generated in the form of NAI, that is, base64encode (RAND) @BSF_servers_domain_name Become.

13. BSF8 sends a 200 OK response to MN12. The server digest response "rspauth" is calculated using the default password according to RFC 2617 (Appendix C of US Provisional Application No. 60 / 692,855, filed June 21, 2005), and Authentication-Info It is conveyed in the header. In addition, the payload of the 200 OK response also includes BS_RESULT, ie g ^y mod p protected with a SMEKEY hash, B-TID, lifetime of key Ks, selected mechanism (CAVE) indication and BS_AUTH. Including data in the BS_AUTH calculation can provide integrity protection. One exemplary method is as follows.

BS_AUTH [data] = SHA-1 (0x00000005 | 0x00000C80 + sizeof (data) | BS_PARAM | data | BS_PARAM | data) modulo 2 ¹²⁸

Where data is the information that needs integrity protection, and in this case includes the B-TID, the lifetime of the key, and an indication of the selected mechanism (CAVE).

14. MN12 confirms rspauth using default password according to RFC 2617 (Attachment C of US Provisional Application No. 60 / 692,855 filed on June 21, 2005), BS_AUTH equals XBS_AUTH ' Make sure (use the same calculation as BS_AUTH). In addition, the MN 12 confirms that the selected selected mechanism is CAVE. If successful, the server and sent message are authenticated. If unsuccessful, the MN 12 may abort the bootstrap procedure and try again immediately or later.

15. MN12 generates 128-bit Ks.

16. The MN 12 sends another HTTP GET request to the BSF 8 with an appropriate Authorization header. The digest response is calculated using the default password. The payload contains the original list of supported mechanisms (in this example {CAVE, B, C}) and MS_AUTH. Including data that needs protection in the MS_AUTH calculation can also provide integrity protection. One exemplary method is as follows.

MS_AUTH [data] = SHA-1 (0x00000004 | 0x00000C80 + sizeof (data) | MS_PARAM | data | MS_PARAM | data) modulo 2 ¹²⁸

Where data is the information that needs integrity protection, in this case the original list of supported mechanisms ({CAVE, B, C}).

17. BSF 8 authenticates MN 12 by confirming the digest response using the default password and confirming that MS_AUTH is equal to XMS_AUTH (same calculation as MS_AUTH). In addition, BSF8 verifies that the list of supported mechanisms is the same as the list received in step 2. If not, the BSF 8 may send an HTTP 403 Forbidden response or other error response to the MN 12 or abort the bootstrap procedure without notification (not shown).

18. If successful, BSF8 sends a 200 OK response to MN12.

  The above procedure can be modified in many ways. However, the basic concept according to the non-limiting exemplary embodiment disclosed in US patent application Ser. No. 11 / 232,494 remains the same, and therefore all possible variations are not described. In one variation, MS_AUTH and BS_AUTH are used as digest passwords in steps 16 and 17, respectively, in which case “data” may not be included in the calculation of MS_AUTH and BS_AUTH. Integrity protection in this case will be provided by a digest authentication mechanism. In yet another variation, MS_AUTH is not used on the MN 12 side and BS_AUTH is not used on the BSF 8 side, and only MS_AUTH or BS_AUTH is used on both. Again, “data” is not included in the calculation of MS_AUTH or BS_AUTH, and integrity protection is provided by the digest authentication mechanism.

Plain HTTP Transport In this non-limiting example, plain HTTP is used as a transport mechanism for MN 12 and BSF 8 to exchange password protected Diffie-Hellman parameters. Mutual authentication between MN12 and BSF8 is based on a password protected Diffie-Hellman mechanism using MS_AUTH and BS_AUTH.

  Figure 7 shows one exemplary implementation of bootstrap mechanism negotiation, with the selected mechanism being CAVE, and the bootstrap procedure using this CAVE is a 3 round HTTP GET / Requires a response. The bootstrap scenario based on MN-AAA Key is very similar and is not included here. The following is a more detailed description of the steps.

1. MN12 sends an HTTP GET request to BSF8. The payload includes a user identifier of the form “IMSI@realm.com”. In addition, the user includes a list of supported bootstrap / authentication mechanisms in the payload (eg, MN12 supports CAVE and two other mechanisms, B and C, {CAVE, B, C}).

2. BSF 8 reads a list of supported mechanisms from the payload and makes a decision based on the list, username (also from the payload), user profile, and / or other information. BSF 8 selects CAVE as the bootstrap mechanism and from this point on it is assumed that the bootstrap is based on this selected mechanism (eg CAVE etc.). BSF8 generates a 32-bit RAND challenge value.

3. BSF8 sends a response (200 OK, etc.) to MN12. RAND is base64 encoded and carried in the payload. The payload also includes an indication that CAVE is the selected mechanism.

4. The RAND challenge value received by the GBA function is sent to the R-UIM terminal or 1X terminal as a simulated global challenge.

5. The 1X terminal (or R-UIM) responds to the global challenge with AUTHR and SMEKEY. As a result, AUTHR and SMEKEY are delivered to the GBA function.

6. GBA function sets MS_PW to SMEKEY. In addition, the GBA function generates a secret random number “x” for the Diffie-Hellman method.

7. MN12 sends another HTTP GET request to BSF8. HTTP payload contains AUTHR and MS_RESULT, i.e. the g ^x mod p, which is protected by the hash of SMEKEY.

8. BSF8 confirms that the received MS_RESULT is not zero. The BSF 8 functioning as the VLR transmits AUTHREQ to the HLR / AC 4 ′. AUTHREQ includes RAND, SYSACCTYPE = GAA access and AUTHR parameters. All ESN parameters are set to zero. The SYSCAP parameter is set to indicate that the Authentication parameter was requested for this system access (bit-A = 1) and that signaling message encryption is supported by the system (bit-B = 1). All other bits of the SYSCAP parameter should be set to zero.

9. HLR / AC confirms AUTHR and generates SMEKEY.

10. The HLR / AC responds with a TIA-41 AUTHREQ that includes the SMEKEY parameter. If authentication fails, AUTHREQ may include only an access denial instruction.

11. BSF8 sets BS_PW = SMEKEY and generates a secret random number “y” for the Diffie-Hellman method.

12. BSF8 generates 128-bit Ks. In addition, by obtaining the base64-encoded RAND value from step 3 and the BSF8 server name, the B-TID value can also be generated in NAI format, that is, base64encode (RAND) @BSF_servers_domain_name.

13. BSF 8 sends a response (eg, 200 OK) to MN 12. The response payload can also include BS_RESULT, ie g ^y mod p protected with a hash of SMEKEY, B-TID, lifetime of key Ks, indication of selected mechanism (CAVE) and BS_AUTH. Including data in the BS_AUTH calculation can provide integrity protection. One exemplary method is as follows.

BS_AUTH [data] = SHA-1 (0x00000005 | 0x00000C80 + sizeof (data) | BS_PARAM | data | BS_PARAM | data) modulo 2 ¹²⁸

Where data is the information that needs integrity protection and includes B-TID, lifetime, and selected mechanism (CAVE) instructions.

14. The MN 12 confirms that BS_AUTH is equal to XBS_AUTH (the same calculation as BS_AUTH). In addition, the MN 12 confirms that the selected selected mechanism is CAVE. If successful, the server and sent message are authenticated. If unsuccessful, the MN 12 preferably aborts the bootstrap procedure and tries again immediately or later.

15. MN12 generates 128-bit Ks.

16. MN12 sends another HTTP GET request to BSF8. The payload includes MS_AUTH. The payload may also include the original list of supported mechanisms (in this example {CAVE, B, C}) and MS_AUTH. Including data that needs protection in the MS_AUTH calculation can also provide integrity protection. One exemplary method is as follows.

MS_AUTH [data] = SHA-1 (0x00000004 | 0x00000C80 + sizeof (data) | MS_PARAM | data | MS_PARAM | data) modulo 2 ¹²⁸

Where data is the information that needs integrity protection and the original list of supported mechanisms ({CAVE, B, C}).

17. BSF8 authenticates MN12 by confirming that MS_AUTH is equal to XMS_AUTH (same calculation as MS_AUTH). In addition, BSF8 verifies that the list of supported mechanisms is the same as the list received in step 2. If not, the BSF 8 may send an HTTP 403 Forbidden response or other error response to the MN 12 or abort the bootstrap procedure without notification (not shown).

18. BSF8 sends a response (200 OK, etc.) to MN12.

  The above procedure can be modified in many ways. However, the basic concept disclosed in accordance with the non-limiting exemplary embodiment disclosed in US patent application Ser. No. 11 / 232,494 remains unchanged.

XML schema definition
In 3GPP GBA, when bootstrapping is successful, the HTTP payload carries the B-TID (bootstrap transaction identifier) and key lifetime in the final 200 OK response. A related XML schema is defined in Attachment C of 3GPP TS 24.109. 3GPP extends this schema to allow the payload to carry other information required for bootstrapping based on SMEKEY and MN-AAA Key, which includes the parameters AUTHR (for CAVE) and password-protected -Includes Hellman parameters. In a non-limiting embodiment disclosed in US patent application Ser. No. 11 / 232,494, further extension of the XML schema is implemented to include a list of authentication mechanisms as well as instructions for selected mechanisms. Possible schema definitions are as follows, and the extension used to accommodate the non-limiting exemplary embodiment disclosed in US patent application Ser. No. 11 / 232,494 is underlined italicized: It is shown.

In this schema, the element “auth_list” is used to convey the list 11 of authentication and bootstrap mechanisms in messages 1 and 5 of FIGS. The element “auth” is used to convey an indication of the mechanism selected by the BSF in messages 3 and 7 of FIGS. The type "authType" is defined as enumerating current authentication and bootstrap mechanisms in various standards and may take the following exemplary values:

"3GPP-AKA": Bootstrap based on 3GPP AKA mechanism;
"3GPP2-AKA": Bootstrap based on 3GPP2 AKA mechanism;
"CAVE": Bootstrap based on SMEKEY (CAVE); and
“MN-AAA”: Bootstrap based on MN-AAA Key.

  As more authentication mechanisms are supported in GBA, the name corresponding to the new authentication mechanism is added to authType.

  Alternatively, only “AKA” may be defined in the schema, not both “3GPP-AKA” and “3GPP2-AKA”. In that case, the mechanism actually used in AKA is preset by the network operator.

  Note that the above schema is actually a specific example, and other techniques can achieve the same purpose. In addition, the schema may be extended to include other information useful when conveyed in the payload. For example, in the above example implementation using plain HTTP as a transport to convey password-protected Diffie-Hellman, the payload is other information such as username, RAND, MS_AUTH, BS_AUTH, etc. It is preferable to convey. The schema should therefore be extended accordingly so that these parameters are also conveyed.

  The authentication mechanism name in the above definition is a specific example and is used in the present specification without losing generality.

  Of course, the exemplary embodiments described in FIGS. 1-7 are simple, efficient and secure, do not require standardization efforts in the IETF, and provide for future authentication and bootstrap mechanisms. It is extensible to support and supports both 3GPP and 3GPP2 systems.

  A network device or network node such as BSF8 that performs a bootstrap procedure based on an apparatus, method and computer program according to non-limiting exemplary embodiments disclosed in US patent application Ser. No. 11 / 232,494 And a technology executed by a device or node such as MN12. This bootstrap procedure is the first bootstrap request for MN12 to send a first request message containing a list of authentication mechanisms supported by MN12 to BSF8; based on the list received by BSF8 from MN12, Determine the authentication mechanism to be used for bootstrapping, proceed with the selected authentication mechanism, and include the determined authentication mechanism indication in the response message to MN12; complete list of authentication mechanisms supported by MN12 Including sending the MN 12 to the BSF 8 based on the determined authentication mechanism, the second request message including at least partly integrity protection in a protected form. If the authentication is successful and the list received in the second request message matches the list received in the first request message, the network replaces the indication of the selected authentication mechanism in a integrity protected form. It is preferable to respond to the MN 12 using a success response message that is at least partially protected in integrity. When the MN 12 receives the success response message, the MN 12 may confirm that the authentication mechanism used by the MN 12 matches the authentication mechanism selected by the BSF 8. In addition, the first request message sent by the MN 12 may also include a user identifier, which may be used by the BSF 8 to help select an authentication mechanism.

  With the teachings according to the present invention, it is possible to accommodate multiple message rounds. As a non-limiting example, the negotiation may proceed with digest authentication or may proceed using HTTP.

  Thus, although non-limiting exemplary embodiments of the invention disclosed in US patent application Ser. No. 11 / 232,494 have been described, the non-limiting exemplary embodiments according to the present invention will now be described. Embodiments will be described. It should be noted that the exemplary embodiments of the present invention can be used with all or part of the various exemplary embodiments of the invention described in US patent application Ser. No. 11 / 232,494.

In accordance with an exemplary embodiment of the present invention, XML is clearly identified to identify the “connection” between a supported authentication mechanism and one or more identifiers (ids) that can be used with that particular mechanism. The schema is changed. If an identifier can be used with multiple mechanisms, the XML schema preferably describes all possible combinations. For example:
mechanism1 id1
mechanism1 id2
mechanism2 id3

  Referring now to Figure 8, when the first HTTP GET message with an XML document as payload (based on the XML schema) is received by BSF8 (message 1 in Figure 8), BSF8 uses the network preferred mechanism. Select and contact the appropriate database to proceed with the bootstrap procedure. If the selected mechanism can accidentally be used with more than one identifier (listed by the MN 12 in the XML document in the HTTP payload), the BSF 8 selects one of the identifiers. When the selection is performed, the XML document returned by the BSF to the MN 12 in a 401 response to the GET request (message 5 in FIG. 8) clearly identifies the selected mechanism and the corresponding associated identifier.

  Note that the XML schema defines how an XML document will appear. The XML document is then sent within the payload of the HTTP message. As such, XML schemas should be considered fixed and are not sent during bootstrap. An XML document according to this XML schema is transmitted as an HTTP payload so as to convey information required for bootstrap.

  The identifiers inserted in the bootstrap procedure message according to the above contents are as follows.

A. HTTP GET request from MN12 to BSF8 (Message 1 in Fig. 8)

The Authorization header in the HTTP GET request may include one of the identifiers of MN12. BSF8 does not use this identifier at this point. The XML document in the HTTP payload preferably includes a list of supported mechanisms and an identifier of the MN 12 as described above.

B. HTTP 401 Unauthorized response from BSF8 to MN12 (Message 5 in Fig. 8)

BSF 8 selects one authentication mechanism and one corresponding identifier from the list found in the XML document in the HTTP payload received from MN 12. The selected authentication mechanism and the corresponding identifier are returned to the MN 12 in the payload of the response message.

C. HTTP GET request from MN12 to BSF8 (message 7 in Figure 8)

The MN 12 uses the identifier returned by the BSF 8 in the payload of the previous message as a user identifier in HTTP digest authentication (Authorization header field). Subsequently, the MN 12 and the BSF 8 proceed according to the authentication mechanism selected by the BSF. As described above, the XML document in the HTTP payload preferably includes a supported mechanism and an identifier of the MN 12. Unlike message 1, this information is integrity protected.

D. HTTP 200 OK response from BSF8 to MN12 (message 9 in Fig. 8)

BSF8 responds with an HTTP 200 OK message indicating successful authentication and bootstrap operation. In addition, this message also contains a digest response calculated by the BSF. The message further includes an indication of the selected authentication mechanism and the corresponding identifier for reference to the MN 12. Similarly, setting qop to "auth-int" protects the integrity of this directive.

  Subsequently, the rest of the bootstrap procedure is described in 3GPP2 S.P0109-0, Version 0.6, December 8, 2005, “General Purpose Bootstrap, attached to the above US Provisional Application No. 60 / 759,487 as Attachment C. Continue as described in "Wrapping Architecture (GBA) Framework". This document is scheduled to be issued as 3GPP2 S.S0109-0, v1.0, and the current latest version is S00-20060220-121A_SP0109_V & V_changes.doc.

[Change XML Schema]
The current XML schema is as follows.

  There are several possible changes that can be made to the XML schema described above to implement an exemplary embodiment of the invention. The following are some examples that are intended to be read as illustrative, not as limiting the practice and / or use of exemplary embodiments of the invention.

[Example 1]

XML schema 1

The following is a “fragment” of the “auth_list” example according to the XML schema described above.

[Example 2]

XML schema 2

The following is a "fragment" of an "auth_list" example according to this XML schema.

[Example 3]

XML schema 3

The following is a “fragment” of examples of “auth_list” and “clientid_list”.

  FIG. 8 shows an example of a call flow using the XML schema 1 described above. An example of this is shown in 3GPP2 S.P0109-0, Version 0.6, December 8, 2005, “General Purpose Bootstrapping Architecture (GBA), attached to US Patent Provisional Application No. 60 / 759,487 above as Attachment C. ) ・ Obtained from Figure C.3-1 of Appendix C of the Framework. The example of FIG. 8 highlights changes in the HTTP payload, so that only messages 1, 5, 7, and 9 are particularly relevant to understanding the exemplary embodiment of the present invention. The rest of the figure may be unchanged from that shown in Appendix C.

Message 1. First GET request (MN12 to BSF8)

The purpose of this message is to initiate the bootstrap procedure between MN12 and BSF8. The MN 12 transmits an HTTP request including the private user identifier to the BSF 8. The MN 12 also shows a list of supported bootstrap mechanisms in the message payload along with the corresponding identifier.

Table: Example of the first GET request (MN12 to BSF8)
GET / HTTP / 1.1

Message 5. 401 Unauthorized response (BSF8 to MN12)
BSF8 sends a challenge to MN8 (without CK, IK and XRES) in an HTTP 401 Unauthorized response. This is to request the MN 12 to prove that the MN 12 itself is genuine. Challenges include RAND and AUTIN, which are placed in the nonce field according to RFC 3310 (IETF RFC 3310 “Digest AKA”, attached as Attachment B to the above-mentioned US Provisional Application No. 60 / 759,487).

Table: 401 Unauthorized response example (BSF8 to MN12)
HTTP / 1.1 401 Unauthorized

Message 7. Example of GET request (from MN12 to BSF8)
The MN 12 transmits an HTTP GET request to the BSF 8 again together with RES used for response calculation.

Table: Example of GET request (MN12 to BSF8)
GET / HTTP / 1.1

Message 9. 200 OK response example (BSF8 to MN12)
BSF 8 sends a 200 OK response to MN 12 to indicate successful authentication.

Table: 200 OK response (BSF8 to MN12)

  In view of the foregoing, it will be appreciated that an exemplary embodiment of the present invention includes a first comprising a list of authentication mechanisms supported by a node and corresponding identification information associated with each authentication mechanism. A message is sent to the wireless network (WN), the authentication mechanism used for bootstrapping is determined at the WN based at least on the list received from the node, and the authentication determined in the first response message to the node Methods, apparatus and computer program (s) are provided that include information about the mechanism along with corresponding identification information.

  Of course, in the present invention, an aspect of the exemplary embodiment is that the corresponding identification information is also included when the “authentication mechanism” is transmitted in the HTTP payload. In the present specification, the identification information is also called an identifier without losing generality. From this point, in the first request and the second request from the MN 12, a list of supported mechanisms is included in the HTTP payload, and thus corresponding identification information is also included. Similarly, in the first response and the second response transmitted by the WN, the selected authentication mechanism is included in the payload, and the corresponding identification information is also included. Further, the second request from MN 12 also includes a list and corresponding identification information, which is integrity protected. Similarly, if there is a selected mechanism and corresponding identification information in the second response, these are preferably also protected for integrity.

  In general, the various embodiments may be implemented in hardware or special purpose circuits, software, logic or any combination thereof. For example, some aspects may be implemented in hardware, while other aspects may be implemented in firmware or software that can be executed by a controller, microprocessor, or other computer device. It is not limited to. While various embodiments of the invention may be illustrated and represented as block diagrams, flowcharts, or using other graphical representations, it should be understood that these blocks, devices, systems, described herein, The techniques or methods may be implemented in hardware, software, firmware, dedicated circuitry or logic, general purpose hardware or general purpose controller, or other computer device, or some combination thereof, as non-limiting examples. .

  Embodiments of the invention can be practiced with various components such as integrated circuit modules. Integrated circuit design is generally a highly automated process. There are a number of complex and powerful software tools that can be used to translate a logic level design into a semiconductor circuit design that can be readily etched and formed on a semiconductor substrate.

  Programs such as those offered by Synopsys, Inc. of Mountain View, California, and Cadence Design of San Jose, California, are established. Automatically route conductors and position components on the semiconductor chip using the stored design rules as well as a library of stored design modules. Once the design of the semiconductor circuit is complete, the resulting design is converted into a standardized electronic form (eg Opus, GDSII, or the like) for manufacturing into a semiconductor processing facility, or “fab” It may be transmitted by.

  Various modifications and adaptations will be readily apparent to those skilled in the art upon reading and considering the foregoing description in conjunction with the accompanying drawings. As a non-limiting example, other types of message formats, etc. may be used to communicate information between device 12 and wireless network component (s) 8 and / or other types May be employed instead of or in addition to those specifically described above. It should be noted that any changes to the teachings of the present invention fall within the scope of the non-limiting embodiments of the present invention.

  Further, some features of the various non-limiting embodiments of the present invention may be used and served without the use of other features. Thus, the foregoing description is merely illustrative of the principles, teachings, and exemplary embodiments of the invention and should not be construed as limiting the invention.

1 is a block diagram illustrating a 3GPP2 GBA reference network architecture. FIG. A bootstrap procedure with selection of an authentication mechanism. This is an example of an error scenario caused by MITM attack. It is another example of an error scenario due to MITM attack. FIG. 4 is an example of mechanism selection with bootstrap using multi-round message exchange. It is the upper half of FIG. FIG. 6 is a non-limiting example of negotiation using HTTP digest authentication. It is the lower half of FIG. FIG. 6 is a non-limiting example of negotiation using HTTP digest authentication. It is the upper half of FIG. FIG. 7 is a non-limiting example of negotiation using plain HTTP transport. It is the lower half of FIG. FIG. 7 is a non-limiting example of negotiation using plain HTTP transport. FIG. 3 is a bootstrap procedure with selection of an authentication mechanism according to an exemplary embodiment of the present invention, the source of which is 3GPP2 S.P0109 attached as Attachment C to the above-mentioned US Provisional Application No. 60 / 759,487. -0, Version 0.6, December 8, 2005, Figure C.3-1: Bootstrap signaling based on Figure C.3-1: AKA in "Generic Bootstrapping Architecture (GBA) Framework" Appendix C (Bootstrapping signaling based on AKA).

Claims (61)

Receiving a first message in a wireless network (WN) comprising a list of authentication mechanisms supported by the node and a corresponding identifier associated with each authentication mechanism;
Determining an authentication mechanism to be used for bootstrapping at the WN based at least on the list received from the node;
Including in a second message sent to the node information including the determined authentication mechanism along with a corresponding identifier.   The method of claim 1, further comprising selecting one of the identifiers associated with the determined authentication mechanism if the determined authentication mechanism is usable with more than one identifier. .   The method of claim 1, wherein the first message includes an HTTP GET request, and the second message includes a first response message that includes an XML document that clearly identifies the determined authentication mechanism and a corresponding identifier. . A third message that includes at least a list of authentication mechanisms supported by the node and a corresponding identifier in an integrity protected form and is at least partially integrity protected based on the determined authentication mechanism; Receiving at the WN;
If authentication is successful and the list received in the third message matches the list received in the first message, the node is used with a second response message that is at least partially integrity protected. Wherein the second response message may include an indication of the selected authentication mechanism and a corresponding identifier in a integrity protected form;
4. The method of claim 3, further comprising:   5. The method of claim 4, further comprising: receiving the third message; and verifying that the authentication mechanism used by the node matches the authentication mechanism determined by the WN. Method.   The method of claim 1, wherein at least the determining is performed by a Bootstrapping Server Function (BSF).   The method of claim 1, wherein the first message is an HTTP GET and the list is included in an HTTP payload.   The method of claim 1, wherein the second message is an HTTP 401 Unauthorized response.   The method of claim 4, wherein the third message is an HTTP GET that includes a response calculated according to the selected authentication mechanism.   The method of claim 4, wherein the second response message is an HTTP 200 OK message. A computer program integrated in a computer readable medium, wherein execution of the computer program by a node data processor comprises the following operations:
Sending a first message comprising a list of authentication mechanisms supported by the node and a corresponding identifier associated with each authentication mechanism to a wireless network (WN); and in the first message by the node Receiving from the WN a first response message that includes information about the authentication mechanism selected by the WN from the provided list, along with a corresponding identifier.   Further comprising sending an at least partially integrity-protected second message to the WN comprising the list of authentication mechanisms supported by the node and the corresponding identifier in an integrity-protected form. 12. The computer program according to claim 11.   12. The act of receiving an at least partially integrity-protected second response message that includes an indication of the selected authentication mechanism along with the corresponding identifier in an integrity-protected form. A computer program described in 1.   The computer program product of claim 13, wherein at least the first response message and the second response message are received from a bootstrapping server function (BSF).   12. The computer program product of claim 11, wherein the first message is transmitted as an HTTP GET, the list is included in an HTTP payload, and the first response message is received as an HTTP 401 Unauthorized response.   13. The computer program product of claim 12, wherein the second message is transmitted as an HTTP GET that includes a response calculated according to the selected authentication mechanism.   The computer program product of claim 13, wherein the second response message is received as an HTTP 200 OK message.   12. The computer program product of claim 11, further comprising verifying that the authentication mechanism used by the node matches the authentication mechanism selected by the WN.   A device comprising a data processor combined with a transmitter and a receiver, the data processor comprising a list of authentication mechanisms supported by the device and a corresponding identifier associated with each authentication mechanism A first message is transmitted to the network via the transmitter, and a first response message including information about an authentication mechanism selected by the network from the list along with a corresponding identifier is sent from the network via the receiver. A device that is operable to receive.   The data processor protects the integrity of the list of authentication mechanisms supported by the device, and the list of authentication mechanisms supported by the device and the corresponding identifier in a integrity protected form. 20. The device of claim 19, further operable to transmit at least partially integrity-protected second message to the network via the transmitter, at least including.   The data processor further includes an at least partially integrity-protected second response message from the network that includes an indication of the selected authentication mechanism and the corresponding identifier in an integrity-protected form. 20. The device of claim 19, wherein the device receives.   22. The device of claim 21, wherein at least the first response message and the second response message are received from a bootstrapping server function (BSF) that forms part of the network.   20. The device of claim 19, wherein the first message is sent as an HTTP GET, the list is included in an HTTP payload, and the first response message is received as an HTTP 401 Unauthorized response.   21. The device of claim 20, wherein the second message is sent as an HTTP GET that includes a response calculated according to the selected authentication mechanism.   The device of claim 21, wherein the second response message is received as an HTTP 200 OK message.   20. The device of claim 19, wherein the data processor is further operable to verify that an authentication mechanism used by the device matches the authentication mechanism selected by the network. A computer program integrated in a computer readable medium, wherein execution of the computer program by a data processor of a wireless network element (WNE) comprises the following operations:
Receiving from the node a first message comprising a list of authentication mechanisms supported by the node and a corresponding identifier associated with each authentication mechanism;
Determining an authentication mechanism to be used for bootstrapping based at least on the list received from the node;
Sending to the node a first response message including information about the determined authentication mechanism and a corresponding identifier; and integrity-protecting the list of authentication mechanisms supported by the node and the corresponding identifier. Receiving a second message, at least partially integrity-protected, from the node, at least partially in the form of a computer program.   If the authentication is successful and the list received in the second message matches the list received in the first message, the selected authentication mechanism and the corresponding identifier are integrity protected. 28. The computer program product of claim 27, further comprising an act of sending to the node a second response message that is in form and that is at least partially integrity protected.   28. The computer program product of claim 27, further comprising reading a profile based on the identifier, wherein the determining action takes into account the profile.   28. The computer program product of claim 27, wherein the wireless network comprises a bootstrapping server function (BSF).   28. The computer program product of claim 27, wherein the first message is received as an HTTP GET that includes an identifier of a user of the node, and the list is included in an HTTP payload.   28. The computer program product of claim 27, wherein the first response message is transmitted as an HTTP 401 Unauthorized response.   28. The computer program product of claim 27, wherein the second message is received as an HTTP GET that includes a response calculated according to the selected authentication mechanism.   30. The computer program product of claim 28, wherein the second response message is transmitted as an HTTP 200 OK message.   A network device including a data processor combined with a transmitter and a receiver, the data processor comprising a list of authentication mechanisms supported by the node and a corresponding identifier associated with each authentication mechanism. A first message comprising: a first message operable to receive from the node via the receiver, wherein the data processor includes at least a portion of the authentication mechanism used for bootstrapping in the list received from the node. Is further operable to transmit a first response message to the node via the transmitter, the first response message including information about the determined authentication mechanism and a corresponding identifier. Integrity is maintained for the list of authentication mechanisms supported by the node and corresponding identifiers. Been comprises format, the second message at least partially integrity protected, is further operable to receive from the node, the network device.   When the data processor is successfully authenticated and the list received in the second message matches the list received in the first message, an indication of the selected authentication mechanism and the corresponding 36. The network device of claim 35, further operable to send an at least partially integrity-protected second response message to the node that includes an identifier in an integrity-protected form.   36. The network device of claim 35, wherein the data processor is further operable to retrieve a profile based on the identifier for consideration when determining the authentication mechanism used for bootstrapping.   36. The network device of claim 35, comprising a bootstrapping server function (BSF).   36. The network device of claim 35, wherein the first message is received as an HTTP GET that includes an identifier of a user of the node and the list is included in an HTTP payload.   36. The network device of claim 35, wherein the first response message is transmitted as an HTTP 401 Unauthorized response.   36. The network device of claim 35, wherein the second message is received as an HTTP GET that includes a response calculated according to the selected authentication mechanism.   The network device according to claim 36, wherein the second response message is transmitted as an HTTP 200 OK message.   Means for transmitting to the network a first message comprising a list of authentication mechanisms supported by the device and a corresponding identifier associated with each authentication mechanism; describing an authentication mechanism selected by said network from said list Means for receiving from the network a first response message including information and a corresponding identifier, supported by the device for transmitting to the network a second message at least partially integrity protected. Means for protecting the integrity of the list of authentication mechanisms, wherein the second message includes the list of authentication mechanisms supported by the device and a corresponding identifier associated with each authentication mechanism. A device that contains it in a protected form.   The receiving means receives from the network an at least partly integrity-protected second response message that includes the selected authentication mechanism indication and the corresponding identifier in an integrity-protected form. 44. The device of claim 43, further operable.   44. The device of claim 43, further comprising means for verifying that the authentication mechanism used by the device matches the authentication mechanism selected by the network.   Means for receiving from the node a first message comprising a list of authentication mechanisms supported by the node and a corresponding identifier associated with each authentication mechanism; and an authentication mechanism used for bootstrapping from the node. Means for selecting based at least in part on the received list; and means for transmitting to the node a first response message including information about the selected authentication mechanism and a corresponding identifier, the receiving means Further operable to receive from the node a second message that is at least partially integrity protected, including the list of authentication mechanisms supported by the node and the corresponding identifier associated with each authentication mechanism. A network device that is possible.   The transmitting means transmits an at least partially integrity-protected second response message to the node that includes an indication of the selected authentication mechanism and the corresponding identifier in an integrity-protected form. 47. Accordingly, the network device of claim 46 responsive to a successful authentication and a match between the list received in the second message and the list received in the first message.   47. The network device of claim 46, further comprising means for reading a profile based on the identifier for use by the selection means when selecting the authentication mechanism used for bootstrapping.   49. The network device of claim 46, comprising a bootstrapping server function (BSF).   A system comprising a device coupled to a network device, the device comprising a data processor combined with a transmitter and a receiver, the data processor comprising a list of authentication mechanisms supported by the device And a first message comprising a corresponding identifier associated with each authentication mechanism is operable to transmit to the network device via the transmitter, the network device being at the transmitter and receiver. Including a combined data processor, wherein the data processor is operable to select an authentication mechanism from the list, the device comprising information and correspondence about the authentication mechanism selected from the list by the network device The first response message containing the identifier Received from the network device via a receiver, the data processor of the device at least in part at least in part in the integrity of the list of authentication mechanisms supported by the device and the corresponding identifier. A system that is operable to protect and transmit a second message including the list of authentication mechanisms and a corresponding identifier to the network device via the transmitter.   The data processor further includes an at least partially integrity protected second response message that includes, in integrity protected form, an indication of the authentication mechanism selected by the network device and the corresponding identifier. 51. The system of claim 50, wherein the system is received from the network device.   51. The system of claim 50, wherein the network device comprises a bootstrapping server function (BSF).   51. The system of claim 50, wherein the device is coupled to the network device through a wireless link. Sending a first message to the network comprising a list of authentication mechanisms supported by the device and a corresponding identifier associated with each authentication mechanism;
Receiving from the network a first response message that includes information about an authentication mechanism selected from the list by the network along with a corresponding identifier. Protecting at least the integrity of the list of authentication mechanisms supported by the device and the corresponding identifier;
55. The method of claim 54, further comprising: transmitting a second message including at least the list of authentication mechanisms and the corresponding identifier to the network. 55. The method of claim 54, further comprising receiving an at least partially integrity-protected second response message from the network that includes an indication of the selected authentication mechanism and the corresponding identifier.   57. The method of claim 56, wherein at least the first response message and the second response message are received from a bootstrapping server function (BSF) that forms part of the network.   55. The method of claim 54, wherein the first message is sent as an HTTP GET, the list is included in an HTTP payload, and the first response message is received as an HTTP 401 Unauthorized response.   56. The method of claim 55, wherein the second message is sent as an HTTP GET that includes a response calculated according to the selected authentication mechanism.   57. The method of claim 56, wherein the second response message is received as an HTTP 200 OK message.   55. The method of claim 54, further comprising verifying that an authentication mechanism used by the device matches the authentication mechanism selected by the network.

Images