Server, terminal control device and terminal authentication method

Information on whether a prefix is distributable to a MN is held by a CA. The server section of the HA allots prefix information to a MN approved by the CA. When the server section of the HA receives an IKE packet from the MN, the server section generates an IPsec SA after checking the prefix information in the server section. The server section allows an MN location registration request to fulfill the IPsec SA. The CA approves distribution of a prefix to the MN and verifies that the MN is genuine by generating an IPsec SA with the HA by utilizing the prefix distributed by the MN.

PRIORITY CLAIM

This application claims priority under 35 USC 119 to Japanese patent application P2003-064329 filed Mar. 11, 2003, the entire disclosure of which is hereby incorporated by reference.

FIELD OF THE INVENTION

The present invention relates to a server, mobile control device, and terminal authentication method. The present invention relates in particular to a server, home agent device and terminal authentication method for guaranteeing and issuing public key certifications in communication systems using mobile IP protocol.

BACKGROUND OF THE INVENTION

The IETF (Internet Engineering Task Force) is evaluating specifications for Mobile IPv6 (Ref. Mobility Support in IPv6 <draft-ietf-mobileip-ipv6-19.txt>, Work in Progress).

The elements comprising the Mobile IPv6 network are a mobile node (MN), a home agent (HA), and correspondent node (CN).

The MN is assigned an IP address (home address) that does not change even if the MN moves. A link possessing a prefix identical to the home address is called a home link. The HA manages MN location information (binding cache) in locations other than the home link.

The MN acquires a Care of Address (hereafter CoA) for links other than the home link. The MN that is not within the home link receives router reports (advertisements) sent periodically by a router within the visited link. The MN senses movement by detecting a prefix different from the home address and generates a CoA. The MN registers (stores) information linking the CoA and home address within the HA.

The MN contains a home agent address discovery function (function for finding the HA address) and may actively search for the IP address of the HA. The MN first of all creates a Mobile IPv6 Home-Agents Anycast Address from the prefix of the home link. The MN sends an ICMP Home Agent Address Discovery Request to the address destination. This signal is received by one of the home link HA. The HA that received the signal sends an ICMP Home Agent Address Discovery Reply containing information on the HA to the MN. The MN extracts the HA information from this signal and acquires the HA address. The MN sends a binding update for that HA address.

The HA receives the binding update and stores the MN location information in the binding cache.

In order to function as a proxy for the MN, the HA sends a neighbor advertisement addressed to all-nodes multicast addresses of the home link. The node that received that neighbor advertisement, stores information linking the MN home address and HA link layer address, in the neighbor cache. The HA captures the packet addressed to the home address of the MN.

Mobile IPv6 contains a function to notify MN outside the home link, of home network prefix information. For example, if the prefix of the home network has been changed, the HA refers (searches) the binding cache and reports the prefix information (makes a mobile prefix advertisement) to the MN among the registered positions. The MN may also make a request to the HA for prefix information (mobile prefix solicitation).

The IP Security Protocol (IPsec) is the focus of attention as a technology for achieving security on the IP network. This IPsec is a technology for safely conveying IP packets by utilizing encryption technology and certification technology. Mobile IPv6 is applying this IPsec technology in the sending of location registration signals (binding updates) from the MN to the HA (Ref. draft-ietf-mobileip-mipv6-ha-ipsec-01.txt, Work in Progress).

This IPsec technology provides a security function by creating an SA (security association) among the devices using IPsec. The devices utilizing IPsec contain a SPD (security policy database) and an SAD (security association database).

The security policy database (SPD) specifies the method for processing the packets. The security association database (SAD) is a list of SA (security associations) held in the devices using IPsec. The SA is identified by a SPI (Security Parameters Index).

The method for creating the SA includes a manual setting method and an automatic creation method. The IKE (Internet Key Exchange) is a protocol for automatically creating and managing these SA. The IKE automatically generates the SA by making use of a proposal exchange function, a function to generate a secret key, and a certification function for IKE correspondent nodes.

Certification methods specified for IKE correspondent nodes are the Pre-shared key authentication method, public key certification method, digital signature authentication method, etc. The digital signature authentication method is highly flexible since it need not share key information beforehand with the other communication party (or correspondent node). The digital signature certification method is used by the CA (Certification Authority) for issuing public key certifications. The format for public key certification is the specified in X. 509.

The CMP (Certificate Management Protocol) is a protocol for issuing and managing electronic certifications. The CMP is specified in IETF RFC2510. The CMP is utilized in transport protocols in HTTP (HyperText Transfer Protocol) and TCP (Transmission Control Protocol).

One technology proposed for localized mobility management based on Mobile IPv6 is Hierarchial Mobile IPv6 mobility management (HMIPv6) (Ref. draft-ietf-mobileip-hmipv6-07.txt, Work in Progress). This HMIPv6 contains a MAP (Mobile Anchor Point) between the HA and MN. The MN receives a router advertisement containing MAP options from the AR (Access Router), acquires the MAP IP address, and generates a RCOA (Regional Care of Address) and LCoA (On-link CoA). The MN compatible with HMIPv6 registers location information in the MAP and HA. The MAP manages the binding information of the MN RCoA and LCoA. The HA manages the binding information of the MN home address and RCoA. The MN only rewrites (updates) the MAP location information when the MN has moved within the MAP.

The IETF is currently evaluating IPv6 Prefix Delegation Options for DHCPv6 (hereafter, DHCP-PD) (draft-ietf-dhc-dhcpv6-opt-prefix-delegation-01.txt, Work in Progress). The DHCP-PD is a function making use of DHCP (Dynamic Host Configuration Protocol) to assign IPv6 prefixes (group) to sites from the address assignment side.

The elements comprising the DHCP-PD are the delegating router and the requesting router. The requesting router asks the delegating router to assign an IPv6 prefix (group). The delegating router selects an IPv6 prefix (group) and sends that to the requesting router. The DHCP-PD for example, is utilized by the ISP (Internet Service Provider) when assigning prefixes to subscribers.

In a communication system mutually connected to both a zone A and zone B, when a mobile node (MN) belonging to zone A has moved to zone B, that MN registers its location in the HA of zone A. The location registration signal (binding update signal) is then subjected to IPsec processing.

The related art has the problem that security cannot be maintained when manually setting the SA (security association) for the HA and MN, and information about the key used in encryption has leaked out. Also, using the Mobile IPv6 prefix report (advertise) function and HA address discovery function will change the home address of the MN or HA address. The method for manually setting the SA between the MN and HA is therefore not practical during system operation. There is also no means for currently verifying on Mobile IP if the MN is genuine.

SUMMARY OF THE INVENTION

The present invention may provide a terminal authentication method that utilizes Mobile IP technology. In particular, this invention may provide a procedure for authenticating terminals by linking a digital signature authentication method with a Mobile IP location registration procedure, and by creating and holding a SA (security association) for a home address linked to the HA issuing public key certifications.

The present invention may also to provide a system for authenticating genuine terminals by linking a DHCP-PD delegating router and CA, and by linking a DHCP-PD delegating router and HA, when the MN is dynamically acquiring a home address.

The present invention in particular may have the following features when a terminal x of a home network with an HA belonging to zone A, utilizes a DHCP-PD section in zone B to acquire a home network prefix.1) The DHCP-PD delegating router may allot prefix information to a terminal approved by CA.2) The HA creates an SA for an IP address possessing a prefix allocated by that delegating router, and approves location registration to satisfy the SA.

The present invention may also to provide an authentication method for a DHCP delegating router to allot prefix information to terminals approved by the CA, when a communication device belonging to zone B possesses a HMIPv6 compatible MAP, and that communication device receives a binding update from the MN and starts the DHCP-PD section.

The present invention may also provide a communication method for the HA to report prefix information to a terminal approved by CA.

More specifically:(1) The CA may be comprised of a system for communicating with a DHCP-PD delegating router section16as show inFIGS. 2,20, and23. The CA issues a public key certification to the terminal and allows reporting prefix information.(2) The terminal is comprised of a Mobile IPv6 function, an IPsec function, and a function to hold information required for a digital signature name. Information required for authenticating a digital signature name may be received from an external storage device. The terminal need not be a mobile terminal.(3) The terminal control device contains a delegating router function for a DHCPv6 Prefix delegation option (hereafter, DHCP-PD). The delegating router function is comprised of a system for communicating with CA, and a system for reporting prefix information to a terminal approved by CA.(4) The terminal control device inquires about prefix information to the DHCP-PD delegating router function when a request to create an SA is received from the terminal. The terminal control device comprises a system to create an SA among terminals if the terminals utilize prefixes allotted by the delegating router function.(5) The terminal control device may contain a storage device or system to hold the public key certification for a terminal. Prefix information may be conveyed to terminals approved by the CA.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

First Embodiment

The first embodiment of the present invention is described next while referring to the accompanying drawings. In this embodiment, the HA is equivalent to a terminal control device.

The MN authentication method and location registration method used when the Mobile IPv6 compatible mobile node (MN) is in a network (hereafter, visited network) other than the home link (hereafter, home network) is described in detail.

FIG. 1shows the structure of the communication network of the present invention. The communication network is comprised of a home network8for MN4, an IP network7and a visited network5(5a,5b). In this embodiment, the home network8, the IP network7and the visited network5are IPv6 networks. The MN4is a mobile node (MN) compatible with Mobile IPv6. The information appliance terminal9contains MN functions compatible with Mobile IPv6. The visited network5and IP network7, and the IP network7and home network8are connected by router or a gateway device. The visited network5and home network8may also be directly connected by a router or a gateway device.

The home network8contains a home agent HA1. The HA1 is a home agent (HA) compatible with Mobile IPv6. The HA1 manages MN location information other than in the home network8.

The visited network5(5a,5b) is comprised of a communication device2(2a,2b) and a router6(6a,6b,6c,6d). The communication device2is comprised of an interface with a router6, and an interface with an IP network7. The router6contains a device authentication function.

Instead of the device authentication function, the router6may utilize a system for communicating with a server possessing a device authentication function.

The IP network7contains the CA3. The home network8or the visited network5may also contain the CA3.

FIG. 2shows the structure of the HA1 installed in the home network8of MN4. The HA1 is comprised of a server section11, (11a,11b) , a server section12, and an interface section (IF)19(19a,19b,19m,19n) containing a line18(18a,18b,18m,18n) and, a switch section17(17a,17b).

The server section11mainly contains a packet transmit-receive processor13, an IPsec processor14, and a mobile IP processor15. The packet transmit-receive processor13contains a function to transmit or receive data packets. The IPsec processor14contains mainly an SPD, SAD and an IPsec processing routine70. The IPsec processor14authenticates packets and performs encoding. The IPsec processor14acquires server section11public key certification from the CA3. The mobile IP processor15contains a Mobile IPv6 for the home agent (HA) function. The mobile IP processor15contains a binding cache management table310.

FIG. 3shows the table structure of the binding cache management table310. The binding cache management table310stores at least a Care of Address (CoA)312acquired by the MN in the visited network for the MN home address311, and a Lifetime313showing the effective period of the binding cache.

The server section12contains a packet transmit-receive processor13and a DHCP PD section16.

The DHCP PD section16contains a DHCP-PD delegating router function. It also contains mainly a prefix control table320, a prefix delegation processing routine60, and a table linking the IA_PD for identifying the DHCP-PD and an MN identifier.

FIG. 4shows the structure of the prefix control table320. This prefix control table320in DHCP PD Section16stores at least an IAID322showing the prefix (group), an allocated prefix323, and a lifetime324of the prefix, and shows the corresponding relation with the DHCP Client identifier321. The DHCP-PD section of the server12is mounted in HA1, however a DHCP-PD section may be mounted in a server separate from the HA1.

FIG. 7shows the structure of the certification authority (CA)3installed in the IP network7. The CA3is comprised a CPU31, a memory32, and an interface section (IF)33containing the line34, and a bus35connecting these components.

The memory32is comprised of at least a prefix allocation control table330and, a public key certification issue routine80, and a certifying information storage table.

FIG. 8shows the table structure of the prefix allocation control table330. The prefix allocation control table330stores a Prefix issue OK flag332showing whether or not permission to issue a prefix was issued to the identifier (ID)331of the terminal.

The sequence for location registration and authentication of MN4in the network5bshown inFIG. 1, is described according to the sequence shown inFIG. 17andFIG. 18. In this embodiment, the MN4contains a system to load the identifier and secret key and public key from a storage device typically a Secure Multimedia Card (SMMC), etc. The MN4further contains a DHCP-PD requesting router function.

When power is turned on, the MN4receives (101) a router advertisement from the router6cbelonging to the network5b. The MN4searches the M bit of the router advertisement and decides on a method for acquiring the CoA (Care of Address). If the M bit is 1, then MN acquires the CoA using the automated structure of the IPv6 statefull address. If the Mbit has not been set, then the Mbit creates a CoA (102) utilizing the automated structure of the IPv6 stateless address.

The MN4next sends a device authentication request to the router6c(103). The router6cauthenticates the device, using the device ID as a search (or retrieval) key. The router6csends (104) a device authentication response including the authentication results to MN4. A MAC address for example is utilized as the device ID.

When device authentication ends correctly, the MN4loads the MN4identifier and secret key and public key from a storage device such as the SMMC. The MN4identifier specifies for example, a FQDN (fully qualified domain name) or a distinguished name of X.500.

The MN4sends a public key certification issue request containing an MN4public key and identifier to the CA3(105). A CMP (Certificate Management Protocol) is utilized for sending and receiving the public key certification.

FIG. 11shows a packet format S1containing a CMP message.

FIG. 10shows the format of an IPv6 packet.

The CMP message S1is stored in data section43B within the payload43of the IPv6 packet.

The CA3receives the request and starts the public key certification issue routine80.

FIG. 9shows the public key certification issue routine80. The CA3confirms whether a certification can be issued to MN4using the MN4identifier (81). If a certification can be issued then the CA3issues a public key certification for MN4. The CA3next creates a new entry for MN4in the prefix allocation control table330, and sets up a prefix issue OK flag (82,106). The CA3sends a public key issue request response containing a public key certification for MN4and a public key for CN3, and ends this routine (83,107).

When the certification cannot be issued in step81, or in step82when the certification cannot be issued for a public key for MN4, the CA3issues a certification issue request response (84) to notify the MN4of the error and ends this routine.

The server section11of HA1 holds an identifier, a HA secret key and a HA public key. This procedure is similar to the procedure used by the MN which has its own MN secret and MN public key. The server section11acquires the public key certification from the CA3(for server section11) (183).

After acquiring the MN's public key certification, the MN4starts the prefix request process and acquires a home prefix.

To find a DHCP server with a prefix that can be allocated, the MN4sends a DHCP solicit message to the All_DHCP_Relay_Agents_and_Servers address (108). This solicit message includes a DHCP client identifier (client identifier option) and IA_PD option. An IAID showing a group (IA_PD) applying a prefix within the MN is set in the IA_PD options.

FIG. 12shows an S2packet format containing a DHCPv6 message. The DHCPv6 is an application protocol using UDP/IP in the transport layer. The DHCP message S2is stored in the data section43B of payload43of the IPv6 packet. The DHCP message specifies the value in the message-type field51. The option parameter of the DHCP message is set in the Options field53.

Here, the server section12for HA1 receives the DHCP solicit message (108). The server section12for HA1 then starts up the prefix delegation processing routine60.

The server section12loads the IAID from the IA_PD options of the DHCP solicit message, and decides (61) if a prefix can be allocated to the IAID. If a prefix can be allocated then the server section12designates an IA_PD from the IAID containing that DHCP solicit message. The server section12searches the table linking the MN4identifier and IA_PD, using the IA_PD as a search (retrieval) key, and decides the MN4identifier. The server section12sends a request (62,109) containing MN4identifiers to the CA3.

When an inquiry is received, the CA3searches the prefix allocation control table330using the NN4identifier as a search key (110).

The CA3searches for the MN4entry generated in step106. The CA3confirms that a prefix issue OK flag is set for the applicable entry, and sends a response showing prefix allocation is allowed, to the server12(63,111).

When a response is received, the server section12searches the DHCP client identifier with the IAID contained in that DHCP solicit message, and the prefix control table320. When the applicable entry is not present in the prefix control table320, the server section12generates a new entry in the prefix control table320, and stores an IAID322and DHCP client identifier321that are contained in that DHCP solicit message. The server section12then sends a DHCP advertise message to the MN4(64,112). This advertise message contains an identifier for server section12(server identifier option), an identifier for MN4(client identifier option), and the IA_PD options received in step108. The advertise message from the server section12may also include IPv6 prefix information for allocation.

When the server12cannot allocate the IPv6 prefix to the IAID in step61, or when the CA3does not allow allocation of the prefix in step63, then the server12sends an advertise message containing a status code option to the MN4showing the prefix cannot be allocated and ends this routine (67).

When allocation (or distribution) of the prefix is approved, the MN4sends a DHCP request message containing IA_PD options to the server section12and requests IPv6 prefix information (113).

When the advertise message received in step112contains an IPv6 prefix message, the request message contains the prefix that the MN4needs to use.

Here, returning toFIG. 5, the description of the prefix delegation processing routine60continues.

When the DHCP request message is received (65), the server section12loads the IAID and specifies the IPv6 prefix for allocation. When the request message contains IPv6 prefix information, then the prefix needed for use by MN4is approved.

The server section12next searches the prefix control table320with the IAID and DHCP client identifier contained in the DHCP request message. The server section12detects and entry generated in step64, and stores the IPv6 prefix for distribution and the prefix lifetime in the applicable entries. The server section12sends a DHCP reply message containing the prefix information to MN4(66,114), and ends this routine.

When a prefix for allocation to MN4could not be specified in step65, or when there was no applicable entry in the prefix control table320in step66, then the server section12sends a DHCP reply message (68) to MN4to report the error and ends this routine.

The MN4extracts IPv6 prefix information from that DHCP reply message. The MN4creates a home address from the prefix information and the MN4interface identifier.

The MN4next specifies the HA address using the HA (home agent) address discovery function. The MN4sends the Home Agent Address Discovery Request (116) to the Mobile IPv6 Home-Agents Anycast Address set in the home network prefix received in step114.

One of the HAs which process the same prefix as the Mobile IPv6 Home-Agents Anycast Address may receive the Home Agent Address Discovery Request.

The server section11aof HA1 receives the Home Agent Address Discovery Request. The server section11asends the Home Agent Address Discovery Reply to the MN4(117).

The MN4receives the Home Agent Address Discovery Reply and acquires the HA address (address of server section11a) (118).

The MN4next utilizes an IKE to create an IPsec SA for use between the server section11aand MN4.

In IKE phase1, an ISAKMP SA is established between the MN4and server section11a. The ISAKMP SA is a control channel for the IKE. The MN4proposes ISAKMP SA parameters (121) utilizing the SA payload in the server section11a.

FIG. 13shows the ISAKMP packet format S3. The packet format used by IKE is specified in the ISAKMP protocol. The IKE transport protocol is UDP/IP.

The ISAKMP packet S3is stored in the data section43B of payload43of the IPv6 packet. The ISAKMP packet S3is comprised of an ISAKMP header55and one or more payloads56. The payload56contains for example, an SA payload to transport the proposed SA, an identification payload to exchange the ID information, and a signature payload to send the digital signature, etc.

The server section11aselects an acceptable proposal from the SA payload received in step121and returns it to the MN4(122).

The MN4and server section11anext exchange Diffe-Hellman public values and random numbers obtained per Nonce (123,124) and generate a secret key.

The MN4and server section11anext exchange ID information for verifying a personal identity. In this embodiment, the signal sent when confirming if the identity attribute is the actual person is defined as the personal identity check signal.FIG. 14shows the ISAKMP packet format S4utilized in checking the personal identity for IKE phase1. The ISAKMP packet S4contains the identification payload56A, signature payload56B and the certificate payload56C.

The MN4sends (125) the ISAKMP packet utilized in the personal identity check to the server section11a. The identification payload56A of this ISAKMP packet125includes the home address generated by MN4in step115. The MN4calculates the hash value, executes the digital signature utilizing the MN4public key in that hash value, and sets it in the signature payload56B. The certificate payload56C includes MN4public key certification that CA3issued.

The server section11aextracts the MN4digital signature from the signature payload56B of packet125. The server section11athen decodes the digital signature using the MN4public key. The MN4public key is acquired from the certificate payload56C of packet125.

The server section11aconfirms the personal identity of the packet sender MN4by comparing the hash value calculated from the received packet125and the decoded value of that digital signature.

The server section11anext extracts the MN4home address from the identification payload of packet125. The server section11asends an inquiry containing the home prefix to the server section12(126). The server section12searches the prefix control table320using the prefix contained in that request126as a search key. If an applicable entry is present in the prefix control table320, then assigning of the prefix is complete (127). The server section12sends a reply to the server section11anotifying that prefix allocation is complete (128).

If allocating of the prefix is complete, the server section11acontinues the processing of IKE phase1. The server section11aexecutes the digital signature using the public key of server section11ain the hash value. The server section11asends the ISAKMP packet containing the digital signature to MN4(129). The IP address of server section11ais set in the identification payload of the ISAKMP packet129. This ISAKMP packet may be included in the public key certification of server section11a. The public key certification of server section11awas issued in step183. Alternatively the public key certification of server section11amay be issued in step181and182ofFIG. 29, and in this case the step183is needless (FIG. 28).

The MN4receives the packet129and confirms if the other party in the IKE communication using the public key of server section11ais genuine. The MN4acquires the server section11apublic key from the public key certification in packet129or acquires it from CA3.

The ISAKMP SA has now been established between MN4and the server section11a.

The IPsec SA is next created in IKE phase2, for MN4and server section11a. This IPsec SA is utilized when IPsec processing and forwarding the packets between the MN4and server section11a. The payload for ISAKMP packets sent and received in IKE phase2is encoded using the ISAKMP SA established in IKE phase1.

The MN4sends an ISAKMP packet to the server section11a. An SA payload containing the IPsec SA proposal, a Nonce payload, and a hash payload were set in this ISAKMP packet (130). The server section11athen sends to the MN4, the ISAKMP packet in which are set the IPsec SA payload containing the accepted IPsec proposal, the Nonce payload, and the hash payload (131).

The MN4sends the ISAKMP packet containing the hash payload to the server section11a(132). The server section11areceives this packet (132) and confirms that MN4has received the packet131. The above process generates two IPsec SA (the IPsec to the server section11afrom MN4, and the IPsec SA to the MN4from the server section11a). The server section11aand the MN4store the IPsec SA (SPI, MN4home address, and server section11aaddress, etc.) in the respective SAD.

The MN4sends a binding update adapted for the SA generated in IKE phase2to the server section11a(133). The MN4temporarily stores the address of server section11ain the binding update list control table (134).

FIG. 15shows the binding update message format S11compatible with IPsec. The IPv6 destination options header401, IPsec header (AH header or ESP header)402, and the IPv6 mobility header403are stored in the IPv6 packet extension header42.

The MN4stores the following values in the binding update sent to the server section11a. The CoA of the MN4is set in the source address41aof the IPv6 packet header. The home address that the MN4generated in step115is set in the home address field of the IPv6 Destination Options Header401.

The server section11areceives this binding update133and starts the IPsec processing routine.

FIG. 6shows the IPsec processing routine70. The IPv6 Destination Options Header401is processed first (71). More specifically, the Destination Options Header value (home address) and the source address value (CoA) are exchanged with each other.

The server section11anext searches the SAD for the type of IPsec (AH or ESP), SPI value, and destination address, and specifies the IPsec SA. When the received packet has been encoded, the server section11afirst decodes the received packet and checks that it matches the specified IPsec SA (72). The server section11anext searches the SPD, and checks whether the (now) reconstructed packet can be accepted (73).

If the packet can be accepted, then the IPsec processor14of server section11asends the reconstructed packet to the mobile IP processor15.

The mobile IP processor15registers the MN4location (makes a binding update) (74).

The mobile IP processor15searches the binding cache management table310using the MN4home address as a search (retrieval) key. If there is no MN4entry in that binding cache management table310, then an MN4entry is added to the binding cache management table310(135). The MN4sets the CoA acquired in the visited network5b, into the Care of Address312entry.

If the processing in step72and step73did not end correctly, then the server section11adiscards the received packet and ends this routine (78).

The mobile IP processor15sends the packet to the IPsec processor14for sending a binding acknowledgement adapted to IPsec, to the MN4. The IPsec processor14searches the SPD and investigates the packet security policy (75). When found that the packet is usable with IPsec, a matching SA is detected from the SAD. The IPsec processor14adds a routing header404to this packet and applies IPsec (76). The server section11anext interchanges the routing header value and the destination address value. The server section11sends a binding acknowledgement subjected to IPsec processing, to MN4(77,136) and then ends this routine.

FIG. 16shows the format S12of a binding acknowledgement message subjected to IPsec. The IPv6 routing header404, the IPsec header (AH Header or ESP header)402, and the IPv6 mobility header403are stored in the IPv6 packet extension header42. The server section11astores the following values in the binding acknowledgment sent to the MN4. The CoA of MN4is stored in the destination address41bof the IPv6 packet header. The MN4home address is stored in the home address field of the IPv6 routing header404.

When the binding acknowledgement is received, the MN4searches the SAD and specifies an SA. When the received packet has been encoded, the received packet is checked after decoding, to find if it matches the SA. The SPD is also searched and a check made to determine if the reconstructed packet can be accepted. If acceptable, the MN4registers the entry temporarily stored in step134, into the binding update list control table (137).

Here, the MN4may register the identification information (for example FQDN) and information matching the home address acquired in step115, into the home network8, the visited network5, or the location information control device (for example a DNS server device) belonging to the IP network7.

The information appliance terminal9is comprised of a Mobile IPv6 function and a DHCP-PD requesting router function. An authentication method can be used with the information appliance terminal9if a public key certification is acquired from the CA3.

The first embodiment of the present invention can therefore provide an authentication method for verifying the authenticity of the IPv6 terminal, by linking a digital signature authentication method with a Mobile IP location registration (binding update) procedure, and by the HA creating and holding an SA for the home address linked to the public key certification.

The MN4and HA1 server section11hold a public key certification issued by the CA3. The HA1 server section12and the MN4contain a DHCP-PD section. By linking the CA3and the HA1 server section12, the HA1 can give a prefix notification to the MN4to whom prefix allocation was approved by CA3. The HA1 server section11can further provide an authentication method for verifying the MN is genuine by generating an IPsec SA among the MN4home prefix for the prefix that has been allocated by the server section12already.

Second Embodiment

The second embodiment of the present invention is described next while referring to the accompanying drawings.

FIG. 19shows the structure of the communication network of the second embodiment of the present invention. The second embodiment is characterized in that the communication device2contains a DHCP-PD requesting router function. In the example of the second embodiment, the IP network7contains an authentication server10. The authentication server10controls information (ID, passwords, etc,) required for authorizing access to the home network.

FIG. 20shows the structure of the communication device2of the second embodiment of the present invention. The communication device2is comprised of a CPU21, a memory22, and an interface section (IF)23(23a,23b) containing a line24(24a,24b), and a bus25connecting these components.

The memory22is comprised mainly of a DHCP-PD section26containing a DHCP-PD requesting router function, and an authentication processor27for authorizing access to the home network8.

FIG. 21shows the sequence for location registration (binding update) and authentication of MN4in the second embodiment of the present invention.

The first embodiment and the second embodiment differ in the installation locations for the DHCP-PD requesting router function. The communication device2(GW2) of the second embodiment contains a DHCP-PD requesting router function, and sends and receives DHCP-PD messages.

The process from step101to step107is the same as the first embodiment.

Hereafter, the process from step141onwards is described.

When a packet is received from the MN4, the GW2requests that the MN4send authentication information (141). The MN4sends an authentication request containing an ID and password (142). The GW2bsends a DHCP solicit containing an IAID (143).

The server section12receives that DHCP solicit and specifies an IA_PD from the IAID. The server section12searches the table of corresponding MN4identifiers and IA_PD using the IA_PD as a search (retrieval) key, and decides on an MN4identifier.

The process from step144to step146is the same as steps109to step111in the first embodiment.

When the reply146is received, the server section12sends a DHCP Advertise (notification) to the GW2b(147). Hereafter, the processing from step148to step149for the server section12is the same as in the first embodiment.

When the DHCP reply149containing the prefix information is received, the GW2bsends an authentication reply containing prefix information to the MN4(150). Hereafter, the MN authentication processing and the location registration (binding update) processing is the same as from step115to step137in the first embodiment.

The second embodiment of the present invention can therefore provide an authentication method for verifying the authenticity of IPv6 terminals not containing a DHCP-PD section, by linking a digital signature authentication method with a mobile IP location registration (binding update) procedure, even in cases where the communication device2is equipped with a DHCP-PD requesting router function.

The second embodiment can also provide a highly safe communication service by providing a function for authorizing access to HA from the communication device2.

Third Embodiment

The third embodiment of the present invention is described next while referring to the accompanying drawings.

FIG. 22shows the structure of the communication network of the third embodiment of the present invention. In addition to the functions of the second embodiment, the third embodiment is characterized by possessing HMIPv6 MAP functions. In the third embodiment, the MN4is a mobile terminal compatible with HMIPv6.

FIG. 23shows the structure of the communication device2of the third embodiment. The memory22of the communication device2contains an HMIPv6 processor29in addition to the functions shown in the second embodiment. The HMIPv6 processor29provides the HMIPv6 compatible MAP functions. The HMIPv6 processor29contains a binding cache management table for holding information linking the RCoA and LCoA.

The sequence for location registration (binding update) and authorization for MN4in the network5shown inFIG. 22are described according to the sequence shown inFIG. 24.

The MN4receives a router notification (router advertisement) containing MAP options from the router (AR: Access Router)6cbelonging to the network5b(161). The MN4specifies the communication device (hereafter MAP) using the router advertisement information161and generates an RCoA and LCoA (162).

The process from step103to step107is the same as in the first embodiment.

When the MN4receives the public key certification from the CA3, it sends a binding update (location registration signal) to the MAP2b(163).

In the third embodiment, the MAP2butilizes the receiving of the binding update (location registration signal) to initiate authentication processing. The process hereafter from step141to step150is the same as the second embodiment.

When the processing up to step150ends correctly, the MAP2bstores information linking the RCoA and LCoA of MN4, into the binding cache management table of the HMIPv6 processor29. The MAP2bsends the binding acknowledgement to the MN4(164).

The MN authorization process and location registration (binding update) process hereafter are the same as from step115to step137of the first embodiment. The third embodiment of the present invention can therefore provide an authentication method for verifying the authenticity of IPv6 terminals not containing a DHCP-PD section, by linking a digital signature authentication method with a mobile IP location registration (binding update) procedure, even in cases where the communication device2is equipped with a HMIPv6 function.

The third embodiment can also provide a communication service with higher safety by the communication device initiating the access authentication processing for the home network when the HMIPv6 control signal is received.

Fourth Embodiment

The fourth embodiment of the present invention is described next while referring to the accompanying drawings. The structure of the communication network in the fourth embodiment is the same as in the first embodiment.

The fourth embodiment is characterized in that the server section11of the HA1 comprises a system to allocate the prefix to MN approved by the CA3, and in containing a MN4public key certification control table. Information on the identification payload contained in the ISAKMP packet of IPsec phase1and information linked to the public key certifications are stored in the public key certification control table.

In the fourth embodiment, the HA1 and the MN need not contain a DHCP-PD section. The HA of the MN4is the server section11a.

After the MN4in the network5bshown inFIG. 1, has completed location registration (binding update) in the server section11a, the sequence from the HA1 server section11anotifying the MN4of the prefix, to the MN4once again completing location registration (binding update) is described while following the sequence shown fromFIG. 25throughFIG. 27.

The sequence from step101to step107is the same as in the first embodiment.

The MN4next creates an IPsec SA in the server section11a.

The sequence from step121through step125is the same as in the first embodiment. The MN4sends to the server section11a, an ISAKMP packet125containing an identification payload set with the M4home address, and with a certificate payload set with the MN4public key certification.

The server section11aloads the certificate payload and identification payload information from the packet125, and adds the MN4entry to the public key certification control table (171). If an MN4entry is already present, then the applicable entry is rewritten (updated).

The sequence from step129to step132is the same as in the first embodiment.

The MN4carries out location registration (binding update) utilizing an IPsec SA generated by MN4and the server section11a. The location registration (binding update) is the same as the first embodiment (from step133to137).

When the server section11ais for example changing its own prefix, the MN4current performing the binding update is notified of the prefix by the server section11a.

The server section11afirst searches the binding cache management table310and then detects the MN4entry generated in step135. The server section11anext searches the public key certification control table using the MN4home address as a search (retrieval) key and loads the MN4public key certification made in step171.

The server section11aspecifies the MN4identifier from the public key certification, and sends an inquiry along with this MN4identifier to the CA3(172,173).

When this inquiry is received, the CA3searches the prefix allocation control table330using the MN4identifier as a search (retrieval) key.

The CA3detects the MN4entry created in step106. The CA3confirms that an applicable entry is set in the prefix issue OK flag (174). The CA3sends a reply to the server section11ashowing a prefix can be allocated (175).

When the reply is received, the server section11asends a mobile prefix advertisement to report the prefix information to the MN4(176). The server section11aapplies the IPsec SA generated in steps130to132, in the mobile prefix advertisement message.

The MN4loads the prefix from the mobile prefix advertisement. The MN4detects changes in the home prefix, and generates a home address. The process from creating the home address to completion of location registration (binding update) is the same as step115through125in the first embodiment (step129through step137).

The fourth embodiment of the present invention is therefore capable of notifying the MN4of the prefix information, by linking HA1 and CA3after confirming the MN is genuine.

As clearly shown by the above embodiments, the present invention provides an authentication method for verifying that the IPv6 terminal is genuine by linking a digital signature authentication method with a Mobile IP location registration (binding update) procedure.

In particular, an authentication method can be provided for verifying the terminal x is genuine when performing Mobile IP binding updates (location registration) with a terminal x an HA belonging to zone A as a home network in zone B, with the method comprising a system for a DHCP-PD delegating router function belonging to zone A to distribute a prefix to the terminal X belonging to zone B; and further comprising: 1) a system for inquiring whether a DHCP-PD delegating router function can allocate a prefix to CA, 2) a system for inquiring whether the HA contains prefix information in the DHCP-PD delegating router function, 3) a system for acquiring a terminal x public key from CA or terminal x when the HA is creating IPsec SA with the terminal x, 4) a system for the HA to approve only location registration (binding update) subjected to the IPsec generated above in 3).

The above described authentication method for verifying a terminal x not comprising a DHCP-PD section, can be provided if a communication device mutually connected to both zone A and zone B contains a DHCP-PD requesting router function and a function authorizing zone A access. Further, a communication service with a high degree of safety can be provided since the communication device allows only authenticated terminals x to have access to the HA.

Also, if the communication device mutually connected to both zone A and zone B contains a MAP function for HMIPv6, then the communication device can use the HMIPv6 control signal as a trigger to initiate access authorization processing for zone A.

Further, if the HA1 contains a system for communicating with CA3and a system for holding MN4public key certification, then prefix information can be reported to the MN4, after the HA1 verifies the MN4is authentic and reports this to CA3.