WO2008053955A1 - Procédé de communication, système de communication, nœud mobile et nœud de communication - Google Patents

Procédé de communication, système de communication, nœud mobile et nœud de communication Download PDF

Info

Publication number
WO2008053955A1
WO2008053955A1 PCT/JP2007/071297 JP2007071297W WO2008053955A1 WO 2008053955 A1 WO2008053955 A1 WO 2008053955A1 JP 2007071297 W JP2007071297 W JP 2007071297W WO 2008053955 A1 WO2008053955 A1 WO 2008053955A1
Authority
WO
WIPO (PCT)
Prior art keywords
care
addresses
node
message
messages
Prior art date
Application number
PCT/JP2007/071297
Other languages
English (en)
French (fr)
Inventor
Takashi Aramaki
Keigo Aso
Original Assignee
Panasonic Corporation
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Panasonic Corporation filed Critical Panasonic Corporation
Priority to JP2008542172A priority Critical patent/JP4778565B2/ja
Priority to EP07831031A priority patent/EP2079201A1/en
Priority to US12/447,406 priority patent/US20100275020A1/en
Publication of WO2008053955A1 publication Critical patent/WO2008053955A1/ja

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/08Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0869Network architectures or network communication protocols for network security for authentication of entities for achieving mutual authentication
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/12Applying verification of the received information
    • H04L63/126Applying verification of the received information the source of the received data
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0816Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
    • H04L9/0819Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s)
    • H04L9/083Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s) involving central third party, e.g. key distribution center [KDC] or trusted third party [TTP]
    • H04L9/0833Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s) involving central third party, e.g. key distribution center [KDC] or trusted third party [TTP] involving conference or group key
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3247Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/80Wireless
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W28/00Network traffic management; Network resource management
    • H04W28/02Traffic management, e.g. flow control or congestion control
    • H04W28/06Optimizing the usage of the radio link, e.g. header compression, information sizing, discarding information
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W8/00Network data management
    • H04W8/02Processing of mobility data, e.g. registration information at HLR [Home Location Register] or VLR [Visitor Location Register]; Transfer of mobility data, e.g. between HLR, VLR or external networks
    • H04W8/08Mobility data transfer
    • H04W8/082Mobility data transfer for traffic bypassing of mobility servers, e.g. location registers, home PLMNs or home agents
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W8/00Network data management
    • H04W8/02Processing of mobility data, e.g. registration information at HLR [Home Location Register] or VLR [Visitor Location Register]; Transfer of mobility data, e.g. between HLR, VLR or external networks
    • H04W8/08Mobility data transfer
    • H04W8/14Mobility data transfer between corresponding nodes
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W80/00Wireless network protocols or protocol adaptations to wireless operation
    • H04W80/04Network layer protocols, e.g. mobile IP [Internet Protocol]

Definitions

  • the present invention relates to a communication method, a communication system, a mobile node, and a communication node in which a counterpart communication node authenticates a mopile node having a plurality of interfaces, each of which is assigned a care-of address. .
  • Standard MIPv6 (Non-Patent Document 1) discloses an RR (Return Routability) procedure as a means for the CN to authenticate the MN at the time of route optimization.
  • MIPv6 RR consists of protection against unauthorized redirection by HoA test and confirmation of reachability by CoA test.
  • Non-Patent Document 2 describes a method in which MN1 registers multiple CoAs with one HoA and registers them with HA2 (Bulk mCoA BU) as shown in FIG. There is no description in Monami6 about the route optimization (RO).
  • Non-Patent Document 1 D. Johnson, C. Perkins and J. Arkko, Mobility Support in IPv6, RFC3 775, June 2004
  • Non-Patent Document 2 R. Wakikawa, T. Ernst, .Nagami, "Multiple Care— of Addresses Regist ration ", draft_ietf-monami6_multiplecoa_00.txt, June 2006.
  • FIG. 7 shows the operation in this case, that is, the problem to be solved by the present invention, and the MIPv6 RR procedure will be described with reference to this figure.
  • MN1 generates a cookie for each HoA and CoA, encapsulates a HoTI (Home-Test-Init) message addressed to CN3 to HA2, transmits it via home network 4 and external network 5a, Direct Co3 (Care-of-Test_Init) [l] to [n] messages for each of multiple (n) CoA [l] to [n] individually via external networks 5a and 5b By sending directly to CN3 without going through HA2, HoA and cookies for each CoA are sent to CN3.
  • HoTI Home-Test-Init
  • HA2 Home-Test-Init
  • Direct Co3 Care-of-Test_Init
  • CN3 In response, CN3 generates a signature token for each HoA, CoA [l] to [n] from each cookie, and sends a HoT (Home-Test) message to MN1 via HA2.
  • a signature token is sent by sending CoT (Care-of_Test) [l] to [n] messages addressed directly to MN1 for CoA [l] to [n].
  • MN1 generates binding management keys Kbm [l] to [n] for each CoA [l] to [n] from each signature token, etc.
  • Message authentication code MA C [l] to [n] (MAC: Message Authentication Code) and send binding 'update' messages BU [l] to [n] directly to CN3 for each of CoA [l] to [n] individually
  • Kbm [l] to [n] and MAC [l] to [n] are transmitted.
  • CN3 generates MAC [l] to [n], etc. separately from MN1 and authenticates BU [l] to [n] messages in the same way as MN1.
  • CN3 may optionally send binding confirmation messages BA [l] to [n] in response to BU [l] to [n] messages. For this reason, in (1) to (3), since CoTi, CoT, and BU messages are sent for each of the multiple CoAs, it is necessary to send a very large number (3n) of messages. There is a point.
  • the present invention reduces the number of messages when performing an RR (Return Routability) procedure for performing authentication between a mopile node (MN) and a counterpart communication node (CN). It is an excellent idea to provide a communication method, a communication system, a mopile node, and a communication node that can be used.
  • RR Return Routability
  • the present invention provides a communication method in which a counterpart communication node authenticates a mopile node having a plurality of interfaces, and a care-of address is assigned to each of the plurality of interfaces.
  • the counterpart communication node receives the plurality of first messages transmitted from each of the plurality of interfaces, generates each signature token for each of the plurality of care-of addresses, and generates each signature token. Sending a token to the mobile node in each of a plurality of second messages;
  • the mopile node generates a common key for the plurality of care-of addresses using the signature tokens in the plurality of second messages, and uses the common key for the plurality of care-of addresses. Generating a common authentication code and sending a Balta 'binding' update message including the plurality of care-of addresses and the common authentication code to the communication node of the other party; The counterpart communication node authenticating a common authentication code to the plurality of care-of addresses in the Balta 'binding update message.
  • the present invention is a communication system in which a destination communication node authenticates a mopile node having a plurality of interfaces, and a care-of address assigned to each of the plurality of interfaces.
  • the counterpart communication node receives the plurality of first messages transmitted from each of the plurality of interfaces, generates each signature token for each of the plurality of care-of addresses, and generates each signature token.
  • the mopile node generates a common key for the plurality of care-of addresses using the signature tokens in the plurality of second messages, and uses the common key for the plurality of care-of addresses.
  • the counterpart communication node has means for authenticating a common authentication code for the plurality of care-of addresses in the Balta 'binding update message.
  • the present invention provides a communication system in which a destination communication node authenticates a mopile node having a plurality of interfaces, and a care-of address is assigned to each of the plurality of interfaces.
  • a mopile node wherein each means of the plurality of interfaces respectively transmits a first message individually to the communication node of the other party;
  • the counterpart communication node receives the plurality of first messages transmitted from each of the plurality of interfaces, generates each signature token for each of the plurality of care-of addresses, and generates each signature token.
  • a token is transmitted to itself in each of a plurality of second messages
  • the plurality of signatures in each of the plurality of second messages are used to A common key is generated for the care-of addresses
  • a common authentication code is generated for the plurality of care-of addresses using the common key
  • the plurality of care-of addresses and the common authentication code are generated.
  • Including a Balta 'binding' update message including the means for transmitting to the correspondent communication node,
  • the destination communication node authenticates a common authentication code for the plurality of care-of addresses in the Balta 'binding update message.
  • the present invention provides a communication system in which a destination communication node authenticates a mopile node having a plurality of interfaces, and a care-of address is assigned to each of the plurality of interfaces.
  • the communication node of the other party wherein when the first message is individually transmitted to each of the plurality of interfaces, the plurality of interfaces transmitted from each of the plurality of interfaces.
  • the mopile node generates a common key for the plurality of care-of addresses using the signature tokens in the plurality of second messages, and uses the common key for the plurality of care-of addresses.
  • a common authentication code is generated and a Balta 'binding' update message including the plurality of care-of addresses and the common authentication code is transmitted to itself. Means for authenticating a common authentication code for the care-of address.
  • the present invention is a communication method in which a destination communication node authenticates a mopile node having a plurality of interfaces, and a care-of address is assigned to each of the plurality of interfaces.
  • the partner communication node authenticates each authentication code in the plurality of binding 'update messages, and sends each binding confirmation message to the mopile node;
  • the mopile node receives each binding confirmation message, generates a common key for the plurality of care-of addresses using each signature token in the plurality of second messages, and generates the common key. Generating a common authentication code for the plurality of care-of addresses, and transmitting a Balta confirmation message including the plurality of care-of addresses and the common authentication code to the communication node of the other party; and And determining whether or not the previous communication node can reach each of the plurality of care-of addresses in the Balta confirmation message.
  • the present invention provides a communication system in which a destination communication node authenticates a mopile node having a plurality of interfaces, each of which is assigned a care-of address.
  • the mopile node generates each key for each of the plurality of care-of addresses using each signature token in the second Balta message, and uses each key for each authentication for each of the plurality of care-of addresses. Generate code and generate the multiple care-of addresses A plurality of binding 'update messages each including each authentication code and each authentication code; and means for transmitting the update message to the counterpart communication node;
  • the mopile node receives each binding confirmation message, generates a common key for the plurality of care-of addresses using each signature token in the plurality of second messages, and generates the common key.
  • the present invention provides a mopile node in a communication system in which a destination communication node authenticates a mopile node having a plurality of interfaces and a care-of address assigned to each of the plurality of interfaces. Means for transmitting a first bulk message including the plurality of care-of addresses to the other communication node;
  • the counterpart communication node receives the first Balta message, generates a signature token for each of the plurality of care-of addresses, and shares each signature token with the plurality of care-of addresses.
  • each signature token in the second Balta message is used to generate each key for each of the plurality of care-of addresses, and each key is used to Means for generating each authentication code for each of a plurality of care-of addresses, and transmitting a plurality of binding 'update messages each including each of the plurality of care-of addresses and each of the authentication codes to the communication node of the other party;
  • Second message A common key is generated for each of the plurality of care-of addresses using each of the signature tokens, and a common authentication code is generated for the plurality of care-of addresses using the common key.
  • the destination communication node determines whether or not each of the plurality of care-of addresses in the Balta confirmation message is reachable.
  • the present invention provides a communication system in which a communication node of a partner authenticates a mopile node having a plurality of interfaces and assigned a care-of address to each of the plurality of interfaces.
  • a communication node when the first Balta message including the plurality of care-of addresses is transmitted to itself by receiving the first Balta message; Generating a signature token for each of the plurality of care-of addresses, and transmitting each signature token to the mopile node in a second Balta message common to the plurality of care-of addresses;
  • the mopile node generates each key for each of the plurality of care-of addresses using each signature token in the second Balta message, and uses each key for each authentication for each of the plurality of care-of addresses.
  • a plurality of binding 'update messages including each of the plurality of care-of-addresses and the respective authentication codes are transmitted to itself, each authentication code in the plurality of binding' update messages is respectively generated.
  • the mopile node receives each binding confirmation message, generates a common key for the plurality of care-of addresses using each signature token in the plurality of second messages, and generates the common key. And generating a common authentication code for the plurality of care-of addresses, and sending a Balta confirmation message including the plurality of care-of addresses and the common authentication code to the plurality of care-of addresses. And a means for judging whether or not each of the care-of addresses can be reached. [0016] With this configuration, it is possible to reduce the number of messages when performing an RR (Return Routability) procedure for performing authentication between the mobile node (MN) and the communication node (CN) of the counterpart.
  • RR Return Routability
  • FIG. 1 is an explanatory diagram showing a configuration and a message of the first embodiment of a communication system according to the present invention.
  • FIG. 2 is an explanatory diagram showing a communication sequence according to the first embodiment.
  • FIG. 3 is an explanatory diagram showing a configuration and messages of a second embodiment of a communication system according to the present invention.
  • FIG. 4 is an explanatory diagram showing a communication sequence according to the second embodiment.
  • FIG. 7 is an explanatory diagram showing the problems to be solved by the present invention.
  • FIG. 1 is an explanatory diagram showing the configuration and messages of the first embodiment of the communication system according to the present invention
  • FIG. 2 shows the communication sequence of the first embodiment.
  • CoTi and CoT messages are transmitted for each of a plurality of CoAs
  • BU messages are transmitted to the plurality of CoAs in a batch (Balter BU).
  • MN1 has two interfaces, and there are two CoAs. For this reason, only two CoTi messages and CoT messages (CoTil, CoTi2) and (CoTl, CoT2) are shown.
  • MN1 generates a home address cookie KO (Home Init Cookie) and care-of addresses CoA [l] to [n] cookie Kl [l] to [n] (Care of Init Cookie). And MN1 sends HoTi message containing cookie K0 to CN3 via HA2 and sends CoTi [l] ⁇ [n] messages containing each cookie Kl [l] ⁇ [n] individually and directly.
  • the packet address of the message addressed from MN1 to HA2 is the packet addressed to CN encapsulated with the packet addressed to HA.
  • the source addresses of the packets of CoTi [l] to [n] messages are CoA [l] to [n], respectively.
  • CN3 holds the secret key Ken and the nonce table in advance, and receives the CoTi [l] to [n] messages, and then receives the secret key Ken, HoA, CoA [l] to [n], nonce (Ni , Nj) generates a signature token TO for the home address HoA and signature tokens Tl [l] to [n] for care-of addresses CoA [l] to [n] as follows: To do. Note that Nj of CoA [l] to [n] may be the same or different from each other.
  • HMAC SHAl (Kcn, (HoA, Ni, 0))
  • CN3 then sends a message ⁇ including cookie K0, signature token ⁇ 0, non-stable index i, etc. to MN1 via ⁇ 2 as shown below, and ⁇ 1 [1] to [ ⁇ ] Tokens ⁇ 1 [1] to [ ⁇ ], non-stable index j and other CoT [l] to [n] messages are sent directly and individually.
  • MAC [1], MAC [2] to MAC [n] as signatures are generated from the Kbm, CoA, CN address, and BU hash values as follows.
  • HMAC_SHA1 Kbm, (CoA [l], CN address, BU)
  • HMAC SHA1 Kbm, (CoA [2], CN address, BU)
  • MAC [n] HMAC_SHA1 (Kbm, (CoA [n], CN address, BU)
  • MNl generates and transmits a message including the following contents as individual BU messages BU [1], BU [2] to: BU [n] for CN3.
  • CN3 generates Kbm [l], Kbm [2] to Kbm [n] separately from MNl and in the same way as MNl, and then generates Kbm [l], Kbm [2] to Generate MAC [1], MAC [2] to MAC [n] from Kbm [n], etc., and BU messages BU [1], BU [2] to: MAC [1], BU [n] Compared with MAC [2] to MAC [n], if they match, “authentication is OK” and a binding confirmation ( ⁇ ) message is individually returned to MN1. For this reason, the number of BU messages is the same as the number of CoAs. Monami6 does not have the concept of BU authentication.
  • MN1 in order to reduce the number of BU messages and generate a Barta BU message, MN1 first hashes the hash values of all tokens as follows: Generates a common binding management key Kbm (common) for CoA [l] to [n]
  • HMAC_SHA1 Kbm (common), (CoA [l], CoA [2] to CoA [n], CN address, BU))
  • MNl generates and transmits a common message to Co A [l] to [n] including the following contents as a Balta BU message for CN3.
  • CN3 generates Kbm (common) separately from MNl and in the same way as MNl, and then generates MAC (common) from this Kbm (common) etc. in the Balta BU message. If it matches, “Authentication is OK” and a binding confirmation ( ⁇ ⁇ ) message is sent back to MN1 as a Balta message.
  • the interface through which MN1 transmits the Balta BU message and the interface through which the Balta message is received are arbitrary, and may be the same or different.
  • CN3 can confirm that the bucket reaches the individual CoA [l], CoA [2] to CoA [n] (reachable).
  • MN1 generates each unique cookie Kl [l] to [n] (Care of Init Cookie) for each CoA [l] to [n], and each cookie Kl [l] to CN3 CoTi [l] to [n] messages including ⁇ [n] are sent individually.
  • HMAC_SHA1 Kbm, (CoA [5], CN address, BU)
  • FIG. 3 is an explanatory diagram showing the configuration and messages of the second embodiment of the communication system according to the present invention
  • FIG. 4 is an explanatory diagram showing the communication sequence of the second embodiment.
  • CoTi and CoT are transmitted as Balta messages
  • BU messages are transmitted individually for each CoA.
  • MN1 generates a home address cookie KO (Home Init Cookie) and care-of addresses CoA [l] to [n] cookie Kl [l] to [n] (Care of Init Cookie). Then, MN1 sends a HoTi message containing cookie K0 to CN3 via HA2, and directly sends a Balta CoTi message containing cookies Kl [l] to [n] and CoA [l] to [n]. To do.
  • the source address of the packet of the Balta CoTi message is the representative Co A of CoA [l] to [n].
  • CN3 holds a secret key Ken and a nonce table in advance, and when it receives a Norw CoTi message, it has a secret key Ken and a hash of HoA, CoA [l] to [n], and nonce (Ni, Nj). From the values, a signature token TO for home address HoA and signature tokens Tl [l] to [n] for care-of addresses Co A [l] to [n] are generated as follows. Note that Nj of CoA [l] to [n] may be the same or different from each other.
  • HMAC SHAl (Kcn, (HoA, Ni, 0))
  • CN3 sends a message ⁇ ⁇ including cookie K0, signature token ⁇ 0, non-stable index i, etc. to MN1 via ⁇ 2 as follows, and ⁇ 1 [1] to [ ⁇ ], A token token ⁇ 1 [1]-[ ⁇ ], a Balta CoT message including non-stable index j is sent directly.
  • the interface through which MN1 transmits the Balta CoTi message and the interface through which the Nonreco CoT message is received are arbitrary, and may be the same or different.
  • MN1 generates binding management keys Kbm [l] and Kbm [2] to Kbm [n] from the hash value of the token
  • HMAC_SHA1 Kbm, (CoA [l], CN address, BU)
  • HMAC SHA1 Kbm, (CoA [2], CN address, BU)
  • MAC [n] HMAC_SHA1 (Kbm, (CoA [n], CN address, BU)
  • MN1 generates and transmits a message including the following contents as individual BU messages BU [1], BU [2] to: BU [n] for CN3.
  • BU [2] (HoA, CoA [2], i, j, seq #, MAC [2])
  • BU [n] (HoA, CoA [n], i, j, seq #, MAC [n])
  • CN3 generates Kbm [l], Kbm [2] to Kbm [n] separately from MN1 and in the same manner as MN1, and then Kbm [l], Kbm [ 2] to Kbm [n] etc. to generate MAC [1] and MAC [2] to MAC [n] respectively, and MAC [1], MAC [2] to MAC [n] in each BU message If they match, “Authentication OK” is set and an individual binding confirmation (iii) message is returned to MN1.
  • CN3 can confirm that the packets reach each CoA [l], CoA [2] to CoA [n] (reachable). [1] A common reachable check key Krc (common) is generated for CoA [2] to CoA [n], and a Balta BAack message including Krc (com mon) is transmitted to CN3.
  • this Krc (common) is the same as the common binding management key Kbm (common) for CoA [l] to [n] generated from the hash values of all tokens in the first embodiment. is there. For this reason, even in the second embodiment, CN3 is reachable to each CoA [l], CoA [2] to CoA [n] even if a Balta CoTi message or a Balta CoT message is transmitted. It can be confirmed that
  • Figure 5 shows the combination of CoTi, CoT and BU messages with individual (Ind) and Balta (Bulk).
  • reachability means that it can be confirmed that the packet reaches each CoA interface.
  • amplification means that the number of response messages is increased (amplified) in response to inquiries and other messages, and it is desirable not to be amplified in order to easily cause congestion.
  • n indicates the number of CoAs.
  • nCol l + nCol + nBU dn messages, 1.5 round trips
  • nCoTi + lCoT + nBU + nBA + lBAack 3n + 2 messages, 2.5 round tripsCase 7:
  • nCol i + nCoT + lBU 2n + 1 messages, 1.5 round trips
  • the number of messages in case 6 is larger than that in case 8 (Fig. 6, Issues), so it is not a good solution.
  • the number of messages in case 7 is less than in case 8 (Fig. 6, issue) when n> 2, so this is the best solution.
  • Case 2 (second embodiment) is improved by reducing the number of messages when force n> 4, which increases the number of round trips, compared to case 8 (Fig. 6, issue).
  • the present invention has the effect of reducing the number of messages when performing the RR procedure for authentication between the mopile node and the communication node of the other party! Touch with S.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Description

明 細 書
通信方法、通信システム、モバイルノード及び通信ノード
技術分野
[0001] 本発明は、複数のインタフェースを有し、複数のインタフェースの各々に気付けアド レスが割り当てられているモパイルノードを相手先の通信ノードが認証する通信方法 、通信システム、モバイルノード及び通信ノードに関する。
背景技術
[0002] 標準の MIPv6 (非特許文献 1)には、ルート最適化時における CNが MNを認証す る手段として RR (Return Routability)手続が開示されている。 MIPv6の RRは、 HoA テストによる不正なリダイレクションからの保護と、 CoAテストによるリーチャビリティの 確認からなる。
[0003] 一方、 Monami6 (Mobile Nodes and Multiple Interfaces in IPv6)では、モノ ィルノ ード(MN)が複数のインタフェースを有する場合のために種々の提案が成されて!/ヽ る。また、モパイル IP (Internet Protocol)を利用する MNは、移動先のアドレスである 気付けアドレス(CoA)を、自身のホームアドレス(HoA)を管理するホームエージェン HHA)に登録し、 HoAあてパケットの転送を依頼する。 MNが、複数の CoAを 1つ の HoAに対して同時に関連付けて登録することができれば、複数のインタフェースを 備える MNは、それぞれのインタフェースに割り当てられた CoAを登録することで、ィ ンタフェースの状態に応じて使用する CoAを瞬時に切り替えることが可能となる。図 6 は従来の Monami6におけるバルタ BU (バインディング ·アップデート)を示す説明図 である。非特許文献 2には、図 6に示すように MN1が複数の CoAを 1つの HoAに関 連付けて HA2に登録 (Bulk mCoA BU)する手法が記述されている。ルート最適化( RO: Route Optimazation)を行う手段については、 Monami6には、何らの記載はな い。
非特許文献 1: D.Johnson, C.Perkins and J.Arkko, Mobility Support in IPv6 , RFC3 775, June 2004
非特許文献 2 : R.Wakikawa, T.Ernst, .Nagami, "Multiple Care— of Addresses Regist ration", draft_ietf-monami6_multiplecoa_00.txt, June 2006.
[0004] ところで、 MNが複数の CoAを HAにバルタ BU (バインディング ·アップデート)登録 する Monami6を、 CNが MNを認証する MIPv6の RR手順に単純に組み合わせ、こ の組み合わせた RR手順において、 MNが CNに対して、複数の CoAに関連するバ インディング 'メッセージを一括して行うこと(バルタ BU)が考えられる。し力、しながら、 図 6に示すような Monami6の Bulk mCoA BUでは、 MN1— HA2間のセキュリティは IPsecにより保護されているという観点から、さらにバルタ BUに対する認証を行うとい う概念がない。これに対し、 CN3が MN1を認証することを目的とする MIPv6の RR手 順では、 MN1— CN3間が IPsecでセキュアに保護されている前提を置くことができ ないため、 BUメッセージの内容が異なり、 RR手順における BUメッセージでは、個々 の CoA毎にバインディング管理キー(Kbm)や署名(MAC)が必要である(後述)。こ のため、 Monami6の HAあてのバルタ BUを MN1— CN3間の RR手順に適用する ことができず、 MN1— CN3間の RR手順における BUメッセージは個々の CoA毎に CNあてに送る必要がある。
[0005] 図 7はこの場合の動作、すなわち本発明が解決しょうとする課題を示し、この図を参 照しながら MIPv6の RR手順を説明する。まず、
(1) MN1は HoA、 CoA毎のクッキーを生成して、 CN3あての HoTI (Home-Test-Ini t)メッセージを HA2あてにカプセル化してホームネットワーク 4及び外部ネットワーク 5 a経由で送信するとともに、複数 (n個)の CoA[l]〜[n]の各々についての直接 CN3あ ての CoTi (Care-of-Test_Init) [l]〜[n]メッセージを個別に外部ネットワーク 5a、 5b経 由で HA2を介することなく直接 CN3へ送信することにより、 HoA、および各 CoA毎 のクッキーを CN3に送信する。
(2) CN3はこれに応答して、各クッキーなどから HoA、 CoA[l]〜[n]毎の署名用トー クンを生成して、 HA2経由の MN1あての HoT(Home-Test)メッセージを送信すると ともに、 CoA[l]〜[n]についての直接 MN1あての CoT (Care-of_Test) [l]〜[n]メッセ ージを送信することにより署名用トークンを送信する。
[0006] (3)次いで、 MN1はこれに応答して、各署名用トークンなどから CoA[l]〜[n]毎のバ インディング管理キー Kbm[l]〜[n]を生成してそれぞれのメッセージ認証コード MA C[l]〜[n] (MAC : Message Authentification Code)し、 CoA[l]〜[n]の各々について の直接 CN3あてのバインディング 'アップデート 'メッセージ BU[l]〜[n]を個々に送 信することにより、 Kbm[l]〜[n]及び MAC[l]〜[n]を送信する。 CN3は MN1とは別 個に、かつ MN1と同様に MAC[l]〜[n]などを生成し、 BU[l]〜[n]メッセージを認証 する。
(4)オプションとして、 CN3は BU[l]〜[n]メッセージに応答してバインディング確認メ ッセージ BA[l]〜[n]を送信してもよい。このため、(1)〜(3)では、複数の CoAの各 々について CoTi、 CoT、 BUの各メッセージを送信するので、非常に多く(3n個)のメ ッセージを送信する必要があるという問題点がある。
発明の開示
[0007] 本発明は上記の問題点に鑑み、モパイルノード (MN)と相手先の通信ノード(CN) との間で認証を行う RR (Return Routability)手続を行う場合のメッセージ数を減少さ せることができる通信方法、通信システム、モパイルノード及び通信ノードを提供する ことを目白勺とする。
[0008] 本発明は上記目的を達成するために、複数のインタフェースを有し、前記複数のィ ンタフェースの各々に気付けアドレスが割り当てられているモパイルノードを相手先の 通信ノードが認証する通信方法であって、
前記モパイルノード力 前記複数のインタフェースの各々力、らそれぞれ第 1のメッセ ージを個々に前記相手先の通信ノードに送信するステップと、
前記相手先の通信ノードが、前記複数のインタフェースの各々から送信された複数 の前記第 1のメッセージを受信して、前記複数の気付けアドレスの各々用の各署名 用トークンを生成し、各署名用トークンを複数の第 2のメッセージの各々で前記モバイ ルノードに送信するステップと、
前記モパイルノードが、前記複数の第 2のメッセージ内の各署名用トークンを用い て前記複数の気付けアドレスに対して共通の鍵を生成し、前記共通の鍵を用いて前 記複数の気付けアドレスに対して共通の認証コードを生成し、前記複数の気付けアド レス及び前記共通の認証コードを含むバルタ 'バインディング 'アップデートメッセ一 ジを前記相手先の通信ノードに送信するステップと、 前記相手先の通信ノードが、前記バルタ 'バインディング ·アップデートメッセージ内 の前記複数の気付けアドレスに対して共通の認証コードを認証するステップとを有す
[0009] また本発明は上記目的を達成するために、複数のインタフェースを有し、前記複数 のインタフェースの各々に気付けアドレスが割り当てられているモパイルノードを相手 先の通信ノードが認証する通信システムであって、
前記モパイルノード力 前記複数のインタフェースの各々力、らそれぞれ第 1のメッセ ージを個々に前記相手先の通信ノードに送信する手段と、
前記相手先の通信ノードが、前記複数のインタフェースの各々から送信された複数 の前記第 1のメッセージを受信して、前記複数の気付けアドレスの各々用の各署名 用トークンを生成し、各署名用トークンを複数の第 2のメッセージの各々で前記モバイ ルノードに送信する手段と、
前記モパイルノードが、前記複数の第 2のメッセージ内の各署名用トークンを用い て前記複数の気付けアドレスに対して共通の鍵を生成し、前記共通の鍵を用いて前 記複数の気付けアドレスに対して共通の認証コードを生成し、前記複数の気付けアド レス及び前記共通の認証コードを含むバルタ 'バインディング 'アップデートメッセ一 ジを前記相手先の通信ノードに送信する手段と、
前記相手先の通信ノードが、前記バルタ 'バインディング ·アップデートメッセージ内 の前記複数の気付けアドレスに対する共通の認証コードを認証する手段とを有する。
[0010] また本発明は上記目的を達成するために、複数のインタフェースを有し、前記複数 のインタフェースの各々に気付けアドレスが割り当てられているモパイルノードを相手 先の通信ノードが認証する通信システムにおける前記モパイルノードであって、 前記複数のインタフェースの各々力 それぞれ第 1のメッセージを前記相手先の通 信ノードに個々に送信する手段と、
前記相手先の通信ノードが、前記複数のインタフェースの各々から送信された複数 の前記第 1のメッセージを受信して、前記複数の気付けアドレスの各々用の各署名 用トークンを生成し、各署名用トークンを複数の第 2のメッセージの各々で自身に送 信した場合に、前記複数の第 2のメッセージ内の各署名用トークンを用いて前記複数 の気付けアドレスに対して共通の鍵を生成し、前記共通の鍵を用いて前記複数の気 付けアドレスに対して共通の認証コードを生成し、前記複数の気付けアドレス及び前 記共通の認証コードを含むバルタ 'バインディング 'アップデートメッセージを前記相 手先の通信ノードに送信する手段とを有し、
前記相手先の通信ノードが、前記バルタ 'バインディング ·アップデートメッセージ内 の前記複数の気付けアドレスに対する共通の認証コードを認証するようにした。
[0011] また本発明は上記目的を達成するために、複数のインタフェースを有し、前記複数 のインタフェースの各々に気付けアドレスが割り当てられているモパイルノードを相手 先の通信ノードが認証する通信システムにおける前記相手先の通信ノードであって、 前記モパイルノード力 前記複数のインタフェースの各々力、らそれぞれ第 1のメッセ ージを自身に個々に送信した場合、前記複数のインタフェースの各々から送信され た複数の前記第 1のメッセージを受信して、前記複数の気付けアドレスの各々用の各 署名用トークンを生成し、各署名用トークンを複数の第 2のメッセージの各々で前記 モパイルノードに送信する手段と、
前記モパイルノードが、前記複数の第 2のメッセージ内の各署名用トークンを用い て前記複数の気付けアドレスに対して共通の鍵を生成し、前記共通の鍵を用いて前 記複数の気付けアドレスに対して共通の認証コードを生成し、前記複数の気付けアド レス及び前記共通の認証コードを含むバルタ 'バインディング 'アップデートメッセ一 ジを自身に送信した場合、前記バルタ 'バインディング ·アップデートメッセージ内の 前記複数の気付けアドレスに対する共通の認証コードを認証する手段とを有する。
[0012] また本発明は上記目的を達成するために、複数のインタフェースを有し、前記複数 のインタフェースの各々に気付けアドレスが割り当てられているモパイルノードを相手 先の通信ノードが認証する通信方法であって、
前記モパイルノード力 前記複数のインタフェースの 1つ力、ら前記複数の気付けアド レスを含む第 1のバルタメッセージを前記相手先の通信ノードに送信するステップと、 前記相手先の通信ノードが、前記第 1のバルタメッセージを受信して、前記複数の 気付けアドレスの各々用の各署名用トークンを生成し、各署名用トークンを前記複数 の気付けアドレスに対して共通の第 2のバルタメッセージで前記モパイルノードに送 前記モパイルノードが、前記第 2のバルタメッセージ内の各署名用トークンを用いて 前記複数の気付けアドレスの各々に対する各鍵を生成し、前記各鍵を用いて前記複 数の気付けアドレスの各々に対する各認証コードを生成し、前記複数の気付けァドレ スの各々及び前記各認証コードをそれぞれ含む複数のバインディング 'アップデート メッセージを前記相手先の通信ノードに送信するステップと、
前記相手先の通信ノードが、前記複数のバインディング 'アップデートメッセージ内 の各認証コードをそれぞれ認証し、各バインディング確認メッセージを前記モパイル ノードに送信するステップと、
前記モパイルノードが、前記各バインディング確認メッセージを受信して、前記複数 の第 2のメッセージ内の各署名用トークンを用いて前記複数の気付けアドレスに対し て共通の鍵を生成し、前記共通の鍵を用いて前記複数の気付けアドレスに対して共 通の認証コードを生成し、前記複数の気付けアドレス及び前記共通の認証コードを 含むバルタ確認メッセージを前記相手先の通信ノードに送信するステップと、 前記相手先の通信ノードが、前記バルタ確認メッセージ内の前記複数の気付けァ ドレスの各々に対して到達可能か否かを判断するステップとを有する。
また本発明は上記目的を達成するために、複数のインタフェースを有し、前記複数 のインタフェースの各々に気付けアドレスが割り当てられているモパイルノードを相手 先の通信ノードが認証する通信システムであって、
前記モパイルノード力 前記複数のインタフェースの 1つ力、ら前記複数の気付けアド レスを含む第 1のバルタメッセージを前記相手先の通信ノードに送信する手段と、 前記相手先の通信ノードが、前記第 1のバルタメッセージを受信して、前記複数の 気付けアドレスの各々用の各署名用トークンを生成し、各署名用トークンを前記複数 の気付けアドレスに対して共通の第 2のバルタメッセージで前記モパイルノードに送 信する手段と、
前記モパイルノードが、前記第 2のバルタメッセージ内の各署名用トークンを用いて 前記複数の気付けアドレスの各々に対する各鍵を生成し、前記各鍵を用いて前記複 数の気付けアドレスの各々に対する各認証コードを生成し、前記複数の気付けァドレ スの各々及び前記各認証コードをそれぞれ含む複数のバインディング 'アップデート メッセージを前記相手先の通信ノードに送信する手段と、
前記相手先の通信ノードが、前記複数のバインディング 'アップデートメッセージ内 の各認証コードをそれぞれ認証し、各バインディング確認メッセージを前記モパイル ノードに送信する手段と、
前記モパイルノードが、前記各バインディング確認メッセージを受信して、前記複数 の第 2のメッセージ内の各署名用トークンを用いて前記複数の気付けアドレスに対し て共通の鍵を生成し、前記共通の鍵を用いて前記複数の気付けアドレスに対して共 通の認証コードを生成し、前記複数の気付けアドレス及び前記共通の認証コードを 含むバルタ確認メッセージを前記相手先の通信ノードに送信する手段と、
前記相手先の通信ノードが、前記バルタ確認メッセージ内の前記複数の気付けァ ドレスの各々に対して到達可能か否かを判断する手段とを有する。
また本発明は上記目的を達成するために、複数のインタフェースを有し、前記複数 のインタフェースの各々に気付けアドレスが割り当てられているモパイルノードを相手 先の通信ノードが認証する通信システムにおける前記モパイルノードであって、 前記複数のインタフェースの 1つ力、ら前記複数の気付けアドレスを含む第 1のバル クメッセージを前記相手先の通信ノードに送信する手段と、
前記相手先の通信ノードが、前記第 1のバルタメッセージを受信して、前記複数の 気付けアドレスの各々用の各署名用トークンを生成し、各署名用トークンを前記複数 の気付けアドレスに対して共通の第 2のバルタメッセージで自身に送信した場合、前 記第 2のバルタメッセージ内の各署名用トークンを用いて前記複数の気付けアドレス の各々に対する各鍵を生成し、前記各鍵を用いて前記複数の気付けアドレスの各々 に対する各認証コードを生成し、前記複数の気付けアドレスの各々及び前記各認証 コードをそれぞれ含む複数のバインディング 'アップデートメッセージを前記相手先の 通信ノードに送信する手段と、
前記相手先の通信ノードが、前記複数のバインディング 'アップデートメッセージ内 の各認証コードをそれぞれ認証し、各バインディング確認メッセージを自身に送信し た場合、前記各バインディング確認メッセージを受信して、前記複数の第 2のメッセ一 ジ内の各署名用トークンを用いて前記複数の気付けアドレスに対して共通の鍵を生 成し、前記共通の鍵を用いて前記複数の気付けアドレスに対して共通の認証コード を生成し、前記複数の気付けアドレス及び前記共通の認証コードを含むバルタ確認 メッセージを前記相手先の通信ノードに送信する手段とを有し、
前記相手先の通信ノードが、前記バルタ確認メッセージ内の前記複数の気付けァ ドレスの各々に対して到達可能か否かを判断するようにした。
また本発明は上記目的を達成するために、複数のインタフェースを有し、前記複数 のインタフェースの各々に気付けアドレスが割り当てられているモパイルノードを相手 先の通信ノードが認証する通信システムにおける前記相手先の通信ノードであって、 前記モパイルノード力 前記複数のインタフェースの 1つ力、ら前記複数の気付けアド レスを含む第 1のバルタメッセージを自身に送信した場合、前記第 1のバルタメッセ一 ジを受信して、前記複数の気付けアドレスの各々用の各署名用トークンを生成し、各 署名用トークンを前記複数の気付けアドレスに対して共通の第 2のバルタメッセージ で前記モパイルノードに送信する手段と、
前記モパイルノードが、前記第 2のバルタメッセージ内の各署名用トークンを用いて 前記複数の気付けアドレスの各々に対する各鍵を生成し、前記各鍵を用いて前記複 数の気付けアドレスの各々に対する各認証コードを生成し、前記複数の気付けァドレ スの各々及び前記各認証コードをそれぞれ含む複数のバインディング 'アップデート メッセージを自身に送信した場合、前記複数のバインディング 'アップデートメッセ一 ジ内の各認証コードをそれぞれ認証し、各バインディング確認メッセージを前記モバ ィルノードに送信する手段と、
前記モパイルノードが、前記各バインディング確認メッセージを受信して、前記複数 の第 2のメッセージ内の各署名用トークンを用いて前記複数の気付けアドレスに対し て共通の鍵を生成し、前記共通の鍵を用いて前記複数の気付けアドレスに対して共 通の認証コードを生成し、前記複数の気付けアドレス及び前記共通の認証コードを 含むバルタ確認メッセージを自身に送信した場合、前記バルタ確認メッセージ内の 前記複数の気付けアドレスの各々に対して到達可能か否力、を判断する手段とを有す [0016] この構成により、モバイルノード(MN)と相手先の通信ノード(CN)との間で認証を 行う RR (Return Routability)手続を行う場合のメッセージ数を減少させることができる
[0017] 本発明によれば、モバイルノード(MN)と相手先の通信ノード(CN)との間で認証 を行う RR (Return Routability)手続を行う場合のメッセージ数を減少させることができ 図面の簡単な説明
[0018] [図 1]本発明に係る通信システムの第 1の実施の形態の構成とメッセージを示す説明 図
[図 2]第 1の実施の形態の通信シーケンスを示す説明図
[図 3]本発明に係る通信システムの第 2の実施の形態の構成とメッセージを示す説明 図
[図 4]第 2の実施の形態の通信シーケンスを示す説明図
[図 5]第 1、第 2の実施の形態を考察した説明図
[図 6]従来の Monami6におけるバルタ BUを示す説明図
[図 7]本発明が解決しょうとする課題を示す説明図
発明を実施するための最良の形態
[0019] 以下、図面を参照して本発明の実施の形態について説明する。
<第 1の実施の形態〉
図 1は本発明に係る通信システムの第 1の実施の形態の構成とメッセージを示す説 明図、図 2は第 1の実施の形態の通信シーケンスを示す。第 1の実施の形態では、複 数の CoAの各々について CoTi、 CoTの各メッセージを送信し、 BUメッセージを複 数の CoAに対して一括(バルタ BU)で送信する。なお、図 1では、 MN1は 2つのイン タフエースを有し、 CoAが 2つである場合を示す。このため、 CoTiメッセージと CoTメ ッセージも 2つのみ(CoTil、 CoTi2)、 (CoTl、 CoT2)を示す。
[0020] (l) CoTi (HoTi)
まず、 MN1はホームアドレス用のクッキー KO (Home Init Cookie)と気付けアドレス CoA[l]〜[n]用の各クッキー Kl[l]〜[n] (Care of Init Cookie)を生成する。そして、 MN1は CN3に対し、クッキー K0を含む HoTiメッセージを HA2経由で送信するとと もに、各クッキー Kl[l]〜[n]を含む CoTi[l]〜[n]メッセージを個別に、かつ直接送信 する。ここで、 MN1から HA2あてのメッセージのパケットのアドレスについては、 CN あてパケットを HAあてパケットでカプセル化したものである。また、 CoTi[l]〜[n]メッ セージの各パケットの送信元アドレスは、それぞれ CoA[l]〜[n]である。
(2)CoT(HoT)
CN3はあらかじめ、秘密鍵 Kenとノンス(nonce)テーブルを保持し、 CoTi[l]〜[n]メ ッセージを受け取ると、秘密鍵 Kenと、 HoA、 CoA[l]〜[n]、 nonce (Ni、 Nj)のハツシ ュ値から、以下のようにホームアドレス HoA用の署名用トークン TOと気付けアドレス C oA[l]〜[n]用の各署名用トークン Tl[l]〜[n]を生成する。なお、 CoA[l]〜[n]の Njは 、共通であっても、また、別個に異なるものでもよい。
TO : HMAC— SHAl(Kcn, (HoA, Ni、 0))
Tl [1]: HMAC_SHA1 (Ken, (CoA[l], Nj、 1))
Tl [2] : HMAC_SHA1 (Ken, (CoA[2], Nj、 1))
Tl [n] : HMAC_SHA1 (Ken, (CoA[n], Nj、 1))
そして、 CN3は MN1に対し、以下のようにクッキー K0、署名用トークン Τ0、ノンス テーブルインデックス iなどを含む ΗοΤメッセージを ΗΑ2経由で送信するとともに、ク ツキ一 Κ1[1]〜[η]、署名用トークン Τ1[1]〜[η]、ノンステーブルインデックス jなどを含 む CoT[l]〜[n]メッセージを直接、かつ個別に送信する。
HoT : (K0, TO, ί···)
CoT[l]: (Kl[l], Tl[l], ]···)
CoT[2]: (Kl[2], Tl[2], ]···)
CoT[n]: (Κ1[η], Τ1[η], ]···)
<課題〉
ここで、上記の(1)、(2)における個々の CoA毎の手順は、標準の MIPv6の RR手 順(RFC3775)に記載されており、公知である。また、この BUメッセージ送信手順で は、 CoA[l]〜[n]個々の BUメッセージを送信するために、以下のようにトークンのハ ッシュ値力、らバインディング管理キー Kbm[l]、Kbm[2]〜Kbm[n]をそれぞれ生成する
Kbm[l] : SHAl (TO, Tl[l])
Kbm[2] : SHAl (T0, Tl[2])
Kbm[n] : SHAl (TO, Τ1[η])
また、この Kbm、 CoA、 CNアドレス、 BUのハッシュ値から以下のようにして署名であ る MAC[1]、 MAC[2]〜MAC[n]を生成する。
MAC[1]: HMAC_SHA1 (Kbm, (CoA[l], CNアドレス, BU)
MAC[2] : HMAC SHA1 (Kbm, (CoA[2], CNアドレス, BU)
MAC[n]: HMAC_SHA1 (Kbm, (CoA[n], CNアドレス, BU)
[0024] そして、 MNlは、 CN3に対する個々の BUメッセージ BU[1]、 BU[2]〜: BU[n]とし て、以下の内容を含むメッセージを生成し、送信する。
BU[l] (HoA, CoA[l], i, j , seq # , MAC[1])
BU[2] (HoA, CoA[2], i, j , seq # , MAC[2])
BU[n] (HoA, CoA[n], i, j , seq # , MAC[n])
[0025] CN3は MNlと別個に、また、 MNlと同様に、 Kbm[l]、 Kbm[2]〜Kbm[n]をそれぞ れ生成し、次いでこの Kbm[l]、 Kbm[2]〜Kbm[n]などから MAC[1]、 MAC[2]〜MA C[n]をそれぞれ生成して BUメッセージ BU[1]、 BU[2]〜: BU[n]内の MAC[1]、 MAC [2]〜MAC[n]と比較し、一致した場合に「認証 OK」とし、バインディング確認(ΒΑ)メ ッセージを個別に MN1に返信する。このため、 BUメッセージの数が CoAの数だけ 必要になる。また、 Monami6では、 BUの認証という概念がない。
[0026] <第 1の実施の形態の解決策〉
(3)これに対し、第 1の実施の形態では、 BUメッセージの数を減少してバルタ BUメ ッセージを生成するために、 MN1はまず、以下のように全てのトークンのハッシュ値 から CoA[l]〜[n]に対して共通のバインディング管理キー Kbm(common)を生成し、
Kbm(common): SHA1 (TO, Tl [l], Τ1 [2]〜[η])
次いで、この Kbm(common)と、一例として全ての CoA[l]〜[n]などから以下のようにし て、 CoA[l]〜[n]に対して共通の MAC(common)を生成する。
MAC(common): HMAC_SHA1 (Kbm(common), (CoA[l], CoA[2]〜CoA[n] , CNアドレス, BU) )
そして、 MNlは、 CN3に対するバルタ BUメッセージとして、以下の内容を含む Co A[l]〜[n]に対して共通のメッセージを生成し、送信する。
Bulk BU (HoA, CoA[l], CoA[2]〜CoA[n], i, j , seq # , MAC)
[0027] (4) CN3は MNlと別個に、また、 MNlと同様に、 Kbm(common)を生成し、次いでこ の Kbm(common)などから MAC(common)をそれぞれ生成してバルタ BUメッセージ内 の MAC(common)と比較し、一致した場合に「認証 OK」とし、バインディング確認(Β Α)メッセージをバルタメッセージで MN1に返信する。ここで、 MN1がバルタ BUメッ セージを送信するインタフェースと、バルタ ΒΑメッセージを受信するインタフェースは 任意であり、また、同じであっても異なってもよい。
[0028] 次に、第 1の実施の形態により、個々の CoA[l], CoA[2]〜CoA[n]に対してバケツ トカ届くこと(reachable)を CN3が確認できることを説明する。
(1)では、 MN1は CoA[l]〜[n]毎にユニークな各クッキー Kl [l]〜[n] (Care of Init C ookie)を生成し、 CN3に対し、各クッキー Kl [l]〜[n]をそれぞれ含む CoTi[l]〜[n]メ ッセージを個別に送信する。
(2)では、 CN3は CoTi[l]〜[n]メッセージを受け取ると、 CoA[l]〜[n]毎にユニーク な各署名用トークン Tl [l]〜[n]を生成し、 MN1に対し、署名用トークン Τ1 [1]〜[η]を それぞれを含む CoT[l]〜[n]メッセージを個別に送信する。
(3)では、 MN1は CoT[l]〜[n]メッセージを受け取ると、署名用トークン Tl [l]〜[n]な どから CoA[l]〜[n]に対して共通のバインディング管理キー Kbm(common)を生成し、 この Kbm(common)と全ての CoA[l]〜[n]などから、 CoA[l]〜[n]に対して共通の MA C(common)を生成し、 CN3に対し、この共通の MAC(common)と全ての CoA[l], Co A[2]〜CoA[n]を含むバルタ BUメッセージを送信する。 [0029] したがって、 MN1がバルタ BUメッセージを CN3に送信しても、 CN3は個々の Co A[l], CoA[2]〜CoA[n]に対して reachableであると確認できる。なお、全ての CoAに つ!/、て reachableを問題にしな!/、場合には、共通の MAC(common)を生成する際に用 いる CoAは全てではなぐ 1以上の代表 CoAを用いてもよい。その例を以下に示す( 代表 CoA=CoA[5], CoA[2], CoA[7])。
MAC: HMAC_SHA1 (Kbm, (CoA[5], CNアドレス, BU)
MAC: HMAC_SHA1 (Kbm, (CoA[2], CoA[7], CNアドレス, BU) [0030] <第 2の実施の形態〉
次に、図 3、図 4を参照して第 2の実施の形態について説明する。図 3は、本発明に 係る通信システムの第 2の実施の形態の構成とメッセージを示す説明図、図 4は第 2 の実施の形態の通信シーケンスを示す説明図である。第 2の実施の形態では、 CoTi 、 CoTをバルタメッセージで送信し、 BUメッセージを CoA毎に個別に送信する。
(l) CoTi (HoTi)
まず、 MN1はホームアドレス用のクッキー KO (Home Init Cookie)と気付けアドレス CoA[l]〜[n]用の各クッキー Kl[l]〜[n] (Care of Init Cookie)を生成する。そして、 MN1は CN3に対し、クッキー K0を含む HoTiメッセージを HA2経由で送信するとと もに、クッキー Kl[l]〜[n]及び CoA[l]〜[n]を含むバルタ CoTiメッセージを直接送信 する。バルタ CoTiメッセージのパケットの送信元アドレスは、 CoA[l]〜[n]の代表 Co Aである。
[0031] (2) CoT (HoT)
CN3はあらかじめ、秘密鍵 Kenとノンス(nonce)テーブルを保持し、ノ ルク CoTiメッ セージを受け取ると、秘密鍵 Kenと、 HoA、 CoA[l]〜[n]、 nonce (Ni、 Nj)のハッシュ 値から、以下のようにホームアドレス HoA用の署名用トークン TOと気付けアドレス Co A[l]〜[n]用の各署名用トークン Tl[l]〜[n]を生成する。なお、 CoA[l]〜[n]の Njは 、共通であっても、また、別個に異なるものでもよい。
TO : HMAC— SHAl (Kcn, (HoA, Ni、 0) )
Tl [1]: HMAC_SHA1 (Ken, (CoA[l], Nj , 0) )
T1[2] : HMAC SHA1 (Ken, (CoA[2], Nj、 0) ) Tl [n] : HMAC_SHA1 (Ken, (CoA[n], Nj、0))
[0032] そして、 CN3は MN1に対し、以下のようにクッキー K0、署名用トークン Τ0、ノンス テーブルインデックス iなどを含む ΗοΤメッセージを ΗΑ2経由で送信するとともに、ク ツキ一 Κ1[1]〜[η]、署名用トークン Τ1[1]〜[η]、ノンステーブルインデックス jなどを含 むバルタ CoTメッセージを直接送信する。
HoT: (K0, TO, ί···)
CoT: (Kl[l], Κ1[2]〜Τ1[η], Τ1[1], Τ1[2]〜Τ1[η], ]···)
ここで、 MN1がバルタ CoTiメッセージを送信するインタフェースと、ノ ノレク CoTメッセ ージを受信するインタフェースは任意であり、また、同じであっても異なってもよい。
[0033] (3) MN1はトークンのハッシュ値からバインディング管理キー Kbm[l]、 Kbm[2]〜K bm[n]をそれぞれ生成し、
Kbm[l]:SHAl(TO, Tl[l])
Kbm[2]:SHAl(T0, Tl[2])
Kbm[n]:SHAl(TO, Τ1[η])
次いで、この Kbm[l]、 Kbm[2]〜Kbm[n]、 CoA[l]、 CoA[2]〜[n]、 CNアドレス、 BU のハッシュ値から以下のようにして署名用の MAC[1]、 MAC[2]〜MAC[n]を生成す
MAC[1]: HMAC_SHA1 (Kbm, (CoA[l], CNアドレス, BU)
MAC[2]:HMAC SHA1 (Kbm, (CoA[2], CNアドレス, BU)
MAC[n]: HMAC_SHA1 (Kbm, (CoA[n], CNアドレス, BU)
[0034] そして、 MN1は、 CN3に対する個々の BUメッセージ BU[1]、 BU[2]〜: BU[n]とし て、以下の内容を含むメッセージを生成し、送信する。
BU[l](HoA, CoA[l], i, j, seq#, MAC[1])
BU[2](HoA, CoA[2], i, j, seq#, MAC[2]) BU[n] (HoA, CoA[n], i, j , seq # , MAC[n])
[0035] (4) CN3は MN1と別個に、また、 MN1と同様に、 Kbm[l]、 Kbm[2]〜Kbm[n]をそれ ぞれ生成し、次いでこの Kbm[l]、 Kbm[2]〜Kbm[n]などから MAC[1]、 MAC[2]〜M AC[n]をそれぞれ生成して個々の BUメッセージ内の MAC[1]、 MAC[2]〜MAC[n] と比較し、一致した場合に「認証 OK」とし、個々のバインディング確認(ΒΑ)メッセ一 ジを MN1に返信する。
[0036] (5) ΜΝ1は個々の BUを受け取ると、 CN3が個々の CoA[l]、 CoA[2]〜CoA[n]に 対してパケットが届くこと(reachable)を確認できるように、 CoA[l]、 CoA[2]〜CoA[n] に対して共通の reachableチェックキー Krc(common)を生成し、 CN3に対し、 Krc(com mon)を含むバルタ BAackメッセージを送信する。
Krc(common): SHA1 (TO, Tl [l], Τ1 [2]〜[η])
ここで、この Krc(common)は、第 1の実施の形態において全てのトークンのハッシュ値 から生成した、 CoA[l]〜[n]に対して共通のバインディング管理キー Kbm(common)と 同じである。このため、第 2の実施の形態においても同様に、バルタ CoTiメッセージ、 バルタ CoTメッセージを送信しても、 CN3は個々の CoA[l]、 CoA[2]〜CoA[n]に対 して reachableであると確認できる。
[0037] <第 1、第 2の実施の形態の考察〉
図 5は CoTi、 CoT、 BUメッセージと個別(Ind)、バルタ(Bulk)の組み合わせを示す 。まず、 reachabilityと Amplificationについて考察する。ここで reachabilityとは、各 CoA のインタフェースへパケットが到達することが確認できることを意味する。また、 Amplifi cationとは、問い合わせなどのメッセージに対して、その応答のメッセージの方が多く なる(アンプリファイされる)ことを意味し、輻輳を引き起こしやすくするためアンプリフ アイされないことが望ましい。
•ケース l (CoTi = Bulk, CoT=Bulk, BU = Bulk)は、 MNの各インタフェースに対す る CNからの到達確認を一度も行って!/、な!/、のでこのままでは reachabilityを満足しな い。これらのバルタメッセージに加えて個別 BAとバルタ BAackを用いることで reachab ilityを満足することはできる(バルタ BAackの代わりに個別 BAackを用いても reachabil ityを満足することはできるがメッセージ数が多い)。ところ力 バルタ BUが個別 BAと してアンプリファイされるので、 NGである。
•ケース 2 (CoTi = Bulk, CoT=Bulk, BU = Ind :第 2の実施の形態)は、個別 BAと バルタ BAackが reachabilityを満足するので、 OKである。
•ケース 3 (CoTi = Bulk, CoT=Ind, BU = Bulk)は、 1つの CoTiにより多くの CoTカ 発生する、すなわちアンプリファイされるので、 NGである。
'ケース 4 (CoTi = Bulk, CoT=Ind, BU = Ind)も、 1つの CoTiにより多くの CoTが発 生する、すなわちアンプリファイされるので、 NGである。
•ケース 5 (CoTi = Ind, CoT = Bulk, BU = Bulk)は、 MNの各インタフェースに対す る CNからの到達確認を一度も行って!/、な!/、のでこのままでは reachabilityを満足しな い。これらのバルタメッセージに加えて個別 BAとバルタ BAackを用いることで reachab ilityを満足することはできる(バルタ BAackの代わりに個別 BAackを用いても reachabil ityを満足することはできるがメッセージ数が多い)。ところ力 バルタ BUが個別 BAと してアンプリファイされるので、 NGである。
•ケース 6 (CoTi = Ind, CoT = Bulk, BU = Ind)は、個別 BAとバルタ BAackが reacha bilityを満足するので、 OKである。
'ケース 7 (CoTi = Ind, CoT = Ind, BU = Bulk:第 1の実施の形態)は、 reachabilityが 個別 CoT、バルタ BUにより安全にチェックされるので、 OKである。
•ケース 8 (CoTi = Ind, CoT = Ind, BU = Ind :図 6,課題)は、 OKである。
次に、上記の OKであったケース 2、 6、 7、 8のメッセージ数(及びメッセージのラウン ドトリップ回数)について考察する。下記で nは CoAの数を示す。
•ケース 8 :
nCol l + nCol +nBU = dn messages, 1.5 round trips
'ケース 2 :
lCoTi+ lCoT + nBU + nBA+ lBAack = 2n+ 3 messages, 2.5 round trips •ケース 6 :
nCoTi+ lCoT + nBU + nBA+ lBAack = 3n + 2 messages, 2.5 round trips •ケース 7 :
nCol i + nCoT+ lBU = 2n+ 1 messages, 1.5 round trips 以上により、ケース 6のメッセージ数はケース 8 (図 6,課題)より多くなるので良い解 決策とは言えない。ケース 7 (第 1の実施の形態)のメッセージ数は、 n〉2の場合、ケ ース 8 (図 6 ,課題)より少なくなるので、最善の解決策である。ケース 2 (第 2の実施の 形態)は、ケース 8 (図 6,課題)よりラウンドトリップの回数が多くはなる力 n〉4の場 合、メッセージ数が少なくなり改善されている。
産業上の利用可能性
本発明は、モパイルノードと相手先の通信ノードとの間で認証を行う RR手続を行う 場合のメッセージ数を減少させることができると!/、う効果を有し、 Monami6などに利 用すること力 Sでさる。

Claims

請求の範囲
[1] 複数のインタフェースを有し、前記複数のインタフェースの各々に気付けアドレスが 割り当てられているモパイルノードを相手先の通信ノードが認証する通信方法であつ て、
前記モパイルノード力 前記複数のインタフェースの各々力、らそれぞれ第 1のメッセ ージを個々に前記相手先の通信ノードに送信するステップと、
前記相手先の通信ノードが、前記複数のインタフェースの各々から送信された複数 の前記第 1のメッセージを受信して、前記複数の気付けアドレスの各々用の各署名 用トークンを生成し、各署名用トークンを複数の第 2のメッセージの各々で前記モバイ ルノードに送信するステップと、
前記モパイルノードが、前記複数の第 2のメッセージ内の各署名用トークンを用い て前記複数の気付けアドレスに対して共通の鍵を生成し、前記共通の鍵を用いて前 記複数の気付けアドレスに対して共通の認証コードを生成し、前記複数の気付けアド レス及び前記共通の認証コードを含むバルタ 'バインディング 'アップデートメッセ一 ジを前記相手先の通信ノードに送信するステップと、
前記相手先の通信ノードが、前記バルタ 'バインディング ·アップデートメッセージ内 の前記複数の気付けアドレスに対する共通の認証コードを認証するステップとを、 有する通信方法。
[2] 複数のインタフェースを有し、前記複数のインタフェースの各々に気付けアドレスが 割り当てられているモパイルノードを相手先の通信ノードが認証する通信システムで あって、
前記モパイルノード力 前記複数のインタフェースの各々力、らそれぞれ第 1のメッセ ージを個々に前記相手先の通信ノードに送信する手段と、
前記相手先の通信ノードが、前記複数のインタフェースの各々から送信された複数 の前記第 1のメッセージを受信して、前記複数の気付けアドレスの各々用の各署名 用トークンを生成し、各署名用トークンを複数の第 2のメッセージの各々で前記モバイ ルノードに送信する手段と、
前記モパイルノードが、前記複数の第 2のメッセージ内の各署名用トークンを用い て前記複数の気付けアドレスに対して共通の鍵を生成し、前記共通の鍵を用いて前 記複数の気付けアドレスに対して共通の認証コードを生成し、前記複数の気付けアド レス及び前記共通の認証コードを含むバルタ 'バインディング 'アップデートメッセ一 ジを前記相手先の通信ノードに送信する手段と、
前記相手先の通信ノードが、前記バルタ 'バインディング ·アップデートメッセージ内 の前記複数の気付けアドレスに対する共通の認証コードを認証する手段とを、 有する通信システム。
[3] 複数のインタフェースを有し、前記複数のインタフェースの各々に気付けアドレスが 割り当てられているモパイルノードを相手先の通信ノードが認証する通信システムに おける前記モパイルノードであって、
前記複数のインタフェースの各々力 それぞれ第 1のメッセージを前記相手先の通 信ノードに個々に送信する手段と、
前記相手先の通信ノードが、前記複数のインタフェースの各々から送信された複数 の前記第 1のメッセージを受信して、前記複数の気付けアドレスの各々用の各署名 用トークンを生成し、各署名用トークンを複数の第 2のメッセージの各々で自身に送 信した場合に、前記複数の第 2のメッセージ内の各署名用トークンを用いて前記複数 の気付けアドレスに対して共通の鍵を生成し、前記共通の鍵を用いて前記複数の気 付けアドレスに対して共通の認証コードを生成し、前記複数の気付けアドレス及び前 記共通の認証コードを含むバルタ 'バインディング 'アップデートメッセージを前記相 手先の通信ノードに送信する手段とを有し、
前記相手先の通信ノードが、前記バルタ 'バインディング ·アップデートメッセージ内 の前記複数の気付けアドレスに対する共通の認証コードを認証するようにしたモバイ ルノード。
[4] 複数のインタフェースを有し、前記複数のインタフェースの各々に気付けアドレスが 割り当てられているモパイルノードを相手先の通信ノードが認証する通信システムに おける前記相手先の通信ノードであって、
前記モパイルノード力 前記複数のインタフェースの各々力、らそれぞれ第 1のメッセ ージを自身に個々に送信した場合、前記複数のインタフェースの各々から送信され たた複複数数のの前前記記第第 11ののメメッッセセーージジをを受受信信ししてて、、前前記記複複数数のの気気付付けけアアドドレレススのの各各々々用用のの各各 署署名名用用トトーーククンンをを生生成成しし、、各各署署名名用用トトーーククンンをを複複数数のの第第 22ののメメッッセセーージジのの各各々々でで前前記記 モモパパイイルルノノーードドにに送送信信すするる手手段段とと、、
前前記記モモパパイイルルノノーードドがが、、前前記記複複数数のの第第 22ののメメッッセセーージジ内内のの各各署署名名用用トトーーククンンをを用用いい てて前前記記複複数数のの気気付付けけアアドドレレススにに対対ししてて共共通通のの鍵鍵をを生生成成しし、、前前記記共共通通のの鍵鍵をを用用いいてて前前 記記複複数数のの気気付付けけアアドドレレススにに対対ししてて共共通通のの認認証証ココーードドをを生生成成しし、、前前記記複複数数のの気気付付けけアアドド レレスス及及びび前前記記共共通通のの認認証証ココーードドをを含含むむババルルタタ ''ババイインンデディィンンググ ''アアッッププデデーートトメメッッセセ一一 ジジをを自自身身にに送送信信ししたた場場合合、、前前記記ババルルタタ ''ババイインンデディィンンググ ··アアッッププデデーートトメメッッセセーージジ内内のの 前前記記複複数数のの気気付付けけアアドドレレススにに対対すするる共共通通のの認認証証ココーードドをを認認証証すするる手手段段ととをを、、
有有すするる通通信信ノノーードド。。
[5] 複複数数ののイインンタタフフェェーーススをを有有しし、、前前記記複複数数ののイインンタタフフェェーーススのの各各々々にに気気付付けけアアドドレレススがが 割割りり当当ててらられれてていいるるモモパパイイルルノノーードドをを相相手手先先のの通通信信ノノーードドがが認認証証すするる通通信信方方法法ででああつつ てて、、
前前記記モモパパイイルルノノーードド力力 前前記記複複数数ののイインンタタフフェェーーススのの 11つつ力力、、らら前前記記複複数数のの気気付付けけアアドド レレススをを含含むむ第第 11ののババルルタタメメッッセセーージジをを前前記記相相手手先先のの通通信信ノノーードドにに送送信信すするるスステテッッププとと、、 前前記記相相手手先先のの通通信信ノノーードドがが、、前前記記第第 11ののババルルタタメメッッセセーージジをを受受信信ししてて、、前前記記複複数数のの 気気付付けけアアドドレレススのの各各々々用用のの各各署署名名用用トトーーククンンをを生生成成しし、、各各署署名名用用トトーーククンンをを前前記記複複数数 のの気気付付けけアアドドレレススにに対対ししてて共共通通のの第第 22ののババルルタタメメッッセセーージジでで前前記記モモパパイイルルノノーードドにに送送 前前記記モモパパイイルルノノーードドがが、、前前記記第第 22ののババルルタタメメッッセセーージジ内内のの各各署署名名用用トトーーククンンをを用用いいてて 前前記記複複数数のの気気付付けけアアドドレレススのの各各々々にに対対すするる各各鍵鍵をを生生成成しし、、前前記記各各鍵鍵をを用用いいてて前前記記複複 数数のの気気付付けけアアドドレレススのの各各々々にに対対すするる各各認認証証ココーードドをを生生成成しし、、前前記記複複数数のの気気付付けけァァドドレレ ススのの各各々々及及びび前前記記各各認認証証ココーードドををそそれれぞぞれれ含含むむ複複数数ののババイインンデディィンンググ ''アアッッププデデーートト メメッッセセーージジをを前前記記相相手手先先のの通通信信ノノーードドにに送送信信すするるスステテッッププとと、、
前前記記相相手手先先のの通通信信ノノーードドがが、、前前記記複複数数ののババイインンデディィンンググ ''アアッッププデデーートトメメッッセセーージジ内内 のの各各認認証証ココーードドををそそれれぞぞれれ認認証証しし、、各各ババイインンデディィンンググ確確認認メメッッセセーージジをを前前記記モモパパイイルル
Figure imgf000022_0001
前前記記モモパパイイルルノノーードドがが、、前前記記各各ババイインンデディィンンググ確確認認メメッッセセーージジをを受受信信ししてて、、前前記記複複数数 の第 2のメッセージ内の各署名用トークンを用いて前記複数の気付けアドレスに対し て共通の鍵を生成し、前記共通の鍵を用いて前記複数の気付けアドレスに対して共 通の認証コードを生成し、前記複数の気付けアドレス及び前記共通の認証コードを 含むバルタ確認メッセージを前記相手先の通信ノードに送信するステップと、 前記相手先の通信ノードが、前記バルタ確認メッセージ内の前記複数の気付けァ ドレスの各々に対して到達可能か否かを判断するステップとを、
有する通信方法。
複数のインタフェースを有し、前記複数のインタフェースの各々に気付けアドレスが 割り当てられているモパイルノードを相手先の通信ノードが認証する通信システムで あって、
前記モパイルノード力 前記複数のインタフェースの 1つ力、ら前記複数の気付けアド レスを含む第 1のバルタメッセージを前記相手先の通信ノードに送信する手段と、 前記相手先の通信ノードが、前記第 1のバルタメッセージを受信して、前記複数の 気付けアドレスの各々用の各署名用トークンを生成し、各署名用トークンを前記複数 の気付けアドレスに対して共通の第 2のバルタメッセージで前記モパイルノードに送 信する手段と、
前記モパイルノードが、前記第 2のバルタメッセージ内の各署名用トークンを用いて 前記複数の気付けアドレスの各々に対する各鍵を生成し、前記各鍵を用いて前記複 数の気付けアドレスの各々に対する各認証コードを生成し、前記複数の気付けァドレ スの各々及び前記各認証コードをそれぞれ含む複数のバインディング 'アップデート メッセージを前記相手先の通信ノードに送信する手段と、
前記相手先の通信ノードが、前記複数のバインディング 'アップデートメッセージ内 の各認証コードをそれぞれ認証し、各バインディング確認メッセージを前記モパイル ノードに送信する手段と、
前記モパイルノードが、前記各バインディング確認メッセージを受信して、前記複数 の第 2のメッセージ内の各署名用トークンを用いて前記複数の気付けアドレスに対し て共通の鍵を生成し、前記共通の鍵を用いて前記複数の気付けアドレスに対して共 通の認証コードを生成し、前記複数の気付けアドレス及び前記共通の認証コードを 含むバルタ確認メッセージを前記相手先の通信ノードに送信する手段と、 前記相手先の通信ノードが、前記バルタ確認メッセージ内の前記複数の気付けァ ドレスの各々に対して到達可能か否かを判断する手段とを、
有する通信システム。
[7] 複数のインタフェースを有し、前記複数のインタフェースの各々に気付けアドレスが 割り当てられているモパイルノードを相手先の通信ノードが認証する通信システムに おける前記モパイルノードであって、
前記複数のインタフェースの 1つ力、ら前記複数の気付けアドレスを含む第 1のバル クメッセージを前記相手先の通信ノードに送信する手段と、
前記相手先の通信ノードが、前記第 1のバルタメッセージを受信して、前記複数の 気付けアドレスの各々用の各署名用トークンを生成し、各署名用トークンを前記複数 の気付けアドレスに対して共通の第 2のバルタメッセージで自身に送信した場合、前 記第 2のバルタメッセージ内の各署名用トークンを用いて前記複数の気付けアドレス の各々に対する各鍵を生成し、前記各鍵を用いて前記複数の気付けアドレスの各々 に対する各認証コードを生成し、前記複数の気付けアドレスの各々及び前記各認証 コードをそれぞれ含む複数のバインディング 'アップデートメッセージを前記相手先の 通信ノードに送信する手段と、
前記相手先の通信ノードが、前記複数のバインディング 'アップデートメッセージ内 の各認証コードをそれぞれ認証し、各バインディング確認メッセージを自身に送信し た場合、前記各バインディング確認メッセージを受信して、前記複数の第 2のメッセ一 ジ内の各署名用トークンを用いて前記複数の気付けアドレスに対して共通の鍵を生 成し、前記共通の鍵を用いて前記複数の気付けアドレスに対して共通の認証コード を生成し、前記複数の気付けアドレス及び前記共通の認証コードを含むバルタ確認 メッセージを前記相手先の通信ノードに送信する手段とを有し、
前記相手先の通信ノードが、前記バルタ確認メッセージ内の前記複数の気付けァ ドレスの各々に対して到達可能か否かを判断するようにしたモパイルノード。
[8] 複数のインタフェースを有し、前記複数のインタフェースの各々に気付けアドレスが 割り当てられているモパイルノードを相手先の通信ノードが認証する通信システムに おける前記相手先の通信ノードであって、
前記モパイルノード力 前記複数のインタフェースの 1つ力、ら前記複数の気付けアド レスを含む第 1のバルタメッセージを自身に送信した場合、前記第 1のバルタメッセ一 ジを受信して、前記複数の気付けアドレスの各々用の各署名用トークンを生成し、各 署名用トークンを前記複数の気付けアドレスに対して共通の第 2のバルタメッセージ で前記モパイルノードに送信する手段と、
前記モパイルノードが、前記第 2のバルタメッセージ内の各署名用トークンを用いて 前記複数の気付けアドレスの各々に対する各鍵を生成し、前記各鍵を用いて前記複 数の気付けアドレスの各々に対する各認証コードを生成し、前記複数の気付けァドレ スの各々及び前記各認証コードをそれぞれ含む複数のバインディング 'アップデート メッセージを自身に送信した場合、前記複数のバインディング 'アップデートメッセ一 ジ内の各認証コードをそれぞれ認証し、各バインディング確認メッセージを前記モバ ィルノードに送信する手段と、
前記モパイルノードが、前記各バインディング確認メッセージを受信して、前記複数 の第 2のメッセージ内の各署名用トークンを用いて前記複数の気付けアドレスに対し て共通の鍵を生成し、前記共通の鍵を用いて前記複数の気付けアドレスに対して共 通の認証コードを生成し、前記複数の気付けアドレス及び前記共通の認証コードを 含むバルタ確認メッセージを自身に送信した場合、前記バルタ確認メッセージ内の 前記複数の気付けアドレスの各々に対して到達可能か否力、を判断する手段とを、 有する通信ノード。
PCT/JP2007/071297 2006-11-02 2007-11-01 Procédé de communication, système de communication, nœud mobile et nœud de communication WO2008053955A1 (fr)

Priority Applications (3)

Application Number Priority Date Filing Date Title
JP2008542172A JP4778565B2 (ja) 2006-11-02 2007-11-01 通信方法、通信システム、モバイルノード及び通信ノード
EP07831031A EP2079201A1 (en) 2006-11-02 2007-11-01 Communication method, communication system, mobile node and communication node
US12/447,406 US20100275020A1 (en) 2006-11-02 2007-11-01 Communication method, communication system, mobile node and communication node

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JP2006299468 2006-11-02
JP2006-299468 2006-11-02

Publications (1)

Publication Number Publication Date
WO2008053955A1 true WO2008053955A1 (fr) 2008-05-08

Family

ID=39344295

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2007/071297 WO2008053955A1 (fr) 2006-11-02 2007-11-01 Procédé de communication, système de communication, nœud mobile et nœud de communication

Country Status (5)

Country Link
US (1) US20100275020A1 (ja)
EP (1) EP2079201A1 (ja)
JP (1) JP4778565B2 (ja)
CN (1) CN101536562A (ja)
WO (1) WO2008053955A1 (ja)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2010023599A1 (en) * 2008-08-26 2010-03-04 Telefonaktiebolaget Lm Ericsson (Publ) Registration of multiple care-of-addresses

Families Citing this family (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8370503B2 (en) * 2008-05-02 2013-02-05 Futurewei Technologies, Inc. Authentication option support for binding revocation in mobile internet protocol version 6
WO2014198745A1 (en) * 2013-06-12 2014-12-18 Telecom Italia S.P.A. Mobile device authentication in heterogeneous communication networks scenario
CN110035037B (zh) * 2018-01-11 2021-09-17 华为技术有限公司 安全认证方法、相关设备及系统
CN109598504B (zh) * 2018-10-25 2020-09-01 阿里巴巴集团控股有限公司 基于区块链的交易处理方法及装置、电子设备

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20060251044A1 (en) * 2005-04-22 2006-11-09 Wassim Haddad Mobility support for multihome nodes

Non-Patent Citations (4)

* Cited by examiner, † Cited by third party
Title
ARASAKI K. ET AL.: "Keitai Denwa-mo no Seigyo Kino o Mochiita Mobile IP Tsushin ni Kansuru Kento", IEICE TECHNICAL REPORT MOMUC 2005-88, 23 February 2006 (2006-02-23), pages 1 - 7, XP008105891 *
D. JOHNSON; C. PERKINS; J. ARKKO: "Mobility Support in IPv6", RFC3775, June 2004 (2004-06-01)
R. WAKIKAWA; T. ERNST; K. NAGAMI, MULTIPLE CARE-OF ADDRESSES REGISTRATION, June 2006 (2006-06-01), Retrieved from the Internet <URL:draft-ieft-monami6-multiplecoa-00.txt>
WAKIKAWA R. ET AL.: "Multiple Care-of Addresses Registration", INTERNET DRAFT, DRAFT-WAKIKAWA-MOBILEIP-MULTIPLECOA-05.TXT, February 2006 (2006-02-01), XP008105903 *

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2010023599A1 (en) * 2008-08-26 2010-03-04 Telefonaktiebolaget Lm Ericsson (Publ) Registration of multiple care-of-addresses

Also Published As

Publication number Publication date
JP4778565B2 (ja) 2011-09-21
US20100275020A1 (en) 2010-10-28
CN101536562A (zh) 2009-09-16
JPWO2008053955A1 (ja) 2010-02-25
EP2079201A1 (en) 2009-07-15

Similar Documents

Publication Publication Date Title
KR100759727B1 (ko) 승인된 통신 방법
ES2251459T3 (es) Autenticacion en una red de tranmisison de datos por paquetes.
US7881468B2 (en) Secret authentication key setup in mobile IPv6
US8175037B2 (en) Method for updating a routing entry
US7907948B2 (en) Providing anonymity to a mobile node in a session with a correspondent node
EP2388976A1 (en) Securing home agent to mobile node communication with HA-MN key
EA013147B1 (ru) Способ и система для обеспечения специфических для доступа ключей
CN101150849B (zh) 生成绑定管理密钥的方法、系统、移动节点及通信节点
KR20030038915A (ko) 무선 통신시스템에서 이동 단말기와 홈에이전트간의인증을 위한 방법
KR100636318B1 (ko) CoA 바인딩 프로토콜을 이용한 어드레스 오너쉽인증방법 및 그 시스템
KR20080065683A (ko) 인가 자료를 제공하기 위한 방법 및 장치
CN101300889A (zh) 用于提供移动性密钥的方法和服务器
JP5044690B2 (ja) Ipモビリティシステムのための動的な外部エージェント−ホーム・エージェント・セキュリティ・アソシエーション割当て
CN100380859C (zh) 用于安全通信的返回路径可选择的方法
JP2007036641A (ja) ホームエージェント装置、及び通信システム
US8295487B2 (en) Method and apparatus for establishing a cryptographic relationship in a mobile communications network
WO2008053955A1 (fr) Procédé de communication, système de communication, nœud mobile et nœud de communication
JPWO2009066439A1 (ja) 通信方法、通信システム、モバイルノード及び通信ノード
KR101062669B1 (ko) MIPv6의 바인딩 업데이트 방법
You et al. Comments on “SPAM: A Secure Password Authentication Mechanism for Seamless Handover in Proxy Mobile IPv6 Networks”
Qiu et al. Protecting all traffic channels in Mobile IPv6 network
US9578029B2 (en) Diameter signaling for mobile IPv4
You et al. Comments on a one-way hash chain based authentication for fmipv6
KR20060117812A (ko) 이동 아이피를 지원하는 무선 네트워크에서 보안 장치 및방법

Legal Events

Date Code Title Description
WWE Wipo information: entry into national phase

Ref document number: 200780041018.4

Country of ref document: CN

121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 07831031

Country of ref document: EP

Kind code of ref document: A1

WWE Wipo information: entry into national phase

Ref document number: 2008542172

Country of ref document: JP

WWE Wipo information: entry into national phase

Ref document number: 2007831031

Country of ref document: EP

WWE Wipo information: entry into national phase

Ref document number: 12447406

Country of ref document: US

WWE Wipo information: entry into national phase

Ref document number: 1602/KOLNP/2009

Country of ref document: IN

NENP Non-entry into the national phase

Ref country code: DE