RU2390959C2 - Method and device of host unit identification protocol - Google Patents

Abstract

FIELD: information technologies.

SUBSTANCE: from the first host-unit (Initiator) to the second host unit (Respondent) message of authentication (I2') is sent (S2), which contains identifier (HIT) of the first host unit (Initiator) and cryptographic element (PF). Message (I2') of authentication is received (S3) in the second host unit (Respondent). After reception identifier and information related to general condition are used (S4) to authenticate cryptographic element (PF). If cryptographic element and remaining part of authentication message are authenticated, then from the second host unit (Respondent) to the first host unit (Initiator) confirmation message (R21) is sent to demonstrate successful authentication. These two messages (I2' and R2') are equivalent to messages I2 and R2 of standard HIP basic exchange protocol, and there is no necessity in messages I1 and R1 from protocol of basic exchange of standard HIP.

EFFECT: reduced traffic in process of unit identification.

46 cl, 5 dwg

Description

FIELD OF THE INVENTION

The invention relates to a method and apparatus for a Host Identity Protocol (HIP).

State of the art

When the Internet was originally developed, the host nodes were stationary and there was an implicit trust between users, despite the lack of genuine security or host identification protocols, and this situation remained unchanged even after the wider adoption and use of technology. At that time, there was no need to consider ways to solve issues related to host host mobility, since computers were relatively bulky and stationary.

Given the challenges of mobility and security management, the Mobile IP standard (see C. Perkins, IP Mobility Support for IPv4, RFC 3220, IETF, 2002) and the Mobile IPv6 standard (see D. Johnson, C. Perkins, J. Arkko, "Mobility Support in IPv6", RFC3775, IETF, 2004). Together, these specifications will provide mobility support for the next generation Internet. Security work is under development in the form of IPsec and related activities, such as various key exchange protocols, to provide security at the IP level. However, experience has shown that, using existing standards, it is difficult to achieve a combination of security and mobility.

The IP address describes the topological location of the node on the network. The IP address is used to route the packet from the source node to the destination node. At the same time, the IP address is also used to identify the host, providing two different functions in the same entity. It is like a person calling his home address in response to a question of who he is. When mobility is also considered, the situation becomes even more complicated: since in this scheme IP addresses act as host identifiers, they must remain unchanged. However, since IP addresses also describe topological locations, they must change when the host changes its location on the network. It goes without saying that it is impossible to simultaneously ensure stability and dynamic change.

One solution to this problem is to separate the identification and location functions from each other, and this approach underlies the proposal of the Host Identity Protocol (HIP) (see R. Moskowitz, P. Nikander, P. Jokela, " Host Identity Protocol ", Internet Draft, work in progress, draft-ietf-hip-base-02, IETF, 2005). HIP separates the roles of location and identification of IP addresses by introducing a new namespace - Host Identity (HI). In the HIP protocol, HIs essentially represent a common cryptographic key from a shared-personal cryptographic key pair, this key being generated from the private key and associated with it. The shared key identifies the party that holds a single copy of the private key. A host that owns a private key from a cryptographic pair can directly prove that it "owns" a shared key, which is used to identify it in the network. Separation also provides a means for handling mobility and multicast in a secure manner.

HIP is described in more detail below, but this is not the only proposal based on the idea of separation of location and identification. The FARA Architecture (see D. Clark, R. Braden, A. Falk, V. Pingali, "FARA: Reorganizing the Addressing Architecture", ACM SIGCOMM 2003 Workshops, August 25 & 27, 2003) is a general idea model that provides the structure from which the actual architecture can be derived. FARA can use HIP when host identifications change, and therefore, HIP can be part of a specific implementation of FARA. The PeerNet proposal (see J. Eriksson, M. Faloutsos, S. Krishnamurthy, "PeerNet: Pushing Peer-to-Peer Down the Stack", IPTPS '03, February 20-21, 2003) also addresses the separation of location and identification. The Internet Indirection Infrastructure, I ³ (see I. Stoica, et.al., "Internet Indirection Infrastructure", ACM SIGCOMM '02, August 19-23, 2002) also defines the separation between identification and routing information.

HIP represents the separation between location information and authentication at the IP layer. In addition to separation, the protocol negotiates Security Associations (SAs) between nodes with the HIP function.

With HIP, each host has one or more identifications that can be long-term or short-term, and which can be used to identify it on the network. With HIP, an identifier is a shared key from a cryptographic public / private pair. When a host has a private key, it can prove that it really "owns" this identity, represented by a shared key; this is similar to how the identification card is shown.

Being a common key, HI can be quite long and therefore impractical in all situations. In HIP, the HI is represented by the Host Identity Tag (HIT), which is generated from the HI by hashing it. Accordingly, there is a slight risk of conflict that two HIs will be hashed into the same HIT. Thus, the HIT tag identifies the HI. Given that the HIT is 128 bits long, it can be used directly for IPv6 applications since it has the same length as IPv6 addresses.

Another HI representation is the Local Scope Identifier (LSI), which is a 32-bit representation for the HI. The purpose of LSI is to facilitate the use of HI in existing protocols and Application Program Interfaces (APIs). For example, since LSI is the same length as IPv4 addresses, it can be used directly for IPv4 applications. Although most of this description is based on the use of a longer HIT, it is clear that the same or similar considerations apply to an alternative representation of LSI.

When HIP is used, the upper layers, which include applications, no longer see IP addresses. Instead, they see the HIT as the "address" of the destination host. Location information is hiding at a new level, which is described below. IP addresses no longer identify hosts; they are used only for routing packets on the network.

Applications, as a rule, are not interested in location information, and they need to know the identity of their peers. Identification is represented by HIT. This means that an IP address only matters at the lower layers where routing is affected. The HITs that are used by applications must be mapped to the corresponding IP addresses before any packet leaves the host. This is achieved in the new Host Identity Layer, as described below.

1 of the accompanying drawings illustrates various layers in HIP, including standard transport layer 4, network layer 8, and link layer 10, where the application or process 2 communicates with transport layer 4 below it. With HIP, a new Host Identity Layer 6 is placed between transport layer 4 and network layer 8.

Locally, each HI and its associated HIT are mapped to the host IP addresses. When packets leave the host, the correct route is selected (by some means), and the corresponding IP addresses are inserted into the packet as source and destination addresses. Each packet coming from the upper layer contains the peer HIT as the destination address. A mapping between HIT and location information can be found at Host Identity Level 6. Therefore, the destination address is mapped to the associated IP address, and the source HIT is mapped to the source IP address.

HIP defines a basic messaging containing four messages (four-pass handshake), and this is used to create Secure Associations (SAs) between hosts with the HIP feature. During the messaging, the Diffie-Hellman procedure is used to create a session key and to establish a pair of IPsec Encapsulating Security Payload (ESP) Security Associations between nodes.

Figure 2 of the accompanying drawings illustrates the operation of a four-pass handshake. Talking parties are referred to as the Initiator initiating the connection and the Respondent. The initiator begins the negotiation by transmitting an I1 packet that contains the HIT labels of the nodes involved in the negotiation. The HIT assignment may be reset if the Initiator is not aware of the Respondent's HIT.

When the Respondent receives the I1 packet, he sends back the R1 packet, which contains the puzzle that the Initiator must solve. The protocol is designed so that the Initiator must perform most of the calculations during the solution of the puzzle. This provides some protection against Denial of Service (DoS) attacks. Package R1 also contains the HIT labels of the nodes involved in the negotiation. In addition, the R1 packet initiates a Diffie-Hellman procedure containing the Responder Host Identity PK _R shared key, along with Diffie-Hellman parameters including the Diffie-Hellman Responder public key DH _R.

Upon receipt of packet R1, the Initiator solves the puzzle and transmits the Respondent in packet I2, which includes the solution together with the IPsec SPI value and its shared key Host Identification PK _I , encrypted using the session key that was built with the newly received shared key Diffie-Hellman Responder DH _R (although in the standard HIP protocol, encryption of the shared key PK _{I of the} Host Identification becomes optional). Package I2 also contains the HIT tags of the nodes involved in the negotiation, as well as the DH _I Diffie-Hellman Initiator key. Defendant verifies that the puzzle has been solved, authenticates that the sender of the message is the initiator, by verifying that the message signature was created by the private key corresponding to the public key PK _I Identification Initiator host, and creates multiple IPsec ESP SA. The last R2 message contains the value of the Respondent Security Parameter Index (SPI) and the HIT label of the nodes involved in the negotiation. Obviously, the creation of IPsec ESP SA is becoming optional in the standard basic HIP exchange.

In addition to packets I1, R1, I2 and R2, the HIP specification defines other packets, including the UPDATE packet. When there is an active HIP connection between two communicating hosts with the HIP function, the UPDATE packet can be used to update the overall status. For example, the UPDATE package is used to update Secure ESP Links. Extensions to the basic HIP specification exist, such as the HIP Mobility and Multi-homing protocols (see P. Nikander, J. Arkko, P. Jokela, "End-Host Mobility and Multihoming with Host Identity Protocol", Internet Draft, work in progress, draft-ietf-hip-mm-01, IETF, 2005), which use UPDATE packages for various purposes. Notably, the HIP host ignores and discards UPDATE packets if it does not have any active HIP communication with the sender of the UPDATE packet.

SA communications between host nodes are tied to Host Identities represented by HIT tags. However, the data packets passing through the network do not contain valid HI information, and the incoming packet is identified and matched by the correct SA using the SPI value in the IPsec header. Figure 3 of the accompanying drawings illustrates the logical and actual structure of the packet when it moves on the network.

From the foregoing, it is clear that changing location information in a packet does not pose any problems for IPsec processing. The package is also correctly identified using SPI. If for any reason the packet is routed to the wrong destination, the receiver will not be able to open the packet because it does not have the correct key.

When an outgoing packet arrives at the HI layer from a higher layer, the destination HIT is verified from the IPsec Security Association Database (SADB). If an SA corresponding to the HIT destination is detected, then the packet is encrypted using the session key associated with the SA.

HIT cannot be used to route a packet. Thus, the destination (and source) addresses must be changed to match the IP addresses of the nodes. As mentioned earlier, these mappings are stored at the HI level. After changing the addresses, the packet can be transmitted to the network, where it is routed to the destination using the IP address information.

At the receiving host, the SPI value is used to find the correct SA from the IPsec SADB. If a record is found, then the IP addresses can be changed to the corresponding HIT tags, and the packet can be decrypted using the session key.

In HIP, the separation between location information and identification information implies that packet identification and routing can be clearly separated. The host receiving the packet identifies the sender by receiving the correct key and then decrypting the packet. Thus, the IP addresses that are included in the packet are irrelevant.

Other technical issues arise when implementing HIP in third generation mobile communication networks (3 ^rd Generation, 3G), where not all User Equipment in 3G environment has HIP function. In this context, the Universal Mobile Telecommunications System (UMTS) is the 3G successor to the Global System for Mobile Communications (GSM). The most important evolutionary step from GSM to UMTS is the General Packet Radio Service (GPRS). GPRS represents packet switching to the GSM core network and provides direct access to Packet Data Networks (PDNs). This enables switched packet transmission over the GSM core network at a speed that is much higher than the ISDN limit of 64 kbit / s, which is necessary for transmission speeds of 2 Mbit / s or more for UMTS. GPRS is a prerequisite for the presentation of UMTS. Similar principles apply equally to both UMTS and GPRS. GPRS was developed as an extension of the existing GSM network infrastructure to provide packet data services without the need for a connection. Compared to GSM, GPRS introduces several new functional elements that support end-to-end IP-based packet data transfer.

As mentioned above, the complete base exchange protocol is a four-message protocol and two round-trip cycles. The Hi3 sentence (see Internet Draft, work in progress, draft-nikander-hiprg-hi3-00.txt) proposes to reduce by one number of round-trips at the end of the Responder by storing the pre-computed message R1 in the intermediate box and by allowing to the intermediate box to respond to I1 messages directly, thereby reducing the total number of messages that the responder sees to I2 and R2, that is, to two messages and one round trip. However, this decision does not change the position at the end of the Initiator.

When looking at the initiator's wireless HIP core exchange, two round-trip loops in the full HIP core protocol can lead to a performance problem. The Initiator must wait for the completion of two round trips before it can communicate with the Responder, which is a potential performance bottleneck. It would be desirable to reduce the number of messages required, and thus reduce the delay in establishing a session.

According to a first aspect of the present invention, there is provided a method of a modified basic exchange of a Host Identity Protocol (HIP) comprising one loop and two messages for use by the first and second HIP hosts having a common state from a pre-existing relationship, comprising the steps on which: transmit from the first host to the second host an authentication message containing the identifier of the first host and a cryptographic element; receiving an authentication message at the second host and using the identifier and general state information to authenticate the cryptographic element; and after successful authentication of the cryptographic element, a confirmation message indicating successful authentication is transmitted from the second host to the first host. The identifier may be a HIP identification tag. The HIP identification label may be a Host Identity Tag (HIT) or a Local Scope Identifier (LSI).

Authentication of a cryptographic element may include verification of the source of the cryptographic element.

The method may include retrieving general status information using the received identifier.

The method may comprise the step of generating or selecting a cryptographic element using general state information.

A cryptographic element can be obtained from performing a cryptographic function.

A cryptographic function may have at least an identifier as input.

The cryptographic function may be a hash function.

The general state information may contain at least the last used item from the hash chain generated from the hash function, and the method may include selecting the next unused item in the hash chain for use as a cryptographic element.

The cryptographic element can be authenticated by computing a hash function using the received identifier and the received cryptographic element, and by comparing the result with at least the last used element.

The hash chain can be pre-generated, and at least the unused elements in the hash chain can be stored in the first host or be available to him.

A hash chain may be generated as a result of a pre-existing relationship.

A hash chain can be allocated for interactions between the first and second host nodes.

A hash chain may be allocated for interactions between the first host nodes and a plurality of such second host nodes.

The general state information may comprise secret information exchanged between the first and second host nodes as a result of a pre-existing relationship.

Secret information may contain a cryptographic key.

Secret information can be used as input to a cryptographic function.

The cryptographic element can be authenticated by calculating the cryptographic function using the received identifier and the received secret information, and by comparing the result with the received cryptographic element.

A time stamp can be used as an input to a cryptographic function.

The counter may be used as input to a cryptographic function, and the method may comprise the step of incrementing the counter.

The authentication message may include a time stamp and / or counter, and the cryptographic element is authenticated by calculating the cryptographic function using the received time stamp and / or counter, and by comparing the result with the received cryptographic element.

General state information may be stored in a second host.

The method may include retrieving general state information from a remote server.

General state information stored on a remote server can be protected from modification by unauthorized parties.

The method may comprise the step of sending at least a portion of the authentication message to a remote server to retrieve general status information. The authentication message may contain the Diffie-Hellman common key of the first host.

The authentication message may contain a shared Host Identity key of the first host.

The confirmation message may contain a Diffie-Hellman public key of the second host.

The method may include the step of signing a confirmation message using the private key of the second host.

The method may include the step of verifying the signature in the first host using the shared Host Identity key of the second host.

The shared Host Identity key of the second host can be known to the first host as a result of a pre-existing relationship, or it can be accessed from a remote server.

The method may include the step of creating a HIP Security Association between the first and second host nodes after receiving a confirmation message in the first host.

A previously existing relationship can be derived from a previously performed standard procedure for a basic HIP exchange between the first and second host nodes.

The method may comprise determining whether the authentication message is a standard basic HIP exchange message I2 or not.

The method may include the step of distinguishing the authentication message from the standard basic HIP exchange message I2 by determining the HIP parameter associated with the cryptographic element.

The method may include the step of distinguishing the authentication message from the standard basic HIP exchange message I2 based on one or more of the following parameters: type of HIP packet; HIP protocol version field a bit or some combination of bits from the backup field of the HIP header; HIP management in the header control field; a variety in one or both of the identifiers of the first and second host nodes; and the IP protocol used.

According to a second aspect of the present invention, there is provided a communication system for executing a modified basic HIP exchange method, comprising one cycle and two messages, between the first and second HIP hosts of the system having a common state from a pre-existing relationship, the first host comprising means for transmitting in the second host, an authentication message containing the identifier of the first host and a cryptographic element; and the second host node comprises means for receiving an authentication message and for using the identifier and information related to the general state to authenticate the cryptographic element; and means for transmitting to the first-host node a confirmation message that indicates successful authentication, said transfer being performed after successful authentication of the cryptographic element.

According to a third aspect of the present invention, there is provided a modified HIP basic exchange method, comprising one cycle and two messages, for use by a HIP Initiator host having a common state from a pre-existing relationship with a HIP Responder host, comprising transmitting to the host a HIP Responder node an authentication message containing an identifier of a HIP Initiator host node and a cryptographic element, wherein the authentication message is intended to be used at a HIP Responder host node to authenticate to authenticate the cryptographic element using the identifier and general state information so that after successful authentication of the cryptographic element, a confirmation message indicating successful authentication can be transmitted to the HIP Initiator host.

According to a fourth aspect of the present invention, there is provided an apparatus for performing, as a HIP Initiator host, a modified HIP basic exchange method comprising one cycle and two messages with a HIP Responder host with which the HIP Initiator host has a common state from previously an existing relationship, comprising means for transmitting an authentication message containing a HIP Initiator's host ID and a cryptographic element to the HIP Responder's host, and the authentication message is intended to To use the HIP at the Responder's host to authenticate the cryptographic element using identifier and general state information, so that after successful authentication of the cryptographic element, a confirmation message can be sent to the HIP Initiator's host, indicating successful authentication.

According to a fifth aspect of the present invention, there is provided a modified basic HIP exchange method, comprising one cycle and two messages, for use by a HIP Responder host having a common state from a pre-existing relationship with a HIP Initiator host, comprising the steps of receiving from the host the HIP Initiator node an authentication message containing the identifier of the HIP Initiator host node and the cryptographic element use the identifier and the general state information to authenticate the ptographic element, and after successful authentication of the cryptographic element, a confirmation message indicating successful authentication is transmitted to the HIP Initiator host.

According to a sixth aspect of the present invention, there is provided an apparatus for executing, as a HIP Responder host, a modified HIP basic exchange method, comprising one cycle and two messages, with a HIP Initiator host with which the HIP Responder host has a common state from previously an existing relationship, comprising means for receiving an authentication message from the HIP Initiator's host containing the HIP Initiator's host ID and a cryptographic element to use the identifier and information regarding Generalized to authenticate the cryptographic element and to, after successful authentication of the cryptographic element, send a confirmation message to the HIP Initiator host that indicates successful authentication.

According to a seventh aspect of the present invention, there is provided an operating program which, when executed on a device, causes the device to execute a method according to the third or fifth aspect of the present invention.

According to an eighth aspect of the present invention, there is provided an operating program which, when downloaded to a device, causes the device to become a device according to the fourth or sixth aspect of the present invention.

The operating program may be contained on a medium. The medium may be a transmission medium. The medium may be a storage medium.

Brief Description of the Drawings

Figure 1 is an illustration of the various levels in the Host Identification Protocol;

Figure 2 - illustration of the four-pass handshake in the HIP protocol;

Figure 3 is an illustration of the logical and valid packet structures in HIP;

Figure 4 is an illustration of a review of a modified basic HIP exchange method according to the present invention; and

5 is a more detailed illustration of a modified basic HIP exchange method according to the present invention.

As described above, it was found advisable to reduce the number of necessary messages in the basic HIP exchange procedure, where possible, and it was determined that there is a potential possibility to delete the exchange of original messages, that is, messages I1 and R1, as described below.

I1 is essentially a trigger message that requests a fresh message R1. The R1 message itself provides three separate functions:

First, it provides the Initiator with the common key PK _R Identity of the Responder's Host.

Secondly, it provides the Initiator with a puzzle, so that the Initiator can show the “honesty” to the Respondent by solving the puzzle.

Thirdly, it provides protection against attacks on the principle of preliminary calculation and repeated reproduction by providing the Initiator with a puzzle that can be verified by the Respondent as freshly generated and not created long ago.

In the event that the Initiator and the Respondent do not have any pre-existing relationship, improvement is unlikely; The Initiator should receive a fresh message R1 so that he can show the Respondent his “honesty” and the freshness of the exchange.

However, if there is a pre-existing relationship between the Initiator and the Respondent, then there is the potential for improvement, and this approach is adopted in an embodiment of the present invention.

FIG. 4 is an overview diagram illustrating a modified HIP core exchange method according to an embodiment of the present invention. From a comparison of FIGS. 2 and 4, it can be seen that this method, an embodiment of the present invention, is almost consistent with the standard HIP basic exchange method, but in this embodiment of the present invention, steps I1 and R1 of the standard HIP basic exchange method are not performed. In addition, the puzzle solution in message I2 is replaced by a new HIP parameter called Paired Freshness (PF), which contains a fresh cryptographic element. The source of the cryptographic element is verified by the Respondent using information related to the general state resulting from a pre-existing relationship between the Initiator and the Respondent. The exact form of the cryptographic element and general state information varies, as described below with reference to specific embodiments of the present invention. Moreover, it is noteworthy that the general state can be asymmetric in the sense that the Initiator and the Respondent can hold different pieces of information, and the relationship between these pieces of information can be cryptographic.

5 corresponds to FIG. 4, but illustrates in more detail the steps performed in an embodiment of the present invention and messages exchanged between the initiator and the Responder host nodes. A first embodiment of the present invention is described with reference to FIG. Each of steps S1-S9 of FIG. 5 is performed by a corresponding part of the host performing this step, and therefore, FIG. 5 can also be interpreted as illustrating the structure of the hosts, however, in practice, the physical element of the host can perform more than one stage.

In a first embodiment of the present invention, the aforementioned cryptographic element and general state information relate to a hash chain stored by the Initiator. The Initiator knows the number of unused values in the hash chain, and the Respondent knows at least the last used value from the hash chain. In a first embodiment of the invention, the general state information comprises at least the last used value from the hash chain.

Hash chains are based on a public function that is relatively easy to compute, but from a computational point of view, it is difficult or impossible to invert. Such functions are called one-way functions. If the result of the function is a fixed length, then it is referred to as a one-way hash function. In other words, the hash () function, which maps strings of bits (either of arbitrary length or a predetermined length) to strings of fixed length, is a hash function if it has the following three properties: (a) for a given x, it is easy to calculate hash (x); (b) for a given hash (x), it is difficult to compute x; and (c) it is difficult to find two values x and y for which hash (x) = hash (y), where x ≠ y. More information can be found in the following document: TA Berson, L. Gong and TMA Lomas, Secure, "Keyed, and Collisionful Hash Functions, Technical Report" SRI-CSL-94-08, SRI International, May 1994.

The hash chain refers to that described, for example, in the following document: L. Lamport, "Password Authentication with Insecure Communication", Communications of the ACM 24.11 (November 1981), pp 770-772. A hash chain of length N is constructed by recursively applying the one-way hash function hash () to the original value s: hash ^N (s) = hash (hash (hash (... hash (s) ...))) (N times). For a hash chain generated in the reverse order, each H _i element in the hash chain is generated from a previously generated H _{i + 1} element by computing H _i = hash (H _{i + 1} ).

The first element H _{0 of the} hash chain resembles a shared key in cryptography using a shared key. Knowing H ₀ , H ₁ cannot be generated by those who do not know the value of s , however, given H _1, its correctness can be verified using H ₀ . In a typical application, the hash chain H ₀ would be distributed in a secure manner, and then the elements of the hash chain would be wasted (or used) one by one, starting from H ₁ and continuing until the value s was reached. In such cases, it is said that the hash chain has been exhausted, and the whole process is repeated again with a different s value to reinitialize the system. Other varieties of hash chains are disclosed in other documents.

In the first embodiment of the invention, such a hash chain is based on the Initiator as a result of the preliminary interaction between the Initiator and the Respondent. The hash chain may be specific to a particular Initiator-Responder pair, with a different hash chain based on each Responder host, or it may relate to interactions with several different Responder host nodes with which the Initiator communicates.

The previous interaction may be, but is not limited to, for example, performing a standard basic HIP exchange between two hosts to establish a secure HIP communication session. Any form of pre-existing relationship between the Initiator and the Responder can be used, which bases the common state between the two host nodes. The previously existing relationship and general status information are schematically shown at the top of FIG. 5.

The general state between the Initiator and the Respondent in the first embodiment of the invention contains some mutual knowledge related to the current position in the hash chain based on the Initiator. In particular, the general state information contains information identifying the last used item in the hash chain. General status information is known to both the Initiator and the Respondent. For example, general status information may be stored in both the Initiator and the Respondent.

In this embodiment, the hash chain is constructed using a hash function with the preceding hash chain element and the HIT _I Label of the Initiator Host Node as input:

H _i = hash (HIT _I , H _{i + 1} ).

Examples of such hash functions include MD5, SHA-1, and SHA-256. Currently, HIP uses SHA-1 for other purposes, and therefore, this will be one of the possible choices for use in the first embodiment of the present invention. The hash () hash function is known to both the Initiator and the Responder.

Suppose that the Initiator wants to establish a fresh, secure HIP connection between himself and the Responder by performing a basic HIP exchange operation. Taking into account the pre-existing relationship, instead, in the first embodiment of the invention, a modified basic HIP exchange method is performed in which the standard HIP basic exchange messages I1 and R1 are dispensed with.

Instead (FIG. 5), in step S1, a pre-generated cryptographic element is selected for inclusion in the Paired Freshness (PF) field of the authentication message I2 ′ based on the general status information. In a first embodiment of the invention, this cryptographic element is the next unused element in the hash chain, and the general state information indicates which element in the hash chain was last used. Therefore, PF is chosen so as to contain a cryptographic element H _i so that the condition
H _i-1 = hash (HIT _I , H _i ), where H _i-1 is the previous mutually known value from the hash chain (general state information).

In step S2, the authentication message I2 ′ containing PF, as well as the Identifier HIT _{I of the} Initiator's Host, is transmitted to the Responder, and it is received by the Responder in step S3. Message I2 'also contains the Diffie-Hellman Initiator public key DH _I and the Host Identity common key PK _I. (Although the standard basic HIP exchange protocol requires that the I2 message carry the Initiator Host Identity PK _I shared key, in other embodiments of the present invention, the key may be excluded from the I2 'message because the Respondent is either aware of PK _I key as part of the general state, or the Responder is able to receive it from the general server.)

In the first embodiment, the I2 ′ message has the same packet type as the I2 message in the standard HIP basic exchange method. Accordingly, when, at step S3, the Respondent receives the message I2 ', he usually expects to find the puzzle solution in the message and, subsequently, verify the puzzle solution. However, in the modified HIP basic exchange method of the first embodiment of the present invention, if the Respondent does not find a solution to the puzzle and instead finds the Pair Freshness parameter, then he can determine that the modified HIP basic exchange is used, and not standard. It is noteworthy that in the case of a standard basic HIP exchange, the Responder, as a rule, does not create any state when generating a response to the I1 message with the R1 message, and therefore, it processes all I2 messages as if they arrived without any recent communication between host nodes.

At step S3, therefore, the Responder scans the received message by searching for a puzzle solution parameter. If the message is an I2 message from the standard protocol, the Responder will find the Solutions parameter and continue processing the message in accordance with the standard protocol. However, if the Initiator uses a modified protocol according to an embodiment of the present invention, the Responder will find and retrieve the Peer Freshness PF parameter of the Peer. The Responder also retrieves the Initiator Host Identity HIT _I from the HIP header.

Using HIT _I , the Responder searches the local database for a general status associated with HIT _I. The general state information in this embodiment of the invention is the current value of H _{i-1 of the} hash chain. If such a general condition cannot be found, then the I2 'message is discarded, and optionally the Responder can respond with the ICMP Parameter Error message. If it is possible to find the state related to HIT _I , then the Responder proceeds to step S4.

Using the cryptographic element H _i from the Pair Freshness parameter, the value H _i-1 from the local state and the Identifier HIT _{I of the} Initiator's Host, at step S4, the Responder authenticates the cryptographic element by verifying that H _i-1 = hash (HIT _I , H _i ). If this relationship is not satisfied, then the I2 'message is discarded, and the optional ICMP Parameter Error message can be transmitted.

Authentication of a cryptographic element essentially comprises verification of the source of the cryptographic element. By verifying the source of the cryptographic element, the verifier can obtain enough confidence (for further processing of the received message) that the cryptographic element was transmitted by the source either (a) after the general state was established between the source and the verifier, or (b) after the source for the last time successfully passed the cryptographic element to the verifier, depending on which of these events took place last, or within the time stamp, if time stamps are used (e that case is described below).

To ensure stability in the event that the Initiator sends one or more I2 'messages that do not reach the Responder, if the above verification fails, the Responder can calculate a small number of hash chain values preceding H _i-1 by repeatedly applying the hash function and thus generating other candidates to match the previously used local state. That is, instead of requiring that H _i-1 be in the local state, the Respondent may provide the opportunity to instead contain H _i-2 , ..., H _ik , for some small value of k. Despite the fact that this method also works for large k values, thereby providing greater stability in terms of packet loss, the desire to protect the Respondent from DoS attacks that deplete the CPU requires a small limit of k, thereby creating a higher threshold for the number of CPU cycles which the Respondent will use when verifying the cryptographic element in any one message I2 '. Moreover, if the Initiator knows the lower bound for k, then in the case of repeated transmission of I2 'messages without receiving the R2 message, the Initiator may consider that the Responder obviously did not receive the I2' message and that, therefore, the general state has lost its relevance. As a result, the Initiator can switch back to using the standard basic HIP exchange.

On the other hand, if the authentication is successful, then the Respondent becomes aware that the message I2 'has recently been transmitted by a known and verified Initiator. In response, the Responder updates the general state by storing the recently used value of the hash chain H _i as the last used element of the hash chain, and, by and large, proceeds to process the I2 'message in accordance with the standard basic HIP exchange protocol, taking into account the need to correctly verify the puzzle solution and authenticating the I2 ′ message by verifying the digital signature in the message.

After positive authentication in step S4 in step S5, a confirmation message R2 'is transmitted to the Initiator. Message R2 'contains the Diffie-Hellman Responder public key, so that the Initiator can create the public key material. Otherwise, the R2 'message may be the same as for the standard protocol.

A confirmation message R2 'is received by the Initiator in step S6, and in step S7, the Initiator verifies the signature used by the Responder for message R2'. For this purpose, the Initiator will already have in memory the common key PK _{R of the} Identity of the Responder's Host from a previously existing relationship. Alternatively, instead of responding to the common key PK _R Identity of the Responder's Host, the Initiator can retrieve it from the shared memory. If the Responder's HIT _{R is} known to the Initiator, then it is not necessary that the shared Host Identity keys in memory be protected by integrity (but they can be protected). Or PK _R can be transmitted in the message R2 '.

After positive verification in step S7, in step S8, Secure HIP Communications are established, and in step S9, secure HIP communications are performed.

Although it is described above that the Respondent knows (for example, has in memory) the last used value of the hash chain (general status information), the Responder can instead retrieve this information from the shared memory, which is integrity protected. Obtaining information related to the hash chain from shared memory in this way can create a danger of a DoS attack, since it requires resources and authorizes the temporary state of the Respondent, that is, the Responder must remember that it processes the I2 'message until it receives a hash value or an indication that the hash value associated with the HIT _{I of the} Initiator does not exist. Alternatively, if the Responder sends message I2 'to the shared memory along with the request and receives it back with the response, then this problem can be partially avoided.

It is also not necessary that the hash chain is stored and maintained by the Initiator. It can be stored and maintained anywhere, provided that the Initiator has access to unused values in the hash chain and that unused values in the hash chain are not accessible openly.

In the first embodiment described above, the general state information and the cryptographic element belonged to a hash chain. The general state information contained the last used item from the hash chain, and the cryptographic element contained the next unused item from the hash chain.

Instead of using a hash chain, the second and third embodiments of the present invention are based on the use of a shared secret between the Initiator and the Respondent. The second and third embodiments of the invention are similar to each other, and both of these options are closely related to the first embodiment of the invention. The second and third embodiments of the invention follow the same steps as illustrated in FIG. 5, but with a cryptographic element and general state information that are different from those of the first embodiment. Accordingly, there is no need for a full description of the second and third embodiments of the present invention. Instead, the main differences from the first embodiment of the invention are highlighted below.

In the second embodiment of the invention, the parameter PF created in step S1 is based on the shared secret and the value of the synchronized counter according to the following expression:

PF = [ hash (HIT _I , K _IR , counter), counter]

where K _IR is the shared secret, “counter” is the value of the counter variable that is incremented after each use, HIT _I is the Identifier Label of the Initiator's host, and hash () is any suitable hash function. The hash function hash () accepts three inputs (HIT _I , K _IR and "counter") to generate a cryptographic element with a hash value (HIT _I , K _IR , counter) to be included in the PF parameter along with the counter value used to generate a cryptographic element. The shared secret of K _IR is known only to the Initiator and the Responder or a group of trusting Respondents, and it is shared between two host nodes (or the Initiator and the group of Respondents) as a result of a pre-existing relationship.

The parameter PF is transmitted, received and retrieved in steps S2 and S3, as described above in connection with the first embodiment of the invention. However, in this embodiment, when using HIT _{I, the} Responder searches the local database to find the general status associated with HIT _I , the general status information that is extracted from the shared secret K _R is the last used counter value . The Responder also retrieves the “counter” value from the PF parameter to recover from the case when one or more I2 'messages were transmitted by the Initiator but did not reach the Responder. As before, if it is possible to find the state related to HIT _I , then the Responder proceeds to step S4. Unlike the first embodiment, the difference between the counter value stored by the Respondent and the counter value used by the Initiator can be significantly larger than the parameter k from the first embodiment, since the counter parameter is a direct input to the hash function, and it does not involve reusing hash functions, as in the first embodiment of the invention.

At step S4, the Responder verifies the source of the cryptographic element from the received parameter PF by calculating the hash function using the following elements as inputs: HIT _I from the header I2 ', the value of the "counter" from the parameter PF and K _IR from the search for the local state. Prior to computing the hash, the Responder verifies that the counter value accepted in the PF parameter is greater than or equal to the value stored in the general state. The calculated hash function is hash (HIT _I , K _IR , counter), which is equivalent to the function calculated by the Initiator to generate a cryptographic key in the initial stage. If the verification is successful, then the Respondent becomes aware that the shared secret has been used correctly and recently, and that the message I2 'was recently sent by a well-known and verified Initiator. The transponder stores the counter value in a general state. Processing further continues, as described above in connection with the first embodiment of the invention.

The third embodiment of the present invention is very similar to the second embodiment, and a common secret is also used here. The third embodiment differs from the second embodiment in that the current time value is used instead of the counter value, wherein the Initiator and the Responder preferably have at least roughly synchronized clocks. So, the parameter PF in the third embodiment of the invention is created in accordance with the following expression:

PF = [ hash (HIT _I , K _IR , current time), current time]

In the first, second and third embodiments, the cryptographic item may be generated using any other input values known to both the host nodes, such as the Identity Tag HIT _R Responder host. However, in the first embodiment of the invention, it can contain only fixed input values that are known at the time when the Hash chain is initially created by the Initiator, while in the second and third embodiments of the invention it can contain input values that are determined at run time. In the second and third embodiments, the hash () hash function can be replaced with some other type of encryption function, where the parties share a secret instead of using a hash chain. Using the HIT _I Label of the Identifier of the Initiator Host as an input to the cryptographic function used to generate the cryptographic element is not essential.

Although the embodiments of the invention have been described above, where the Initiator communicates with one Responder and there is one hash chain for such communication, instead of one Responder there may be a group of Respondents, all of which use a common directory to store the last used value of the hash chain. In this case, instead of using separate hash chains for all hosts in the group, the Initiator can use only one hash chain to create HIP links to all hosts in the group.

The use of a hash chain and a shared secret can be combined, and the above methods can be more or less complicated by various means that are quite obvious to those skilled in the art without significant effect on their security properties.

In step S3 of the first, second and third embodiments of the invention, the search in the database or directory should preferably not consume too many resources or too much time, or otherwise the Responder will become vulnerable to a new DoS attack. Nevertheless, provided that the required effort and time are within reasonable limits, for example, if at most several times more resources and time are required than when verifying the puzzle solution in the standard HIP basic exchange protocol, the modified basic exchange procedure may regarded as sufficiently protected.

Although the type of PF parameter can be recognized by any suitable means, it is expected that the Freshness parameter of the Peer will be defined as a separate HIP extension parameter, and that it will have a separate parameter type identifier. In this regard, the HIP protocol currently uses 16-bit unsigned integers as parameter identifiers, and a unique identifier for the type of parameter is specified for each type of parameter.

Other suitable alternatives for determining whether a standard or modified version of the basic HIP protocol is used include the HIP packet type (using a type different from the standard I2 packet), the HIP version number, the backup field in the HIP header, the HIP control bits (Control ), encoding information in either the HIT of the Initiator or the HIT of the Respondent, for example, using a different prefix different from the prefix used in the standard protocol and using a different type of IP protocol for transmitting modifier messages th e version of the protocol.

In an embodiment of the present invention, the Initiator's Host Identity PK _I shared key in message I2 'may be transmitted in its pure form (if it is unknown to the Respondent), may not be transmitted at all (if it is known that the Responder already has it), or may be encrypted using a common Respondent's key instead of the Diffie-Hellman session key, since the Diffie-Hellman session shared key will only be available later.

We now turn to security issues related to the use of the modified basic HIP exchange according to the present invention. If the Respondent considers the Initiator to be trustworthy and competent, so that the Initiator never sends I2 messages containing false information, never sends I2 messages unless he intends to initiate HIP communication with the Responder, and keeps unused hash chain values and / or common secret, the protocol will be as secure as the standard basic HIP exchange. Modifications to the standard basic HIP exchange method affect the protection part of the basic exchange against DoS attacks and to a lesser extent other parts. The rest of the protocol conforms to a large extent to the standard basic HIP exchange, with the exception of two main differences:

Firstly, the Initiator does not need to learn the shared Recipient Host Identity key from the (currently non-existent) R1 message, since this key is already known to him or he can get it from somewhere else.

Secondly, the Response Diffie-Hallman common key DH _R carried in the standard basic HIP exchange message R1 is now transmitted in the message R2 ', because the message R1 is not available. As a result, the initiator's Host Identity PK _I shared key in message I2 'cannot be encrypted using the session key, and the Encryption of the Initiator Host Node PK _I key is made optional in the standard basic HIP exchange protocol.

Considering protection against DoS attacks, the following observations can be made:

In the standard basic HIP exchange, one hash function is required to verify the puzzle solution. In the modified basic HIP exchange according to the present invention, verification of the Fresh Freshness parameter requires searching for the previous value of the hash chain or common secret and calculating one hash function if packets were not previously lost, in which case a small amount of calculations may be required. In other words, the required CPU load is approximately the same, while a slightly increased memory access load may occur due to the search for the associated state.

In the standard HIP core exchange, puzzle verification provides the Respondent with confidence that the Initiator is there and that he spent some time with the CPU to solve the puzzle. In the modified HIP core exchange of the present invention, the verification of the Fresh Freshness parameter provides the Respondent with the assurance that the Initiator has sent the I2 'message some time after the last communication with the Responder. If a common secret with a time stamp is used, then the Respondent receives additional assurance that either the cracker previously managed to move the Initiator's clock forward, or, alternatively, the Initiator actually sent a message relatively recently, that is, within the discretization of the time stamp.

In the standard HIP core exchange, the puzzle verification phase relies on general information. Anyone can solve the puzzle and send the puzzle to the Respondent, not just the Initiator. However, solving a puzzle requires a certain number of CPU cycles, and therefore it is uneconomical to do so. This is the essence of protecting HIP from DoS attacks - the need for the Initiator to do some work beforehand. In an embodiment of the present invention, a similar pattern takes place. Theoretically, anyone can reverse the hash chain, that is, find the next unused value in the hash chain. However, this will require even more CPU resources than with the basic HIP exchange puzzle. On the other hand, the Initiator knows the following value of the hash chain (since it generated a hash chain), and therefore, if the Respondent trusts (at least to some extent) the Initiator, and if the Responder knows the last used value in the hash chain, then the Responder may with relatively low costs, verify that the Initiator actually transmitted a message that contains the accepted value of the hash chain after the current saved last one was transmitted This is the size of the hash chain.

By combining the assurance provided through the modified I2 'message with the assumption that the Initiator is honest and competent, as shown above, the Respondent can expect at least an equal degree of security, as in the case of standard basic HIP exchange. Both protocols, that is, standard and modified according to the present invention, have a DoS vulnerability to man-in-the-middle attacks. The modified HIP core exchange of the present invention without a time stamp has a limited vulnerability to attacks such as replay: a time stamp helps protect against such attacks. In particular, if the Initiator sends messages I2 ', which have the parameter PF, but do not have a time stamp, so that the cracker can receive the message, and the Recipient cannot, then the cracker can replay the message once to the Recipient, thereby leading to that the Recipient creates unnecessary HIP communication, that is, unnecessarily wastes resources. However, this residual attack cannot be considered serious, since each intercepted message can be used only once, and, therefore, the additional work caused on the side of the Recipient is naturally limited.

As mentioned above, the pre-existing relationship between the Initiator and the Responder to create a common state may be the result of a previous execution of a standard basic HIP exchange between two hosts to establish a secure HIP communication session. However, any form of a pre-existing relationship between the Initiator and the Respondent may be used. For example, the general status can be set manually by manually entering the shared secret into both hosts. Other examples will be apparent to those skilled in the art.

It should also be noted that if hosts previously performed a standard basic HIP exchange, they can hold the resulting HIP communication for quite some time and simply use the HIP UPDATE messages to create new IPsec SAs. The fundamental difference between using HIP UPDATES and the method according to the present invention is that in the case of an UPDATE message, the HIP key material (namely, KEYMAT) is not regenerated, while in the case of an embodiment of the present invention it is regenerated.

As mentioned above, two round-trip loops and four messages in the standard HIP core protocol can often pose a performance problem. An embodiment of the present invention provides a significant technical advantage by providing an alternative basic HIP exchange procedure with only one round-trip loop and two messages.

Obviously, the operation of one or more of the above components can be controlled by a program running on a device or apparatus. Such an operating program may be stored on a computer-readable medium, or may, for example, be implemented as a signal, such as a download data signal provided from an Internet site. The appended claims should be interpreted as encompassing the operating program per se, or as recording on a medium, or as a signal, or in any other form.

It will be apparent to those skilled in the art that embodiments of the present invention are not limited to any particular protocol or addressing scheme for each of the layers, for example, in the transport layer or network layer, and it will function in the HIP structure of any addressing protocol or The transport protocol was not used in this structure.

Claims (46)

1. An authentication method based on a modified HIP network node identification protocol containing a single cycle of two messages for use by the first and second HIP network nodes having a sharing state based on a pre-established relationship, comprising the steps of
send from the first network node to the second network node an authentication message containing the identifier of the first network node and a cryptographic data element;
receiving the authentication message by the second network node and using the identifier and information regarding the sharing status to authenticate the cryptographic element; and
after successful authentication of the cryptographic element, a confirmation message is sent from the second network node to the first network node, which indicates successful authentication. 2. The method of claim 1, wherein the identifier is a HIP identification tag. 3. The method of claim 2, wherein the HIP identification label is a Network Node Identification Label (HIT) or Local Area Identifier (LSI). 4. The method of claim 1, wherein the authentication of the cryptographic element comprises verifying the source of the cryptographic element. 5. The method according to claim 1, comprising the step of retrieving the sharing status information using the received identifier. 6. The method according to claim 1, comprising the step of generating or selecting a cryptographic element using the sharing status information. 7. The method according to claim 1, in which the cryptographic element is obtained from performing a cryptographic function. 8. The method according to claim 7, in which the cryptographic function has, as input, at least said identifier. 9. The method according to claim 7 or 8, in which the cryptographic function is a hash function. 10. The method according to claim 9, in which the information about the sharing status contains at least the last used item from the hash chain generated from the hash function, and which contains the step of selecting the next unused item in the hash chain for use as a cryptographic element. 11. The method of claim 10, wherein the cryptographic element is authenticated by computing a hash function using the received identifier and the received cryptographic element, and by comparing the result with at least the last used element. 12. The method of claim 10 or 11, wherein the hash chain is pre-generated and at least the unused elements in the hash chain are stored in the first host or the first host has access to them. 13. The method of claim 12, wherein the hash chain is generated as a result of a predefined relationship. 14. The method of claim 10, wherein the hash chain is dedicated to interactions between the first and second network nodes. 15. The method of claim 10, wherein the hash chain is dedicated to interactions between the first network nodes and a plurality of such second network nodes. 16. The method according to claim 1, wherein the sharing status information comprises secret information exchanged between the first and second network nodes as a result of a predetermined relationship. 17. The method according to clause 16, in which the secret information contains a cryptographic key. 18. The method according to clause 16, in which the secret information is used as input into a cryptographic function. 19. The method of claim 18, wherein the cryptographic element is authenticated by computing a cryptographic function using the received identifier and secret information, and by comparing the result with the received cryptographic element. 20. The method of claim 18, wherein the time stamp is used as input to a cryptographic function. 21. The method according to p. 18, in which the counter is used as input into the cryptographic function, and which contains the stage at which the counter is incremented. 22. The method according to claim 20, in which the authentication message contains a time stamp and / or counter, and the cryptographic element is authenticated by calculating the cryptographic function using the received time stamp and / or counter, and by comparing the result with the received cryptographic element. 23. The method according to claim 1, wherein the general state information is stored in a second network node. 24. The method according to claim 1, which comprises the step of retrieving information about the status of sharing from a remote server. 25. The method according to paragraph 24, in which information about the sharing status stored in the remote server is protected from modification by unauthorized parties. 26. The method according to paragraph 24, comprising the step of sending at least a portion of the authentication message to a remote server to recover information about the sharing status. 27. The method of claim 1, wherein the authentication message comprises a Diffie-Hellman common key of the first network node. 28. The method according to claim 1, in which the authentication message contains a common Identification key of the network node (HI) of the first network node. 29. The method according to claim 1, in which the confirmation message contains a common Diffie-Hellman key of the second network node. 30. The method according to any one of the preceding paragraphs, comprising the step of signing a confirmation message using the private key of the second network node. 31. The method according to claim 30, comprising the step of verifying the signature in the first network node using the shared key of the Network node identification of the second network node. 32. The method according to p, in which the shared key Identification of the network node of the second network node is known to the first network node as a result of a pre-established relationship or it is accessible from a remote server. 33. The method according to claim 1, comprising the step of creating a HIP Secure Communications (SA) between the first and second network nodes after receiving the confirmation message in the first network node. 34. The method according to claim 1, in which the pre-established relationship is obtained from the fact that the standard basic HIP exchange between the first and second network nodes has been previously performed. 35. The method according to claim 1, comprising determining whether the authentication message is HIP standard message 12 or not. 36. The method of claim 35, wherein the authentication message is distinguished from the message 12 of the standard basic HIP exchange by determining the type of HIP parameter associated with the cryptographic element. 37. The method of claim 35, wherein the authentication message is distinguished from the standard HIP message 12 based on one or more of the following parameters: type of HIP packet; HIP protocol version field a bit or some combination of bits from the backup field of the HIP header; HIP control in the Control field of the header is a variation in any one or both identifiers of the first and second network nodes and the IP protocol used. 38. A communication system for performing an authentication method based on a modified protocol for identifying HIP network nodes, comprising a single cycle of two messages between the first and second network nodes of the HIP system having a shared state based on a pre-established relationship, the first network node comprising for sending to the second network node an authentication message containing the identifier of the first network node and a cryptographic element; and the second network node comprises means for receiving an authentication message and for using the identifier and information related to the sharing state to authenticate the cryptographic element; and means for sending to the first network node a confirmation message that indicates successful authentication, the direction being executed after the authentication of the cryptographic element is successful. 39. An authentication method based on a modified HIP network nodes identification protocol containing a single cycle of two messages for use by a HIP Initiator network node having a sharing state based on a pre-established relationship with a HIP Responder network node, comprising the step of send to the HIP Responder network node an authentication message containing the identifier of the HIP Initiator network node and a cryptographic element, the authentication message being nacheno for use in HIP Responder network node to authenticate the cryptographic item using the identifier and information relating to the sharing state, so that after a successful authentication of the cryptographic item in a network node HIP Initiator could be sent a confirmation message which indicates successful authentication. 40. Device for performing, as a network node of a HIP Initiator, an authentication method based on a modified HIP network nodes identification protocol containing a single cycle of two messages with a HIP Responder network node with which the HIP Initiator network node has a sharing state based on previously the established relationship, containing means for sending to the network node of the HIP Responder an authentication message containing the identifier of the network node of the HIP Initiator and cryptographic an authentication element, wherein the authentication message is intended to be used at the HIP Responder's network node to authenticate the cryptographic element using the identifier and information regarding the sharing state, so that after successful authentication of the cryptographic element the confirmation message can be sent to the HIP Initiator's network node, which indicates successful authentication. 41. An authentication method based on a modified protocol for identifying HIP network nodes, containing a single cycle of two messages, for use by a HIP Responder network node in a shared state, based on a predefined relationship, with a HIP Initiator network node, comprising the steps of receive an authentication message from the HIP Initiator's network node containing the HIP Initiator's network node identifier and cryptographic element, use the identifier and information the sharing status to authenticate the cryptographic element, and after successful authentication of the cryptographic element, a confirmation message indicating successful authentication is sent to the HIP Initiator's network node. 42. A device for performing as an HIP Responder network node an authentication method based on a modified HIP network nodes identification protocol containing a single cycle of two messages with a HIP Initiator network node with which the HIP Responder network node has a sharing state based on a predefined a relationship, comprising means for receiving an authentication message from the HIP Initiator's network node containing the identifier of the HIP Initiator's network node and cryptographic Every element to use the ID and state information sharing in order to authenticate the cryptographic item, and that after successful authentication of the cryptographic item to send to the network node HIP Initiator confirmation message that indicates successful authentication. 43. A computer-readable medium storing a computer program that, when executed on a device, causes the device to execute the method of claim 39 or 41. 44. A machine-readable medium storing a computer program, which, when downloaded to a device, causes the device to become the device according to claim 40 or 42. 45. The computer-readable medium of claim 43 or 44, which is a transmission medium. 46. The computer-readable medium of claim 43 or 44, which is a storage medium.

Images