[要約] RFC 5304は、"IS-IS Cryptographic Authentication"に関する文書で、Intermediate System to Intermediate System (IS-IS) プロトコルにおける情報の認証を強化するための仕様を提供します。このRFCの目的は、IS-ISプロトコルで交換される情報の改ざんを防ぎ、ネットワークのセキュリティを向上させることにあります。利用場面としては、特にセキュリティが重要視されるネットワーク環境でのIS-ISプロトコルの使用時に適用されます。関連するRFCとしては、RFC 1195（IS-ISの使用を拡張するもの）、RFC 5305（IS-ISの拡張）、RFC 5310（IS-ISのセキュリティ機能の強化）などがあります。これらのRFCは、IS-ISプロトコルの機能拡張やセキュリティ向上に貢献しています。
Network Working Group T. Li
Request for Comments: 5304 Redback Networks, Inc.
Obsoletes: 3567 R. Atkinson
Updates: 1195 Extreme Networks, Inc.
Category: Standards Track October 2008
IS-IS Cryptographic Authentication
IS-IS暗号化認証
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）の最新版を参照してください。このメモの配布は無制限です。
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. This document replaces RFC 3567.
このドキュメントでは、RFC 2104にあるハッシュメッセージ認証コード-メッセージダイジェスト5（HMAC-MD5）アルゴリズムを使用した中間システムから中間システム（IS-IS）プロトコルデータユニット（PDU）の認証について説明します。IS-ISは、 RFC 1195で説明されているインターネットプロトコルバージョン4（IPv4）をサポートする拡張機能を備えた国際標準化機構（ISO）10589。基本仕様には、複数の認証アルゴリズムを可能にする認証メカニズムが含まれています。基本仕様では、平文パスワードのアルゴリズムのみを指定しています。このドキュメントはRFC 3567に代わるものです。
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認証アルゴリズムを既存の認証メカニズムと組み合わせて使用できるようにする、その仕様への拡張を提案しています。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Authentication Procedures . . . . . . . . . . . . . . . . . . . 3
2.1. Implementation Considerations . . . . . . . . . . . . . . . 5
3. Security Considerations . . . . . . . . . . . . . . . . . . . . 5
3.1. Security Limitations . . . . . . . . . . . . . . . . . . . 5
3.2. Assurance . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.3. Key Configuration . . . . . . . . . . . . . . . . . . . . . 6
3.4. Other Considerations . . . . . . . . . . . . . . . . . . . 7
3.5. Future Directions . . . . . . . . . . . . . . . . . . . . . 7
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8
6.1. Normative References . . . . . . . . . . . . . . . . . . . 8
6.2. Informative References . . . . . . . . . . . . . . . . . . 9
The IS-IS protocol, as specified in [ISO-10589], provides for the authentication of Link State Protocol Data Units (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 [RFC1195].
[ISO-10589]で規定されているIS-ISプロトコルは、LSPの一部として認証情報を含めることにより、リンクステートプロトコルデータユニット（LSP）の認証を提供します。この認証情報はType-Length-Value（TLV）タプルとしてエンコードされます。 IPv4ネットワークでのIS-ISの使用については、[RFC1195]で説明されています。
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. This document replaces [RFC3567], which is an Informational RFC. This document is on the Standards Track. This document has revised Section 3, with the significant addition of a discussion of recent attacks on MD5 in Section 3.2. This document has also added a substantive "IANA Considerations" section to create a missing codepoint registry.
このドキュメントは、IETF内のIS-ISワーキンググループの発行物です。このドキュメントは、情報RFCである[RFC3567]に代わるものです。このドキュメントは標準化過程にあります。このドキュメントはセクション3を改訂し、セクション3.2でMD5に対する最近の攻撃に関する説明を大幅に追加しています。このドキュメントには、不足しているコードポイントレジストリを作成するための実質的な「IANAの考慮事項」セクションも追加されています。
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」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 [RFC2119]で説明されているように解釈されます。
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 [RFC2104]. 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が必要です[RFC2104]。キー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と同様にドメイン認証文字列を使用するものとします（SHALL）。 IS-IS Hello PDUはリンクレベル認証文字列を使用する必要があります（SHALL）。これは、リンクステート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 field, 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 that occurs just after password rollover on an IS-IS router and 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 to restart from the value 1 using the new password. However, neighbors will reject those new LSPs because the Sequence Number is smaller. The router cannot increase its own LSP Sequence Number because it fails to authenticate its own old LSP that neighbors keep sending to it. So the router cannot 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 be kept on this case to mitigate the risk from such an 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 in order to reduce the risk of an adversary compromising the routing system by deliberately injecting false information into that 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. It provides improved security against passive attacks, as defined in [RFC1704], when compared to cleartext password authentication.
このドキュメントのテクノロジーは、IS-ISの認証メカニズムを提供します。ここで説明するメカニズムは完全ではなく、完全である必要もありません。代わりに、このメカニズムは、IS-ISプロトコルを攻撃する攻撃者の仕事関数の大幅な増加を表し、過度の実装、展開、または運用の複雑さを引き起こしません。 [RFC1704]で定義されているように、クリアテキストのパスワード認証と比較すると、パッシブ攻撃に対するセキュリティが向上します。
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 [DoS].
このメカニズムはリプレイ攻撃を防止しません。ただし、ほとんどの場合、このような攻撃はIS-ISプロトコルの既存のメカニズムをトリガーし、古い情報を効果的に拒否します。一般に、サービス拒否攻撃は、有用なネットワーキングプロトコル[DoS]では防止できません。
The mechanisms in this document do not provide protection against compromised, malfunctioning, or misconfigured routers. Such routers can, either accidentally or deliberately, cause malfunctions that affect the whole routing domain. The reader is encouraged to consult [RFC4593] for a more comprehensive description of threats to routing protocols.
このドキュメントのメカニズムは、ルーターのセキュリティが低下したり、誤動作したり、設定が誤っていたりすることを防ぐものではありません。このようなルーターは、偶然または故意に、ルーティングドメイン全体に影響を与える誤動作を引き起こす可能性があります。ルーティングプロトコルに対する脅威のより包括的な説明については、[RFC4593]を参照することをお勧めします。
Users need to understand that the quality of the security provided by this mechanism depends completely on the strength of the implemented authentication algorithms, the strength of the key being used, and the correct implementation of the security mechanism in all communicating IS-IS implementations. This mechanism also depends on the IS-IS Authentication Key being kept confidential by all parties. If any of these are incorrect or insufficiently secure, then no real security will be provided to the users of this mechanism.
ユーザーは、このメカニズムによって提供されるセキュリティの品質が、実装されている認証アルゴリズムの強度、使用されているキーの強度、および通信するすべてのIS-IS実装でのセキュリティメカニズムの正しい実装に完全に依存することを理解する必要があります。このメカニズムは、IS-IS認証キーがすべての関係者によって機密に保持されていることにも依存します。これらのいずれかが正しくない、または安全性が不十分である場合、このメカニズムのユーザーには実際のセキュリティは提供されません。
Since Dobbertin's attacks on MD5 [Dobb96a] [Dobb96b] [Dobb98] were first published a dozen years ago, there have been growing concerns about the effectiveness of the compression function within MD5. More recent work by Wang and Yu [WY05] accentuates these concerns. However, despite these research results, there are no published attacks at present on either Keyed-MD5 or HMAC-MD5. A recent paper by Bellare [Bell06a] [Bell06b] provides new proofs for the security of HMAC that require fewer assumptions than previous published proofs for HMAC. Those proofs indicate that the published issues with MD5 (and separately with SHA-1) do not create an attack on HMAC-MD5 (or HMAC SHA-1). Most recently, Fouque and others [FLN07] have published new attacks on NMAC-MD4, HMAC-MD4, and NMAC-MD5. However, their attacks are non-trivial computationally, and they have not found an equivalent attack on HMAC-MD5. So, despite the published issues with the MD5 algorithm, there is currently no published attack that applies to HMAC-MD5 as used in this IS-IS specification. As with any cryptographic technique, there is the possibility of the discovery of future attacks against this mechanism.
MD5に対するDobbertinの攻撃[Dobb96a] [Dobb96b] [Dobb98]が最初に発表されてから10年が経過したため、MD5内の圧縮機能の有効性に関する懸念が高まっています。 WangとYu [WY05]による最近の研究は、これらの懸念を強調しています。ただし、これらの研究結果にもかかわらず、Keyed-MD5またはHMAC-MD5のいずれにも現在公開されている攻撃はありません。 Bellareによる最近の論文[Bell06a] [Bell06b]は、以前に公開されたHMACの証明よりも少ない仮定を必要とするHMACのセキュリティの新しい証明を提供します。これらの証拠は、MD5（およびSHA-1とは別に）で公開された問題がHMAC-MD5（またはHMAC SHA-1）への攻撃を引き起こさないことを示しています。最近では、Fouqueと他の[FLN07]がNMAC-MD4、HMAC-MD4、およびNMAC-MD5に対する新しい攻撃を公開しています。しかし、それらの攻撃は計算上重要ではなく、HMAC-MD5に対する同等の攻撃は発見されていません。そのため、MD5アルゴリズムに関する公開された問題にもかかわらず、このIS-IS仕様で使用されるHMAC-MD5に適用される公開された攻撃は現在ありません。他の暗号技術と同様に、このメカニズムに対する将来の攻撃が発見される可能性があります。
It should be noted that the key configuration mechanism of routers may restrict the possible keys that may be used between peers. It is strongly recommended that an implementation be able to support, at minimum, a key composed of a string of printable ASCII of 80 bytes or less, as this is current practice.
ルーターのキー構成メカニズムは、ピア間で使用される可能性のあるキーを制限する場合があることに注意してください。これは現在の慣例であるため、実装では、少なくとも80バイト以下の印刷可能なASCIIの文字列で構成されるキーをサポートできるようにすることを強くお勧めします。
Changes to the authentication mechanism described here (primarily: to add a Key-ID field such as that of OSPFv2 and RIPv2) 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 [RFC2154] 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.
より強力な認証が必要であると考えられる場合、完全なデジタル署名[RFC2154]の使用は真剣に検討する必要のあるアプローチになります。運用中の商用ネットワークにおける現在の脅威環境を考えると、完全なデジタル署名の計算負荷は合理的なものよりはるかに高いと考えられているため、現時点ではこの目的で拒否されました。
If and when additional authentication mechanisms are defined (for example, to provide a cryptographically stronger hash function), it will also be necessary to define mechanisms that allow graceful transition from the existing mechanisms (as defined in this document) to any future mechanism.
追加の認証メカニズムが定義されている場合（たとえば、暗号化により強力なハッシュ関数を提供するため）、既存のメカニズム（このドキュメントで定義されている）から将来のメカニズムへの適切な移行を可能にするメカニズムも定義する必要があります。
IANA has created a new codepoint registry to administer the Authentication Type codepoints for TLV 10. This registry is part of the existing IS-IS codepoints registry as established by [RFC3563] and [RFC3359]. This registry is managed using the Designated Expert policy as described in [RFC5226] and is called "IS-IS Authentication Type Codes for TLV 10".
IANAは、TLV 10の認証タイプコードポイントを管理するための新しいコードポイントレジストリを作成しました。このレジストリは、[RFC3563]および[RFC3359]によって確立された既存のIS-ISコードポイントレジストリの一部です。このレジストリは、[RFC5226]で説明されているDesignated Expertポリシーを使用して管理され、「TLV 10のIS-IS認証タイプコード」と呼ばれます。
The values in the "IS-IS Authentication Type Codes for TLV 10" registry should be recorded in decimal and should only be approved after a designated expert, appointed by the IESG area director, has been consulted. The intention is that any allocation will be accompanied by a published RFC. However, the designated expert can approve allocations once it seems clear that an RFC will be published, allowing for the allocation of values prior to the document being approved for publication as an RFC. New items should be documented in a publicly and freely available specification. We should also allow external specifications to allocate and use the IS-IS Authentication Type Codes maintained by this registry.
「TLV 10のIS-IS認証タイプコード」レジストリの値は10進数で記録し、IESGエリアディレクターによって任命された指定の専門家に相談した後にのみ承認する必要があります。意図は、すべての割り当てに公開されたRFCが伴うことです。ただし、指定されたエキスパートは、RFCが公開されることが明確になったら割り当てを承認できます。これにより、RFCとしての公開が承認される前に値の割り当てが可能になります。新しいアイテムは、公的に自由に入手できる仕様で文書化する必要があります。また、このレジストリで管理されているIS-IS認証タイプコードを割り当てて使用することを外部仕様に許可する必要があります。
Initial values for the "IS-IS Authentication Type Codes for TLV 10" registry are given below; future assignments are to be made through Expert Review. Assignments consist of an authentication type name and its associated value.
「TLV 10のIS-IS認証タイプコード」レジストリの初期値を以下に示します。将来の割り当ては、エキスパートレビューを通じて行われます。割り当ては、認証タイプ名とそれに関連付けられた値で構成されます。
+---------------------------------------------+-------+-------------+
| Authentication Type Code | Value | Reference |
+---------------------------------------------+-------+-------------+
| Reserved | 0 | [ISO-10589] |
| Cleartext Password | 1 | [ISO-10589] |
| ISO 10589 Reserved | 2 | [ISO-10589] |
| HMAC-MD5 Authentication | 54 | RFC 5304 |
| Routeing Domain private authentication | 255 | [ISO-10589] |
| method | | |
+---------------------------------------------+-------+-------------+
The authors would like to thank (in alphabetical order) Stephen Farrell, Dave Katz, Steven Luong, Tony Przygienda, Nai-Ming Shen, and Henk Smit for their comments and suggestions on this document.
著者は、このドキュメントに関するコメントと提案について、Stephen Farrell、Dave Katz、Steven Luong、Tony Przygienda、Nai-Ming Shen、およびHenk Smitに（アルファベット順で）感謝します。
[ISO-10589] ISO, "Intermediate System to Intermediate System intra-domain routeing information exchange protocol for use in conjunction with the protocol for providing the connectionless-mode network service (ISO 8473)", International Standard 10589:2002, Second Edition, 2002.
[ISO-10589] ISO、「コネクションレスモードのネットワークサービス（ISO 8473）を提供するためのプロトコルと組み合わせて使用する中間システムから中間システムのドメイン内ルーティング情報交換プロトコル」、国際標準10589：2002、第2版、 2002年
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997.
[RFC2104] Krawczyk、H.、Bellare、M。、およびR. Canetti、「HMAC：Keyed-Hashing for Message Authentication」、RFC 2104、1997年2月。
[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月。
[Bell06a] Bellare, M., "New Proofs for NMAC and HMAC: Security without Collision-Resistance", Preliminary Version, in Proceedings of Crypto 2006, Lecture Notes in Computer Science, Vol. 4117, August 2006.
[Bell06a] Bellare、M。、「NMACとHMACの新しい証明：衝突防止なしのセキュリティ」、暫定版、Crypto 2006、Lecture Notes in Computer Science、Vol。 4117、2006年8月。
[Bell06b] Bellare, M., "New Proofs for NMAC and HMAC: Security without Collision-Resistance", August 2006, <http:// www-cse.ucsd.edu/users/mihir/papers/hmac-new.html>.
[Bell06b] Bellare、M。、「NMACおよびHMACの新しい証明：衝突防止なしのセキュリティ」、2006年8月、<http：// www-cse.ucsd.edu/users/mihir/papers/hmac-new.html >。
[DoS] Voydock, V. and S. Kent, "Security Mechanisms in High-level Networks", ACM Computing Surveys Vol. 15, No. 2, June 1983.
[DoS] Voydock、V。およびS.ケント、「高レベルネットワークのセキュリティメカニズム」、ACM Computing Surveys Vol。 15、No。2、1983年6月。
[Dobb96a] Dobbertin, H., "Cryptanalysis of MD5 Compress", EuroCrypt Rump Session 1996, May 1996.
[Dobb96a] Dobbertin、H。、「MD5 Compressの暗号解読」、EuroCrypt Rump Session 1996、1996年5月。
[Dobb96b] Dobbertin, H., "The Status of MD5 After a Recent Attack", CryptoBytes, Vol. 2, No. 2, 1996.
[Dobb96b] Dobbertin、H。、「最近の攻撃後のMD5のステータス」、CryptoBytes、Vol。 2、No。2、1996。
[Dobb98] Dobbertin, H., "Cryptanalysis of MD4", Journal of Cryptology, Vol. 11, No. 4, 1998.
[Dobb98] Dobbertin、H。、「MD4の暗号解析」、Journal of Cryptology、Vol。 11、No。4、1998。
[FLN07] Fouque, P., Leurent, G., and P. Nguyen, "Full Key-Recovery Attacks on HMAC/NMAC-MD5 and NMAC-MD5", Proceedings of Crypto 2007, August 2007.
[FLN07] Fouque、P.、Leurent、G。、およびP. Nguyen、「HMAC / NMAC-MD5およびNMAC-MD5に対する完全なキー回復攻撃」、Proceedings of Crypto 2007、2007年8月。
[RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and dual environments", RFC 1195, December 1990.
[RFC1195] Callon、R。、「TCP / IPおよびデュアル環境でのルーティングのためのOSI IS-ISの使用」、RFC 1195、1990年12月。
[RFC1704] Haller, N. and R. Atkinson, "On Internet Authentication", RFC 1704, October 1994.
[RFC1704] Haller、N。およびR. Atkinson、「On Internet Authentication」、RFC 1704、1994年10月。
[RFC2154] Murphy, S., Badger, M., and B. Wellington, "OSPF with Digital Signatures", RFC 2154, June 1997.
[RFC2154] Murphy、S.、Badger、M。、およびB. Wellington、「OSPF with Digital Signatures」、RFC 2154、1997年6月。
[RFC3359] Przygienda, T., "Reserved Type, Length and Value (TLV) Codepoints in Intermediate System to Intermediate System", RFC 3359, August 2002.
[RFC3359] Przygienda、T。、「中間システムから中間システムへの予約済みタイプ、長さ、および値（TLV）コードポイント」、RFC 3359、2002年8月。
[RFC3563] Zinin, A., "Cooperative Agreement Between the ISOC/IETF and ISO/IEC Joint Technical Committee 1/Sub Committee 6 (JTC1/SC6) on IS-IS Routing Protocol Development", RFC 3563, July 2003.
[RFC3563] Zinin、A。、「IS-ISルーティングプロトコルの開発に関するISOC / IETFとISO / IECの合同技術委員会1 /サブ委員会6（JTC1 / SC6）間の協力協定」、RFC 3563、2003年7月。
[RFC3567] Li, T. and R. Atkinson, "Intermediate System to Intermediate System (IS-IS) Cryptographic Authentication", RFC 3567, July 2003.
[RFC3567] Li、T。およびR. Atkinson、「Intermediate System to Intermediate System（IS-IS）Cryptographic Authentication」、RFC 3567、2003年7月。
[RFC4593] Barbir, A., Murphy, S., and Y. Yang, "Generic Threats to Routing Protocols", RFC 4593, October 2006.
[RFC4593] Barbir、A.、Murphy、S。、およびY. Yang、「ルーティングプロトコルに対する一般的な脅威」、RFC 4593、2006年10月。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5226] Narten、T。およびH. Alvestrand、「RFCでIANAの考慮事項セクションを作成するためのガイドライン」、BCP 26、RFC 5226、2008年5月。
[WY05] Wang, X. and H. Yu, "How to Break MD5 and Other Hash Functions", Proceedings of EuroCrypt 2005, Lecture Notes in Computer Science, Vol. 3494, 2005.
[WY05] Wang、X。およびH. Yu、「MD5およびその他のハッシュ関数を壊す方法」、EuroCrypt 2005の議事録、コンピュータサイエンスの講演ノート、Vol。 3494、2005。
Authors' Addresses
著者のアドレス
Tony Li Redback Networks, Inc. 300 Holger Way San Jose, CA 95134 USA
Tony Li Redback Networks、Inc. 300 Holger Way San Jose、CA 95134 USA
Phone: +1 408 750 5160
EMail: tony.li@tony.li
R. Atkinson Extreme Networks, Inc. 3585 Monroe St. Santa Clara, CA 95051 USA
R. Atkinson Extreme Networks、Inc. 3585 Monroe St. Santa Clara、CA 95051 USA
Phone: +1 408 579 2800
EMail: rja@extremenetworks.com
Full Copyright Statement
完全な著作権表示
Copyright (C) The IETF Trust (2008).
Copyright（C）IETF Trust（2008）。
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は、この規格の実装に必要となる可能性のある技術をカバーする可能性のある著作権、特許、特許出願、またはその他の所有権に注意を向けるよう、利害関係者に呼びかけます。 IEETのietf-ipr@ietf.orgに情報を送信してください。