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と）ハンドオーバキーを使用して、安全な近隣探索を配布（SEND）
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からプロキシ広告とプロキシルータアドバタイズメントのためのルータ要請を使用しています。鍵交換メッセージは、SENDセキュリティが要求されています。つまり、送信元アドレスは、暗号生成されたアドレス（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）は、前のアクセスルータ（AR）に、IPハンドオーバを受け、モバイルノード（MN）から送信されます。 FBUは、新しい新しいARのリンク上の気付アドレスにトンネリングされるMNの以前のケア - の前のARのリンク上のアドレスに送信されたトラフィックので、ルーティング変化を引き起こします。アドレスのみを主張する権限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
この文書では、軽量な機構がFMIPを確保するため、共有ハンドオーバキーがARによってMNにプロビジョニングすることができることにより定義されます。機構は、MNのARから送信された共有ハンドオーバキーを暗号化/復号化するために、[SEND]とSENDと同じ公開鍵アルゴリズムを使用してMNに発生する追加の公開/秘密鍵ペアを送信利用します。鍵プロビジョニングは、それによって、ハンドオーバプロセスの任意のパフォーマンス・オーバーヘッドを軽減すること、ハンドオーバ前に、いくつかの任意の時点で発生します。 SENDによって保護する必要があるハンドオーバキー規定MNとARとの間のメッセージ交換。つまり、キープロビジョニング・メッセージの送信元アドレスがCGAでなければならないとのメッセージがCGA秘密鍵で署名する必要があります。これは、ARは、上で動作するようにMNの認可を確立することができます
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.
CGA。 ARは、ハンドオーバキーに名前を付けるためにCGAを使用しています。 SENDキーペアは、しかしながら、ハンドオーバ暗号化/復号鍵対から、実際のハンドオーバキーから独立しています。共有ハンドオーバキーが確立された後、MNはIPハンドオーバを受けたときに、MNは、FBUに承認メッセージ認証コード（MAC）を生成します。前の気付CGAは、FBUに含ま承認をチェックするための右のハンドオーバキーを見つけるために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].
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.
Handover key encryption private key
ハンドオーバ鍵暗号の秘密鍵
Private key corresponding to handover key encryption public
key, held by the 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.
SENDは、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]シグナル近隣探索を確保するためにCGAsを利用しています。簡単に言えば、CGAは、ノードのサブネット、ランダムナンス、およびRSA公開鍵のIPv6サブネットプレフィックスを一緒にハッシュすることによって形成され、CGA公開鍵と呼ばれます。 CGA秘密鍵は、IPv6アドレスへのリンク層アドレスを解決するために送られた近隣広告（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とMNのARから暗号化され、共有ハンドオーバキーを輸送するAR間のプロキシ広告（RtSolPrを）/プロキシルータ広告（代理ルータ広告）[FMIP]交換SEND固定ルータ要請を利用します。 MNはSENDを採用することができるようにまず、MNは、必要な鍵ペアと関連するCGAアドレスを生成します。その後、MNはSENDのために使用されたのと同じ公開鍵アルゴリズムを使用して、共有ハンドオーバキーを暗号化/復号化のための公開鍵/秘密鍵のペアを生成します。 MNは、ハンドオーバ鍵暗号公開鍵を含むハンドオーバキー要求オプションでRtSolPrをメッセージを送信します。 RtSolPrをメッセージの送信元アドレスは、MNの気付CGA ARのリンク上で、RtSolPrをメッセージはMNのCGAキーで署名されており、RFC 3971 [SEND]に従って、CGAパラメータオプションが含まれています。 ARはその後、SEND使用してメッセージを確認するオプションを返信ハンドオーバキーで代理ルータ広告に含まれている共有ハンドオーバキーを暗号化するためにハンドオーバ鍵暗号、公開鍵を利用しています。 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はSEND [SEND]の場合と全く同じパラメータ（キーサイズなど）とまったく同じ公開鍵アルゴリズムを使用して、ハンドオーバ鍵暗号、公開鍵/秘密鍵のペアを生成しなければなりません。 MNは、異なるアクセスルータ上で鍵ペアを再利用することができますが、他の暗号化のためか、署名操作のための鍵のペアを使用してはなりません。暗号解読を防止するために、鍵のペアはHKEPK寿命の期間またはいずれか早い方ハンドオーバの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は、ハンドオーバ暗号公開鍵でハンドオーバキー要求オプションを含むProxy広告のためのルーター要請（RtSolPrを）を送らなければなりません。 MNのためのCGAは、パケット上のソースアドレスでなければなりません、そしてMNはSEND CGAオプションを含み、[SEND]で指定されるように、パケットに署名オプションを送らなければなりません。 SEND署名は、署名オプション自体を除いて、RFC 3971に記載されているように128ビットの送信元アドレスと宛先アドレスとICMPチェックサムを含む、RtSolPrを内のすべてのフィールドをカバーします。 MNはまた、MNの好適FBU認証アルゴリズムへのハンドオーバキー要求オプションでハンドオーバー認証アルゴリズムのタイプ（AT）拡張フィールドを設定します。 SENDナンスもアンチリプレイ保護のために含まれなければなりません。
3.2. Receiving Router Solicitations for Proxy Advertisement and Sending Proxy Router Advertisements
3.2. プロキシ広告のためのルータ要請を受けて、プロキシルータ広告を送信します
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.
SENDとFMIPv6と可能なARがSENDで保護MNからRtSolPrをを受信し、ハンドオーバキー要求オプションを含む場合、ARは最初RFC 3971.に記載されているようにRtSolPrをARが行う必要があり、検証することができない場合SEND使用RtSolPrを検証しなければなりませんハンドオーバキーは含まれませ応答でオプションを返信します。メッセージが正当なMNのための通信を妨害する攻撃者の試みかもしれないのでARはまた、アドレスの既存のキーのレコードを変更しないでください。 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は、共有ハンドオーバキーを持っていない場合は、セクション3.6で説明したように、ARは、共有ハンドオーバキーを構築しなければなりません。 ARはハンドオーバキー要求オプションに含まハンドオーバ鍵暗号、公開鍵を使用して、ハンドオーバキーを暗号化する必要があります。 ARはハンドオーバキーに暗号化されたハンドオーバキーを挿入しなければなりません。オプションを返信し、ハンドオーバキーを添付しなければならない代理ルータ広告にオプションを返信します。キーの有効期間、HK-LIFETIME、また、ハンドオーバキーに含まれなければならないがオプションを返信します。それがサポートされている場合ARは、ハンドオーバキー要求オプションのATフィールドに示さMNの好ましいアルゴリズムのタイプにハンドオーバキーオプションのATフィールドを設定すべきです。そうでない場合、ARは、同等の強度またはより強いである認証アルゴリズムを選択し、それにフィールドを設定しなければなりません。 ARはまた、アンチリプレイ保護のためRtSolPrをからSEND nonceを含まなければなりません。 ARは、SEND対応ルータに適した証明書を持っているSEND証明書の発見をサポートし、SEND CGAオプションとは、送信する代理ルータ広告メッセージにSEND署名オプションを指定する必要があります。彼らはこれらのメッセージを確認できるように、同様に、モバイルノードは、一つ以上のSENDのトラストアンカーを設定する必要があります。 SEND署名は、署名オプション自体を除いて、RFC 3971に記載されているように128ビットの送信元アドレスと宛先アドレスとICMPチェックサムを含め、代理ルータ広告内のすべてのフィールドをカバーします。代理ルータ広告は、RtSolPrを上のソースアドレスだったMNの気付CGAでMNに戻ってユニキャストされます。ハンドオーバキーはCGAによってインデックス付け、将来の使用のためにARによって記憶されなければならない、および認証アルゴリズムタイプ（ATフィールドの処理、すなわち、解像度）とHK-寿命がキーで記録されなければなりません。
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.
SENDに固定された1つ以上のPrRtAdvsを受信すると、ハンドオーバキーはオプションを返信持つRFC 3971.通常で説明したように、MNは、最初PrRtAdvsを検証しなければならない、MNは、送信前にRAを検証するために、ルータの証明書パスを取得していますPrRtSolとMNは、代理ルータ広告を署名するために使用されるキーは、ルータの認証を取得した公開鍵であることを確認するためにチェックしなければなりません。 MNは、ルータの証明書パスがキャッシュされていない場合は、キーを検証する証明書パスを取得するためのSEND 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は、ハンドオーバキーでATフラグに1を選択してくださいMNがサポートする認証アルゴリズムを示すオプションを返信します。そのメッセージからは、MNは、MNが複数の持っている場合には、使用するハンドオーバ鍵暗号、公開鍵を決定する必要があります。 MNは、RtSolPrをからSEND nonceを一致させることによって、使用する権利公開鍵を見つけました。そのようなマッチが発生していない場合は、MNは、代理ルータ広告を削除する必要があります。 MNは、アルゴリズムの種類とHK-LIFETIMEとともに、そのハンドオーバ鍵暗号の秘密鍵を使用して、ハンドオーバキーを解読し、ARのCGAと名付けられ、後の使用のためのハンドオーバキーを格納するために、一致する秘密鍵を使用しなければなりません。 MNは、代理ルータ広告に示されている返されたアルゴリズムのタイプを使用しなければなりません。 MNのMUSTのMNが、後にFBUを送信する指標ARのIPv6アドレスを持つハンドオーバキー、およびハンドオーバキーが適用されるMNのCGA。これは、前のARとの通信時MNは、適切なキーを選択することができます。 FMIPv6とサービスがまだルータから要求された場合にHK-LIFETIMEが期限切れに先立ち、MNは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は、そのようなすべてのキーを追跡するかもしれません。 PrRtAdvsのどれもが、MNがサポートするアルゴリズムに対応するアルゴリズムタイプインジケータが含まれていない場合、MNは異なるアルゴリズムを要求RtSolPrを再送信してもよい（MAY）が、妥協のルータから競り下げ攻撃を防ぐために、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は、FBU FMIPv6とを使用して前のAR（PAR）をシグナリングする必要がある場合、MNは、メッセージの認証子を生成するために、ハンドオーバキーと対応する認証アルゴリズムを利用しなければなりません。 MNは、PARのCGAとMNの以前の気付CGA PARのリンク上を使用して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を使用して、対応するハンドオーバキーを見つけなければなりません。ハンドオーバキーが見つかった場合、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 MAYは、別の新しいARにPARからのトラフィックを移動させる別の、その後のハンドオーバの最適化を初期化することが可能です。 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はその気付アドレスに同じCGAを生成した場合、以前に、返されたのと同じハンドオーバキーを受け取ることができます。しかし、MNは、それが実際PARから再びハンドオーバキーを受信することなく、古いキーを使用し続けることができますと仮定してはいけません。 MIPv6のバインディングアップデートが新しいARに完了した後、MNは、ハンドオーバキーを捨てます。 PARは、FMIPv6とは、以前の気付アドレスがタイムアウトのために転送する場合、またはHK-LIFETIMEの有効期限が切れた後にキーを捨てなければなりません。
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近隣探索[RFC4861]のオプションです。ハンドオーバキー要求オプションは、SEND CGAオプション、RSA署名オプション、およびノンスオプションと共に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：オーセンティケータを計算するために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 .: A 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近隣探索[RFC4861]のオプションです。ハンドオーバキーオプションがSEND CGAオプション、RSA署名オプション、およびノンスオプションと共に、代理ルータ広告メッセージに含まれている返信。
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：オーセンティケータを計算するために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 .: A 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の元アドレスに関連付けられたハンドオーバによる変化を認可するための共有キーをブートストラップするためにSENDと同じ公開鍵アルゴリズムで生成した公開鍵を利用しています。 CGAsを含む一般的なセキュリティ上の考慮事項は、この文書に記載されているプロトコルには適用され、CGAs周りのセキュリティ上の考慮事項の議論については、[CGA]を参照してください。このプロトコルは、RSのためにSENDプロトコル[SEND]としてRtSolPrをを使用して、リプレイ攻撃やサービス拒否（DoS）攻撃から同じリスクにさらされます。リプレイ攻撃やDoS攻撃を緩和するためのRFC 3971で推奨策はここにも適用されます。 AR上のハンドオーバキーを生成する際に、追加の考慮事項が含まれます。状態枯渇の攻撃を避けるために、ハンドオーバキーは、RtSolPrをの発信元を確認する処理を送信する前に生成されるべきではありません。状態の枯渇攻撃は未解決の勧誘のために予約状態の量、および巧妙なキャッシュ管理を制限し、そのようRtSolPrを速度制限などの技術によって対処することができます。近隣探索の実装で使用されるこれらの技術は同じです。
For other FMIPv6 security considerations, please see the FMIPv6 document [FMIP].
他のFMIPv6とセキュリティの考慮事項については、[FMIP] FMIPv6との文書を参照してください。
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近隣探索オプションのIPv6近隣探索オプションタイプコードを割り当てられた、ハンドオーバキー要求オプション（27）とハンドオーバキーは、この文書で定義されたオプション（28）を、返信します。
[FMIP] Koodli, R., Ed., "Mobile IPv6 Fast Handovers", RFC 5268, June 2008.
[FMIP] Koodli、R.、エド。、 "モバイルIPv6高速ハンドオーバ"、RFC 5268、2008年6月。
[SEND] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander, "SEcure Neighbor Discovery (SEND)", RFC 3971, March 2005.
[SEND] Arkko、J.、編、ケンプ、J.、Zill、B.、およびP. Nikander、 "セキュア近隣探索（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]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、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.、シンプソン、W.、およびH.ソリマン、 "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]ジョンソン、J.とB. Kaliski、 "公開鍵暗号規格（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。、編、ケンプ、J.、およびE. Nordmarkと、 "IPv6近隣探索（ND）信頼モデルと脅威"、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]ブラドナー、S.、マンキン、A.、及びシラー、J.、 "専用キー（PBK）のためのフレームワーク" が進歩、2003年6月進行中で働いています。
Authors' Addresses
著者のアドレス
James Kempf DoCoMo Labs USA 3240 Hillview Avenue Palo Alto, CA 94303 USA
ジェームズ・ケンプドコモUSA研究所3240ヒルビュー・アベニューカリフォルニア州パロアルト94303 USA
Phone: +1 650 496 4711 EMail: kempf@docomolabs-usa.com
電話：+1 650 496 4711 Eメール：kempf@docomolabs-usa.com
Rajeev Koodli Starent Networks 30 International Place Tewksbury, MA 01876 USA
ラジーブKoodliスタレントネットワークス30・インターナショナル・プレイステュークスベリー、MA 01876 USA
Phone: +1 408 735 7679 EMail: rkoodli@starentnetworks.com
電話：+1 408 735 7679 Eメール：rkoodli@starentnetworks.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2008).
著作権（C）IETFトラスト（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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットSOCIETY、（もしあれば）を後援し、IETF TRUST ANDインターネットエンジニアリングタスクフォース放棄ALLに設けられています。保証は、明示または黙示、この情報の利用および特定目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証がこれらに限定されません。
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.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができます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に情報を記述してください。