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).
著作権（C）インターネット協会（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].
キーワード "MUST"、 "MUST NOT"、 "REQUIRED" は、 "NOT SHALL" "ものと" この文書では、 "SHOULD"、 "推奨" "NOT SHOULD"、 "MAY"、 "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].
- コレスポンデント・ノードは、移動ノードの行動を信頼する十分な理由を持っています。具体的には、通信相手ノードは、[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.
一般的に言って、コレスポンデントノードは、移動ノードとprecomputableた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
- 共有鍵（Kcnを）は、少なくとも20オクテット長、鍵生成トークンを生成するために使用
- A nonce for use when generating the care-of keygen token
- ケア - の生成トークンを生成するために使用ナンス
- A nonce for use when generating the home keygen token
- ホーム鍵生成トークンを生成するために使用ナンス
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]).
モバイルIPv6 [1]リターン・ルータビリティに指定されている鍵生成トークンはKcnをおよびナンスから生成されなければなりません。同様に、モバイルIPv6で指定されたKbmは、その後同様に鍵生成トークンから生成されなければならないバインディング管理キー[1]。事前設定されたデータは、モバイルノードのホームアドレスに関連付けられています。 KCNは（[3] RFC 4086を参照）に十分なランダムで生成しなければなりません。
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を使用して更新メッセージを結合するためのリプレイ保護は、バインディングアップデートでシーケンス番号フィールドの値に依存します。コレスポンデントノードは、そのフィールドの最近使用した値に関する情報を保持しない場合は、古い結合更新メッセージを再生し、旧気付けアドレスへのルーティングに対応するノードをだますために、悪意のあるノードのための機会があるかもしれません。このため、precomputableたKbmを使用して、通信相手ノードは、（例えば、安定したストレージにそれをコミットすることによって）precomputableたKbmの値を使用してBinding Updateメッセージのシーケンス番号フィールドの最新の値を追跡する必要があります。
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].
結合更新は、precomputable結合鍵（Kbmを）を使用して認証する場合、結合認証データサブオプションが存在しなければなりません。ナンスインデックスオプションが存在してはなりません。それが存在する場合には、供給されたナンス指数は無視されるべきであり、[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.
コレスポンデントノードとモバイルノードは、キャッシュ管理メッセージを結合するための認証要件を管理するためにprecomputableバインディング管理キー（Kbmを）を使用することができます。このようなキーは[5]で概説した脅威への不注意による露出を避けるために、慎重に扱わなければなりません。この文書に記載されている多くの要件は、手動設定の安全性を確保することを意図しています。特に、Kcnを、セクション3で述べたように、（[3] RFC 4086を参照）に十分なランダムで生成しなければなりません。
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日24時間、年の毎日を新鮮なバインディングアップデートを送信した場合、これは7年ごとのキーを変更することが必要となります。モバイルノードがとても分ごとに行うことをしたとしても、これは月以上の保護を提供するであろう。典型的な移動パターンを考えると、リプレイの問題のほとんどない危険性があります。問題が発生する可能性のためにノードがKcnをと関連する一回だけのために手動で設定以外の方法を使用することが期待されます。シーケンス番号フィールドは、ロールオーバーすると、新たなKbmを値が計算されるように、当事者は、Kcnをの新しい値を設定する必要があります。
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.
コレスポンデントノードは、特定の移動ノードからBinding Updateメッセージのシーケンス番号を追跡していない場合、コレスポンデントノードは、モバイルノードの気付アドレスの古い値を受け入れるにだまさすることができます。このアドレスは、その間に他の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.
precomputableた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の議論を見直し皆のためです。導入のためのテキストを供給するためのヤリArkkoに感謝します。
[1] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004.
[1]ジョンソン、D.、パーキンス、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]ブラドナーのは、S.は、BCP 14、RFC 2119、1997年3月の "RFCsにおける使用のためのレベルを示すために"。
[3] Eastlake, D., 3rd, Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, June 2005.
[3]イーストレーク、D.、3、シラー、J.、およびS.クロッカー、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.、オーラ、T.、モンテネグロ、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フェアチャイルドドライブマウンテンビュー、CA 94043 USA
Phone: +1 650 625-2986 Fax: +1 650 625-2502 EMail: charles.perkins@nokia.com
電話：+1 650 625-2986ファックス：+1 650 625-2502 Eメール：charles.perkins@nokia.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2006).
著作権（C）インターネット協会（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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
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に情報を記述してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFCエディタ機能のための資金は、IETF管理サポート活動（IASA）によって提供されます。