JP2006086618A - Communication control method, communication control unit, control program, and recording medium - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To provide an authentication method for dispensing with an authentication inquiry to a Radius server each time when performing expansion authentication between a starter and a responder. <P>SOLUTION: A communication control method comprises a reception step for allowing the responder to receive an authentication packet transmitted from the starter, an authentication inquiry step for performing the authentication inquiry from the responder to the authentication server, an authentication determination step for determining whether the authentication inquiry was successful, and an authentication continuation step for continuing negotiation when the authentication inquiry was successful. The communication control method has the authentication determination step for determining whether negotiations are first ones when the starter started connecting to the responder when the starter performed a plurality of negotiations to the responder. <P>COPYRIGHT: (C)2006,JPO&NCIPI

Description

  The present invention relates to a communication control method, a communication control device, a control program, and a recording medium that reduce traffic during authentication in IPsec (Internet Protocol security architecture) communication.

  In recent years, with the spread of networks such as the Internet, electronic mails and files have been sent and received. Along with this, security concerns are increasing.

Conventionally, as a security mechanism used in a network such as the Internet, as disclosed in Patent Documents 1 and 2, it is a security mechanism in an IP (Internet Protocol) layer defined in RFC (Request For Comment) 2401. There are SSL (Secure Socket Layer) used by IPsec and WEB.

  In these protocols, it is necessary to share a session key used for encrypted communication between communicators before performing secure communication. As the method, there are IKE (Internet Key Exchange) defined in RFC2409, Handshake Protocol included in SSL, or the like.

  IKE is an independent mechanism that dynamically establishes a key required for IPsec, and is specifically defined in RFC2407 and RFC2408. It consists of ISAKMP (Internet Security Association and Key Management Protocol), which provides a key exchange framework, and Oakley, which defines the actual key management mechanism on ISAKMP.

IKE includes Phase 1 that establishes an ISAKMP SA (ISAKMP Security Association) for ISAKMP and Phase 2 that establishes an SA for IPsec. These two phases are collectively referred to as negotiation. The negotiation is, for example, confirming which communication mode can be used when a gateway such as a switch or router is connected to a communication terminal such as a personal computer. SA is a set of policies and keys used to protect communication. There are two main modes: Phase 1 which can protect the ID of the communication person and Aggressive mode which cannot protect the ID. Phase 2 has only the quick mode.

FIG. 1 is a diagram for explaining a main mode authentication method.
As shown in FIG. 1, the main mode includes an initiator (hereinafter referred to as a starter) and a responder (hereinafter referred to as a responder). T represents the elapsed time. In the main mode, ISAKMP is established by performing communication (three reciprocations) six times between the initiator and the responder. In the first two rounds (one round-trip) communication, an agreement such as an algorithm used by both parties is made. In the next two (one round-trip) communication, auxiliary data such as public values and random numbers of Diffie-Hellman key exchange algorithms necessary for key exchange are exchanged. Then, authentication of the key generated in the last two (one round-trip) communication is performed.

FIG. 2 is a diagram for explaining an authentication method in the aggressive mode.
As shown in FIG. 2, the aggressive mode has a starter and a responder. T represents the elapsed time. In the aggressive mode, the ISAKMP SA is established by communicating three times (1.5 round trips) between the initiator and the responder. In the first two rounds (one round-trip) communication, an agreement is made on the algorithm used by both parties, and exchange of auxiliary data such as the public value of the Diffie-Hellman key exchange algorithm and random numbers required for key exchange is performed. In the third communication, authentication of the starter and authentication of the generated key are performed. This third communication is not encrypted by the generated ISAKMP SA. Accordingly, it is impossible to protect the ID.

  In the main mode and the aggressive mode, three types of authentication methods can be used: electronic signature, public key cryptography, and a method using a pre-stored common key.

  The Phase 2 quick mode establishes an IPsec SA by communicating three times (1.5 times) between the initiator and responder. Communication contents in the quick mode are protected by ISAKMP SA. In the first two (one round-trip) communication, an algorithm used for both is determined, and the key generated in the third communication is authenticated.

  As described above, a session key used for encrypted communication can be shared between communicators before performing secure communication with IPsec.

  Next, consider a communication system that performs IPsec tunneling using an authentication server. IPsec tunneling refers to a secure communication path realized by encryption, and can be regarded as a virtual dedicated line.

  FIG. 3 is a diagram schematically illustrating a network that authenticates a CPE (Customer Premises Equipment) device using an authentication server. The CPE device is a communication terminal installed in a company or home, and corresponds to a personal computer or the like. As shown in FIG. 3, the network for authenticating the CPE device includes an ISP (Internet Service Provider) 1, a Radius (Remoto Authentication Dial In User Service) server 2, a Gateway 3, an ESP (Encapsulating Security Payload) tunnel 4, and a CPE device 5. -1 to 5-3. The Gateway 3 includes a router and a switch. Here, three CPE devices are installed and illustrated, but one or more CPE devices may be provided.

  First, the CPE device 5-2 performs authentication with the Radius server 2 via the Gateway 3. When the CPE device 5-2 is successfully authenticated with the Radius server 2, communication with the ISP 1 is possible. If the Gateway 3 itself has an authentication means without using the Radius server 2, the gateway 3 performs authentication processing, and if the authentication is successful, the ISP 1 can communicate.

  The authentication process described above will be described in detail with reference to FIG.

  FIG. 4 is a diagram for explaining a network authentication method for authenticating the CPE device shown in FIG. 3 described above. FIG. 4 includes a starter, a responder, and an authentication server. The initiator, responder, and authentication server represent the CPE device, Gateway, and Radius server shown in FIG. 3, respectively. T represents the elapsed time.

  As shown in FIG. 4, the CPE device that is the initiator establishes Phase1, that is, ISAKMP SA, to the Gateway that is the responder. After Phase 1 is established, xauth authentication and Radius-xauth authentication are performed by the CPE device that is the initiator and the Gateway that is the responder.

  In xauth authentication, the authentication packet makes one round trip between the CPE device that is the initiator and the gateway that is the responder. First, the responding Gateway sends a REQUEST packet to the CPE device that is the initiator. The REQUEST packet is a packet in which the responder requests a user name and a password from the initiator. When the CPE device that is the initiator receives the REQUEST packet, the CPE device that is the initiator sends a REPLY packet to the Gateway that is the responder. The REPLY packet is a packet in which the user name and IP address are set for the REQUEST packet received from the responder, and the initiator responds to the responder. When the xauth authentication is PAP (Password Authentication Protocol) authentication, the REPLY packet is sent to the responding Gateway with the user name and password.

  When the responding Gateway receives the REPLY packet, it transmits an Access-Request packet to the Radius server. The Access-Request packet is a packet for making a connection request from the responder to the Radius server, and the user name and IP address set in the REPLY packet are set. When the xauth authentication is PAP authentication, the user name, IP address, and password of the REPLY packet are set in the Access-Request packet and transmitted to the Radius server.

  When the Radius server receives the Access-Request packet, it compares the user name and IP address of the Radius server itself with the user name and IP address set in the Access-Request packet. If they match as a result of the comparison, the Radius server determines that the authentication is successful, and transmits an Access-Accept packet to the responding Gateway. In the case of PAP authentication, a password is added to the comparison item. The Access-Accept packet is a packet for permitting connection, and is a packet transmitted to the responder when the Radius server determines that the authentication is successful.

  When receiving the Access-Accept packet, the Gateway as the responder transmits a SET packet to the CPE device as the initiator. The SET packet is a packet informing the responder that the authentication is successful to the initiator. When the CPE device that is the initiator receives the SET packet, the CPE device transmits an ACK packet to the Gateway that is the responder, and the authentication process is completed. The ACK packet is a packet for confirming that the initiator has succeeded in authenticating the SET packet received from the responder.

  When PAP authentication is performed without using the Radius server, the user name, IP address, and password of the responding Gateway itself are compared with the user name, IP address, and password set in the REPLY packet. If the comparison results in a match, the responding Gateway sends a SET packet to the initiator CPE device. When the CPE device that is the initiator receives the SET packet, the CPE device transmits an ACK packet to the gateway that is the responder, and the authentication process is completed.

  When xauth authentication and Radius-xauth authentication are completed, Phase 2, that is, processing for establishing an IPsec SA is started. When the process of establishing the IPsec SA is completed and the process of Phase 1 is repeated, the processes of Phase 1, xauth authentication, Radius-xauth authentication, and Phase 2 are repeated.

Further, the authentication process between the responder Gateway and the Radius server will be described in detail with reference to a flowchart.
FIG. 5 is a conventional flowchart showing an authentication process between the responding Gateway and the Radius server.

First, using the above-described authentication method, the responding Gateway receives the REPLY packet (S101). Next, the username, password, etc. set in the REPLY packet received by the responding Gateway are set in the Access-Request packet, and the Gateway sends the Access-Request packet to the Radius server, that is, an authentication query. (S102). If the authentication is successful in the Radius server (S103; Yes), the negotiation is continued, that is, IKE is continued. If the authentication fails on the Radius server (S103; No), the negotiation is terminated, that is, IKE is interrupted.
JP 2001-298449 A Japanese Patent Laid-Open No. 2003-179592

  However, in the authentication method as described above, when Phase 1 is extended, that is, when extended authentication is performed between the initiator and the responder, an authentication inquiry must be made to the Radius server each time. As a result, traffic on the communication network has increased, which has hindered network operation.

  The present invention has been made in view of the above-described problems. When Phase 1 is extended, that is, when extended authentication is performed again between the initiator and the responder, an authentication inquiry is not made to the Radius server each time. A communication control method may be provided.

  According to a first aspect of the communication control method of the present invention, a responder receives an authentication packet transmitted from an initiator, an authentication inquiry step of making an authentication inquiry from the responder to an authentication server, and an authentication inquiry succeeding A communication control method comprising an authentication determination step for determining whether or not an authentication has been successful, and an authentication continuation step for continuing negotiation when an authentication inquiry is successful. In this case, the communication control method further comprises an authentication determination step for determining whether or not the starter is the first negotiation for starting connection with the responder.

  In the second aspect of the communication control method of the present invention, when the authentication determination step determines that the negotiation is the first negotiation, the second and subsequent negotiations are performed by the authentication information of the authentication packet transmitted from the initiator and the responder. The communication control method is characterized in that the authentication information is compared, and if the comparison results in a match, it is determined that the authentication is successful.

  According to a third aspect of the communication control method of the present invention, the authentication information is a user name, an IP address, and a password.

  According to a first aspect of the communication control apparatus of the present invention, a responder receives an authentication packet transmitted from an initiator, an authentication inquiry unit that makes an authentication inquiry from the responder to an authentication server, and the authentication inquiry A communication control device including an authentication determination unit that determines whether or not the authentication inquiry is successful, and an authentication continuation unit that continues negotiation when the authentication inquiry is successful. The communication control device includes an authentication determination unit configured to determine whether or not the starter is a first negotiation that starts connection to the responder when the negotiation is performed once.

  According to a second aspect of the communication control device of the present invention, when the authentication determination unit determines that the negotiation is the first negotiation, the second and subsequent negotiations are performed by the authentication information and the responder of the authentication packet transmitted from the initiator. The communication control device is characterized in that the authentication information is compared and the authentication control unit determines that the authentication is successful when the comparison results in a match.

  According to a third aspect of the communication control apparatus of the present invention, the authentication information is a user name, an IP address, and a password.

  According to a first aspect of the control program of the present invention, the responder receives an authentication packet transmitted from the initiator, causes the responder to make an authentication inquiry to the authentication server, and determines whether the authentication inquiry is successful. A control program for controlling the communication control device for continuing the negotiation by the computer when the authentication inquiry is successful, when the initiator initiates a response from the initiator to the responder a plurality of times, the initiator starts the response to the responder. It is a control program characterized by determining whether it is the first negotiation which started the connection.

  According to the second aspect of the control program of the present invention, when the determination is made as the first negotiation, the authentication information of the authentication packet transmitted from the initiator and the authentication information held by the responder when the second and subsequent negotiations are performed And a control program characterized in that if the result of the comparison is a match, it is determined that the authentication is successful.

  According to a third aspect of the control program of the present invention, the authentication information is a user name, an IP address, and a password.

  A first aspect of the recording medium of the present invention is a computer-readable recording medium in which the control program described above is recorded.

  According to the communication control method of the present invention, when extended authentication is performed between the initiator and the responder, it is possible to provide an authentication method that does not require an authentication inquiry to the Radius server each time. That is, by reducing the traffic volume at the time of authentication performed between the responder and the Radius server, it is possible to expect a more appropriate network operation than before.

  Embodiments of the present invention will be described below in detail with reference to the drawings.

FIG. 6 is a diagram for explaining the communication control method of the present invention.
As shown in FIG. 6, the communication control method according to the present invention includes a starter, a responder, and an authentication server. T represents the elapsed time. First, the initiator starts Phase 1 processing with the responder.

In Phase 1, main mode is used. That is, ISAKMP is established by performing communication 6 times (3 reciprocations) between the initiator and the responder. In the first two rounds (one round-trip) communication, an agreement such as an algorithm used by both parties is made. In the next two (one round-trip) communication, auxiliary data such as public values and random numbers of Diffie-Hellman key exchange algorithms necessary for key exchange are exchanged. Then, authentication of the key generated in the last two (one round-trip) communication is performed. When the processing of Phase 1 is completed, the initiator starts xauth authentication and Radius-xauth authentication with the responder.

In xauth authentication, the authentication packet makes one round trip between the initiator and the responder. First, the responder sends a REQUEST packet to the initiator. The REQUEST packet is a packet in which the responder requests a user name and an IP address from the initiator. When the initiator receives the REQUEST packet, the initiator sends a REPLY packet to the responder. The REPLY packet is a packet in which a user name and an IP address are set to the REQUEST packet received from the responder, and the initiator responds to the responder. When xauth authentication is PAP authentication, the REPLY packet is sent to the responder with the user name, IP address, and password.

  When the responder receives the REPLY packet, the responder transmits an Access-Request packet to the Radius server. The Access-Request packet is a packet for making a connection request from the responder to the Radius server, and the user name and IP address set in the REPLY packet are set in the Access-Request packet. When the xauth authentication is PAP authentication, the user name, IP address, and password of the REPLY packet are set in the Access-Request packet and transmitted to the Radius server.

  When the responder receives the Access-Accept packet, the responder registers the user name and IP address transmitted from the initiator with the responder itself. Furthermore, a SET packet is transmitted to the initiator. The SET packet is a packet informing the responder that the authentication is successful to the initiator. When the initiator receives the SET packet, the initiator transmits an ACK packet to the responder, and the authentication process is completed. The ACK packet is a packet for confirming that the initiator has succeeded in authenticating the SET packet received from the responder.

  When PAP authentication is performed without using the Radius server, the user name, IP address, and password of the responder itself are compared with the user name, IP address, and password set in the REPLY packet. If the result of the comparison is a match, the responder sends a SET packet to the initiator. When the initiator receives the SET packet, the initiator transmits an ACK packet to the responder, and the authentication process is completed.

  If the starter succeeds in xauth authentication with the responder, the responder subsequently performs Radius-xauth authentication with the Radius server.

    In the Radius-xauth authentication, when a gateway as a responder receives a REPLY packet, it transmits an Access-Request packet to the Radius server. The Access-Request packet is a packet for making a connection request from the responder to the Radius server, and the user name and IP address set in the REPLY packet are set in the Access-Request packet. When the xauth authentication is PAP authentication, the user name, IP address, and password of the REPLY packet are set in the Access-Request packet and transmitted to the Radius server.

  When the Radius server receives the Access-Request packet, it compares the user name and password of the Radius server itself with the user name and password set in the Access-Request packet. If they match as a result of the comparison, the Radius server determines that the authentication is successful, and transmits an Access-Accept packet to the responding Gateway. The Access-Accept packet is a packet for permitting connection, and is a packet transmitted to the responder when the Radius server determines that the authentication is successful.

  When the responder succeeds in Radius-xauth authentication with the Radius server and succeeds in xauth authentication with the initiator, the initiator starts the process of Phase 2 with the responder.

Phase2 uses quick mode. That is, communication is performed three times (1.5 times) between the initiator and the responder to establish an IPsec SA. Communication contents in the quick mode are protected by ISAKMP SA. In the first two (one round-trip) communication, an algorithm used for both is determined, and the key generated in the third communication is authenticated.

  Next, the starter performs Phase 1 re-stretching processing. After the above Phase 1 processing is completed, the starter then starts xauth authentication with the responder.

  In xauth authentication, the authentication packet makes one round trip between the initiator and the responder. First, the responder sends a REQUEST packet to the initiator. When the initiator receives the REQUEST packet, the initiator sends a REPLY packet to the responder. The REPLY packet is a packet in which the user name is set for the REQUEST packet received from the responder, and the initiator responds to the responder. When xauth authentication is PAP authentication, the REPLY packet is sent to the responder with the user name and password.

  When the responder receives the REPLY packet, the user name and IP address registered in the responder itself are compared with the user name and IP address set in the REPLY packet. If the result of the comparison is a match, the starter performs Phase 2 processing with the responder. If they do not match, the responder terminates the negotiation with the initiator.

  That is, when the first authentication is successful between the responder and the Radius server, the second and subsequent responders and the Radius server are not inquired for authentication. That is, the broken line arrow portion shown in FIG. 6 which is an authentication inquiry between the conventional responder and the Radius server is not performed by the present invention.

At that time, the authentication inquiry between the responder and the Radius server holds the state of the user name and IP address when the authentication is successful at the first time. And the authentication name between the responder for the second time and the Radius server, the user name when the authentication was successful in the first time,
By using the IP address, the second and subsequent responders and the Radius server do not need to be authenticated. In the case of PAP authentication, the responder keeps a user name, an IP address, and a password.

  In addition, the above-mentioned authentication inquiry between the responder and the Radius server after the second time is not necessary, and the authentication inquiry between the responder and the Radius server after the second time is necessary between the starter and the responder. Only when all SAs are released.

  In the above-described embodiment, the phase 1 process is performed using the main mode, but the phase 1 process may be performed using the aggressive mode.

Furthermore, the authentication process between the responder of the present invention and the Radius server will be described in detail with reference to a flowchart.
FIG. 7 is a flowchart of the present invention showing an authentication process between the responder and the Radius server.

  First, the responder receives a REPLY packet from the initiator (S201). When the responder receives the REPLY packet, it determines whether or not to hold the state (S202). Note that the state holding means a state in which a responder holds a user name, an IP address, and the like. If the responder is not holding the state, that is, if the user name, IP address, etc. are not held (S202; YES), the responder makes an authentication inquiry to the Radius server (S203). That is, the responder transmits an Access-Request packet to the Radius server.

  The responder makes an authentication inquiry to the Radius server and determines whether or not the authentication is successful (S204). That is, the user name and IP address set in the Access-Request packet are compared with the user name and IP address registered in the Radius server.

If the authentication is successful (S204: YES), that is, if the user name and IP address set in the Access-Request packet match the user name and IP address registered in the Radius server, the responder Does state retention. That is, the responder holds the user name, IP address, etc. of the initiator (S205). Then, the responder continues the negotiation (S206), that is, continues the IKE.

  On the other hand, if the responder is holding the state, that is, if the responder holds the user name, IP address, etc. of the starter (S202; NO), the user of the starter whose state is held by the responder The name, IP address, etc. are compared with the user name, IP address, etc. set in the REPLY packet (S207).

  If the user name, IP address, etc. of the initiator that is kept in the responder match the user name, IP address, etc. set in the REPLY packet, if they match (S207: YES), the negotiation continues. (S206). On the other hand, as a result of comparing the user name, IP address, etc. of the starter held in the responder with the user name, IP address, etc. set in the REPLY packet, they do not match (S207; NO) ), The responder ends the negotiation (S206).

  When the responder makes an authentication inquiry to the Radius server and determines whether or not the authentication has succeeded (S204), if the authentication fails (S204; NO), the responder ends the negotiation ( S206). That is, the responder sends an Access-Request packet to the Radius server, and the user name and IP address of the initiator set in the Access-Request packet and the user name and IP address registered in the Radius server If they do not match, the responder terminates the negotiation.

  In this embodiment, the Radius server is used as the authentication server. However, an AAA (Authentication, Authorization, Authorization) server may be used, and a TACACS (Terminal Access Controller Access Control System) server or the like may be used.

  Further, the operation of the communication control apparatus (responder) of the present invention will be described in detail with reference to FIG.

  FIG. 8 is another block diagram showing the communication control apparatus of the present invention. As shown in FIG. 8, the communication control apparatus of the present invention includes an ISAKMP control daemon 7, a kernel 8, a peer information database 9, and an SA information database 10. In the present embodiment, it is considered that the authentication process is performed between the initiator and the responder without using the Radius server described above.

  First, when the starter connects to the responder, the responder described above starts the processing of Phase1. Then, when the processing of Phase 1 is completed, the responder starts xauth authentication. The phase 1 processing may be performed in either the main mode or the aggressive mode.

  In xauth authentication, the responder sends a REQUEST packet to the initiator. When the initiator receives the REQUEST packet transmitted from the responder, the initiator sets the user name and IP address in the REPLY packet and transmits the packet to the responder.

  The responder receives the REPLY packet transmitted from the initiator. Then, the responder compares the user name and IP address set in the REPLY packet with the user name and IP address registered in the responder itself. If they match, the ISAKMP control daemon 7 inside the responder sends a SET packet transmission request to the Kernel 9 inside the responder based on the peer information registered in the peer information database 8.

  Kernel 9 that has received the SET packet transmission request transmits the SET packet to the initiator. The initiator who has received the SET packet transmits an ACK packet to the responder. When the responder receives the ACK packet transmitted from the initiator, the responder starts the process of Phase 2 described above.

  When the responder finishes the processing of Phase 2 described above, the ISAKMP control daemon 7 inside the responder notifies the Kernel 9 of completion of creation of the IPsec SA and registers the IPsec SA information in the SA information database 10. The Kernel 9 uses the SA information registered in the SA information database 10 and starts ESP communication between the responder and the initiator.

  In the above description, the case where the control program for controlling the communication control device is stored in the ROM in advance has been described. However, the control program is recorded in advance on recording media such as various magnetic disks, optical disks, and memory cards. However, it is also possible to read and install from these recording media.

  It is also possible to provide a communication interface and download the control program via a network such as the Internet or LAN, and install and execute it. By configuring in this way, it becomes possible to configure a network device with higher functionality and higher reliability in terms of software.

  Note that the present invention is not limited to the above-described embodiment, and various modifications can be made without departing from the scope of the invention.

When performing extended authentication between the initiator and the responder by the communication control method of the present invention, it is not necessary to make an authentication inquiry to the Radius server each time. As a result, the amount of communication traffic is reduced and the network operation is improved, so the industrial applicability is high.

FIG. 1 is a diagram for explaining a main mode authentication method. FIG. 2 is a diagram for explaining an authentication method in the aggressive mode. FIG. 3 is a diagram schematically illustrating a network that performs authentication of a CPE device using an authentication server. FIG. 4 is a diagram for explaining a network authentication method for authenticating the CPE device shown in FIG. FIG. 5 is a conventional flowchart showing an authentication process between the responding Gateway and the Radius server. FIG. 6 is a diagram for explaining the authentication method of the present invention. FIG. 7 is a flowchart of the present invention showing an authentication process between the responder and the Radius server. FIG. 8 is a block diagram of the responder.

Explanation of symbols

1 Internet 2 Radius server 3 Gateway (responder)
4 ESP tunnel 5-1 to 5-3 CPE equipment (starter)
6 Network 7 ISAKMP control daemon 8 Peer information database 9 Kernel
10 SA information database

Claims (10)

  A receiving step in which the responder receives an authentication packet transmitted from the initiator, an authentication inquiry step in which an authentication inquiry is made from the responder to the authentication server, and an authentication determination step of determining whether or not the authentication inquiry is successful; A communication control method comprising an authentication continuation step for continuing negotiation when the authentication inquiry is successful, and when the initiator initiates a plurality of negotiations from the initiator to the responder, A communication control method, comprising: an authentication determination step for determining whether or not it is an initial negotiation for starting a connection with a responder.   When it is determined that the authentication determination step is the first negotiation, the second and subsequent negotiations are performed by comparing the authentication information of the authentication packet transmitted from the initiator and the authentication information of the responder. The communication control method according to claim 1, wherein if the result matches, the authentication is determined to be successful.   The communication control method according to claim 2, wherein the authentication information includes a user name, an IP address, and a password.   A receiver that receives the authentication packet transmitted from the initiator, an authentication inquiry unit that makes an authentication inquiry from the responder to the authentication server, and an authentication determination unit that determines whether or not the authentication inquiry is successful; An authentication continuation unit that continues negotiation when the authentication inquiry is successful, and when the initiator performs negotiations from the initiator to the responder a plurality of times, the initiator A communication control apparatus, comprising: an authentication determination unit that determines whether or not it is an initial negotiation for starting a connection to a responder.   When the authentication determination unit determines that it is the first negotiation, the second and subsequent negotiations compare the authentication information of the authentication packet transmitted from the initiator and the authentication information of the responder, and compare 5. The communication control apparatus according to claim 4, wherein if the result is a match, it is determined that the authentication is successful. The communication control apparatus according to claim 5, wherein the authentication information is a user name, an IP address, and a password.   When the responder receives an authentication packet transmitted from the initiator, causes the responder to make an authentication inquiry to the authentication server, determines whether the authentication inquiry is successful, and if the authentication inquiry is successful, A control program for controlling a communication control device for continuing negotiation by a computer, wherein the starter initiates a connection to the responder when the starter negotiates a plurality of times with the responder. A control program for judging whether or not.   When it is determined that the determination is the first negotiation, the second and subsequent negotiations are performed by comparing the authentication information of the authentication packet transmitted from the initiator and the authentication information of the responder. The control program according to claim 7, wherein when the two match, the authentication is determined to be successful.   The control program according to claim 8, wherein the authentication information is a user name, an IP address, and a password.   A computer-readable recording medium on which the control program according to any one of claims 7 to 9 is recorded.

Images