[要約] RFC 6094は、ルーティングプロトコルにおける暗号化認証アルゴリズムの実装要件に関する要約を提供します。この文書の目的は、インターネットエンジニアリングタスクフォース（IETF）によって開発されたルーティングプロトコルで使用される認証メカニズムの現状を把握し、将来のプロトコル設計や既存のプロトコルの改善に役立てることです。利用場面としては、ネットワークエンジニアやプロトコル設計者がセキュアなルーティング環境を構築する際の参考資料として活用されます。関連するRFCとしては、具体的なルーティングプロトコルを定義するRFCや、セキュリティ関連のRFCが挙げられますが、RFC 6094自体はこれらの実装要件を概観するものであり、特定のRFCを直接参照する形ではないため、具体的な関連RFCの番号は文書内で直接指定されていません。
Internet Engineering Task Force (IETF) M. Bhatia
Request for Comments: 6094 Alcatel-Lucent
Category: Informational V. Manral
ISSN: 2070-1721 IP Infusion
February 2011
Summary of Cryptographic Authentication Algorithm Implementation Requirements for Routing Protocols
ルーティングプロトコルの暗号化認証アルゴリズム実装要件の概要
Abstract
概要
The routing protocols Open Shortest Path First version 2 (OSPFv2), Intermediate System to Intermediate System (IS-IS), and Routing Information Protocol (RIP) currently define cleartext and MD5 (Message Digest 5) methods for authenticating protocol packets. Recently, effort has been made to add support for the SHA (Secure Hash Algorithm) family of hash functions for the purpose of authenticating routing protocol packets for RIP, IS-IS, and OSPF.
ルーティングプロトコルのOpen Shortest Path Firstバージョン2（OSPFv2）、中間システム間（IS-IS）、およびルーティング情報プロトコル（RIP）は現在、プロトコルパケットを認証するためのクリアテキストおよびMD5（メッセージダイジェスト5）メソッドを定義しています。最近、RIP、IS-IS、およびOSPFのルーティングプロトコルパケットを認証するために、ハッシュ関数のSHA（Secure Hash Algorithm）ファミリのサポートを追加する努力が行われています。
To encourage interoperability between disparate implementations, it is imperative that we specify the expected minimal set of algorithms, thereby ensuring that there is at least one algorithm that all implementations will have in common.
異種の実装間の相互運用性を促進するために、予想される最小のアルゴリズムセットを指定することが不可欠です。これにより、すべての実装に共通のアルゴリズムが少なくとも1つあることを確認します。
Similarly, RIP for IPv6 (RIPng) and OSPFv3 support IPsec algorithms for authenticating their protocol packets.
同様に、RIP for IPv6（RIPng）およびOSPFv3は、プロトコルパケットを認証するためのIPsecアルゴリズムをサポートしています。
This document examines the current set of available algorithms, with interoperability and effective cryptographic authentication protection being the principal considerations. Cryptographic authentication of these routing protocols requires the availability of the same algorithms in disparate implementations. It is desirable that newly specified algorithms should be implemented and available in routing protocol implementations because they may be promoted to requirements at some future time.
このドキュメントでは、相互運用性と効果的な暗号化認証の保護が主な考慮事項である、利用可能なアルゴリズムの現在のセットを調べます。これらのルーティングプロトコルの暗号化認証では、異なる実装で同じアルゴリズムを使用できる必要があります。新しく指定されたアルゴリズムは実装され、ルーティングプロトコルの実装で使用可能であることが望ましいです。これは、将来的に要件に昇格する可能性があるためです。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントはInternet Standards Trackの仕様ではありません。情報提供を目的として公開されています。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。 IESGによって承認されたすべてのドキュメントが、あらゆるレベルのインターネット標準の候補になるわけではありません。 RFC 5741のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6094.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc6094で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2011 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 Simplified BSD License.
この文書は、BCP 78およびこの文書の発行日に有効なIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction ....................................................3
2. Intermediate System to Intermediate System (IS-IS) ..............4
2.1. Authentication Scheme Selection ............................4
2.2. Authentication Algorithm Selection .........................5
3. Open Shortest Path First Version 2 (OSPFv2) .....................5
3.1. Authentication Scheme Selection ............................6
3.2. Authentication Algorithm Selection .........................6
4. Open Shortest Path First Version 3 (OSPFv3) .....................7
5. Routing Information Protocol Version 2 (RIPv2) ..................7
5.1. Authentication Scheme Selection ............................7
5.2. Authentication Algorithm Selection .........................8
6. Routing Information Protocol for IPv6 (RIPng) ...................8
7. Security Considerations .........................................9
8. Acknowledgements ................................................9
9. References .....................................................10
9.1. Normative References ......................................10
9.2. Informative References ....................................10
Most routing protocols include three different types of authentication schemes: Null authentication, cleartext password, and cryptographic authentication. Null authentication is equivalent to having no authentication scheme at all.
ほとんどのルーティングプロトコルには、Null認証、クリアテキストパスワード、および暗号化認証という3種類の認証方式が含まれています。 Null認証は、認証スキームをまったく持たないことと同じです。
In a cleartext scheme, also known as a "simple password" scheme, the password is exchanged completely unprotected, and anyone with physical access to the network can learn the password and compromise the integrity of the routing domain. The simple password scheme protects against accidental establishment of routing sessions in a given domain, but beyond that it offers no additional protection.
「単純なパスワード」スキームとも呼ばれるクリアテキストスキームでは、パスワードは完全に保護されずに交換され、ネットワークに物理的にアクセスできる人は誰でもパスワードを学習し、ルーティングドメインの整合性を危うくする可能性があります。単純なパスワードスキームは、特定のドメインでルーティングセッションが誤って確立されるのを防ぎますが、それを超えると、追加の保護は提供されません。
In a cryptographic authentication scheme, routers share a secret key that is used to generate a message authentication code for each of the protocol packets. Today, routing protocols that implement message authentication codes often use a Keyed-MD5 [RFC1321] digest. The recent escalating series of attacks on MD5 raise concerns about its remaining useful lifetime.
暗号化認証スキームでは、ルーターは各プロトコルパケットのメッセージ認証コードを生成するために使用される秘密鍵を共有します。今日、メッセージ認証コードを実装するルーティングプロトコルは、Keyed-MD5 [RFC1321]ダイジェストを使用することがよくあります。最近のエスカレートするMD5への一連の攻撃は、残りの有効寿命についての懸念を引き起こします。
These attacks may not necessarily result in direct vulnerabilities for Keyed-MD5 digests as message authentication codes because the colliding message may not correspond to a syntactically correct protocol packet. The known collision, pre-image, and second pre-image attacks [RFC4270] on MD5 may not increase the effectiveness of the key recovery attacks on HMAC-MD5. Regardless, there is a need felt to deprecate MD5 [RFC1321] as the basis for the Hashed Message Authentication Code (HMAC) algorithm in favor of stronger digest algorithms.
衝突するメッセージが構文的に正しいプロトコルパケットに対応していない可能性があるため、これらの攻撃は、メッセージ認証コードとしてのKeyed-MD5ダイジェストに直接的な脆弱性をもたらすとは限りません。 MD5に対する既知の衝突、プリイメージ、および2番目のプリイメージ攻撃[RFC4270]は、HMAC-MD5に対するキー回復攻撃の有効性を向上させない場合があります。いずれにせよ、より強力なダイジェストアルゴリズムを支持して、ハッシュメッセージ認証コード（HMAC）アルゴリズムの基礎としてMD5 [RFC1321]を廃止する必要性が感じられます。
In light of these considerations, there are proposals to replace HMAC-MD5 with keyed HMAC-SHA [SHS] digests where HMAC-MD5 is currently mandated in RIPv2 [RFC2453] IS-IS [ISO] [RFC1195], and Keyed-MD5 in OSPFv2 [RFC2328].
これらの考慮事項に照らして、HMAC-MD5をキー付きHMAC-SHA [SHS]ダイジェストで置き換える提案があり、HMAC-MD5は現在RIPv2 [RFC2453] IS-IS [ISO] [RFC1195]で必須であり、Keyed-MD5はOSPFv2 [RFC2328]。
OSPFv3 [RFC5340] and RIPng [RFC2080] rely on the IPv6 Authentication Header (AH) [RFC4302] and IPv6 Encapsulating Security Payload (ESP) [RFC4303] in order to provide integrity, authentication, and/or confidentiality.
OSPFv3 [RFC5340]およびRIPng [RFC2080]は、IPv6認証ヘッダー（AH）[RFC4302]およびIPv6カプセル化セキュリティペイロード（ESP）[RFC4303]を使用して、整合性、認証、および/または機密性を提供します。
However, the nature of cryptography is that algorithmic improvement is an ongoing process, as is the exploration and refinement of attack vectors. An algorithm believed to be strong today may be demonstrated to be weak tomorrow. Given this, the choice of preferred algorithm should favor the minimization of the likelihood of it being compromised quickly.
ただし、暗号化の性質は、攻撃のベクトルの調査と改良と同様に、アルゴリズムの改善は継続的なプロセスであることです。今日強力であると考えられているアルゴリズムは、明日は弱いことが示される場合があります。これを踏まえると、好ましいアルゴリズムの選択は、それがすぐに危険にさらされる可能性の最小化を優先するはずです。
It should be recognized that preferred algorithm(s) will change over time to adapt to the evolving threats. At any particular time, the mandatory-to-implement algorithm(s) might not be specified in the base protocol specification. As protocols are extended, the preference for presently stronger algorithms presents a problem regarding the question of interoperability of existing and future implementations with respect to standards, and also regarding operational preference for the configuration as deployed.
進化する脅威に適応するために、優先アルゴリズムが時間とともに変化することを認識しておく必要があります。特定の時点で、必須から実装までのアルゴリズムが基本プロトコル仕様で指定されていない場合があります。プロトコルが拡張されると、現在より強力なアルゴリズムの優先順位は、標準に関する既存および将来の実装の相互運用性の問題、および展開された構成の運用優先順位に関する問題を提起します。
It is expected that an implementation should support the changing of security (authentication) keys. Changing the symmetric key used in any HMAC algorithm on a periodic basis is good security practice. Operators need to plan for this.
実装では、セキュリティ（認証）キーの変更をサポートする必要があります。すべてのHMACアルゴリズムで使用される対称鍵を定期的に変更することは、優れたセキュリティ慣行です。オペレーターはこれを計画する必要があります。
Implementations can support in-service key change so that no control packets are lost. During an in-service/in-band key change, more than one key can be active for receiving packets for a session. Some protocols support a key identifier that allows the two peers of a session to have multiple keys simultaneously for a session.
実装はサービス中のキー変更をサポートできるため、制御パケットが失われることはありません。インサービス/インバンドキーの変更中、セッションのパケットを受信するために複数のキーをアクティブにすることができます。一部のプロトコルは、セッションの2つのピアがセッションに対して同時に複数のキーを持つことを可能にするキー識別子をサポートしています。
However, these protocols currently manage keys manually (i.e., via operator intervention) or dynamically based on some timer or security protocol.
ただし、これらのプロトコルは現在、手動で（つまり、オペレーターの介入により）、またはタイマーやセキュリティプロトコルに基づいて動的にキーを管理しています。
The IS-IS specification allows for authentication of its Protocol Data Units (PDUs) via the authentication TLV (TLV 10) in the PDU. The base specification [ISO] had provisions only for cleartext passwords. [RFC5304] extends the authentication capabilities by providing cryptographic authentication for IS-IS PDUs. It mandates support for HMAC-MD5.
IS-IS仕様では、PDUの認証TLV（TLV 10）を介してプロトコルデータユニット（PDU）の認証が可能です。基本仕様[ISO]には、平文パスワードのみの規定がありました。 [RFC5304]は、IS-IS PDUに暗号化認証を提供することにより、認証機能を拡張します。 HMAC-MD5のサポートを義務付けています。
[RFC5310] adds support for the use of any cryptographic hash function for authenticating IS-IS PDUs. In addition to this, [RFC5310] also details how IS-IS can use the HMAC construct along with the Secure Hash Algorithm (SHA) family of cryptographic hash functions to secure IS-IS PDUs.
[RFC5310]は、IS-IS PDUを認証するための暗号化ハッシュ関数の使用のサポートを追加します。これに加えて、[RFC5310]では、IS-ISがHMACコンストラクトと暗号化ハッシュ関数のSecure Hash Algorithm（SHA）ファミリーを使用してIS-IS PDUを保護する方法についても詳しく説明しています。
In order for IS-IS implementations to securely interoperate, they must support one or more authentication schemes in common. This section specifies the preference for standards-conformant IS-IS implementations that use accepted authentication schemes.
IS-IS実装を安全に相互運用するには、共通の1つ以上の認証スキームをサポートする必要があります。このセクションでは、承認済みの認証スキームを使用する標準準拠のIS-IS実装の優先順位を指定します。
The earliest interoperability requirement for authentication as stated by [ISO] [RFC1195] required all implementations to support a
[ISO] [RFC1195]で述べられている認証の最も初期の相互運用性要件は、すべての実装が
cleartext password. This authentication scheme's utility is limited to precluding the accidental introduction of a new IS into a broadcast domain. Operators should not use this scheme, as it provides no protection against an attacker with access to the broadcast domain: anyone can determine the secret password through inspection of the PDU. This mechanism does not provide any significant level of security and should be avoided.
クリアテキストのパスワード。この認証スキームのユーティリティは、ブロードキャストドメインへの新しいISの誤った導入を防ぐことに限定されています。ブロードキャストドメインにアクセスする攻撃者に対する保護を提供しないため、オペレーターはこのスキームを使用しないでください。誰もがPDUの検査を通じて秘密のパスワードを決定できます。このメカニズムは重要なレベルのセキュリティを提供しないため、回避する必要があります。
[RFC5304] defined the cryptographic authentication scheme for IS-IS. HMAC-MD5 was the only algorithm specified; hence, it is mandated. [RFC5310] defined a generic cryptographic scheme and added support for additional algorithms. Implementations should support [RFC5310], as it defines the generic cryptographic authentication scheme.
[RFC5304]は、IS-ISの暗号化認証スキームを定義しました。指定されたアルゴリズムはHMAC-MD5のみでした。したがって、それが義務付けられています。 [RFC5310]は、一般的な暗号化スキームを定義し、追加のアルゴリズムのサポートを追加しました。実装は、[RFC5310]をサポートする必要があります。これは、一般的な暗号認証スキームを定義しているためです。
For IS-IS implementations to securely interoperate, they must have support for one or more authentication algorithms in common.
IS-IS実装が安全に相互運用するには、共通の1つ以上の認証アルゴリズムをサポートする必要があります。
This section details the authentication algorithm requirements for standards-conformant IS-IS implementations.
このセクションでは、標準に準拠したIS-IS実装の認証アルゴリズム要件について詳しく説明します。
The following are the available options for authentication algorithms:
認証アルゴリズムに使用できるオプションは次のとおりです。
o [RFC5304] mandates the use of HMAC-MD5.
o [RFC5304]はHMAC-MD5の使用を義務付けています。
o [RFC5310] does not require a particular algorithm but instead supports any digest algorithm (i.e., cryptographic hash functions).
o [RFC5310]は特定のアルゴリズムを必要とせず、代わりに任意のダイジェストアルゴリズム（つまり、暗号化ハッシュ関数）をサポートします。
As noted earlier, there is a desire to deprecate MD5. IS-IS implementations will likely migrate to an authentication scheme supported by [RFC5310], because it is algorithm agnostic. Possible digest algorithms include SHA-1, SHA-224, SHA-256, SHA-384, and SHA-512. Picking at least one mandatory-to-implement algorithm is imperative to ensuring interoperability.
前述のように、MD5を廃止したいという要望があります。 IS-ISの実装は、アルゴリズムにとらわれないため、[RFC5310]でサポートされる認証スキームに移行する可能性があります。可能なダイジェストアルゴリズムには、SHA-1、SHA-224、SHA-256、SHA-384、およびSHA-512が含まれます。相互運用性を確保するには、少なくとも1つの必須から実装までのアルゴリズムを選択することが不可欠です。
[RFC2328] includes three different types of authentication schemes: Null authentication, cleartext password (defined as "simple password" in [RFC2328]), and cryptographic authentication. Null authentication is semantically equivalent to no authentication.
[RFC2328]には、Null認証、クリアテキストパスワード（[RFC2328]では「単純なパスワード」として定義）、および暗号化認証という3つの異なるタイプの認証スキームが含まれています。ヌル認証は、意味的には認証なしと同等です。
In the cryptographic authentication scheme, the OSPFv2 routers on a common network/subnet are configured with a shared secret that is used to generate a Keyed-MD5 digest for each packet. A monotonically increasing sequence number scheme is used to protect against replay attacks.
暗号化認証スキームでは、共通のネットワーク/サブネット上のOSPFv2ルーターは、各パケットのKeyed-MD5ダイジェストを生成するために使用される共有秘密で構成されます。単調に増加するシーケンス番号スキームは、リプレイアタックから保護するために使用されます。
[RFC5709] adds support for the use of the SHA family of hash algorithms for authentication of OSPFv2 packets.
[RFC5709]は、OSPFv2パケットの認証にハッシュアルゴリズムのSHAファミリを使用するためのサポートを追加します。
For OSPF implementations to securely interoperate, they must have one or more authentication schemes in common.
OSPF実装を安全に相互運用するには、共通の認証スキームが1つ以上必要です。
While all implementations will have Null authentication since it's mandated by [RFC2328], its use is not appropriate in any context where the operator wishes to authenticate OSPFv2 packets in their network.
[RFC2328]によって義務付けられているため、すべての実装でNull認証が行われますが、オペレーターがネットワークでOSPFv2パケットを認証することを希望する状況では、その使用は適切ではありません。
While all implementations will also support a cleartext password since it's mandated by [RFC2328], its use is only appropriate when the operator wants to preclude the accidental introduction of a router into the domain. This scheme is patently not useful when an operator wants to authenticate the OSPFv2 packets.
[RFC2328]で義務付けられているため、すべての実装でもクリアテキストパスワードがサポートされますが、その使用は、オペレーターが誤ってルーターをドメインに導入したくない場合にのみ適切です。オペレーターがOSPFv2パケットを認証したい場合、このスキームは明らかに有用ではありません。
Cryptographic authentication is a mandatory scheme defined in [RFC2328], and all conformant implementations must support this.
暗号化認証は[RFC2328]で定義された必須のスキームであり、すべての適合実装はこれをサポートする必要があります。
For OSPFv2 implementations to securely interoperate, they must support one or more cryptographic authentication algorithms in common.
OSPFv2実装が安全に相互運用するには、共通の1つ以上の暗号化認証アルゴリズムをサポートする必要があります。
The following are the available options for authentication algorithms:
認証アルゴリズムに使用できるオプションは次のとおりです。
o [RFC2328] specifies the use of Keyed-MD5.
o [RFC2328]は、Keyed-MD5の使用を指定しています。
o [RFC5709] specifies the use of HMAC-SHA-1, HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512, and also mandates support for HMAC-SHA-256 (HMAC-SHA-1 is optional).
o [RFC5709]は、HMAC-SHA-1、HMAC-SHA-256、HMAC-SHA-384、およびHMAC-SHA-512の使用を指定し、HMAC-SHA-256のサポートを義務付けています（HMAC-SHA-1はオプションです） ）。
As noted earlier, there is a desire to deprecate MD5. Some alternatives for MD5 are listed in [RFC5709].
前述のように、MD5を廃止したいという要望があります。 MD5のいくつかの代替案が[RFC5709]にリストされています。
Possible digest algorithms include SHA-1, SHA-256, SHA-384, and SHA-512. Picking one mandatory-to-implement algorithm is imperative to ensuring interoperability.
可能なダイジェストアルゴリズムには、SHA-1、SHA-256、SHA-384、SHA-512などがあります。相互運用性を確保するには、実装に必須のアルゴリズムを1つ選択することが不可欠です。
OSPFv3 [RFC5340] relies on the IPv6 Authentication Header (AH) [RFC4302] and IPv6 Encapsulating Security Payload (ESP) [RFC4303] in order to provide integrity, authentication, and/or confidentiality.
OSPFv3 [RFC5340]は、IPv6認証ヘッダー（AH）[RFC4302]およびIPv6カプセル化セキュリティペイロード（ESP）[RFC4303]を使用して、整合性、認証、機密性を提供します。
[RFC4552] mandates the use of ESP for authenticating OSPFv3 packets. The implementations could also provide support for using AH to protect these packets.
[RFC4552]は、OSPFv3パケットの認証にESPの使用を義務付けています。実装は、AHを使用してこれらのパケットを保護するためのサポートも提供できます。
The algorithm requirements for AH and ESP are described in [RFC4835] as follows:
AHとESPのアルゴリズム要件は、[RFC4835]で次のように説明されています。
o [RFC2404] mandates HMAC-SHA-1-96.
o 「ＲＦＣ２４０４」 まんだてｓ ＨまＣーしゃー１ー９６。
o [RFC3566] indicates AES-XCBC-MAC-96 as a "should", but it's likely that this will be mandated at some future time.
o [RFC3566]はAES-XCBC-MAC-96を「推奨」として示していますが、将来的にはこれが義務付けられる可能性があります。
RIPv2, originally specified in [RFC1388] and then in [RFC1723], has been updated and published as STD 56, [RFC2453]. If the Address Family Identifier of the first (and only the first) entry in the RIPv2 message is 0xFFFF, then the remainder of the entry contains the authentication information. The [RFC2453] version of the protocol provides for authenticating packets using a cleartext password (defined as "simple password" in [RFC2453]) not more than 16 octets in length.
元々[RFC1388]、次に[RFC1723]で指定されたRIPv2が更新され、STD 56、[RFC2453]として公開されました。 RIPv2メッセージの最初の（最初の）エントリのアドレスファミリ識別子が0xFFFFの場合、エントリの残りの部分には認証情報が含まれています。プロトコルの[RFC2453]バージョンでは、長さが16オクテット以下のクリアテキストパスワード（[RFC2453]では「単純なパスワード」として定義）を使用してパケットを認証できます。
[RFC2082] added support for Keyed-MD5 authentication, where a digest is appended to the end of the RIP packet. [RFC4822] obsoleted [RFC2082] and added the SHA family of hash algorithms to the list of cryptographic authentications that can be used to protect RIPv2, whereas [RFC2082] previously specified only the use of Keyed-MD5.
[RFC2082] RIPパケットの最後にダイジェストが追加されるKeyed-MD5認証のサポートが追加されました。 [RFC4822]は[RFC2082]を廃止し、ハッシュアルゴリズムのSHAファミリをRIPv2の保護に使用できる暗号化認証のリストに追加しましたが、[RFC2082]は以前にKeyed-MD5の使用のみを指定しました。
For RIPv2 implementations to securely interoperate, they must support one or more authentication schemes in common.
RIPv2実装を安全に相互運用するには、共通の1つ以上の認証方式をサポートする必要があります。
While all implementations will support a cleartext password since it's mandated by [RFC2453], its use is only appropriate when the operator wants to preclude the accidental introduction of a router into the domain. This scheme is patently not useful when an operator wants to authenticate the RIPv2 packets.
[RFC2453]によって義務付けられているため、すべての実装はクリアテキストのパスワードをサポートしますが、その使用は、オペレーターが誤ってルーターをドメインに導入したくない場合にのみ適切です。この方式は、オペレーターがRIPv2パケットを認証する必要がある場合、特許がありません。
[RFC2082] mandates the use of an authentication scheme that uses Keyed-MD5. However, [RFC2082] has been obsoleted by [RFC4822]. Compliant implementations must provide support for an authentication scheme that uses Keyed-MD5 but should recognize that this is superseded by cryptographic authentication as defined in [RFC4822].
[RFC2082]は、Keyed-MD5を使用する認証スキームの使用を義務付けています。ただし、[RFC2082]は[RFC4822]に置き換えられました。準拠した実装は、Keyed-MD5を使用する認証スキームのサポートを提供する必要がありますが、これは[RFC4822]で定義されている暗号化認証によって置き換えられることを認識する必要があります。
Implementations should provide support for [RFC4822], as it specifies the RIPv2 cryptographic authentication schemes.
[RFC4822]はRIPv2暗号化認証スキームを指定しているため、実装は[RFC4822]のサポートを提供する必要があります。
For RIPv2 implementations to securely interoperate, they must support one or more authentication algorithms in common.
RIPv2実装が安全に相互運用するには、共通の1つ以上の認証アルゴリズムをサポートする必要があります。
The following are the available options for authentication algorithms:
認証アルゴリズムに使用できるオプションは次のとおりです。
o [RFC2082] specifies the use of Keyed-MD5.
o [RFC2082]は、Keyed-MD5の使用を指定しています。
o [RFC4822] specifies the use of Keyed-MD5, HMAC-SHA-1, HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512.
o [RFC4822]は、Keyed-MD5、HMAC-SHA-1、HMAC-SHA-256、HMAC-SHA-384、およびHMAC-SHA-512の使用を指定しています。
As noted earlier, there is a desire to deprecate MD5. Some alternatives for MD5 are listed in [RFC4822]. Possible digest algorithms include SHA-1, SHA-256, SHA-384, and SHA-512. Picking one mandatory-to-implement algorithm is imperative to ensuring interoperability.
前述のように、MD5を廃止したいという要望があります。 MD5のいくつかの代替案が[RFC4822]にリストされています。可能なダイジェストアルゴリズムには、SHA-1、SHA-256、SHA-384、SHA-512などがあります。相互運用性を確保するには、実装に必須のアルゴリズムを1つ選択することが不可欠です。
RIPng [RFC2080] relies on the IPv6 Authentication Header (AH) [RFC4302] and IPv6 Encapsulating Security Payload (ESP) [RFC4303] in order to provide integrity, authentication, and/or confidentiality.
RIPng [RFC2080]は、IPv6認証ヘッダー（AH）[RFC4302]およびIPv6カプセル化セキュリティペイロード（ESP）[RFC4303]を使用して、整合性、認証、機密性を提供します。
The algorithm requirements for AH and ESP are described in [RFC4835] as follows:
AHとESPのアルゴリズム要件は、[RFC4835]で次のように説明されています。
o [RFC2404] mandates HMAC-SHA-1-96.
o 「ＲＦＣ２４０４」 まんだてｓ ＨまＣーしゃー１ー９６。
o [RFC3566] indicates AES-XCBC-MAC-96 as a "should", but it's likely that this will be mandated at some future time.
o [RFC3566]はAES-XCBC-MAC-96を「推奨」として示していますが、将来的にはこれが義務付けられる可能性があります。
The cryptographic mechanisms referenced in this document provide only authentication algorithms. These algorithms do not provide confidentiality. Encrypting the content of the packet and thereby providing confidentiality is not considered in the definition of the routing protocols.
このドキュメントで参照されている暗号化メカニズムは、認証アルゴリズムのみを提供します。これらのアルゴリズムは機密性を提供しません。パケットの内容を暗号化して機密性を提供することは、ルーティングプロトコルの定義では考慮されません。
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. The feasibility of attacking the integrity of routing protocol messages protected by keyed digests may be significantly more limited than that of other data; however, preference for one family of algorithms over another may also change independently of the perceived risk to a particular protocol.
HMACの暗号強度は、基礎となるハッシュ関数の暗号強度と、キーのサイズと品質に依存します。キー付きダイジェストによって保護されたルーティングプロトコルメッセージの整合性を攻撃する可能性は、他のデータの場合よりも大幅に制限される可能性があります。ただし、あるアルゴリズムファミリの優先順位は、特定のプロトコルに対する認識されたリスクとは無関係に変化する場合もあります。
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. Operational experience suggests that the lack of periodic rekeying is a source of significant exposure and that the lifespan of shared keys in the network is frequently measured in years.
セキュリティを強化するには、使用するキーを定期的に変更する必要があり、実装では複数のキーを同時に保存して使用できる必要があります。運用上の経験から、定期的な鍵更新の欠如が重大な危険の原因であり、ネットワーク内の共有鍵の寿命は年単位で測定されることが多いことが示唆されています。
While simple password schemes are well represented in the document series and in conformant implementations of the protocols, the inability to offer either integrity or identity protection are sufficient reason to strongly discourage their use.
一連のドキュメントやプロトコルの準拠実装では、単純なパスワードスキームがよく表現されていますが、整合性またはID保護を提供できないことが、その使用を強く妨げる十分な理由です。
This document concerns itself with the selection of cryptographic algorithms for use in the authentication of routing protocol packets being exchanged between adjacent routing processes. The cryptographic algorithms identified in this document are not known to be broken at the current time, and ongoing cryptographic research so far leads us to believe that they will likely remain secure in the foreseeable future. We expect that new revisions of this document will be issued in the future to reflect current thinking on the algorithms that various routing protocols should employ to ensure interoperability between disparate implementations.
このドキュメントは、隣接するルーティングプロセス間で交換されるルーティングプロトコルパケットの認証に使用する暗号化アルゴリズムの選択に関係しています。このドキュメントで特定されている暗号化アルゴリズムは現時点で破られていることは知られていないため、現在進行中の暗号化研究により、近い将来それらが安全であり続けると考えられています。異種の実装間の相互運用性を保証するためにさまざまなルーティングプロトコルが採用すべきアルゴリズムに関する現在の考え方を反映するために、このドキュメントの新しい改訂版が将来発行されることを期待しています。
We would like to thank Joel Jaeggli, Sean Turner, and Adrian Farrel for their comments and feedback on this document, which resulted in significant improvement of the same.
このドキュメントに対するコメントとフィードバックを提供してくれたJoel Jaeggli、Sean Turner、およびAdrian Farrelに感謝します。
[ISO] "Intermediate system to Intermediate system routing information exchange protocol for use in conjunction with the protocol for providing the connectionless-mode network service", ISO/IEC 10589:1992 (ISO 8473).
[ISO]「コネクションレスモードのネットワークサービスを提供するためのプロトコルと組み合わせて使用するための中間システム間中間ルーティング情報交換プロトコル」、ISO / IEC 10589：1992（ISO 8473）。
[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月。
[RFC2080] Malkin, G. and R. Minnear, "RIPng for IPv6", RFC 2080, January 1997.
[RFC2080] Malkin、G。およびR. Minnear、「RIPng for IPv6」、RFC 2080、1997年1月。
[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
[RFC2328] Moy、J。、「OSPFバージョン2」、STD 54、RFC 2328、1998年4月。
[RFC2453] Malkin, G., "RIP Version 2", STD 56, RFC 2453, November 1998.
[RFC2453] Malkin、G。、「RIPバージョン2」、STD 56、RFC 2453、1998年11月。
[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月。
[RFC4835] Manral, V., "Cryptographic Algorithm Implementation Requirements for Encapsulating Security Payload (ESP) and Authentication Header (AH)", RFC 4835, April 2007.
[RFC4835] Manral、V。、「カプセル化セキュリティペイロード（ESP）および認証ヘッダー（AH）の暗号化アルゴリズム実装要件」、RFC 4835、2007年4月。
[RFC5304] Li, T. and R. Atkinson, "IS-IS Cryptographic Authentication", RFC 5304, October 2008.
[RFC5304] Li、T。およびR. Atkinson、「IS-IS Cryptographic Authentication」、RFC 5304、2008年10月。
[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月。
[RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF for IPv6", RFC 5340, July 2008.
[RFC5340] Coltun、R.、Ferguson、D.、Moy、J。、およびA. Lindem、「OSPF for IPv6」、RFC 5340、2008年7月。
[RFC5709] Bhatia, M., Manral, V., Fanto, M., White, R., Barnes, M., Li, T., and R. Atkinson, "OSPFv2 HMAC-SHA Cryptographic Authentication", RFC 5709, October 2009.
[RFC5709] Bhatia、M.、Manral、V.、Fanto、M.、White、R.、Barnes、M.、Li、T。、およびR. Atkinson、「OSPFv2 HMAC-SHA Cryptographic Authentication」、RFC 5709、 2009年10月。
[RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 1992.
[RFC1321] Rivest、R。、「MD5メッセージダイジェストアルゴリズム」、RFC 1321、1992年4月。
[RFC1388] Malkin, G., "RIP Version 2 Carrying Additional Information", RFC 1388, January 1993.
[RFC1388] Malkin、G。、「RIP Version 2 Carrying Additional Information」、RFC 1388、1993年1月。
[RFC1723] Malkin, G., "RIP Version 2 - Carrying Additional Information", RFC 1723, November 1994.
[RFC1723] Malkin、G。、「RIPバージョン2-追加情報の運搬」、RFC 1723、1994年11月。
[RFC2082] Baker, F. and R. Atkinson, "RIP-2 MD5 Authentication", RFC 2082, January 1997.
[RFC2082]ベイカー、F。およびR.アトキンソン、「RIP-2 MD5認証」、RFC 2082、1997年1月。
[RFC2404] Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within ESP and AH", RFC 2404, November 1998.
[RFC2404]マドソン、C。およびR.グレン、「ESPおよびAH内でのHMAC-SHA-1-96の使用」、RFC 2404、1998年11月。
[RFC3566] Frankel, S. and H. Herbert, "The AES-XCBC-MAC-96 Algorithm and Its Use With IPsec", RFC 3566, September 2003.
[RFC3566]フランケルS.およびH.ハーバート、「AES-XCBC-MAC-96アルゴリズムとIPsecでのその使用」、RFC 3566、2003年9月。
[RFC4270] Hoffman, P. and B. Schneier, "Attacks on Cryptographic Hashes in Internet Protocols", RFC 4270, November 2005.
[RFC4270] Hoffman、P.およびB. Schneier、「インターネットプロトコルにおける暗号化ハッシュへの攻撃」、RFC 4270、2005年11月。
[RFC4302] Kent, S., "IP Authentication Header", RFC 4302, December 2005.
[RFC4302]ケント、S。、「IP認証ヘッダー」、RFC 4302、2005年12月。
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005.
[RFC4303]ケント、S。、「IPカプセル化セキュリティペイロード（ESP）」、RFC 4303、2005年12月。
[RFC4552] Gupta, M. and N. Melam, "Authentication/Confidentiality for OSPFv3", RFC 4552, June 2006.
[RFC4552] Gupta、M。およびN. Melam、「Authentication / Confidentiality for OSPFv3」、RFC 4552、2006年6月。
[SHS] "Secure Hash Standard (SHS)", National Institute of Standards and Technology (NIST) FIPS Publication 180-3, October 2008.
[SHS]「Secure Hash Standard（SHS）」、米国連邦情報・技術局（NIST）FIPS Publication 180-3、2008年10月。
Authors' Addresses
著者のアドレス
Manav Bhatia Alcatel-Lucent Bangalore India
Manav Bhatiaアルカテルルーセントバンガロールインド
EMail: manav.bhatia@alcatel-lucent.com
Vishwas Manral IP Infusion 1188 E. Arques Ave. Sunnyvale, CA 94089 USA
Vishwas Maral Pip Infosion 1188 ADアークスAV。サニーベール、94089彼
Phone: 408-400-1900 EMail: vishwas@ipinfusion.com
電話：408-400-1900メール：vishwas@ipinfusion.com