JP2009200980A - Network system and method for distributing latest authentication key to dhcp client - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To easily distribute a latest authentication key to a DHCP client in a case where the authentication key is updated in a DHCP server, in a technique for presetting the same authentication key to both the DHCP server and the DHCP client and blocking a service of connection to the Internet or the like in a case where the DHCP client does not have the correct authentication key. <P>SOLUTION: In a network system using a TCP/IP protocol, when authenticating a DHCP signal, a DHCP server separates the dispensation of an address for dispensation to DHCP clients in accordance with contents of DHCP signals sent from the DHCP clients, so that each of the DHCP clients is caused to update an authentication key. <P>COPYRIGHT: (C)2009,JPO&INPIT

Description

  According to the present invention, when a DHCP (Dynamic Host Configuration Protocol) signal is authenticated in a network system using the TCP / IP protocol, the DHCP server determines an address to be paid out to the DHCP client according to the contents of the DHCP signal received from the DHCP client. The present invention relates to a system and method for distributing the latest authentication key to DHCP clients by separately paying out. The DHCP signal authentication means that a device (system component) that receives a DHCP signal verifies the received DHCP signal and confirms that the signal has been transmitted from a valid transmission partner.

  DHCP is a protocol in which when a client accesses a server and requests acquisition of an IP address, the server dynamically allocates an IP address to the client, and collects the “assigned IP address” when the IP connection of the client ends. In order to ensure security in the process of distributing IP addresses, RFC (Request for comments) stipulates authentication of DHCP signals exchanged between a DHCP server and a DHCP client. The RFC specifies a method using a DHCP authentication option (Authentication Option), a vendor-specific method using a vendor-extensible option, and the like for authentication between a server and a client.

  The DHCP authentication option is defined in Option 90 and RFC3118 in DHCPv4, and in Option 11 and RFC3315 in DHCPv6. On the other hand, options that can be extended by the vendor are also defined in the RFC.

  A conventional system (method) using the DHCP authentication option will be briefly described with reference to FIG.

In order to use the DHCP authentication option, first, the DHCP client HGW (Home Gate Way) and the DHCP server NACF (Network
In both Attachment Control Functions), a set of keys (a plurality of keys and a key ID for identifying the keys) used for the authentication option is set in advance. HGW and NACF are defined in ITU-TY.2012.

  When the DHCP client is activated, the DHCP client starts an IP address request to the DHCP server (DHCPDISCOVER / Solicit). DHCPDISCOVER (before the slash) is a display in DHCPv4, and Solicit (after the slash) is a display in DHCPv6 (the same applies hereinafter).

  When receiving the IP address request start signal (DHCPDISCOVER / Solicit) from the DHCP client (HGW), the DHCP server (NACF) is identified by a certain key (for example, key ID = 1) from a plurality of preset keys. (Selected key ID = 1) and “authentication information” are returned to the DHCP client (DHCPOFFER / Advertise). The authentication information is a hash value calculated from the DHCP message and the selected key.

  The DHCP client determines whether the authentication information is correct using the key specified by the received key ID = 1, and if the check is correct, sends the key ID = 1 and the authentication information to the DHCP server to distribute the IP address. Request (DHCPREQUEST / Request).

  If the DHCP server checks the authentication information sent from the DHCP client and determines that it is correct, the DHCP server selects one of the pooled IP addresses and sends it to the DHCP client (DHCPACK / Reply). . In this way, the DHCP server gives an IP address to the DHCP client while ensuring security by using an authentication option. In RFC, the key distribution method is not defined, and it is necessary to change the key periodically in order to ensure high security.

Another conventional technique will be described with reference to FIG. This prior art does not use the authentication option as described with reference to FIG. 9, but relates to authentication using vendor extension. Vendor extension is Vendor class option, Vendor-Specific
This applies when DHCP vendor extension options such as the Information option are used.

  The prior art shown in FIG. 10 is different from the case of FIG. 9 only in that the vendor extension option is used, and the operation sequence itself is substantially the same.

  In FIG. 10, in order to perform authentication using the DHCP vendor extension option, first, a plurality of keys to be used for authentication are set in advance on both the DHCP client (HGW) and the DHCP server (NACF). deep. When the DHCP client is activated, it sends a signal indicating the start of an authentication request to the DHCP server (DHCPDISCOVER / Solicit). When the DHCP server receives this authentication request start signal from the DHCP client, the DHCP server selects a key from a plurality of preset keys (assuming the selected key is XX), and selects the selected key. An authentication application signal, which is authentication information including information, is sent to the DHCP client (DHCPOFFER / Advertise). The authentication information is a hash value calculated from the DHCP message and the selected key, as in the case of FIG.

The DHCP client determines whether the authentication information is correct using the received key, and if it is correct, sends an authentication application signal, which is authentication information including the key information, to the DHCP server.
(DHCPREQUEST / Request). The DHCP server checks the authentication application signal sent from the DHCP client by using the previously selected key XX, and if it is judged correct, sends the IP address to the authentication application signal and sends it to the DHCP client. . The DHCP client checks the received authentication information using the previously selected key XXX, and if the check is correct, the received IP address is recognized as an official address, and the vendor-specific authentication ends.

  In the above-described prior art, the same key is set in advance for both the DHCP server and the DHCP client, and if the DHCP client does not have the correct authentication key, the connection service to the Internet or the like is blocked. In order to maintain the security of the connection method using the authentication key, it is necessary to update the authentication key periodically or irregularly on the DHCP server. When the authentication key is updated on the DHCP server, the DHCP client key must also be updated. However, there is no proposal for updating the authentication key of the DHCP client.

For example, Japanese Patent Application Laid-Open No. H10-228707 describes security improvement in a TCP / IP network using a DHCP server.
JP 2001-36561 A

  The same authentication key is set in advance on both the DHCP server and the DHCP client, and when the DHCP client does not have the correct authentication key, the authentication key is updated in the DHCP server in a method of blocking the connection service to the Internet or the like. In such a case, the latest authentication key can be easily distributed to the DHCP client.

  According to the present invention, in the network system using the TCP / IP protocol, the DHCP server, when authenticating the DHCP signal, assigns an address to be paid out to the DHCP client according to the contents of the DHCP signal sent from the DHCP client. By distributing the payout, the DHCP client is made to update the authentication key.

  In addition, the DHCP server receives an authentication key when the DHCP client does not request authentication of the DHCP signal, or when the DHCP client requests authentication of the DHCP signal but does not have the correct authentication key. An address that can be connected only to a server to be distributed is issued to the DHCP client.

  The DHCP server can distribute the latest DHCP authentication key to the DHCP client by distributing the address to be paid out to the client according to the DHCP signal from the DHCP client. Furthermore, when updating the DHCP authentication key, it is possible to avoid the troublesome task of separately installing new keys on both the server and the client.

  Hereinafter, the first embodiment will be described with reference to FIGS. The first embodiment is a case where an authentication option is used.

  FIG. 1 is a diagram for explaining the outline of the operation of the first embodiment. The DHCP server (NACF) has two types of address pools A and B. If the DHCP client (HGW) makes an address request without using the authentication option, or the authentication option has been used, but the correct key is not used. When an address request is made at, the address is paid out from the address pool A to the client. On the other hand, when the DHCP client has used the authentication option using the correct key, the address is paid out from the address pool B to the client.

  A DHCP client can access HGWC-FE (Home GateWay Configuration Functional Entity (ITU-T Y.2012)) with an address from address pool A, but it can access other networks such as the Internet (indicated by reference numeral 10). Can not. On the other hand, when a DHCP client uses an address from the address pool B, it can access a network such as the Internet (indicated by reference numeral 12) in addition to HGWC-FE.

  The addresses of pools A and B mean an IPv4 address in DHCPv4, and an IPv6 address and an IPv6 prefix in DHCPv6.

  An IP-Edge (DHCP relay agent) provided between the DHCP server and the DHCP client performs filtering setting that determines the connection destination of the DHCP client according to the type of address from the client. In other words, if the address from the DHCP client is issued from the pool A, the IP-Edge sets the DHCP client to allow connection only to the HGWC-FE, and the address from the DHCP client is set from the pool B. If it has been paid out, a setting is made to allow the DHCP client to connect to the HGWC-FE or to a network such as the Internet.

  Next, the first embodiment will be further described with reference to FIGS. As shown in FIG. 1, there is an IP-Edge between the DHCP client (HGW) and the DHCP server (NACP), but there is a systematic change that affects the signal content before and after the IP-Edge. 2 to 4, the illustration of IP-Edge is omitted.

  In FIG. 2, the DHCP client does not have the key required when using the authentication option. That is, in order for a DHCP client to access the network 12 (FIG. 1) such as the Internet, a key must be obtained from a DHCP server. First, the DHCP client initiates an IP address assignment request without using an authentication option (Solicit). Since the DHCP client does not use the authentication option, the DHCP server selects an address from the pool A and responds to the DHCP client (Advertise). The response signal (Advertise) does not include the selected address.

  Next, when the DHCP client makes an IP address assignment request to the DHCP server (Request), the DHCP server issues an address selected from the pool A and responds to the DHCP client (Reply). That is, the DHCP server passes the address selected from pool A to the DHCP client. At this address, the DHCP client can only access the HGWC-FE and not a network such as the Internet.

  For this reason, the DHCP client needs to access the HGWC-FE to obtain a key used for the authentication option, and then access the DHCP server to obtain the address selected from the pool B.

The DHCP client uses an address selected from pool A, and uses HTTPS (hypertext transfer protocol over transport layer security / secure).
Connect to the HGWC-FE by encrypted communication such as sockets layer). In response to this, the HGWC-FE makes a key acquisition request to the DHCP server (at this time, the HGWC-FE gives the DHCP client's IP address to the DHCP server). The DHCP server specifies the DHCP client from the IP address included in the key acquisition request from the HGWC-FE, selects the key ID and key set for the DHCP client, and requests the HGWC-FE to acquire the key. (The HGW key ID and key are transmitted). Next, the HGWC-FE distributes the received key ID and key to the DHCP client. Thus, the DHCP client will have a key and key ID that can be used for authentication options.

  FIG. 3 shows a sequence for using an authentication option using the key ID and key described in FIG. The DHCP client selects one of a plurality of keys that the DHCP client has, and accesses the DHCP server using an authentication option (Solicit). When the DHCP server confirms that the received key matches the self-owned key, the DHCP server recognizes that there is an authentication option, selects an address from the pool B, and responds to the DHCP client using the authentication option (Advertise). . The response signal (Advertise) does not include the selected address. In contrast, when the DHCP client responds to the DHCP server using the authentication option (Request), the DHCP server pays out the address paid out from the pool B and gives it to the DHCP client (Reply). Thus, DHCP clients can use this address to access other networks such as the Internet. Since the sequence in which the DHCP client accesses the Internet or the like is the same as the conventional one, the description is omitted.

  FIG. 4 is a diagram for explaining the update of the key used for the authentication option. When the DHCP client has the keys described in FIGS. 2 and 3 (key IDs 1 and 2), the DHCP server updated the keys (key IDs 1 and 2) to new keys (key IDs 3 and 4). And In this state, the DHCP client starts an IP address acquisition operation using the authentication option with respect to the DHCP server (Solicit). In this case, since the authentication option is used, the DHCP server selects an address from the pool B, and sends 3 or 4 of the updated authentication key ID to the DHCP client. Since the DHCP client does not have the updated key ID (and key) sent from the DHCP server, it deletes the key ID and key it possesses. As a result, the DHCP client has no key. Therefore, the DHCP client distributes the key updated by the new key distribution sequence described in FIG. 2 from the HGWC-FE.

  As described above, the DHCP server can distribute the latest DHCP authentication key to the DHCP client by distributing the address to be paid out to the client according to the DHCP signal from the DHCP client. Furthermore, according to the present invention, when updating the DHCP authentication key, it is possible to avoid a complicated operation of separately installing new keys on both the server and the client.

5 to 8 are diagrams for explaining a second embodiment of the present invention. This embodiment does not use an authentication option as in the first embodiment described above, but relates to authentication using vendor extension. Vendor extension is Vendor class option, Vendor-Specific
This applies when DHCP vendor extension options such as the Information option are used.

  FIG. 5 is the same as FIG. The DHCP server (NACF) shown in FIG. 5 includes two types of address pools A and B as described in FIG. 1, and the DHCP client (HGW) makes an address request without using the authentication option, or If the authentication option is used but an address request is made without using the correct key, the address is issued from the address pool A to the client. On the other hand, when the DHCP client has used the authentication option using the correct key, the address is paid out from the address pool B to the client. The other description of FIG. 5 is the same as that of FIG.

  6 to 8 correspond to FIGS. 2 to 4, respectively, and the operation sequence is substantially the same.

  In FIG. 6, as in the case of FIG. 2, the DHCP client does not have a key necessary for using authentication using vendor extension. That is, in order for the DHCP client to access the network 12 (FIG. 5) such as the Internet, the key must be received from the DHCP server. First, the DHCP client initiates an IP address assignment request without making an authentication request (Solicit). Since the DHCP client does not make an authentication request, the DHCP server selects an address from the pool A and responds to the DHCP client (Advertise). The response signal (Advertise) does not include the selected address.

  Next, when the DHCP client makes an IP address assignment request to the DHCP server (Request), the DHCP server issues an address selected from the pool A and responds to the DHCP client (Reply). That is, the DHCP server passes the address selected from pool A to the DHCP client. At this address, the DHCP client can only access the HGWC-FE and not a network such as the Internet.

  For this reason, the DHCP client needs to access the HGWC-FE to obtain the key used for the authentication request, and then access the DHCP server to obtain the address selected from the pool B.

  The DHCP client uses the address selected from the pool A and connects to the HGWC-FE by encrypted communication such as HTTPS. In response to this, the HGWC-FE makes a key acquisition request to the DHCP server (at this time, the HGWC-FE gives the DHCP client's IP address to the DHCP server). The DHCP server specifies the DHCP client from the IP address included in the key acquisition request from the HGWC-FE, selects the key ID and key set for the DHCP client, and requests the HGWC-FE to acquire the key. (The HGW key ID and key are transmitted). Next, the HGWC-FE distributes the received key ID and key to the DHCP client. Thus, the DHCP client will have a key and key ID that can be used for authentication options.

  FIG. 7 shows a sequence in which a DHCP server and a DHCP client perform authentication using vendor extension using the same key. The DHCP client selects one of a plurality of keys that the DHCP client has, and transmits an authentication request signal to the DHCP server (Solicit). When the DHCP server confirms that the sent key matches the self-owned key, the DHCP server recognizes that there is an authentication request, selects an address from the pool B, and sends an authentication application signal to the DHCP client (Advertise). The authentication applied signal (Advertise) does not include the selected address. In contrast, when the DHCP client sends an authentication application signal to the DHCP server (Request), the DHCP server pays out the address paid out from the pool B and gives it to the DHCP client (Reply). Thus, DHCP clients can use this address to access other networks such as the Internet. Since the sequence in which the DHCP client accesses the Internet or the like is the same as the conventional one, the description is omitted.

  FIG. 8 is a diagram for explaining updating of a key used for the authentication option. Assume that when the DHCP client has the key described in FIGS. 6 and 7, the DHCP server updates the key to a new key. In such a state, the DHCP client issues an authentication request signal to the DHCP server (Solicit). In this case, the DHCP server determines that there is an authentication request, selects an address from the pool B, adds an updated authentication key, and sends an authentication application signal to the DHCP client. However, since the DHCP client does not have the updated key sent from the DHCP server, it deletes the possessed key. As a result, the DHCP client has no key. Therefore, the DHCP client distributes the key updated by the new key distribution sequence described in FIG. 6 from the HGWC-FE.

  As described above, the DHCP server can distribute the latest DHCP authentication key to the DHCP client by distributing the address to be paid out to the client according to the DHCP signal from the DHCP client. Furthermore, when updating the DHCP authentication key, it is possible to avoid the troublesome task of separately installing new keys on both the server and the client.

The figure explaining 1st Embodiment The figure explaining 1st Embodiment The figure explaining 1st Embodiment The figure explaining 1st Embodiment The figure explaining 2nd Embodiment The figure explaining 2nd Embodiment The figure explaining 2nd Embodiment The figure explaining 2nd Embodiment The figure explaining 1st prior art The figure explaining the 2nd conventional technology

Explanation of symbols

10 Network such as the Internet 12 Network

Claims (10)

  In a network system using the TCP / IP protocol, when a DHCP server authenticates a DHCP signal, the DHCP server distributes an address to be paid out to the DHCP client according to the contents of the DHCP signal sent from the DHCP client. A network system characterized by causing a DHCP client to update an authentication key.   If the DHCP client does not request authentication of the DHCP signal, or if the DHCP client requests authentication of the DHCP signal but does not have the correct authentication key, the DHCP server is the only server that distributes the authentication key. 2. The network system according to claim 1, wherein an address that can be connected to the network is issued to the DHCP client.   2. The network system according to claim 1, wherein the DHCP server issues an address that can be connected to a network such as the Internet to the DHCP client when the DHCP client determines that the authentication of the DHCP signal is correct.   4. The network system according to claim 1, wherein an authentication option is used for DHCP signal authentication.   4. The network system according to claim 1, wherein the authentication of the DHCP signal is unique to the vendor using an option that can be expanded by the vendor.   In a network system using the TCP / IP protocol, a DHCP server examines the contents of a DHCP signal sent from a DHCP client when authenticating the DHCP signal, and pays out to the DHCP client according to the result of the examination. An authentication key update method, characterized by causing a DHCP client to update an authentication key by distributing addresses.   If the DHCP client does not request authentication of the DHCP signal, or if the DHCP client requests authentication of the DHCP signal but does not have the correct authentication key, the DHCP server is the only server that distributes the authentication key. The authentication key update method according to claim 6, wherein an address that can be connected to the DHCP client is paid out to the DHCP client.   7. The authentication key update method according to claim 6, wherein when the DHCP client determines that the authentication of the DHCP signal is correct, the DHCP server issues an address connectable to a network such as the Internet to the DHCP client.   9. The authentication key update method according to claim 6, wherein authentication of the DHCP signal uses an authentication option.   9. The authentication key update method according to claim 6, wherein authentication of the DHCP signal is unique to the vendor using an option that can be expanded by the vendor.

Images