Method of securing exchanges between an applicant node and a destination node

[0001] The invention relates to an authentication technique in a communication network.

[0002] This applies to the ad-hoc communication network. An ad-hoc network is a network formed by all nodes having the ability to communicate with each other without developing a permanent infrastructure. However, it is possible for the network to connect to the infrastructure, for example for access to an Internet communication network. Nodes that make up such a network can be mobile or fixed. These nodes interact and cooperate with each other, possibly based on multi-hop communication. Thus, the exchange between the reporting node and the destination node may, if appropriate, go through at least one intermediate node.

[0003] A document entitled "Kerberos Assisted Authentication in Mobile Ad-hoc

Networks "by A. Pirzad and C. McDonald, published in the materials of the" 27th Australasian Computer Science Conference "2004, describes the Kerberos authentication mechanism in an ad-hoc network. The N1 reporting node contacts the access server of another N2 node. Following successful authentication, the server transmits data, called a ticket or authentication card, protected by secret KN2 key of another N2 node, and session key KN1N1 protected by secret key KN1 of reporting node N1. The ticket contains the session key KN1N2. Therefore, the reporting node N1 receives the session key KN1N2 by decryption using the KN1 key. Then, it passes the access request to another N2 node, the request contains a ticket and data signed with the KN1N2 session key. Another N2 node decrypts the ticket using its KN2 key and obtains the KN1N2 session key. With the help of the latter, it decrypts the signed data and therefore authenticates the reporting node N1. This mechanism guarantees detection of identity theft of the reporting node, detection of attacks by repetition, establishment of secured channels and authentication of the reporting node at another node. Only the reporting node is authenticated at another node by providing authentication proof and data signed with the KN1N2 session key. If another node does not later use the KN1N2 session key obtained by decrypting its own authentication proof KN2 secret key, the reporting node has no guarantee that the other node is a trustworthy node. In addition, for multi-hop communications through at least one intermediate node, the intermediate node is not necessarily a trustworthy node.

[0004] Document "Providing Authentication and Access Control in Vehicular Network Environnement" by Hasna Moustaf et al. published in documents from the conference "IFIP TC-11 21^ST INTERNATIONAL INFORMATION SECURITY CONFERENCE, SEC 2006 ", pages 62-73, describes another authentication mechanism for establishing secure communication between vehicles.

[0005] One of the objects of the invention is to remedy the disadvantages of the prior art.

[0006] To this end, the invention proposes a method of securing the exchange between the reporting node and the destination node, said nodes belonging to one communication network, said method comprising the following steps performed by the security server:

- the stage of receiving the request sent by the reporting node for access to the target node;

- the step of sending a response to the request, said response comprising an authentication proof intended for the destination node and a session key intended for use for exchanges between the reporting and destination node, characterized in that at least one secret, to be shared with at least one another reporting node, separate from the session key, is associated with the destination node, and the response sent to the reporting node also contains the secret.

[0007] We note that the invention is derived from potential unfriendliness in an ad-hoc communication network. In any case, the invention may apply to any communication network where it is necessary to follow a secure route.

[0008] In response to a request, the server not only provides information related to the exchange between the reporting node and the destination node, such as the authentication proof for delivery to the destination node and the session key for exchanges between the reporting node and the destination node, but also the secret to sharing with at least one reporting node and associated with the destination node. Thus, depending on the destination node, a group of nodes is created containing at least the reporting node and the destination node. This group of nodes shares the secret, allowing you to improve exchange security in the group. Thus, only one request is made, allowing both permission to access the service provided by the destination node and the secret shared in the group. By performing the role of a trusted third party, the server enables the intermediate reporting node to authenticate to the destination node and provides the reporting node with a shared secret enabling it to enter into a relationship with the destination node over a secure connection. The unity of the request, respectively - of its response, allows to achieve a simple and particularly effective application. Thus, it is possible to simply send a shared secret during exchange for access to the destination node without requiring new authentication from a trusted third party. The fact that the group node has a shared secret and is able to prove it allows us to conclude that it is authenticated by default in the server. The use of shared secret also allows the use of simple and fast authentication techniques, based on symmetrical cryptography, adapted for use in nodes that may have limited resources, such as their batteries, their memory capacity.

[0009] For the use of an ad-hoc network, the destination node provides, for example, a service in a specific geographical zone. The nodes, having received the shared secret and thus authenticated by default on the server, therefore form a trusted group securing the exchange

- 3 for the destination node in a possibly multi-jump connection. The destination node may itself receive the secret through a privileged relationship with the server.

[0010] Thus, it is possible to improve the exchange security between the reporting node and the destination node in an ad-hoc communication network.

[0011] In one embodiment, the response also includes a validity period associated with said secret.

[0012] Thus, it is possible to send multiple shared secrets with which respective validity intervals are associated. The reporting node then determines the secret to use depending on the current clock. This allows you to limit requests to the server to receive important secrets and avoid simultaneous requests when the secrets are no longer valid. The shared secret is often renewed, which avoids theft of shared secret.

[0013] The invention also relates to a method of communication between a reporting node and a target node, wherein said node belongs to one communication network, said method comprising the following steps performed by the reporting node:

- the stage of sending a request to the security server for access to the destination node;

- the stage of receiving the response to the request, containing the proof of authentication, intended for the destination node and the session key, intended for use for exchanges between the reporting and destination node, characterized in that the response also contains at least one secret and said method also includes the stage authenticating at least one node using at least one said secret, and said other node is capable of connecting to the destination node.

[0014] The reporting node thus receives the secret associated with the target node shared in a group of nodes called a trusted group. It can therefore authenticate nodes with which it is in direct relationship, i.e. with its direct neighbors, by means of this shared secret and privileged authenticated neighboring nodes when exchanging with the destination node. It thus obtains the guarantee that the unfriendly node will not respond instead of the destination node and also that no unfriendly node will intervene in the chain of nodes connecting the reporting node and the destination node.

[0015] In one embodiment, the response also includes a validity period associated with said secret, and the reporting node selects a secret valid depending on the current moment.

[0016] Thus, the group nodes share a secret jointly regardless of when they forwarded the request to the server.

[0017] In another implementation method, the step of sending the access request to the destination node is performed following the detection of the lack of a valid secret.

[0018] Each time the reporting node no longer has validity secrets, it contacts the server again to maintain the duration of the trusted group.

[0019] In addition, the reporting node and the destination node communicate via a path created from authenticated nodes by means of a secret.

[0020] The invention also relates to an exchange security server between a reporting node and a destination node in a communication network, comprising:

- means of receiving the request sent by the reporting node for access to the target node;

- means of sending a response to the request, and said response contains an authentication proof, intended for the destination node and a session key, intended for use for exchanges between the reporting and destination node, characterized in that the sending means are further adapted to contain a secret response, and said secret, to be shared with at least one other reporting node, separate from the session key, is associated with the destination node.

[0021] The invention also relates to a communication network node comprising:

- means of sending a request to the server for access to the target node;

- means of receiving the response to the request, and the response contains an authentication proof, intended for the destination node and a session key, intended for use for exchanges between the node and the destination node, characterized in that the receiving means are further adapted to receive a response containing at least one the secret and said node further comprise means of authenticating at least one other node by means of said at least one secret, and said node is able to connect to the destination node.

[0022] The invention also relates to a communication system in a communication network comprising a server as described above and a plurality of nodes such as described above.

[0023] The invention further relates to a computer program containing instructions for implementing a method of securing an exchange, as described above, by a communication network server when the program is executed by the processor.

[0024] The invention also relates to a computer program comprising instructions for implementing a method of communicating with a destination node, as described above, by a reporting node of a communication network when the program is executed by the processor.

[0025] The invention also relates to a signal carrying a response to a notification for access to a destination node, sent by a reporting node, and said response is sent by a server to a reporting node and includes an authentication proof intended for the destination node and a session key intended for use for exchanges between the reporting and destination nodes, characterized in that said response also contains at least one secret and said secret, to share with at least

- one other reporting node, separate from the session key, is associated with the destination node.

[0026] The invention will be better understood by the following description of a particular embodiment of the invention, with reference to the accompanying drawings, in which:

- figure 1 shows a communication network;

- figure 2 shows part of the method steps according to a particular embodiment of the invention;

- figure 3 shows another part of the communication method according to a particular embodiment of the invention;

- figure 4 shows a request for access according to a particular embodiment of the invention;

- figure 5 shows the response to a request for access according to a particular embodiment of the invention;

- figure 6 shows in detail this response field according to a particular embodiment of the invention;

- figure 7 shows an exchange securing device according to a particular embodiment of the invention;

- figure 8 shows a node of the communication network according to a particular embodiment of the invention.

[0027] Figure 1 shows an ad-hoc network 2. It contains a plurality of nodes, designated N1 to N8. These nodes are capable of communicating with each other via wireless connections. Communication between two nodes of the ad-hoc network 2 can take place via other nodes; this is about multi-hop communication. By way of example, communication between the N1 and N4 nodes takes place via the N3 node and is represented in figure 1 by a dotted line. Similarly, communication between N2 and N8 takes place via N5 and N7, and communication between N2 and N6 takes place via N5. These nodes can be mobile or fixed.

[0028] Each node N1-N8 of the ad-hoc network 2 has its own secret key KN1-KN8.

[0029] Next, nodes N1 and N2 perform the special role of the application delivery node. It is an ad-hoc network node 2, which remains, for example, constant with which other nodes of the ad-hoc network can communicate to access a given service or application. By way of non-exhaustive examples, it is about downloading audiovisual content, posting audiovisual content or "video streaming", printing ...

[0030] The Serv security server belongs to the core network 1 of the communication operator. This Serv security server is built to authenticate nodes of the ad-hoc network and provide them with proof of their authentication so that they can access the applications proposed by the N1 and N2 application delivery nodes. The Serv security server is built to remember the identifiers of the nodes allowed for access to the ad-hoc network. Each node identifier is associated with

- 6 his secret key. Then, the Serv security server uses the Kerberos protocol, as described in the Internet Engineering Task Force RFC 4120 document entitled "The Kerberos Network authentication Service". It acts as a trusted third party. It includes two units: the first unit fulfilling the role of the authentication unit, marked AS for "Authentication Server" and the second unit fulfilling the role of server sending tickets, marked TGS for "Ticket Grant Service".

[0031] The AP allows the nodes of the ad-hoc network 2 to access the core network 1 and thus to communicate with the security server Serv. Then, the AP is built to act as a Kerberos proxy, as described in the IETF document "draft-ietf-krb-wg-iakerb-00".

[0032] The exchange securing method, such as that used by the security server, will now be described with reference to figure 2.

[0033] A communication method such as that used by the reporting node will also be described with reference to figures 2 and 3.

[0034] In the example described, the user of the node from the applicant N4 wants to communicate with the node providing the N1 application.

[0035] The reporting node N4 detects in a first step E1, designated "S_RAS (NF)" in figure 2, that there is no secret of ongoing validity to communicate in the ad-hoc network 2 or that there is no validating proof of validity for N1 application delivery node. The secret is associated with the N1 application delivery node and is intended to be shared by a group of nodes in the ad-hoc network communicating with the latter. The authentication proof is intended to be delivered to the N1 application delivery node and gives it proof that the N4 reporting node has been authenticated in the Serv security server.

[0036] Always during this step E1, the reporting node N4 forwards the request M1 to the security server Serv for access to the delivery node of the application N1. This is the AS-REQ message in the Kerberos protocol.

[0037] The exchange takes place via an AP that uses a delegation mechanism (or "Kerberos Proxy" function in English). In any case, to simplify the description and figure 2, the individual exchanges have not been decomposed.

[0038] This M1 request is received by the Serv security server, and more specifically by the AS unit, in the receiving step F1, designated "R_RAS (NF)" in figure 2.

[0039] After verifying the identifier of the N4 reporting node, the AS of the security server Serv transmits in step F2, designated "S_RepAS" in Figure 2, an M2 message responding to the request for access to the supply node of the N1 application including, according to the Kerberos protocol:

- the first TTGS ticket and

- the first Ksession session key encrypted using its own secret KN4 key N4 reporting node.

[0040] The Kerberos protocol is an AS-REP message.

[0041] This first TTGS ticket is encrypted by the AS unit of the security server Serv using the key Ktgs. In particular, it contains information about the N4 reporting node, but also the first Ksession session key intended for use by the latter to obtain authentication proof.

[0042] The M2 message responding to the request for access to the supply node of the N1 application is received by the reporting node N4 in step E2, designated "R_RepAS" in figure 2.

[0043] After completing this exchange of M1 and M2 messages, the reporting node N4 has the first TTGS ticket that it cannot decrypt and the first Ksession session key. If the N4 reporting node is not the one it claims to be, it is not possible to decrypt the first Ksession session key, because only the real N4 reporting node has the secret KN4 key to decrypt the first Ksession session key.

[0044] In step E3, designated "S_RTGS" in Figure 2, the reporting node N4 forwards the request of the authentication proof M3 to the security server TGS unit M3. The Kerberos protocol is a TGS-REQ message. This M3 request contains the first TTGS ticket forwarded by the Serv server AS in the M2 message responding to the request for access to the N1 application delivery node, as well as information protected by the first Ksession session key.

[0045] The M3 authentication proof request is shown in figure 4.

[0046] Such request 100 includes, according to RFC 4120:

- field 102, indicating the Kerberos version;

- field 104 indicating the type of the message;

- field 106 containing the data for the initial authentication;

- field 108 containing the content of the message.

[0047] Box 108 contains, including N4 reporting node identifier and tags 110 to indicate the bearer or not the protocol options. In a particular embodiment of the invention, the tag allows the reporting node N4 to signal that its request also seeks to obtain the secret associated with the delivery node of the N1 application. This ensures compatibility with a server using the classic Kerberos protocol and also distinguishes between nodes that carry these options and nodes that do not.

[0048] This M3 authentication proof request is received by the security server TGS unit Serv in step F3, designated "R_RTGS" in figure 2.

[0049] In step F4, designated "Auth" in figure 2, the security server TGS unit decrypts the first TTGS ticket using its own secret Ktgs key. He then receives the first Ksession session key and can therefore decrypt the information provided by the N4 reporting node. This allows her to authenticate

- 8 default N4 reporting node, because the latter provides it with proof when it has the KN4 key. The TGS entity then determines the second KN1N4 session key to be used, as appropriate, for subsequent exchanges between the N1 application delivery node and the N4 reporting node. The TGS unit also specifies the authentication evidence to allow access to the N1 application delivery node. This authentication evidence contains the second KN1N4 session key and is protected by the secret KN1 key of the N1 application delivery node.

[0050] In test step F5, designated "Test_F" in figure 2, the TGS entity checks if the request M3 includes in field 110 a flag indicating that the request is also intended to obtain a shared secret.

[0051] If such a tag is present, in step F6, designated "Det_Kad" in figure 2, the TGS entity specifies the secret Kad associated with the N1 application delivery node to which the N4 requesting node wants access and intended to be shared by the group nodes of the ad-hoc network 2.

[0052] In step F7, designated "S_RepTGS" in Figure 2, the TGS entity forwards the requesting node M4 with an M4 response to the request containing:

- authentication proof for delivery to the N1 application delivery node, as defined in step F4, protected by the secret key KN1 of the N1 application delivery node;

- a second session key, KN1N4, intended for use for exchanges between the N4 reporting node and the N1 application delivery node, specified in step F4, protected by the first Ksession session key;

- if the flag signaling that the request is also intended to obtain a secret is present in the request M3, the shared secret Kad specified in step F6, protected by the first session key Ksession.

[0053] This M4 response to the request of the authentication proof is shown in figure 5. The Kerberos protocol is a TGS-REP message.

[0054] Such a response 200 comprises according to RFC 4120:

- field 202 indicating the Kerberos protocol version;

- field 204 indicating the type of the message;

- field 206 containing data for pre-authentication;

- field 208 containing the domain of the reporting node;

- box 210 containing the name of the applicant's node;

- field 212 containing the authentication proof for delivery to the node providing the N1 application;

- field 214 containing data protected by encryption with the first session key Ksession known simultaneously by the TGS unit and the reporting node N4.

[0055] The encrypted data contained in field 214 is shown in figure 6. They contain in particular:

- second session key 216 KN1N4;

- 9 - field 218 containing markers to enable signaling the carrier or not of the protocol option; in a particular embodiment of the invention, the tag allows the Serv security server to signal that the secret is contained in data string 214;

- field 222 containing the secret Kad depending on the value of the tag for the shared secret mentioned above.

[0056] In an implementation variant, the secret validity time interval associated with the secret Kad is transmitted in field 220.

[0057] The M4 response is received by the reporting node N4 in step E4, designated "R_RepTGS" in figure 2.

[0058] After the M3 and M4 message exchange is completed, the reporting node N4 has an authentication proof to be delivered to the delivery node of the N1 application which it cannot decrypt, the second session key KN1N4 and the shared secret Kad in the node group of the ad-hoc network 2.

[0059] It should also be noted that in the case of multi-hop communication, when the N4 reporting node passes the authentication proof to the N1 application delivery node, no intermediate nodes that contribute to the circulation of the authentication proof can decrypt it and therefore cannot obtain the second KN1N4 session key . As a result, the authentication proof is protected by encryption using the secret key KN1 of the N1 application delivery node and cannot be decrypted by any or any node.

[0060] The reporting node N4 has a shared secret Kad, so it has the ability to apply an authentication step for each node with which it is in direct relationship, i.e. neighboring nodes. It is understood as a neighboring node, a node located in the radio coverage area of ​​the N4 reporting node. Reporting node N4 presents the shared secret Kad to a neighboring node as proof of authenticity, and the neighboring node also proves its authenticity by presenting the same key. For example, EAP-PSK mutual authentication using Kad shared secret. This type of authentication presents the advantage of requesting limited processing resources.

[0061] This authentication mechanism is described in RFC 4764 IETF. It is described briefly with reference to figure 3.

[0062] Reporting node N4 forwards the L1 identity request message of the neighbor N3, for example "EAP-Request Identity". The neighbor N3 communicates its Idv identity to the reporting node N4 in the L2 message, for example "EAP-Response Identity". In the L3 message, for example "EAP-Request / PSK", the reporting node N4 passes its own Idd identity as well as the randomly selected Rd variable it generated to the neighboring node N3. The neighbor N3 determines the randomly selected Rv variable, calculates the first MAC authentication code based on all data (Idv, Rv, Idd, Rd) signed by the shared secret Kad and passes its Idv identifier, randomly selected Rv variable and the first authentication code to the N4 reporting node. MAC in the L4 message, for example "EAP-response / PSK". The reporting node N4 verifies

- the first MAC authentication code using the shared secret Kad for authentication of the neighbor N3. Then, the reporting node N4 forwards in the L5 message, for example "EAP_Request / PSK", to the neighboring N3 node randomly selected Rd variable, as well as the second MAC authentication code calculated on the basis of the whole created by its Idd ID and randomly selected variable Rv, signed with the secret shared staff. The neighbor N3 verifies the second MAC authentication code using the shared secret Kad and forwards the L6 message to the reporting node N4, for example "EAP-Response / PSK" which contains a randomly selected Rd variable. A L7 message, for example "EAP-Success" on success, passed from reporting node N4 to neighbor N3 completes the authentication step.

[0063] It is therefore possible to favor, for the circulation of messages between the reporting node N4 and the application delivery node N1, the nodes of the ad-hoc network 2 belonging to the group sharing the secret Kad. As a result, it is possible to construct the paths used by the routing protocol using a security metric. Such a mechanism is described, for example, in the article entitled "Secure Routing for Mobile Ad-hoc Networks" by P. Argyroudis and D. O'Mahony, published in the IEEE Communications Survey, 3rd quarter 2005. This article describes the "Secure Ad-hoc Routing" SAR mechanism used for reactive routing protocols, such as the "Ad-hoc On-Demand Distance Vector AODV" protocol "Or the DSR" Dynamic Source Routing "protocol, which integrates security metrics in Route Request messages to construct paths between nodes having a specific level of security.

[0064] The reporting node N4 thus forwards its request for access to the application delivery node by presenting its authentication proof, which, as a reminder, is protected by the secret key KN1 of the application delivery node N1. The access request is therefore forwarded by the OSI layer 3 routing protocol. The N3 intermediate node receiving the access request cannot decrypt the authentication proof and changes that request by selecting the neighboring node depending on the authenticity of its neighbors. This is repeated until the N1 application delivery node, which by decrypting the authentication card with its own secret key KN1, receives the second session key KN1N4. The authentication proof proves that the reporting node N4 is properly authenticated in the Serv. Security server. An authentication proof is therefore sent to the node providing the N1 application via a path created from authenticated nodes using a shared secret. The N1 application delivery node may therefore provide the requested service by protecting traffic using the second KN1N4 session key. Subsequent exchanges between the N4 reporting node and the N1 application delivery node also borrow this path or any other path created from nodes authenticated by a shared secret.

[0065] In another embodiment of the invention, following the receipt of the request sent by the reporting node N4 in step F1, the TGS entity determines during the step F6 a plurality of shared secrets and associates a validity period with each shared secret.

- 11 secrets. Each shared secret, Kad, therefore has a limited duration of D. The server forwards, in step F7, all important shared secrets for subsequent periods.

[0066] A response is received at step E4 by reporting node N4.

[0067] Then, when it needs to authenticate one of its neighbors, the reporting node N4 selects a valid shared secret depending on the current moment.

[0068] Thus, because the Serv security server distributes many keys during a request for access to the destination node, the nodes ask the server less often and additionally these requests are performed in a desynchronous manner.

[0069] We will now describe a server for securing the exchange between the reporting node and the destination node in the communication network with reference to figure 7.

[0070] Such server 300 has:

- memory means 308, designated "KN" in figure 7, constructed to remember secret keys appropriately associated with communication network nodes;

- request receiving module 302, designated "Rec_S" in figure 7, the request is sent by the reporting node for access to the destination node;

- a data determination module 310 for access to the target node, designated "Det_PK" in Figure 7, constructed to specify the authentication proof intended for the reporting node and the session key intended for use during exchange between the reporting node and the destination node ;

- a module receiving 306 at least one shared secret, designated "Det_Kad" in figure 7, the secret is associated with the destination node and shared in a group of nodes containing at least one reporting node separate from the session key;

- the encryption / decryption module 312, designated "C / D_S" in figure 7, built to encrypt the data intended for the node depending on its respective secret key extracted from storage means 308 or depending on the session key shared between the node and the server, and to decrypt received data protected by a session key;

- request response sending module 304, designated "S_S" in Figure 7, said response includes the authentication proof intended for the destination node, the session key, intended for use for exchanges between the reporting and destination node, and at least one secret received.

[0071] In a particular embodiment of the invention, the data determination module 310 for access to the destination node uses Kerberos steps.

[0072] In a variation of the described implementation method, the secret receiving module 306 also receives an associated validity period. In this case, the send module 304 also transmits the associated validity period in response.

[0073] We will now describe a node of the communication network with reference to figure 8.

[0074] Such node 400 includes:

- sending module 402, designated "S_N" in figure 8, requests to the server for access to the destination node;

- a response response receiving module 404, designated "Rec_N" in figure 8, the response includes the authentication proof intended for the destination node, the session key intended for use for exchanges between the node and the destination node, and at least one shared secret;

- the encryption / decryption module 410, designated "C / D_N" in figure 8, built to decrypt data depending on its respective secret key or depending on the session key shared between the node and the server and for data encryption using the session key;

- authentication module 406, designated "Auth" in figure 8, at least one other node by means of at least one said secret, said other node is able to connect to the destination node;

- a path determination module 408 in the communication network, designated "Det_R" in figure 8, built to specify the path to the destination node giving privilege to authenticated nodes.

[0075] In a variant of the described implementation method, the receiving module 404 is built to receive a validity period associated with the shared secret, and the authentication module 406 is built to determine a valid shared secret depending on the current moment.

[0076] Security server modules 302, 304, 306 are built to use the method of securing the exchanges described above. These are in particular software modules containing software instructions for performing the steps of the protection method described above used by the communication network server. The invention therefore also relates to:

- a program for a communication network server containing program instructions intended to order the steps of the method for securing the exchanges described above when said program is implemented by a processor;

- a readable recording medium for the communication network server on which the program for the communication network server is recorded.

[0077] The modules 402, 404, 406 of the communication network node are structured to use the method of communication with another node described above. These are in particular software modules containing software instructions for causing the steps of the method of communication described above to be performed by a node of the communication network. The invention therefore also relates to:

- a program for a communication network node containing program instructions for ordering the steps of the above described method of communication when said program is implemented by a processor;

- a readable recording medium for a communication network node on which a program for a communication network node is recorded.

[0078] The software modules may be stored in or transferred on a data carrier. It may be a physical storage medium, for example a CD-ROM, magnetic floppy disk or hard disk, or even a transmission medium such as an optical or radio electric signal or a telecommunications network.

[0079] The invention also relates to a communication system in a communication network, comprising a server for securing exchanges and a plurality of nodes such as those described above.

[0080] The description was made taking into account the shared secret associated with the N1 application delivery node. In another variant, it is also possible to share such a secret across the entire ad-hoc 2 network and associate it with all application delivery nodes.

[0081] The description was made in a particular case of a security server comprising two AS and TGS units. It is also possible to design a server for each unit.

[0082] The description has also been made in the particular case of the application delivery node. It is of course understood that the inventive methods apply to each destination node with which the reporting node wants to communicate.

[0083] The invention can also be implemented by other types of mechanisms in which the security server forwards the authentication evidence provided by the reporting node to the application delivery node.

[0084] Message exchanges have been described in a sequential manner. It is also possible to separate M1 (request for access to the N1 application delivery node) and M2 (reply to M1 request) messages from these two messages M3 (M3 authentication request request) and M4 messages (M4 request reply).

[0085] In yet another variant, it is also possible, if the first session key Ksession has an associated validity period, to directly send M3 authentication proof request.

[0086] The description was also made as part of an ad-hoc network. The application of the invention need not be limited to this type of network. It can also be applied to any type of communication network in which a node wants to establish a path determined via trusted nodes.

Prepared and verified

Grażyna Palka Patent Attorney