BRPI0611696B1 - METHOD, DEVICE AND SYSTEM FOR PROVIDING IDENTITIES OF US MOBILE ALONG WITH AUTHENTICATION PREFERENCES IN A GENERIC INITIALIZATION ARCHITECTURE - Google Patents

Abstract

computer program method, apparatus and product for providing mobile node identities in conjunction with authentication preferences in the generic initial authentication architecture. In one example and a non-limiting aspect thereof, a method is provided which includes in the wireless network (wn) the 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; determine in wn an authentication mechanism to be used for initial authentication, based at least on the list received from the node; and including the information in the second message that is sent to the node, the information comprising an authentication mechanism determined in conjunction with the corresponding identity. The method also includes protecting at least the list of authentication mechanisms supported by the node and the corresponding identities and sending the second message to the network, the second message including at least one list of the authentication mechanisms and the corresponding identities. The method also includes receiving the second reply message from the network that is at least partially integrity protected, where the second reply message includes an indication of the selected authentication mechanism and the corresponding identity.

Description

Technique Field

The exemplary and non-limiting modalities of this invention refer, in general, to communication systems, methods and devices and, more specifically, refer to authentication techniques and related techniques used in communication systems.

Background

1Ο

The following definitions are defined together:

3GPP AAA Third Generation Partnership Project Authentication, Authorization and Accounting

GAA Generic Authentication Architecture

GBA Generic Initial Authentication Architecture

BSF Initial Authentication Server Role

AKA Authentication and Key Convention

IM Multimedia IP

ISIM IM Services Identity Module

NAI Network Access Identifier

MN Mobile Node

EU User Equipment

EV-DO Evolution Data Only

The 3GPP GBA (see 3GPP TS 33.220 “GAA: GBA”, attached as

Presentation A to US Provisional Patent Application referred to above No. 60 / 759,487) aims to specify a mechanism for initial authentication and key convention for application security from the 3GPP AKA mechanism. GBA is also being introduced in 3GPP2, where AKA is not considered, initial authentication based on legacy key materials, including the SMEKEY key (for CDMAIx systems) and MN-AAA (for systems

Petition 870190003069, of 10/01/2019, p. 10/25

2/42

CDMAIx EV-DO), is also being standardized. As a result, when operating on a 3GPP2 system an MN may support, or may be required to support, more than an authentication and initial authentication mechanism. Therefore, a technique is needed for the MN and the network to agree on the defined algorithm to be used in the initial authentication. The same is required for future terminals that support both 3GPP and 3GPP2 networks, in such a way that a 3GPP terminal can perform visitation on a 3GPP2 network (and vice versa) and still use GBA. In addition, it is possible for operators to employ both networks, 3GPP and 3GPP2, in the same geographical location. In such cases, the terminals also have to negotiate with the network the initial authentication mechanism to be used.

3GPP supports only one authentication mechanism and initial authentication, that is, the AKA Build mechanism and the AKA protocol with the algorithms defined by 3GPP. The use of AKA with 15 build authentication is specified in Build-AKA (see IETF RFC 3310 “Build AKA”, attached as Presentation B to US Provisional Patent Application referred to above No. 60 / 759,487).

In 3GPP2 there are different mechanisms for initial authentication supported by the network side, in both terminals, legacy and non-legacy, which 20 need to be supported.

MN can support multiple key generation and authentication mechanisms (for example, AKA, MN-AAA, CAVE) and can have multiple pre-provisioned secrets. In 3GPP2 there is a defined mechanism selection procedure, which determines that the MN inserts in the payload of the first message that it sends to BSF the list of supported authentication mechanisms, allowing BSF to select the authentication mechanism that it to prefer. When BSF selects the key generation and authentication mechanism, it contacts the correct database and fetches the authentication data. For example, if MN supports MN-AAA, in addition to 30 other mechanisms, and BSF selects MN-AAA, then BSF will contact H-AAA for

3/42 seek the challenge.

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 1x terminal, then it has an IMSI-like identity.

This creates a problem, when the MN first contacts BSF by sending a Get HTTP request (according to 3GPP2 S.P0109-0, Version 0.6, December 0, 2005, “Generic Bootstrapping Architecture (GBA) Framework ”, attached as Presentation C to Application for 10 US Provisional Patent No. 60 / 759,487, cited above), he has to enter his identity in the application. Since most identities can only be used with specific key generation and authentication mechanisms, (for example, private identity can only be used with AKA, IMSI can only be used by CAVE, EV-DO NAI can be used by MN -AAA), by selecting and including one of their identities in the GET request, the MN also pre-selects the authentication mechanism implicitly. With a specific identity already inserted, BSF cannot make any other choice for the mechanism than the one with which the identity can be used. Alternatively, a mapping of the different identities of an MN may need to be accessible to the 20 BSF, but this approach may not be desirable for a number of reasons.

Summary of the Invention

In accordance with its exemplary and non-limiting modalities, this invention provides a method that includes receiving on 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 WN an authentication mechanism to be used for initial authentication, based on at least the list received from the node; and including information in a second message that is sent to the node, the information comprising the authentication mechanism determined in conjunction with a corresponding identity.

4/42

In accordance with its exemplary and non-limiting modalities, this invention also provides a computer program product incorporated in a computer-readable medium whose execution by a node's data processor comprises operations to send 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 reply message from the WN, the first reply message comprising information belonging to an authentication mechanism selected by the WN from the list provided by the node in the first message together with a corresponding identity.

In accordance with its exemplary and non-limiting modalities, this invention also provides a device that includes a data processor coupled to a transmitter and a receiver and operable to send a first message to a network via the transmitter which 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 via the receiver a first response message, the first response message comprising information belonging to a mechanism selected by the network from the list together with a corresponding identity.

Additionally, according to its exemplary and non-limiting modalities, this invention provides a computer program product incorporated in a computer-readable medium whose execution by a wireless network element (WNE) data processor comprises operations to receive a first message from a node that 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 initial authentication, based on at least the list received from the node; submit

5/42 a first reply message to the node, the first reply message comprising information belonging to the determined authentication mechanism and a corresponding identity; and receiving a second message from the node that is, at least partially, of protected integrity, the second message comprising at least the list of authentication mechanisms that the node supports, and corresponding identities, in a form of protected integrity.

Additionally, according to its exemplary and non-limiting modalities, this invention provides a network device that includes a data processor coupled to a transmitter and a receiver and 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 additionally operable to determine an authentication mechanism to be used for initial authentication, based at least in part on the list received from the node, and to send a first response message to the node via the transmitter, the first reply message comprising information belonging to the determined authentication mechanism and a corresponding Identity. The data processor is additionally operable to receive from the node a second message that is, at least partially, of protected integrity, the second message comprising the list of authentication mechanisms that the node supports, and corresponding identities, in a form of protected integrity.

Additionally, in accordance with its exemplary and non-limiting modalities, this invention provides a device that includes a means to send a first message to a network that is comprised of a list of authentication mechanisms supported by the device and, in association with each authentication mechanism, a corresponding identity; and a means for receiving from the network a first response message, the first response message comprising descriptive information from a mechanism

6/42 authentication selected by the network from the list and a corresponding identity. The device further includes means to protect the integrity of the list of authentication mechanisms supported by the device and to send a second message to the network which is, at least partially, of protected integrity, the second message comprising, in a form of protected integrity , the list of authentication mechanisms that the device supports and, in association with each authentication mechanism, a corresponding identity.

Furthermore, according to its exemplary and non-limiting modalities, this invention provides a network device that includes a means to receive, 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 initial authentication, based at least in part on the list received from the node, and means for sending a first reply message to the node , the first reply message comprising information belonging to the selected authentication mechanism and a corresponding identity. The receiving means is additionally operable to receive from the node a second message which is at least partially of protected identity, the second message comprising the list of authentication mechanisms that the node supports and, in association with each authentication mechanism, the identity corresponding.

Still further according to its exemplary and non-limiting modalities, this invention provides a system having a device coupled to a network device, where the device comprises a data processor coupled to a transmitter and receiver and being operable to send to the network device, via the transmitter, a first message which is comprised of a list of authentication mechanisms supported by the device and, in association with each authentication mechanism 30, a corresponding identity. The network device

7/42 comprises a data processor coupled to a transmitter and receiver and is operable to select an authentication mechanism from the list. The device receives from the network device via the receiver a first response message, where the first response message comprises information belonging to the authentication mechanism selected by the network device from the list and a corresponding identity. The device's data processor is operable, at least partially, to 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 through the transmitter to the network device, the second message comprising the list of authentication mechanisms and corresponding identities.

Still further in accordance with its exemplary and non-limiting modalities, this invention provides a method that includes sending a first message to a network 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 from the network a first reply message, the first reply message comprising information belonging to an authentication mechanism selected by the network from the list in conjunction with a corresponding identity.

Brief Description of the Drawings In the Drawing Figures, attached:

Figure 1 is a block diagram that illustrates the architecture of the 3GPP2 GBA reference network;

Figure 2 illustrates an initial authentication procedure with a selection of authentication mechanism;

Figure 3 is an example of an error scenario with an MITM attack;

Figure 4 is another example of an error scenario with an attack

8/42

ΜΙΤΜ.

Figure 5 shows an example of mechanism selection with initial authentication that uses multiple series of message exchanges;

Figure 6 shows a non-limiting negotiation example using HTTP build authentication;

Figure 7 shows a non-limiting negotiation example using simple HTTP transport; and

Figure 8 illustrates an initial authentication procedure with a selection of authentication mechanism according to the exemplary modalities of this invention, and is adapted from Figure C.3-1: Initial authentication signaling based on AKA found in Annex C of 3GPP2 S.P0109-0, Version 0.6, of December 8, 2005, “Generic Bootstrapping Architecture (GBA) Framework”, attached as Presentation C to US Provisional Patent Application No. 60 / 759,487 mentioned above.

Detailed Description

The non-limiting and exemplary modalities of this invention generally refer to authentication, and more specifically refer to the 3GPP Generic Initial Authentication Architecture (GBA), which was defined in 3GPP and also introduced in 3GPP2. Figure 1 shows the initial, general and non-limiting authentication reference architecture. Figure 1 shows a Native Subscriber System (HSS) 2, a Native Location Register (HLR) 4, an Access, Authentication and Accounting (AAA) 6 server, BSF 8, a Network Application Function (NAF ) 10 and the User Equipment / Mobile Node (MN) 12, as well as the interfaces between these components. It is assumed that suitable transmitters (Tx) and receivers (Rx) are used to transport information and messages between MN 12, BSF 8 and other network components. The non-limiting and exemplary modalities of the invention mainly deal with procedures related to the Ub interface between MN 12 and BSF 8 where the initial authentication is performed. Note that a mobile terminal is referred to as User Equipment (UE) in 3GPP, and as a Mobile Node (MN)

9/42 on 3GPP2. In this patent application these terms can be used interchangeably without loss of generality, and can also be referred to even more generally as a device or a node.

The non-limiting and exemplary modalities of this invention provide a mechanism for negotiating the supported algorithms / mechanisms for initial authentication between the MN 12 and the network.

The non-limiting and exemplary modalities of this invention provide a solution for MN 12 and the network element (BSF 8) to agree on an authentication and initial authentication mechanism for use in GBA (3GPP2 environment), and also define as the mechanism can be integrated into existing 3GPP procedures. It is assumed that the MN 12 has a list 11 of the authentication and initial authentication mechanisms it supports, such as by storing the list 11 in a memory (MEM) 12A coupled to a data processor (DP) 12B. Memory 12A also supposedly includes program code for operating DP 12B in accordance with the various embodiments of this invention. It is also assumed that BSF 8 also includes a memory (MEM) 8A coupled to a data processor (DP) 8B. It is assumed that memory 8A includes program code for operation for DP 8B in accordance with various embodiments of this invention.

In general, the various modalities of the MN 12 may include, but are not limited to cell phones, personal digital assistants (PDAs) having wireless communication capabilities, handheld computers having wireless communication capabilities, image capture devices such as cameras digital devices having wireless communication capabilities, gaming devices having wireless communication capabilities and playback devices having wireless communication capabilities, Internet devices allowing wireless Internet access and browsing, as well as portable units or terminals that incorporate combinations of such functions. In other embodiments, the node may not include a transmitter and a receiver that are capable of wirelessly communicating with a network via a wireless link, since connections

10/42 wires can be used instead via cable or wiring, including one or both interconnects, electrical and optical.

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, magnetic memory devices and systems, memory devices and systems optical memory, fixed memory and removable memory. Data processors 8B and 12B can be of any type suitable for the local technical environment, and can include one or more general purpose computers, special purpose computers, microprocessors, digital signal processors (DSPs) and processors based on an architecture multi-core processor, as non-limiting examples.

In general, the exemplary examples of such an invention can be implemented by computer software executable by a MN 12 wireless processor, such as the DP 12B, or by the hardware circuit, or by a combination of software and hardware circuits. The modalities of this invention can also be implemented by computer software executable by a BSF 8 data processor, such as DP 8B, or by hardware circuits, or by a combination of software and hardware circuits.

Reference is first made to US Patent Application SN 11 / 232,494, filed on 9/21/2005, entitled: “Method, Apparatus and Computer Program Product Providing Bootstrapping Mechanism Selection in Generic Bootstrapping Architecture (GBA)”, by Gabor Bajko and Tat Keung Chan, whose content is incorporated here, in full, as a reference as if completely exposed here again. US Patent Application SN 11 / 232,494 has been attached to Presentation D for US Provisional Patent Application cited above No.: 60 / 759,487, and claims priority in accordance with 35 USC §119 (e) from Provisional Patent Application US No. 60 / 690,528, filed on June 13, 2005, and from US Provisional Patent Application No. 60 / 692,855, filed on June 21, 2005 (cited several times below), whose disclosures

11/42 are incorporated here, in full, by reference.

Before further discussing the exemplary embodiments of that invention, and to obtain a more complete understanding of it, a discussion of the matter disclosed in US Patent Application is now provided.

11 / 232,494. In this regard, reference is now made below to Figures 2-7.

*

In an exemplary embodiment, the initial authentication procedure, in accordance with the non-limiting modalities disclosed in US Patent Application No. 11 / 232,494, comprises the following steps, which are described below in further detail with respect to Figure 2.

ίο A. In an initial authentication request, MN 12 presents the list 11 of authentication mechanisms that it supports to BSF 8 in a request. The MN 12 also includes the user's identity.

B. BSF 8 decides on the authentication mechanism to be used for initial authentication, based on list 11 received from MN 12 and other information (including as non-limiting examples the mechanisms that BSF 8 itself supports, and the user profile retrieved based on user identity). BSF 8 then proceeds with the selected authentication mechanism, which typically includes responding with an authentication challenge. BSF 8 also includes in the reply an indication of the chosen authentication mechanism 20.

C. MN 12 sends a new HTTP request to BSF 8 containing the response to the challenge generated based on the selected authentication mechanism. The message also includes the original list 11 of authentication mechanisms that the MN 12 supports, only this time it is integrity protected.

D. BSF 8 verifies that the response to the challenge is correct, and considers the MN authentication successful if the response corresponds to the expected response. If authentication is successful, and the list 11 received in step C is identical to that in step A, BSF 8 responds to the MN with a successful HTTP response. The reply message can also include an indication of the

12/42 selected authentication mechanism, which is integrity protected.

E. MN 12 receives the successful response and can verify that the chosen authentication mechanism is as indicated.

Since the first two messages (step A and B) typically cannot be protected because the two parties have not authenticated each other, an MITM attacker can intercept message A and remove a powerful authentication mechanism from the list, leaving only one mechanism (s) weak authentication list to choose from by BSF 8. This results in a “low-effort” attack, where the initial authentication procedure is forced to be based on a weaker authentication mechanism when stronger authentication mechanisms are supported by both parties (for example, BSF 8 and MN 12). The procedure in accordance with the non-limiting modalities disclosed in US Patent Application SN 11 / 232,494, eliminates these types of “little attempted” attacks because the MN 12 repeats the list in a form of integrity protected in step C, this mode allowing BSF 8 to detect a MITM attack if the lists in steps A and C do not match.

Describing the various aspects of the non-limiting modalities disclosed in US Patent Application No. 11 / 232,494, now in more detail, in 3GPP the Ub interface (between MN 12 and BSF 8) is based on HTTP build authentication. The same mechanism was adopted in 3GPP2. For example, for AKA from 3GPP and 3GPP2, AKA Build is used, whereas for initial authentication for CDMA 1x and CDMA EV-DO systems, HTTP Build authentication protected by Diffie-Hellman password (based on SMEKEY Key and MN 12- AAA, respectively) is used (see contribution 3GPP2: “Bootstrapping procedures for CDMA 1x and CDMA 1x EV-DO Systems”, 3GPP2 TSG-S WG4, Portland, May 2005). In other words, possible authentication and initial authentication mechanisms can include at least the following:

AKA of 2GPP (the algorithm is not specified, it is operator specific);

13/42

AKA of 3GPP2 (SHA-1 is the determined algorithm);

Initial SMEKEY-based authentication; and

Initial authentication based on the MN-AAA Key.

In the future, a greater number of authentication mechanisms may be available and can be easily included in the MN-BSF selection procedure.

To eliminate the need to standardize a compilation variant for each of each authentication mechanism in IETF, it is preferred that the list of supported authentication mechanisms and the selected authentication mechanism 10 be embedded in the payload of HTTP messages, more specifically the that carry that information in the build authentication headers.

Figure 2 shows the message sequence for an initial GBA authentication procedure with authentication mechanism selection, and is explained in detail as follows:

1. MN 12 sends an initial authentication request in the form of GET HTTP to BSF 8. MN 12 includes the user's identity in the Authorization header. In addition, the list of supported authentication mechanisms (for example, [A, B, C]) is included in the HTTP payload.

2. Upon receiving the initial authentication request, BSF 8 extracts the list of supported authentication mechanisms from the payload. Based on the extracted authentication mechanisms, the list of authentication mechanisms that BSF 8 itself supports, the user profile (retrieved based on the user's identity), and possibly other information, BSF 8 decides 25 on the authentication mechanism to be used for initial authentication.

3. BSF 8 sends an unauthorized HTTP 401 response to MN 12. The response comprises the appropriate information based on the selected authentication mechanism. For example, if 3GPP AKA is selected, the Authenticate WWW header contains AKA parameters according to IETF RFC 30 3310 “Compile AKA”. In addition, the payload will include an indication of the

14/42 selected authentication mechanism (in this case, A). In addition, the quality of protection (qop) for Compile authentication is set to “auth-int”, indicating that protection of payload integrity is required.

4. MN 12 retrieves the selection from BSF 8 from the payload and continues the authentication process according to the selection. This will typically comprise computing an answer based on the challenge received and some shared secrets.

5. MN 12 sends a new initial authentication request in the form of GET HTTP to BSF 8, with the response computed in accordance with the selected authentication mechanism. In addition, the payload comprises the original list of authentication mechanisms that the MN 12 supports. Since qop was set to “auth-int”, this original list is included in the computation of the Compile response and, therefore, is integrity protected.

6. BSF 8 checks first whether the list presented in the payload matches the one received in step 2. Only if a match is found does BSF 8 continue with authentication based on the selected mechanism. This typically includes verifying the build response received and computing a server response for the purpose of server-side authentication.

7. BSF 8 responds with an HTTP 200 OK message, indicating a successful initial authentication and authentication operation. The message also includes the compilation response computed by BSF. The message may also include an indication of the authentication mechanism selected for reference by the MN. Similarly, this indication is of identity protected by setting qop to “auth-int”.

8. MN 12 can verify that the selected authentication mechanism is in fact identical to the one indicated in step 3. It should be noted that the mechanism works perfectly even without including the selected authentication mechanism in the HTTP 200 OK response.

9. Both BSF 8 and MN 12 derive the authentication key

15/42 initial based on the selected authentication and initial authentication mechanism.

Figure 3 illustrates the scenario when an MITM 14 attacker attempts an attack of few attempts, as described above. The following explains each step in Figure 3.

1. Identical to step 1 as in Figure 2. The original list 11 contains, for example, three supported mechanisms, that is, A, B and C.

1a. Message 1 is intercepted by the attacker MITM 14. The original list 11 is replaced with a list containing only one C mechanism, which may be the weakest of the three supported.

2. BSF 8 extracts the list, which contains only the C engine and therefore selects C and proceeds.

3. Identical to step 3 in Figure 2, with mechanism C indicated.

4. MN 12 believes that BSF 8 chose mechanism C and therefore proceeds accordingly.

5. Identical to step 6 in Figure 2. Although MN 12 continues with mechanism C, it includes the original list of [A, B, C] in the payload, which is of integrity protected and, therefore, the attacker MITM 14 you cannot make a change to the message.

6. BSF 8 while checking the received list finds that it is not identical to the one received in step 2. It concludes that a low-attempt attack has been launched and therefore aborts the initial authentication procedure with a prohibited HTTP 403 message.

Alternatively, BSF 8 can detect this attack when the list received in step 2 does not match the one as indicated in the user's profile, in which case it can also decide to abort the initial authentication procedure. This is illustrated in steps 1,2 and 3 in Figure 4.

Additionally, in accordance with the non-limiting modalities disclosed in US Patent Application No. 11/232,494, at least one belongs to those cases where the initial authentication procedure for the mechanism

16/42 *

selected authentication process involves more than two series of requests / responses to complete. For example, initial authentication based on

AKA-build requires two sets of request / response to complete. Although the previous modality describes the cases where initial authentication based on SMEKEY Key and MN-AAA may also require two request / response series, there may be cases where they require more than two request / response series. In such cases, the non-limiting modalities disclosed in US Patent Application No. 11/232,494 still apply. This scenario is illustrated in Figure 5 and explained as follows.

1. In an initial authentication request, MN 12 presents a list of authentication mechanisms it supports (for example, {A, B, C}) to BSF 8 in a request. The MN 12 also includes the user's identity. It can be assumed that in most cases this list is not protected.

2. BSF 8 decides on the authentication mechanism to be used for initial authentication, based on the list received from MN 12 and other information (including the mechanisms that BSF 8 itself supports, and the user profile retrieved based on in the user's identity). Figure 5 assumes the chosen A mechanism as a non-limiting example.

3. BSF 8 then proceeds with the chosen authentication mechanism, which typically includes responding with an authentication challenge. BSF 8 also includes in the response an indication of the chosen authentication mechanism (mechanism A in this example). Again, that statement may not be protected.

It should be noted that from that point on MN 12, BSF 8 continues with the selected mechanism (for example, mechanism A as illustrated in Figure 5). As noted above, different mechanisms may require different serial numbers of message exchanges (for example, requests / responses) to complete the initial authentication procedure. For example, the Compile-AKA mechanism requires one or more requests / responses after step 3 to complete; whereas for initial authentication based on

17/42 CAVE key and MN-AAA key, additional series may be required. According to the exemplary modalities of this invention, in one of these messages subsequent to MN 12 sends the original list 11 (as sent in message 1) again, but it is protected (for example, integrity protected); while BSF 8 can send the chosen mechanism (as sent in message 3) again, but it is protected (for example, integrity protected). Note that although MN 12 sends the original list 11, again protected, it is optional (but preferable) for BSF 8 to send the chosen mechanism again protected. If these parameters were sent again protected, the other party is able to verify that the parameter sent is identical to the original parameter received, in order to detect any attempt by an MITM attacker to change the original parameters, which were sent unprotected. In the following description, integrity protection is employed as an exemplary technique for protecting parameters. It must be understood that the parameters can also be encrypted.

4. Still referring to Figure 5, in step 4, MN 12 computes the responses according to mechanism A.

5-6. There may be multiple sets of requests / responses between MN 12 and BSF 8 as explained. In some of these series, the chosen mechanism may not be able to provide the required integrity protection. Therefore, MN 12 and BSF 8 may not be able to send parameters with protected integrity.

7. At a certain point in the initial authentication procedure, the MN 12 may be able to send a message that includes data that is integrity protected. For example, in message 7 suppose that MN 12 is capable of sending such a message. If this is the case, MN 12 will include the original list 11 (the list {A, B, C} in the example) which is protected integrity, indicated by P [{A, B, C}] in Figure 5.

8. Upon receiving the message, BSF 8 verifies that the protected integrity list is identical to the list originally sent by MN 12 in message 1.

18/42

If not, BSF 8 can send an error response to MN 12 to abort the operation (not shown). Alternatively, BSF 8 can quietly abort the operation.

9. At some point in the procedure and initial authentication, BSF 8 may be able to send a message that includes data that is protected integrity. For example, in message 9, suppose that BSF 8 is capable of sending such a message. BSF can include the chosen mechanism (mechanism A in the example) that is of integrity protected, indicated by P [A] in Figure 5.

10. Upon receiving the message, the MN 12 verifies that the chosen protected integrity mechanism is identical to the one originally sent by BSF 8 in message 2. If not, the MN 12 can send an error message to BSF 8 to abort the operation (not shown). Alternatively, the MN 12 can quietly abort the operation.

11. If successful, both parties are empowered to derive the initial Ks authentication key according to the selected initial authentication mechanism.

It can be seen that steps 7 and 8, and steps 9 and 10 (if present) need not be in the order as described, and that they need not be in consecutive messages. That is, BSF 8 can send a message with the protected integrity parameter (the chosen mechanism) first, and the MN 12 can send a message with the protected integrity parameter (the list of supported mechanisms) at a later time . In addition, there may be more series of messages before and after sending protected integrity messages.

The following description provides exemplary implementations, in accordance with the non-limiting modalities disclosed in the US Patent Application

S.N.11 / 232.494, using HTTP build authentication (Figure 6) and simple HTTP transport (Figure 7). It should be noted that the exemplary and non-limiting modalities disclosed in the US S.N.

19/42

11 / 232.494 are not limited to these two examples, and can be implemented using other transport / authentication mechanisms (for example, the Extensible Authentication Protocol (EAP)). In the following descriptions, the parameters needed for engine negotiation (the list 11 of supported engines, sent by MN 12, and the chosen engine, sent by BSF 8) are supposed to be sent in the payloads of HTTP messages. Note, however, that these parameters can alternatively be carried in the appropriate headers in HTTP messages.

HTTP build authentication

In this exemplary implementation, Diffie-Hellman password-protected HTTP build authentication is used for initial authentication. A standard password (for example, Ί1 ... Γ) can be used as the build password, so that mutual authentication between MN 12 and BSF 8 is effectively based on the password-protected Diffie-Hellman mechanism, using MS_AUTH and / or BS_AUTH. The details of the password-protected Diffie-Hellman mechanism are based on the WKEY (Wireless LAN Key) generation procedures described in the wireless LAN interconnection specification, which is being specified in 3GPP2 (see Section 7.1.1 of 3GPP2 X. P0028 “Wireless LAN interworking, attached as Presentation D to US Provisional Patent Application No. 60 / 692,855, filed on June 21, 2005).

Figure 6 illustrates an exemplary implementation of the initial authentication mechanism negotiation with the chosen mechanism being CAVE, where the initial CAVE authentication procedure requires three HTTP request / response series as a whole. The scenario for initial authentication based on the MN-AAA Key is very similar and is therefore not described in further detail.

The following describes the steps shown in Figure 6 in more detail.

1. MN 12 sends a GET HTTP request to BSF 8. The user's identity, in the form of “IMSI@realm.com”, is included as the name

20/42 user in the Authorization header. In addition, the user submits the list 11 of supported authentication mechanisms / initial authentication in the payload (for example, {CAVE, B, C}, meaning that MN 12 supports CAVE and two other mechanisms, B and C).

2. BSF 8 retrieves the list of supported mechanisms from the payload and makes a decision based on the list, username, user profile, and / or other information, and BSF 8 selects CAVE as the initial authentication mechanism in this non-limiting example. From that point on, the initial authentication is based on the chosen mechanism, which is CAVE. BSF 8 ίο generates a 32-bit RAND challenge value.

3. BSF 8 sends an HTTP 401 response to MN 12. The RAND is base-64 encoded and is carried in the nonce field for a given time in the Authenticate-WWW header. The “qop-options” field is set to ^M auth-int ”. The payload also contains an indication that CAVE is a chosen mechanism.

4. MN 12 extracts the chosen mechanism from the payload and proceeds accordingly. For CAVE, the RAND challenge value received by the GBA Function is sent to R-UIM or terminal 1X as a simulated Global Challenge.

5. The 1X terminal (or R-UIM) responds to the global challenge with a

AUTHR and SMEKEY. AUTHR and SMEKEY are then handed over to the GBA Function.

6. The GBA Function determines MS_PW to be SMEKEY. It also generates a secret random number “x for the Diffie-Hellman method. For Build authentication, the GBA Function also has a random 32-bit number, CRAND, to be used as a nonce client.

7. MN 12 sends another GET HTTP request to BSF 8 with an appropriate Authorization header. The Compile response is supposed to be computed in accordance with RFC2617 (attached as Presentation C to US Provisional Patent Application No. 60 / 692,855, filed on June 21, 2005)

21/42 using the default password. CRAND is base64 encoded and transported in the field. The HTTP payload contains AUTHR and MS_RESULT, that is, g ^x mod p, covered by the SMEKEY hash with MS__PW = SMEKEY).

8. BSF 8 verifies that the received MS_RESULT is not zero. BSF 8, acting as a VLR, sends an AUTHREQ, to the HLR / AC 4 ’. AUTHREQ includes RAND, SYSACCTYPE = GAA access and AUTHR parameters. The ESN parameter is defined for all zeros. The SYSCAP parameter is defined to indicate that the Authentication parameters were requested when accessing this system (bitA = 1) and that Signaling Message Encryption is supported by the system (bit-B = 1). All other bits of the SYSCAP parameter are preferably set to zero.

9. HLR / AC 4 'checks AUTHR and generates SMEKEY.

10. The HLR / AC 4 'responds with a TIA-41 AUTHREQ that includes the SMEKEY parameter. If authentication fails, AUTHREQ will only include an indication to deny access.

11. BSF 8 authenticates MN 12 by verifying the Compile response using the default password. If successful, BSF 8 defines BS_PW = SMEKEY and generates a random secret number “y” for the DiffieHellman method.

12. BSF 8 generates 128-bit Ks. The B-TID value is also generated in the NAI format by taking the base64-encoded RAND value from step 2, and the BSF 8 server name, ie base64encode (RAND) @ BSF_servers_domaín_name.

13. BSF 8 sends a 200 OK response to MN 12. The server build response, “rspauth”, is calculated according to RFC 2617 (Presentation C for US Provisional Patent Application No. 60 / 692,855, filed on June 21, 2005) using the default password and carried in the Authentication-lnfo header. The payload of the 200 OK response also contains the BS-RESULT, that is, g ^and mod p, covered by the SMEKEY hash, the B-TID, the lifetime of the Ks key, an indication of the chosen mechanism (CAVE) and BS_AUTH .

22/42

Note that integrity protection can be provided by including the data in the BS_AUTH computation. An exemplary form is as follows:

BS_AUTH [data] = SHA-1 (0x00000005 | 0x00000080 + sizeof (data) | BS — PARAM | data | BS_PARAM | data) module 2 ¹²⁸ , where the data constitute the information that needs to be protected integrity, in which case it includes the B-TID, key life, and indication of the chosen mechanism (CAVE).

14. MN 12 checks rspauth in accordance with RFC 2617 (Filing C for US Provisional Patent Application No. 60 / 692,855, filed June 21, 2005) using the standard password, and checks whether BS_AUTH is equal to XBS_AUTH ' (using the same calculation as BS_AUTH). Then MN 12 also checks if the chosen mechanism indicated is CAVE. If successful, the server and the message sent are authenticated. If it is not successful, MN 12 aborts the initial authentication procedure and can try again immediately or at a later time.

15. MN 12 generates 128-bit Ks.

16. MN 12 sends another GET HTTP request to BSF 8 with an appropriate Authorization header. The compile response is computed using the default password. The payload contains the original list of supported engines ({CABE, B, C} in this example) and MS_AUTH. Integrity protection can be provided by including the data that needs to be protected in the MS__AUTH computation. An exemplary form is as follows:

BS_AUTH [data] = SHA-1 (0x00000004 | OxOOOOOC80 + sizeof (data) | MS_PARAM | data | MS_PARAM | data) module 2 ¹²⁸ , where the data constitute the information that needs to be protected integrity, which in this case is the list supported engines ({CAVE, B, C}).

17. BSF 8 verifies the compilation response using the standard password and authenticates MN 12 by verifying that MS_AUTH is equal to SMS_AUTH (the same calculation as MS_AUTH). BSF 8 also checks that the list of supported engines is identical to the list received in step 2. If not, BSF 8 can send a response to HTTP 403 Forbidden, or other responses from

23/42 error for MN 12, or silently abort the initial authentication procedure (not shown).

18. If successful, BSF 8 sends a 200 OK response to MN 12.

Note that there are many possible variations in the above procedure. However, the basic concepts according to the exemplary and non-limiting modalities disclosed in US Patent Application No. 11/232,494 remain identical and, therefore, not all possible variations are described. A variation is that MS_AUTH and BS__AUTH are used as the build password in steps 16 and 17, respectively, in which case "data" may not be included in the calculation of MS_AUTH and BS_AUTH. Integrity protection in this case will be provided by the build authentication mechanism. Yet another variation is that instead of using MS_AUTH on the MN 12 side and BS_AUTH on the BSF 8 side, only MS_AUTH or BS.AUTH will be used on both sides. Again, "data" is not included in the MS_AUTH or BS_AUTH computation, and integrity protection is provided by the build authentication mechanism.

Simple HTTP transport

In this non-limiting example, simple HTTP is used as a transport mechanism for MN 12 and BSF 8 to change password-protected Diffie-Hellman parameters. Mutual authentication between MN 12 and BSF 8 is based on the password-protected Diffie-Hellman mechanism using MS_AUTH and BS_AUTH.

Figure 7 illustrates an exemplary implementation of an initial authentication mechanism negotiation with the chosen mechanism being CAVE, and where the initial authentication procedure with CAVE requires three sets of GET HTTP / response. The scenario for initial authentication based on the MN-AAA Key is very similar and is therefore not included here. The following describes the steps in more detail.

1. MN 12 sends a GET HTTP request to BSF 8. The

24/42 user identity, in the form of “IMSI@realm.com”, is included in the payload. In addition, the user includes the initial authentication / authentication mechanism list, supported in the payload (for example, (CAVE, B, C}, meaning that MN 12 supports CAVE and two other mechanisms, B and C).

2. BSF 8 retrieves the list of supported mechanisms from the payload and makes a decision based on the list, the user name (also from the payload), the user profile, and / or other information. Suppose that BSF 8 selects CAVE as the initial authentication mechanism, and from that point on the initial authentication is based on the chosen mechanism (for example, CAVE). BSF 8 generates a 32-bit RAND challenge value.

3. BSF 8 sends a response (200 OK) to MN 12. The RAND is base64-encoded and loaded into the payload. The payload also contains an indication that CAVE is the chosen mechanism.

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

5. Terminal 1X (or R-UIM) responds to the global challenge with an AUTHR and SMEKEY. AUTHR and SMEKEY are then delivered to the GBA Function.

6. The GBA Role determines MA_PW to be SMEKEY. It also generates a secret random number “x” for the Diffie-Hellman method.

7. MN 12 sends another GET HTTP request to BSF 8. The HTTP payload contains AUTHR and MS_RESULT, that is, g ^x mod p, covered by the SMEKEY hash.

8. BSF 8 verifies that the received MS_RESULT is not zero. BSF 8, acting as a VLR, sends an AUTHREQ to HLR / AC 4 ’. AUTHREQ includes RAND, SYSACCTYPE = GAA access and AUTHR parameters. The ESN parameter is set to all zeros. The SYSCAP parameter is adjusted to indicate that the Authentication parameters were requested when accessing this system (bit-A = 1) and that Signaling Message Encryption is supported by the system (bit-B = 1). All other bits of the SYSCAP parameter can be set to zero.

25/42

9. HLR / AC checks the AUTHR and generates the SMEKEY.

10. HLR / AC responds with a TIA-41 AUTHREQ that includes the SMEKEY parameter. If authentication fails, AUTHREQ can include only an access denied indication.

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

12. BSF 8 generates 128-bit Ks. The B-TID value can also be generated in the NAI format by taking the base64 encoded RAND value from step 2, and the BSF 8 server name, that is, base64encode (RAND) @BSF_servers_domain_name.

13. BSF 8 sends a response (for example, 200 OK) to the MN

12. The payload for the response may contain the BS_RESULT, that is, g ^and mod p, covered by the SMEKEY hash, the B-TID, the lifetime of the Ks key, an indication of the chosen mechanism (CAVE) and BS_AUTH. Note that integrity protection can be provided by including the data in the BS_AUTH computation. An exemplary form is as follows:

BS_AUTH [data] = SHA-1 (0x00000005 | OxOOOOOC80 + sizeof (data) | BS_PARAM | data | BS_PARAM | data) module 2 ¹²⁸ , where the data constitute the information that needs to be protected, and includes B-TID, useful life, and the indication of the chosen mechanism (CAVE).

14. MN 12 checks whether BS_AUTH is equal to XBS_AUTH (same calculation as BS_AUTH). The MN 12 also checks whether the chosen mechanism indicated is CAVE. If successful, the server and the message sent are authenticated. If it is not successful, MN 12 preferably aborts the initial authentication procedure and can try again immediately or at a later time.

15. MN 12 generates 128-bit Ks.

16. MN 12 sends another GET HTTP request to BSF 8. The payload contains MS_AUTH. The payload can also contain the original list of supported engines ({CAVE, B, C} in this example) and MS_AUTH. The protection

26/42 integrity can be provided by including the data that needs to be protected in the MS_AUTH computation. An exemplary form is as follows:

MS__AUTH [data] = SHA-1 (0x00000004 | 0x00000080 + sizeof (data) | MS_PARAM | data | MS_PARAM | data) module 2 ¹²⁸ , where the data constitute the information that needs to be protected, and the original list of supported mechanisms ({CAVE, B, C}).

17. BS authenticates MN 12 by verifying that MS_AUTH is equal to XMS_AUTH (same calculation as MS_AUTH). BS also checks that the list of supported engines is identical to the list received in step 2. If not, BSF 8 can send an HTTP 403 Forbidden response, or other error responses to MN 12, or it can silently abort the initial authentication procedure (not shown).

18. BSF 8 sends responses (for example, 200 OK) to MN 12.

Note that there can be many possible variations in the above procedure. However, the basic concepts revealed in accordance with the non-limiting and exemplary modalities disclosed in US Patent Application No. 11/232,494 remain the same.

XML Schema Definition

In the 3GPP GBA, an HTTP payload loads the B-TID (Initial Authentication Transaction Identifier) and key life in the final 200 OK response if the initial authentication 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 needed for initial authentication based on the SMEKEY Key and MN-AAA, these include the AUTHR parameter (for CAVE) and the password-protected Diffie-Hellman parameters. The non-limiting modalities disclosed in US Patent Application No. 11 / 232,494 provide that the XML schema is extended further to include the list of authentication mechanisms, as well as the indication of the selected mechanism. A possible definition of the scheme is as follows, where the extensions used to support non-limiting modalities

27/42 and examples disclosed in Patent Application S.N. 11 / 232,494 are shown underlined and in italics.

<? xml version-'1.0 encoding = UTF-8?>

<xs: schema targetNamespace-'uri: 3 gpp2-gba xmlns: gba = uri: 3gpp2-gba xmlns: xs = ^l 'http: //www.w3,orq/2001/XMLSchema' ^t >

<! - definition of the root element containing B-TID, key life, and other parameters ->

<xs: complexType name = * 'bootstrappinglnfoType>

<xs: sequence>

<xs: element name-’btid type = xs: string minOccurs-Ό7>

<xs: element name-'lifetime type = xs: dateTime minOccurs = 07> <xs: element name-authr type-'xs: base64Binary minOccurs-Ό7> <xs: element name = ms_result type = xs: base64Binary minOccurs-Ό7> <xs: element name = bs_result type = xs: base64Binary minOccurs-O7> <xs: element name = authjist minÓccurs = 0>

<xs: simpleType>

<xs: list itemType = gba: authTvpe 7> </ xs: simpleType>

</ xs: element>

<xs: element name = auth type = gba: authType minOccurs-O7> </ xs: sequence>

</ xs: comp! exType>

<! - definition of the type of authentication mechanism and initial authentication -> <xs: simpleTvDe name = authType>

<xs: base restriction = xs: strina>

<xs: enumeration value-'3GPP-AKA />

<xs: enumeration value = 3GPP2-AKA'7>

<xs: enumeration value— CAVE'7> <xs: enumeration value-'ΜΝ-ΑΑΑ 7> </ xs: restriction>

</ xs: simpleTvpe>

<i — the root element ->

<xs: element name-Bootstrappinglnfo type = gba: bootstrappinglnfoType />

</ xs: schema>

In the schema, the element, the element “authjist” is used to load the list 11 of authentication mechanisms and initial authentication in messages 1 and 5 in Figures 2 and 3. The element “auth” is used to load an indication of the BSF mechanism. -selected in messages 3 and 7 in Figures 2 and

3. The “auth Type” is defined as an enumeration of the current authentication mechanisms and initial authentication in the various standards, and can assume

28/42 the following exemplary values:

“3GPP-AKA”: initial authentication based on the 3GPP AKA mechanism;

“3GPP2-AKA”: initial authentication based on the 3GPP2 AKA mechanism;

“CAVE”: initial authentication based on SMEKEY (CAVE); and “MN-AAA”: initial authentication based on the MN-AAA key.

When more authentication mechanisms are supported in GBA, corresponding names of the new authentication mechanisms are added to authType.

Alternatively, instead of having both “3GPP-AKA” and “3GPP2AKA”, only “AKA” can be defined in the scheme. The current mechanism used in AKA is then pre-configured by the network operator.

Note that the above scheme is of an exemplary nature, and that other techniques are possible to achieve the same objective. In addition, the scheme can be extended to include other information that is useful for transporting payloads. For example, in the exemplary implementation using simple HTTP as a transport to load the password-protected Diffie-Hellman described above, the payloads preferably carry other information such as the username, RAND, MS_AUTH, BS_AUTH, and so on. The scheme can thus be extended accordingly to allow these parameters to be carried as well.

It should be noted that the names of the authentication mechanisms in the definition above are exemplary, and are used here without a loss of generality.

It must be considered that the exemplary modalities described in Figures 1-7 are simple, efficient and secure, do not require IETF standardization efforts, are extensible to support future authentication and initial authentication mechanisms, and support both 3GPP and 3GPP2 systems.

29/42

In accordance with a computer program apparatus, method and product, in accordance with the non-limiting and exemplary modalities disclosed in US Patent Application SN 11 / 232.494, a technique is provided for execution by means of a network or node device , such as BSF 8, and a device or node, such as MN 12, to perform an initial authentication procedure comprising, in an initial authentication request, MN 12 by sending a first request message to BSF 8 that includes a list of authentication mechanisms that the MN 12 supports; BSF 8 determining an authentication mechanism to be used for initial authentication, based on at least the list received from MN 12, and proceeding with the selected authentication mechanism and including in a reply message to MN 12 an indication of the determined authentication mechanism; the MN 12 sending a second request message, which is at least partially of integrity protected, to BSF 8 based on the determined authentication mechanism, the second request message including the list of authentication mechanisms that the MN 12 supports in a form of protected integrity. If authentication is successful, and if the list received in the second request message matches the list received in the second request message, the network can respond to MN 12 with a successful response message, which at least partially is of integrity protected, where the successful response message includes an indication of the authentication mechanism selected in a form of protected integrity. MN 12, upon receiving the successful response message, can verify that the authentication mechanism used by MN 12 matches the authentication mechanism selected by BSF 8. The first request message sent by MN 12 can also understand the user's identity , which can be used by BSF 8 to assist in selecting the authentication mechanism.

Multiple series of messages can be accommodated by the teachings according to the invention. Negotiation can proceed for

30/42 through Build authentication, or you can proceed using HTTP as non-limiting examples.

Having thus described the exemplary and non-limiting embodiments of the invention disclosed in U.S. Patent Application No. 11 / 232,494, a description is now provided of the exemplary and non-limiting embodiments of the invention according to that invention. It can be seen that the exemplary embodiments of that invention can be used in conjunction with all or some of the various exemplary embodiments of the invention described in US Patent Application No. 11/232,494.

In accordance with the exemplary modalities of this invention, the XML Schema is modified in such a way that it clearly identifies the "link" between the supported authentication mechanism and the identity or identities (ids) that can be used with those specific mechanisms. If an identity can be used with multiple mechanisms, then the XML Schema preferably lists all possible combinations, for example:

1id1 mechanism 1id2 mechanism 2id3 mechanisms

Referring now to Figure 8, when the first GET HTTP message with the XML document (based on XML Schema) as a payload is received by BSF 8 (message 1 in Figure 8), BSF 8 selects the preferred mechanism by the network and contact the appropriate database to proceed with the initial authentication procedure. If the selected engine happens to be usable with more than one identity (as listed by MN 12 in the XML document in the HTTP payload), then BSF 8 selects one of the identities. When the selection is made, the XML document returned to MN 12 by BSF in Response 401 (message 5 in Figure 8) for the GET request explicitly identifies the selected mechanism and the corresponding associated identity.

It can be seen that the XML Schema defines as a

31/42 XML document will appear. The XML document is then sent in the payload of HTTP messages. In this way, the XML Schema can be considered to be fixed, and is not sent during initial authentication. However, XML documents, according to this XML Schema, are sent as an HTTP payload, to carry the information needed for initial authentication.

According to the previously mentioned arguments, the identities to be inserted in the messages of the initial authentication procedure are as follows:

A. GET HTTP request from MN 12 to BSF 8 (message 1 in Figure 8)

The Authorization header in the GET HTTP request can contain any of the MN 12 identities. BSF 8 is not based on that identity at this time. Preferably, the XML document in the HTTP payload contains the list of supported mechanisms and MN 12 identities as described above.

B. HTTP 401 UNAUTHORIZED response from BSF 8 to MN 12 (message 5 in Figure 8).

BSF 8 selects an authentication mechanism and a corresponding identity from the list found in the XML document in the HTTP payload received from MN 12. The selected authentication mechanism and the corresponding identity are returned to MN 12 in the payload the reply message.

C. GET HTTP request from MN 12 to BSF 8 (message 7 in Figure 8)

MN 12 uses its identity returned by BSF 8 in the payload of the previous message as the user identity in HTTP build authentication (authorization header field). MN 12 and BSF 8 then proceed according to the authentication mechanism selected by BSF 8. Preferably, the XML document in the HTTP payload contains the supported mechanisms and MN 12 identifies as described above. Unlike the

32/42 message 1, that information has integrity protected.

D. HTTP 200 OK response from BSF 8 to MN 12 (message 9 in Figure 8)

BSF 8 responds with an HTTP 200 OK message, indicating a successful authentication and initial authentication operation. The message also includes the compilation response computed by BSF. The message can also include an indication of the selected authentication mechanism and the corresponding identity for reference by MN 12. Similarly, this indication has integrity protected by setting qop to “auth-int”.

The rest of the initial authentication procedure can then continue as described in 3GPP2 S.P0109-0, Version 0.6, December 8,

2005, “Generic Bootstrapping Architecture (GBA) Framework”, attached as Presentation C to US Provisional Patent Application No. 60 / 759,487. This document must be published as 3GPP2 S.S0109-0, v1.0, and currently the most recent version is S00-20060220-121A_SP0109_V & V_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 life, and other type = xs: base64Binary parameters ->

<xs: complexType name = bootstrappinglnfoType>

<xs: sequence>

<xs: element name = btid type = xs: string minOccurs-O7> <xs: element name-lifetime type = xs: dateTime minOccurs = 07> <xs: element name = esn type = xs: base64Binary minOccurs = 07> <xs : element name = ms_chair minOccurs-O7>

<xs: element name = ms_result minOccurs = 07> <xs: element name = bs_result minOccurs-O7>

<xs: element name = auth_list minOccurs = 0> <xs: simpleType>

type = xs: base64Binary type = xs: base64Binary

33/42 <xs: list itemType-gba: authType7>

</ xs: simpleType> </ xs: element> <xs: element name- ^ uth * 'type = gba: authType minOccurs = 07> </ xs: sequence>

</ xs: complexType>

<! -_ definition of the type of authentication mechanism and initial authentication_ ~>

<xs: simpleType name-authType>

<xs: restriction base = xs: string ^,, ><xs: enumeration value = AKA7><xs: enumeration value = CAVE7><xs: enumeration value = MN-AAA7></ xs: restriction>

</ xs: simpleType>

<1 — the root element—>

<xs: element name = Bootstrappinglnfo type = gba: bootstrappinglnfoType7>

<xs: schema>

There are several possible modifications that can be made to the Schema

Previous XML to implement the exemplary modalities of the invention. The following are several examples intended to be read by way of example and not as a limitation on the practice and / or use of the exemplary modalities of this invention.

Example 1.

XML schema 1:

type-'xs: base64Binary type = xs: base64Binary <? xml version-Ί.0 ”encoding = UTF-8?>

<xs: schema targetNamespace- ^, uri: 3gpp2-gba ”xmlns: gba = uri: 3gpp2-gba xmlns: xs = ^t, http: //www.w3.ora/2001/XMLSchema ' ^, ><! - element definition root containing B-TID, key life, and other parameters ->

<xs: complexType name = bootstrappinglnfoType ''> <xs: sequence>

<xs: element name = btid type = xs: string minOccurs-O7><xs: element name-lifetime type = xs: dateTime minOccurs-'07><xs: element name- ”esn type- ^f xs: base64Binary minOccurs-O7 ><xs: element name = ms_chaH minOccurs-O7>

<xs: element name = ms_result minOccurs-O7>

<xs: element name-bS-jesult minOccurs = 07>

<xs: element name = auth_Jist minOccurs-O>

<xs: complexType>

<xs: sequence>

<xs: element name = auth_Jnfo type = gba: authlnfo minOccurs-Ί 7>

type = xs: base64Binary

34/42

</ xs: sequence> </ xs: complexT ype> </ xs: element> <xs: element name ^ auth type = gba: authlnfo minOccurs = 'O7> 5 </ xs: sequence> </ xs: complexType> <xs: complexType name-'authlnfo> <xs: sequence> 10 <xs: element name = method type = gba: authType7> <xs: element name = clientid type-xs: string /> </ xs: sequence> </ xs: complexType> <! -_ definition of the type of authentication mechanism and 15 initial authentication -> <xs: simpieType name-'authType> <xs: restriction base-'xs: string> <xs: enumeration value- 'AKA7> <xs: enumeration value-'CAVE7> <xs: enumeration value = MN- YYY7> ^ 20 </ xs: restriction> </ xs: simpleType> <1-the root element—> <xs: element name = Bootstrappinglnfo type = gba: bootstrappinglnfoType7> </ xs: schema> 25 The following is a snippet of an example of an "authjist according to the previous XML Schema: <auth_jist> <auth_info> <method> AKA </method> 30 <clientid> userijDrivate@homel.net </clientid> </auth_info> <auth_info> <method> CAVE </method> <clientid> 123456789012345 </clientid> 35 </auth_info> <authjnfo> <method> MN-AAA </method> <clientid> foo@example.com </clientid> </ auth info> 40 </auth_list> Example 2 Scheme 2 XML: <? xml version-TO encoding = UTF-8 ' ^, ?><xs: schema targetNamespace = uri: 3 gpp2-gba 45 xmlns: gba = uri: 3gpp2-gba ” xmlns: xs = http: //www.w3.org/2001/XMLSchema> <! - definition of the root element containing B-TID, key life, and other parameters ->

35/42

—20 <xs: complexType name-'bootstrappinglnfoType>

<xs: sequence>

<xs: element name = btid type = xs: string minOccurs-O7> <xs: element name = lifetime type = xs: dateTime minOccurs = 07> <xs: element name = esn type = xs: base64Binary minOcciirs = 07> <xs : element name = ms_chall minOccurs = 07>

<xs: element name = ms_result minOccurs = 07>

<xs: element name = bs_result minOccurs-O7>

<xs: element name = authjist minOccurs-O> <xs: complexType> <xs: sequence>

<xs: element name = authjnfo type-’gba: authlnfo minOccurs- '1 7> </ xs: sequence> </ xs: complexType> </ xs: element>

<xs: element name-áuth '’type-'gba: authlnfo” minOccurs-O7> </ xs: sequence> </ xs: complexType>

type = xs: base64Binary type = xs: base64Binary type = xs: base64Binary <xs: complexType name-'authlnfo ”>

<xs: simpleContent>

<xs: extensionbase = ”gba: authType>

<xs: attribute name- 'clientid type = xs: string ’' use = required7> </ xs: extension>

</ xs: simpleContent>

</ xs: complexType>

<! -_ definition of the type of authentication mechanism and initial authentication_ ~> <xs: simpleType name = authType> <xs: restriction base = xs: string>

<xs: enumeration value-'AKA7>

<xs: enumeration value-'CAVE7>

<xs: enumeration value = MN-AAA7>

</ xs: restriction>

</ xs: simpleType>

<! - the root element -><xs: elementname = Bootstrappinglnfo ' ^, type = gba: bootstrappinglnfoType7>

</ xs: schema>

Below is a snippet of an example “authjist” according to this XML Schema:

authjist>

<auth_info clientid = useri_private@homel.net> AKA </auth_info> 45 <authjnfo clientid = 123456789012345> CAVE </authJnfo>

<auth_Jnfo clientid = foo@example.com> MN-AAA </auth_info> </auth_list>

36/42

Example 3

XML Schema 3:

<? xml version = 1.0 encoding = UTF-8?> <xs: schema targetNamespace-uri: 3gpp2-gba xmlns: qba = uri: 3qop2-qba xmlns: xs = http: //www.w3.org/2001/XMLSchema > <! - definition of the root element containing B-TID, key life, and other parameters ~>

<xs: complexType name-bootstrappinglnfoType>

<xs: sequence>

<xs: element name = btid type = xs: string minOccurs-'07><xs: element name = lifetime type = ^l, xs: dateTime minOccurs-O7><xs: element name = esn type- * xs: base64Binary minOccurs- O7><xs: eiement name-'ms_chair 'minOccurs = 07>

<xs: element name = ms_result minOccurs = 07>

<xs: element name = bs_result min0ccurs-'07>

<xs: element name = auth_list minOccurs-O> <xs: simpleType>

<xs: listitemType = gba: authType7> </ xs: simpleType> </ xs: element>

<xs: element name = auth type = gba: authType minOccurs-O7> <xs: element name = clientid_list minOccurs-O> <xs: simpleType>

<xs: I ist itemType-'xs: string7> </ xs: simpleType> </ xs: element>

<xs: elementname- ’clientid type-'xs: string minOccurs = 07> </ xs: sequence>

</ xs: complexType>

<l-_definition of the type of authentication mechanism and initial authentication .-> <xs: simpleType name = authType> <xs: restriction base = xs: string> <xs: enumeration value = AKA7> <xs: enumeration value- ' CAVE7> <xs: enumeration value-'MN-AAA'7> </ xs: restriction>

</ xs: simpleType>

type = xs: base64Binary type = xs: base64Binary type = xs: base64Binaiy <! - the root element ->

<xs: element name = Bootstrappinglnfo type ^{= ,,} gba: bootstrappinglnfoType7>

</ xs: schema>

The following is a snippet of an example of “authjist and“ clientidjist ”:

<auth_list> AKA CAVE MN-AAA </authJist>

37/42 <clientid_list> userl_private @ homel .net 123456789012345 foo@example.com </clientid_list>

Figure 8 shows an exemplary call flow using the

Scheme 1 XML above. The example is taken from Figure C.3-1 of Annex C of 3GPP2 .P0109-0, Version 0.6, December 8, 2005, “Generic Bootstrapping

Architecture (GBA) Framework ”, attached as Presentation C to US Provisional Patent Application referred to above No. 60 / 759,487. The example in Figure 8 highlights the changes made to the HTTP payload, and therefore only messages 1, 5, 7 and 9 are of specific relevance to gain an understanding of the exemplary modalities of this invention. The rest of the diagram can remain unchanged from that shown in Annex C.

Message 1. Initial GET request (MN 12 to BSF 8)

The purpose of this message is to initiate the initial authentication procedure between MN 12 and BSF 8. MN 12 sends an HTTP 15 Request containing the user's private identity to its native BSF 8. MN 12 also presents a list of initial authentication mechanisms that it supports, together with the corresponding identities, in the message payload.

Table: Example of an initial GET request (MN 12 to BSF 8) 20 GET / HTTP / 1.1

Host: bsf.home.net

User-Agent: Initial Authentication Client Agent Date:

Accept: */*

Referer: http://pki-portal.homel.net:2311/pkip/enroll

Authorization: Compile Username=userl_private@home.net, realmbsf.home.net '', nonce- ¹ , uri-V, response- ”

Content-Type: application / vnd.3 gpp2.bsf + xml

Content-Length (...) <? Xml version-'1.0 encoding = UTF-8?> <Bootstrappinglnfoxmlns = uri: 3gpp2-gba> <authjist>

<auth_info>

<method> AKA </method> <clientid> userlj3rivate@homel.net </clientid> </auth_info>

<auth_info>

38/42

Λ <method> CAVE </method> <clientid> 123456789012345 </clientid> </auth_info> <auth_info> 5 <method> MN-AAA </method> <clientid> foo@example.com </clientid> </auth_info> </auth_list> 10 </ Bootstrapping! Nfo> Message 5. 401 unauthorized response (BSF 8 to MN 12) BSF 8 sends the challenge to MN 8 in the HTTP 401 Unauthorized response (without CK, IK and XRES). This is to demand that MN 12 authenticate itself. The challenge contains RAND and AUTN that are populated in the field 15 nonce in accordance with RFC 3310 (IETF RFC 3310 “Compile AKA”, attached as submission B to US Provisional Patent Application referred to above No. 60 / 759,487). Table: Example of 401 Unauthorized Response (BSF 8 for MN 20 12) HTTP / 1.1 401 Unauthorized Server: Initial Authentication Server Date: Monday, October 24, 2005 at 10:13:17 GMT WWW-Authenticar: Compile domain-bsf. home.net, nonce = base64 (RAND + AUTN 25 + specific server data), algorithm = AKAvl-MD5, qop = auth-int Content-Type: application / vnd.3gpp2.bsf + xml Content-Length: (...) <? xml version-'1.0 encoding = UTF -8?><Bootstrapping! Nfoxmlns = uri: 3gpp2-gba ^,, > 30 <auth> <method> AKA </method> <clientid> userl_private@homel.net </clientid> </auth> 35 </ Bootstrappi ng I nfo> Message 7. GET Request Example (MN 12 to BSF 8) The MN 12 again sends a GET HTTP request, with the RES which is used for response calculation, to BSF 8. Table: Example of GET Request (MN 12 to BSF 8) 40 GET / HTTP / 1.1 Host: bsf.home.net

39/42

User-Agent: Initial Authentication Client Agent Date: Mon, 24 Oct 2005 10:13:18 GMT Accept: 7 * Referer: http://pki-portal.home.net:2311/pkip/enroll 5 Authorization: Compile Username =userl_private@horne.net, realm-'bsf. home.net, nonce = base64 (RAND + AUTN + server specific data), uri- /, qop = auth-int, nc = 00000001, cnonce = 6629fae49393a05397450978507c4efl, 10 response = 6629fae49393a05397450978507c4efl, opaque = 5ccc069c403ebaf9fD171 e9517f30e41, algorithm = AKAvl-MD5 Content-Type: application / vnd.3gpp2.bsf + xml Content-Length: (...) <? xml version = 1.0 encoding = UTF-8?> 15 <BootstrappÍnglnfoxmlns = uri: 3gpp2-gba> <auth_list> <auth_info> <method> AKA </method> <clientid> userl_private @ homel .netuseri__private @ homel.net 20 </clientid> </auth_info> <auth_info> <method> CAVE </method> <clientid> 123456789012345 </clientid> 25 </auth_info> <auth_info> <method> MN-AAA </method> <clientid> foo@example.com </clientid> </auth_info> 30 </authJist> </Bootstrappinglnfo> Message 9. Sample 200 OK response (BSF 8 to MN 12) BSF 8 sends 200 OK response to MN 12 to indicate success 35 authentication. Table: 200 OK response (BSF 8 to MN 12) HTTP / 1.1 200 OK Server: Initial Authentication Server Authentication-lnfo: qop = auth-int, 40 rspauth = 6629fae49394a05397450978507c4efl, cnonce = 6629fae49393a05397450978507o4efl, nc = 00000001 Date: Expires: * date / time * Content-Type: application / vnd.3gpp.bsf + xml 45 Content -Length: (...) <? xml version = 1.0 encoding = UTF-8?> <BootstrappinglnfoxmlnS'uri: 3gpp-gba>

40/42 <auth>

<method> AKA </method> <clientid> userl_private@homel.net </ click ntid>

</auth>

<btid> bmFtYXJ0bHUgc2F5cyBoaQ==@bsf.operator.com </btid> <lifetime> 2005-l I-21T13: 20: 00-05: 00 </lifetime>

</Bootstrappinglnfo>

Based on the foregoing, it should be evident that the exemplary modalities of that invention provide a computer program method, apparatus and product (s) for sending a first message to a wireless network (WN) that is comprised of a list of authentication 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 initial authentication, based on at least the list received from the node, and including a first response message for the information node belonging to the authentication mechanism determined in conjunction with the corresponding identification.

An aspect of the exemplary embodiments of that invention can be considered to be that in that invention, when an "authentication mechanism" is sent in the HTTP payload, the corresponding identification, also referred to here without loss of generality as an identity, is also included. From this point of view, for the first and second requests from MN 12, the list of supported mechanisms is included in the HTTP payload and, therefore, the corresponding identifications are also included. In addition, for first, and second, responses sent by WN, the selected authentication mechanism is included in the payload, and the corresponding identification is also included. In addition, the second request from MN 12 also contains the list and the corresponding identifications, and that information has integrity protected. Similarly, the selected mechanism and the corresponding identification, if present in the second response, preferably also have integrity protected.

In general, the various modalities can be implemented in

41/42 hardware or special use circuits, software, logic or their combinations. For example, some aspects can be implemented in hardware, while other aspects can be implemented in firmware or software which can be performed by a controller, microprocessor or other computing device, although the invention is not limited to them. Although several aspects of the invention can be illustrated and described as block diagrams, flowcharts, or using some other pictorial representation, it is well understood that these blocks, devices, systems, techniques or methods described here can be implemented, as non-limiting examples, in hardware, software, firmware, special-purpose circuits or logic, general-purpose hardware or controller or other computing devices, or any combination thereof.

The modalities of the invention can be practiced on several components such as integrated circuit modules. The integrated circuit model is, as a whole, a highly automated process. Complex and powerful software tools are available to convert a logic-level model into a semiconductor circuit model ready to be etched and formed into a semiconductor substrate.

Programs, such as those provided by Synopsys, Inc. of Mountain View, California and Cadence Design, of San Jose, California automatically guide drivers and locate components on a semiconductor chip using well-established design rules as well as libraries of module modules. pre-stored project. When the design for a semiconductor circuit has been completed, the resulting design, and 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 become evident to those skilled in the art in the light of the previous description, when read in conjunction with the attached drawings. As non-limiting examples, other types of

42/42 message formats and the like may be used to carry information between device 12 and 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 to the teachings of that invention will still fall within the scope of the non-limiting modalities of that invention.

In addition, some of the features of the various non-limiting embodiments of this invention can be used advantageously without the corresponding use of other features. As such, the foregoing description should only be considered as illustrative of the principles, teachings and modalities | exemplary of that invention, and not as a limitation thereof.

Claims (29)

1. A method for providing mobile node identities in conjunction with authentication preferences in a generic boot architecture, characterized by comprising: receiving from a mobile node, via a wireless network boot server function, a first message consisting of a list of authentication mechanisms supported by a node and, in association with each authentication mechanism, a corresponding identity; determine, by the function of the boot server, an authentication mechanism to be used for boot, based at least on the list received from the mobile node; receive, via the mobile node's boot server function, a third message that is at least partially protected based on the determined authentication mechanism, the third message comprising at least the list of authentication mechanisms that the mobile node supports, and identities correspondents, in a form of protected integrity; and if authentication is successful, and if the list received in the third message matches the list received in the first message, respond to the mobile node with a second reply message that is at least partially integrity protected, where the second reply message it can include an indication of the selected authentication mechanism, and the corresponding identities, in a protected integrity form. Method according to claim 1, characterized in that, if the determined authentication mechanism is usable with more than one identity, it comprises Petition 870190003069, of 10/01/2019, p. 11/25 2/11 also the selection of one of the identities to be associated with the determined authentication mechanism. Method according to claim 1, characterized in that the first message comprises an HTTP GET request, and the second message comprises a first reply message including an XML document that explicitly identifies the determined authentication mechanism and a corresponding identity. Method according to claim 1, characterized in that it further comprises the verification that the authentication mechanism used by the mobile node corresponds to the authentication mechanism determined by the Initialization Server Role. Method according to claim 1, characterized in that the first message is an HTTP GET, in which the list is included in an HTTP payload. Method according to claim 1, characterized in that the second message is an Unauthorized HTTP 401 response. Method according to claim 1, characterized in that the third message is an HTTP GET that comprises a response calculated according to the selected authentication mechanism. Method according to claim 1, characterized in that the second reply message is an HTTP 200 OK message. 9. A device for providing mobile node identities in conjunction with authentication preferences in a generic boot architecture, Petition 870190003069, of 10/01/2019, p. 12/25 3/11 characterized by comprising a data processor, a transmitter, and a receiver; where the device is configured to: send to a network boot server function, through the transmitter, a first message consisting of a list of authentication mechanisms supported by the device and, in association with each authentication mechanism, a corresponding identity of a user, and receive from the boot server function, via the receiver, a first response message comprising information pertaining to an authentication mechanism selected by the boot server function from the list together with a corresponding identity, where the device comprises a mobile node, and where the device is still configured to: send, through the transmitter, a second message to the boot server function that is at least partially integrity protected, the second message comprising at least the list of authentication mechanisms that the device supports, and the corresponding identities, in a form protected integrity; and if the authentication is successful, and if the list received in the second message matches the list received in the first message, receive, through the receiver, a second response message from the boot server role that is at least partially integrity protected, the second reply message comprising an indication of the selected authentication mechanism, and the corresponding identity, in a form of protected integrity. Device according to claim 9, characterized in that the first message is sent as an HTTP GET, in which the list is included in an HTTP payload, and in which the first response message is received as an HTTP 401 response No Authorized. Petition 870190003069, of 10/01/2019, p. 13/25 4/11 Device according to claim 9, characterized in that the second message is sent as an HTTP GET that comprises a response calculated according to the selected authentication mechanism. Device according to claim 9, characterized in that the second reply message is received as an HTTP 200 OK message. Device according to claim 9, characterized in that the data processor is still operable to verify that an authentication mechanism used by the device matches the authentication mechanism selected by the network. 14. Network device to provide mobile node identities in conjunction with authentication preferences in a generic boot architecture, characterized by comprising a data processor, a transmitter and a receiver, and in which the network device is configured to: receive from a mobile node, through the receiver, a first message composed of a list of authentication mechanisms supported by the node and, in association with each authentication mechanism, a corresponding identity of a user, determine an authentication mechanism to be used for initialization, based, at least in part, on the list received from the mobile node, sending a first response message to the node through the transmitter, the first response message comprising information pertaining to the given authentication mechanism, and a corresponding identity , receive, from the mobile node, a second message which is at least partially of protected integrity, the second message comprising Petition 870190003069, of 10/01/2019, p. 14/25 5/11 the list of authentication mechanisms that the node supports, and the corresponding identities, in a form of protected integrity; and if authentication is successful, and if the list received in the second message matches the list received in the first message, send a second reply message to the mobile node that is at least partially protected integrity, the second reply message comprising an indication the selected authentication mechanism, and the corresponding identity, in a form of protected integrity, where the network device comprises a boot server role. Network device according to claim 14, characterized in that the data processor is still operable to retrieve an identity-based profile for consideration when determining the authentication mechanism to be used for initialization. Network device according to claim 14, characterized in that the first message is received as an HTTP GET comprising an identity of a node user, in which the list is included in an HTTP payload. Network device according to claim 14, characterized in that the first response message is sent as an Unauthorized HTTP 401 response. A network device according to claim 14, characterized in that the second message is received as an HTTP GET comprising a response calculated according to the selected authentication mechanism. Network device according to claim 14, characterized in that the second reply message is sent as an HTTP 200 OK message. Petition 870190003069, of 10/01/2019, p. 15/25 6/11 20. A device for providing mobile node identities in conjunction with authentication preferences in a generic boot architecture, characterized by comprising: a transmitter, configured to send a boot server role a first message consisting of a list of authentication mechanisms supported by the device and, in association with each authentication mechanism, a corresponding user identity, in which the transmitter is configured yet to send a second message to the boot server role that is at least partially integrity protected, the second message comprising at least the list of authentication mechanisms that the device supports, and the corresponding identities, in a form of protected integrity ; a receiver, configured to receive from the boot server role a first reply message, the first reply message comprising descriptive information for an authentication mechanism selected by the boot server role from the list and a corresponding identity; a processor; and a memory incorporated with software; where the processor, together with memory and software, is configured to make the device protect the integrity of the list of authentication mechanisms supported by the device that is sent in the second message at least partially of protected integrity for the boot server, and further configured to verify that the authentication mechanism used by the device matches the authentication mechanism selected by the boot server function, where the device comprises a mobile node, and Petition 870190003069, of 10/01/2019, p. 16/25 7/11 if authentication is successful, and if the list received in the second message matches the list received in the first message, the receiver is still configured to receive a second response message from the boot server role that is at least partially of protected integrity, where the second reply message comprises an indication of the selected authentication mechanism, and the corresponding identity, in a form of protected integrity. 21. A network device for providing mobile node identities in conjunction with authentication preferences in a generic boot architecture, characterized by comprising: a receiver, configured to receive from a mobile node a first message consisting of a list of authentication mechanisms supported by the mobile node and, in association with each authentication mechanism, a corresponding identity of a user, a processor: a built-in memory with software, where the processor, together with the memory and software, is configured to make the network device select an authentication mechanism to be used for initialization, based, at least in part, on the list received from the mobile node, and send a first response message to the mobile node, the first response message comprising information pertaining to the selected authentication mechanism, and a corresponding identity, in which said receiver is still configured to receive a mobile response from the mobile node. second message which is at least partially of protected integrity, the second message comprising the list of authentication mechanisms that the mobile node supports and, in association with each authentication mechanism, the corresponding identity, Petition 870190003069, of 10/01/2019, p. 17/25 8/11 in which the device comprises a mobile node, and the network device comprises a boot server function, in which said network device is responsive to successful authentication, and to a match of the list received in the second message with the list received in the first message, to send to the mobile node a second reply message that is at least partially of protected integrity, the second reply message comprising an indication of the selected authentication mechanism, and the corresponding identity, in a form of protected integrity . 22. Network device according to claim 21, characterized in that it further comprises means for retrieving an identity-based profile for use by said selection means when selecting the authentication mechanism to be used for initialization. 23. A system for providing mobile node identities in conjunction with authentication preferences in a generic boot architecture, characterized by comprising a network device coupled to a network device, comprising a data processor coupled to a transmitter and receiver , and operable to send to the network device, through the transmitter, a first message composed of a list of authentication mechanisms supported by the device and, in association with each authentication mechanism, a corresponding identity, said network device comprising a processor data coupled to a transmitter and a receiver, and operable to select an authentication mechanism from the list, said device receiving from the network device, through the receiver, a first response message, the first response message comprising information belonging to the sel authentication mechanism by the network device in the list and a corresponding identity, said data processor of the Petition 870190003069, of 10/01/2019, p. 18/25 9/11 operable device to at least partially protect the integrity of the list of authentication mechanisms supported by the device, and the corresponding identities, and to send, through the transmitter, a second message to the network device, the second message comprising the list authentication mechanisms and corresponding identities, where the device comprises a mobile node and the network device comprises a boot server function, where, if authentication is successful, and if the list received in the second message matches the list received in the first message, said data processor further receives a second reply message from the network device which is at least partially protected integrity, wherein the second reply message comprises an indication of the authentication mechanism selected by the network device in question. a form of protected integrity, and the corresponding identity you. System according to claim 23, characterized in that the device is connected to the network device via a wireless connection. 25. A method for providing mobile node identities in conjunction with authentication preferences in a generic boot architecture, characterized by comprising: Send, through a mobile node, to the Initialization Server Role of a network, a first message consisting of a list of authentication mechanisms supported by a device and, in association with each authentication mechanism, a corresponding identity of a user ; and receiving, through the mobile node of the Boot Server Role, a first reply message, the first reply message comprising information pertaining to an authentication mechanism Petition 870190003069, of 10/01/2019, p. 19/25 10/11 selected by the network from the list, together with a corresponding identity; protect the integrity of at least the list of authentication mechanisms supported by the device and the corresponding identities; send a second message to the Boot Server Role, the second message comprising at least the list of authentication mechanisms and the corresponding identities; and if authentication is successful, and if the list received in the second message matches the list received in the first message, receive a second response message from the boot server role that is at least partially integrity protected, the second message from response comprising an indication of the selected authentication mechanism, and the corresponding identity, wherein the device comprises a mobile node. 26. Method according to claim 25, characterized in that the first message is sent as an HTTP GET, in which the list is included in an HTTP payload, and in which the first reply message is received as an HTTP 401 response No Authorized. 27. Method according to claim 25, characterized in that the second message is sent as an HTTP GET that comprises a response calculated according to the selected authentication mechanism. 28. Method according to claim 25, characterized in that the second reply message is received as an HTTP 200 OK message. 29. The method of claim 25, further comprising verifying that an authentication mechanism used by the device Petition 870190003069, of 10/01/2019, p. 20/25 11/11 corresponds to the authentication mechanism selected by the Boot Server Role.