Network Working Group S. Bellovin
Request for Comments: 4808 Columbia University
Category: Informational March 2007
Key Change Strategies for TCP-MD5
Status of This Memo
このメモのステータス
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。それはどんな種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The IETF Trust (2007).
著作権（C）IETFトラスト（2007）。
Abstract
抽象
The TCP-MD5 option is most commonly used to secure BGP sessions between routers. However, changing the long-term key is difficult, since the change needs to be synchronized between different organizations. We describe single-ended strategies that will permit (mostly) unsynchronized key changes.
TCP-MD5オプションは、最も一般的にルータ間のBGPセッションを固定するために使用されます。変更は、異なる組織間で同期する必要があるためしかし、長期的なキーを変更することは、困難です。我々は（主に）非同期のキーの変更を可能にするシングルエンドの戦略について説明します。
The TCP-MD5 option [RFC2385] is most commonly used to secure BGP sessions between routers. However, changing the long-term key is difficult, since the change needs to be synchronized between different organizations. Worse yet, if the keys are out of sync, it may break the connection between the two routers, rendering repair attempts difficult.
TCP-MD5オプション[RFC2385]は、最も一般的にルータ間のBGPセッションを固定するために使用されます。変更は、異なる組織間で同期する必要があるためしかし、長期的なキーを変更することは、困難です。キーが同期していた場合にさらに悪いことに、それは難しい修理の試みをレンダリングする、2つのルータ間の接続を壊すことがあります。
The proper solution involves some sort of key management protocol. Apart from the complexity of such things, RFC 2385 was not written with key changes in mind. In particular, there is no KeyID field in the option, which means that even a key management protocol would run into the same problem.
適切な解決策は、鍵管理プロトコルのいくつかの並べ替えを必要とします。別にこのようなことの複雑さから、RFC 2385には、心の中で重要な変化に書かれていませんでした。具体的には、何の鍵IDフィールドにも鍵管理プロトコルは、同じ問題に遭遇することを意味し、オプションではありません。
Fortunately, a heuristic permits key change despite this protocol deficiency. The change can be installed unilaterally at one end of a connection; it is fully compatible with the existing protocol.
幸いなことに、ヒューリスティックは、このプロトコルの欠乏にもかかわらず、キーの変更が可能になります。変化は、接続の一端に一方的に設置することができます。それは既存のプロトコルとの完全な互換性があります。
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 [RFC2119].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[RFC2119]に記載されているように解釈されます。
Separate algorithms are necessary for transmission and reception. Reception is easier; we explain it first.
別のアルゴリズムは、送信および受信のために必要です。フロントは簡単です。まずそれを説明します。
A receiver has a list of valid keys. Each key has a (conceptual) timestamp associated with it. When a segment arrives, each key is tried in turn. The segment is discarded if and only if it cannot be validated by any key in the list.
受信機は、有効なキーのリストを持っています。各キーは、それに関連する（概念的な）タイムスタンプを有しています。セグメントが到着すると、各キーが順番に試されています。セグメントがあれば破棄され、それは、リスト内の任意のキーで検証することができない場合にのみ。
In principle, there is no need to test keys in any particular order. For performance reasons, though, a simple most-recently-used (MRU) strategy -- try the last valid key first -- should work well. More complex mechanisms, such as examining the TCP sequence number of an arriving segment to see whether it fits in a hole, are almost certainly unnecessary. On the other hand, validating that a received segment is putatively legal, by checking its sequence number against the advertised window, can help avoid denial of service attacks.
原則として、任意の特定の順序でキーをテストする必要はありません。パフォーマンス上の理由から、しかし、簡単な最も最近使用（MRU）の戦略 - 最初の最後の有効なキーを試してみてください - うまくいくはずです。そのようなことが穴に収まるかどうかを確認するために到着したセグメントのTCPシーケンス番号を調べるなど、より複雑なメカニズムは、ほぼ確実に不必要です。一方、受信したセグメントは、法的推定的であることを検証し、広告ウィンドウに対してそのシーケンス番号を確認することで、サービス拒否（DoS）攻撃を避けるのを助けることができます。
The newest key that has successfully validated a segment is marked as the "preferred" key; see below.
正常セグメントを検証した最新の鍵が「好ましい」キーとしてマークされています。下記参照。
Implicit in this scheme is the assumption that older keys will eventually be unneeded and can be removed. Accordingly, implementations SHOULD provide an indication of when a key was last used successfully.
この方式では暗黙の古いキーは最終的に不要になり、取り外すことができるという仮定があります。したがって、実装は鍵が最後に正しく使用した場合の指示を提供すべきです。
Transmission is more complex, because the sender does not know which keys can be accepted at the far end. Accordingly, the conservative strategy is to delay using any new keys for a considerable amount of time, probably measured in days. This time interval is the amount of asynchronicity the parties wish to permit; it is agreed upon out of band and configured manually.
送信者が遠端で受け入れが可能なキーを知っていないため、送信は、より複雑です。したがって、保守的な戦略は、おそらく日に測定された、かなりの時間のために、新しいキーを使用して遅延させることです。この時間間隔は、当事者が許可したい非同期の量です。それはバンドのうちに合意し、手動で設定されています。
Some automation is possible, however. If a key has been used successfully to validate an incoming segment, clearly the other side knows it. Accordingly, any key marked as "preferred" by the receiving part of a stack SHOULD be used for transmissions.
いくつかの自動化は、しかし、可能です。鍵が入ってくるセグメントを検証するために首尾よく使用されている場合は、はっきりと反対側はそれを知っています。したがって、スタックの受信部で「好ましい」としてマークされた任意のキーを送信するために使用されるべきです。
A sophisticated implementation could try alternate keys if the TCP retransmission counter gets too high. (This is analogous to dead gateway detection.) In particular, if a key change has just been attempted but such segments are not acknowledged, it is reasonable to fall back to the previous key and issue an alert of some sort. Similarly, an implementation with a new but unused key could occasionally try to use it, much in the way that TCP implementations probe closed windows. Doing this avoids the "silent host" problem discussed in Section 3.1. This should be done at a moderately slow rate.
TCPの再送カウンタが高すぎる場合には、洗練された実装では、代替キーを試みることができます。キーの変更がちょうど試みられているが、このようなセグメントが確認されていない場合（これが死んでゲートウェイの検出に類似しています。）特に、戻って、以前のキーに落ち、ある種の警告を発行することが合理的です。同様に、新しいなく、未使用のキーを持つ実装は時折ずっとTCP実装プローブは、ウィンドウを閉じたような方法で、それを使用しようとすることができます。これを行うと、3.1節で述べた「サイレントホスト」の問題を回避します。これは、適度に遅い速度で行われる必要があります。
Note that there is an ambiguity when an acknowledgment is received for a segment transmitted with two different keys. The TCP Timestamp option [RFC1323] can be used for disambiguation.
肯定応答は、2つの異なる鍵を用いて送信されたセグメントのために受信された曖昧さがあることに留意されたいです。 TCPタイムスタンプオプション[RFC1323]は曖昧さ回避のために使用することができます。
Suppose only one end of the connection has this algorithm implemented. The new key is provisioned on that system, with a start time far in the future -- sufficiently far, in fact, that it will not be used spontaneously. After the key is ready, the other end is notified, out-of-band, that a key change can commence.
このアルゴリズムは実施しており、接続の一端のみを仮定します。新しいキーが遠い将来の開始時間と、そのシステム上でプロビジョニングされた - 十分に離れ、実際には、それが自然発生的に使用されないこと。キーの準備ができた後、もう一方の端は、キーの変更が開始できることを、アウト・オブ・バンド、通知されます。
At some point, the other end is upgraded. Because it does not have multiple keys available, it will start using the new key immediately for its transmission, and will drop all segments that use the old key. As soon as it tries to transmit, the upgraded side will designate the new key as preferred, and will use it for all of its transmissions. Note specifically that this will include retransmissions of any segments rejected because they used the old key.
いくつかの点で、他の端がアップグレードされます。それが可能な複数のキーを持っていないので、それはすぐにその伝送のための新しいキーを使用して開始し、古いキーを使用するすべてのセグメントをドロップします。すぐにそれが送信しようとすると、アップグレードされた側が、好ましいものとして新しいキーを指定し、その送信のすべてのためにそれを使用します。これは、彼らは古いキーを使用しているため拒否任意のセグメントの再送信が含まれることに特に注意してください。
There is a problem if the unchanged machine is a "silent host" -- a host that has nothing to say, and hence does not transmit. The best way to avoid this is for an upgraded machine to try a variety of keys in the event of repeated unacknowledged packets, and to probe for new unused keys during silent periods, as discussed in Section 2.2. Alternatively, application-level KeepAlive messages may be used to ensure that neither end of the connection is completely silent. See, for example, Section 4.4 of [RFC4271] or Section 3.5.4 of [RFC3036].
何も言うことがない、ので、送信しないホスト - 変わらないマシンが「サイレントホスト」である場合に問題があります。アップグレードされたマシンが繰り返される未確認パケットの場合には、キーの多様性を試してみて、2.2節で述べたように、無音期間中に新しい未使用のキーのためにプローブするためにこれを回避する最善の方法です。あるいは、アプリケーション・レベルのキープアライブメッセージは、接続のどちらの端部が完全に沈黙していることを確実にするために使用されてもよいです。例えば、[RFC4271]のセクション4.4 [RFC3036]のセクション3.5.4を参照。
Double-ended operations are similar, save that both sides deploy the new key at about the same time. One should be configured to start using the new key at a point where it is reasonably certain that the other side would have it installed, too. Assuming that has in fact happened, the new key will be marked "preferred" on both sides.
ダブルエンドの操作は、両側がほぼ同時に新しいキーを展開することを保存し、類似しています。一つは、あまりにも、他の側は、それがインストールされているであろうと合理的に一定である地点で新しいキーを使用して起動するように設定する必要があります。それは実際には新しいキーが両側に「望ましい」とマークされますが、起こっていると仮定。
As noted, implementations should monitor when a key was last used for transmission or reception. Any monitoring mechanism can be used; most likely, it will be one or both of a MIB object or objects and the vendor's usual command-line mechanism for displaying data of this type. Regardless, the network operations center should keep track of this. When a new key has been used successfully for both transmission and reception for a reasonable amount of time -- the exact value isn't crucial, but it should probably be longer than twice the maximum segment lifetime -- the old key can be marked for deletion. There is an implicit assumption here that there will not be substantial overlap in the usage period of such keys; monitoring systems should look for any such anomalies, of course.
述べたようにキーを送信または受信するために最後に使用した場合、実装は、監視すべきです。任意の監視機構を使用することができます。最も可能性が高い、それはMIBオブジェクトまたはオブジェクトと、このタイプのデータを表示するためのベンダーの通常のコマンドライン機構の一方または両方になります。かかわらず、ネットワークオペレーションセンターは、このを追跡する必要があります。新しいキーが妥当な時間のために、送信と受信の両方のために首尾よく使用されている場合は - 正確な値は重要ではないですが、それはおそらく二回最大セグメント寿命よりも長くする必要があります - 古い鍵がためにマークすることができます削除。そのようなキーの使用期間中にかなりの重複がないこと、ここで暗黙の前提があります。監視システムは当然のことながら、そのような異常を探してください。
As implied in Section 1, this is an interim strategy, intended to make TCP-MD5 operationally usable today. We do not suggest or recommend it as a long-term solution. In this section, we make some suggestions about the design of a future TCP authentication option.
第1節で示唆されるように、これは今日のTCP-MD5は、運用上使用可能にすることを目的と暫定的な戦略です。私たちは、提案や長期的なソリューションとして、それをお勧めしません。このセクションでは、我々は将来のTCP認証オプションの設計に関するいくつかの提案を行います。
The first and most obvious change is to replace keyed MD5 with a stronger MAC [RFC4278]. Today, HMAC-SHA1 [RFC4634] is the preferred choice, though others such as UMAC [RFC4418] should be considered as well.
最初の、そして最も明らかな変化は、より強力なMAC [RFC4278]でキー付きMD5を交換することです。そのようなUMAC [RFC4418]などの他は同様に考慮されるべきであるけれども、今日、HMAC-SHA1 [RFC4634]は、好ましい選択肢です。
A new authentication option should contain some form of a Key ID field. Such an option would permit unambiguous identification of which key was used to create the MAC for a given segment, sparing the receiver the need to engage in the sort of heuristics described here. A Key ID is useful with both manual and automatic key management. (Note carefully that we do not prescribe any particular Key ID mechanism here. Rather, we are stating a requirement: there must be a simple, low-cost way to select a particular key, and it must be possible to rekey without tearing down long-lived connections.)
新しい認証オプションは、キーIDフィールドのいくつかのフォームを含める必要があります。そのようなオプションは、キーを受信機にここで説明ヒューリスティックのソートに従事する必要性を温存、所与のセグメントのためのMACを作成するために使用したの明確な同定を可能にします。キーIDは、手動と自動の鍵管理の両方で有用です。 。特定のキーを選択するための簡単、低コストの方法がなければならない、そして長いを切断せずにキー更新することは可能である必要があります（ここでは、特定のキーIDメカニズムを規定していないということではなく、我々は要件を述べている慎重に注意してください-lived接続。）
Finally, an automated key management mechanism should be defined. The general reasoning for that is set forth in [RFC4107]; specific issues pertaining to BGP and TCP are given in [RFC3562].
最後に、自動化された鍵管理メカニズムを定義する必要があります。そのための一般的な理由は、[RFC4107]に記載されています。 BGPおよびTCPに関連する特定の問題は、[RFC3562]に記載されています。
In theory, accepting multiple keys simultaneously makes life easier for an attacker. In practice, if the recommendations in [RFC3562] are followed, this should not be a problem.
理論的には、同時に複数のキーを受け入れることは、攻撃者のための生活が容易になります。 [RFC3562]の推奨事項に従っている場合は実際には、これが問題になることはありません。
New keys must be communicated securely. Specifically, new key messages must be kept confidential and must be properly authenticated.
新しい鍵は安全に通信する必要があります。具体的には、新しいキーメッセージは、機密保持する必要があり、適切に認証される必要があります。
Having multiple keys makes CPU denial-of-service attacks easier. This suggests that keeping the overlap period reasonably short is a good idea. In addition, the Generalized TTL Security Mechanism [RFC3682], if applicable to the local topology, can help. Note that most of the time, only one key will exist; virtually all of the remaining time there will be only two keys in existence.
複数のキーを持つことは、CPU、サービス拒否攻撃が容易になります。これは、適度に短いオーバーラップ期間を維持することは良い考えであることを示唆しています。また、一般TTLセキュリティメカニズム[RFC3682]、ローカルトポロジーに該当する場合は、助けることができます。ほとんどの時間は、1つのキーだけが存在することに注意してください。事実上すべての残りの時間の有無で2つだけのキーが存在します。
There are no IANA actions required. The TCP-MD5 option number is defined in [RFC2385], and is currently listed by IANA.
必要な一切IANAのアクションはありません。 TCP-MD5オプション番号は[RFC2385]で定義され、現在IANAによって記載されています。
I'd like to thank Ron Bonica, Randy Bush, Ross Callon, Rob Evans, Eric Rescorla, and Sam Weiler for their comments and inspiration.
私は彼らのコメントとインスピレーションのためにロンBonica、ランディブッシュ、ロスCallon、ロブ・エヴァンス、エリックレスコラ、およびサム・ワイラーに感謝したいと思います。
[RFC1323] Jacobson, V., Braden, B., and D. Borman, "TCP Extensions for High Performance", RFC 1323, May 1992.
[RFC1323]ジェーコブソン、V.、ブレーデン、B.、およびD.ボーマン、 "ハイパフォーマンスのためのTCP拡張"、RFC 1323、1992年5月。
[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月。
[RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 Signature Option", RFC 2385, August 1998.
[RFC2385] Heffernanの、A.、 "TCP MD5署名オプションを使用してBGPセッションの保護"、RFC 2385、1998年8月。
[RFC3036] Andersson, L., Doolan, P., Feldman, N., Fredette, A., and B. Thomas, "LDP Specification", RFC 3036, January 2001.
[RFC3036]アンデション、L.、Doolan、P.、フェルドマン、N.、Fredette、A.、およびB.トーマス、 "LDP仕様"、RFC 3036、2001年1月。
[RFC3562] Leech, M., "Key Management Considerations for the TCP MD5 Signature Option", RFC 3562, July 2003.
[RFC3562]リーチ、M.、 "TCP MD5署名オプションのためのキー管理の考慮事項"、RFC 3562、2003年7月。
[RFC3682] Gill, V., Heasley, J., and D. Meyer, "The Generalized TTL Security Mechanism (GTSM)", RFC 3682, February 2004.
[RFC3682]ギル、V.、Heasley、J.、およびD.マイヤー、 "一般TTLセキュリティメカニズム（GTSM）"、RFC 3682、2004年2月。
[RFC4107] Bellovin, S. and R. Housley, "Guidelines for Cryptographic Key Management", BCP 107, RFC 4107, June 2005.
[RFC4107] Bellovin氏、S.とR. Housley氏、 "暗号鍵管理のためのガイドライン"、BCP 107、RFC 4107、2005年6月。
[RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, January 2006.
[RFC4271] Rekhter、Y.、李、T.、およびS.野兎、 "ボーダーゲートウェイプロトコル4（BGP-4）"、RFC 4271、2006年1月。
[RFC4278] Bellovin, S. and A. Zinin, "Standards Maturity Variance Regarding the TCP MD5 Signature Option (RFC 2385) and the BGP-4 Specification", RFC 4278, January 2006.
[RFC4278] Bellovin氏、S.およびA.ジニン、 "TCP MD5署名オプション（RFC 2385）およびBGP-4仕様に関して標準成熟差異"、RFC 4278、2006年1月。
[RFC4418] Krovetz, T., "UMAC: Message Authentication Code using Universal Hashing", RFC 4418, March 2006.
[RFC4418] Krovetz、T.、 "UMAC：ユニバーサルハッシュを使用してメッセージ認証コード"、RFC 4418、2006年3月。
[RFC4634] Eastlake, D. and T. Hansen, "US Secure Hash Algorithms (SHA and HMAC-SHA)", RFC 4634, August 2006.
[RFC4634]イーストレイク、D.とT.ハンセンは、RFC 4634、2006年8月、 "米国は、ハッシュアルゴリズム（SHAとHMAC-SHA）を固定します"。
Author's Address
著者のアドレス
Steven M. Bellovin Columbia University 1214 Amsterdam Avenue MC 0401 New York, NY 10027 US
スティーブンM. Bellovin氏コロンビア大学1214アムステルダムアベニューMC 0401ニューヨーク、NY 10027米国
Phone: +1 212 939 7149 EMail: bellovin@acm.org
電話：+1 212 939 7149 Eメール：bellovin@acm.org
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2007).
著作権（C）IETFトラスト（2007）。
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に情報を記述してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。