[要約] RFC 3567は、IS-ISプロトコルにおける暗号認証の仕組みを提供する。目的は、ネットワークのセキュリティを向上させ、不正なアクセスや攻撃から保護することである。
Network Working Group T. Li
Request for Comments: 3567 Procket Networks
Category: Informational R. Atkinson
Extreme Networks
July 2003
Intermediate System to Intermediate System (IS-IS) Cryptographic Authentication
Intermediate System to Intermediate System（IS-IS）暗号化認証
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 Internet Society (2003). All Rights Reserved.
Copyright（C）The Internet Society（2003）。全著作権所有。
Abstract
概要
This document describes the authentication of Intermediate System to Intermediate System (IS-IS) Protocol Data Units (PDUs) using the Hashed Message Authentication Codes - Message Digest 5 (HMAC-MD5) algorithm as found in RFC 2104. IS-IS is specified in International Standards Organization (ISO) 10589, with extensions to support Internet Protocol version 4 (IPv4) described in RFC 1195. The base specification includes an authentication mechanism that allows for multiple authentication algorithms. The base specification only specifies the algorithm for cleartext passwords.
このドキュメントでは、RFC 2104にあるハッシュメッセージ認証コード-メッセージダイジェスト5（HMAC-MD5）アルゴリズムを使用した中間システムから中間システム（IS-IS）プロトコルデータユニット（PDU）の認証について説明します。IS-ISは、 RFC 1195で説明されているインターネットプロトコルバージョン4（IPv4）をサポートする拡張機能を備えた国際標準化機構（ISO）10589。基本仕様には、複数の認証アルゴリズムを可能にする認証メカニズムが含まれています。基本仕様では、平文パスワードのアルゴリズムのみを指定しています。
This document proposes an extension to that specification that allows the use of the HMAC-MD5 authentication algorithm to be used in conjunction with the existing authentication mechanisms.
このドキュメントは、HMAC-MD5認証アルゴリズムを既存の認証メカニズムと組み合わせて使用できるようにする、その仕様への拡張を提案しています。
The IS-IS protocol, as specified in ISO 10589 [1], provides for the authentication of Link State PDUs (LSPs) through the inclusion of authentication information as part of the LSP. This authentication information is encoded as a Type-Length-Value (TLV) tuple. The use of IS-IS for IPv4 networks is described in [3].
ISO 10589 [1]で指定されているIS-ISプロトコルは、LSPの一部として認証情報を含めることにより、リンクステートPDU（LSP）の認証を提供します。この認証情報はType-Length-Value（TLV）タプルとしてエンコードされます。 IPv4ネットワークでのIS-ISの使用については、[3]で説明されています。
The type of the TLV is specified as 10. The length of the TLV is variable. The value of the TLV depends on the authentication algorithm and related secrets being used. The first octet of the value is used to specify the authentication type. Type 0 is reserved, type 1 indicates a cleartext password, and type 255 is used for routing domain private authentication methods. The remainder of the TLV value is known as the Authentication Value.
TLVのタイプは10として指定されます。TLVの長さは可変です。 TLVの値は、使用されている認証アルゴリズムと関連するシークレットによって異なります。値の最初のオクテットは、認証タイプを指定するために使用されます。タイプ0は予約されており、タイプ1はクリアテキストのパスワードを示し、タイプ255はルーティングドメインのプライベート認証方法に使用されます。 TLV値の残りの部分は、認証値と呼ばれます。
This document extends the above situation by allocating a new authentication type for HMAC-MD5 and specifying the algorithms for the computation of the Authentication Value. This document also describes modifications to the base protocol to ensure that the authentication mechanisms described in this document are effective.
このドキュメントでは、HMAC-MD5に新しい認証タイプを割り当て、認証値の計算のためのアルゴリズムを指定することにより、上記の状況を拡張しています。このドキュメントでは、このドキュメントで説明されている認証メカニズムが効果的であることを確認するための、ベースプロトコルへの変更についても説明します。
This document is a publication of the IS-IS Working Group within the IETF, and is a contribution to ISO IEC JTC1/SC6, for eventual inclusion with ISO 10589.
このドキュメントは、IETF内のIS-ISワーキンググループの発行物であり、最終的にISO 10589に含まれるためのISO IEC JTC1 / SC6への貢献です。
The authentication type used for HMAC-MD5 is 54 (0x36). The length of the Authentication Value for HMAC-MD5 is 16, and the length field in the TLV is 17.
HMAC-MD5に使用される認証タイプは54（0x36）です。 HMAC-MD5の認証値の長さは16で、TLVの長さフィールドは17です。
The HMAC-MD5 algorithm requires a key K and text T as input [2]. The key K is the password for the PDU type, as specified in ISO 10589. The text T is the IS-IS PDU to be authenticated with the Authentication Value field inside of the Authentication Information TLV set to zero. Note that the Authentication Type is set to 54 and the length of the TLV is set to 17 before authentication is computed. When LSPs are authenticated, the Checksum and Remaining Lifetime fields are set to zero (0) before authentication is computed. The result of the algorithm is placed in the Authentication Value field.
HMAC-MD5アルゴリズムでは、入力としてキーKとテキストTが必要です[2]。キーKは、ISO 10589で指定されているPDUタイプのパスワードです。テキストTは、認証情報TLV内の認証値フィールドをゼロに設定して認証されるIS-IS PDUです。認証が計算される前に、認証タイプが54に設定され、TLVの長さが17に設定されていることに注意してください。 LSPが認証されると、認証が計算される前に、チェックサムフィールドと残りのライフタイムフィールドがゼロ（0）に設定されます。アルゴリズムの結果は、認証値フィールドに配置されます。
When calculating the HMAC-MD5 result for Sequence Number PDUs, Level 1 Sequence Number PDUs SHALL use the Area Authentication string as in Level 1 Link State PDUs. Level 2 Sequence Number PDUs shall use the domain authentication string as in Level 2 Link State PDUs. IS-IS HELLO PDUs SHALL use the Link Level Authentication String, which MAY be different from that of Link State PDUs. The HMAC-MD5 result for the IS-IS HELLO PDUs SHALL be calculated after the Packet is padded to the MTU size, if padding is not disabled. Implementations that support the optional checksum for the Sequence Number PDUs and IS-IS HELLO PDUs MUST NOT include the Checksum TLV.
シーケンス番号PDUのHMAC-MD5結果を計算するとき、レベル1シーケンス番号PDUは、レベル1リンク状態PDUと同様にエリア認証文字列を使用する必要があります（SHALL）。レベル2シーケンス番号PDUは、レベル2リンク状態PDUと同様に、ドメイン認証文字列を使用します。 IS-IS HELLO PDUは、リンクレベルの認証文字列を使用するものとします。これは、リンクステートPDUのものとは異なる場合があります。パディングが無効になっていない場合、IS-IS HELLO PDUのHMAC-MD5結果は、パケットがMTUサイズにパディングされた後に計算される必要があります（SHALL）。シーケンス番号PDUおよびIS-IS HELLO PDUのオプションのチェックサムをサポートする実装には、チェックサムTLVを含めてはなりません（MUST NOT）。
To authenticate an incoming PDU, a system should save the values of the Authentication Value field, the Checksum and the Remaining Lifetime field, set these fields to zero, compute authentication, and then restore the values of these fields.
システムは着信PDUを認証するために、Authentication Valueフィールド、ChecksumおよびRemaining Lifetimeフィールドの値を保存し、これらのフィールドをゼロに設定して認証を計算し、これらのフィールドの値を復元する必要があります。
An implementation that implements HMAC-MD5 authentication and receives HMAC-MD5 Authentication Information MUST discard the PDU if the Authentication Value is incorrect.
HMAC-MD5認証を実装し、HMAC-MD5認証情報を受信する実装は、認証値が正しくない場合、PDUを破棄する必要があります。
An implementation MAY have a transition mode where it includes HMAC-MD5 Authentication Information in PDUs but does not verify the HMAC-MD5 authentication information. This is a transition aid for networks in the process of deploying authentication.
実装は、PDUにHMAC-MD5認証情報を含むが、HMAC-MD5認証情報を検証しない遷移モードを持つ場合があります。これは、認証の展開プロセスにおけるネットワークの移行支援です。
An implementation MAY check a set of passwords when verifying the Authentication Value. This provides a mechanism for incrementally changing passwords in a network.
実装は、認証値を検証するときに一連のパスワードをチェックしてもよい（MAY）。これは、ネットワーク内でパスワードを段階的に変更するためのメカニズムを提供します。
An implementation that does not implement HMAC-MD5 authentication MAY accept a PDU that contains the HMAC-MD5 Authentication Type. ISes (routers) that implement HMAC-MD5 authentication and initiate LSP purges MUST remove the body of the LSP and add the authentication TLV. ISes implementing HMAC-MD5 authentication MUST NOT accept unauthenticated purges. ISes MUST NOT accept purges that contain TLVs other than the authentication TLV. These restrictions are necessary to prevent a hostile system from receiving an LSP, setting the Remaining Lifetime field to zero, and flooding it, thereby initiating a purge without knowing the authentication password.
HMAC-MD5認証を実装しない実装は、HMAC-MD5認証タイプを含むPDUを受け入れることができます。 HMAC-MD5認証を実装してLSPパージを開始するISes（ルーター）は、LSPの本体を削除し、認証TLVを追加する必要があります。 HMAC-MD5認証を実装するISesは、認証されていないパージを受け入れてはなりません（MUST NOT）。 ISesは、認証TLV以外のTLVを含むパージを受け入れてはなりません（MUST NOT）。これらの制限は、悪意のあるシステムがLSPを受信し、[Remaining Lifetime]フィールドをゼロに設定し、フラッディングして、認証パスワードを知らなくてもパージを開始できないようにするために必要です。
There is an implementation issue just after password rollover on an IS-IS router that might benefit from additional commentary. Immediately after password rollover on the router, the router or IS-IS process may restart. If this happens, this causes the LSP Sequence Number restarts from the value 1 using the new password. However, neighbors will reject those new LSPs because the Sequence Number is smaller. The router can not increase its own LSP Sequence Number because it fails to authenticate its own old LSP that neighbors keep sending to it. So the router can not update its LSP Sequence Number to its neighbors until all the neighbors time out all of the original LSPs. One possible solution to this problem is for the IS-IS process to detect if any inbound LSP with an authentication failure has the local System ID and also has a higher Sequence Number than the IS-IS process has. In this event, the IS-IS process SHOULD increase its own LSP Sequence Number accordingly and re-flood the LSPs. However, as this scenario could also be triggered by an active attack by an adversary, it is recommended that a counter also be kept on this case to mitigate the risk from such an active attack.
IS-ISルーターでのパスワードロールオーバーの直後に実装に関する問題があり、追加の説明が役立つ場合があります。ルータでのパスワードロールオーバーの直後に、ルータまたはIS-ISプロセスが再起動する場合があります。これが発生すると、LSPシーケンス番号が新しいパスワードを使用して値1から再起動します。ただし、シーケンス番号が小さいため、ネイバーはこれらの新しいLSPを拒否します。ルータは、ネイバーが送信し続ける独自の古いLSPを認証できないため、独自のLSPシーケンス番号を増やすことができません。そのため、ルータは、すべてのネイバーが元のLSPのすべてをタイムアウトするまで、LSPシーケンス番号をネイバーに更新できません。この問題の解決策の1つは、IS-ISプロセスが認証失敗の着信LSPにローカルシステムIDがあり、IS-ISプロセスよりも大きいシーケンス番号があるかどうかを検出することです。このイベントでは、IS-ISプロセスは自身のLSPシーケンス番号を適宜増やし、LSPを再度フラッディングする必要があります（SHOULD）。ただし、このシナリオは敵対者によるアクティブな攻撃によってもトリガーされる可能性があるため、このようなアクティブな攻撃によるリスクを軽減するために、このケースでもカウンターを保持することをお勧めします。
This document enhances the security of the IS-IS routing protocol. Because a routing protocol contains information that need not be kept secret, privacy is not a requirement. However, authentication of the messages within the protocol is of interest, to reduce the risk of an adversary compromising the routing system by deliberately injecting false information into the routing system.
このドキュメントは、IS-ISルーティングプロトコルのセキュリティを強化します。ルーティングプロトコルには秘密にしておく必要のない情報が含まれているため、プライバシーは必須ではありません。ただし、プロトコル内のメッセージの認証は、意図的に誤った情報をルーティングシステムに挿入することにより、攻撃者がルーティングシステムを危険にさらすリスクを減らすために重要です。
The technology in this document provides an authentication mechanism for IS-IS. The mechanism described here is not perfect and does not need to be perfect. Instead, this mechanism represents a significant increase in the work function of an adversary attacking the IS-IS protocol, while not causing undue implementation, deployment, or operational complexity.
このドキュメントのテクノロジーは、IS-ISの認証メカニズムを提供します。ここで説明するメカニズムは完全ではなく、完全である必要もありません。代わりに、このメカニズムは、IS-ISプロトコルを攻撃する攻撃者の仕事関数の大幅な増加を表し、過度の実装、展開、または運用の複雑さを引き起こしません。
This mechanism does not prevent replay attacks, however, in most cases, such attacks would trigger existing mechanisms in the IS-IS protocol that would effectively reject old information. Denial of service attacks are not generally preventable in a useful networking protocol [4].
このメカニズムはリプレイ攻撃を防止しませんが、ほとんどの場合、そのような攻撃はIS-ISプロトコルの既存のメカニズムをトリガーし、古い情報を効果的に拒否します。サービス拒否攻撃は、有用なネットワーキングプロトコルでは一般に防止できません[4]。
Changes to the authentication mechanism described here (primarily: to add a Key-ID field such as OSPFv2 and RIPv2 have) were considered at some length, but ultimately were rejected. The mechanism here was already widely implemented in 1999. As of this writing, this mechanism is fairly widely deployed within the users interested in cryptographic authentication of IS-IS. The improvement provided by the proposed revised mechanism was not large enough to justify the change, given the installed base and lack of operator interest in deploying a revised mechanism.
ここで説明する認証メカニズムへの変更（主に：OSPFv2やRIPv2などのKey-IDフィールドを追加すること）はある程度考慮されましたが、最終的には拒否されました。ここでのメカニズムはすでに1999年に広く実装されていました。これを書いている時点では、このメカニズムはIS-ISの暗号化認証に関心のあるユーザーの中でかなり広く展開されています。インストールされたベースと、改訂されたメカニズムの展開に対するオペレーターの関心の欠如を考えると、提案された改訂されたメカニズムによって提供される改善は、変更を正当化するほど大きくありませんでした。
If and when a key management protocol appears that is both widely implemented and easily deployed to secure routing protocols such as IS-IS, a different authentication mechanism that is designed for use with that key management schema could be added if desired.
IS-ISなどの安全なルーティングプロトコルに広く実装され、簡単に展開できるキー管理プロトコルが表示された場合、必要に応じて、そのキー管理スキーマで使用するために設計された別の認証メカニズムを追加できます。
If a stronger authentication were believed to be required, then the use of a full digital signature [5] would be an approach that should be seriously considered. It was rejected for this purpose at this time because the computational burden of full digital signatures is believed to be much higher than is reasonable given the current threat environment in operational commercial networks.
より強力な認証が必要であると考えられている場合、完全なデジタル署名の使用[5]は、真剣に検討する必要のあるアプローチになります。完全なデジタル署名の計算負荷は、運用中の商用ネットワークにおける現在の脅威環境を考慮して、合理的なものよりはるかに高いと考えられているため、現時点ではこの目的で拒否されました。
Acknowledgements
謝辞
The authors would like to thank (in alphabetical order) Dave Katz, Steven Luong, Tony Przygienda, Nai-Ming Shen, and Henk Smit for their comments and suggestions on this document.
著者は、このドキュメントに対するコメントと提案について、Dave Katz、Steven Luong、Tony Przygienda、Nai-Ming Shen、およびHenk Smitに（アルファベット順で）感謝します。
Normative References
引用文献
[1] ISO, "Intermediate System to Intermediate System Routing Information Exchange Protocol for use in Conjunction with the Protocol for Providing the Connectionless-mode Network Service (ISO 8473)", ISO/IEC 10589:2002, Second Edition.
[1] ISO、「コネクションレスモードのネットワークサービスを提供するためのプロトコル（ISO 8473）と組み合わせて使用するための中間システムから中間システムへのルーティング情報交換プロトコル」、ISO / IEC 10589：2002、Second Edition。
[2] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997.
[2] Krawczyk、H.、Bellare、M。、およびR. Canetti、「HMAC：Keyed-Hashing for Message Authentication」、RFC 2104、1997年2月。
Informative References
参考引用
[3] Callon, R., "Use of OSI IS-IS for Routing in TCP/IP and Dual environments", RFC 1195, December 1990.
[3] Callon、R。、「TCP / IPおよびデュアル環境でのルーティングのためのOSI IS-ISの使用」、RFC 1195、1990年12月。
[4] Voydock, V. and S. Kent, "Security Mechanisms in High-level Networks", ACM Computing Surveys, Vol. 15, No. 2, June 1983.
[4] Voydock、V。およびS.ケント、「高レベルネットワークのセキュリティメカニズム」、ACM Computing Surveys、Vol。 15、No。2、1983年6月。
[5] Murphy, S., Badger, M. and B. Wellington, "OSPF with Digital Signatures", RFC 2154, June 1997.
[5] マーフィー、S。、バジャー、M.、B。ウェリントン、「OSPF with Digital Signatures」、RFC 2154、1997年6月。
Authors' Addresses
著者のアドレス
Tony Li Procket Networks 1100 Cadillac Ct. Milpitas, CA 95035 USA
トニー・リー・プロケット・ネットワークス1100キャデラックCt。ミルピタス、カリフォルニア州95035米国
Phone: +1 (408) 635-7903
EMail: tli@procket.net
Ran J. Atkinson Extreme Networks 3585 Monroe Street Santa Clara, CA 95051 USA
らん Ｊ。 あｔきんそん えｘｔれめ ねとぉｒｋｓ ３５８５ もんろえ Ｓｔれえｔ さんた Ｃぁら、 か ９５０５１ うさ
Phone: +1 (408) 579-2800
EMail: rja@extremenetworks.com
Full Copyright Statement
完全な著作権表示
Copyright (C) The Internet Society (2003). All Rights Reserved.
Copyright（C）The Internet Society（2003）。全著作権所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
このドキュメントとその翻訳はコピーして他のユーザーに提供することができ、コメントまたはその他の方法で説明したり、その実装を支援する派生物を、全体または一部を問わず、準備、コピー、公開、配布することができます。ただし、上記の著作権表示とこの段落は、そのようなすべてのコピーと派生物に含まれています。ただし、このドキュメント自体は、著作権に関する通知を削除したり、インターネットソサエティや他のインターネット組織への参照を削除したりするなど、いかなる方法でも変更できません。ただし、インターネット標準を開発する目的で必要な場合は除きます。インターネット標準のプロセスに従うか、または必要に応じて、それを英語以外の言語に翻訳する必要があります。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees.
上記で付与された制限付きのアクセス許可は永続的であり、インターネットソサエティまたはその継承者または譲受人によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.
このドキュメントとここに含まれる情報は「現状有姿」で提供され、インターネット社会およびインターネット技術タスクフォースは、明示または黙示を問わず、ここに記載されている情報の使用が保証するものに限定されない一切の保証を含みません。商品性または特定の目的への適合性に関する権利または黙示の保証を侵害すること。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能への資金提供は、現在Internet Societyから提供されています。