[要約] RFC 5310は、IS-ISプロトコルにおける汎用的な暗号認証メカニズムを定義しています。この文書の目的は、IS-ISが使用するメッセージの認証を強化し、偽造や改ざんから保護するための方法を提供することです。利用場面としては、ネットワーク内でのルーティング情報の安全な交換が挙げられます。関連するRFCとしては、RFC 1195（IS-ISの使用をTCP/IPと同様のプロトコルに拡張するもの）、RFC 5304（IS-ISのセキュリティ拡張）、RFC 5309（IS-ISのポイント・トゥ・ポイントオーバーラン接続のための拡張）などがあります。RFC 5310は、ネットワークのセキュリティを向上させるために重要な役割を果たします。
Network Working Group M. Bhatia
Request for Comments: 5310 Alcatel-Lucent
Category: Standards Track V. Manral
IP Infusion
T. Li
Redback Networks Inc.
R. Atkinson
Extreme Networks
R. White
Cisco Systems
M. Fanto
Aegis Data Security
February 2009
IS-IS Generic Cryptographic Authentication
IS-IS Generic Cryptographic Authentication
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) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2009 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
この文書は、BCP 78およびこの文書の発行日に有効なIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。
Abstract
概要
This document proposes an extension to Intermediate System to Intermediate System (IS-IS) to allow the use of any cryptographic authentication algorithm in addition to the already-documented authentication schemes, described in the base specification and RFC 5304. IS-IS is specified in International Standards Organization (ISO) 10589, with extensions to support Internet Protocol version 4 (IPv4) described in RFC 1195.
このドキュメントでは、中間システム間（IS-IS）の拡張を提案し、基本仕様とRFC 5304で説明されている、すでに文書化されている認証スキームに加えて、暗号化認証アルゴリズムを使用できるようにします。IS-ISは、 RFC 1195に記載されているインターネットプロトコルバージョン4（IPv4）をサポートする拡張機能を備えた国際標準化機構（ISO）10589。
Although this document has been written specifically for using the Hashed Message Authentication Code (HMAC) construct along with the Secure Hash Algorithm (SHA) family of cryptographic hash functions, the method described in this document is generic and can be used to extend IS-IS to support any cryptographic hash function in the future.
このドキュメントは、ハッシュメッセージ認証コード（HMAC）構成を暗号化ハッシュ関数のセキュアハッシュアルゴリズム（SHA）ファミリーと共に使用するために特別に記述されていますが、このドキュメントで説明されている方法は一般的であり、IS-ISの拡張に使用できます。将来的に暗号化ハッシュ関数をサポートするため。
Table of Contents
目次
1. Introduction ....................................................2
1.1. Conventions Used in This Document ..........................3
2. IS-IS Security Association ......................................3
3. Authentication Procedures .......................................4
3.1. Authentication TLV .........................................4
3.2. Authentication Process .....................................5
3.3. Cryptographic Aspects ......................................5
3.4. Procedures at the Sending Side .............................7
3.5. Procedure at the Receiving Side ............................8
4. Security Considerations .........................................8
5. Acknowledgments .................................................9
6. IANA Considerations ............................................10
7. References .....................................................10
7.1. Normative References ......................................10
7.2. Informative References ....................................11
The Intermediate System to Intermediate System (IS-IS) specification ([ISO], [RFC1195]) allows for authentication of its Protocol Data Units (PDUs) via the authentication TLV 10 that is carried as a part of the PDU. The base specification has provision for only cleartext passwords and RFC 5304 [RFC5304] augments this to provide the capability to use Hashed Message Authentication Code - Message Digest 5 (HMAC-MD5) authentication for its PDUs.
Intermediate System to Intermediate System（IS-IS）仕様（[ISO]、[RFC1195]）では、PDUの一部として伝送される認証TLV 10を介して、そのプロトコルデータユニット（PDU）を認証できます。基本仕様にはクリアテキストのパスワードのみの規定があり、RFC 5304 [RFC5304]はこれを拡張して、そのPDUにハッシュメッセージ認証コード-メッセージダイジェスト5（HMAC-MD5）認証を使用する機能を提供します。
The first octet of the value field of TLV 10 specifies the type of authentication to be carried out. Type 0 is reserved, Type 1 indicates a cleartext password, Type 54 indicates HMAC MD5, and Type 255 is used for routing domain private authentication methods. The remainder of the value field contains the actual authentication data, determined by the value of the authentication type.
TLV 10の値フィールドの最初のオクテットは、実行される認証のタイプを指定します。タイプ0は予約済み、タイプ1はクリアテキストパスワード、タイプ54はHMAC MD5を示し、タイプ255はルーティングドメインのプライベート認証方法に使用されます。値フィールドの残りの部分には、認証タイプの値によって決定される実際の認証データが含まれています。
This document proposes a new authentication type to be carried in TLV 10, called the generic cryptographic authentication (CRYPTO_AUTH). This can be used to specify any authentication algorithm for authenticating and verifying IS-IS PDUs.
このドキュメントは、一般的な暗号化認証（CRYPTO_AUTH）と呼ばれる、TLV 10で実行される新しい認証タイプを提案します。これを使用して、IS-IS PDUを認証および検証するための認証アルゴリズムを指定できます。
This document also explains how HMAC-SHA authentication can be used in IS-IS.
このドキュメントでは、IS-ISでHMAC-SHA認証を使用する方法についても説明します。
By definition, HMAC ([RFC2104], [FIPS-198]) requires a cryptographic hash function. We propose to use any one of SHA-1, SHA-224, SHA-256, SHA-384, or SHA-512 [FIPS-180-3] to authenticate the IS-IS PDUs.
定義により、HMAC（[RFC2104]、[FIPS-198]）には暗号化ハッシュ関数が必要です。 IS-IS PDUの認証には、SHA-1、SHA-224、SHA-256、SHA-384、またはSHA-512 [FIPS-180-3]のいずれかを使用することをお勧めします。
We propose to do away with the per-interface keys and instead have Key IDs that map to unique IS-IS Security Associations (SAs).
インターフェイスごとのキーを廃止し、代わりに一意のIS-ISセキュリティアソシエーション（SA）にマップするキーIDを用意することを提案します。
While at the time of this writing there are no openly published attacks on the HMAC-MD5 mechanism, some reports ([Dobb96a], [Dobb96b]) create concern about the ultimate strength of the MD5 cryptographic hash function.
この記事の執筆時点では、HMAC-MD5メカニズムに対する公開された攻撃はありませんが、一部のレポート（[Dobb96a]、[Dobb96b]）は、MD5暗号化ハッシュ関数の最終的な強度について懸念を抱いています。
The mechanism described in this document does not provide confidentiality, since PDUs are sent in the clear. However, the objective of a routing protocol is to advertise the routing topology, and confidentiality is not normally required for routing protocols.
PDUは平文で送信されるため、このドキュメントで説明されているメカニズムでは機密性は提供されません。ただし、ルーティングプロトコルの目的はルーティングトポロジをアドバタイズすることであり、ルーティングプロトコルには通常、機密性は必要ありません。
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]で説明されているように解釈されます。
An IS-IS Security Association contains a set of parameters shared between any two legitimate IS-IS speakers.
IS-ISセキュリティアソシエーションには、2つの正当なIS-ISスピーカー間で共有される一連のパラメータが含まれています。
Parameters associated with an IS-IS SA:
IS-IS SAに関連するパラメータ：
o Key Identifier (Key ID): This is a two-octet unsigned integer used to uniquely identify an IS-IS SA, as manually configured by the network operator.
o キー識別子（キーID）：これは、ネットワークオペレーターが手動で構成した、IS-IS SAを一意に識別するために使用される2オクテットの符号なし整数です。
The receiver determines the active SA by looking at the Key ID field in the incoming PDU.
受信側は、着信PDUのキーIDフィールドを調べて、アクティブなSAを決定します。
The sender, based on the active configuration, selects the Security Association to use and puts the correct Key ID value associated with the Security Association in the IS-IS PDU. If multiple valid and active IS-IS Security Associations exist for a given outbound interface at the time an IS-IS PDU is sent, the sender may use any of those Security Associations to protect the packet.
送信者は、アクティブな構成に基づいて、使用するセキュリティアソシエーションを選択し、セキュリティアソシエーションに関連付けられた正しいキーID値をIS-IS PDUに入れます。 IS-IS PDUの送信時に、特定の送信インターフェイスに対して複数の有効でアクティブなIS-ISセキュリティアソシエーションが存在する場合、送信者はそれらのセキュリティアソシエーションのいずれかを使用してパケットを保護できます。
Using Key IDs makes changing keys while maintaining protocol operation convenient. Each Key ID specifies two independent parts: the authentication protocol and the authentication key, explained below. Normally, an implementation would allow the network operator to configure a set of keys in a key chain, with each key in the chain having a fixed lifetime. The actual operation of these mechanisms is outside the scope of this document.
キーIDを使用すると、プロトコルの操作を維持しながらキーを変更できます。各キーIDは、認証プロトコルと認証キーの2つの独立した部分を指定します。通常、実装により、ネットワークオペレーターは、キーチェーン内のキーのセットを構成できます。チェーン内の各キーは、有効期間が固定されています。これらのメカニズムの実際の操作は、このドキュメントの範囲外です。
Note that each Key ID can indicate a key with a different authentication protocol. This allows multiple authentication mechanisms to be used at various times without disrupting an IS-IS peering, including the introduction of new authentication mechanisms.
各キーIDは、異なる認証プロトコルのキーを示す場合があることに注意してください。これにより、新しい認証メカニズムの導入など、IS-ISピアリングを中断することなく、複数の認証メカニズムをさまざまなタイミングで使用できます。
o Authentication Algorithm: This signifies the authentication algorithm to be used with the IS-IS SA. This information is never sent in cleartext over the wire. Because this information is not sent on the wire, the implementer chooses an implementation-specific representation for this information. At present, the following values are possible: HMAC-SHA-1, HMAC-SHA-224, HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512.
o 認証アルゴリズム：これは、IS-IS SAで使用される認証アルゴリズムを示します。この情報がネットワーク上で平文で送信されることはありません。この情報はネットワーク上で送信されないため、実装者はこの情報の実装固有の表現を選択します。現在、可能な値はHMAC-SHA-1、HMAC-SHA-224、HMAC-SHA-256、HMAC-SHA-384、およびHMAC-SHA-512です。
o Authentication Key: This value denotes the cryptographic authentication key associated with the IS-IS SA. The length of this key is variable and depends upon the authentication algorithm specified by the IS-IS SA.
o 認証キー：この値は、IS-IS SAに関連付けられた暗号化認証キーを示します。このキーの長さは可変であり、IS-IS SAによって指定された認証アルゴリズムによって異なります。
A new authentication code, 3, indicates that the CRYPTO_AUTH mechanism described in this document is in use and is inserted in the first octet of the existing IS-IS Authentication TLV (10).
新しい認証コード3は、このドキュメントで説明されているCRYPTO_AUTHメカニズムが使用中であり、既存のIS-IS認証TLVの最初のオクテットに挿入されていることを示します（10）。
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6
+-+-+-+-+-+-+-+-+
| Type 10 |
+-+-+-+-+-+-+-+-+
| Length |
+-+-+-+-+-+-+-+-+
| Auth Type 3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Key ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
| |
+ +
| Authentication Data (Variable)|
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1
図1
When calculating the CRYPTO_AUTH 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.
シーケンス番号PDUのCRYPTO_AUTH結果を計算する場合、レベル1シーケンス番号PDUは、レベル1リンク状態PDUの場合と同様に、エリア認証文字列を使用する必要があります（SHALL）。レベル2シーケンス番号PDUは、レベル2リンク状態PDUと同様に、ドメイン認証文字列を使用します。
IS-IS HELLO PDUs SHALL use the Link Level Authentication string, which MAY be different from that of Link State PDUs. The CRYPTO_AUTH result for the IS-IS HELLO PDUs SHALL be calculated after the PDU 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.
IS-IS HELLO PDUは、リンクレベル認証文字列を使用するものとします。これは、リンク状態PDUの文字列とは異なる場合があります。パディングが無効になっていない場合、IS-IS HELLO PDUのCRYPTO_AUTH結果は、PDUがMTUサイズにパディングされた後に計算される必要があります（SHALL）。シーケンス番号PDUおよびIS-IS HELLO PDUのオプションのチェックサムをサポートする実装には、チェックサムTLVを含めてはなりません（MUST NOT）。
In the algorithm description below, the following nomenclature, which is consistent with [FIPS-198] is used:
以下のアルゴリズムの説明では、[FIPS-198]と一致する次の用語が使用されます。
H is the specific hashing algorithm (e.g., SHA-256). K is the password for the PDU type as per the International Standard ISO/IEC 10589 [ISO]. Ko is the cryptographic key used with the hash algorithm.
Hは特定のハッシュアルゴリズムです（SHA-256など）。 Kは、国際規格ISO / IEC 10589 [ISO]に基づくPDUタイプのパスワードです。 Koは、ハッシュアルゴリズムで使用される暗号化キーです。
B is the block size of H, measured in octets rather than bits.
Note that B is the internal block size, not the hash size.
For SHA-1 and SHA-256: B == 64
For SHA-384 and SHA-512: B == 128
L is the length of the hash, measured in octets rather than bits.
Lはハッシュの長さで、ビットではなくオクテットで測定されます。
XOR is the exclusive-or operation.
XORは、排他的論理和演算です。
Opad is the hexadecimal value 0x5c repeated B times. Ipad is the hexadecimal value 0x36 repeated B times. Apad is the hexadecimal value 0x878FE1F3 repeated (L/4) times.
Opadは、16進値0x5cをB回繰り返したものです。 Ipadは、16進値0x36をB回繰り返したものです。 Apadは、16進値0x878FE1F3を（L / 4）回繰り返したものです。
(1) Preparation of the Key
（1）キーの準備
In this application, Ko is always L octets long.
このアプリケーションでは、Koは常にLオクテットの長さです。
If the Authentication Key (K) is L octets long, then Ko is equal to K. If the Authentication Key (K) is more than L octets long, then Ko is set to H(K). If the Authentication Key (K) is less than L octets long, then Ko is set to the Authentication Key (K) with zeros appended to the end of the Authentication Key (K) such that Ko is L octets long.
認証キー（K）がLオクテット長の場合、KoはKに等しくなります。認証キー（K）がLオクテットより長い場合、KoはH（K）に設定されます。認証キー（K）がLオクテットより短い場合、Koは認証キー（K）に設定され、認証キー（K）の最後にゼロが追加されて、KoはLオクテットの長さになります。
(2) First Hash
（2）最初のハッシュ
First, the IS-IS packet's Authentication Data field is filled with the value Apad, and the Authentication Type field is set to 0x3.
まず、IS-ISパケットの認証データフィールドに値Apadが入力され、認証タイプフィールドが0x3に設定されます。
Then, a first hash, also known as the inner hash, is computed as follows:
次に、内部ハッシュとも呼ばれる最初のハッシュが次のように計算されます。
First-Hash = H(Ko XOR Ipad || (IS-IS PDU))
First-Hash = H（Ko XOR Ipad ||（IS-IS PDU））
(3) Second Hash
（3）2番目のハッシュ
Then a second hash, also known as the outer hash, is computed as follows:
次に、外部ハッシュとも呼ばれる2番目のハッシュが次のように計算されます。
Second-Hash = H(Ko XOR Opad || First-Hash)
2番目のハッシュ= H（Ko XOR Opad || First-Hash）
(4) Result
（4）結果
The resulting second hash becomes the authentication data that is sent in the Authentication Data field of the IS-IS PDU. The length of the Authentication Data field is always identical to the message digest size of the specific hash function H that is being used.
結果の2番目のハッシュは、IS-IS PDUの認証データフィールドで送信される認証データになります。 [認証データ]フィールドの長さは、使用されている特定のハッシュ関数Hのメッセージダイジェストサイズと常に同じです。
This also means that the use of hash functions with larger output sizes will also increase the size of the IS-IS PDU as transmitted on the wire.
これは、出力サイズが大きいハッシュ関数を使用すると、回線で送信されるIS-IS PDUのサイズも大きくなることも意味します。
An appropriate IS-IS SA is selected for use with an outgoing IS-IS PDU. This is done based on the active key at that instant. If IS-IS is unable to find an active key, then the PDU is discarded.
発信IS-IS PDUで使用するために適切なIS-IS SAが選択されます。これは、その瞬間のアクティブなキーに基づいて行われます。 IS-ISがアクティブなキーを見つけることができない場合、PDUは破棄されます。
If IS-IS is able to find the active key, then the key provides the authentication algorithm (HMAC-SHA-1, HMAC-SHA-224, HMAC-SHA-256, HMAC-SHA-384, or HMAC-SHA-512) that needs to be applied on the PDU.
IS-ISがアクティブなキーを見つけることができる場合、キーは認証アルゴリズムを提供します（HMAC-SHA-1、HMAC-SHA-224、HMAC-SHA-256、HMAC-SHA-384、またはHMAC-SHA-512 ）PDUに適用する必要があります。
An implementation MUST fill the authentication type and the length before the authentication data is computed. The authentication data is computed as explained in the previous section. The length of the TLV is set as per the authentication algorithm that is being used.
認証データが計算される前に、実装は認証タイプと長さを満たさなければなりません（MUST）。認証データは、前のセクションで説明したように計算されます。 TLVの長さは、使用されている認証アルゴリズムに従って設定されます。
The length is set to 23 for HMAC-SHA-1, 31 for HMAC-SHA-224, 35 for HMAC-SHA-256, 51 for HMAC-SHA-384, and 67 for HMAC-SHA-512. Note that two octets have been added to account for the Key ID and one octet for the authentication type.
長さは、HMAC-SHA-1では23、HMAC-SHA-224では31、HMAC-SHA-256では35、HMAC-SHA-384では51、HMAC-SHA-512では67に設定されています。キーIDを説明するために2つのオクテットが追加され、認証タイプのために1つのオクテットが追加されていることに注意してください。
The Key ID is filled.
キーIDが入力されています。
The Checksum and Remaining Lifetime fields are set to zero for the Link State Packets (LSPs) before authentication is calculated.
認証が計算される前に、リンク状態パケット（LSP）のチェックサムフィールドと残りのライフタイムフィールドはゼロに設定されます。
The result of the authentication algorithm is placed in the authentication data, following the Key ID.
認証アルゴリズムの結果は、キーIDに続いて認証データに入れられます。
The authentication data for the IS-IS IIH PDUs MUST be computed after the IS-IS Hello (IIH) has been padded to the MTU size, if padding is not explicitly disabled.
IS-IS IIH PDUの認証データは、パディングが明示的に無効になっていない場合は、IS-IS Hello（IIH）がMTUサイズにパディングされた後に計算する必要があります。
The appropriate IS-IS SA is identified by looking at the Key ID from the Authentication TLV 10 from the incoming IS-IS PDU.
適切なIS-IS SAは、着信IS-IS PDUからの認証TLV 10からのキーIDを調べることによって識別されます。
Authentication-algorithm-dependent processing needs to be performed, using the algorithm specified by the appropriate IS-IS SA for the received packet.
受信したパケットに対して適切なIS-IS SAによって指定されたアルゴリズムを使用して、認証アルゴリズムに依存する処理を実行する必要があります。
Before an implementation performs any processing, it needs to save the values of the Authentication Value, the Checksum, and the Remaining Lifetime fields.
実装が処理を実行する前に、認証値、チェックサム、および残りのライフタイムフィールドの値を保存する必要があります。
It should then set the Authentication Value field with Apad and the Checksum and Remaining Lifetime fields with zero before the authentication data is computed. The calculated data is compared with the received authentication data in the PDU, and the PDU is discarded if the two do not match. In such a case, an error event SHOULD be logged.
次に、認証データが計算される前に、認証値フィールドをApadで、チェックサムフィールドと残りのライフタイムフィールドをゼロで設定する必要があります。計算されたデータはPDUで受信した認証データと比較され、2つが一致しない場合、PDUは破棄されます。そのような場合、エラーイベントがログに記録されるべきです（SHOULD）。
An implementation MAY have a transition mode where it includes CRYPTO_AUTH information in the PDUs but does not verify this information. This is provided as a transition aid for networks in the process of migrating to the new CRYPTO_AUTH-based authentication schemes.
実装には、PDUにCRYPTO_AUTH情報が含まれているが、この情報は検証されない移行モードがある場合があります。これは、新しいCRYPTO_AUTHベースの認証スキームに移行する過程で、ネットワークの移行支援として提供されます。
This document proposes extensions to IS-IS that make it more secure than what it is today. It does not provide confidentiality as a routing protocol contains information that does not need to be kept secret. It does, however, provide means to authenticate the sender of the PDUs, which is of interest to us.
このドキュメントでは、IS-ISの拡張機能を提案します。これにより、現在のIS-ISよりも安全になります。ルーティングプロトコルには秘密にする必要のない情報が含まれているため、機密性は提供されません。ただし、これはPDUの送信者を認証する手段を提供します。これは私たちにとって重要です。
It should be noted that authentication method described in this document is not being used to authenticate the specific originator of a PDU, but is rather being used to confirm that the PDU has indeed been issued by an intermediate system that had access to either the area or domain password, depending upon the kind of PDU it is.
このドキュメントで説明されている認証方法は、PDUの特定の発信元を認証するために使用されているのではなく、そのPDUが実際にエリアまたはいずれかにアクセスした中間システムによって発行されたことを確認するために使用されていることに注意してください。 PDUの種類に応じたドメインパスワード。
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プロトコルを攻撃する攻撃者の仕事関数の大幅な増加を表し、過度の実装、展開、または運用の複雑さを引き起こしません。
The mechanism detailed in this document does not protect IS-IS against replay attacks. An adversary could in theory replay old IIHs and bring down the adjacency [CRYPTO] or replay old Complete Sequence Number PDUs (CSNPs) and Partial Sequence Number PDUs (PSNPs) that would cause a flood of LSPs in the network. Using some sort of crypto sequence numbers in IS-IS IIHs and CSNP/PSNPs is an option to solve this problem. Discussing this is beyond the scope of this document.
このドキュメントで詳しく説明されているメカニズムは、IS-ISをリプレイ攻撃から保護しません。理論上、攻撃者は古いIIHを再生して隣接[CRYPTO]を停止するか、ネットワークでLSPのフラッディングを引き起こす古い完全シーケンス番号PDU（CSNP）と部分シーケンス番号PDU（PSNP）を再生できます。 IS-IS IIHおよびCSNP / PSNPで何らかの暗号シーケンス番号を使用することは、この問題を解決するためのオプションです。これについて議論することは、このドキュメントの範囲を超えています。
This document states that the remaining lifetime of the LSP MUST be set to zero before computing the authentication, thus this field is not authenticated. This field is excluded so that the LSPs may be aged by the ISes in between, without requiring re-computation of the authentication data. This can be exploited by an attacker.
このドキュメントでは、認証を計算する前にLSPの残りのライフタイムをゼロに設定する必要があると述べているため、このフィールドは認証されません。このフィールドは除外されているため、認証データの再計算を必要とせずにLSPがISesによってエージングされる可能性があります。これは攻撃者によって悪用される可能性があります。
There is a transition mode suggested where routers can ignore the CRYPTO_AUTH information carried in the PDUs. The operator must ensure that this mode is only used when migrating to the new CRYPTO_AUTH-based authentication scheme, as this leaves the router vulnerable to an attack.
ルーターがPDUで運ばれるCRYPTO_AUTH情報を無視できる移行モードが提案されています。オペレーターは、このモードが新しいCRYPTO_AUTHベースの認証スキームに移行する場合にのみ使用されることを確認する必要があります。これにより、ルーターが攻撃に対して脆弱になるためです。
To ensure greater security, the keys used should be changed periodically, and implementations MUST be able to store and use more than one key at the same time. Operators should ensure that the authentication key is never sent over the network in cleartext via any protocol. Care should also be taken to ensure that the selected key is unpredictable, avoiding any keys known to be weak for the algorithm in use. [RFC4086] contains helpful information on both key generation techniques and cryptographic randomness.
セキュリティを強化するには、使用するキーを定期的に変更する必要があります。実装では、同時に複数のキーを保存して使用できる必要があります。オペレーターは、認証キーがプロトコルを介してクリアテキストでネットワーク上に送信されないようにする必要があります。また、選択したキーが予測不能になるように注意を払い、使用中のアルゴリズムに対して脆弱であることがわかっているキーを回避する必要があります。 [RFC4086]には、鍵生成技術と暗号のランダム性の両方に関する役立つ情報が含まれています。
It should be noted that the cryptographic strength of the HMAC depends upon the cryptographic strength of the underlying hash function and on the size and quality of the key.
HMACの暗号強度は、基礎となるハッシュ関数の暗号強度と、キーのサイズと品質に依存することに注意してください。
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]の使用は真剣に検討する必要のあるアプローチになります。完全なデジタル署名の計算負荷は、運用中の商用ネットワークにおける現在の脅威環境を考慮して、合理的なものよりはるかに高いと考えられているため、現時点ではこの目的で拒否されました。
The authors would like to thank Hugo Krawczyk, Arjen K. Lenstra (Bell Labs), and Eric Grosse (Bell Labs) for educating us on some of the finer points related to Crypto Mathematics.
著者は、Crypto Mathematicsに関連するいくつかの細かい点について教えてくれたHugo Krawczyk、Arjen K. Lenstra（Bell Labs）、およびEric Grosse（Bell Labs）に感謝します。
We would also like to thank Bill Burr, Tim Polk, John Kelsey, and Morris Dworkin of (US) NIST for review of portions of this document that are directly derived from the closely related work on RIPv2 Cryptographic Authentication [RFC4822].
また、RIPv2暗号化認証[RFC4822]に関する密接に関連した研究から直接得られたこのドキュメントの一部のレビューについて、（米国）NISTのBill Burr、Tim Polk、John Kelsey、およびMorris Dworkinに感謝します。
We would also like to mention Alfred Hoenes for his careful and detailed review during the last call.
最後の電話でのアルフレッド・ホーネスの注意深い詳細なレビューについても触れたいと思います。
Lastly, we would like to acknowledge Brian and Stephen Eisenberg for their continued support.
最後に、ブライアンとスティーブンアイゼンバーグの継続的なサポートに感謝いたします。
IANA has registered the value for the CRYPTO_AUTH method in the "IS-IS Authentication Type Codes for TLV 10" subregistry established by [RFC5304]. The value 3 denotes the CRYPTO_AUTH mechanism for authenticating IS-IS PDUs.
IANAは、CRYPTO_AUTHメソッドの値を、[RFC5304]によって確立された「TLV 10のIS-IS認証タイプコード」サブレジストリに登録しました。値3は、IS-IS PDUを認証するためのCRYPTO_AUTHメカニズムを示します。
+--------------------------------------------+-------+-------------+
| Authentication Type Code | Value | Reference |
+--------------------------------------------+-------+-------------+
| Cryptographic Authentication (CRYPTO_AUTH) | 3 | [RFC5310] |
+--------------------------------------------+-------+-------------+
[FIPS-180-3] US National Institute of Standards & Technology, "Secure Hash Standard (SHS)", FIPS PUB 180-3, October 2008.
[FIPS-180-3]米国国立標準技術研究所、「Secure Hash Standard（SHS）」、FIPS PUB 180-3、2008年10月。
[FIPS-198] US National Institute of Standards & Technology, "The Keyed-Hash Message Authentication Code (HMAC)", FIPS PUB 198, March 2002.
[FIPS-198]米国国立標準技術研究所、「キー付きハッシュメッセージ認証コード（HMAC）」、FIPS PUB 198、2002年3月。
[ISO] "Intermediate system to Intermediate system routeing information exchange protocol for use in conjunction with the Protocol for providing the Connectionless-mode Network Service (ISO 8473)", ISO/IEC 10589:1992.
[ISO]「コネクションレスモードのネットワークサービスを提供するためのプロトコル（ISO 8473）と組み合わせて使用するための中間システムから中間システムへのルーティング情報交換プロトコル」、ISO / IEC 10589：1992。
[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月。
[RFC2104] Krawczk, H., "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997.
[RFC2104] Krawczk、H。、「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, February 2001.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、2001年2月。
[RFC5304] Li, T. and R. Atkinson, "Intermediate System to Intermediate System (IS-IS) Cryptographic Authentication", RFC 5304, October 2008.
[RFC5304] Li、T。およびR. Atkinson、「Intermediate System to Intermediate System（IS-IS）Cryptographic Authentication」、RFC 5304、2008年10月。
[CRYPTO] Vishwas, M., White, R., and M. Bhatia, "Issues with existing Cryptographic Protection Methods for Routing Protocols", Work in Progress, February 2008.
[CRYPTO] Vishwas、M.、White、R。、およびM. Bhatia、「ルーティングプロトコルの既存の暗号化保護方法に関する問題」、2008年2月に進行中の作業。
[Dobb96a] Dobbertin, H., "Cryptanalysis of MD5 Compress", Technical Report, May 1996.
[Dobb96a] Dobbertin、H。、「MD5 Compressの暗号解読」、テクニカルレポート、1996年5月。
[Dobb96b] Dobbertin, H., "The Status of MD5 After a Recent Attack", Cryptobytes, Volume 2, No 2, Summer 1996.
[Dobb96b] Dobbertin、H.、「最近の攻撃後のMD5のステータス」、Cryptobytes、Volume 2、No 2、1996年夏。
[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月。
[RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", RFC 4086, June 2005.
[RFC4086] Eastlake、D.、Schiller、J。、およびS. Crocker、「セキュリティのランダム性要件」、RFC 4086、2005年6月。
[RFC4822] Atkinson, R. and M. Fanto, "RIPv2 Cryptographic Authentication", RFC 4822, February 2007.
[RFC4822] Atkinson、R。およびM. Fanto、「RIPv2 Cryptographic Authentication」、RFC 4822、2007年2月。
Authors' Addresses
著者のアドレス
Manav Bhatia Alcatel-Lucent Bangalore, India
Manav Bhatiaアルカテルルーセントバンガロール、インド
EMail: manav@alcatel-lucent.com
Vishwas Manral IP Infusion Almora, Uttarakhand India
Vishwas Maral Pip Infosionアルモラ、ウッタラーカンド州インド
EMail: vishwas@ipinfusion.com Tony Li Redback Networks Inc. 300 Holger Way San Jose, CA 95134 USA
Eメール：vishwas@ipinfusion.com Tony Li Redback Networks Inc. 300 Holger Way San Jose、CA 95134 USA
EMail: tony.li@tony.li
Randall J. Atkinson Extreme Networks 3585 Monroe Street Santa Clara, CA 95051 USA
Randall J. Atkinson Extreme Networks 3585 Monroe Street Santa Clara、CA 95051 USA
EMail: rja@extremenetworks.com
Russ White Cisco Systems RTP North Carolina USA
Russ White Cisco Systems RTP North Carolina USA
EMail: riw@cisco.com
Matthew J. Fanto Aegis Data Security Dearborn, MI USA
マシューJ.ファントイージスデータセキュリティDearborn、MI USA
EMail: mfanto@aegisdatasecurity.com