CN102904861B

CN102904861B - A kind of extended authentication method and system based on ISAKMP

Info

Publication number: CN102904861B
Application number: CN201110213510.3A
Authority: CN
Inventors: 梁小萍; 韦银星
Original assignee: ZTE Corp
Current assignee: No2 Shrimp Culture Company Sheyang Port Sheyang County
Priority date: 2011-07-28
Filing date: 2011-07-28
Publication date: 2017-10-03
Anticipated expiration: 2031-07-28
Also published as: CN102904861A

Abstract

The invention discloses a kind of extended authentication method based on internet security alliance and IKMP (ISAKMP), including：When needing to send first route messages, promoter consults to be authenticated using Extensible Authentication Protocol (EAP) with respondent；After the success of EAP authentication process, master session key (MSK) or shared key of the promoter with the respondent according to the generation of EAP processes, calculate message authentication code (HMAC) value with key in AUTH load, and AUTH load is sent to other side, certification is completed in ISAKMP.The present invention discloses a kind of extended authentication system based on ISAKMP, using the method and system of the present invention, authentication method, and then the development for the modern authentication techniques that can follow up can be flexibly selected in ISAKMP.

Description

Extended authentication method and system based on ISAKMP

Technical Field

The invention relates to a key management and authentication technology of routing equipment in a communication network, in particular to an extended authentication method and system based on Internet Security Alliance and Key Management Protocol (ISAKMP).

Background

The Internet (Internet) has become an indispensable infrastructure of modern society, playing a very important role for politics, economy and civilian life. Once the internet is damaged or attacked, serious harm and influence are brought, so that the network security is concerned by people in the world. The core device in the internet is a routing device, which is an important aspect of network security to ensure the security of the routing device, and the key management and authentication are very important aspects in the security mechanism of the routing device (including the running routing protocol). Here, the Internet refers to an Internet Protocol (IP) network. Currently, the Internet Engineering Task Force (IETF), a global organization for Internet architecture and various protocol standards enactment, is working on the Key and Authentication of Routing Protocols (KARP) and the security Inter-Domain Routing (SIDR) working group, and some propose to extend ISAKMP for key management and authentication of Routing devices (including Routing Protocols).

The basic idea and process of ISAKMP authentication are as follows: the two authentication parties negotiate a Security Association (SA), that is: ISAKMP SA, where SA is a set of keying material, comprising: the adopted hash algorithm (hashalgorithm) or signature algorithm, encryption algorithm (encryption algorithm), authentication algorithm (authentication algorithm), and group information exchanged by Diffie-Hellman; the two parties of Authentication use the negotiated hash algorithm or signature algorithm to calculate and generate a Message Authentication Code (HMAC) with a key from the sent part of messages and/or ISAKMP states, write the HMAC into the AUTH load and deliver the HMAC to the other party, and then complete the process of Message and identity Authentication. Wherein, the partial message is: SA parameters or authentication parameters; a pre-configured shared key (pre-shared key) or a key calculated through a key exchange such as Diffie-Hellman exchange may be used as an input key in calculating the HMAC.

However, in the prior art, the limitations of the authentication method of ISAKMP mainly appear in the following aspects:

first, the range of choice of authentication mechanism is limited. Because only simple hash algorithm or signature algorithm can be used to generate HMAC to complete the authentication process, the latest authentication method such as the Security Transport Layer (TLS) authentication method cannot be used for authentication, thus limiting the freedom of selecting the authentication mechanism by the routing device and failing to follow the development of modern authentication technology at any time.

Second, the configuration is complicated. The authentication mechanism of ISAKMP requires that the routing devices are configured with a trust relationship in advance, such as a pre-shared key or a digital certificate, however, configuring the trust relationship on the routing devices is very labor intensive and in some cases even impossible. For example, assuming that there are n routing devices in the local network, and a trust relationship is configured for each two routing devices, n (n-1)/2 trust relationships need to be configured, if the local network is large in size, that is: when the number of the routing devices is large, the configuration workload is very large. In addition, if the two routing devices belong to different operators, it is difficult to configure a trust relationship between the two routing devices in advance. Further, if globally, it is not possible to configure trust relationships for routing devices two by two.

Third, three-party authentication techniques cannot be used. ISAKMP defines a two-party authentication technology, and requires a trust relationship to be configured between routing devices in advance. However, in practical applications, it is often impossible to implement the pre-configuration of trust relationships between two routing devices, especially when the routing devices belong to different network domains. In this case, ISAKMP does not solve the situation where a trust relationship is not configured in advance between routing devices well, since ISAKMP does not define a three-party authentication mechanism.

Fourth, it is not conducive to long-term key updates and the addition of a torn-down routing device. When a certain routing device needs to update the shared key, all other related routing devices need to update the key, which is a huge workload and can affect other routing devices. When a routing device needs to be added to the network, all relevant routing devices add the security material relevant to the routing device, and the workload of the process is also huge, and the other routing devices are affected. When a certain routing device is removed, all other related routing devices delete the security material related to the routing device, which is also a heavy burden and affects other routing devices.

Disclosure of Invention

In view of the above, the main objective of the present invention is to provide an extended authentication method and system based on ISAKMP, which can flexibly select an authentication method in ISAKMP, and further follow up the development of modern authentication technology.

In order to achieve the purpose, the technical scheme of the invention is realized as follows:

the invention provides an ISAKMP-based extended authentication method, which comprises the following steps:

when a first routing message needs to be sent, an initiator and a responder negotiate to use an Extensible Authentication Protocol (EAP) for Authentication;

after the EAP authentication process is successful, the initiator and the responder calculate an HMAC value in the AUTH load according to a Master Session Key (MSK) or a shared Key generated by the EAP process, send the AUTH load to the other party, and complete authentication in ISAKMP.

In the above solution, the negotiating between the initiator and the responder to use EAP for authentication includes:

the initiator sends an EAP message containing no AUTH load to the responder;

after receiving the EAP message, the responder sends an EAP Request (Request) to the initiator through EAP load;

and after receiving the EAP Request, the initiator sends an EAP Response (Response) to the responder through the EAP load, and the responder performs an EAP authentication process.

In the above solution, before the initiator sends the EAP message to the responder, the method further includes:

the initiator and the responder perform an initial SA establishment procedure.

In the above solution, when negotiating between the initiator and the responder for EAP authentication, and when the initiator and the responder do not configure a trust relationship therebetween and both the initiator and the responder have configured a trust relationship with a Diameter server in advance, the method further includes:

the responder sends an EAP Start (Start) message to a Diameter server according to a Diameter-EAP protocol;

after receiving the EAP Start message, the Diameter server interacts with the EAP authentication information of the responder so as to enable the initiator and the responder to perform an EAP authentication process through the Diameter server, and after the EAP authentication process is successful, the Diameter server sends the generated MSK or the shared secret key to the responder.

In the above solution, the responder sends an EAPStart message to the Diameter server according to the Diameter-EAP protocol, and the sending is:

the responder sends a Diameter-EAP-Request message containing an empty EAP payload to a Diameter server;

the initiator and the responder perform EAP authentication information interaction to enable the initiator and the responder to perform EAP authentication through a Diameter server, and the EAP authentication process comprises the following steps:

the Diameter server encapsulates the EAP Request in an EAP load, and then returns a Diameter-EAP-Answer message containing the EAP load to the responder;

the responder encapsulates the received EAP Request in an extensible payload EAP payload of ISAKMP and sends the EAP payload to the initiator;

the initiator returns corresponding EAP Response to the responder according to the received EAP Request;

and the responder encapsulates the received EAP Response in the EAP payload of the Diameter-EAP-Request message, sends the EAP payload to the Diameter server, and repeats the steps until the Diameter server confirms that the EAP authentication process is finished.

In the above scheme, before the responder calculates the HMAC value in the AUTH payload according to the MSK or the shared key generated by the EAP procedure, the method further includes:

after the EAP authentication process is successful, the Diameter server sends an EAP success message and the MSK or the shared secret key generated in the EAP authentication process to the responder.

In the above solution, when negotiating between the initiator and the responder for EAP authentication, and when a trust relationship is not configured between the initiator and the responder and a trust relationship is established between the initiator and the responder through two or more Diameter servers, the method further includes:

the responder sends an EAP Start message to a Diameter relay server according to a Diameter-EAP protocol;

the Diameter relay server forwards an EAP Start message to the Diameter server;

after receiving the EAP Start message, the Diameter server performs EAP authentication information interaction with the Diameter relay server so that the initiator and the responder perform an EAP authentication process through the Diameter server and the Diameter relay server, and after the EAP authentication process is successful, the Diameter relay server sends the generated MSK or shared key to the Diameter relay server; and the Diameter relay server sends the received MSK or the shared secret key to the responder.

the EAP authentication information interaction is carried out with the Diameter relay server, so that the EAP authentication process is carried out between the initiator and the responder through the Diameter server and the Diameter relay server, and the EAP authentication process is carried out by the Diameter relay server and the Diameter relay server, and the EAP authentication process comprises the following steps:

the Diameter server encapsulates the EAP Request in an EAP load, and then returns a Diameter-EAP-Answer message containing the EAP load to the Diameter relay server;

the Diameter relay server forwards the received Diameter-EAP-Answer message containing EAP load to the responder;

the responder encapsulates the received EAP Response in the EAP load of the Diameter-EAP-Request message and sends the EAP load to the Diameter relay server;

and the Diameter relay server forwards the received EAP Response to the Diameter server, and the steps are repeated until the Diameter server confirms that the EAP authentication process is finished.

after the EAP authentication process is successful, the Diameter server sends an EAP success message and MSK or a shared key generated in the EAP authentication process to the Diameter relay server;

and the Diameter relay server forwards the received EAP success message and the MSK or the shared secret key generated in the EAP authentication process to the responder.

The invention also provides an extended authentication system based on ISAKMP, which comprises: a first router and a second router; wherein,

the first router is used for negotiating with second routing equipment to use EAP for authentication when needing to send a first routing message; after the EAP authentication is successful, according to the MSK or the shared key generated in the EAP process, the AUTH load value is calculated, the AUTH load is sent to the second routing equipment, and the authentication is completed in ISAKMP;

the second router is used for negotiating with the first routing equipment to use EAP for authentication; and after the EAP authentication is successful, calculating the AUTH load value according to the MSK or the shared key generated in the EAP process, sending the AUTH load to the first routing equipment, and completing the authentication in ISAKMP.

In the foregoing solution, when negotiating to use EAP for authentication between the first routing device and the second routing device, and when the first routing device and the second routing device do not configure a trust relationship, and when the first routing device and the second routing device both have configured a trust relationship with the Diameter server in advance, the system further includes: the first Diameter server is used for carrying out EAP authentication information interaction with the second routing equipment after receiving the EAP Start message sent by the second routing equipment so as to enable the first routing equipment and the second routing equipment to carry out an EAP authentication process through the Diameter server, and sending the generated MSK or the shared key to the second routing equipment after the EAP authentication process is successful;

the second routing device is further configured to send an EAP Start message to the first Diameter server according to a Diameter-EAP protocol, perform EAP authentication information interaction with the first Diameter server, so that the first routing device and the second routing device perform an EAP authentication process through the first Diameter server, and receive the generated MSK or shared key sent by the first Diameter server.

In the foregoing solution, when negotiating to use EAP for authentication between the first routing device and the second routing device, and when a trust relationship is not configured between the first routing device and the second routing device and the trust relationship is established between the first routing device and the second routing device through two or more Diameter servers, the system further includes: the second Diameter server is used for forwarding the EAP Start message to the first Diameter server after receiving the EAP Start message sent by the second routing equipment; performing EAP authentication information interaction with the first Diameter server so that the first routing equipment and the second routing equipment perform an EAP authentication process through the first Diameter server and the second Diameter server; and sending the received generated MSK or shared key sent by the first Diameter server to the second routing equipment;

the first Diameter server is further configured to perform EAP authentication information interaction with the second Diameter server after receiving the EAP Start message sent by the second Diameter server, so that the first routing device and the second routing device perform an EAP authentication process through the first Diameter server and the second Diameter server, and send the generated MSK or shared key to the second Diameter server after the EAP authentication process is successful;

the second routing device is further configured to send an EAP Start message to the second Diameter server according to a Diameter-EAP protocol, and receive the generated MSK or shared key sent by the second Diameter server.

In the above scheme, the number of the second Diameter servers is more than one.

The ISAKMP-based extended authentication method and the ISAKMP-based extended authentication system have the advantages that when a first routing message needs to be sent, an initiator and a responder negotiate to use EAP (extensible authentication protocol) for authentication; after the EAP authentication process is successful, the initiator and the responder calculate an HMAC value in the AUTH load according to the MSK or the shared key generated in the EAP process, send the AUTH load to the opposite side and finish authentication in ISAKMP; the initiator and the responder can flexibly select the authentication method according to the requirements in the EAP authentication process, so that the authentication mechanism is flexible, and the development of the modern authentication technology can be followed.

In addition, when negotiating to use EAP for authentication, when a trust relationship is not configured between an initiator and a responder and the trust relationship is configured between the initiator and the responder and a Diameter server in advance, the responder uses the Diameter-EAP protocol to send an EAP Start message to the Diameter server; after receiving the EAP Start message, the Diameter server performs EAP authentication information interaction with the responder, so that the responder and the initiator perform an EAP authentication process through the Diameter server; when a trust relationship is not configured between an initiator and a responder and the trust relationship is established between the initiator and the responder through more than two Diameter servers, the responder sends an EAP Start message to the Diameter relay server according to a Diameter-EAP protocol; the Diameter relay server forwards an EAP Start message to the Diameter server; after receiving the EAP Start message, the Diameter server interacts with the EAP authentication information of the Diameter relay server and the responder so as to enable the initiator and the responder to perform the EAP authentication process through the Diameter server and the Diameter relay server, thus realizing a three-party authentication technology in ISAKMP and solving the problem of complicated configuration trust relationship; moreover, when the key is updated and/or the routing equipment is added and/or removed, only the security material related to the corresponding routing equipment needs to be updated and/or added and/or deleted on the Diameter server, so that the workload can be effectively reduced, and the implementation is convenient.

Drawings

FIG. 1 is a schematic flow chart of an ISAKMP-based extended authentication method according to the present invention;

FIG. 2 is a schematic diagram of an identity protection exchange process of prior art ISAKMP;

fig. 3 is a schematic flowchart illustrating an extended authentication method based on ISAKMP according to an embodiment;

figure 4 is a schematic flow chart of an ISAKMP-based extended authentication method introduced into a Diameter server according to a second embodiment;

figure 5 is a schematic flow chart of an ISAKMP-based extended authentication method introduced into a Diameter relay server according to a third embodiment;

fig. 6 is a schematic structural diagram of an ISAKMP-based extended authentication system according to the present invention.

Detailed Description

The present invention will be described in further detail with reference to the accompanying drawings and specific embodiments.

In the following description, a routing device acting as an initiator is referred to as an initiator, and a routing device acting as a responder is referred to as a responder. Wherein, the initiator means: the routing device initiating the first message, the responder means: is a routing device that feeds back the first message to the originator.

The extended authentication method based on ISAKMP of the invention, as shown in figure 1, includes the following steps:

step 101: when a first routing message needs to be sent, an initiator and a responder negotiate to use EAP for authentication;

here, the specific implementation of this step includes the following steps:

the initiator sends an EAP message containing no AUTH load to the responder;

after receiving the EAP message, the responder sends EAP Request to the initiator through EAP load;

and after receiving the EAP Request, the initiator sends EAP Response to the responder through the EAP load, and the responder performs an EAP authentication process.

Wherein, the EAP message does not contain AUTH payload, and the responder can know to start the EAP authentication procedure accordingly.

If the initiator and the responder need to interact more, the sequence of EAP Request and EAPResponse may continue, namely: the initiator and the responder interact EAP load for a plurality of times until the responder sends an EAP authentication result to the initiator, namely: success (EAP Success) or failure (EAPFailure).

Before the initiator sends an EAP message to the responder, the method may further include:

the initiator and the responder perform an initial SA establishment process; the specific implementation of the initial SA establishment procedure is the prior art, and is not described herein again.

When negotiating the use between the initiator and the responder for EAP authentication and when the initiator and the responder are not configured with trust relationship, and the initiator and the responder are both configured with trust relationship with a Diameter server in advance, the method further comprises:

the responder sends an EAP Start message to a Diameter server according to a Diameter-EAP protocol;

The responder sends an EAP Start message to a Diameter server according to a Diameter-EAP protocol, specifically:

the method for performing EAP authentication information interaction between the initiator and the responder through a Diameter server includes:

and the responder encapsulates the received EAP Response in the EAP payload of the Diameter-EAP-Request message, sends the EAP payload to the Diameter server, and repeats the steps until the Diameter server confirms that the EAP authentication process is finished. Here, the result of the authentication may be success or failure.

If the EAP authentication process is successful, the Diameter server sends an EAP Success message and the MSK or the shared key generated in the EAP method authentication process to the responder, and the responder sends the generated MSK or the shared key to the initiator.

When negotiating the use between the initiator and the responder for EAP authentication, and when a trust relationship is not configured between the initiator and the responder and the trust relationship is established between the initiator and the responder through more than two Diameter servers, the method further comprises the following steps:

the Diameter relay server forwards an EAP Start message to the Diameter server;

The responder sends an EAP Start message to a Diameter relay server according to a Diameter-EAP protocol, specifically:

the responder sends a Diameter-EAP-Request message containing an empty EAP payload to a Diameter relay server;

performing EAP authentication information interaction with a Diameter relay server to perform an EAP authentication process between the initiator and the responder through the Diameter server and the Diameter relay server, specifically:

and the Diameter relay server forwards the received EAP Response to the Diameter server, and the steps are repeated until the Diameter server confirms that the EAP authentication process is finished. Here, the result of the authentication may be success or failure.

The process is the same as the process when the initiator and the responder and the Diameter server are configured with trust relationship in advance, the information interaction among the responder, the Diameter relay server and the Diameter server is also completed according to the Diameter-EAP protocol, and in the process, the Diameter relay server only plays a role of relay and can directly forward the messages from the responder and the Diameter server without processing. If the EAP authentication process is successful, the Diameter server sends the EAP Success message and the MSK or the shared key generated in the EAP method authentication process to the Diameter relay server, the Diameter relay server forwards the EAP Success message and the MSK or the shared key generated in the EAP method authentication process to the responder, and the responder sends the generated MSK or the shared key to the initiator.

the initiator and the responder carry out an ISAKMP SA establishment process; the specific implementation of the ISAKMP SA establishment process is the prior art, and is not described herein again; after ISAKMP SA is established, under the protection of ISAKMP SA, the initiator and the responder negotiate to use EAP for authentication.

Since bidirectional authentication is implemented in ISAKMP, when selecting an EAP method, it is recommended to select an EAP method that can implement bidirectional authentication so that an MSK or a shared key can be generated.

Step 102: after the EAP authentication process is successful, the initiator and the responder calculate the HMAC value in the AUTH load according to the MSK or the shared key generated in the EAP process, send the AUTH load to the opposite side and finish the authentication in ISAKMP.

Here, when the MSK is generated in the EAP authentication process, the HMAC value in the AUTH payload is calculated according to the generated MSK, and when the MSK is not generated in the EAP authentication process, the HMAC value in the AUTH payload is calculated according to the generated shared key.

After the EAP authentication is successful, the responder sends an EAP authentication result to the initiator and simultaneously sends an MSK or a shared key generated according to the EAP authentication process to the initiator, so that the initiator and the responder can complete authentication in ISAKMP.

In other words, when the initiator and the responder send a session again, the generated shared key is different from the shared key of the previous session, and the MSK does not change; here, the specific processing procedure of calculating the HMAC value in the AUTH payload according to the MSK or the shared key generated by the EAP procedure is the prior art, and is not described here again.

The specific process of completing authentication in ISAKMP is the prior art, and is not described herein again.

The format and definition of the EAP load involved in the EAP authentication process adopted by the invention are the same as those defined in RFC 3748. Here, the RFC refers to Request Comments (RFC), which are a series of files arranged by number. The documents collect software documents about internet related information, and UNIX and internet communities.

The present invention will be described in further detail with reference to examples.

ISAKMP may implement Authentication mechanisms in four Exchange types (Exchange types), which are basic Exchange (Base Exchange), Identity Protection Exchange (Identity Protection Exchange), Authentication Only Exchange (Authentication Only Exchange), and Aggressive Exchange (Aggressive Exchange), respectively. Among them, Identity Protection Exchange can protect Identity load and AUTH load well.

The process of Identity Protection Exchange, as shown in fig. 2, includes the following steps:

step 201: when a first routing message needs to be sent, an initiator sends HDR load and SA load to a responder;

step 202: after receiving the SA load, the responder sends HDR load and SA load to the initiator, and negotiates with the initiator to establish ISAKMP SA;

here, the HDR payload represents an ISAKMP protocol header, and the HDR payload is transmitted when the initiator and the responder interact with each other.

Step 203-204: the initiator and the responder mutually send Key Exchange (KE) loads and random number (NONCE) loads, and the initiator and the responder calculate a shared Key according to the received KE loads and the received NONCE loads and use the shared Key as an input Key of the HMAC for calculating the AUTH loads;

here, the KE payload is loaded with the public value (public value) of Diffie-Hellman.

Step 205-206: under the protection of ISAKMP SA, the initiator and the responder mutually transmit HDR load, identity (IDx) load and AUTH load for mutual authentication.

Specifically, the initiator and the responder respectively calculate an HMAC value and compare the HMAC value with the HMAC value in the AUTH load, if the HMACs of both the initiator and the responder can be matched, the mutual authentication is passed, otherwise, the authentication fails.

Here, the "+" sign after the HDR payload indicates that the subsequent payloads are encrypted, i.e.: the IDx load and the AUTH load are encrypted;

x may be ii or ir, representing the initiator and responder of ISAKMP, respectively, or ui or ur, representing the user initiator and responder, respectively, when ISAKMP daemon is a proxy negotiator (proxy negotiator); the AUTH payload is a generic identity authentication mechanism, and may specifically be a HASH payload or a SIG payload.

Because of the security features of the Identity Protection Exchange, to achieve the objectives of the present invention and to best embody the core ideas of the present invention, the following embodiments are all described using the Identity Protection Exchange to practice the core ideas of the present invention, namely: for EAP extension, other exchange types in ISAKMP can also perform EAP extension according to the embodiment of the present invention, and belong to the protection scope of the patent of the present invention.

The first embodiment is as follows:

the application scenario of this embodiment is as follows: the shared secret key k is configured between the initiator and the responder in advance_abThe initiator and responder may be anywhere on the network, communicating using the IP protocol. The initiator is a router sending the routing message, and the responder is a router receiving the routing message. In this embodiment, the ISAKMP is subjected to EAP extension, and the process of performing authentication by using an EAP method based on the identity protection exchange of ISAKMP, as shown in fig. 3, includes the following steps:

step 301: when a first routing message needs to be sent, an initiator sends an SA load to a responder;

step 302: the responder sends the SA payload to the initiator;

to this end, the initiator negotiates with the responder to establish an ISAKMP SA.

Step 303: the initiator sends KE load and NONCE load to the responder;

step 304: the responder sends KE load and NONCE load to the initiator;

here, the process of steps 301 to 304 may be referred to as ISAKMP SA establishment process, and the steps 301 to 304 are performed for the purpose of: the initiator and the responder exchange and negotiate a cryptographic algorithm (cryptology algorithms), exchange NONCE, perform Diffie-Hellman (D-H) exchange and the like with each other, and a secure channel is provided for subsequent exchange of the initiator and the responder; the specific processing procedures of steps 301 to 304 are prior art and will not be described herein.

Step 305: under the protection of ISAKMP SA, the initiator sends IDii load to the responder;

here, the initiator leaves AUTH payload empty, thereby informing the responder that it wants to negotiate authentication using the EAP method.

Step 306: under the protection of ISAKMP SA, the responder sends IDir, AUTH and EAP loads to the initiator;

here, sending the EAP payload means that the responder agrees to authenticate using the EAP method while issuing an EAPRequest;

step 307: the initiator responses the EAP load to the responder and performs an EAP authentication process with the responder;

here, the EAP load is EAP Response;

the method used for EAP authentication may be an existing authentication method, such as: TLS, fifth version of the Message Digest Algorithm (MD5, Message Digest Algorithm 5), etc.; in practical application, the method adopted for performing the EAP authentication process can be selected according to the requirement; according to the different authentication methods, the initiator and the responder need to interact with each other for multiple EAP loads, in other words, according to the authentication method, the initiator may need to send multiple EAP loads to the responder, and correspondingly, the responder needs to send multiple EAP loads to the initiator to complete the EAP authentication process. It is proposed to use an EAP method that enables bidirectional authentication.

Since the shared secret key k is configured between the initiator and the responder in advance_abTherefore, after receiving the EAP payload, the responder directly performs an EAP authentication procedure with the initiator.

Step 308: after the EAP authentication is successful, the responder returns an EAP load to the sender;

here, the EAP payload is EAP Success, and a process including EAP authentication generates an MSK or a shared key.

Step 309: after receiving the EAP load, the initiator calculates an HMAC value in the AUTH load according to the MSK or the shared key generated in the EAP authentication process, and sends the AUTH load to the responder so as to compare the AUTH load with the calculated HMAC value;

step 310: the responder calculates an HMAC value in the AUTH load according to the MSK or the shared key generated in the EAP authentication process, and sends the AUTH load to the initiator so as to compare the AUTH load with the calculated HMAC value;

at this point, both parties complete ISAKMP authentication.

Example two:

the application scenario of this embodiment is as follows: the initiator and the responder are not configured with trust relationship, and the initiator and the Diameter server are configured with trust relationship k in advance_acThe trust relationship k is configured between the responder and the Diameter server in advance_bcISAKMP is adopted between the initiator and the responder for interaction, and Diameter-ISAKMP is adopted between the responder and the Diameter server for interaction. The initiator is a router sending the routing message, and the responder is a router receiving the routing message. The embodiment introduces an ISAKMP-based extended authentication method of a Diameter server, as shown in fig. 4The method comprises the following steps:

step 401: when a first routing message needs to be sent, an initiator sends an SA load to a responder;

step 402: the responder sends the SA payload to the initiator;

Step 403: the initiator sends KE load and NONCE load to the responder;

step 404: the responder sends KE load and NONCE load to the initiator;

here, the processes of steps 401 to 404 may be referred to as ISAKMP SA establishment processes, and the steps 401 to 404 are performed for the purpose of: the initiator and the responder exchange with each other to negotiate the crytographic algorithms, exchange NONCE, perform D-H exchange and the like, and a secure channel is provided for the subsequent exchange of the initiator and the responder; the specific processing procedures of steps 401 to 404 are prior art and are not described herein again.

Step 405: under the protection of ISAKMP SA, the initiator sends HDR load and IDii load to the responder;

Step 406: after receiving the KE load and the NONCE load, the responder sends an EAP Start message to a Diameter server according to a Diameter-EAP protocol;

specifically, an empty EAP payload is sent in a Diameter-EAP-Request message to prompt the Diameter server.

Here, because the trust relationship between the initiator and the responder is not configured, and the trust relationship k is configured between the responder and the Diameter server in advance_bcTherefore, after receiving the EAP payload, the responder sends an EAP start message to the Diameter server;

the process of establishing initial connection between responder Diameter servers is known as the Diameter protocol, namely: the specification in the RFC3588 document is that in actual application, generally, only names and trust relationships need to be configured; the way of establishing the connection may be: the responder and the Diameter server can complete dynamic connection establishment by utilizing a Domain Name System (DNS) server, and the responder and the Diameter server can also establish connection in a manual configuration mode.

Step 407: after receiving the EAP Start message, the Diameter server encapsulates an EAP Request in an EAP load, and then returns a Diameter-EAP-Answer message containing the EAP load to a responder;

step 408: the responder encapsulates the received EAP Request in the extensible payload EAP payload of the ISAKMP and sends the EAP payload to the initiator;

step 409: the initiator returns corresponding EAP Response to the responder according to the received EAP Request;

here, the EAP Response is also encapsulated in the extension payload EAP payload of ISAKMP.

Step 410: the responder encapsulates the received EAP Response in the EAP load of the Diameter-EAP-Request message, and sends the EAP load to the Diameter server to perform an EAP authentication process;

here, the method adopted for EAP authentication may be an existing authentication method, such as: TLS, or MD5, etc.; in practical application, the method adopted for performing the EAP authentication process can be selected according to the requirement; according to different adopted authentication methods, the initiator and the responder need to interact with each other for multiple EAP loads, in other words, according to the adopted authentication method, the initiator may need to send multiple EAP loads to the responder, and correspondingly, the responder needs to send multiple EAP loads to the initiator, and correspondingly, multiple EAP messages need to be interacted between the Diameter server and the responder to complete the EAP authentication process. It is proposed to use an EAP method that enables bidirectional authentication.

Step 411: when the EAP authentication process is successful, the Diameter server encapsulates the EAP Success message and MSK or shared key generated in the EAP authentication process in a Diameter-EAP-Answer message and sends the Diameter-EAP-Answer message to a responder;

step 412: after the responder receives the Diameter-EAP-Answer message, the responder returns an EAP load to the sender;

Step 413: after receiving the EAP load, the initiator calculates an HMAC value in the AUTH load according to the MSK or the shared key and sends the AUTH load to the responder so as to compare the AUTH load with the calculated HMAC value;

step 414: and the responder calculates the HMAC value in the AUTH load according to the MSK or the shared key and sends the AUTH load to the initiator so as to compare the AUTH load with the calculated HMAC value.

At this point, both parties complete ISAKMP authentication.

Example three:

the application scenario of this embodiment is as follows: the initiator and the responder are not configured with trust relationship, and the initiator and the Diameter server are configured with trust relationship k in advance_acThe trust relationship k is configured between the responder and the Diameter relay server in advance_bdThe trust relationship k is configured between the Diameter relay server and the Diameter server in advance_cd. Since the trust relationship between the Diameter relay server and the initiator is not configured in advance. The initiator is a router sending the routing message, and the responder is a router receiving the routing message. The extended authentication method based on ISAKMP introduced into the Diameter relay server in this embodiment, as shown in fig. 5, includes the following steps:

step 501: when a first routing message needs to be sent, an initiator sends an SA load to a responder;

step 502: the responder sends the SA payload to the initiator;

Step 503: the initiator sends KE load and NONCE load to the responder;

step 504: the responder sends KE load and NONCE load to the initiator;

here, the process of steps 501-504 can be referred to as ISAKMP SA establishment process, and steps 501-504 are performed for the purpose of: the initiator and the responder exchange with each other to negotiate the crytographic algorithms, exchange NONCE, perform D-H exchange and the like, and a secure channel is provided for the subsequent exchange of the initiator and the responder; the specific processing procedures of steps 501 to 504 are prior art and are not described herein again.

Step 505: under the protection of ISAKMP SA, the initiator sends HDR load and IDii load to the responder;

Step 506: after receiving the KE load and the NONCE load, the responder sends an EAP Start message to the Diameter relay server according to a Diameter-EAP protocol;

specifically, an empty EAP payload is sent in a Diameter-EAP-Request message to prompt the Diameter relay server.

Here, because the trust relationship is not configured between the initiator and the responder, and the trust relationship k is configured between the responder and the Diameter relay server in advance_bdTherefore, after receiving the EAP payload, the responder sends an authentication request message to the Diameter relay server;

the process of establishing initial connection between a responder and a Diameter relay server is referred to as Diameter protocol, namely: the specification in the RFC3588 document is that in actual application, generally, only names and trust relationships need to be configured; the way of establishing the connection may be: the responder and the Diameter relay server can complete dynamic connection establishment by utilizing a DNS (domain name system) server, and the responder and the Diameter relay server can also establish connection in a manual configuration mode.

Step 507: the Diameter relay server directly forwards the EAP Start message to the Diameter server;

step 508: after receiving the EAP Start message, the Diameter server encapsulates an EAP Request in an EAP load, and then returns a Diameter-EAP-Answer message containing the EAP load to the Diameter relay server;

step 509: after receiving the message, the Diameter relay server forwards the received Diameter-EAP-Answer message containing EAP load to a responder;

step 510: the responder encapsulates the received EAP Request in the extensible payload EAP payload of the ISAKMP and sends the EAP payload to the initiator;

step 511: the initiator returns corresponding EAP Response to the responder according to the received EAP Request;

Step 512: the responder encapsulates the received EAP Response in the EAP load of the Diameter-EAP-Request message and sends the EAP load to the Diameter relay server;

step 513: the Diameter relay server transmits the received EAP Response to the Diameter server to perform an EAP authentication process;

here, the method adopted for EAP authentication may be an existing authentication method, such as: TLS, or MD5, etc.; in practical application, the method adopted for performing the EAP authentication process can be selected according to the requirement; according to different adopted authentication methods, multiple EAP loads need to be interacted between an initiator and a responder, in other words, according to the adopted authentication method, the initiator may need to send multiple EAP loads to the responder, and correspondingly, the responder needs to send multiple EAP loads to the initiator, and correspondingly, multiple EAP messages need to be interacted between a Diameter relay server and the responder, and multiple EAP messages also need to be interacted between the Diameter relay server and the Diameter server, so as to complete an EAP authentication process. It is proposed to use an EAP method that enables bidirectional authentication.

Step 514: when the EAP authentication process is successful, the Diameter server encapsulates the EAP Success message and MSK or shared key generated in the EAP authentication process in a Diameter-EAP-Answer message and sends the Diameter-EAP-Answer message to the Diameter relay server;

step 515: after receiving the Diameter-EAP-Answer message, the Diameter relay server forwards the received Diameter-EAP-Answer message to a responder;

step 516: after the responder receives the Diameter-EAP-Answer message, the responder returns an EAP load to the sender;

517: after receiving the EAP load, the initiator calculates an HMAC value in the AUTH load according to the MSK or the shared key and sends the AUTH load to the responder so as to compare the AUTH load with the calculated HMAC value;

step 518: and the responder calculates the HMAC value in the AUTH load according to the MSK or the shared key and sends the AUTH load to the initiator so as to compare the AUTH load with the calculated HMAC value.

Here, the definition and action of the message in the present embodiment are completely the same as those in the second embodiment.

At this point, both parties complete ISAKMP authentication.

In order to implement the above method, the present invention further provides an extended authentication system based on ISAKMP, as shown in fig. 6, the system includes: a first routing device 61, and a second routing device 62; wherein,

the first routing device 61 is configured to negotiate with the second routing device 62 to use EAP for authentication when the first routing message needs to be sent; after the EAP authentication is successful, the value of the AUTH load is calculated according to the MSK or the shared key generated in the EAP process, and the AUTH load is sent to the second routing device 62, and the authentication is completed in the ISAKMP;

a second routing device 62 for negotiating authentication using EAP with the first routing device 61; and after the EAP authentication is successful, the value of the AUTH load is calculated according to the MSK or the shared key generated in the EAP process, and the AUTH load is sent to the first routing device 61, and the authentication is completed in the ISAKMP.

Here, it should be noted that: the first routing device 61 is a routing device acting as an initiator, and the second routing device 62 is a routing device acting as a responder; wherein, the initiator means: the routing device initiating the first message, the responder means: is a routing device that feeds back the first message to the originator.

When negotiating the authentication using EAP between the first routing device 61 and the second routing device 62, and when the trust relationship is not configured between the first routing device and the second routing device 62, and the trust relationship is configured in advance between the first routing device 61 and the second routing device 62 and the Diameter server, the system may further include: the first Diameter server is configured to perform EAP authentication information interaction with the second routing device 62 after receiving the EAP Start message sent by the second routing device 62, so that the first routing device 61 and the second routing device 62 perform an EAP authentication process through the Diameter server, and send the generated MSK or shared key to the second routing device 62 after the EAP authentication process is successful;

the second routing device 62 is further configured to send an EAP Start message to the first Diameter server according to a Diameter-EAP protocol, perform EAP authentication information interaction with the first Diameter server, so that the first routing device 61 and the second routing device 62 perform an EAP authentication process through the first Diameter server, and receive the generated MSK or shared key sent by the first Diameter server.

When negotiating the authentication using EAP between the first routing device 61 and the second routing device 62, and when the trust relationship is not configured between the first routing device 61 and the second routing device 62, and the trust relationship is established between the first routing device 61 and the second routing device 62 through two or more dtiameter servers, the system further includes: the second Diameter server is configured to forward the EAP Start message to the first Diameter server after receiving the EAP Start message sent by the second routing device 62; performing EAP authentication information interaction with the first Diameter server, so that the first routing device 61 and the second routing device 62 perform an EAP authentication process through the first Diameter server and the second Diameter server; and sends the received generated MSK or shared key sent by the first Diameter server to the second routing device 62;

the first Diameter server is further configured to perform EAP authentication information interaction with the second Diameter server after receiving the EAP Start message sent by the second Diameter server, so that the first routing device 61 and the second routing device 62 perform an EAP authentication process through the first Diameter server and the second Diameter server, and send the generated MSK or shared key to the second Diameter server after the EAP authentication process is successful;

the second routing device 62 is further configured to send an EAP Start message to the second Diameter server according to the Diameter-EAP protocol, and receive the generated MSK or shared key sent by the second Diameter server.

Here, it should be noted that: the number of the second Diameter servers may be more than one.

Here, the specific processing procedures of the first router, the second router, the first Diameter server, and the second Diameter server in the system of the present invention have been described in detail above, and are not described again.

The above description is only a preferred embodiment of the present invention, and is not intended to limit the scope of the present invention.

Claims

1. An extended authentication method based on Internet Security Association and Key Management Protocol (ISAKMP), the method comprising:

when a first routing message needs to be sent, the initiator and the responder negotiate to use an Extensible Authentication Protocol (EAP) for authentication;

after the EAP authentication process is successful, the initiator and the responder calculate a message authentication code (HMAC) value with a key in an AUTH load according to a Master Session Key (MSK) or a shared key generated in the EAP process, send the AUTH load to the opposite side and finish authentication in ISAKMP;

the ISAKMP comprises four exchange types of basic exchange, identity protection exchange, authentication-only exchange and access exchange.

2. The method of claim 1, wherein the initiator negotiating authentication with the responder using EAP comprises:

the initiator sends an EAP message containing no AUTH load to the responder;

3. The method of claim 2, wherein before the initiator sends an EAP message to the responder, the method further comprises:

the initiator and the responder perform an initial Security Association (SA) establishment procedure.

4. The method of claim 1, 2 or 3, wherein when negotiating the use of EAP authentication between the initiator and the responder and when a trust relationship is not configured between the initiator and the responder and a trust relationship is previously configured between both the initiator and the responder and a Diameter server, the method further comprises:

5. The method of claim 4 wherein the responder sends an EAP Start message to a Diameter server according to the Diameter-EAP protocol as follows:

6. The method of claim 5, wherein before the responder calculates the HMAC value in the AUTH payload according to the MSK or the shared key generated by the EAP procedure, the method further comprises:

7. The method of claim 1, 2 or 3, wherein when negotiating the use of EAP authentication between the initiator and the responder and when a trust relationship is not configured between the initiator and the responder, the method further comprises:

the Diameter relay server forwards an EAP Start message to the Diameter server;

8. The method of claim 7 wherein the responder sends an EAP Start message to a Diameter server according to the Diameter-EAP protocol as:

9. The method of claim 8, wherein before the responder calculates the HMAC value in the AUTH payload according to the MSK or the shared key generated by the EAP procedure, the method further comprises:

10. An ISAKMP-based extended authentication system, the system comprising: a first router and a second router; wherein,

the second router is used for negotiating with the first routing equipment to use EAP for authentication; after the EAP authentication is successful, calculating the AUTH load value according to the MSK or the shared key generated in the EAP process, sending the AUTH load to the first routing equipment, and completing the authentication in ISAKMP;

the ISAKMP includes four exchange types, basic exchange, identity protection exchange, authentication only exchange, and aggressive exchange.

11. The system of claim 10, wherein when negotiating authentication using EAP between the first routing device and the second routing device, and when a trust relationship is not configured between the first routing device and the second routing device, and when a trust relationship has been previously configured between both the first routing device and the second routing device and the Diameter server, the system further comprises: the first Diameter server is used for carrying out EAP authentication information interaction with the second routing equipment after receiving the EAP Start message sent by the second routing equipment so as to enable the first routing equipment and the second routing equipment to carry out an EAP authentication process through the Diameter server, and sending the generated MSK or the shared key to the second routing equipment after the EAP authentication process is successful;

12. The system of claim 11, wherein when negotiating EAP authentication between the first routing device and the second routing device, and when the first routing device and the second routing device are not configured with a trust relationship, the system further comprises when the first routing device and the second routing device establish trust relationships between each other through two or more Diameter servers: the second Diameter server is used for forwarding the EAP Start message to the first Diameter server after receiving the EAP Start message sent by the second routing equipment; performing EAP authentication information interaction with the first Diameter server so that the first routing equipment and the second routing equipment perform an EAP authentication process through the first Diameter server and the second Diameter server; and sending the received generated MSK or shared key sent by the first Diameter server to the second routing equipment;

the second routing device is further configured to send an EAPStart message to the second Diameter server according to a Diameter-EAP protocol, and receive the generated MSK or shared key sent by the second Diameter server.

13. The system of claim 12 wherein the number of second Diameter servers is more than one.