[要約] RFC 4808は、TCP-MD5のキー変更戦略に関するガイドラインであり、TCP-MD5セッションのセキュリティを向上させるための方法を提供しています。目的は、TCP-MD5のキーの変更を効果的かつ安全に行うための手順を提供することです。
Network Working Group S. Bellovin
Request for Comments: 4808 Columbia University
Category: Informational March 2007
Key Change Strategies for TCP-MD5
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）The IETF Trust（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は念頭にある重要な変更で書かれていませんでした。特に、オプションにはKeyIDフィールドはありません。つまり、重要な管理プロトコルでさえ同じ問題に陥ることがあります。
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].
「必須」、「そうしない」、「必須」、「shall」、「shall "、" ingle "、" should "、" not "、" becommended "、" bay "、および「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シーケンス番号を調べて穴に収まるかどうかを確認するなど、より複雑なメカニズムは、ほぼ間違いなく不要です。一方、宣伝されたウィンドウに対してシーケンス番号をチェックすることにより、受信したセグメントが推定的に合法であることを検証することは、サービス拒否攻撃を回避するのに役立ちます。
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再送信カウンターが高すぎる場合、代替キーを試すことができます。（これは、Dead Gatewayの検出に類似しています。）特に、重要な変更が試みられたばかりであるが、そのようなセグメントが認められていない場合、以前のキーに戻り、何らかのアラートを発行することは合理的です。同様に、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で説明したように、サイレント期間中に新しい未使用のキーをプローブすることです。あるいは、アプリケーションレベルのKeepAliveメッセージを使用して、接続のどちらの終わりも完全に沈黙していないことを保証することができます。たとえば、[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オブジェクトまたはオブジェクトの1つまたは両方と、このタイプのデータを表示するためのベンダーの通常のコマンドラインメカニズムです。とにかく、ネットワークオペレーションセンターはこれを追跡する必要があります。妥当な時間の間、伝送と受信の両方に新しいキーが正常に使用されている場合 - 正確な値は重要ではありませんが、おそらく最大セグメントの寿命の2倍よりも長くなるはずです - 古いキーは消す。ここでは、そのようなキーの使用期間に実質的な重複がないという暗黙の仮定があります。もちろん、監視システムはそのような異常を探す必要があります。
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.
最初で最も明らかな変更は、キー付きMD5をより強力なMAC [RFC4278]に置き換えることです。今日、HMAC-SHA1 [RFC4634]が好ましい選択ですが、UMAC [RFC4418]などの他のものも考慮する必要があります。
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メカニズムを規定していないことに注意してください。むしろ、要件を述べています。特定のキーを選択するための簡単で低コストの方法が必要であり、長い間破壊せずに再キーを再キーすることができる必要があります。 - ライブ接続。）
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.
ロン・ボニカ、ランディ・ブッシュ、ロス・カロン、ロブ・エヴァンス、エリック・レスコルラ、サム・ワイラーのコメントとインスピレーションに感謝したいと思います。
[RFC1323] Jacobson, V., Braden, B., and D. Borman, "TCP Extensions for High Performance", RFC 1323, May 1992.
[RFC1323] Jacobson、V.、Braden、B。、およびD. Borman、「TCP拡張のための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] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、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] Andersson、L.、Doolan、P.、Feldman、N.、Fredette、A。、およびB. Thomas、「LDP仕様」、RFC 3036、2001年1月。
[RFC3562] Leech, M., "Key Management Considerations for the TCP MD5 Signature Option", RFC 3562, July 2003.
[RFC3562] Leech、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] Gill、V.、Heasley、J。、およびD. Meyer、「一般化された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.、Li、T。、およびS. Hares、「A Border Gateway Protocol 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. Zinin、「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：Universal Hashingを使用したメッセージ認証コード」、RFC 4418、2006年3月。
[RFC4634] Eastlake, D. and T. Hansen, "US Secure Hash Algorithms (SHA and HMAC-SHA)", RFC 4634, August 2006.
[RFC4634] Eastlake、D。およびT. Hansen、「US Secure Hash Algorithms（SHA and HMAC-SHA）」、RFC 4634、2006年8月。
Author's Address
著者の連絡先
Steven M. Bellovin Columbia University 1214 Amsterdam Avenue MC 0401 New York, NY 10027 US
スティーブンM.ベロビンコロンビア大学1214アムステルダムアベニューMC 0401ニューヨーク、ニューヨーク10027 US
Phone: +1 212 939 7149
EMail: bellovin@acm.org
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2007).
著作権（c）The IETF Trust（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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供され、貢献者、彼/彼女が代表する組織（もしあれば）、インターネット協会、IETFトラスト、インターネットエンジニアリングタスクフォースがすべてを否認します。明示的または黙示的な保証。ここでの情報の使用は、特定の目的に対する商品性または適合性の権利または暗黙の保証を侵害しないという保証を含むがこれらに限定されない。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、本書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスに基づくライセンスの範囲に関連すると主張される可能性のある他の権利に関しては、立場を取得しません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要なテクノロジーをカバーする可能性のあるその他の独自の権利を注意深く招待します。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。