[要約] 要約：RFC 5269は、SEcure Neighbor Discovery（SEND）を使用して、Symmetric Fast Mobile IPv6（FMIPv6）のハンドオーバーキーを配布する方法について説明しています。 目的：このRFCの目的は、FMIPv6のハンドオーバーキーの配布をセキュアに行うために、SENDプロトコルを使用する方法を提案することです。
Network Working Group J. Kempf
Request for Comments: 5269 DoCoMo Labs USA
Category: Standards Track R. Koodli
Starent Networks
June 2008
Distributing a Symmetric Fast Mobile IPv6 (FMIPv6) Handover Key Using SEcure Neighbor Discovery (SEND)
セキュアネイバーディスカバリーを使用した対称高速モバイルIPv6（fmipv6）ハンドオーバーキーの配布（送信）
Status of This Memo
本文書の位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の現在のエディションを参照してください。このメモの配布は無制限です。
Abstract
概要
Fast Mobile IPv6 requires that a Fast Binding Update is secured using a security association shared between an Access Router and a Mobile Node in order to avoid certain attacks. In this document, a method for provisioning a shared key from the Access Router to the Mobile Node is defined to protect this signaling. The Mobile Node generates a public/private key pair using the same public key algorithm as for SEND (RFC 3971). The Mobile Node sends the public key to the Access Router. The Access Router encrypts a shared handover key using the public key and sends it back to the Mobile Node. The Mobile Node decrypts the shared handover key using the matching private key, and the handover key is then available for generating an authenticator on a Fast Binding Update. The Mobile Node and Access Router use the Router Solicitation for Proxy Advertisement and Proxy Router Advertisement from Fast Mobile IPv6 for the key exchange. The key exchange messages are required to have SEND security; that is, the source address is a Cryptographically Generated Address (CGA) and the messages are signed using the CGA private key of the sending node. This allows the Access Router, prior to providing the shared handover key, to verify the authorization of the Mobile Node to claim the address so that the previous care-of CGA in the Fast Binding Update can act as the name of the key.
高速モバイルIPv6では、特定の攻撃を回避するために、アクセスルーターとモバイルノードの間で共有されるセキュリティアソシエーションを使用して高速バインディングアップデートを保護する必要があります。このドキュメントでは、アクセスルーターからモバイルノードへの共有キーをプロビジョニングする方法が定義され、このシグナリングを保護します。モバイルノードは、SEND（RFC 3971）と同じ公開キーアルゴリズムを使用して、パブリック/プライベートキーペアを生成します。モバイルノードは、公開キーをアクセスルーターに送信します。アクセスルーターは、公開キーを使用して共有ハンドオーバーキーを暗号化し、モバイルノードに送り返します。モバイルノードは、一致する秘密キーを使用して共有ハンドオーバーキーを復号化し、ハンドオーバーキーを使用でき、高速バインディングアップデートで認証器を生成します。モバイルノードとアクセスルーターは、キーエクスチェンジに高速モバイルIPv6からプロキシ広告とプロキシルーター広告にルーター勧誘を使用します。キーエクスチェンジメッセージは、セキュリティを送信するために必要です。つまり、ソースアドレスは暗号化されたアドレス（CGA）であり、メッセージは送信ノードのCGA秘密鍵を使用して署名されます。これにより、共有されたハンドオーバーキーを提供する前に、アクセスルーターがモバイルノードの承認を検証してアドレスを請求し、高速バインディングアップデートの以前のCGAがキーの名前として機能するようにします。
Table of Contents
目次
1. Introduction ....................................................2
1.1. Terminology ................................................3
2. Overview of the Protocol ........................................3
2.1. Brief Review of SEND .......................................3
2.2. Protocol Overview ..........................................4
3. Handover Key Provisioning and Use ...............................4
3.1. Sending Router Solicitations for Proxy Advertisement .......4
3.2. Receiving Router Solicitations for Proxy
Advertisement and Sending Proxy Router Advertisements ......5
3.3. Receiving Proxy Router Advertisements ......................6
3.4. Sending FBUs ...............................................7
3.5. Receiving FBUs .............................................7
3.6. Key Generation and Lifetime ................................7
3.7. Protocol Constants .........................................8
4. Message Formats .................................................8
4.1. Handover Key Request Option ................................8
4.2. Handover Key Reply Option .................................10
5. Security Considerations ........................................11
6. IANA Considerations ............................................11
7. References .....................................................12
7.1. Normative References ......................................12
7.2. Informative References ....................................12
In Fast Mobile IPv6 (FMIPv6) [FMIP], a Fast Binding Update (FBU) is sent from a Mobile Node (MN), undergoing IP handover, to the previous Access Router (AR). The FBU causes a routing change so traffic sent to the MN's previous Care-of Address on the previous AR's link is tunneled to the new Care-of Address on the new AR's link. Only an MN authorized to claim the address should be able to change the routing for the previous Care-of Address. If such authorization is not established, an attacker can redirect a victim MN's traffic at will.
高速モバイルIPv6（FMIPV6）[FMIP]では、高速バインディングアップデート（FBU）がモバイルノード（MN）からIPハンドオーバーを経て、以前のアクセスルーター（AR）に送信されます。FBUはルーティングの変更を引き起こすため、以前のARのリンク上のMNの以前のケアオブアドレスにトラフィックが送信されます。住所を請求する権限を与えられたMNのみが、以前の住所のルーティングを変更できるはずです。そのような許可が確立されていない場合、攻撃者は被害者MNのトラフィックを自由にリダイレクトできます。
In this document, a lightweight mechanism is defined by which a shared handover key for securing FMIP can be provisioned on the MN by the AR. The mechanism utilizes SEND [SEND] and an additional public/private key pair, generated on the MN using the same public key algorithm as SEND, to encrypt/decrypt a shared handover key sent from the AR to the MN. The key provisioning occurs at some arbitrary time prior to handover, thereby relieving any performance overhead on the handover process. The message exchange between the MN and AR to provision the handover key is required to be protected by SEND; that is, the source address for the key provisioning messages must be a CGA and the messages must be signed with the CGA private key. This allows the AR to establish the MN's authorization to operate on the CGA. The AR uses the CGA to name the handover key. The SEND key pair is, however, independent from the handover encryption/decryption key pair and from the actual handover key. Once the shared handover key has been established, when the MN undergoes IP handover, the MN generates an authorization Message Authentication Code (MAC) on the FBU. The previous care-of CGA included in the FBU is used by the AR to find the right handover key for checking the authorization.
このドキュメントでは、FMIPを保護するための共有ハンドオーバーキーをARによってMNにプロビジョニングできる軽量メカニズムが定義されています。メカニズムは、送信と同じ公開キーアルゴリズムを使用してMNで生成された送信[送信]と追加のパブリックキーペアを使用して、ARからMNに送信された共有ハンドオーバーキーを暗号化/復号化します。主要なプロビジョニングは、引き渡し前の任意の時期に発生し、それにより、ハンドオーバープロセスのパフォーマンスオーバーヘッドを緩和します。MNとARの間のメッセージ交換は、送信によって保護される必要があります。つまり、キープロビジョニングメッセージのソースアドレスはCGAでなければならず、メッセージはCGAの秘密鍵で署名する必要があります。これにより、ARはCGAで動作するMNの許可を確立できます。ARはCGAを使用してハンドオーバーキーに名前を付けます。ただし、送信キーペアは、ハンドオーバー暗号化/復号化キーペアと実際のハンドオーバーキーから独立しています。共有ハンドオーバーキーが確立されると、MNがIPハンドオーバーを受けると、MNはFBUで承認メッセージ認証コード（MAC）を生成します。FBUに含まれていた以前のCGAのケアは、ARが承認をチェックするための正しいハンドオーバーキーを見つけるために使用されます。
Handover keys are an instantiation of the purpose built key architectural principle [PBK].
ハンドオーバーキーは、目的で構築されたキーアーキテクチャの原則[PBK]のインスタンス化です。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はRFC 2119 [RFC2119]で説明されているように解釈されます。
In addition, the following terminology is used:
さらに、次の用語が使用されます。
CGA public key
CGA公開キー
Public key used to generate the CGA according to RFC 3972 [CGA].
RFC 3972 [CGA]に従ってCGAを生成するために使用される公開鍵。
CGA private key
CGA秘密鍵
Private key corresponding to the CGA public key.
CGA公開キーに対応する秘密鍵。
Handover key encryption public key
ハンドオーバーキー暗号化公開キー
Public key generated by the MN and sent to the current AR to encrypt the shared handover key.
MNによって生成され、現在のARに送られて共有ハンドオーバーキーを暗号化します。
Handover key encryption private key
ハンドオーバーキー暗号化秘密鍵
Private key corresponding to handover key encryption public key, held by the MN.
MNが保有するハンドオーバーキー暗号化に対応する秘密鍵。
SEND protects against a variety of threats to local link address resolution (also known as Neighbor Discovery) and last hop router (AR) discovery in IPv6 [RFC3756]. These threats are not exclusive to wireless networks, but they generally are easier to mount on certain wireless networks because the link between the access point and MN can't be physically secured.
IPv6 [RFC3756]のローカルリンクアドレス解像度（近隣発見とも呼ばれます）および最後のホップルーター（AR）発見に対するさまざまな脅威から保護を送信します。これらの脅威はワイヤレスネットワーク専用ではありませんが、アクセスポイントとMNの間のリンクを物理的に保護できないため、特定のワイヤレスネットワークに取り付けるのが一般的に簡単です。
SEND utilizes CGAs in order to secure Neighbor Discovery signaling [CGA]. Briefly, a CGA is formed by hashing together the IPv6 subnet prefix for a node's subnet, a random nonce, and an RSA public key, called the CGA public key. The CGA private key is used to sign a Neighbor Advertisement (NA) message sent to resolve the link-layer address to the IPv6 address. The combination of the CGA and the signature on the NA proves to a receiving node the sender's authorization to claim the address. The node may opportunistically generate one or several keys specifically for SEND, or it may use a certified key that it distributes more widely.
SENDは、近隣発見シグナル伝達[CGA]を保護するためにCGAを使用します。簡単に言えば、CGAは、CGA公開キーと呼ばれるノードのサブネット、ランダムなノンセ、およびRSA公開キーのIPv6サブネットプレフィックスを一緒にハッシュすることにより形成されます。CGAの秘密鍵は、IPv6アドレスへのリンク層アドレスを解決するために送信されたNeighbor Advertisement（NA）メッセージに署名するために使用されます。CGAとNAの署名の組み合わせは、受信ノードに、住所を請求する送信者の許可を証明します。ノードは、send専用に1つまたは複数のキーを日和見的に生成するか、より広く分布する認定キーを使用する場合があります。
The protocol utilizes the SEND secured Router Solicitation for Proxy Advertisement (RtSolPr)/Proxy Router Advertisement (PrRtAdv) [FMIP] exchange between the MN and the AR to transport an encrypted, shared handover key from the AR to the MN. First, the MN generates the necessary key pair and associated CGA addresses so that the MN can employ SEND. Then, the MN generates a public/private key pair for encrypting/decrypting the shared handover key, using the same public key algorithm as was used for SEND. The MN then sends an RtSolPr message with a Handover Key Request Option containing the handover key encryption public key. The source address of the RtSolPr message is the MN's care-of CGA on the AR's link, the RtSolPr message is signed with the MN's CGA key, and contains the CGA Parameters option, in accordance with RFC 3971 [SEND]. The AR verifies the message using SEND, then utilizes the handover key encryption public key to encrypt a shared handover key, which is included with the PrRtAdv in the Handover Key Reply Option. The MN decrypts the shared handover key and uses it to establish an authorization MAC when it sends an FBU to the previous AR.
プロトコルは、MNとARの間のプロキシ広告/プロキシルーター広告（PRRTADV）[FMIP]交換のために、プロキシ広告（RTSOLPR）/プロキシルーター広告（PRRTADV）の送信担保付きルーター勧誘を利用して、ARからMNへの暗号化された共有ハンドオーバーキーを輸送します。まず、MNは必要なキーペアと関連するCGAアドレスを生成して、MNが送信を採用できるようにします。次に、MNは、送信に使用されたのと同じ公開キーアルゴリズムを使用して、共有ハンドオーバーキーを暗号化/解読するためのパブリック/プライベートキーペアを生成します。MNは、ハンドオーバーキー暗号化の公開キーを含むハンドオーバーキー要求オプションを備えたRTSOLPRメッセージを送信します。RTSOLPRメッセージのソースアドレスは、ARのリンク上のMNのケアのCGAであり、RTSOLPRメッセージはMNのCGAキーで署名され、RFC 3971 [送信]に従ってCGAパラメーターオプションが含まれています。ARは送信を使用してメッセージを検証し、ハンドオーバーキー暗号化の公開キーを使用して、ハンドオーバーキー返信オプションにPRRTADVに含まれる共有ハンドオーバーキーを暗号化します。MNは、共有ハンドオーバーキーを復号化し、以前のARにFBUを送信するときに認証MACを確立するために使用します。
At some time prior to handover, the MN MUST generate a handover key encryption public/private key pair, using exactly the same public key algorithm with exactly the same parameters (key size, etc.) as for SEND [SEND]. The MN can reuse the key pair on different access routers but MUST NOT use the key pair for any other encryption or for signature operation. In order to prevent cryptanalysis, the key pair SHOULD be discarded after either a duration of HKEPK-LIFETIME or HKEPK-HANDOVERS number of handovers, whichever occurs first. See Section 3.7 for definitions of protocol constants.
ハンドオーバーの前の時点で、MNは、送信[送信]とまったく同じパラメーター（キーサイズなど）とまったく同じ公開キーアルゴリズムを使用して、ハンドオーバーキー暗号化パブリックキーペアを生成する必要があります。MNは、異なるアクセスルーターでキーペアを再利用できますが、他の暗号化や署名操作にキーペアを使用してはなりません。暗号化を防ぐために、HKEPK-LIFETIMEの期間またはHKEPKハンドオーバー数のいずれか最初のいずれかのいずれかのいずれかのハンドオーバーのいずれかの後に、キーペアを破棄する必要があります。プロトコル定数の定義については、セクション3.7を参照してください。
The MN MUST send a Router Solicitation for Proxy Advertisement (RtSolPr) containing a Handover Key Request Option with the handover encryption public key. A CGA for the MN MUST be the source address on the packet, and the MN MUST include the SEND CGA Option and SEND Signature Option with the packet, as specified in [SEND]. The SEND signature covers all fields in the RtSolPr, including the 128-bit source and destination addresses and ICMP checksum as described in RFC 3971, except for the Signature Option itself. The MN also sets the handover authentication Algorithm Type (AT) extension field in the Handover Key Request Option to the MN's preferred FBU authentication algorithm. The SEND Nonce MUST also be included for anti-replay protection.
MNは、ハンドオーバー暗号化の公開キーにハンドオーバーキー要求オプションを含むプロキシ広告（RTSOLPR）のルーター勧誘（RTSOLPR）を送信する必要があります。MNのCGAはパケットのソースアドレスである必要があり、MNには[送信]で指定されているように、CGAオプションを送信し、パケットに署名オプションを送信する必要があります。送信署名は、署名オプション自体を除き、RFC 3971で説明されている128ビットソースおよび宛先アドレス、およびICMPチェックサムを含む、RTSOLPRのすべてのフィールドをカバーします。MNは、MNの優先FBU認証アルゴリズムにハンドオーバーキー要求オプションにハンドオーバー認証アルゴリズムタイプ（AT）拡張フィールドを設定します。Send Nonceは、反レプレイ防止のためにも含める必要があります。
When an FMIPv6 capable AR with SEND receives an RtSolPr from an MN protected with SEND and including a Handover Key Request Option, the AR MUST first validate the RtSolPr using SEND as described in RFC 3971. If the RtSolPr can not be validated, the AR MUST NOT include a Handover Key Reply Option in the reply. The AR also MUST NOT change any existing key record for the address, since the message may be an attempt by an attacker to disrupt communications for a legitimate MN. The AR SHOULD respond to the RtSolPr but MUST NOT perform handover key provisioning.
送信を備えたFMIPV6対応ARが送信およびハンドオーバーキーリクエストオプションを含むMNからRTSOLPRを受信した場合、ARは最初にRFC 3971で説明されているように送信を使用してRTSOLPRを検証する必要があります。返信にハンドオーバーキー返信オプションを含めないでください。また、ARは、攻撃者が合法的なMNのコミュニケーションを混乱させようとする試みである可能性があるため、アドレスの既存のキーレコードを変更してはなりません。ARはRTSOLPRに応答する必要がありますが、ハンドオーバーキープロビジョニングを実行してはなりません。
If the RtSolPr can be validated, the AR MUST then determine whether the CGA is already associated with a shared handover key. If the CGA is associated with an existing handover key, the AR MUST return the existing handover key to the MN. If the CGA does not have a shared handover key, the AR MUST construct a shared handover key as described in Section 3.6. The AR MUST encrypt the handover key with the handover key encryption public key included in the Handover Key Request Option. The AR MUST insert the encrypted handover key into a Handover Key Reply Option and MUST attach the Handover Key Reply Option to the PrRtAdv. The lifetime of the key, HK-LIFETIME, MUST also be included in the Handover Key Reply Option. The AR SHOULD set the AT field of the Handover Key Option to the MN's preferred algorithm type indicated in the AT field of the Handover Key Request Option, if it is supported; otherwise, the AR MUST select an authentication algorithm that is of equivalent strength or stronger, and set the field to that. The AR MUST also include the SEND nonce from the RtSolPr for anti-replay protection. The AR MUST have a certificate suitable for a SEND-capable router, support SEND certificate discovery, and include a SEND CGA Option and a SEND Signature Option in the PrRtAdv messages it sends. Similarly, the mobile nodes MUST be configured with one or more SEND trust anchors so that they can verify these messages. The SEND signature covers all fields in the PrRtAdv, including the 128-bit source and destination addresses and ICMP checksum as described in RFC 3971, except for the Signature Option itself. The PrRtAdv is then unicast back to the MN at the MN's care-of CGA that was the source address on the RtSolPr. The handover key MUST be stored by the AR for future use, indexed by the CGA, and the authentication algorithm type (i.e., the resolution of the AT field processing) and HK-LIFETIME MUST be recorded with the key.
RTSOLPRを検証できる場合、ARはCGAがすでに共有ハンドオーバーキーに関連付けられているかどうかを判断する必要があります。CGAが既存のハンドオーバーキーに関連付けられている場合、ARは既存のハンドオーバーキーをMNに返す必要があります。CGAにハンドオーバーキーが共有されていない場合、ARはセクション3.6で説明されているように共有ハンドオーバーキーを構築する必要があります。ARは、ハンドオーバーキーリクエストオプションに含まれるハンドオーバーキー暗号化公開キーを使用して、ハンドオーバーキーを暗号化する必要があります。ARは、暗号化されたハンドオーバーキーをハンドオーバーキー返信オプションに挿入し、PRRTADVにハンドオーバーキーの返信オプションを添付する必要があります。キーの寿命、HK-Lifetimeも、ハンドオーバーキー返信オプションに含める必要があります。ARは、サポートされている場合、ハンドオーバーキー要求オプションのATフィールドに示されているMNの優先アルゴリズムタイプに、ハンドオーバーキーオプションのATフィールドを設定する必要があります。それ以外の場合、ARは、同等の強度またはより強力な認証アルゴリズムを選択し、それにフィールドを設定する必要があります。ARには、アンチレプレイ保護のためにRTSOLPRからのSend Nonceも含める必要があります。ARには、送信対応ルーターに適した証明書が必要であり、Send Send Empitiant Discoveryをサポートし、送信CGAオプションと送信署名オプションが送信されます。同様に、モバイルノードは、これらのメッセージを検証できるように、1つ以上の信頼アンカーを送信することで構成する必要があります。送信署名は、署名オプション自体を除き、RFC 3971に記載されている128ビットソースおよび宛先アドレスとICMPチェックサムを含む、PRRTADVのすべてのフィールドをカバーします。PRRTADVは、RTSOLPRのソースアドレスであったMNのケアオブCGAのMNにユニキャストされます。ハンドオーバーキーは、CGAによってインデックス化された将来の使用のためにARによって保存されなければなりません。および認証アルゴリズムタイプ（つまり、ATフィールド処理の解像度）とHK-Lifetimeをキーで記録する必要があります。
Upon receipt of one or more PrRtAdvs secured with SEND and having the Handover Key Reply Option, the MN MUST first validate the PrRtAdvs as described in RFC 3971. Normally, the MN will have obtained the router's certification path to validate an RA prior to sending the PrRtSol and the MN MUST check to ensure that the key used to sign the PrRtAdv is the router's certified public key. If the MN does not have the router's certification path cached, it MUST use the SEND CPS/CPA messages to obtain the certification path to validate the key. If a certified key from the router was not used to sign the message, the message MUST be dropped.
送信で保護された1つ以上のPRRTADVを受け取って、ハンドオーバーキー返信オプションを受け取ると、MNは最初にRFC 3971で説明されているようにPRRTADVを検証する必要があります。通常、MNは、RAを送信する前にRAを検証するためのルーターの認証パスを取得しました。PRRTSOLとMNは、PRRTADVに署名するために使用されるキーがルーターの認定公開キーであることを確認するためにチェックする必要があります。MNにルーターの認証パスがキャッシュされていない場合、CPS/CPAの送信メッセージを使用して認証パスを取得してキーを検証する必要があります。メッセージに署名するためにルーターの認定キーを使用していない場合、メッセージを削除する必要があります。
From the messages that validate, the MN SHOULD choose one with an AT flag in the Handover Key Reply Option indicating an authentication algorithm that the MN supports. From that message, the MN MUST determine which handover key encryption public key to use in the event the MN has more than one. The MN finds the right public key to use by matching the SEND nonce from the RtSolPr. If no such match occurs, the MN MUST drop the PrRtAdv. The MN MUST use the matching private key to decrypt the handover key using its handover key encryption private key, and store the handover key for later use, named with the AR's CGA, along with the algorithm type and HK-LIFETIME. The MN MUST use the returned algorithm type indicated in the PrRtAdv. The MN MUST index the handover keys with the AR's IPv6 address, to which the MN later sends the FBU, and the MN's CGA to which the handover key applies. This allows the MN to select the proper key when communicating with a previous AR. Prior to HK-LIFETIME expiring, the MN MUST request a new key from the AR if FMIPv6 service is still required from the router.
検証するメッセージから、MNは、MNがサポートする認証アルゴリズムを示す、ハンドオーバーキー返信オプションのATフラグを使用して1つを選択する必要があります。そのメッセージから、MNは、MNが複数持っている場合に使用するハンドオーバーキー暗号化の公開キーを決定する必要があります。MNは、RTSOLPRからの送信Nonceを一致させることにより、使用する適切な公開キーを見つけます。そのような一致が発生しない場合、MNはPRRTADVをドロップする必要があります。MNは、一致する秘密鍵を使用して、ハンドオーバーキー暗号化の秘密鍵を使用してハンドオーバーキーを復号化し、ARのCGAに名前が付けられた後で使用するためにハンドオーバーキーをアルゴリズムのタイプとHK-Lifetimeとともに保存する必要があります。MNは、PRRTADVに示されている返されたアルゴリズムタイプを使用する必要があります。MNは、MNが後にFBUを送信するARのIPv6アドレスと、ハンドオーバーキーが適用されるMNのCGAを送信するARのIPv6アドレスでハンドオーバーキーをインデックスする必要があります。これにより、MNは以前のARと通信するときに適切なキーを選択できます。HK-Lifetimeが期限切れになる前に、MNはルーターからFMIPV6サービスがまだ必要な場合はARから新しいキーを要求する必要があります。
If more than one router responds to the RtSolPr, the MN MAY keep track of all such keys. If none of the PrRtAdvs contains an algorithm type indicator corresponding to an algorithm the MN supports, the MN MAY re-send the RtSolPr requesting a different algorithm, but to prevent bidding down attacks from compromised routers, the MN SHOULD NOT request an algorithm that is weaker than its original request.
複数のルーターがRTSOLPRに応答する場合、MNはそのようなすべてのキーを追跡することができます。MNがサポートするアルゴリズムに対応するアルゴリズムタイプインジケーターがPRRTADVに含まれていない場合、MNはRTSOLPRが別のアルゴリズムを要求するが、侵害されたルーターからの入札攻撃を防ぐために、MNはアルゴリズムを要求すべきではない場合、元のリクエストよりも弱い。
When the MN needs to signal the Previous AR (PAR) using an FMIPv6 FBU, the MN MUST utilize the handover key and the corresponding authentication algorithm to generate an authenticator for the message. The MN MUST select the appropriate key for the PAR using the PAR's CGA and the MN's previous care-of CGA on the PAR's link. As defined by the FMIPv6 [FMIP], the MN MUST generate the authentication MAC using the handover key and the appropriate algorithm and MUST include the MAC in the FBU message. As specified by FMIPv6, the MN MUST include the old care-of CGA in a Home Address Option. The FMIPv6 document provides more detail about the construction of the authenticator on the FBU.
MNがFMIPV6 FBUを使用して以前のAR（PAR）を信号する必要がある場合、MNはハンドオーバーキーと対応する認証アルゴリズムを利用して、メッセージの認証器を生成する必要があります。MNは、PARのCGAとPARのリンクでMNの以前のCGAを使用してPARの適切なキーを選択する必要があります。FMIPV6 [FMIP]で定義されているように、MNはハンドオーバーキーと適切なアルゴリズムを使用して認証MACを生成する必要があり、FBUメッセージにMACを含める必要があります。FMIPV6で指定されているように、MNは自宅の住所オプションに古いCGAを含める必要があります。FMIPV6ドキュメントは、FBU上の認証器の構築に関する詳細を提供します。
When the PAR receives an FBU message containing an authenticator, the PAR MUST find the corresponding handover key using the MN's care-of CGA in the Home Address Option as the index. If a handover key is found, the PAR MUST utilize the handover key and the appropriate algorithm to verify the authenticator. If the handover key is not found, the PAR MUST NOT change forwarding for the care-of CGA. The FMIPv6 document [FMIP] provides more detail on how the AR processes an FBU containing an authenticator.
PARが認証器を含むFBUメッセージを受信した場合、PARは、インデックスとしてMNのCGAのCGAを使用して対応するハンドオーバーキーを見つける必要があります。ハンドオーバーキーが見つかった場合、PARはハンドオーバーキーと適切なアルゴリズムを使用して、認証器を検証する必要があります。ハンドオーバーキーが見つからない場合、PARはCGAのケアの転送を変更してはなりません。FMIPV6ドキュメント[FMIP]は、ARが認証器を含むFBUをどのように処理するかについての詳細を提供します。
The AR MUST randomly generate a key having sufficient strength to match the authentication algorithm. Some authentication algorithms specify a required key size. The AR MUST generate a unique key for each CGA public key, and SHOULD take care that the key generation is uncorrelated between handover keys, and between handover keys and CGA keys. The actual algorithm used to generate the key is not important for interoperability since only the AR generates the key; the MN simply uses it.
ARは、認証アルゴリズムと一致するのに十分な強度を持つキーをランダムに生成する必要があります。一部の認証アルゴリズムは、必要なキーサイズを指定します。ARは、各CGA公開キーに一意のキーを生成する必要があり、キー生成がハンドオーバーキーの間、およびハンドオーバーキーとCGAキーの間で無関係であることに注意する必要があります。キーを生成するために使用される実際のアルゴリズムは、ARのみがキーを生成するため、相互運用性にとって重要ではありません。MNは単純に使用します。
A PAR SHOULD NOT discard the handover key immediately after use if it is still valid. It is possible that the MN may undergo rapid movement to another AR prior to the completion of Mobile IPv6 binding update on the PAR, and the MN MAY as a consequence initialize another, subsequent handover optimization to move traffic from the PAR to another new AR. The default time for keeping the key valid corresponds to the default time during which forwarding from the PAR to the new AR is performed for FMIP. The FMIPv6 document [FMIP] provides more detail about the FMIP forwarding time default.
PARは、使用後すぐにハンドオーバーキーを廃棄しないでください。Mnは、PARでモバイルIPv6バインディングアップデートが完了する前に別のARに急速に移動する可能性があり、Mnは別の、その後のハンドオーバー最適化を初期化して、トラフィックをPARから別の新しいARに移動する可能性があります。キーを有効に保つためのデフォルトの時間は、PARから新しいARへの転送がFMIPに対して実行されるデフォルトの時間に対応します。FMIPV6ドキュメント[FMIP]は、FMIP転送時間のデフォルトの詳細を提供します。
If the MN returns to a PAR prior to the expiration of the handover key, the PAR MAY send and the MN MAY receive the same handover key as was previously returned, if the MN generates the same CGA for its Care-of Address. However, the MN MUST NOT assume that it can continue to use the old key without actually receiving the handover key again from the PAR. The MN SHOULD discard the handover key after MIPv6 binding update is complete on the new AR. The PAR MUST discard the key after FMIPv6 forwarding for the previous Care-of Address times out or when HK-LIFETIME expires.
MNがハンドオーバーキーの有効期限の前にPARに戻った場合、PARは送信され、MNが以前に返されたのと同じハンドオーバーキーを受信する場合があります。ただし、MNは、実際にハンドオーバーキーをPARから再び受信せずに古いキーを使用し続けることができると想定してはなりません。MIPV6バインディングアップデートが新しいARで完了した後、MNはハンドオーバーキーを破棄する必要があります。PARは、以前の住所ケアタイムアウトまたはHK-lifetimeが期限切れになった場合、FMIPV6転送後にキーを破棄する必要があります。
The following are protocol constants with suggested defaults:
以下は、提案されたデフォルトのプロトコル定数です。
HKEPK-LIFETIME: The maximum lifetime for the handover key encryption public key. Default is 12 hours.
HKEPK-LIFETIME：ハンドオーバーキー暗号化の公開キーの最大寿命。デフォルトは12時間です。
HKEPK-HANDOVERS: The maximum number of handovers for which the handover key encryption public key should be reused. Default is 10.
HKEPKハンドオーバー：ハンドオーバーキー暗号化の公開キーを再利用するハンドオーバーの最大数。デフォルトは10です。
HK-LIFETIME: The maximum lifetime for the handover key. Default is 12 hours (43200 seconds).
HK-Lifetime：ハンドオーバーキーの最大寿命。デフォルトは12時間（43200秒）です。
The Handover Key Request Option is a standard IPv6 Neighbor Discovery [RFC4861] option in TLV format. The Handover Key Request Option is included in the RtSolPr message along with the SEND CGA Option, RSA Signature Option, and Nonce Option.
ハンドオーバーキーリクエストオプションは、TLV形式の標準のIPv6 Neighbor Discovery [RFC4861]オプションです。ハンドオーバーキーリクエストオプションは、rtsolprメッセージに含まれています。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Pad Length | AT |Resrvd.|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Handover Key Encryption Public Key .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Padding .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Fields:
Type: 27
タイプ：27
Length: The length of the option in units of 8 octets, including the Type and Length fields. The value 0 is invalid. The receiver MUST discard a message that contains this value.
長さ：タイプと長さのフィールドを含む8オクテットの単位のオプションの長さ。値0は無効です。受信者は、この値を含むメッセージを破棄する必要があります。
Pad Length: The number of padding octets beyond the end of the Handover Key Encryption Public Key field but within the length specified by the Length field. Padding octets MUST be set to zero by senders and ignored by receivers.
パッドの長さ：ハンドオーバーキー暗号化の端を越えてオクテットをパディングする数は、公開キーフィールドですが、長さフィールドで指定された長さ内に。パディングオクテットは、送信者によってゼロに設定され、レシーバーによって無視される必要があります。
AT: A 4-bit algorithm type field describing the algorithm used by FMIPv6 to calculate the authenticator. See [FMIP] for details.
AT：Authenticatorを計算するためにFMIPV6が使用するアルゴリズムを記述する4ビットアルゴリズムタイプフィールド。詳細については、[fmip]を参照してください。
Resrvd.: A 4-bit field reserved for future use. The value MUST be initialized to zero by the sender and MUST be ignored by the receiver.
Resrvd。：将来の使用のために予約されている4ビットフィールド。値は送信者によってゼロに初期化され、受信機によって無視される必要があります。
Handover Key Encryption Public Key: The handover key encryption public key. The key MUST be formatted according to the same specification as the CGA key in the CGA Parameters Option [CGA] of the message, and MUST have the same parameters as the CGA key.
ハンドオーバーキー暗号化公開キー：ハンドオーバーキー暗号化公開キー。キーは、メッセージのCGAパラメーターオプション[CGA]のCGAキーと同じ仕様に従ってフォーマットする必要があり、CGAキーと同じパラメーターを持つ必要があります。
Padding: A variable-length field making the option length a multiple of 8, containing as many octets as specified in the Pad Length field.
パディング：オプションの長さを8の倍数にする可変長フィールドで、パッドの長さフィールドで指定されている数のオクテットが含まれています。
The Handover Key Reply Option is a standard IPv6 Neighbor Discovery [RFC4861] option in TLV format. The Handover Key Reply Option is included in the PrRtAdv message along with the SEND CGA Option, RSA Signature Option, and Nonce Option.
ハンドオーバーキー返信オプションは、TLV形式の標準的なIPv6 Neighbor Discovery [RFC4861]オプションです。Handover Key Replyオプションは、Send CGAオプション、RSA署名オプション、およびNONCEオプションとともに、PRRTADVメッセージに含まれています。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Pad Length | AT |Resrvd.|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Key Lifetime | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| |
. .
. Encrypted Handover Key .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Padding .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Fields:
田畑：
Type: 28
タイプ：28
Length: The length of the option in units of 8 octets, including the Type and Length fields. The value 0 is invalid. The receiver MUST discard a message that contains this value.
長さ：タイプと長さのフィールドを含む8オクテットの単位のオプションの長さ。値0は無効です。受信者は、この値を含むメッセージを破棄する必要があります。
Pad Length: The number of padding octets beyond the end of the Encrypted Handover Key field but within the length specified by the Length field. Padding octets MUST be set to zero by senders and ignored by receivers.
パッドの長さ：暗号化されたハンドオーバーキーフィールドの端を超えて、長さフィールドで指定された長さ内でパディングオクテットの数。パディングオクテットは、送信者によってゼロに設定され、レシーバーによって無視される必要があります。
AT: A 4-bit algorithm type field describing the algorithm used by FMIPv6 to calculate the authenticator. See [FMIP] for details.
AT：Authenticatorを計算するためにFMIPV6が使用するアルゴリズムを記述する4ビットアルゴリズムタイプフィールド。詳細については、[fmip]を参照してください。
Resrvd.: A 4-bit field reserved for future use. The value MUST be initialized to zero by the sender and MUST be ignored by the receiver.
Resrvd。：将来の使用のために予約されている4ビットフィールド。値は送信者によってゼロに初期化され、受信機によって無視される必要があります。
Key Lifetime: Lifetime of the handover key, HK-LIFETIME, in seconds.
キーライフタイム：ハンドオーバーキー、hk-lifetimeの寿命、秒単位。
Encrypted Handover Key: The shared handover key, encrypted with the MN's handover key encryption public key, using the RSAES-PKCS1-v1_5 format [RFC3447].
暗号化されたハンドオーバーキー：RSAES-PKCS1-V1_5形式[RFC3447]を使用して、MNのハンドオーバーキー暗号化公開キーで暗号化された共有ハンドオーバーキー。
Padding: A variable-length field making the option length a multiple of 8, containing as many octets as specified in the Pad Length field.
パディング：オプションの長さを8の倍数にする可変長フィールドで、パッドの長さフィールドで指定されている数のオクテットが含まれています。
This document describes a shared key provisioning protocol for the FMIPv6 handover optimization protocol. The key provisioning protocol utilizes a public key generated with the same public key algorithm as SEND to bootstrap a shared key for authorizing changes due to handover associated with the MN's former address on the PAR. General security considerations involving CGAs apply to the protocol described in this document, see [CGA] for a discussion of security considerations around CGAs. This protocol is subject to the same risks from replay attacks and denial-of-service (DoS) attacks using the RtSolPr as the SEND protocol [SEND] for RS. The measures recommended in RFC 3971 for mitigating replay attacks and DoS attacks apply here as well. An additional consideration involves when to generate the handover key on the AR. To avoid state depletion attacks, the handover key SHOULD NOT be generated prior to SEND processing that verifies the originator of RtSolPr. State depletion attacks can be addressed by techniques, such as rate limiting RtSolPr, restricting the amount of state reserved for unresolved solicitations, and clever cache management. These techniques are the same as used in implementing Neighbor Discovery.
このドキュメントでは、FMIPv6ハンドオーバー最適化プロトコルの共有キープロビジョニングプロトコルについて説明します。キープロビジョニングプロトコルは、PARのMNの以前のアドレスに関連付けられているハンドオーバーによる変更を承認するための共有キーをBootStrapに送信するのと同じ公開キーアルゴリズムで生成された公開キーを使用します。CGAが関与する一般的なセキュリティ上の考慮事項このドキュメントに記載されているプロトコルに適用されます。CGAに関するセキュリティに関する考慮事項については、[CGA]を参照してください。このプロトコルは、RTSOLPRをRsの送信プロトコル[送信]として使用して、リプレイ攻撃とサービス拒否（DOS）攻撃から同じリスクを課しています。RFC 3971で推奨される措置は、リプレイ攻撃とDOS攻撃を緩和するためにもここにも適用されます。追加の考慮事項には、ARでハンドオーバーキーを生成するタイミングが含まれます。州の枯渇攻撃を避けるために、RTSOLPRの発信者を検証する処理を送信する前に、ハンドオーバーキーを生成しないでください。州の枯渇攻撃は、RTSOLPRを制限するレート、未解決の勧誘のために予約されている州の量、および巧妙なキャッシュ管理などの手法によって対処できます。これらの手法は、近隣発見の実装で使用されるのと同じです。
For other FMIPv6 security considerations, please see the FMIPv6 document [FMIP].
他のFMIPV6セキュリティに関する考慮事項については、FMIPv6ドキュメント[FMIP]を参照してください。
IANA has assigned IPv6 Neighbor Discovery option type codes for the two new IPv6 Neighbor Discovery options, the Handover Key Request Option (27) and Handover Key Reply Option (28), defined in this document.
IANAは、このドキュメントで定義されている2つの新しいIPv6ネイバーディスカバリーオプション、ハンドオーバーキーリクエストオプション（27）およびハンドオーバーキー返信オプション（28）のIPv6ネイバーディスカバリーオプションタイプコードを割り当てました。
[FMIP] Koodli, R., Ed., "Mobile IPv6 Fast Handovers", RFC 5268, June 2008.
[FMIP] Koodli、R.、ed。、「Mobile IPv6 Fast Handovers」、RFC 5268、2008年6月。
[SEND] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander, "SEcure Neighbor Discovery (SEND)", RFC 3971, March 2005.
[送信] Arkko、J.、ed。、Kempf、J.、Zill、B。、およびP. Nikander、「Secure Neighbor Discovery（Send）」、RFC 3971、2005年3月。
[CGA] Aura, T., "Cryptographically Generated Addresses (CGA)", RFC 3972, March 2005.
[CGA]オーラ、T。、「暗号化されたアドレス（CGA）」、RFC 3972、2005年3月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, September 2007.
[RFC4861] Narten、T.、Nordmark、E.、Simpson、W。、およびH. Soliman、「IPバージョン6（IPv6）の近隣発見」、RFC 4861、2007年9月。
[RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography Standards (PKCS) #1: RSA Cryptography Specifications Version 2.1", RFC 3447, February 2003.
[RFC3447] Jonsson、J.およびB. Kaliski、「Public-Key Cryptography Standards（PKCS）＃1：RSA暗号仕様バージョン2.1」、RFC 3447、2003年2月。
[RFC3756] Nikander, P., Ed., Kempf, J., and E. Nordmark, "IPv6 Neighbor Discovery (ND) Trust Models and Threats", RFC 3756, May 2004.
[RFC3756] Nikander、P.、Ed。、Kempf、J。、およびE. Nordmark、「IPv6 Neighbor Discovery（ND）Trust Models and Threats」、RFC 3756、2004年5月。
[PBK] Bradner, S., Mankin, A., and Schiller, J., "A Framework for Purpose-Built Keys (PBK)", Work in Progress, June 2003. Progress.
[PBK] Bradner、S.、Mankin、A。、およびSchiller、J。、「専用キー（PBK）のフレームワーク」、2003年6月、進行中の作業。
Authors' Addresses
著者のアドレス
James Kempf DoCoMo Labs USA 3240 Hillview Avenue Palo Alto, CA 94303 USA
James Kempf Docomo Labs USA 3240 Hillview Avenue Palo Alto、CA 94303 USA
Phone: +1 650 496 4711
EMail: kempf@docomolabs-usa.com
Rajeev Koodli Starent Networks 30 International Place Tewksbury, MA 01876 USA
Rajeev Koodli Starent Networks 30 International Place Tewksbury、MA 01876 USA
Phone: +1 408 735 7679
EMail: rkoodli@starentnetworks.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2008).
著作権（c）The IETF Trust（2008）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書は、BCP 78に含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持しています。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供され、貢献者、彼/彼女が代表する組織（もしあれば）、インターネット協会、IETFトラスト、インターネットエンジニアリングタスクフォースがすべてを否認します。明示的または黙示的な保証。ここでの情報の使用は、特定の目的に対する商品性または適合性の権利または暗黙の保証を侵害しないという保証を含むがこれらに限定されない。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、この文書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスがどの程度であるかについての使用に関連すると主張する可能性があるという立場はありません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要な技術をカバーする可能性のあるその他の独自の権利を注意深く招待するよう招待しています。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。