JP4874037B2 - Network equipment - Google Patents

Description

  The present invention relates to a network device that can control IPsec (Security Architecture for Internet Protocol) in units of users as well as devices.

  It has become possible to maintain safety on the communication path by encrypting communication by IPsec (for example, see Patent Documents 1 and 2).

  With regard to IPsec authentication and access control, in the Phase 1 processing by IKE (Internet Key Exchange), which is processing for generating an IPsec encrypted shared key, the standard is X. which is an international standard for user names and directory services. Those defined in 500 can also be used.

  However, since it is assumed that the data is set in a device and processed, an identifier for distributing data is premised on an IP (Internet Protocol) address and a MAC (Media Access Control) address.

Similarly, as an IPsec access database, it is instructed by the standard to sort by IP address.
JP 2006-20266 A JP 2006-20262 A

  As described above, since an IP address or a MAC address has been conventionally used as an administrative identifier, in the IKE portion authenticated as personal authentication, it is ensured that the device is correct, but the user who uses it is The right thing is not secured.

  For this reason, for example, in an environment where a plurality of users share a device such as one MFP (Multi Function Printer), the protocol itself has an authentication mechanism such as ROW data printing from port 9100, LPR (Line PRinter daemon protocol), etc. There was a problem that printing was possible from any user logged in to the device as long as it was authenticated by the device. In addition to printing, authentication data cannot be passed on the protocol for execution of rsh (remote shell) commands and DNS (Domain Name System) name resolution using User Datagram Protocol (UDP). was there.

  In the current IPsec, since there is a specification that only a packet that can be described by one ID can be passed, only access control can be performed by finely setting IPsec SA (Security Association), and users can be set as a unit. It was difficult to achieve access control.

  On the other hand, user authentication and encryption can be performed by using SSL (Secure Socket Layer). However, since SSL depends on the protocol, the application needs to be changed and it is difficult to introduce it into an existing system. is there.

  The present invention has been proposed in view of the above-described conventional problems, and an object of the present invention is to provide a network device capable of performing IPsec control in units of users as well as devices. is there.

In order to solve the above-mentioned problem, in the present invention, as described in claim 1, primary IPsec means for applying primary IPsec to communication data based on IPsec SA authenticated by a device; A secondary IPsec means for applying a secondary IPsec based on the IPsec SA authenticated by the user for the payload to which the primary IPsec is applied, and authenticating with a user ID and a password by an authentication server. The gist is a network device that applies the second-order IPsec using the identifier and the common key acquired from the above .

  Further, as described in claim 2, in the network device according to claim 1, authentication is performed using an identifier determined on the transmission side and the destination side and a common key for the identifier, and the authenticated identifier Can be used for the selector of the secondary IPsec that is applied to the payload.

  Further, as described in claim 3, in the network device according to claim 1, an identifier and a common key for user authentication can be managed by a server.

Further, as described in claim 4 , in the network device according to claim 1, in the stage of creating the primary IPsec, capability exchange means for identifying whether or not the other party supports the secondary IPsec. And the capability exchanging means can make an inquiry by packet exchange by Private USE .

Further, as described in claim 5 , in the network device according to claim 1, the authentication by the user is determined to be appropriate when an ID exists in the database and the access condition is satisfied. Can be.

In addition, as described in claim 6 , in the network device according to claim 1, the destination device has access permission of the device after the decryption of the primary IPsec, and the secondary IPsec If the user has permission to access after descrambling, the received packet can be sent to a higher-level process.

Further, as described in claims 7 and 8 , it can be configured as an access control method.

  In the network device of the present invention, by applying double IPsec, IPsec control can be performed not only for the device but also for each user or the like, and appropriate access control can be performed.

  Hereinafter, preferred embodiments of the present invention will be described.

<System configuration>
FIG. 1 is an overall configuration diagram showing an embodiment of a network system using a network device of the present invention.

  In FIG. 1, network devices 1A and 1B and an authentication server (XAUTH server) 2 are connected on a network 3. Note that the authentication server 2 is not essential and is provided as necessary. In addition, in the description of operations described later, it is assumed that communication is performed between the network device 1A and the network device 1B. However, the communication is not limited to the same network 3, but communicates with a network device in another segment via a router or the like. Is also possible.

  FIG. 2 is a diagram showing an example of the internal configuration of the network device 1 (1A, 1B).

  In FIG. 2, the network device 1 includes an application 11 that uses communication, a network processing unit 12 that performs network control, an IKE processing unit 13 that is inside the network processing unit 12 and performs key exchange processing, and an IPsec setting. An IPsec SA database 14, an IP processing unit 15 for processing an IP layer of IPv4 (Internet Protocol version 4) and IPv6 (Internet Protocol version 6), and a primary IPsec and an IP processing unit 15 inside the IP processing unit 15. An IPsec processing unit 16 that performs secondary IPsec processing and an I / F processing unit 17 that interfaces with a network are provided.

<Basic double IPsec>
FIG. 3 is a diagram showing an example of the IPsec SA database 14, wherein (a) shows a primary IPsec SA and (b) shows a secondary IPsec SA. The primary IPsec SA shown in (a) holds information such as a source address, a destination address, a source port, a destination port, an encryption method, and an authentication method. The secondary IPsec SA shown in (b) holds information such as an identification ID for identifying a user (identifier common to the transmission side and the destination side), a transmission source port, a destination port, an encryption method, and an authentication method. .

  FIG. 4 is a diagram illustrating an example of negotiation for double IPsec.

  In FIG. 4, assuming that the network device 1A is the transmission side and the network device 1B is the destination side, the primary IPsec is performed based on the primary IPsec SA (FIG. 3A) in response to a request from the network device 1A. Device authentication (PreShareKey, digital signature, public key authentication, etc.) by Phase 1 and key exchange are performed (step S101), and then the primary IPsec encryption method, encryption key, and SA are determined by primary IPsec Phase 2 (step S101). S102). After this, encrypted communication by primary IPsec is performed.

  Next, based on the secondary IPsec SA (FIG. 3B), user authentication by the secondary IPsec Phase1 (Fully Qualified Domain Name (FQDN), PreShareKey, digital signature, release by the user ID specified by X.500, etc. Key authentication, etc.) and key exchange (step S103), and then the secondary IPsec encryption method, encryption key, and SA are determined by the secondary IPsec Phase 2 (step S104). Thereafter, encrypted communication to which the primary IPsec and the secondary IPsec are applied is performed (step S105).

  FIG. 5 is a flowchart showing an example of processing on the destination side of user authentication by secondary IPsec Phase1.

  In FIG. 5, when the process is started (step S111), the IPsec SA database 14 is searched with the ID transmitted from the network device 1A on the transmission side (step S112), and it is determined whether or not the ID exists (step S113). .

  If the ID exists (YES in step S113), the IPsec SA database 14 is further searched (step S114), it is determined whether the access condition is met (step S115), and the case where the access condition is met (YES in step S115) is common. The key is confirmed (step S116), and the process is terminated (step S118).

  On the other hand, if the ID does not exist (NO in step S113) or does not meet the access condition (NO in step S115), an access discard command is transmitted to the transmitting side (step S117), and the process ends (step S118). ).

  6 to 9 are diagrams showing the structure of communication data to which primary IPsec and secondary IPsec are applied. FIG. 6 shows a case where the secondary is based on AH (Authentication Header) and the primary is based on ESP (Encapsulating Security Payload). 7 shows the case where the secondary is based on ESP and the primary is based on ESP, FIG. 8 shows the case where the secondary is based on AH, the primary is based on AH, and FIG. 9 shows the case where the secondary is based on ESP and the primary is based on AH. The case of the transport mode and the case of the tunnel mode are shown for each of the primary IPsec and the secondary IPsec. Identifier data as a selector for identifying a user is added to a payload to which primary IPsec is applied.

  FIG. 10 is a flowchart showing a processing example of double IPsec data decoding.

  In FIG. 10, when the process is started (step S121), the encryption of the primary IPsec is released (step S122), and it is determined whether there is a device access permission with reference to the IPsec SA database 14 (step S123).

  If the device has access permission (YES in step S123), the secondary IPsec encryption is canceled (step S124), and it is determined whether or not there is access permission for the identifier indicating the user by referring to the IPsec SA database 14 (step S124). In step S125), if there is permission to access the identifier (YES in step S125), the packet is sent to the higher-level process (step S126), and the process ends (step S128).

  On the other hand, if there is no device access permission (NO in step S123) or no identifier access permission (NO in step S125), the packet is discarded (step S127), and the process is terminated (step S128).

  In the above-described method, user authentication data needs to be previously stored in the IPsec SA database 14 as common data. However, in this case, it is necessary to insert authentication data for each device for access control, and putting authentication data in advance is dangerous in operation because there is a possibility of leakage. In order to improve this point, it is desirable to use a digital signature for the authentication data.

  In this case, instead of using a common identification ID and a common authentication key, digital signature authentication using an external server is performed for this part. The identification ID at this time is X. A 500 IPsec tree structure is created, and this identifier is embedded as an ID to create a secondary IPsec SA. An example of the secondary IPsec SA in this case is shown in FIG. The primary IPsec SA is the same as that shown in FIG.

<Dual IPsec with XAUTH authentication>
In the embodiment described above, it is necessary to store user control information in the IPsec SA database 14 as common data in advance. For this reason, the setting becomes complicated as the number of devices increases. Therefore, by generating a secondary IPsec SA in conjunction with user / password authentication by XAUTH, access control can be managed by the server.

  FIG. 12 is a diagram illustrating an example of double IPsec negotiation using authentication by XAUTH.

  In FIG. 12, assuming that the network device 1A is the transmission side and the network device 1B is the destination side, device authentication and key exchange are performed by the primary IPsec Phase 1 in response to a request from the network device 1A (step S201). Subsequently, the user and password are authenticated by the authentication server (XAUTH) 2 (step S202). Then, the user name is set as the FQDN name in the selector of the secondary IPsec SA. This creates a user-authenticated SA.

  Next, the primary IPsec encryption method, encryption key, and SA are determined by the primary IPsec Phase 2 (step S203). After this, encrypted communication by primary IPsec is performed.

  Next, device authentication and key exchange are performed using the secondary IPsec Phase 1 (step S204), and then the secondary IPsec encryption method, encryption key, and SA are determined using the secondary IPsec Phase 2 (step S205). Thereafter, encrypted communication to which the primary IPsec and the secondary IPsec are applied is performed (step S206).

  Note that authentication of the user and password by XAUTH (step S202) involves authentication data communication and needs to be encrypted at the minimum, so it must be after the first IPsec Phase1 (step S201). However, the position can be changed before the second IPsec Phase 2 (step S205). That is, it can be placed immediately after the primary IPsec Phase 1 (step S204), immediately after the primary IPsec Phase 2 (step S203), or immediately after the secondary IPsec Phase 1 (step S204). However, since the processing of Phase 1 is relatively heavy and authentication may fail and processing up to that time may be wasted, it is most preferable immediately after the primary IPsec Phase 1 (step S201).

<Double IPsec using capability exchange by Private USE>
In each of the embodiments described above, communication is not possible unless both the primary IPsec and the secondary IPsec are generated. For this reason, there is a situation in which user authentication is not particularly required for data for confirming a network environment such as UDP used for confirming a state as a device, data for confirming a state between devices, and the like. Therefore, by setting a selector that processes only in the primary IPsec and providing a mechanism that can specify whether or not the secondary IPsec can be used, it is possible to control what requires and does not require user authentication. . As a result, only the primary IPsec provides only low-importance information, and the secondary IPsec provides high-importance information.

  FIG. 13 is a diagram showing an example of the IPsec SA database 14, and the secondary IPsec SA holds information such as a transmission source identification ID, a destination, a transmission source port, a destination port, an encryption method, and an authentication method. The primary IPsec SA is the same as that shown in FIG.

  FIG. 14 is a diagram illustrating an example of double IPsec negotiation using capability exchange by Private USE.

  In FIG. 14, assuming that the network device 1A is the transmission side and the network device 1B is the destination side, device authentication and key exchange are performed by the primary IPsec Phase 1 in response to a request from the network device 1A (step S301). Subsequently, it is confirmed whether or not the secondary IPsec is supported by Private USE (step S302). FIG. 15 is a diagram showing a state of packet exchange by Private USE. Capability exchange is performed by adding Private USE data to an ISAKMP (Internet Security Association Key Management Protocol) header and performing data communication.

  Returning to FIG. 14, the primary IPsec encryption method, encryption key, and SA are determined by the primary IPsec Phase 2 (step S303). After this, encrypted communication by primary IPsec is performed.

  After that, when secondary IPsec is not supported by capability exchange by Private USE (step S302), an operation when secondary IPsec processing cannot be performed is separately defined, and processing is performed in accordance with the rules. A situation that does not support secondary IPsec is also set as a selector (FIG. 13).

  Next, when the secondary IPsec is supported, the device authentication and key exchange are performed by the secondary IPsec Phase 1 (step S304), and then the secondary IPsec encryption method and the encryption key by the secondary IPsec Phase 2 are performed. , SA is determined (step S305). Thereafter, encrypted communication to which the primary IPsec and the secondary IPsec are applied is performed (step S306).

  It should be noted that although an example in which confirmation of whether or not the secondary IPsec is supported by the private USE (step S302) is performed immediately after the primary IPsec Phase1 (step S301), the capability exchange by the private USE is performed even in a plain text state. Since there is no problem, it may be immediately before the primary IPsec Phase 1 (step S301) or immediately after the primary IPsec Phase 2 (step S303).

  FIG. 16 is a flowchart showing a processing example of double IPsec data decoding.

  In FIG. 16, when the process is started (step S311), the encryption of the primary IPsec is released (step S312), and it is determined whether or not the device has access permission with reference to the IPsec SA database 14 (step S313).

  When there is a device access permission (YES in step S313), it is determined whether secondary IPsec is applied (step S314).

  When secondary IPsec is applied (YES in step S314), the encryption of the secondary IPsec is released (step S315), and it is determined whether or not there is access permission for the identifier indicating the user by referring to the IPsec SA database 14. If the identifier is permitted to access (YES in step S316), the packet is sent to the higher-level process (step S317), and the process ends (step S320).

  On the other hand, if secondary IPsec is not applied (NO in step S314) or if there is no identifier access permission (NO in step S316), it is determined whether the protocol and port are permitted to be accessed (step S318). If it is an access-permitted protocol and port (YES in step S318), the packet is sent to the upper process (step S317), and the process is terminated (step S320).

  If there is no device access permission (NO in step S313), or if the access is not permitted for the protocol and port (NO in step S318), the packet is discarded (step S319), and the process is terminated (step S320). .

<Summary>
As described above, according to the present invention, the IPsec SA authenticated by the device and the IPsec SA authenticated by the user can be used, and different IPsec SAs can be created when the devices are used in common. Therefore, even if a plurality of users share the device, access control can be performed by changing authentication data.

  For example, in an environment where a plurality of users share a single device such as an MFP, IPsec 2 is used even when using a protocol that does not have an authentication mechanism in the protocol itself, such as ROW data printing from port 9100, LPR, etc. Since user authentication can be performed in a duplicated manner, a person who is permitted to print and a person who is not permitted to print can be used separately.

  Similarly, in the execution of the rsh command, DNS name resolution by UDP, etc., it is possible to process only authorized users.

  In this case, compared to protocol-dependent encryption such as SSL, device authentication and personal authentication can be performed at the TCP / IP layer regardless of the protocol, and therefore can be applied without changing the application.

  The present invention has been described above by the preferred embodiments of the present invention. While the invention has been described with reference to specific embodiments, various modifications and changes may be made to the embodiments without departing from the broad spirit and scope of the invention as defined in the claims. Obviously you can. In other words, the present invention should not be construed as being limited by the details of the specific examples and the accompanying drawings.

1 is an overall configuration diagram showing an embodiment of a network system using a network device of the present invention. It is a figure which shows the internal structural example of a network apparatus. It is a figure which shows the example of an IPsec SA database. It is a figure which shows the example of the negotiation for double IPsec. It is a flowchart which shows the example of a process in the destination side of the user authentication by secondary IPsec Phase1. It is a figure which shows the structure of communication data in case secondary is based on AH and primary is based on ESP. It is a figure which shows the structure of communication data in case secondary is based on ESP and primary is based on ESP. It is a figure which shows the structure of communication data in case secondary is AH and primary is AH. It is a figure which shows the structure of communication data in case secondary is based on ESP and primary is based on AH. It is a flowchart which shows the process example of the data decoding of double IPsec. It is a figure which shows the example of an IPsec SA database. It is a figure which shows the example of the negotiation of double IPsec using the authentication by XAUTH. It is a figure which shows the example of an IPsec SA database. It is a figure which shows the example of the negotiation of the double IPsec using the capability exchange by Private USE. It is a figure which shows the mode of the packet exchange by Private USE. It is a flowchart which shows the process example of the data decoding of double IPsec.

Explanation of symbols

DESCRIPTION OF SYMBOLS 1, 1A, 1B Network equipment 11 Application 12 Network processing part 13 IKE processing part 14 IPsec SA database 15 IP processing part 16 IPsec processing part 17 I / F processing part 2 Authentication server 3 Network

Claims (8)

Primary IPsec means for applying primary IPsec to communication data based on IPsec SA authenticated by the device;
A secondary IPsec means for applying the secondary IPsec based on the IPsec SA authenticated by the user for the payload to which the primary IPsec is applied ,
A network device characterized in that authentication by a user ID and password is performed by an authentication server, and the second-order IPsec is applied using an identifier and a common key acquired from the authentication server . The network device according to claim 1,
A network device characterized in that authentication is performed by using an identifier determined on a transmission side and a destination side and a common key for the identifier, and the authenticated identifier is used for a secondary IPsec selector that applies to a payload. The network device according to claim 1,
A network device characterized in that an identifier and a common key for user authentication are managed by a server. The network device according to claim 1,
A capability exchanging means for identifying whether the other party supports the secondary IPsec in the stage of creating the primary IPsec ;
The network device according to claim 1, wherein the capability exchange means makes an inquiry by packet exchange by Private USE . The network device according to claim 1,
A network device characterized in that authentication by the user is judged to be appropriate when an ID exists in a database and an access condition is met. The network device according to claim 1,
The destination device sends the received packet to a higher-level process when there is device access permission after the primary IPsec decryption and when there is a user access permission after the secondary IPsec decryption Network equipment. A primary IPsec process for applying primary IPsec to communication data based on IPsec SA authenticated by the device;
A secondary IPsec process for applying a secondary IPsec based on a user-authenticated IPsec SA for a payload to which the primary IPsec is applied ,
An access control method comprising: authenticating with a user ID and password by an authentication server, and applying the second-order IPsec using an identifier and a common key acquired from the authentication server . The access control method according to claim 7 ,
An access control method, wherein authentication is performed by using an identifier determined on the transmission side and the destination side and a common key for the identifier, and the authenticated identifier is used for a secondary IPsec selector that applies the payload.

Images