[要約] 要約：RFC 4449は、モバイルIPv6ルート最適化のセキュリティを向上させるための静的共有キーの使用について説明しています。 目的：このRFCの目的は、モバイルIPv6ネットワークでのルート最適化のセキュリティを確保するために、静的共有キーの使用方法を提案することです。
Network Working Group C. Perkins
Request for Comments: 4449 Nokia Research Center
Category: Standards Track June 2006
Securing Mobile IPv6 Route Optimization Using a Static Shared Key
静的共有キーを使用したモバイルIPv6ルート最適化の保護
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）の現在のエディションを参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2006).
Copyright（c）The Internet Society（2006）。
Abstract
概要
A mobile node and a correspondent node may preconfigure data useful for precomputing a Binding Management Key that can subsequently be used for authorizing Binding Updates.
モバイルノードと特派員ノードは、バインディングの更新を承認するために使用できる拘束力のある管理キーを事前に計算するのに役立つデータを事前に設定できます。
Table of Contents
目次
1. Introduction ....................................................1
2. Applicability Statement .........................................2
3. Precomputing a Binding Management Key (Kbm) .....................3
4. Security Considerations .........................................4
5. Acknowledgement .................................................5
6. References ......................................................5
6.1. Normative References .......................................5
6.2. Informative References .....................................6
This specification introduces an alternative, low-latency security mechanism for protecting signaling related to the route optimization in Mobile IPv6. The default mechanism specified in [1] uses a periodic return routability test to verify both the "right" of the mobile node to use a specific home address, as well as the validity of the claimed care-of address. That mechanism requires no configuration and no trusted entities beyond the mobile node's home agent.
この仕様では、モバイルIPv6のルート最適化に関連するシグナル伝達を保護するための代替の低遅延セキュリティメカニズムを紹介します。[1]で指定されているデフォルトのメカニズムは、定期的な返品ルー上のテストを使用して、モバイルノードの「右」の両方を検証して、特定のホームアドレスを使用し、主張されたケアオブアドレスの有効性を検証します。そのメカニズムには、モバイルノードのホームエージェントを超えて構成も信頼できるエンティティも必要ありません。
The mechanism specified in this document, however, requires the configuration of a shared secret between mobile node and its correspondent node. As a result, messages relating to the routability tests can be omitted, leading to significantly smaller latency. In addition, the right to use a specific home address is ensured in a stronger manner than in [1]. On the other hand, the applicability of this mechanisms is limited due to the need for preconfiguration. This mechanism is also limited to use only in scenarios where mobile nodes can be trusted not to misbehave, as the validity of the claimed care-of addresses is not verified.
ただし、このドキュメントで指定されたメカニズムには、モバイルノードとその特派員ノードの間の共有秘密の構成が必要です。その結果、ルー上のテストに関連するメッセージを省略し、遅延が大幅に小さいことになります。さらに、特定のホームアドレスを使用する権利は、[1]よりも強力な方法で保証されます。一方、このメカニズムの適用性は、事前構成の必要性のために制限されています。このメカニズムは、請求された住所の妥当性が確認されていないため、モバイルノードが不正行為をしないと信頼できるシナリオでのみ使用することも限定されています。
The keywords "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 [2]. Other terminology is used as already defined in [1].
キーワードは「必要」、「必要」、「必須」、「shall」、「shall "、" sulld "、" nove "、" becommended "、" "、" optional "は、RFC 2119 [2]に記載されているように解釈されます。他の用語は、[1]ですでに定義されているように使用されています。
This mechanism is useful in scenarios where the following conditions are all met:
このメカニズムは、次の条件がすべて満たされているシナリオで役立ちます。
- Mobile node and correspondent node are administered within the same domain.
- モバイルノードと特派員ノードは、同じドメイン内で管理されます。
- The correspondent node has good reason to trust the actions of the mobile node. In particular, the correspondent node needs to be certain that the mobile node will not launch flooding attacks against a third party as described in [5].
- 特派員ノードには、モバイルノードのアクションを信頼する正当な理由があります。特に、CRERRECRESTENT NODEは、[5]に記載されているように、モバイルノードが第三者に対して洪水攻撃を開始しないことを確認する必要があります。
- The configuration effort related to this mechanism is acceptable. Users MUST be able to generate/select a sufficiently good value for Kcn (see [3])
- このメカニズムに関連する構成の取り組みは受け入れられます。ユーザーは、KCNに対して十分に良い値を生成/選択できる必要があります（[3]を参照）
- There is a desire to take advantage of higher efficiency or greater assurance with regards to the correctness of the home address offered via this mechanism.
- このメカニズムを介して提供されるホームアドレスの正確性に関して、より高い効率性またはより高い保証を利用したいという願望があります。
- This mechanism is used only for authenticating Binding Update messages (and not, e.g., data), so the total volume of traffic is low (see RFC 4107 [4], and the discussion in section 4).
- このメカニズムは、バインディングアップデートメッセージの認証にのみ使用されます（データなどではありません）、トラフィックの総量は低くなります（RFC 4107 [4]、およびセクション4の説明を参照）。
This mechanism can also be useful in software development, testing, and diagnostics related to mobility signaling.
このメカニズムは、モビリティシグナル伝達に関連するソフトウェア開発、テスト、診断にも役立ちます。
Generally speaking, the required level of trust that the correspondent node needs for enabling a precomputable Kbm with a mobile node is more often found within relatively small, closed groups of users who are personally familiar with each other, or who have some external basis for establishing trustworthy interactions. A typical example scenario where this mechanism is applicable is within a corporation, or between specific users. Application in the general Internet is typically not possible due to the effort that is required to manually configure the correspondent nodes. Application at a public network operator is typically not possible due to requirements placed on the trustworthiness of mobile nodes.
一般的に言えば、特派員ノードがモバイルノードを使用して事前コンパート可能なKBMを有効にするために必要な信頼のレベルは、比較的小さな閉じたユーザーのグループ内で、お互いに個人的に精通している、または確立するための外部の基礎を持っているユーザーの閉じたグループ内でより頻繁に見られます。信頼できる相互作用。このメカニズムが適用される典型的な例のシナリオは、企業内または特定のユーザー間であります。一般的に、一般的なインターネットでのアプリケーションは、特派員ノードを手動で構成するために必要な努力のために不可能です。通常、パブリックネットワークオペレーターでのアプリケーションは、モバイルノードの信頼性に課される要件のために、通常は不可能です。
A mobile node and a correspondent node may preconfigure data useful for creating a Binding Management Key (Kbm), which can then be used for authorizing binding management messages, especially Binding Update and Binding Acknowledgement messages. This data is as follows:
モバイルノードと特派員ノードは、拘束力のある管理キー（KBM）の作成に役立つデータを事前に設定する場合があります。これは、バインディング管理メッセージ、特に拘束力のある更新および拘束力のある確認メッセージを承認するために使用できます。このデータは次のとおりです。
- A shared key (Kcn) used to generate keygen tokens, at least 20 octets long
- Keygenトークンを生成するために使用される共有キー（KCN）、少なくとも20オクテットの長さ
- A nonce for use when generating the care-of keygen token
- Keygenのケアを生成するときに使用するための非Ce
- A nonce for use when generating the home keygen token
- ホームKeygenトークンを生成するときに使用するためのノンセ
The keygen tokens MUST be generated from Kcn and the nonces as specified in Mobile IPv6 [1] return routability. Likewise, the binding management key Kbm must subsequently be generated from the keygen tokens in the same way as specified in Mobile IPv6 [1]. The preconfigured data is associated to the mobile node's home address. Kcn MUST be generated with sufficient randomness (see RFC 4086 [3]).
keygenトークンは、モバイルIPv6 [1]で指定されているKCNとNoncesから生成する必要があります。同様に、バインディング管理キーKBMは、モバイルIPv6で指定されたものと同じ方法で、keygenトークンから生成する必要があります[1]。事前に設定されたデータは、モバイルノードのホームアドレスに関連付けられています。KCNは十分なランダム性で生成する必要があります（RFC 4086 [3]を参照）。
Replay protection for Binding Update messages using Kbm computed from the preconfigured data depends upon the value of the Sequence Number field in the Binding Update. If the correspondent node does not maintain information about the recently used values of that field, then there may be an opportunity for a malicious node to replay old Binding Update messages and fool the correspondent node into routing toward an old care-of address. For this reason, a correspondent node that uses a precomputable Kbm also MUST keep track of the most recent value of the Sequence Number field of Binding Update messages using the precomputable Kbm value (for example, by committing it to stable storage).
事前に設定されたデータから計算されたKBMを使用したバインディングアップデートメッセージのリプレイ保護は、バインディングアップデートのシーケンス番号フィールドの値に依存します。特派員ノードがそのフィールドの最近使用されている値に関する情報を維持していない場合、悪意のあるノードが古いバインディングアップデートメッセージを再生し、特派員ノードを愚かにして、古い住所へのルーティングに機会があるかもしれません。このため、事前に計算可能なKBMを使用する特派員ノードは、事前コンパート可能なKBM値を使用して、バインディングアップデートメッセージのシーケンス番号フィールドの最新値フィールドを追跡する必要があります（たとえば、安定したストレージにコミットすることにより）。
When a Binding Update is to be authenticated using such a precomputable binding key (Kbm), the Binding Authorization Data suboption MUST be present. The Nonce Indices option SHOULD NOT be present. If it is present, the nonce indices supplied SHOULD be ignored and are not included as part of the calculation for the authentication data, which is to be performed exactly as specified in [1].
このような事前計算可能なバインディングキー（KBM）を使用してバインディングアップデートを認証する場合、バインディング認証データサブオプションが存在する必要があります。NONCEインデックスオプションは存在しないでください。存在する場合、提供されるノンセインデックスは無視する必要があり、[1]で指定されたとおりに実行される認証データの計算の一部として含まれていません。
A correspondent node and a mobile node may use a precomputable binding management key (Kbm) to manage the authentication requirements for binding cache management messages. Such keys must be handled carefully to avoid inadvertent exposure to the threats outlined in [5]. Many requirements listed in this document are intended to ensure the safety of the manual configuration. In particular, Kcn MUST be generated with sufficient randomness (see RFC 4086 [3]), as noted in Section 3.
特派員ノードとモバイルノードは、元キャッシュ管理メッセージの認証要件を管理するために、事前計算可能なバインディング管理キー（KBM）を使用する場合があります。このようなキーは、[5]で概説されている脅威への不注意な暴露を避けるために、慎重に処理する必要があります。このドキュメントにリストされている多くの要件は、手動構成の安全性を確保することを目的としています。特に、セクション3に記載されているように、KCNは十分なランダム性で生成する必要があります（RFC 4086 [3]を参照）。
Manually configured keys MUST be used in conformance with RFC 4107 [4]. Used according to the applicability statement, and with the other security measures mandated in this specification, the keys will satisfy the properties in that document. In order to ensure protection against dictionary attacks, the configured security information is intended to be used ONLY for authenticating Binding Update messages.
手動で構成されたキーは、RFC 4107に準拠して使用する必要があります[4]。アプリケーションステートメントに従って使用され、この仕様で義務付けられている他のセキュリティ対策により、キーはそのドキュメントのプロパティを満たします。辞書攻撃に対する保護を確保するために、構成されたセキュリティ情報は、バインディングアップデートメッセージの認証にのみ使用することを目的としています。
A mobile node MUST use a different value for Kcn for each node in its Binding Update List, and a correspondent node MUST ensure that every mobile node uses a different value of Kcn. This ensures that the sender of a Binding Update can always be uniquely determined. This is necessary, as this authorization method does not provide any guarantee that the given care-of address is legitimate. For the same reason, this method SHOULD only be applied between nodes that are under the same administration. The return routability procedure is RECOMMENDED for all general use and MUST be the default, unless the user explicitly overrides this by entering the aforementioned preconfigured data for a particular peer.
モバイルノードは、バインディングアップデートリストの各ノードに対してKCNに対して異なる値を使用する必要があり、特派員ノードはすべてのモバイルノードがKCNの異なる値を使用することを確認する必要があります。これにより、バインディングアップデートの送信者が常に一意に決定されることが保証されます。この承認方法は、与えられた住所が合法であるという保証を提供しないため、これが必要です。同じ理由で、この方法は、同じ管理下にあるノード間でのみ適用する必要があります。すべての一般的な使用には返品ルー上の手順が推奨され、特定のピアの前述の事前設定データを入力することにより、ユーザーがこれを明示的にオーバーライドしない限り、デフォルトでなければなりません。
Replay protection for the Binding Authorization Data option authentication mechanism is provided by the Sequence Number field of the Binding Update. This method of providing replay protection fails when the Binding Update sequence numbers cycle through the 16 bit counter (i.e., not more than 65,536 distinct uses of Kbm), or if the sequence numbers are not protected against reboots. If the mobile node were to send a fresh Binding Update to its correspondent node every hour, 24 hours a day, every day of the year, this would require changing keys every 7 years. Even if the mobile node were to do so every minute, this would provide protection for over a month. Given typical mobility patterns, there is little danger of replay problems; nodes for which problems might arise are expected to use methods other than manual configuration for Kcn and the associated nonces. When the Sequence Number field rolls over, the parties SHOULD configure a new value for Kcn, so that new Kbm values will be computed.
バインディング認証データのリプレイ保護オプション認証メカニズムは、バインディングアップデートのシーケンス番号フィールドによって提供されます。リプレイ保護を提供するこの方法は、バインディングアップデートシーケンス番号が16ビットカウンター（つまり、KBMの65,536個以下の使用）を介してサイクリングする場合、またはシーケンス番号が再起動に対して保護されていない場合に失敗します。モバイルノードが、1年ごとに1日24時間、毎日1時間ごとに新たなバインディングアップデートを特派員ノードに送信する場合、7年ごとにキーを変更する必要があります。モバイルノードが毎分そうしていたとしても、これは1か月以上の保護を提供します。典型的なモビリティパターンを考えると、リプレイの問題の危険はほとんどありません。問題が発生する可能性のあるノードは、KCNおよび関連するNonceの手動構成以外の方法を使用することが期待されます。シーケンス番号フィールドがロールオーバーすると、当事者はKCNの新しい値を構成して、新しいKBM値が計算されるようにする必要があります。
If a correspondent node does NOT keep track of the sequence number for Binding Update messages from a particular mobile node, then the correspondent node could be fooled into accepting an old value for the mobile node's care-of address. In the unlikely event that this address was reallocated to another IPv6 node in the meantime, that IPv6 node would then be vulnerable to unwanted traffic emanating from the correspondent node.
特派員ノードが特定のモバイルノードからのバインディングアップデートメッセージのシーケンス番号を追跡しない場合、特派員ノードは、モバイルノードのケアオブアドレスの古い値を受け入れるようにだまされる可能性があります。このアドレスがその間に別のIPv6ノードに再割り当てされた可能性が低い場合、そのIPv6ノードは、特派員ノードから発生する不要なトラフィックに対して脆弱になります。
Note that where a node has been configured to use the mechanism specified in this document with a particular peer, it SHOULD NOT attempt to use another mechanism, even if the peer requests this or claims not to support the mechanism in this document. This is necessary in order to prevent bidding down attacks.
特定のピアでこのドキュメントで指定されたメカニズムを使用するようにノードが構成されている場合、ピアがこれを要求したり、このドキュメントのメカニズムをサポートしないと主張している場合でも、別のメカニズムを使用しようとはしないでください。これは、入札攻撃を防ぐために必要です。
There is no upper bound on the lifetime defined for the precomputable Kbm. As noted, the key is very likely to be quite secure over the lifetime of the security association and usefulness of applications between a mobile node and correspondent node that fit the terms specified in section 2.
事前に計算可能なKBMに対して定義された生涯に上限はありません。前述のように、キーは、セキュリティ協会の寿命と、セクション2で指定された用語に適合するモバイルノードと特派員ノードの間のアプリケーションの有用性にわたって非常に安全である可能性が非常に高いです。
Thanks are due to everyone who reviewed the discussion of issue #146. Thanks to Jari Arkko for supplying text for the Introduction.
問題＃146の議論をレビューしたすべての人に感謝します。紹介のためにテキストを提供してくれたJari Arkkoに感謝します。
[1] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004.
[1] Johnson、D.、Perkins、C。、およびJ. Arkko、「IPv6のモビリティサポート」、RFC 3775、2004年6月。
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[2] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[3] Eastlake, D., 3rd, Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, June 2005.
[3] Eastlake、D.、3rd、Schiller、J。、およびS. Crocker、「セキュリティのランダム性要件」、BCP 106、RFC 4086、2005年6月。
[4] Bellovin, S. and R. Housley, "Guidelines for Cryptographic Key Management", BCP 107, RFC 4107, June 2005.
[4] Bellovin、S。およびR. Housley、「暗号化キー管理のためのガイドライン」、BCP 107、RFC 4107、2005年6月。
[5] Nikander, P., Arkko, J., Aura, T., Montenegro, G., and E. Nordmark, "Mobile IP Version 6 Route Optimization Security Design Background", RFC 4226, December 2005.
[5] Nikander、P.、Arkko、J.、Aura、T.、Montenegro、G。、およびE. Nordmark、「モバイルIPバージョン6ルート最適化セキュリティデザイン背景」、RFC 4226、2005年12月。
Author's Address
著者の連絡先
Charles E. Perkins Nokia Research Center 313 Fairchild Drive Mountain View, CA 94043 USA
チャールズE.パーキンスノキアリサーチセンター313フェアチャイルドドライブマウンテンビュー、カリフォルニア94043 USA
Phone: +1 650 625-2986
Fax: +1 650 625-2502
EMail: charles.perkins@nokia.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2006).
Copyright（c）The Internet Society（2006）。
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 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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
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への情報をお問い合わせください。
Acknowledgement
謝辞
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFCエディター機能の資金は、IETF管理サポートアクティビティ（IASA）によって提供されます。