[要約] RFC 5709は、OSPFv2 (Open Shortest Path First Version 2) プロトコルにおけるHMAC-SHA (Hash Message Authentication Code - Secure Hash Algorithm) 暗号化認証の実装に関する文書です。このRFCの目的は、OSPFv2の認証プロセスを強化し、より高度なセキュリティ要件に対応するために、既存の単純なパスワード認証やMD5ベースの認証メカニズムに代わるものとしてHMAC-SHA認証オプションを提供することです。この認証方式は、ネットワーク内でのルーティング情報の交換がより安全に行われるように設計されており、特にセキュリティが重視される環境での利用が想定されています。関連するRFCには、RFC 2328 (OSPF Version 2) やRFC 5340 (OSPF for IPv6) などがあります。
Network Working Group M. Bhatia
Request for Comments: 5709 Alcatel-Lucent
Updates: 2328 V. Manral
Category: Standards Track IP Infusion
M. Fanto
Aegis Data Security
R. White
M. Barnes
Cisco Systems
T. Li
Ericsson
R. Atkinson
Extreme Networks
October 2009
OSPFv2 HMAC-SHA Cryptographic Authentication
OSPFv2 HMAC-SHA暗号化認証
Abstract
概要
This document describes how the National Institute of Standards and Technology (NIST) Secure Hash Standard family of algorithms can be used with OSPF version 2's built-in, cryptographic authentication mechanism. This updates, but does not supercede, the cryptographic authentication mechanism specified in RFC 2328.
このドキュメントでは、国立標準技術研究所（NIST）のSecure Hash Standardファミリのアルゴリズムを、OSPFバージョン2の組み込みの暗号化認証メカニズムで使用する方法について説明します。これは、RFC 2328で指定された暗号化認証メカニズムを更新しますが、優先しません。
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 and License 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. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License.
この文書は、BCP 78およびこの文書の発行日に有効なIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eで説明されているように、簡略化されたBSDライセンスのテキストが含まれている必要があり、BSDライセンスで説明されているように保証なしで提供されます。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
このドキュメントには、2008年11月10日より前に公開または公開されたIETFドキュメントまたはIETFコントリビューションの素材が含まれている場合があります。この素材の一部で著作権を管理している人が、IETFトラストにそのような素材の変更を許可する権利を付与していない可能性がありますIETF標準プロセス外。このような資料の著作権を管理する人から適切なライセンスを取得せずに、このドキュメントをIETF標準プロセス外で変更したり、その派生物をIETF標準プロセス外で作成したりすることはできません。 RFCとして、またはそれを英語以外の言語に翻訳するための出版物。
A variety of risks exist when deploying any routing protocol [Bell89]. This document provides an update to OSPFv2 Cryptographic Authentication, which is specified in Appendix D of RFC 2328. This document does not deprecate or supercede RFC 2328. OSPFv2, itself, is defined in RFC 2328 [RFC2328].
ルーティングプロトコルを展開する場合、さまざまなリスクが存在します[Bell89]。このドキュメントは、RFC 2328の付録Dで指定されているOSPFv2暗号化認証のアップデートを提供します。このドキュメントは、RFC 2328を非推奨または優先しません。OSPFv2自体は、RFC 2328 [RFC2328]で定義されています。
This document adds support for Secure Hash Algorithms (SHA) defined in the US NIST Secure Hash Standard (SHS), which is defined by NIST FIPS 180-2. [FIPS-180-2] includes SHA-1, SHA-224, SHA-256, SHA-384, and SHA-512. The Hashed Message Authentication Code (HMAC) authentication mode defined in NIST FIPS 198 is used [FIPS-198].
このドキュメントでは、NIST FIPS 180-2で定義されているUS NIST Secure Hash Standard（SHS）で定義されているセキュアハッシュアルゴリズム（SHA）のサポートを追加します。 [FIPS-180-2]には、SHA-1、SHA-224、SHA-256、SHA-384、SHA-512が含まれます。 NIST FIPS 198で定義されたハッシュメッセージ認証コード（HMAC）認証モードが使用されます[FIPS-198]。
It is believed that [RFC2104] is mathematically identical to [FIPS-198] and it is also believed that algorithms in [RFC4634] are mathematically identical to [FIPS-180-2].
[RFC2104]は[FIPS-198]と数学的に同一であると考えられており、[RFC4634]のアルゴリズムは[FIPS-180-2]と数学的に同一であるとも考えられています。
The creation of this addition to OSPFv2 was driven by operator requests that they be able to use the NIST SHS family of algorithms in the NIST HMAC mode, instead of being forced to use the Keyed-MD5 algorithm and mode with OSPFv2 Cryptographic Authentication. Cryptographic matters are discussed in more detail in the Security Considerations section of this document.
OSPFv2へのこの追加の作成は、Keyed-MD5アルゴリズムとOSPFv2暗号化認証でのモードの使用を強制されるのではなく、NIST HMACモードでNIST SHSファミリーのアルゴリズムを使用できるというオペレーターの要求によって推進されました。暗号の問題については、このドキュメントの「セキュリティに関する考慮事項」セクションで詳しく説明しています。
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 RFC 2119 [RFC2119].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 RFC 2119 [RFC2119]で説明されているように解釈されます。
All OSPF protocol exchanges can be authenticated. The OSPF packet header (see Appendix A.3.1 of RFC 2328) includes an Authentication Type field and 64 bits of data for use by the appropriate authentication scheme (determined by the Type field).
すべてのOSPFプロトコル交換を認証できます。 OSPFパケットヘッダー（RFC 2328の付録A.3.1を参照）には、認証タイプフィールドと、適切な認証スキーム（タイプフィールドによって決定される）で使用するための64ビットのデータが含まれています。
The authentication type is configurable on a per-interface (or, equivalently, on a per-network/subnet) basis. Additional authentication data is also configurable on a per-interface basis.
認証タイプは、インターフェースごと（または、同等に、ネットワーク/サブネットごと）に構成できます。追加の認証データもインターフェイスごとに設定できます。
OSPF authentication types 0, 1, and 2 are defined by RFC 2328. This document provides an update to RFC 2328 that is only applicable to Authentication Type 2, "Cryptographic Authentication".
OSPF認証タイプ0、1、および2はRFC 2328で定義されています。このドキュメントでは、認証タイプ2、「暗号化認証」にのみ適用されるRFC 2328のアップデートを提供します。
Using this authentication type, a shared secret key is configured in all routers attached to a common network/subnet. For each OSPF protocol packet, the key is used to generate/verify a "message digest" that is appended to the end of the OSPF packet. The message digest is a one-way function of the OSPF protocol packet and the secret key. Since the secret key is never sent over the network in the clear, protection is provided against passive attacks [RFC1704].
この認証タイプを使用して、共通のネットワーク/サブネットに接続されたすべてのルーターで共有秘密鍵が構成されます。 OSPFプロトコルパケットごとに、キーを使用して、OSPFパケットの末尾に付加される「メッセージダイジェスト」を生成/検証します。メッセージダイジェストは、OSPFプロトコルパケットと秘密鍵の一方向の機能です。秘密鍵は平文でネットワークを介して送信されることはないため、パッシブ攻撃に対する保護が提供されます[RFC1704]。
The algorithms used to generate and verify the message digest are specified implicitly by the secret key. This specification discusses the computation of OSPFv2 Cryptographic Authentication data when any of the NIST SHS family of algorithms is used in the Hashed Message Authentication Code (HMAC) mode. Please also see RFC 2328, Appendix D.
メッセージダイジェストの生成と検証に使用されるアルゴリズムは、秘密鍵によって暗黙的に指定されます。この仕様では、NIST SHSファミリーのアルゴリズムがハッシュメッセージ認証コード（HMAC）モードで使用されている場合のOSPFv2暗号化認証データの計算について説明します。 RFC 2328の付録Dもご覧ください。
With the additions in this document, the currently valid algorithms (including mode) for OSPFv2 Cryptographic Authentication include:
このドキュメントに追加された、現在有効なOSPFv2暗号化認証のアルゴリズム（モードを含む）には、次のものが含まれます。
Keyed-MD5 (defined in RFC 2328, Appendix D) HMAC-SHA-1 (defined here) HMAC-SHA-256 (defined here) HMAC-SHA-384 (defined here) HMAC-SHA-512 (defined here)
Keyed-MD5（RFC 2328、付録Dで定義）HMAC-SHA-1（ここで定義）HMAC-SHA-256（ここで定義）HMAC-SHA-384（ここで定義）HMAC-SHA-512（ここで定義）
Of the above, implementations of this specification MUST include support for at least:
上記のうち、この仕様の実装には、少なくとも次のサポートが含まれている必要があります。
HMAC-SHA-256
ＨまＣーしゃー２５６
and SHOULD include support for:
とのサポートを含める必要があります：
HMAC-SHA-1
ＨまＣーしゃー１
and SHOULD also (for backwards compatibility with existing implementations and deployments) include support for:
また、SHOULDは（既存の実装およびデプロイメントとの下位互換性のために）次のサポートを含みます。
Keyed-MD5
キー付きMD5
and MAY also include support for:
また、以下のサポートも含まれる場合があります。
HMAC-SHA-384 HMAC-SHA-512
HMAC-SHA-384 HMAC-SHA-512
An implementation of this specification MUST allow network operators to configure ANY authentication algorithm supported by that implementation for use with ANY given KeyID value that is configured into that OSPFv2 router.
この仕様の実装では、ネットワークオペレーターが、その実装でサポートされている任意の認証アルゴリズムを構成して、そのOSPFv2ルーターに構成されている特定のKeyID値で使用できるようにする必要があります。
The overall cryptographic authentication process defined in Appendix D of RFC 2328 remains unchanged. However, the specific cryptographic details (i.e., SHA rather than MD5, HMAC rather than Keyed-Hash) are defined herein. To reduce the potential for confusion, this section minimises the repetition of text from RFC 2328, Appendix D, which is incorporated here by reference [RFC2328].
RFC 2328の付録Dで定義されている全体的な暗号化認証プロセスは変更されていません。ただし、特定の暗号の詳細（つまり、MD5ではなくSHA、Keyed-HashではなくHMAC）がここで定義されています。混乱の可能性を減らすために、このセクションでは、RFC 2328の付録Dからのテキストの繰り返しを最小限に抑えています。これは、参照によりここに組み込まれています[RFC2328]。
First, following the procedure defined in RFC 2328, Appendix D, select the appropriate OSPFv2 Security Association for use with this packet and set the KeyID field to the KeyID value of that OSPFv2 Security Association.
まず、RFC 2328の付録Dで定義されている手順に従って、このパケットで使用する適切なOSPFv2セキュリティアソシエーションを選択し、KeyIDフィールドをそのOSPFv2セキュリティアソシエーションのKeyID値に設定します。
Second, set the Authentication Type to Cryptographic Authentication, and set the Authentication Data Length field to the length (measured in bytes, not bits) of the cryptographic hash that will be used. When any NIST SHS algorithm is used in HMAC mode with OSPFv2 Cryptographic Authentication, the Authentication Data Length is equal to the normal hash output length (measured in bytes) for the specific NIST SHS algorithm in use. For example, with NIST SHA-256, the Authentication Data Length is 32 bytes.
次に、[認証タイプ]を[暗号化認証]に設定し、[認証データ長]フィールドを、使用される暗号化ハッシュの長さ（ビットではなくバイト単位で測定）に設定します。 OSPFv2暗号化認証を使用したHMACモードでNIST SHSアルゴリズムが使用されている場合、認証データ長は、使用中の特定のNIST SHSアルゴリズムの通常のハッシュ出力長（バイト単位）と同じです。たとえば、NIST SHA-256では、認証データ長は32バイトです。
Third, the 32-bit cryptographic sequence number is set in accordance with the procedures in RFC 2328, Appendix D that are applicable to the Cryptographic Authentication type.
3番目に、32ビットの暗号化シーケンス番号は、暗号化認証タイプに適用可能なRFC 2328、付録Dの手順に従って設定されます。
Fourth, the message digest is then calculated and appended to the OSPF packet, as described below in Section 3.3. The KeyID, Authentication Algorithm, and Authentication Key to be used for calculating the digest are all components of the selected OSPFv2 Security Association. Input to the authentication algorithm consists of the OSPF packet and the secret key.
次に、メッセージダイジェストが計算されて、OSPFパケットに追加されます。ダイジェストの計算に使用されるKeyID、認証アルゴリズム、および認証キーは、選択されたOSPFv2セキュリティアソシエーションのすべてのコンポーネントです。認証アルゴリズムへの入力は、OSPFパケットと秘密鍵で構成されます。
This document uses the term OSPFv2 Security Association (OSPFv2 SA) to refer to the authentication key information defined in Section D.3 of RFC 2328. The OSPFv2 protocol does not include an in-band mechanism to create or manage OSPFv2 Security Associations. The parameters of an OSPFv2 Security Association are updated to be:
このドキュメントでは、OSPFv2セキュリティアソシエーション（OSPFv2 SA）という用語を使用して、RFC 2328のセクションD.3で定義されている認証キー情報を指します。OSPFv2プロトコルには、OSPFv2セキュリティアソシエーションを作成または管理するインバンドメカニズムは含まれていません。 OSPFv2セキュリティアソシエーションのパラメータは、次のように更新されます。
Key Identifier (KeyID) This is an 8-bit unsigned value used to uniquely identify an OSPFv2 SA and is configured either by the router administrator (or, in the future, possibly by some key management protocol specified by the IETF). The receiver uses this to locate the appropriate OSPFv2 SA to use. The sender puts this KeyID value in the OSPF packet based on the active OSPF configuration.
鍵識別子（KeyID）これは、OSPFv2 SAを一意に識別するために使用される8ビットの符号なしの値であり、ルーター管理者（または将来的には、IETFによって指定されたいくつかの鍵管理プロトコル）によって構成されます。レシーバーはこれを使用して、使用する適切なOSPFv2 SAを見つけます。送信者は、アクティブなOSPF構成に基づいて、このKeyID値をOSPFパケットに入れます。
Authentication Algorithm This indicates the authentication algorithm (and also the cryptographic mode, such as HMAC) to be used. This information SHOULD never be sent over the wire in cleartext form. At present, valid values are Keyed-MD5, HMAC-SHA-1, HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512.
認証アルゴリズムこれは、使用する認証アルゴリズム（およびHMACなどの暗号モード）を示します。この情報は、クリアテキスト形式でネットワーク経由で送信してはなりません。現在、有効な値はKeyed-MD5、HMAC-SHA-1、HMAC-SHA-256、HMAC-SHA-384、およびHMAC-SHA-512です。
Authentication Key This is the cryptographic key used for cryptographic authentication with this OSPFv2 SA. This value SHOULD never be sent over the wire in cleartext form. This is noted as "K" in Section 3.3 below.
認証キーこれは、このOSPFv2 SAでの暗号化認証に使用される暗号化キーです。この値は、クリアテキスト形式でネットワーク経由で送信してはいけません（SHOULD）。これは、以下のセクション3.3で「K」と示されています。
Key Start Accept The time that this OSPF router will accept packets that have been created with this OSPF Security Association.
Key Start AcceptこのOSPFルータが、このOSPFセキュリティアソシエーションで作成されたパケットを受け入れる時間。
Key Start Generate The time that this OSPF router will begin using this OSPF Security Association for OSPF packet generation.
Key Start GenerateこのOSPFルーターがこのOSPF Security Associationを使用してOSPFパケットを生成する時間。
Key Stop Generate The time that this OSPF router will stop using this OSPF Security Association for OSPF packet generation.
キーストップの生成このOSPFルータがOSPFパケット生成のためにこのOSPFセキュリティアソシエーションの使用を停止する時間。
Key Stop Accept The time that this OSPF router will stop accepting packets generated with this OSPF Security Association.
Key Stop AcceptこのOSPFルーターが、このOSPFセキュリティアソシエーションで生成されたパケットの受け入れを停止する時間。
In order to achieve smooth key transition, KeyStartAccept SHOULD be less than KeyStartGenerate and KeyStopGenerate SHOULD be less than KeyStopAccept. If KeyStopGenerate and KeyStopAccept are left unspecified, the key's lifetime is infinite. When a new key replaces an old, the KeyStartGenerate time for the new key MUST be less than or equal to the KeyStopGenerate time of the old key.
スムーズなキー遷移を実現するために、KeyStartAcceptはKeyStartGenerateより小さく、KeyStopGenerateはKeyStopAcceptより小さくする必要があります。 KeyStopGenerateおよびKeyStopAcceptが指定されていない場合、キーの有効期間は無限です。新しいキーが古いキーを置き換えるとき、新しいキーのKeyStartGenerate時間は古いキーのKeyStopGenerate時間以下でなければなりません。
Key storage SHOULD persist across a system restart, warm or cold, to avoid operational issues. In the event that the last key associated with an interface expires, it is unacceptable to revert to an unauthenticated condition, and not advisable to disrupt routing. Therefore, the router should send a "last Authentication Key expiration" notification to the network manager and treat the key as having an infinite lifetime until the lifetime is extended, the key is deleted by network management, or a new key is configured.
運用上の問題を回避するために、キーストレージは、システムの再起動（ウォームまたはコールド）を通じて維持する必要があります。インターフェイスに関連付けられた最後のキーが期限切れになった場合、認証されていない状態に戻すことは受け入れられず、ルーティングを中断することはお勧めできません。したがって、ルータは「最終認証キーの有効期限」通知をネットワークマネージャに送信し、ライフタイムが延長されるか、ネットワーク管理によってキーが削除されるか、新しいキーが設定されるまで、キーを無期限のライフタイムとして扱う必要があります。
This describes the computation of the Authentication Data value when any NIST SHS algorithm is used in the HMAC mode with OSPFv2 Cryptographic Authentication.
これは、OSPFv2暗号化認証を使用するHMACモードでNIST SHSアルゴリズムが使用されている場合の認証データ値の計算について説明しています。
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).
Hは特定のハッシュアルゴリズムです（SHA-256など）。
K is the Authentication Key for the OSPFv2 security association.
Kは、OSPFv2セキュリティアソシエーションの認証キーです。
Ko is the cryptographic key used with the hash algorithm.
Koは、ハッシュアルゴリズムで使用される暗号化キーです。
B is the block size of H, measured in octets rather than bits. Note well that B is the internal block size, not the hash size.
BはHのブロックサイズで、ビットではなくオクテットで測定されます。 Bはハッシュサイズではなく、内部ブロックサイズであることに注意してください。
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.
Opadは、16進値0x5cをB回繰り返したものです。
Ipad is the hexadecimal value 0x36 repeated B times.
Ipadは、16進値0x36をB回繰り返したものです。
Apad is the hexadecimal value 0x878FE1F3 repeated (L/4) times.
Apadは、16進値0x878FE1F3を（L / 4）回繰り返したものです。
Implementation note: This definition of Apad means that Apad is always the same length as the hash output.
実装メモ：このApadの定義は、Apadが常にハッシュ出力と同じ長さであることを意味します。
(1) PREPARATION OF KEY In this application, Ko is always L octets long.
（1）キーの準備このアプリケーションでは、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 First, the OSPFv2 packet's Authentication Trailer (which is the appendage described in RFC 2328, Section D.4.3, Page 233, items (6)(a) and (6)(d)) is filled with the value Apad, and the Authentication Type field is set to 2.
（2）FIRST-HASH最初に、OSPFv2パケットの認証トレーラー（RFC 2328、セクションD.4.3、ページ233、項目（6）（a）および（6）（d）で説明されている付属物）に、値はApad、認証タイプフィールドは2に設定されています。
Then, a First-Hash, also known as the inner hash, is computed as follows:
次に、内部ハッシュとも呼ばれるFirst-Hashが次のように計算されます。
First-Hash = H(Ko XOR Ipad || (OSPFv2 Packet))
First-Hash = H（Ko XOR Ipad ||（OSPFv2パケット））
Implementation Notes: Note that the First-Hash above includes the Authentication Trailer containing the Apad value, as well as the OSPF packet, as per RFC 2328, Section D.4.3.
実装上の注意：上記の最初のハッシュには、RFC 2328のセクションD.4.3に従って、Apad値とOSPFパケットを含む認証トレーラーが含まれていることに注意してください。
The definition of Apad (above) ensures it is always the same length as the hash output. This is consistent with RFC 2328. The "(OSPFv2 Packet)" mentioned in the First-Hash (above) does include the OSPF Authentication Trailer.
Apad（上記）の定義により、ハッシュ出力と常に同じ長さになります。これはRFC 2328と一致しています。First-Hash（上記）で述べた「（OSPFv2パケット）」には、OSPF認証トレーラーが含まれています。
The digest length for SHA-1 is 20 bytes; for SHA-256, 32 bytes; for SHA-384, 48 bytes; and for SHA-512, 64 bytes.
SHA-1のダイジェスト長は20バイトです。 SHA-256の場合、32バイト。 SHA-384の場合、48バイト。 SHA-512の場合は64バイト。
(3) SECOND-HASH Then a Second-Hash, also known as the outer hash, is computed as follows:
（3）SECOND-HASH次に、外部ハッシュとも呼ばれる第2ハッシュが次のように計算されます。
Second-Hash = H(Ko XOR Opad || First-Hash)
2番目のハッシュ= H（Ko XOR Opad || First-Hash）
(4) RESULT The resulting Second-Hash becomes the Authentication Data that is sent in the Authentication Trailer of the OSPFv2 packet. The length of the Authentication Trailer is always identical to the message digest size of the specific hash function H that is being used.
（4）結果結果のSecond-Hashは、OSPFv2パケットの認証トレーラーで送信される認証データになります。認証トレーラーの長さは、使用されている特定のハッシュ関数Hのメッセージダイジェストサイズと常に同じです。
This also means that the use of hash functions with larger output sizes will also increase the size of the OSPFv2 packet as transmitted on the wire.
これは、出力サイズが大きいハッシュ関数を使用すると、回線上で送信されるOSPFv2パケットのサイズも大きくなることも意味します。
Implementation Note: RFC 2328, Appendix D specifies that the Authentication Trailer is not counted in the OSPF packet's own Length field, but is included in the packet's IP Length field.
実装メモ：RFC 2328の付録Dでは、認証トレーラーはOSPFパケット自体の長さフィールドではカウントされず、パケットのIP長さフィールドに含まれることが指定されています。
Message verification follows the procedure defined in RFC 2328, except that the cryptographic calculation of the message digest follows the procedure in Section 3.3 above when any NIST SHS algorithm in the HMAC mode is in use. Kindly recall that the cryptographic algorithm/mode in use is indicated implicitly by the KeyID of the received OSPFv2 packet.
メッセージの検証はRFC 2328で定義された手順に従いますが、HMACモードのNIST SHSアルゴリズムが使用されている場合、メッセージダイジェストの暗号計算は上記のセクション3.3の手順に従います。使用中の暗号化アルゴリズム/モードは、受信したOSPFv2パケットのKeyIDによって暗黙的に示されることを思い出してください。
Implementation Notes: One must save the received digest value before calculating the expected digest value, so that after that calculation the received value can be compared with the expected value to determine whether to accept that OSPF packet.
実装上の注意：予想されるダイジェスト値を計算する前に、受信したダイジェスト値を保存する必要があります。これにより、その計算後に、受信した値を期待値と比較して、そのOSPFパケットを受け入れるかどうかを判断できます。
RFC 2328, Section D.4.3 (6) (c) should be read very closely prior to implementing the above. With SHA algorithms in HMAC mode, Apad is placed where the MD5 key would be put if Keyed-MD5 were in use.
RFC 2328、セクションD.4.3（6）（c）は、上記を実装する前に非常によく読む必要があります。 HMACモードのSHAアルゴリズムでは、Keyed-MD5が使用されている場合にMD5キーが配置される場所にApadが配置されます。
Using KeyIDs makes changing the active OSPFv2 SA convenient. An implementation can choose to associate a lifetime with each OSPFv2 SA and can thus automatically switch to a different OSPFv2 SA based on the lifetimes of the configured OSPFv2 SA(s).
KeyIDを使用すると、アクティブなOSPFv2 SAを簡単に変更できます。実装では、各OSPFv2 SAにライフタイムを関連付けることを選択できるため、構成されたOSPFv2 SAのライフタイムに基づいて、異なるOSPFv2 SAに自動的に切り替えることができます。
After changing the active OSPFv2 SA, the OSPF sender will use the (different) KeyID value associated with the newly active OSPFv2 SA. The receiver will use this new KeyID to select the appropriate (new) OSPFv2 SA to use with the received OSPF packet containing the new KeyID value.
アクティブなOSPFv2 SAを変更した後、OSPF送信側は新しくアクティブになったOSPFv2 SAに関連付けられた（異なる）KeyID値を使用します。レシーバーはこの新しいKeyIDを使用して、新しいKeyID値を含む受信したOSPFパケットで使用する適切な（新しい）OSPFv2 SAを選択します。
Because the KeyID field is present, the receiver does not need to try all configured OSPFv2 Security Associations with any received OSPFv2 packet. This can mitigate some of the risks of a Denial-of-Service (DoS) attack on the OSPF instance, but does not entirely prevent all conceivable DoS attacks. For example, an on-link adversary still could generate OSPFv2 packets that are syntactically valid but that contain invalid Authentication Data, thereby forcing the receiver(s) to perform expensive cryptographic computations to discover that the packets are invalid.
KeyIDフィールドが存在するため、受信者は、受信したOSPFv2パケットを使用して、構成されているすべてのOSPFv2セキュリティアソシエーションを試行する必要はありません。これにより、OSPFインスタンスに対するサービス拒否（DoS）攻撃のリスクの一部を軽減できますが、考えられるすべてのDoS攻撃を完全に防ぐことはできません。たとえば、オンリンクの攻撃者は引き続き、構文的には有効であるが無効な認証データを含むOSPFv2パケットを生成する可能性があります。これにより、受信者は高価な暗号計算を実行して、パケットが無効であることを発見するよう強制されます。
This document enhances the security of the OSPFv2 routing protocol by adding, to the existing OSPFv2 Cryptographic Authentication method, support for the algorithms defined in the NIST Secure Hash Standard (SHS) using the Hashed Message Authentication Code (HMAC) mode, and by adding support for the Hashed Message Authentication Code (HMAC) mode.
このドキュメントは、既存のOSPFv2暗号化認証方式に、ハッシュメッセージ認証コード（HMAC）モードを使用してNISTセキュアハッシュ標準（SHS）で定義されたアルゴリズムのサポートを追加し、サポートを追加することにより、OSPFv2ルーティングプロトコルのセキュリティを強化しますハッシュメッセージ認証コード（HMAC）モードの場合。
This provides several alternatives to the existing Keyed-MD5 mechanism. There are published concerns about the overall strength of the MD5 algorithm ([Dobb96a], [Dobb96b], [Wang04]). While those published concerns apply to the use of MD5 in other modes (e.g., use of MD5 X.509v3/PKIX digital certificates), they are not an attack upon Keyed-MD5, which is what OSPFv2 specified in RFC 2328. There are also published concerns about the SHA algorithm [Wang05] and also concerns about the MD5 and SHA algorithms in the HMAC mode ([RR07], [RR08]). Separately, some organisations (e.g., the US government) prefer NIST algorithms, such as the SHA family, over other algorithms for local policy reasons.
これにより、既存のKeyed-MD5メカニズムに対するいくつかの代替手段が提供されます。 MD5アルゴリズムの全体的な強さに関する懸念が公開されています（[Dobb96a]、[Dobb96b]、[Wang04]）。これらの公開された懸念事項は他のモードでのMD5の使用（たとえば、MD5 X.509v3 / PKIXデジタル証明書の使用）に適用されますが、RFC 2328で指定されているOSPFv2であるKeyed-MD5への攻撃ではありません。 SHAアルゴリズムに関する公開された懸念[Wang05]、およびHMACモードでのMD5およびSHAアルゴリズムに関する懸念（[RR07]、[RR08]）。それとは別に、一部の組織（米国政府など）は、ローカルポリシー上の理由から、SHAファミリなどのNISTアルゴリズムを他のアルゴリズムよりも優先しています。
The value Apad is used here primarily for consistency with IETF specifications for HMAC-SHA authentication of RIPv2 SHA [RFC4822] and IS-IS SHA [RFC5310] and to minimise OSPF protocol processing changes in Section D.4.3 of RFC 2328 [RFC2328].
ここで値Apadは、主にRIPv2 SHA [RFC4822]およびIS-IS SHA [RFC5310]のHMAC-SHA認証のIETF仕様との整合性を保ち、RFC 2328 [RFC2328]のセクションD.4.3でのOSPFプロトコル処理の変更を最小限に抑えるために使用されます。
The quality of the security provided by the Cryptographic Authentication option depends completely on the strength of the cryptographic algorithm and cryptographic mode in use, the strength of the key being used, and the correct implementation of the security mechanism in all communicating OSPF implementations. Accordingly, the use of high assurance development methods is recommended. It also requires that all parties maintain the secrecy of the shared secret key. [RFC4086] provides guidance on methods for generating cryptographically random bits.
暗号化認証オプションによって提供されるセキュリティの品質は、使用中の暗号化アルゴリズムと暗号化モードの強度、使用されているキーの強度、および通信しているすべてのOSPF実装におけるセキュリティメカニズムの正しい実装に完全に依存します。したがって、高保証の開発方法の使用が推奨されます。また、すべての関係者が共有秘密鍵の秘密を保持することも必要です。 [RFC4086]は、暗号的にランダムなビットを生成する方法に関するガイダンスを提供します。
This mechanism is vulnerable to a replay attack by any on-link node. An on-link node could record a legitimate OSPF packet sent on the link, then replay that packet at the next time the recorded OSPF packet's sequence number is valid. This replay attack could cause significant routing disruptions within the OSPF domain.
このメカニズムは、リンク上のノードによるリプレイ攻撃に対して脆弱です。リンク上のノードは、リンク上で送信された正当なOSPFパケットを記録し、次に記録されたOSPFパケットのシーケンス番号が有効になったときにそのパケットを再生できます。このリプレイ攻撃により、OSPFドメイン内でルーティングが大幅に中断する可能性があります。
Ideally, for example, to prevent the preceding attack, each OSPF Security Association would be replaced by a new and different OSPF Security Association before any sequence number were reused. As of the date this document was published, no form of automated key management has been standardised for OSPF. So, as of the date this document was published, common operational practice has been to use the same OSPF Authentication Key for very long periods of time. This operational practice is undesirable for many reasons. Therefore, it is clearly desirable to develop and standardise some automated key-management mechanism for OSPF.
たとえば、前述の攻撃を防ぐために、理想的には、各OSPFセキュリティアソシエーションは、シーケンス番号が再利用される前に、新しい異なるOSPFセキュリティアソシエーションに置き換えられます。このドキュメントの発行日現在、OSPF用に自動化されたキー管理の形式は標準化されていません。したがって、このドキュメントの発行日以降、一般的な運用慣行では、同じOSPF認証キーを非常に長期間使用するようになっています。この運用慣行は、多くの理由で望ましくありません。したがって、OSPFのいくつかの自動キー管理メカニズムを開発して標準化することが明らかに望ましいです。
Because all of the currently specified algorithms use symmetric cryptography, one cannot authenticate precisely which OSPF router sent a given packet. However, one can authenticate that the sender knew the OSPF Security Association (including the OSPFv2 SA's parameters) currently in use.
現在指定されているアルゴリズムはすべて対称暗号を使用しているため、特定のパケットを送信したOSPFルーターを正確に認証することはできません。ただし、送信者が現在使用中のOSPFセキュリティアソシエーション（OSPFv2 SAのパラメーターを含む）を知っていることを認証できます。
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 the routing system.
ルーティングプロトコルには秘密にしておく必要のない情報が含まれているため、プライバシーは必須ではありません。ただし、プロトコル内のメッセージの認証は、意図的に誤った情報をルーティングシステムに挿入することにより、攻撃者がルーティングシステムを危険にさらすリスクを減らすために重要です。
The technology in this document enhances an authentication mechanism for OSPFv2. The mechanism described here is not perfect and need not be perfect. Instead, this mechanism represents a significant increase in the work function of an adversary attacking OSPFv2, as compared with plain-text authentication or null authentication, while not causing undue implementation, deployment, or operational complexity. Denial-of-Service attacks are not generally preventable in a useful networking protocol [VK83].
このドキュメントのテクノロジーは、OSPFv2の認証メカニズムを強化します。ここで説明するメカニズムは完全ではなく、完全である必要もありません。代わりに、このメカニズムは、プレーンテキスト認証またはヌル認証と比較して、攻撃者の攻撃しているOSPFv2の作業機能を大幅に増加させ、過度の実装、展開、または運用の複雑さを引き起こしません。サービス拒否攻撃は、有用なネットワーキングプロトコル[VK83]では一般に防止できません。
Because of implementation considerations, including the need for backwards compatibility, this specification uses the same mechanism as specified in RFC 2328 and limits itself to adding support for additional cryptographic hash functions. Also, some large network operators have indicated they prefer to retain the basic mechanism defined in RFC 2328, rather than migrate to IP Security, due to deployment and operational considerations. If all the OSPFv2 routers supported IPsec, then IPsec tunnels could be used in lieu of this mechanism [RFC4301]. This would, however, relegate the topology to point-to-point adjacencies over the mesh of IPsec tunnels.
後方互換性の必要性などの実装上の考慮事項のため、この仕様ではRFC 2328で指定されているのと同じメカニズムを使用し、追加の暗号化ハッシュ関数のサポートの追加に限定しています。また、一部の大規模なネットワークオペレーターは、配備と運用上の考慮事項により、IPセキュリティに移行するのではなく、RFC 2328で定義された基本的なメカニズムを維持することを好むと述べています。すべてのOSPFv2ルーターがIPsecをサポートしている場合、このメカニズムの代わりにIPsecトンネルを使用できます[RFC4301]。ただし、これにより、トポロジがIPsecトンネルのメッシュを介したポイントツーポイント隣接に委任されます。
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. Use of full digital signatures would enable precise authentication of the OSPF router originating each OSPF link-state advertisement, and thereby provide much stronger integrity protection for the OSPF routing domain.
より強力な認証が必要であると考えられる場合、完全なデジタル署名[RFC2154]の使用は真剣に検討する必要のあるアプローチになります。完全なデジタル署名を使用すると、各OSPFリンクステートアドバタイズメントを発信するOSPFルーターの正確な認証が可能になり、OSPFルーティングドメインの完全性が大幅に保護されます。
The OSPF Authentication Codes registry entry for Cryptographic Authentication (Registry Code 2) has been updated to refer to this document as well as to RFC 2328.
暗号化認証（レジストリコード2）のOSPF認証コードレジストリエントリが更新され、このドキュメントおよびRFC 2328を参照するようになりました。
The authors would 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に感謝します。
David Black, Nevil Brownlee, Acee Lindem, and Hilarie Orman (in alphabetical order by last name) provided feedback on earlier versions of this document. That feedback has greatly improved both the technical content and the readability of the current document.
David Black、Nevil Brownlee、Acee Lindem、およびHilarie Orman（姓のアルファベット順）が、このドキュメントの以前のバージョンに関するフィードバックを提供しました。そのフィードバックにより、技術的な内容と現在のドキュメントの読みやすさが大幅に改善されました。
Henrik Levkowetz's Internet Draft tools were very helpful in preparing this document and are much appreciated.
Henrik Levkowetzのインターネットドラフトツールは、このドキュメントの作成に非常に役立ち、高く評価されています。
[FIPS-180-2] US National Institute of Standards & Technology, "Secure Hash Standard (SHS)", FIPS PUB 180-2, August 2002.
[FIPS-180-2]米国国立標準技術研究所、「Secure Hash Standard（SHS）」、FIPS PUB 180-2、2002年8月。
[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月。
[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月。
[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
[RFC2328] Moy、J。、「OSPFバージョン2」、STD 54、RFC 2328、1998年4月。
[Bell89] Bellovin, S., "Security Problems in the TCP/IP Protocol Suite", ACM Computer Communications Review, Volume 19, Number 2, pp. 32-48, April 1989.
[Bell89] Bellovin、S。、「TCP / IPプロトコルスイートのセキュリティ問題」、ACM Computer Communications Review、Volume 19、Number 2、32-48ページ、1989年4月。
[Dobb96a] Dobbertin, H, "Cryptanalysis of MD5 Compress", Technical Report, 2 May 1996. (Presented at the Rump Session of EuroCrypt 1996.)
[Dobb96a] Dobbertin、H、「MD5 Compressの暗号解読」、テクニカルレポート、1996年5月2日。（EuroCrypt 1996のランプセッションで発表）
[Dobb96b] Dobbertin, H, "The Status of MD5 After a Recent Attack", CryptoBytes, Vol. 2, No. 2, Summer 1996.
[Dobb96b] Dobbertin、H、「最近の攻撃後のMD5のステータス」、CryptoBytes、Vol。 2、2、1996年夏。
[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月。
[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月。
[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., 3rd, Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, June 2005.
[RFC4086] Eastlake、D.、3rd、Schiller、J。、およびS. Crocker、「Randomness Requirements for Security」、BCP 106、RFC 4086、2005年6月。
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[RFC4301] Kent、S。およびK. Seo、「インターネットプロトコルのセキュリティアーキテクチャ」、RFC 4301、2005年12月。
[RFC4634] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms (SHA and HMAC-SHA)", RFC 4634, July 2006.
[RFC4634] Eastlake 3rd、D。およびT. Hansen、「US Secure Hash Algorithms（SHA and HMAC-SHA）」、RFC 4634、2006年7月。
[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月。
[RFC5310] Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R., and M. Fanto, "IS-IS Generic Cryptographic Authentication", RFC 5310, February 2009.
[RFC5310] Bhatia、M.、Manral、V.、Li、T.、Atkinson、R.、White、R。、およびM. Fanto、「IS-IS Generic Cryptographic Authentication」、RFC 5310、2009年2月。
[RR07] Rechberger, C. and V. Rijmen, "On Authentication with HMAC and Non-random Properties", Financial Cryptography and Data Security, Lecture Notes in Computer Science, Volume 4886/2008, Springer-Verlag, Berlin, December 2007.
[RR07] Rechberger、C。およびV. Rijmen、「HMACおよび非ランダムプロパティによる認証について」、金融暗号化およびデータセキュリティ、コンピュータサイエンスの講義ノート、ボリューム4886/2008、Springer-Verlag、ベルリン、2007年12月。
[RR08] Rechberger, C. and V. Rijmen, "New Results on NMAC/HMAC when Instantiated with Popular Hash Functions", Journal of Universal Computer Science, Volume 14, Number 3, pp. 347-376, 1 February 2008.
[RR08] Rechberger、C。およびV. Rijmen、「人気のハッシュ関数でインスタンス化されたときのNMAC / HMACの新しい結果」、Universal Computer Scienceジャーナル、14巻、3号、347〜376ページ、2008年2月1日。
[VK83] Voydock, V. and S. Kent, "Security Mechanisms in High-level Networks", ACM Computing Surveys, Vol. 15, No. 2, June 1983.
[VK83] Voydock、V。およびS.ケント、「高レベルネットワークのセキュリティメカニズム」、ACM Computing Surveys、Vol。 15、No。2、1983年6月。
[Wang04] Wang, X., et alia, "Collisions for Hash Functions MD4,
MD5, HAVAL-128, and RIPEMD", August 2004, IACR,
http://eprint.iacr.org/2004/199
[Wang05] Wang, X., et alia, "Finding Collisions in the Full SHA-1" Proceedings of Crypto 2005, Lecture Notes in Computer Science, Volume 3621, pp. 17-36, Springer-Verlag, Berlin, August 31, 2005.
[Wang05] Wang、X.、alia、 "Finding Collisions in the Full SHA-1" Proceedings of Crypto 2005、Lecture Notes in Computer Science、Volume 3621、pp。17-36、Springer-Verlag、Berlin、August 31 2005年
Authors' Addresses
著者のアドレス
Manav Bhatia Alcatel-Lucent Bangalore, India
Manav Bhatiaアルカテルルーセントバンガロール、インド
EMail: manav.bhatia@alcatel-lucent.com
Vishwas Manral IP Infusion Almora, Uttarakhand India
Vishwas Maral Pip Infosionアルモラ、ウッタラーカンド州インド
EMail: vishwas@ipinfusion.com
Matthew J. Fanto Aegis Data Security Dearborn, MI USA
マシューJ.ファントイージスデータセキュリティDearborn、MI USA
EMail: mfanto@aegisdatasecurity.com Russ I. White Cisco Systems 7025 Kit Creek Road P.O. Box 14987 RTP, NC 27709 USA
メール：mfanto@aegisdatasecurity.com Russ I. White Cisco Systems 7025 Kit Creek Road P.O.ボックス14987 RTP、NC 27709米国
EMail: riw@cisco.com
M. Barnes Cisco Systems 225 West Tasman Drive San Jose, CA 95134 USA
M.バーンズシスコシステムズ225 West Tasman Drive San Jose、CA 95134 USA
EMail: mjbarnes@cisco.com
Tony Li Ericsson 300 Holger Way San Jose, CA 95134 USA
Tony Li Ericsson 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
Phone: +1 (408) 579-2800
EMail: rja@extremenetworks.com