MX2007015841A - Apparatus, method and computer program product providing mobile node identities in conjunction with authentication preferences in generic bootstrapping architecture (gba). - Google Patents

Abstract

In one exemplary and non-limiting aspect thereof a method is provided that includes sending a wireless network (WN) a first message that includes a list of authentication mechanisms supported by a node and, in association with each authentication mechanism, a corresponding identity; determining in the WN an authentication mechanism to be used for bootstrapping, based at least on the list received from the node; and including information in a second message that is sent to the node, the information including the determined authentication mechanism in conjunction with a corresponding identity. The method further includes protecting at least the list of authentication mechanisms supported by the node and the corresponding identities and sending a second message to the network, the second message including at least the list of authentication mechanisms and the corresponding identities. The method further includes receiving a second response message from the network that is at least partially integrity protected, where the second response message includes an indication of the selected authentication mechanism and the corresponding identity.

Description

APPARATUS, METHOD AND PRODUCT OF COMPUTER PROGRAM THAT PROVIDES IDENTITIES OF MOBILE NODE IN CONJUNCTION WITH PREFERENCES OF AUTHENTICATION IN ARCHITECTURE OF STARTING GENERIC TECHNICAL FIELD OF THE INVENTION The exemplary and non-restrictive embodiments of this invention generally refer to systems, methods and communication devices and, more specifically, relate to authentication and related techniques used in communication systems.

BACKGROUND OF THE INVENTION The following definitions are given together with the present: 3GPP Third Generation Society Project AAA Authentication, Authorization and Accounting GAA Generic Authentication Architecture GBA Generic Boot Architecture BSF Role of AKA Boot Server Authentication Agreement and IM Key Multiple Media ISIM IP Identity Services Module NA NAI Network Access Identifier MN Mobile Node UE User Equipment EV-DO Only Evolution Data The 3GPP GBA (see 3GPP TS 33.220"GAA.GBA", added as Annex A, to the aforementioned US Provisional Patent Application No. 60 / 759,487) focuses on the specification of a mechanism for authentication agreement and startup key for application security from the 3GPP AKA mechanism. The GBA is also being introduced in 3GPP2, where apart from AKA, the boot based on legacy key materials, which include the SMEKEY (for CDMA lx systems) and the MN-AAA key (for CDMA lx EV-DO systems), is also They are standardizing. As a result, when operating in a 3GPP2 system, an MN can support, or may be required to support, more than one authentication and startup mechanism. Therefore, a technique is needed for the MN and the network to match over the algorithm set to be used at startup. The same is required for future terminals that support both 3GPP and 3GPP2 networks, such that a 3GPP terminal can swim in a 3GPP2 network (< and vice versa) and still use GBA. In addition, it is possible for operators to deploy both 3GPP and 3GPP2 networks in the same geographic location. In such cases, the terminals also have to negotiate with the network the boot mechanism to be used. The 3GPP supports only one authentication and boot mechanism, that is, the summarized AKA mechanism and AKA protocol with algorithms defined by 3GPP. The use of AKA with summary authentication is specified in summary AKA (see IETF RFC 3310"Digest AKA", added as Annex B to the aforementioned US Provisional Patent application No.: 60 / 759,487). In 3GPP2 there are different mechanisms for booting supported on the network side, since both legacy and non-legacy terminals need to be supported. The MN may have support for multiple authentication mechanisms and key generation (eg, AKA, MN-AAA, CAVE) and may have multiple secrets previously provided. In 3GPP2 there is a defined mechanism selection procedure, which instructs the MN to insert in the payload of the first message it sends to the BSF, the list of supported authentication mechanisms, allowing the BSF to select the authentication mechanism it prefers. Once the BSF selects the authentication and key generation mechanism, it contacts the correct database and extracts the authentication data. For example, if the MN supports MN-AAA, in addition to other mechanisms, and the BSF selects MN-AAA, then the BSF will be in contact with the H-AAA to extract a query. The MN also has one or more identities.

For example, if the MN has an ISIM application, then it has a private identity. If the MN is an EV-DO terminal, then it has an NAI. If the MN is a terminal lx, then it has an identity similar to IMSI. This creates a problem, because when the MN first contacts the BSF by sending a request to obtain HTTP (HTTP GET) (according to 3GPP2 S.P0109-0, Version 0.6, 08 December 2005, "Generic Bootstrapping Architecture (GBA) Framework", added as Annex C to the aforementioned US Provisional Patent Application No.: 60 / 759,487), is instructed to insert its identity in the application. Because most identities can only be used with specific authentication and key generation mechanisms (for example, private identity can only be used with AKA, IMSI can only be used by CAVE, EV-DO, NAI can only be used used by MN-AAA), by selecting and including one of its identities in the GET request, the MN implicitly preselects the authentication mechanism as well. With a specific identity already inserted, the BSF can not make another choice for the mechanism than the one that identity can use. Alternatively, a mapping of the different identities of an MN may need to be accessible by the BSF, but this procedure may not be desirable for several reasons.

SUMMARY OF THE INVENTION According to exemplary non-restrictive modalities thereof, this invention provides a method that includes receiving in a wireless network (WN) a first message that is comprised of a list of authentication mechanisms, supported by a node and, in association with each authentication mechanism, a corresponding entity; determining in the WN an authentication mechanism to be used for the boot, based on at least the received list of the node; and include information in a second message that is sent to the node, the information comprises the authentication mechanism determined in conjunction with a corresponding identity. In accordance with exemplary and nonrestrictive embodiments thereof, this invention further provides a computer program product exemplified in a computer readable medium, which execution by a data processor of a node comprises operations of sending a wireless network (WN), a first message that is comprised of a list of authentication mechanisms supported by the node and, in association with each authentication mechanism, a corresponding identity; and receiving a first response message from the WN, the first response message comprises information pertaining to an authentication mechanism selected by the WN from the list provided by the node in the first message, in conjunction with a corresponding identity. In accordance with the exemplary and non-limiting embodiments, this invention further provides a device that includes a data processor, coupled to a transmitter and a receiver and operating to send to a network through the transmitter, a first message that is comprised of a list of authentication mechanisms, supported by the device and, in association with each authentication mechanism, a corresponding identity, and to receive a first response message from the network through the receiver, the first response message comprises information that belongs to an authentication mechanism selected by the network of the list, in conjunction with a corresponding identity. In addition, in accordance with exemplary and non-limiting embodiments, this invention provides a computer program product, exemplified in a computer-readable medium, which is executed by a wireless network element (WNE) data processor. it comprises operations of receiving a first message from a node, which is included in the list of authentication mechanisms, supported by the node and, in association with each authentication mechanism, a corresponding identity; determining an authentication mechanism to be used for startup, based on at least the received list of the node; sending a first response message to the node, the first response message comprises information belonging to the given authentication mechanism and a corresponding identity; and receiving a second message from the node that is at least partially protected in its integrity, the second message comprises at least the list of authentication mechanisms that the node supports, and the corresponding identities, in a fully protected form. In addition, according to exemplary and non-limiting embodiments, this invention provides a network device that includes a data processor, coupled to a transmitter and a receiver, and which operates to receive a first message from a node through the receiver. which is comprised of a list of authentication mechanisms, supported by the node and, in association with each authentication mechanism, a corresponding identity. The data processor also operates to determine an authentication mechanism to be used for startup, based at least in part on the received list of the node, and to send a first response message to the node through the transmitter, the first response message comprises information belonging to the determined authentication mechanism and a corresponding identity. The data processor further operates to receive from the node a second message that is at least partially protected in integrity, the second message comprises the list of authentication mechanisms that the node supports, and corresponding identities, in a fully protected manner. Further, in accordance with exemplary and non-limiting embodiments, this invention provides a device that includes means for sending to a network, a first message that is comprised of a list of authentication mechanisms supported by the device and, in association with each mechanism of authentication, a corresponding identity; and means for receiving a first response message from the network, the first response message comprises descriptive information of an authentication mechanism selected by the network between the list and a corresponding identity. The device also includes means to protect in its entirety the list of authentication mechanisms, supported by the device and to send a second message to the network, which is at least partially protected in its integrity, the second message comprises, in a protected form in its entirety, the list of authentication mechanisms that the device supports and, in association with each authentication mechanism, a corresponding identity. Additionally, in accordance with exemplary and non-restrictive embodiments, this invention provides a network device that includes means for receiving from a node, a first message that is comprised of a list of authentication mechanisms supported by the node and, in association with each authentication mechanism, a corresponding identity, means for selecting an authentication mechanism to be used for the startup, based at least in part on the received list of the node, and means for sending a first response message to the node, the The first response message comprises information pertaining to the selected authentication mechanism and a corresponding identity. The receiving means also operates to receive from the node a second message that is at least partially protected in its integrity, the second message comprises the list of authentication mechanisms that the node supports and, in association with each authentication mechanism, the corresponding identity . Additionally, in accordance with exemplary and non-restrictive embodiments, this invention provides a system having a device coupled to a network device, wherein the device comprises a data processor coupled to a transmitter and a receiver and operating to send the device to the device. network through the transmitter, a first message that is comprised of a list of authentication mechanisms, supported by the device and, in association with each authentication mechanism, a corresponding identity. The network device comprises a data processor, coupled to a transmitter and a receiver and operates to select an authentication mechanism from the list. The device receives from the network device through the receiver, a first response message, wherein the first response message comprises information pertaining to the authentication mechanism, selected by the network device between the list and a corresponding identity. The data processor of the device is operable to at least partially protect the integrity, of at least the list of authentication mechanisms, supported by the device, and the corresponding identities, and to send through the transmitter, a second message to the device of network, the second message comprises the list of authentication mechanisms and the corresponding identities. Additionally, in accordance with exemplary and non-restrictive embodiments, this invention provides a method that includes sending to a network, a first message that is comprised of a list of authentication mechanisms, supported by a device and, in association with each authentication mechanism. , a corresponding identity; and receiving a first response message from the network, the first response message comprises information pertaining to an authentication mechanism, selected by the network between the list, in conjunction with a corresponding identity.

BRIEF DESCRIPTION OF THE DRAWINGS In the figures of the accompanying drawings: Figure 1 is a block diagram illustrating the 3GPP2 GBA reference network architecture; Figure 2 illustrates a start-up procedure with an authentication mechanism selection; Figure 3 is an example of an error environment with an MITM attack; Figure 4 is another example of an error environment with an MITM attack; Figure 5 shows an example of boot mechanism selection, which uses multiple series of message exchanges; Figure 6 shows an example of non-restrictive negotiation using HTTP summary authentication; Figure 7 shows an example of non-restrictive negotiation using simple HTTP transport; and Figure 8 illustrates a start-up procedure with a selection of authentication mechanism, in accordance with the exemplary embodiments of this invention, and is adapted from Figure C.3-1: AKA-based start signaling found in the Annex C of 3GPP2 S.P0109-0, Version 0.6, 08 December 2005, "Generic Bootstrapping Architecture (GBA) Framework", added as Annex C to the aforementioned US Provisional Patent application No.: 60 / 759,487.

DETAILED DESCRIPTION OF THE INVENTION The exemplary and non-restrictive embodiments of this invention are directed in general to authentication, and more specifically address the Architecture of Generic Startup (GBA) 3GPP, which has been defined in 3GPP and has also been introduced in 3GPP2. Figure 1 shows the reference architecture of non-restrictive startup in general. Figure 1 shows a System of Local Subscriber (HSS) (2), a Local Position Registration (HLR) (4), a server (6), Access, Authentication and Accounting (AAA), the BSF (8), a Network Application Function (NAF) (10) and the User / Node Team Mobile (MN) (12), as well as the interfaces between these components. It is assumed that the appropriate transmitters (Tx) and receivers (Rx) are used to communicate information and messages between the MN (12), the BSF (8) and other components of the network. The exemplary and non-restrictive embodiments of the invention relate mainly to the procedures related to the interface Ub between the MN (12) and the BSF (8), where the startup is performed. Note that a mobile terminal is referred to as User Equipment (UE) in 3GPP, and as a Mobile Node (MN) in 3GGP2. In this patent application, these terms may be used interchangeably without a loss of generality, and may also be referred to more generally as a device or as a node. The exemplary and non-restrictive embodiments of this invention provide a mechanism for negotiating supported mechanisms / algorithms for startup between the MN (12) and the network. The exemplary and non-restrictive embodiments of this invention provide a solution for the MN (12) and the network element (BSF (8)) to agree on an authentication and startup mechanism to be used in GBA (3GPP2 environment) ), and also define how the mechanism can be integrated into existing 3GPP procedures. It is assumed that MN (12) has a list (11) of the authentication and boot mechanisms it supports, such as by storing the list (11) in a memory (MEM) (12A) coupled to a data processor ( DP) (12B). It is also assumed that the memory (12A) includes program code to operate the DP (12B) in accordance with the various embodiments of this invention. It is further assumed that the BSF (8) also includes a memory (MEM) (8A) coupled to a data processor (DP) (8B). It is assumed that the memory (8A) includes program code to operate the DP (8B) in accordance with the various embodiments of this invention. In general, the various modalities of MN (12) may include, without restriction, cell phones, personal digital assistants (PDAs) that have wireless communication capabilities, laptops that have wireless communication capabilities, image capture devices such as digital cameras that have wireless communication capabilities, gaming devices that have wireless communication capabilities, music storage and playback devices that have wireless communication capabilities, devices of Internet that allow the access and the search in wireless Internet, as well as units or portable terminals that incorporate combinations of such functions. In other embodiments, the node may not include a transmitter and a receiver that is capable of performing wireless communications with a network through a wireless link, since wired connections may be used instead of through a cable or wires, including one or both electrical and optical interconnections. The memories (8A) and (12A) can be of any type suitable for the local technical environment and can be implemented using any suitable data storage technology, such as semiconductor-based memory devices, devices and magnetic memory systems , devices and systems of optical memory, fixed memory and removable memory. The data processors (8B) and (12B) may be of any type suitable for the local technical environment, and may include one or more general-purpose computers, special-purpose computers, microprocessors, digital signal processors (DSP) and processors based on multi-core processor architecture, as non-restrictive examples. In general, exemplary embodiments of this invention can be implemented by computer software, executable by an MN data processor (12), such as DP (12B), or by hardware circuitry, or by a combination of software and circuitry of hardware. The embodiments of this invention can also be implemented by computer software, executable by a BSF data processor (8), such as DP (8B), or by hardware circuitry, or by a combination of software and hardware circuitry. . First, reference is made to U.S. Patent Application Serial No. 11 / 232,494, filed on 09/21/2005, entitled: "Method, Apparatus and Product of Computer Program that Provides Selection of Boot Mechanism in Generic Startup Architecture ( GBA) ", by Gabor Bajko and Tat Keung Chan, whose entire exhibition is considered part of this, as a reference. U.S. Patent Application Serial No. 11 / 232,494 is added as Annex D to the aforementioned US Provisional Patent Application No. 60 / 759,487, and claims priority under United States Code 35 § 119 (e) of the US Provisional Patent Application No. 60 / 690,528 filed on 06/13/2005, and US Provisional Patent Application No. 60 / 692,855, filed on 06/21/2005 (mentioned several times below), the entire disclosure of which is hereby incorporated by reference. It is considered part of this, as a reference. Before describing the further exemplary embodiments of this invention, and for the purpose of achieving a more complete understanding thereof, a description of the subject matter described in the United States Patent Application Serial Number 11 / 232,494 is now provided. Reference is made later to Figures 2-7 in this regard. In an exemplary embodiment, the start-up procedure, in accordance with the non-restrictive embodiments described in U.S. Patent Application Serial No. 11 / 232,494, comprises the following steps, which are described in greater detail below with respect to Figure 2. A. In an initial start request, the MN (12) presents the list (11) of authentication mechanisms it supports, to the BSF (8) in a request. The MN (12) also includes the identity of the user. B. The BSF (8) decides on the authentication mechanism that will be used for the boot, based on the list (11) received from the MN (12) and other information (including as non-limiting examples, the mechanisms that the BSF (8) itself supports, and the profile of the user recovered based on the identity of the user ). The BSF (8) then proceeds with the selected authentication mechanism, which commonly includes responding with an authentication interrogation. The BSF (8) also includes in the response, an indication of the chosen authentication mechanism. C. The MN (12) sends a new HTTP request to the BSF (8) that contains the response to the generated interrogation, based on the selected authentication mechanism. The message also includes the original list (11) of the authentication mechanism supported by the MN (12), only this time it is protected in its entirety. D. The BSF (8) verifies if the answer to the interrogation is correct, and considers the successful MN authentication in case the response corresponds to the expected response. If the authentication is successful, and the list (11) received in step C is the same as in step A, the BSF (8) responds to the MN with a successful HTTP response. The response message may also include an indication of the selected authentication mechanism, which is fully protected. E. The MN (12) receives the successful response and can verify that the chosen authentication mechanism is the indicated one. Since the first two messages (steps A and B) commonly can not be protected because the two parties have not authenticated each other, an MITM aggressor can intercept message A and remove a strong authentication mechanism in the list, leaving only one or several poor authentication mechanisms in the list for the BSF (8) to choose. This results in a nbiá-áown attack ", where the boot procedure is forced to be based on a more deficient authentication mechanism even when the stronger ones are supported by both parties (for example, the BSF (8) and the MN (12) The procedure, in accordance with the non-restrictive modalities described in U.S. Patent Application Serial No. 11 / 232,494, eliminates these types of nbid-down attacks "by forcing MN (12) to repeat the list in a form protected entirely in step C, thus allowing the BSF (8) to detect an attack by MITM, if the lists in steps A and C do not match, describing now in greater detail the various aspects of the non-restrictive modalities, described in U.S. Patent Application Serial No. 11 / 232,494, in 3GPP, the Ub interface (between the MN (12) and the BSF (8)) is based on HTTP summary authentication.The same mechanism has been adopted in 3GPP2. For example, for 3GPP and 3GPP2 AKA, summary AKA is used, while for the boot of the CDMAlx and CDMA EV-DO systems, HTTP summary authentication with password-protected Diffie-Hellman procedure (based on SMEKEY and MN 12-AAA key respectively) is used) (See contribution 3GPP2: "Boot Procedures for CDMA lx and CDMA lx EV-DO Systems", 3GPP2 TSG-S WG4, Portland, May 2005). In other words, possible authentication and boot mechanisms may include at least the following: 3GPP AKA (the algorithm is not specified, it is operator specific); 3GPP2 AKA (SHA-1 is the ordered algorithm); Start based on SMEKEY; and Start based on MN-AAA key. In the future, more authentication mechanisms may be available and can be easily included in the MN-BSF selection procedure. To eliminate the need to standardize a summarized variant for each IETF authentication mechanism, it is preferred that the list of supported authentication mechanisms and the selected authentication mechanism be inserted into the payload of HTTP messages, instead of carrying this information in the summary authentication headers. Figure 2 shows the message sequence for a GBA boot procedure with selection of authentication mechanism, and is explained in more detail as follows: Step (1.). The MN (12) sends an initial start request in the form of an HTTP GET to the BSF (8).

The MN (12) includes the identity of the user in the Authorization header. In addition, the list of supported authentication mechanisms (for example [A, B, C]) is included in the HTTP payload. Step 2.) . After receiving the start request, the BSF (8) extracts the list of supported authentication mechanisms from the payload. Based on the extracted authentication mechanisms, the list of authentication mechanisms that the same BSF (8) supports, the user profile (retrieved based on the user's identity), and possibly other information, the BSF (8) decides about the authentication mechanism to use at startup. Step 3.) . The BSF (8) sends an unauthorized HTTP 401 response to the MN (12). The response comprises the appropriate information based on the selected authentication mechanism. For example, if 3GPP AKA is selected, the authenticated WWW header contains AKA parameters according to IETF RFC 3310"Digest AKA". In addition, the payload will include an indication of the selected authentication mechanism (in this case, A). In addition, the quality of protection (qop) for summary authentication is set to "auth-int", indicating that full protection of the payload is required.

Step 4.) . The MN (12) retrieves the selection of the BSF (8) from the payload and continues the authentication process according to the selection. Commonly, this will include calculating a response based on the interrogation received and some shared secrets. Step (5.). The MN (12) sends a new start request in the form of HTTP GET to the BSF (8), with the response calculated according to the selected authentication mechanism. In addition, the payload comprises the original list of authentication mechanisms supported by the MN (12). Since the qop has been set to "auth-int", this original list is included in the calculation of the summary response and is therefore protected in its entirety. Step (6.). The BSF (8) first verifies that the list presented in the payload matches the one received in step (2.). Only if a match is discovered, the BSF (8) continues with the authentication based on the selected mechanism. Commonly, this comprises verifying the received summary response and calculating a response from the server for the server-side authentication object. Step (7.). The BSF (8) responds with an HTTP 200 OK message, indicating a successful authentication and startup operation. The message also includes the summary response, calculated by the BSF. The message may also include an indication of the authentication mechanism selected for reference by the MN (12). Similarly, this indication is fully protected by setting the qop to "auth-int". Step (8.). The MN (12) can verify that the selected authentication mechanism is of course the same as that indicated in step (3.). It should be noted, that the mechanism works perfectly even without including the authentication mechanism selected in the HTTP 200 OK response. Step (9.). Both the BSF (8) and the MN (12) derive the boot key, based on the selected mechanism of authentication and startup. Figure 3 illustrates the environment when an MITM aggressor (14) attempts a bid-down attack as described above. The following explains each step in Figure 3. Step (1.). Same as in step (1.) as in figure 2. The original list (11) contains, for example, three supported mechanisms, specifically, A, B and C. Step (la.). The message (1.) is intercepted by the aggressor of MITM (14). The original list (11) is replaced with a list containing only mechanism C, which may be the weakest of the three supported. Step 2.). The BSF (8) extracts the list, which contains only mechanism C and therefore selects C and proceeds. Step 3.) . Same as in step (3.) in figure 2, with mechanism C indicated. Step 4.). The MN (12) believes that the BSF (8) has chosen mechanism C and therefore proceeds accordingly. Step (5.). Same as in step (6.) in figure 2. Although the MN (12) proceeds with the mechanism C, it includes the original list of [A, B, C] in the payload, which is protected in its entirety and by therefore, the aggressor of MITM (14) can not modify the message. Step (6.). The BSF (8) while verifying the received list finds that it is not the same as that received in step (2.). It concludes that a bid-down attack has been launched and therefore aborts the startup procedure, Step (7.). sending an HTTP message 403 Prohibited. Alternatively, the BSF (8) can detect this attack when the list received in step (2) does not match as indicated in the user's profile, in which case it can also decide to abort the boot procedure. This is illustrated in steps (1.), (2.) and (3.) of Figure 4. In addition, according to the non-restrictive modalities described in U.S. Patent Application Serial No. 11 / 232,494, minus one belongs to those cases where the boot procedure for the selected authentication mechanism involves more than two series of requests / responses to complete it. For example, start-up based on summarized AKA requires two series of requests / responses to complete. Since the previous modality describes the cases where SMEKEY-based startup and MN-AAA key may require two series of requests / responses as well, there may be cases where more than two request / response series are required. In such cases, non-restrictive modalities, described in US Patent Application Serial No. 11 / 232,494, still apply. This environment is illustrated in Figure 5 and is explained as follows: Step (1.). In an initial startup request, the MN (12) presents a list of authentication mechanisms that it supports (eg, {A, B, C.}.) To the BSF (8) in a request. The MN (12) also includes the identity of the user. It can be assumed that in most cases this list is not protected.

Step 2.). The BSF (8) decides on the authentication mechanism to be used for the startup, based on the list received from the MN (12) and other information (which includes the mechanisms that the same BSF (8) supports, and the profile of the user recovered based on the identity of the user). Figure 5 assumes as a non-restrictive example, that mechanism A is chosen. Step (3.). Then the BSF (8) proceeds with the chosen authentication mechanism, which commonly includes responding with an authentication interrogation. The BSF (8) also includes the response, an indication of the chosen authentication mechanism (mechanism A in this example). Again, this indication may not be protected. It should be noted that from this point the MN (12) and the BSF (8) continue with the selected mechanism (for example mechanism A as illustrated in figure 5).

As already indicated above, different mechanisms may require different numbers of series of message exchanges (for example, requests / responses) to complete the startup procedure. For example, the summarized AKA mechanism requires one more request / response after step (3.) is completed; while for the CAVE-based boot and the MN-AAA key, additional series may be required. In accordance with the exemplary embodiments of this invention, in one of these subsequent messages, the MN (12) sends the original list (11) (as it is sent in the message (1.) again, but this one is protected (ie, protected in its entirety), while the BSF (8) can send the chosen mechanism (as it is sent in the message (3.) again, but it is protected (ie, protected integrity) .Note that while the MN ( 12) sends the original list (11) protected again, it is optional (but it is preferable) that the BSF (8) sends the chosen mechanism protected again If these newly protected parameters are sent, the other party is enabled to verify that the parameter sent is the same as the original parameter received, to detect any attempt by an MITM aggressor to change the original parameters, which have been sent unprotected In the following description, integrity protection is used as an example technique. plar to protect the parameters. It should be understood that the parameters can also be encoded. Step 4.) . Still with reference to Figure 5, in step (4.) the MN (12) calculates the responses according to mechanism A. Steps (5.) - (6.). There may be multiple request / response series between the MN (12) and the BSF (8), as explained. In some of these series, the chosen mechanism may not be able to provide the required integrity protection. Therefore, the MN (12) and the BSF (8) may not be able to send the protected parameters in their entirety. Step (7.). At some point of the boot procedure, the MN (12) may be able to send a message that includes data that is protected in its entirety. For example, in the message (7.) it is assumed that the MN (12) is capable of sending such a message. If so, the MN (12) will include the original list (11) (the list {A, B, C.}. In the example) that is protected in its entirety, indicated by P [. { A, B, C.}. ] in Figure 5. Step (8.). Upon receiving the message, the BSF (8) verifies that the list protected in its integrity is the same as the list originally sent by the MN (12) in the message (1.). If not, the BSF (8) can send an error response to the MN (12) to abort the operation (not shown). Alternatively, the BSF (8) can silently abort the operation. Step (9.). At a certain point in the boot procedure, the BSF (8) may be able to send a message that includes data that is protected in its entirety. For example, in the message (9.), it is assumed that the BSF (8) is capable of sending such a message. The BSF can include the chosen mechanism (mechanism A in the example) that is fully protected, indicated by P [A] in figure 5. Step (10.). Upon receiving the message, the MN (12) verifies that the selected mechanism protected in its integrity is the same as that originally sent by the BSF (8) in the message (2.). If not, the MN (12) may send an error message to the BSF (8) to abort the operation (not shown). Alternatively, the MN (12) can silently abort the operation. Step (11.). If successful, both parties are able to derive the boot key Ks according to the selected boot mechanism. It can be seen that steps (7.) and (8.), and steps (9.) and (10.) (if present), do not need to be in the order described, and that these do not need to be in messages Consecutive That is, the BSF (8) can send a message with the protected parameter in its integrity (the chosen mechanism) first, and the MN (12) can send a message with the protected parameter in its integrity (the list of supported mechanisms) at a later time. In addition, there may be more message series, before and after the messages protected in their entirety are sent. The following description provides exemplary implementations, in accordance with the non-restrictive modes, described in US Patent Application Serial No. 11 / 232,494, using HTTP summary authentication (Figure 6) and HTTP total transport (Figure 7). It should be noted that exemplary and restrictive embodiments, described in US Patent Application Serial No. 11 / 232,494, are not limited by these two examples, and can be implemented using other transport / authentication mechanisms as well (eg, the Extensible Authentication (EAP for its acronym in English)). In the following descriptions, it is assumed that the parameters necessary for the negotiation of the mechanism (the list (11) of the supported mechanisms, sent by the MN (12), and the chosen mechanism, sent by the BSF (8)) are to send in payloads in HTTP messages. Note, however, that these parameters can alternatively be carried in appropriate headers in HTTP messages.

HTTP Summary Authentication In this exemplary implementation, HTTP summary authentication with password-protected Diffie-Hellman procedure is used for startup. You can use a default password (for example "11 ... 1") as the summarized password, so that mutual authentication between the MN (12) and the BSF (8) is currently based on the Diffie-Hellman mechanism password protected, using MS_AUTH and / or BS_AUTH. The details of the password-protected Diffie-Hellman mechanism are based on WKEY generation procedures (wireless LAN key) described in the wireless LAN interworking specification, which is specified in 3GPP2 (see section 7.1.1 of "Wireless LAN interworking"). "3GPP2 X.P0028, attached as an annex to US Provisional Patent Application No.: 60 / 692,855, filed on 06/21/2005). Figure 6 illustrates an exemplary implementation of the boot mechanism negotiation with the chosen mechanism that is CAVE, where the CAVE boot procedure requires three series of HTTP requests / responses together. The boot environment based on the MN-AAA key is very similar, and therefore is not described in more detail. The following describes the steps shown in Figure 6 in greater detail. Step 1.). The MN (12) sends an HTTP GET request to the BSF (8). The identity of the user, in the form of IMSI @ realm. com, is included as the username in the authorization header. In addition, the user sends the list (11) of the boot / authentication mechanisms supported in the payload (eg, { CAVE, B, C.}., Which means that the MN (12) supports CAVE and two other mechanisms, B and C). Step 2.) . The BSF (8) retrieves the list of supported mechanisms from the payload and makes a decision based on the list, the user's name, the user's profile and / or other information, and the BSF (8) selects CAVE as the starting mechanism in this non-restrictive example. From this point, the boot is based on the chosen mechanism, which is CAVE. The BSF (8) generates a 32-bit RAND interrogation value. Step 3.). The BSF (8) sends an HTTP response 401 to MN (12). The RAND is coded with base 64 and is carried in the particular field of the authenticated WWW header. The "qop options" field is set to "auth-int".

The payload also contains an indication that CAVE is the chosen mechanism. Step 4.). The MN (12) extracts the chosen mechanism from the payload and proceeds accordingly. For CAVE, the RAND interrogation value, received by the GBA function, is sent to the R-UIM or terminal IX as a simulated Global interrogation. Step (5.). Terminal IX (or R-UIM) responds to the global interrogation with an AUTHR and SMEKEY. The AUTHR and the SMEKEY are then delivered to the GBA function.

Step (6.). The GBA function sets MS_PW to be the SMEKEY. It also generates a secret random number "x" for the Diffie-Hellman method. For summary authentication, the GBA function also generates a 32-bit random number, CRAND, which is to be used as a customer's particular. Step (7.). The MN (12) sends another HTTP GET request to the BSF (8) with an appropriate authorization header. It is assumed that the summary response will be calculated in accordance with RFC2617 (added as Annex C to US Provisional Patent Application No. 60 / 692,855, filed on 06/21/2005) using the default password. The CRAND is coded with base 64 and is carried in the field cnonce. The HTTP payload contains the AUTHR and the MS_RESULT, that is, gx mod p covered by the SMEKEY hash with MS_PW = SMEKEY). Step (8.) The BSF (8) verifies that the received MS_RESULT is not zero. The BSF (8), which acts as a VLR, sends an AUTHREQ to the HRL / AC 4 '. The AUTHREQ includes the RA? D, the SYSACCTYPE access = GAA and the AUTHR parameters. The parameter ES? is set for all zeros. The SYSCAP parameter is set to indicate that the authentication parameters were requested in this system access (bit-A = l) and that the Coding of the Signaling Message is supported by the system (bit-B = l).

All other bits of the SYSCAP parameter are preferably set to zero. Step (9.). The HLR / AC 4 'verifies the AUTHR and generates the SMEKEY. Step (10.). The HLR / AC 4 'responds with a AUTHREQ TIA-41 that includes the SMEKEY parameter. If authentication fails, the AUTHREQ will only include an indication to deny access. Step (11.). The BSF (8) authenticates the MN (12) verifying the summary response using the default password. If successful, the BSF (8) establishes BS_PW = SMEKEY and generates a random secret number wy "for the Diffie-Hellman method Step (12.) The BSF (8) generates the 128 bit Ks The B-TID value of the NAI format is also generated taking the RAND value encoded with base 64 of step (2.), and the name of the BSF server (8), that is, base64encode (RAND) @BSF_servers_domain_name Step (13.) The BSF (8) sends a response 200 OK to MN (12) The summary response of the server, "rspauth" is calculated in accordance with RFC 2617 (Annex C to the United States Provisional Patent No. 60 / 692,855, filed 06/21/2005) using the default password and carried in the Authentication Info header. The payload of the 200 OK response also contains the BS_RESULT, that is, gx mod p, covered by the SMEKEY hash, the B-TID, the life type of the Ks key, an indication of the selected mechanism (CAVE) and BS_AUTH. Note that integrida protection can be provided by including the data in the calculation of BS_AUTH. An exemplary way is the following: BS_AUTH [data] = SHA-1 (0x00000005 | 0x00000C80 + size of (data) | BS_PARAM | data | BS_PARAM | data) module 2128, where data is the information needed to protect it in its entirety, and in this case includes the B-TID, key life time, and the indication of the chosen mechanism (CAVE). Step (14.). The MN (12) verifies rspauth according to RFC 2617 (Annex C to US Provisional Patent Application No. 60 / 692,855, filed on 06/21/2005) using the default password, and verifies that BS_AUTH is equal to XBS_AUTH '(using the same calculation as BS_AUTH). The MN (12) also verifies that the chosen mechanism indicated is CAVE. If successful, the server and the sent message are authenticated. If it is not successful, the MN (12) aborts the boot procedure and can try immediately or at a later time. Step (15.). The MN (12) generates the Ks of 128 bit Step (16.). The MN (12) sends another HTTP GET request to the BSF (8) with an appropriate authorization header. The summary response is calculated using the default password. The payload contains the original list of supported mechanisms ( { CAVE, B, C.}. In this example) and MS_AUTH. Integrity protection can be provided including the data that needs to be protected in the calculation of MS_AUTH. An exemplary way is the following: MS_AUTH [data] = SHA-1 (0x00000004 | 0x00000C80 + size of (data) | MS_PARAM | data | MS_PARAM | data) module 2128, where data is the information that needs to be protected in its entirety , which in this case is the original list of supported mechanisms ( { CAVE, B, C.}.). Step (17.). The BSF (8) verifies the summarized response using the default password and authenticates the MN (12) by verifying that the MS_AUTH is equal to XMS_AUTH (same calculation as MS_AUTH). The BSF (8) also 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 Prohibition 403 response, or other error responses to the MN (12), or silently abort the boot procedure (not shown). Step (18.). If successful, the BSF (8) sends a 200 OK response to the MN (12). Note that there are many possible variations in the previous procedure. However, the basic concepts in accordance with exemplary non-restrictive modalities, described in US Patent Application Serial Number 11/232494 they remain the same and, therefore, not all possible variations are described. A variation is that MS_AUTH and BS_AUTH are used as the password summarized in steps (16.) and (17.) respectively, in which case the "data" may not be included in the calculation of MS_AUTH and BS_AUTH. Integrity protection in that case will be provided by the summary authentication mechanism. Still another variation is that instead of using MS_AUTH on the side of the MN (12) and BS_AUTH on the side of the BSF (8), only MS_AUTH or BS_AUTH on both sides will be used. Again, the "data" is not included in the calculation of MS_AUTH or BS_AUTH, and integrity protection is provided by the summary authentication mechanism.

HTTP total transport In this non-restrictive example, total HTTP is used as a transport mechanism for the MN (12) and the BSF (8), to exchange the password protected Diffie-Hellman parameters. Mutual authentication between the MN (12) and the BSF (8) is based on the password protected Diffie-Hellman mechanism using MS_AUTH and BS AUTH.

Figure 7 illustrates an exemplary implementation of a boot mechanism negotiation with the chosen mechanism that is CAVE, and where the CAVE boot procedure requires three HTTP GET / response series. The boot environment based on the MN-AAA key is very similar and therefore is not included here. The following describes the steps in more detail. Step 1.). The MN (12) sends an HTTP GET request to the BSF (8). The identity of the user, in the form of "IMSI @ realm. Com", is included in the payload. In addition, the user includes the boot / authentication mechanism list supported in the payload (ie, { CAVE, B, C.}., That is, the MN (12) supports CAVE and two other mechanisms, B and C). Step 2.). The BSF (8) retrieves the list of supported mechanisms from the payload and makes a decision based on the list, the name of the user (also of the payload), the profile of the user, and / or other information. It is assumed that the BSF (8) selects CAVE as the boot mechanism, and from this point, the boot is based on the chosen mechanism (for example, CAVE). The BSF (8) generates a 32-bit RAND interrogation value. Step 3.) . The BSF (8) sends a response (for example 200 OK) to the MN (12). The RAND is coded with base64 and is carried in the payload. The payload also contains an indication that CAVE is the chosen mechanism. Step 4.) . The RAND interrogation value received by the GBA Function is sent to the R-UIM or to the IX terminal as a simulated Global interrogation. Step (5.). The terminal IX (or the R-UIM) responds to the global interrogation with an AUTHR and the SMEKEY. The AUTHR and SMEKEY are then delivered to the GBA function. Step (6.). The GBA function sets MS_PW to be SMEKEY. It also generates a secret random number wx "for the Diffie-Hellman method Step (7.) The MN (12) sends another HTTP GET request to the BSF (8). The HTTP payload contains the AUTHR and the MS_RESULT , ie, g mod p covered by the SMEKEY hash Step (8.) The BSF (8) verifies that the received MS_RESULT is not zero The BSF (8), which acts as a VLR, sends an AUTHREQ to the HLR / AC 4 'The AUTHREQ includes the RAND, the SYSACCTYPE access = GAA and the AUTHR parameters The ES? Parameter is set for all zeros.The SYSCAP parameter is set to indicate that the authentication parameters were requested in this access to the system (bit-A = l) and that the Coding of the Signaling Message is supported by the system (bit-B = l) All the other bits of the SYSCAP parameter can be set to zero Step (9.) The HLR / AC checks the AUTHR and generates the SMEKEY Step (10.) The HLR / AC responds with an AUTHREQ TIA-41 that includes the SMEKEY parameter. If authentication fails, the AUTHREQ may include only an indication of access denial. Step (11.). The BSF (8) sets BS_PW = SMEKEY and generates a random secret number "y" for the Diffie-Hellman method. Step (12.). The BSF (8) generates the 128 bit Ks. The B-TID value can also be generated in the NAI format by taking the RAND value encoded with base64 from step (2.), and the name of the BSF server (8), that is, base64encode (RAND) ®BSF_servers_domain_name. Step (13.). The BSF (8) sends a response (for example 200 OK) to the MN (12). The payload of the response can contain the BS_RESULT, that is, g and mod p, covered by the SMEKEY hash, the B-TID, the lifetime of the key Ks, an indication of the chosen mechanism (CAVE) and BS_AUTH. Note that the full protection can be provided by including the data in the calculation of BS_AUTH. An exemplary way is the following: BS_AUTH [data] = SHA- (0x00000005 | 0x00000C80 + sizeof (data) | BS_PARAM | data | BS_PARAM | data) module 2128, where data is the information that needs to be protected in its entirety, and includes B-TID, time of life, and the indication of the chosen mechanism (CAVE). Step (14.). The MN (12) verifies that the BS_AUTH is equal to XBS_AUTH (same calculation as BS_AUTH). The MN (12) also verifies that the chosen mechanism indicated is CAVE. If successful, the server and the message sent are authenticated. If it is not successful, the MN (12) preferably aborts the boot procedure and can retry immediately or at a later time. Step (15.). The MN (12) generates the Ks of 128 bit Step (16.). The MN (12) sends another HTTP GET request to the BSF (8). The payload contains MS_AUTH. The payload can also contain the original list of supported mechanisms ( { CAVE, B, C.}. In this example) and MS_AUTH. Integrity protection can be provided including the data that needs to be protected in the calculation of MS_AUTH. An exemplary way is the following: MS_AUTH [data] = SHA - (0x00000004 | 0x00000C80 + sizeof (data) | MS_PARAM | data | MS_PARAM | data) module 2128, where data is the information that needs to be protected in its entirety, and the list original of supported mechanisms ( { CAVE, B, C.}.). Step (17.). The BS authenticates the MN (12) by verifying that MS_AUTH is equal to XMS_AUTH (same calculation as MS_AUTH). The BS also 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 Prohibition 403 response, or other error responses to the MN (12), or it may silently abort the startup procedure (not shown). Step (18.). The BSF (8) sends the response (for example 200 OK) to the MN (12). Note that there are many possible variations in the previous procedure. However, the basic concepts described in accordance with the exemplary and non-restrictive embodiments described in U.S. Patent Application Serial No. 11 / 232,494, remain the same.

Definition of XML schema In 3GPP GBA, an HTTP payload carries the B-TID (Startup Transaction Identifier) and the lifetime of the key in the final response 200 OK if the boot is successful. The associated XML schema is defined in Annex C of 3GPP TS 24.109. 3GPP2 extends this scheme to allow the payload to carry other information necessary for startup, based on SMEKEY and the MN-AAA key, these include the AUTHR parameter (for CAVE) and password-protected Diffie-Hellman parameters.

The non-restrictive modalities described in US Patent Application Serial No. 11 / 232,494 allow the XML Schema to be further extended to include the list of authentication mechanisms, as well as the indication of the selected mechanism. One possible definition of the scheme is the following, wherein the extensions used to support the exemplary and non-restrictive embodiments described in US Patent Application Serial No. 11 / 232,494 are shown underlined and in italics. < ? xml version- '1.0"encoding =" UTF-8"? <xs: schema targetNamespace =" uri: 3gpp2-gba "xmlns: gba =" uri: 3gpp2-gba "xmlns: xs-' http: / /www.w3.org/2001/XMLSchema "> < ! ~ defnition of the root element containing B-TID, key lifetime, and other parameters ~ > < xs: complexType name = "bootstrappingInfoType" > < xs: sequence > < xs: element name- 'btid "type =" xs: string "minOccurs =" 0"/ > < xs: element name-' lifetime" type = "xs: dateTime" minOccurs = "0" / > < xs: element name = "authr" type = "xs: base64Binary" minOccurs = "0" / > < xs: element name = "ms_result" type = "xs: base64Binary" minOccurs = "0" / > < xs: element name = "bs_result" type- "xs: base64 Binary" minOccurs = "0" / > < xs: element name = "auth list" minOccurs = "0" > < xs: simpleTvpe > < xs: list itemTvpe = "eba: authTvpe" í > < Ixs: simpleTvpe > < / xs: element > < xs: element name = "auth" tvpe = "gba. authType" minOccurs = "0" / > < / xs: sequence > < / xs: complexType > < / - definition of type of authentication and boot mechanism- > < xs: simpleTvpe name = "authType" > < xs: restriction base = "xs: string" > < xs: enumeration value = "3GPP-AKA" í > < xs: enumeration value = "3GPP2-AKA" / > < xs: 'enumeration valué - "CA VE" Í > < xs: enumeration value = "MN-AAA" / > < Ixs: restriction > < Ixs: simpleTvpe > < ! - the root element - > < xs: element name- 'Bootstrappinglnfo "type =" gba: bootstrappingInfoType "/ > < / xs: schema > In the scheme, the "auth_list" element is used to carry the list (11) of the authentication and boot mechanisms in messages (1.) and (5.), in figures 2 and 3. The "auth" element it is used to carry an indication of the selected BSF mechanism in messages (3.) and (7.) in figures (2) and (3). It is defined that the "authType" type is an enumeration of the current authentication and boot mechanisms in the various standards, and can take the following exemplary values: "3GPP-AKA": boot based on 3GPP mechanism AKA; "3GPP2-AKA": boot based on 3GPP2 mechanism AKA "CAVE" start based on SMEKEY (CAVE); and "MN-AAA": start based on the MN-AAA key. When more authentication mechanisms are supported in GBA, the corresponding names of the new authentication mechanisms are added to authType. Alternatively, instead of having both "3GPP-AKA" and "3GPP2-AKA", only "AKA" you can define the scheme. The actual mechanism used in AKA is then preconfigured by the network operator. Note that the above scheme is exemplary by nature, and other techniques are possible to achieve the same goal. In addition, the scheme can be extended to include other information that is useful to carry on payloads. For example, in the exemplary implementation that uses full HTTP as transport to carry the password protected Diffie-Hellman method described above, preferably the payloads carry other information such as the user's name, RAND, MS_AUTH, BS_AUTH, and so on. Therefore the scheme can be extended to allow these parameters to be carried as well. It should be noted that the names of the authentication mechanisms in the above definition are exemplary, and are used herein without a loss of generality. It should be noted that the exemplary modalities described in Figures 1-7 are simple, efficient and secure, do not require standardization effort in IETF, are extensible to support future authentication and startup mechanisms, and support both 3GPP and 3GPP2 systems. According to an apparatus, method and computer program product, in accordance with the exemplary and non-restrictive embodiments described in US Patent Application Serial No. 11 / 232,494, a technique for execution by a device or node is provided. network, such as the BSF (8), and a device or node, such as the MN (12), to execute a startup procedure comprising, in an initial startup request, the MN (12) sending to the BSF (8). ) a first request message that includes a list of authentication mechanisms that the MN (12) supports; the BSF (8) determines an authentication mechanism to be used for the startup, based at least on the list received from the MN (12), and proceeding with the selected authentication mechanism and including in a response message to the MN (12) ), an indication of the determined authentication mechanism; the MN (12) sends a second request message, which is at least partially protected in its entirety, to the BSF (8) based on the determined authentication mechanism, the second request message includes the list of authentication mechanisms that the MN (12) supports in a fully protected manner. If the authentication is successful, and if the list received in the second request message corresponds to the list received in the first request message, the network can respond to the MN (12) with a successful response message, which is at least partially protected in its entirety, wherein the successful response message includes an indication of the selected authentication mechanism in a fully protected manner. The MN (12), after receiving the successful response message, can verify that the authentication mechanism used by the MN (12) corresponds to the authentication mechanism selected by the BSF (8). The first request message sent by the MN (12) may also comprise the identity of the user, which may be used by the BSF (8) to help select the authentication mechanism. Multiple message series can be accommodated by the techniques according to the invention. The negotiation can proceed by summary authentication, or it can proceed using HTTP, as non-restrictive examples. Having thus described exemplary non-restrictive embodiments of the invention, described in U.S. Patent Application Serial No. 11 / 232,494, a description is now given of the exemplary and non-restrictive embodiments of the invention, in accordance with this invention. It can be noted that the exemplary embodiments of this invention can be used in conjunction with all or some of the various exemplary embodiments of the invention, described in U.S. Patent Application Serial No. 11 / 232,494. In accordance with the exemplary embodiments of this invention, the XML schema is modified in such a way as to clearly identify the "union" between the supported authentication mechanism or the identity or identities (ids) that can be used with that specific mechanism. If you can use an identity with multiple mechanisms, then the XML schema preferably lists all possible combinations, for example: Mechanism 1 idl Mechanism 1 id2 Mechanism 2 id3 Referring now to Figure 8, once the first HTTP GET message with the XML document (based on the XML schema) it is received as a payload by the BSF (8) (message (1.) in Figure 8), the BSF (8) selects the preferred mechanism for the network and contacts the appropriate database to proceed with the startup procedure. If it happens that the selected mechanism is usable with more than one identity (as listed by the MN (12) in the XML document, in the HTTP payload), then the BSF (8) selects one of the identities. Once the selection is made, the XML document is returned to the MN (12) by the BSF in the response (401) (message (5.) in Figure 8) so that the GET request explicitly identifies the selected mechanism and the corresponding associated identity. You can notice that the XML schema defines how an XML document will appear. The XML document is then sent in the payload of the HTTP message. Therefore, it can be considered that the XML schema will be fixed, and it is not sent during startup. However, the documents XML in accordance with this XML schema, are sent as HTTP payload, to communicate the necessary information for the boot. According to the above, the identities will be inserted in the messages of the boot procedure, as follows: A. HTTP GET request from the MN (12) to the BSF (8) (message (1.) in figure 8) The authorization header in the request HTTP GET can contain any of the MN identities (12).

The BSF (8) does not trust this identity on this occasion. Preferably, the XML document in the HTTP payload contains the list of supported mechanisms and MN identities (12) as described above. B. UNAUTHORIZED HTTP 401 response from the BSF (8) to MN (12) (message (5.) in Figure 8) The BSF (8) selects an authentication mechanism and a corresponding identity from the list found in the XML document, in the HTTP payload received from the MN (12) The selected authentication mechanism and the corresponding identity are returned to the MN (12) in the payload of the response message. C. The HTTP GET request of the MN (12) to the BSF (8) (message (7.) of Figure 8). The MN (12) uses its identity returned by the BSF (8) in the payload of the previous message, such as the identity of the user in the HTTP summary authentication (authorization header field). The MN (12) and the BSF (8) then proceed according to the authentication mechanism selected by the BSF (8). Preferably, the XML document in the HTTP payload contains the supported mechanisms and identities of the MN (12), as described above. Unlike the message (1.), this information is fully protected. D. HTTP 200 OK response from the BSF (8) to the MN (12) (message (9.) in figure 8) The BSF (8) responds with an HTTP 200 OK message, indicating a successful authentication and startup operation . The message also includes the summary response, calculated by the BSF. The message may also include an indication for reference by the MN (12). Similarly, this indication is fully protected by setting qop to "auth-int". The rest of the boot procedure can then proceed as described in 3GPP2 S.P0109-0, Version 0.6, 08 December 2005, "Generic Bootstrapping Architecture (GBA) Framework", added as Annex C to the US Provisional Patent application previously mentioned No .: 60 / 759,487. It is expected that this document will be published as 3GPP2 S.S0109-0, vl.O, and currently the most recent version is S00-20060220-121A_SP0109_VScV_changes.doc.

XML schema modification The current XML schema is as follows: < ? xml version = "1.0" encoding = "UTF-8"? > < xs: schema targetNamespace = "uri: 3gpp2-gba" xmlns: gba = "uri: 3gpp2-gba" xmlns: xs = "http://www.w3.org/2001/XMLSchema" > < ! - definition of the root element containing B-TID, key lifetime, and other parameters- > < xs: complexType name = "bootstrappingInfoType" > < xs: sequence > < xs: element name = "btid" type = "xs: string" minOccurs = "0" / > < xs: element name- 'üfetime "type-' xs: dateTime" minOccurs = "0" / > < xs: element name = "esn" type = "xs: base64Binary" minOccurs = "0" / > < xs: element name = "ms_chall" type- lxs: base64Binary "minOccurs =" 0'7 > < xs: element name = "ms_result" type- 'xs: base64 Binary "minOccurs =" 0"/ > < xs: element name =" bs_result "type =" xs: base64Binary "minOccurs =" 0'7 > < xs: element name = "auth_list" minOccurs = "0" > < xs: simpleType > < xs: list itemType = "gba: authType'7> &xs: simpleType > ß &xs: element > < xs: element name =" auth "type =" gba: authType "minOccurs =" 0'7 > < / xs: sequence > < / xs: complexType < ! -definition of type of authentication mechanism and startup ~ > < xs: simpleType name = "authType" > < xs: restriction base = "xs: string" > < xs: enumeration value = "AKA" / > < xs: enumeration value = "CAVE" / > < xs: enumeration value = "MN-AAA" / > < / xs: restriction > < / xs: simpleType > < ! - the root element - > < xs: element name = "BootstrappingInfo" type = "gba: bootstrappingInfoType" / > < / xs: schema > There are several possible modifications that can be made to the previous XML schema, in order to implement the exemplary embodiments of this invention. The following are several examples that are intended to be read as exemplary and not as a limitation on the practice and / or use of the exemplary embodiments of this invention. Example 1.

XMLSchema 1: < ? xml version = "l, 0" encoding = "UTF-8"? > < xs: schema targetNamespace = "uri: 3gpp2-gba" xmlns: gba = "uri: 3gpp2-gba" xm lns: xs = "htf: // www. w3. org / 2001 / XMLSchema" > < ! ~ definition of the root element containing B-TID, key lifetime, and other parameters-- > < xs: complexType name = "bootstrappingInfoType" > < xs: sequence > < xs: element name = "btid" type = "xs: string" minOccurs = "0'7> <xs: element name =" lifetime "type =" xs: dateTime "inOccurs =" 0"/ > < xs: element name = "esn" type = "xs: base64Binary" minOccurs = "0'7 > < xs: element name- 'ms chall "type =" xs: base64 Binary "minOccurs =" 0'7 > < xs: element name- 'ms result "type =" xs: base64Binary "minOccurs =" 0"/ > < xs: element name =" bs result "type =" xs: base64Binary "minOccurs =" 0'7 > < xs: element name = "auth_list" minOccurs = "0" > < xs: complexType > < xs: sequence > < xs: element ñame- 'auth info "type =" gba: authlnfo "minOccurs =" l "/ > < / xs: sequence > < / xs: complexType > < / xs: element > < xs: element name = "auth" type = "gba: authlnfo" minOccurs = "0" / > < / xs: sequence > < / xs: complexType > <xs: complexType name = "authInfo" > < xs: sequence > < xs: element name = "method" type = "gba: authType" / > < xs: element name = "clientid" type = "xs: string" / > < / xs: sequence < / xs: complexType > <! -definition of type of authentication mechanism and boot ~ < xs: simpleType name = "authType" > < xs: restriction base = " xs: string "> < xs: enumeration valué- 'AKA'7> < xs: enumeration value =" CAVE'7 > < xs: enumeration value = "MN-AAA'7> < / xs: restriction < / xs: simpleType > <! -the root element- > < xs: element name- 'Bootstrappmglnfo" type - 'gba: bootstrappingInfoType "/ > < / xs: schema > The following is a "fragment" of an example of "auth_list" according to the previous XML schema: < auth_list > < auth_info > < method > AKA < / method > < clientid > userl_private @ homel .net < / clientid > < / auth_info > < auth info > < method > CAVE < / method > < clientid > 123456789012345 < / clientid > < / auth_info > < auth_info > < method > MN-AAA < / method > < clientid > foo@example.com < / clientid > < / auth_info > < / auth list > Example 2 XML Schema 2 < ? xml version = "1.0" encoding = "UTF-8'J> &xs: schema targetNamespace =" uri: 3 gpp2-gba "xmlns: gba =" uri: 3gpp2-gba "xmlns: xs- 'http: //www.w3.org/2001/XMLSchema "> < ! - definition of the root element containing B-TID, key lifetime, and other parameters- > < : complexType name = "bootstrappingInfoType" > < xs: sequence > < xs: element name = "btid" type = "xs: string" minOccurs = "0'7> <xs: element name- ifetime" type = "xs: dateTime" minOccurs = "0'7> < xs : element name = "esn" type = "xs: base64Binary" minOccurs = "0" / > < xs: element na e- 's chall "type =" xs: base64Binary "minOccurs =" 0"/ > < xs: element name = "ms_result" type = "xs: base64Binary" minOccurs- '0'7 > < xs: element name = "bs_result" type = "xs: base64Binary" minOccurs = "0'7> <xs: element name =" auth_list "minOccurs =" 0"> <xs: complexType> < xs : sequence > < xs: element name = "auth_info" type = "gba: authlnfo" minOccurs = 'T' / > < / xs: sequence > < / xs: complexType > < / xs: element > <xs: element name- 'auth "type =" gba: authlnfo "minOccurs =" 0"/ > < / xs: sequence > < / xs: complexType > < xs: complexType name = "authlnfo" > < xs: simpleContent > < xs: extension base = "gba: authType" > < xs: attributename = "clientid" type = "xs: string" use = "required'7> < / xs: extension < / xs: simpleContent > < / xs: complexType > <! - definition of type of authentication mechanism and boot ~ < xs: simpIeType name = "authType" > < xs: restriction base = "xs: string" < xs: enumeration value = "AKA" / > < xs: enumeration value = "CAVE" / > < xs: enumeration value = "MN-AAA" / > < / xs: restriction > < / xs: simpleType > <! - the root element - > < xs: element name = "BootstrappingInfo" type = "gba: bootstrappingInfoType" / > < / xs: schema > The following is a "fragment" of an example of "auth_list" according to to this XML schema: < auth_list > < auth_info clientid = "userl_private@homel.net" > AKA < / auth_info > < auth_info clientid = "123456789012345" > CAVE < / auth_info > < auth_info clientid = "foo@example.com" > MN-AAA < / auth_info > < / auth list > Example 3 XML Schema 3: < ? xml version = "1.0" encoding = "UTF-8'J> &xs: schema targetNamespace =" uri: 3gpp2-gba "xmlns: gba =" uri: 3gpp2-gba "xmlns: xs =" http: / / www. w3.org/2001/XMLSchema "> < - definition of the root element containing B-TID, key lifetime, and other parameters-- > < xs: complexType name =" bootstrappingInfoType "> < xs: sequence > < xs: element name = "btid" type = "xs: string" minOccurs = "0'7 > < xs: element name = "lifetime" type = "xs: dateTime" minOccurs = "0'7> < xs: element name =" esn "type =" xs: base64Binary "minOccurs =" 0'7 > < xs: element name = "ms_chaH" type = "xs: base64Binary" minOccurs = "0" / > < xs: element name = "ms_result" type = "xs: base64Binary" minOccurs = "0'7> <xs: element name =" bs_result "type =" xs: base64Binary "minOccurs =" 0'7 > < xs: element name = "auth_list" minOccurs = "0" > < xs: simpleType > < xs: list itemType = "gba: authType'7> < / xs: simpleType > / xs: element > <xs: element name =" auth "type =" gba: authType "minOccurs =" 0"&> < xs: element name =" clientid_list "minOccurs =" 0"> < xs: simpleType > < xs: list itemType =" xs: string "/ > < / xs: simpleType > < / xs: element > < xs: element name = "clientid" type = "xs: string" minOccurs = "0'7 > < / xs: sequence > < / xs: complexType > < ! -definition of type of authentication and startup mechanism ~ > < xs: simpleType name = "authType" > < xs: restriction base = "xs: string" > < xs: enumeration valué- 'AKA' / > < xs: enumeration value = "CAVE'7 > < xs: enumeration value = "MN-AAA7" </ xs: restriction> </ xs: simpleType> <! - the root element -> <xs: element yam- "Bootstrappinglnfo" type = "gba: bootstrappingInfoType'7 > < / xs: schema > The following is a fragment of an example of "auth_list" and "clientid_list": < auth _list > AKA CAVE MN-AAA < / auth_list > < clientidJist > userl_private@homel.net 123456789012345 foo@example.com < / clientid list > Figure 8 shows an example of call flow using the XML schema (1) above. The example is taken from Figure C.3-1 of Annex C of 3GPP2 S.p0109-0, Version 0.6, December 8, 2005, "Generic Bootstrapping Architecture (GBA) Framework", added as Annex C to the aforementioned US Provisional Patent application No.: 60 / 759,487. The example in figure 8 highlights the changes made to the HTTP payload, therefore only the messages (1.), (5.), (7.) and (9.) are of particular relevance to achieve an understanding of the exemplary embodiments of this invention. The rest of the diagram may remain unchanged as shown in Annex C.

Message (1.) Initial request GET (MN (12) to BSF (8)) The purpose of this message is to start the boot procedure between the MN (12) and the BSF (8). The MN (12) sends an HTTP request containing the user's private identity to its local BSF (8). The MN (12) also presents a list of boot mechanisms that supports, along with the corresponding identities, in the message payload.

Table: Initial request example GET (MN (12)) to BSF (8) GET /HTTP/1.1 Host: bsf.home.net User- Agent: Bootstrapping Client Agent Date: Accept: * / * Referer: http://pki-portal.hornel.net:231 1 / pkip / enroll Authorization; Digest username = "userl_private@home.net", realm = "bsf.home.net", nonce- '", uri =' 7", response = "" Content-Type: application / vnd.3gpp2.bsf + xml Content -Length: (...) < ? xml version = "1.0" encoding = "UTF-8"? > < BootstrappingInfo xmlns = "uri: 3gpp2-gba" > < auth_list > < auth_info > < method > AKA < / method > < clientid > userl_private@homel.net <; / clientid > < / auth_info > < auth_info > < method > CAVE < / method > < clientid > 123456789012345 < / clientid > < / auth_info > < auth_info > < method > MN-AAA < / method > < clientid > foo@example.com < / clientid > < / auth_info > < / auth_list > < / BootstrappingInfo > Message (5.). Unauthorized response 401 (BSF (8)) to MN (12)) The BSF (8) transfers the interrogation to the MN (8) in the HTTP 401 unauthorized response (without the CK, IK and XRES). This is to ask the MN (12) to authenticate itself. The interrogation contains RAND and AUTN that are populated in a particular field according to RFC 3310 (IETF RFC 3310"Digest AKA", added as Annex B to the aforementioned United States Provisional Patent Application No. 60 / 759,487). Table: Example of unauthorized response 401 (from BSF (8) to MN (12)) HTTP / 1.1 401 unauthorized Server: start-up server Date: Monday, 24 October 2005 10:13:17 TMG WWW- Authenticate: Digest realm- 'bsf.home.net ", nonce = base64 (RAND + AUTN + server speciflc data), algorithm = AKAvl-MD5, qop = auth-int Content-Type: application / vnd.3gpp2.bsf + xml Content-Length: (...) <? xml version- '1.0"encoding =" UTF-8"? > < BootstrappingInfo xmlns = "uri: 3gpp2-gba" > < auth > < method > AKA < / method > < clientid > userl_private@homel.net < / clientid > < / auth > < / BootstrappingInfo > Message (7.). GET request example (MN (12) to BSF (8)) The MN (12) sends an HTTP GET request again, with the RES that is used to calculate the response, to the BSF (8) Table: GET request example (MN (12) to BSF (8)) GET / HTTP / 1.1 Host: bsf.home.net User-Agent: Bootstrapping Client Agent Date: Mon, 24 Oct 2005 10:13:18 GMT Accept: * / * Referer: http: //pki-portal.home. net: 231 1 / pkip / enroll Authorization: Digest username = "userl_private@home.net", realm- 'bsf. home.net ", nonce = base64 (RAND + AUTN + server specific data), uri- 7", qop = auth-int, nc = 00000001, cnonce = "6629fae49393a05397450978507c4efl", response = "6629fae49393a05397450978507c4efl", opaque = "5ccc069c403ebaf9f0171 e9517O0e41", algorithm = AKAvl-MD5 Content-Type: application / vnd.3gpp2.bsf + xml Content-Length: (...) < ? xml version- '1.0"encoding =" UTF-8"?> <BootstrappingInfo xmlns =" uri: 3gpp2-gba "> <auth_list> <auth_info> <method> AKA </ lt; method > < clientid > userl_private @ homel.netuserl_private @ homel.net < / clientid > < / auth_info > < auth_info > < method > CAVE < / method > < clientid > 123456789012345 < / clientid > < / auth_info > < auth_info > < method > MN-AAA < / method > < clientid > foo@example.com < / clientid > < / auth_info > < / auth_list > < / BootstrappingInfo > Message (9.). Response example 200 OK (BSF (8)) to MN (12)) The BSF (8) sends the 200 OK response to the MN (12) to indicate the success of the authentication.

Table: Response 200 OK (BSF (8) to MN (12)) HTTP / 1.1 200 OK Server: Bootstrapping Server Authentication-Info: QOP = auth-int, rspauth = "6629fae49394a05397450978507c4efl" cnonce = "6629fae49393a05397450978507c4efl" nc = 00000001 Date: Expires: * date / time * Content-Type: application / vnd .3gpp.bsf + xml Content-Length: (...) < ? xml version- '1.0"encoding =" UTF-8"?> <BootstrappingInfo xmlns =" uri: 3gpp-gba "> <auth> <method> AKA </ method> </ font> clientid > userl_private@homel.net < / clientid > < / auth > < BTID > bmFtYXJ0bHUgc2F5 cyBoaQ = @ bsf operator.com. < / BTID > < lifetime > 2005-l l- 21T13: 20: 00-05: 00 < / lifetime > < / BootstrappingInfo > Based on the foregoing, it should be apparent that the exemplary embodiments of this invention provide a method, apparatus and product or computer program products for sending to a wireless network (WN) a first message that is comprised of a list of authentication mechanisms, supported by a node and, in association with each authentication mechanism, a corresponding identification, and determining in the WN, an authentication mechanism to be used for the start, based at least on the list received from the node, and include in a first response message the information of the node belonging to the determined authentication mechanism, together with the corresponding identification. It can be appreciated that one aspect of the exemplary embodiments of this invention is that when an "authentication mechanism" is sent in the HTTP payload, there is also included the corresponding identification, also referred to herein without a loss of generality as a identity. From this point of view, for the first and second requests of the MN (12), the list of the supported mechanisms in the HTTP payload is included and, therefore, the corresponding identifications are also included. Also, for the first and second answers sent by the WN, the authentication mechanism selected in the payload is included, and the corresponding identification is also included. In addition, the second request of the M? (12) also contains the list of the corresponding identifications, and this information is protected in its entirety. Similarly, the selected mechanism and the corresponding identification, if present in the second response, are preferably also protected in their entirety. In general, the various modalities can 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, which may be executed by a controller, microprocessor or other computing device, although the invention is not limited thereto. Since various aspects of the invention can be illustrated and described as block diagrams, flow charts or using some other pictorial representation, it is well understood that these blocks, apparatuses, systems, techniques or methods described herein can be implemented, in non-limiting examples, hardware, software, firmware, circuits or special-purpose logic, hardware or general-purpose controller or other computing devices, or some combinations thereof. The embodiments of the inventions can be practiced in several components as integrated circuit modules. The design of integrated circuits that is generally a very automated process. Powerful and powerful software tools are available to convert a logic level design into a semiconductor circuit design, ready to be recorded and formed into a semiconductor substrate. Programs, such as those provided by Synopsis, Inc., of Mountain View, California and Cadenee Design, of San Jose, California automatically route conductors and place components on a semiconductor chip, using well-established design rules as well as libraries of pre-packaged design modules . Once the design for a semiconductor circuit has been completed, the resulting design, in a standardized electronic format (for example, Opus, GDSII, or similar) can be transmitted to a semiconductor manufacturing facility or "fab" for manufacturing . Various modifications and adaptations may be apparent to those skilled in the relevant arts, in view of the foregoing description, when read in conjunction with the accompanying drawings. As non-restrictive examples, other types of message format and the like may be used to communicate information between the device (12) and the wireless network element (s). (8), and / or other types of authentication mechanisms may be employed instead of, or in addition to, those specifically mentioned above. However, any and all modifications of the teachings of this invention will still fall within the scope of the non-restrictive embodiments of this invention. In addition, some of the characteristics of the various non-restrictive embodiments of this invention may be used to advantage, without the corresponding use of other features. As such, the foregoing description should be considered only as illustrative of the exemplary principles, teachings, and modalities of this invention, and not as a limitation thereto.

Claims (61)

1. CLAIMS 1. A method, comprising: receiving in a wireless network (WN) a first message that is comprised of a list of authentication mechanisms, supported by a node and, in association with each authentication mechanism, a corresponding identity; determining in the WN, an authentication mechanism to be used for the boot, based on at least the received list of the node; and include information in a second message that is sent to the node, the information comprises the authentication mechanism determined in conjunction with a corresponding identity. The method according to claim 1, wherein, if the determined authentication mechanism is usable with more than one identity, it further comprises selecting one of the identities to be associated with the determined authentication mechanism. The method according to claim 1, wherein the first message comprises an HTTP GET request, and wherein the second message comprises a first response message including an XML document that explicitly identifies the determined authentication mechanism and a corresponding identity. 4. The method according to claim 3, further comprising receiving a third message in the WN, which is at least partially protected in its entirety, based on the given authentication mechanism, the third message comprises at least the list of authentication mechanisms that supports the node, and the corresponding identities, in a fully protected manner; if the authentication is successful, and if the received list of the third message corresponds to the received list of the first message, reply to the node with a second response message that is at least partially protected in its entirety, wherein the second response message can understand an indication of the selected authentication mechanism, and corresponding identities, in an integrity protected manner. The method according to claim 4, further comprising receiving the third message and verifying that the authentication mechanism used by the node corresponds to the authentication mechanism determined by the WN. The method according to claim 1, wherein at least the determining step is executed by a Startup Server Function (BSF). The method according to claim 1, wherein the first message is an HTTP GET, wherein the list is included in an HTTP payload. The method according to claim 1, wherein the second message is an HTTP unauthorized response 401. The method according to claim 4, wherein the third message is an HTTP GET comprising a response calculated according to the mechanism of selected authentication. The method according to claim 4, wherein the second response message is an HTTP message 200 OK 11. A computer program product exemplified in a computer readable medium, whose execution by a data processor of a node comprises the operation of: sending a first message to a wireless network (WN) that is comprised of a list of mechanisms of authentication, supported by the node and, in association with each authentication mechanism, a corresponding identity; and receiving a first response message from the WN, the first response message comprises information pertaining to an authentication mechanism, selected by the WN between the list provided by the node in the first message, in conjunction with a corresponding identity. 12. The computer program product according to claim 11, further comprising an operation of sending a second message to the WN, which is at least partially protected in its entirety, the second message comprises the list of authentication mechanisms, and the corresponding identities , which the node supports in a fully protected manner. 13. The computer program product according to claim 11, further comprising an operation of receiving a second response message that is at least partially fully protected, wherein the second response message comprises an indication of the selected authentication mechanism, together with the corresponding identity, in a protected form in your integrity The computer program product according to claim 13, wherein at least the first and second response messages are received from a start service function (BSF). The computer program product of claim 11, wherein the first message is sent as an HTTP GET, where the list is included in an HTTP payload, and wherein the first response message is received as a response HTTP not authorized 401. 16. The computer program product according to claim 12, wherein the second message is sent as an HTTP GET comprising a response calculated in accordance with the selected authentication mechanism. 17. The computer program product according to claim 13, wherein the second response message is received as an HTTP 200 OK message. 18. The computer program product according to claim 11, further comprising verifying that the authentication mechanism used by the node corresponds to the authentication mechanism selected by the WN. 19. A device, comprising a data processor, coupled to a transmitter and a receiver and operable to send to a network through the transmitter, a first message that is comprised of a list of authentication mechanisms, supported by the device and, in association with each authentication mechanism, a corresponding identity, and receiving from the network through the receiver a first response message, the first response message comprises information pertaining to an authentication mechanism selected by the network between the list, in conjunction with a corresponding identity. 20. The device according to claim 19, the data processor is further operable to protect the integrity of the list of authentication mechanisms supported by the device and to send through the transmitter a second message to the network, which is at least partially protected in its entirety, the second message comprises at least the list of authentication mechanisms, and the corresponding identities, that the device supports, in a fully protected manner. The device according to claim 19, wherein the data processor further receives a second response message from the network, which is at least partially protected in its entirety, wherein the second response message comprises an indication of the authentication mechanism selected, and the corresponding identity, in a fully protected form. 22. The device according to claim 21, wherein at least the first and second response messages are received from a Start Service Function (BSF) comprising a part of the network. The device according to claim 19, wherein the first message is sent as an HTTP GET, wherein the list is included in an HTTP payload, and wherein the first response message is received as an unauthorized HTTP 401 response 24. The device according to claim 20, wherein the second message is sent as an HTTP GET comprising a response calculated in accordance with the selected authentication mechanism. 25. The device according to claim 21, wherein the second response message is received as an HTTP 200 OK message. 26. The device according to claim 19, wherein the data processor is further operable to verify that an authentication mechanism used by the device corresponds to the authentication mechanism selected by the network. 27. A computer program product, exemplified in a computer-readable medium, whose execution by a data processor of a wireless network element (WNE) comprises the operations of: receiving a first message from a node, which is comprised of a list of authentication mechanisms, supported by the node and, in association with each authentication mechanism, a corresponding identity; determine an authentication mechanism to be used for the startup, based at least on the list received from the node; sending a first response message to the node, the first response message comprises information belonging to the given authentication mechanism and a corresponding identity; and receiving a second message from the node that is at least partially protected in its integrity, the second message comprises at least the list of authentication mechanisms that the node supports, and the corresponding identities, in a fully protected form. 28. The computer program product according to claim 27, wherein, if the authentication is successful, and if the list received in the second message corresponds to the list received in the first message, it also comprises an operation of sending a second message. response to the node, which is at least partially protected in its entirety, wherein the second response message comprises an indication of the selected authentication mechanism, and the corresponding identity, in a form protected in its integrity. 29. The computer program product according to claim 27, further comprising recovering a profile based on identity, and wherein the determining operation considers the profile. 30. The computer program product of claim 27, wherein a wireless network is comprised of a Startup Service Function (BSF) 31. The computer program product of claim 27, wherein the first message is received. as an HTTP GET comprising an identity of a NODE user, where the list is included in an HTTP payload. 32. The computer program product according to claim 27, wherein the first response message is sent as an unauthorized HTTP response 401. 33. The computer program product according to claim 27, wherein the second message is received. as an HTTP GET that comprises a response calculated according to the selected authentication mechanism. 34. The computer program product according to claim 28, wherein the second response message is sent as an HTTP 200 OK message 35. A network device, comprising a data processor coupled to a transmitter and a receiver and which it is operable to receive from a node, through the receiver, a first message that is comprised of a list of authentication mechanisms supported by the node and, in association with each authentication mechanism, a corresponding identity, the data processor is operable in addition to determining an authentication mechanism to be used for startup, based at least in part on the list received from the node, and for sending a first response message to the node through the transmitter, the first response message comprises information that belongs to the determined authentication mechanism and a corresponding identity, the data processor is also operable to receive from the node, an In the second message, which is at least partially protected in its entirety, the second message comprises the list of authentication mechanisms that the node supports, and corresponding identities, in a fully protected form. 36. The network device according to claim 35, the data processor is operable in addition, if the authentication is successful, and if the list received in the second message corresponds to the list received in the first message, to send a second message of response to the node, which is at least partially protected in its entirety, wherein the second response message comprises an indication of the selected authentication mechanism, and the corresponding identity, in a form protected in its integrity. 37. The network device according to claim 35, wherein the data processor is further operable to retrieve a profile based on the identity, for consideration when determining the authentication mechanism to be used for the boot. 38. The network device according to claim 35, comprising a start service function (BSF). 39. The network device according to claim 35, wherein the first message is received as an HTTP GET comprising an identity of a user of the node, wherein the list is included in an HTTP payload. 40. The network device according to claim 35, wherein the first response message is sent as an HTTP unauthorized response 401. 41. The network device according to claim 35, wherein the second message is received as an HTTP GET. which comprises a response calculated in accordance with the selected authentication mechanism. 42. The network device according to claim 36, wherein the second response message is sent as an HTTP 200 OK message. 43. A device, comprising means for sending to a network, a first message that is comprised of a list of authentication mechanisms, supported by the device and, in association with each authentication mechanism, a corresponding identity; and means for receiving a first response message from the network, the first response message comprises information describing an authentication mechanism selected by the network between the list and a corresponding identity, which also includes means to fully protect the list of mechanisms of authentication, supported by the device to send a second message to the network, which is at least partially protected in its integrity, the second message comprises, in a fully protected form, the list of authentication mechanisms that the device supports and, in association with each authentication mechanism, a corresponding identity. 44. The device according to claim 43, wherein the receiving means is further operable to receive a second response message from the network, which is at least partially protected in its entirety, wherein the second response message comprises an indication of the mechanism of selected authentication, and the corresponding identity, in a fully protected form. 45. The device according to claim 43, further comprising means for verifying that the authentication mechanism used by the device corresponds to the authentication mechanism selected by the network. 46. A network device, comprising means for receiving from a node, a first message that is comprised of a list of authentication mechanisms, supported by the node and, in association with each authentication mechanism, a corresponding identity, means for selecting an authentication mechanism to be used for startup, based at least in part on the received list of the node, and means for sending a first response message to the node, the first response message comprises information pertaining to the mechanism of selected authentication and a corresponding identity, and receiving means operable in addition to receive from the node, a second message that is at least partially protected in its integrity, the second message comprises the list of authentication mechanisms that the node supports and, in association with each authentication mechanism, the corresponding identity. 47. The network device. according to claim 46, wherein the means for sending is sensitive to successful authentication, and to the list received in the second message corresponding to the list received in the first message, to send to the node, a second response message that is at less partially protected in its entirety, wherein the second response message comprises, in a fully protected form, an indication of the selected authentication mechanism and the corresponding identity. 48. The network device according to claim 46, further comprising means for recovering a profile based on the identity to be used by the selection means when selecting the authentication mechanism to be used for the boot. 49. The network device according to claim 46, which comprises a Start-up Service (BSF) function. 50. A system, comprising a device coupled to a network device, the device comprises a data processor coupled to a transmitter and a receiver and which is operable to send to the network device through the transmitter, a first message that is comprised of a list of authentication mechanisms, supported by the device and, in association with each authentication mechanism, a corresponding identity, the network device comprises a data processor coupled to a transmitter and a receiver and is operable to select a mechanism of authentication between the list, the device receives a first response message from the network device through the receiver, the first response message comprises information pertaining to the authentication mechanism, selected by the network device between the list and a corresponding identity , the data processor of the device is operable to at least partially protect the integrity of at least the list of authentication mechanisms supported by the device, and the corresponding identities, and to send a second message to the network device through the transmitter, the second message comprises the list of corresponding authentication mechanisms and identities. 51. The system according to claim 50, wherein the data processor further receives a second response message from the network device, which is at least partially protected in its integrity, wherein the second response message comprises an indication of the mechanism of authentication selected by the network device in a fully protected form, and the corresponding identity. 52. The system according to claim 50, wherein the network device is comprised of a Service Start Function (BSF). 53. The system according to claim 50, wherein the device is coupled to the network device through a wireless link. 54. A method, comprising: sending to a network, a first message that is comprised of a list of authentication mechanisms, supported by a device and, in association with each authentication mechanism, a corresponding identity; and receiving a first response message from the network, the first response message comprises information belonging to an authentication mechanism, selected by the network of the list, together with a corresponding identity. 55. The method according to claim 54, further comprising: protecting in its integrity at least the list of authentication mechanisms, supported by the device and the corresponding identities; and sending a second message to the network, the second message comprises at least the list of authentication mechanisms and the corresponding identities. 56. The method according to claim 54, further comprising: receiving a second response message from the network, which is at least partially protected in its entirety, wherein the second response message comprises an indication of the selected authentication mechanism, and the corresponding identity. 57. The method according to claim 56, wherein at least the first and second response message are received from a Start Service Function (BSF) comprising a part of the network. 58. The method according to claim 54, wherein the first message is sent as an HTTP GET, wherein the list is included in an HTTP payload, and wherein the first response message is received as an unauthorized HTTP response 401. 59. The method according to claim 55, wherein the second message is sent as an HTTP GET comprising a response calculated in accordance with the selected authentication mechanism. 60. The method according to claim 56, wherein the second response message is received as an HTTP 200 OK message. 61. The method according to claim 54, further comprising verifying that an authentication mechanism used by the device corresponds to the authentication mechanism selected by the network.