RFC2082 日本語訳
2082 RIP-2 MD5 Authentication. F. Baker, R. Atkinson. January 1997. (Format: TXT=25436 bytes) (Obsoleted by RFC4822) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group F. Baker
Request for Comments: 2082 R. Atkinson
Category: Standards Track Cisco Systems
January 1997
コメントを求めるワーキンググループF.ベイカー要求をネットワークでつないでください: 2082年のR.アトキンソンカテゴリ: 標準化過程シスコシステムズ1997年1月
RIP-2 MD5 Authentication
裂け目-2MD5認証
Status of this Memo
この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.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Table of Contents
目次
1 Use of Imperatives ........................................... 1 2 Introduction ................................................. 2 3 Implementation Approach ...................................... 3 3.1 RIP-2 PDU Format ........................................... 3 3.2 Processing Algorithm ....................................... 5 3.2.1 Message Generation ....................................... 6 3.2.2 Message Reception ........................................ 7 4 Management Procedures ........................................ 7 4.1 Key Management Requirements ................................ 7 4.2 Key Management Procedures .................................. 8 4.3 Pathological Cases ......................................... 9 5 Conformance Requirements ..................................... 9 6 Acknowledgments .............................................. 10 7 References ................................................... 10 8 Security Considerations ...................................... 11 9 Chairman's Address ........................................... 11 10 Authors' Addresses .......................................... 12
1 命令の使用… 1 2序論… 2 3実装アプローチ… 3 3.1 裂け目-2PDU形式… 3 3.2処理アルゴリズム… 5 3.2 .1メッセージ世代… 6 3.2 .2 メッセージレセプション… 7 4の管理手順… 7 4.1 Key Management要件… 7 4.2 Key Management手順… 8 4.3の病理学的なケース… 9 5の順応要件… 9 6の承認… 10 7つの参照箇所… 10 8 セキュリティ問題… 11 9 委員長のアドレス… 11 10人の作者のアドレス… 12
1. Use of Imperatives
1. 命令の使用
Throughout this document, the words that are used to define the significance of particular requirements are capitalized. These words are:
このドキュメント中では、特定の要件の意味を定義するのに使用される単語は大文字で書かれます。 これらの単語は以下の通りです。
MUST
必須
This word or the adjective "REQUIRED" means that the item is an
absolute requirement of this specification.
「必要である」というこの単語か形容詞が、項目がこの仕様に関する絶対条件であることを意味します。
Baker & Atkinson Standards Track [Page 1] RFC 2082 RIP-2 MD5 Authentication January 1997
1997年のベイカーとアトキンソン標準化過程[1ページ]RFC2082MD5認証1月2日裂け目-
MUST NOT
必須NOT
This phrase means that the item is an absolute prohibition of this
specification.
この句は、項目がこの仕様の絶対禁止であることを意味します。
SHOULD
should
This word or the adjective "RECOMMENDED" means that there may
exist valid reasons in particular circumstances to ignore this
item, but the full implications should be understood and the case
carefully weighed before choosing a different course.
この単語か形容詞がこの項目を無視する特定の事情の正当な理由を存在するかもしれない手段に「推薦しました」が、完全な含意は、理解されていて異なったコースを選ぶ前に慎重に熟慮されたケースであるべきです。
SHOULD NOT
should
This phrase means that there may exist valid reasons in particular
circumstances when the listed behavior is acceptable or even
useful, but the full implications should be understood and the
case carefully weighed before implementing any behavior described
with this label.
この句は、このラベルで説明されたどんな振舞いも実装する前にいつ記載された振舞いが許容できるか、または役に立ちさえしますが、完全な含意が理解されるべきであるか、そして、この件が慎重に熟慮した特定の事情の正当な理由が存在するかもしれないことを意味します。
MAY
This word or the adjective "OPTIONAL" means that this item is
truly optional. One vendor may choose to include the item because
a particular marketplace requires it or because it enhances the
product, for example; another vendor may omit the same item.
この項目は、This単語か形容詞的「任意」の手段ですが、本当に、任意の状態でそうするかもしれません。 特定の市場がそれを必要とするか、または例えば製品を高めるので、1つのベンダーが、項目を含んでいるのを選ぶかもしれません。 別のベンダーは同じ項目を省略するかもしれません。
2. Introduction
2. 序論
Growth in the Internet has made us aware of the need for improved authentication of routing information. RIP-2 provides for unauthenticated service (as in classical RIP), or password authentication. Both are vulnerable to passive attacks currently widespread in the Internet. Well-understood security issues exist in routing protocols [4]. Clear text passwords, currently specified for use with RIP-2, are no longer considered sufficient [5].
インターネットでの成長で、私たちはルーティング情報の改良された認証の必要性を意識するようになりました。 RIP-2は非認証されたサービス(古典的なRIPのように)、またはパスワード認証に備えます。 両方が現在インターネットで広範囲の受け身の攻撃に被害を受け易いです。 よく理解されている安全保障問題はルーティング・プロトコル[4]で存在しています。 現在RIP-2との使用に指定されたクリアテキストパスワードはもう十分な[5]であると考えられません。
If authentication is disabled, then only simple misconfigurations are detected. Simple passwords transmitted in the clear will further protect against the honest neighbor, but are useless in the general case. By simply capturing information on the wire - straightforward even in a remote environment - a hostile process can learn the password and overcome the network.
認証は障害があるなら、簡単なmisconfigurationsだけが検出されます。 明確で伝えられた簡単なパスワードは、さらに正直な隣人から守りますが、一般的な場合で役に立ちません。 単にリモート環境でさえ簡単なワイヤの情報を得ることによって、敵対的なプロセスは、パスワードを学んで、ネットワークに打ち勝つことができます。
We propose that RIP-2 use an authentication algorithm, as was originally proposed for SNMP Version 2, augmented by a sequence number. Keyed MD5 is proposed as the standard authentication algorithm for RIP-2, but the mechanism is intended to be algorithm- independent. While this mechanism is not unbreakable (no known
私たちは、RIP-2が認証アルゴリズムを使用するよう提案します、元々一連番号によって増大させられるSNMPバージョン2のために提案されたように。 合わせられたMD5はRIP-2のための標準の認証アルゴリズムとして提案されますが、メカニズムはアルゴリズム独立者であることを意図します。 このメカニズムが解読不能でない、(知られません。
Baker & Atkinson Standards Track [Page 2] RFC 2082 RIP-2 MD5 Authentication January 1997
1997年のベイカーとアトキンソン標準化過程[2ページ]RFC2082MD5認証1月2日裂け目-
mechanism is), it provides a greatly enhanced probability that a system being attacked will detect and ignore hostile messages. This is because we transmit the output of an authentication algorithm (e.g., Keyed MD5) rather than the secret RIP-2 Authentication Key. This output is a one-way function of a message and a secret RIP-2 Authentication Key. This RIP-2 Authentication Key is never sent over the network in the clear, thus providing protection against the passive attacks now commonplace in the Internet.
メカニズムがそうである、)、攻撃されるシステムが敵対的なメッセージを検出して、無視するのは大いに高められた確率に提供されます。 これは私たちが秘密のRIP-2 Authentication Keyよりむしろ認証アルゴリズム(例えば、Keyed MD5)の出力を伝えるからです。 この出力はメッセージと秘密のRIP-2 Authentication Keyに関する一方向関数です。 明確のネットワークの上にこのRIP-2 Authentication Keyを決して送りません、その結果、現在インターネットで平凡な受け身の攻撃に対する保護を提供します。
In this way, protection is afforded against forgery or message modification. It is possible to replay a message until the sequence number changes, but the sequence number makes replay in the long term less of an issue. The mechanism does not afford confidentiality, since messages stay in the clear; however, the mechanism is also exportable from most countries, which test a privacy algorithm would fail.
このように、偽造かメッセージ変更に対して保護を提供します。 一連番号が変化するまで、それはメッセージを再演するのにおいて可能ですが、一連番号は、より少ないという問題の長い期間で再生をします。 メッセージが明確に残っているので、メカニズムは秘密性を都合しません。 しかしながら、また、メカニズムもほとんどの国から輸出向きです。プライバシーアルゴリズムはそのテストに失敗するでしょう。
Other relevant rationales for the approach are that Keyed MD5 is being used for OSPF cryptographic authentication, and is therefore present in routers already, as is some form of password management. A similar approach has been standardized for use in IP-layer authentication. [7]
アプローチのための他の関連原理はKeyed MD5がOSPFの暗号の認証に使用されていて、したがって、ルータで既に存在しているということです、何らかの形式のパスワード管理のように。 同様のアプローチはIP-層の認証における使用のために標準化されました。 [7]
3. Implementation Approach
3. 実装アプローチ
Implementation requires three issues to be addressed:
実装は、3冊が扱われるのを必要とします:
(1) A changed packet format,
(1) 変えられたパケット・フォーマット
(2) Authentication procedures, and
そして(2) 認証手順。
(3) Management controls.
(3) 管理は制御されます。
3.1. RIP-2 PDU Format
3.1. 裂け目-2PDU形式
The basic RIP-2 message format provides for an 8 byte header with an array of 20 byte records as its data content. When Keyed MD5 is used, the same header and content are used, except that the 16 byte "authentication key" field is reused to describe a "Keyed Message Digest" trailer. This consists in five fields:
基本的なRIP-2メッセージ・フォーマットはデータ内容として20バイトの記録の勢ぞろいで8バイトのヘッダーに備えます。 Keyed MD5が使用されているとき、同じヘッダーと内容は使用されています、16バイト「認証キー」分野が「合わせられたメッセージダイジェスト」トレーラについて説明するために再利用されるのを除いて。 これは5つの分野で成ります:
(1) The "Authentication Type" is Keyed Message Digest Algorithm,
indicated by the value 3 (1 and 2 indicate "IP Route" and
"Password", respectively).
(1) 「認証タイプ」は値3によって示されたKeyed Message Digest Algorithm(1と2はそれぞれ「IPルート」と「パスワード」を示す)です。
(2) A 16 bit offset from the RIP-2 header to the MD5 digest (if no
other trailer fields are ever defined, this value equals the
RIP-2 Data Length).
(2) 16ビットはRIP-2ヘッダーからMD5ダイジェストまで相殺されました(他のトレーラ分野が全く今までに定義されないなら、この値はRIP-2 Data Lengthと等しいです)。
Baker & Atkinson Standards Track [Page 3] RFC 2082 RIP-2 MD5 Authentication January 1997
1997年のベイカーとアトキンソン標準化過程[3ページ]RFC2082MD5認証1月2日裂け目-
(3) An unsigned 8-bit field that contains the Key Identifier
or Key-ID. This identifies the key used to create the
Authentication Data for this RIP-2 message. In
implementations supporting more than one authentication
algorithm, the Key-ID also indicates the authentication
algorithm in use for this message. A key is associated with
an interface.
(3) Key IdentifierかKey-IDを含む未署名の8ビットの分野。 これはこのRIP-2メッセージのためにAuthentication Dataを作成するのに使用されるキーを特定します。 また、1つ以上の認証アルゴリズムをサポートする実装では、Key-IDはこのメッセージに、使用中の認証アルゴリズムを示します。 キーはインタフェースに関連しています。
(4) An unsigned 8-bit field that contains the length in octets of the
trailing Authentication Data field. The presence of this field
permits other algorithms (e.g., Keyed SHA) to be substituted for
Keyed MD5 if desired.
(4) 引きずっているAuthentication Data分野の八重奏における長さを含む未署名の8ビットの分野。 望まれているなら、この分野の存在は、他のアルゴリズム(例えば、Keyed SHA)がKeyed MD5に代入されることを許可します。
(5) An unsigned 32 bit sequence number. The sequence number MUST be
non-decreasing for all messages sent with the same Key ID.
(5) 未署名の32は一連番号に噛み付きました。 一連番号が同じKey IDと共に送られたすべてのメッセージのための非減少でなければならない。
The trailer consists of the Authentication Data, which is the output of the Keyed Message Digest Algorithm. When the Authentication Algorithm is Keyed MD5, the output data is 16 bytes; during digest calculation, this is effectively followed by a pad field and a length field as defined by RFC 1321.
トレーラはAuthentication Dataから成ります。(Authentication DataはKeyed Message Digest Algorithmの出力です)。 Authentication AlgorithmがKeyed MD5であるときに、出力データは16バイトです。 ダイジェスト計算の間、RFC1321によって定義されるように事実上、パッド分野と長さの分野はこれのあとに続いています。
Baker & Atkinson Standards Track [Page 4] RFC 2082 RIP-2 MD5 Authentication January 1997
1997年のベイカーとアトキンソン標準化過程[4ページ]RFC2082MD5認証1月2日裂け目-
3.2. Processing Algorithm
3.2. 処理アルゴリズム
When the authentication type is "Keyed Message Digest", message processing is changed in message creation and reception.
認証タイプが「合わせられたメッセージダイジェスト」であるときに、メッセージ作成とレセプションでメッセージ処理を変えます。
0 1 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Command (1) | Version (1) | Routing Domain (2) |
+---------------+---------------+-------------------------------+
| 0xFFFF | AuType=Keyed Message Digest |
+-------------------------------+-------------------------------+
| RIP-2 Packet Length | Key ID | Auth Data Len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number (non-decreasing) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| reserved must be zero |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| reserved must be zero |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
/ (RIP-2 Packet Length - 24) bytes of Data /
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0xFFFF | 0x01 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Authentication Data (var. length; 16 bytes with Keyed MD5) /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | コマンド(1)| バージョン(1)| 経路ドメイン(2)| +---------------+---------------+-------------------------------+ | 0xFFFF| AuTypeは合わせられたメッセージダイジェストと等しいです。| +-------------------------------+-------------------------------+ | 裂け目-2パケット長| 主要なID| Auth Dataレン| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 一連番号(非減少)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 予約されているのは、ゼロであるに違いありません。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 予約されているのは、ゼロであるに違いありません。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | /(RIP-2 Packet Length--24)バイトのData/| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0xFFFF| 0×01| 認証..var...長さ..バイト
In memory, the following trailer is appended by the MD5 algorithm and treated as though it were part of the message.
メモリでは、以下のトレーラは、まるでそれがメッセージの一部であるかのようにMD5アルゴリズムで追加されて、扱われます。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | sixteen octets of MD5 "secret" | / / | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | zero or more pad bytes (defined by RFC 1321 when MD5 is used) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 64 bit message length MSW | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 64 bit message length LSW | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MD5「秘密」の16の八重奏| / / | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ゼロか以上がバイト(RFC1321で、MD5がいつ使用されているかを定義する)を水増しします。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 64ビットのメッセージ長MSW| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 64ビットのメッセージ長LSW| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Baker & Atkinson Standards Track [Page 5] RFC 2082 RIP-2 MD5 Authentication January 1997
1997年のベイカーとアトキンソン標準化過程[5ページ]RFC2082MD5認証1月2日裂け目-
3.2.1. Message Generation
3.2.1. メッセージ世代
The RIP-2 Packet is created as usual, with these exceptions:
RIP-2 Packetはこれらの例外で通常通りで作成されます:
(1) The UDP checksum need not be calculated, but MAY be set to
zero.
(1) UDPチェックサムは、計算される必要はありませんが、ゼロに設定されるかもしれません。
(2) The authentication type field indicates the Keyed Message Digest
Algorithm (3).
(2) 認証タイプ分野はKeyed Message Digest Algorithm(3)を示します。
(3) The authentication "password" field is reused to store a packet
offset to the Authentication Data, a Key Identifier, the
Authentication Data Length, and a non-decreasing sequence number.
(3) 認証「パスワード」分野は、Authentication Data、Key Identifier、Authentication Data Length、および非減少している一連番号まで相殺されたパケットを保存するために再利用されます。
The value used in the sequence number is arbitrary, but two suggestions are the time of the message's creation or a simple message counter.
一連番号に使用される値は任意ですが、2つの提案が、メッセージの作成の時間か簡単なメッセージカウンタです。
The RIP-2 Authentication Key is selected by the sender based on the outgoing interface. Each key has a lifetime associated with it. No key is ever used outside its lifetime. Since the key's algorithm is related to the key itself, stored in the sender and receiver along with it, the Key ID effectively indicates which authentication algorithm is in use if the implementation supports more than one authentication algorithm.
RIP-2 Authentication Keyは外向的なインタフェースに基づく送付者によって選択されます。 各キーには、それに関連している寿命があります。 キーは全く生涯、今までに、使用されません。 キーのアルゴリズムがそれに伴う送付者と受信機に保存されたキー自体に関連するので、事実上、Key IDは、実装が1つ以上の認証アルゴリズムをサポートするならどの認証アルゴリズムが使用中であるかを示します。
(1) The RIP-2 header's packet length field indicates the standard
RIP-2 portion of the packet.
(1) RIP-2ヘッダーのパケット長分野はパケットの標準のRIP-2部分を示します。
(2) The Authentication Data Offset, Key Identifier, and
Authentication Data size fields are filled in appropriately.
(2) Authentication Data Offset、Key Identifier、およびAuthentication Dataサイズ分野は適切に記入されます。
(3) The RIP-2 Authentication Key, which is 16 bytes long when the
Keyed MD5 algorithm is used, is now appended to the data. For
all algorithms, the RIP-2 Authentication Key is never longer than
the output of the algorithm in use.
(3) 現在、RIP-2 Authentication Key(Keyed MD5アルゴリズムが使用されているとき、16バイト長である)をデータに追加します。 すべてのアルゴリズムの割には、RIP-2 Authentication Keyは使用中のアルゴリズムの出力より決して長くはありません。
(4) Trailing pad and length fields are added and the digest
calculated using the indicated algorithm. When Keyed MD5 is the
algorithm in use, these are calculated per RFC 1321.
(4) 引きずっているパッドと長さの分野は、加えられて示されたアルゴリズムを使用することで計算されたダイジェストです。 Keyed MD5が使用中のアルゴリズムであるときに、これらはRFC1321単位で計算されます。
(5) The digest is written over the RIP-2 Authentication Key. When
MD5 is used, this digest will be 16 bytes long.
(5) ダイジェストはRIP-2 Authentication Keyの上に書かれています。 MD5が使用されているとき、このダイジェストは16バイト長になるでしょう。
The trailing pad is not actually transmitted, as it is entirely predictable from the message length and algorithm in use.
それが使用中のメッセージ長とアルゴリズムから完全に予測できるとき、引きずっているパッドは実際に送られません。
Baker & Atkinson Standards Track [Page 6] RFC 2082 RIP-2 MD5 Authentication January 1997
1997年のベイカーとアトキンソン標準化過程[6ページ]RFC2082MD5認証1月2日裂け目-
3.2.2. Message Reception
3.2.2. メッセージレセプション
When the message is received, the process is reversed:
メッセージが受信されているとき、プロセスは逆にされます:
(1) The digest is set aside,
(1) ダイジェストはかたわらに置かれます。
(2) The appropriate algorithm and key are determined from the value
of the Key Identifier field,
(2) 適切なアルゴリズムとキーはKey Identifier分野の値から断固としています。
(3) The RIP-2 Authentication Key is written into the appropriate
number (16 when Keyed MD5 is used) of bytes starting at the
offset indicated,
(3) RIP-2 Authentication Keyはオフセットにおける始めが示したバイトの適切な数(Keyed MD5であるときに、16は使用されている)に書かれています。
(4) Appropriate padding is added as needed, and
そして(4) 適切な詰め物が必要に応じて加えられる。
(5) A new digest calculated using the indicated algorithm.
(5) 示されたアルゴリズムを使用することで計算された新しいダイジェスト。
If the calculated digest does not match the received digest, the
message is discarded unprocessed. If the neighbor has been heard
from recently enough to have viable routes in the route table and the
received sequence number is less than the last one received, the
message likewise is discarded unprocessed. When connectivity to the
neighbor has been lost, the receiver SHOULD be ready to accept
either:
- a message with a sequence number of zero
- a message with a higher sequence number than the last received
sequence number.
計算されたダイジェストが受け取られていているダイジェストに合っていないなら、未加工で捨てられたメッセージです。 隣人の声が最近ルートテーブルに実行可能なルートを持つことができるくらい聞かれて、容認された一連番号が最終より少ないなら、1つは受信されました、同様に未加工で捨てられたメッセージ。 隣人への接続性は失われて、受信機はSHOULDです。いつ、受け入れる準備ができていてください: - ゼロの一連番号があるメッセージ--最終より高い一連番号があるメッセージは一連番号を受けました。
A router that has forgotten its current sequence number but remembers its key and Key-ID MUST send its first packet with a sequence number of zero. This leaves a small opening for a replay attack. Router vendors are encouraged to provide stable storage for keys, key lifetimes, Key-IDs, and the related sequence numbers.
現在の一連番号を忘れましたが、そのキーとKey-IDを覚えているルータはゼロの一連番号と共に最初のパケットを送らなければなりません。 これは小径端部を反射攻撃に残します。 ルータベンダーがキー、主要な生涯、Key-ID、および関連配列番号のための安定貯蔵を提供するよう奨励されます。
Acceptable messages are now truncated to RIP-2 message itself and treated normally.
許容できるメッセージは、今、RIP-2メッセージ自体に先端を切られて、通常、扱われます。
4. Management Procedures
4. 管理手順
4.1. Key Management Requirements
4.1. Key Management要件
It is strongly desirable that a hypothetical security breach in one Internet protocol not automatically compromise other Internet protocols. The Authentication Key of this specification SHOULD NOT be stored using protocols or algorithms that have known flaws.
1つのインターネットプロトコルにおける仮定している機密保護違反が、他のインターネットがプロトコルであると自動的に感染しないのは、強く望ましいです。 Authentication Key、この仕様SHOULD NOTにおいて、保存された使用プロトコルか欠点を知っていたアルゴリズムがそうです。
Baker & Atkinson Standards Track [Page 7] RFC 2082 RIP-2 MD5 Authentication January 1997
1997年のベイカーとアトキンソン標準化過程[7ページ]RFC2082MD5認証1月2日裂け目-
Implementations MUST support the storage of more than one key at the same time, although it is recognized that only one key will normally be active on an interface. They MUST associate a specific lifetime (i.e., date/time first valid and date/time no longer valid) and a key identifier with each key, and MUST support manual key distribution (e.g., the privileged user manually typing in the key, key lifetime, and key identifier on the router console). The lifetime may be infinite. If more than one algorithm is supported, then the implementation MUST require that the algorithm be specified for each key at the time the other key information is entered. Keys that are out of date MAY be deleted at will by the implementation without requiring human intervention. Manual deletion of active keys SHOULD also be supported.
実装は同時に1個以上のキーのストレージをサポートしなければなりません、通常、1個のキーだけがインタフェースでアクティブになると認められますが。 彼らは、特定の生涯(すなわち、/時間もう最初に、有効、そして、日付/時間日付の有効な)、主要な識別子を各キーに関連づけなければならなくて、手動の主要な分配(例えば、ルータコンソールの上に手動で主要で、主要な生涯、および主要な識別子をタイプする特権ユーザ)をサポートしなければなりません。 寿命は無限であるかもしれません。 1つ以上のアルゴリズムがサポートされるなら、実装は、もう片方の主要な情報が入力されるときアルゴリズムが各キーに指定されるのを必要としなければなりません。 人間の介入を必要としないで、時代遅れのキーは実装によって自由自在に削除されるかもしれません。 能動態の手動の削除はSHOULDを合わせます、また、サポートされてください。
It is likely that the IETF will define a standard key management protocol. It is strongly desirable to use that key management protocol to distribute RIP-2 Authentication Keys among communicating RIP-2 implementations. Such a protocol would provide scalability and significantly reduce the human administrative burden. The Key ID can be used as a hook between RIP-2 and such a future protocol. Key management protocols have a long history of subtle flaws that are often discovered long after the protocol was first described in public. To avoid having to change all RIP-2 implementations should such a flaw be discovered, integrated key management protocol techniques were deliberately omitted from this specification.
IETFは標準のかぎ管理プロトコルを定義しそうでしょう。 かぎ管理がRIP-2実装を伝えるのにRIP-2 Authenticationキーズを分配するために議定書を作るのは、使用するのにおいて強く望ましいです。 そのようなプロトコルは、スケーラビリティを提供して、人間の管理負担をかなり減少させるでしょう。 RIP-2とそのような将来のプロトコルの間のフックとしてKey IDを使用できます。 かぎ管理プロトコルには、プロトコルが最初に公然と説明されたずっと後にしばしば発見される微妙な欠点の長い歴史があります。 そのような欠点が発見されるならすべてのRIP-2実装を変えなければならないのを避けるために、統合かぎ管理プロトコルのテクニックは故意にこの仕様から省略されました。
4.2. Key Management Procedures
4.2. Key Management手順
As with all security methods using keys, it is necessary to change the RIP-2 Authentication Key on a regular basis. To maintain routing stability during such changes, implementations MUST be able to store and use more than one RIP-2 Authentication Key on a given interface at the same time.
キーを使用するすべてのセキュリティメソッドのように、定期的にRIP-2 Authentication Keyを変えるのが必要です。 実装は、同時に、与えられたインタフェースの1RIP-2 Authentication Keyを保存して、そのような変化の間、ルーティングの安定性を維持するのに、使用できなければなりません。
Each key will have its own Key Identifier, which is stored locally. The combination of the Key Identifier and the interface associated with the message uniquely identifies the Authentication Algorithm and RIP-2 Authentication Key in use.
各キーにはそれ自身のKey Identifierがあるでしょう。(Key Identifierは局所的に保存されます)。 メッセージに関連しているKey Identifierとインタフェースの組み合わせは唯一使用中のAuthentication AlgorithmとRIP-2 Authentication Keyを特定します。
As noted above in Section 2.2.1, the party creating the RIP-2 message will select a valid key from the set of valid keys for that interface. The receiver will use the Key Identifier and interface to determine which key to use for authentication of the received message. More than one key may be associated with an interface at the same time.
上で述べたようにセクション2.2.1では、RIP-2メッセージを作成するパーティーは有効なキーのセットから有効なキーをそのインタフェースに選択するでしょう。 受信機は、受信されたメッセージの認証にどのキーを使用したらよいかを決定するのにKey Identifierとインタフェースを使用するでしょう。 1個以上のキーが同時に、インタフェースに関連しているかもしれません。
Baker & Atkinson Standards Track [Page 8] RFC 2082 RIP-2 MD5 Authentication January 1997
1997年のベイカーとアトキンソン標準化過程[8ページ]RFC2082MD5認証1月2日裂け目-
Hence it is possible to have fairly smooth RIP-2 Authentication Key rollovers without losing legitimate RIP-2 messages because the stored key is incorrect and without requiring people to change all the keys at once. To ensure a smooth rollover, each communicating RIP-2 system must be updated with the new key several minutes before the current key will expire and several minutes before the new key lifetime begins. The new key should have a lifetime that starts several minutes before the old key expires. This gives time for each system to learn of the new RIP-2 Authentication Key before that key will be used. It also ensures that the new key will begin being used and the current key will go out of use before the current key's lifetime expires. For the duration of the overlap in key lifetimes, a system may receive messages using either key and authenticate the message. The Key-ID in the received message is used to select the appropriate key for authentication.
したがって、保存されたキーが不正確であるので正統のRIP-2メッセージを失うことなしで人々がすぐにすべてのキーを変えるのが必要であるなしで滑らかなRIP-2 Authentication Keyロールオーバーを公正に持っているのは可能です。 滑らかなロールオーバーを確実にするために、現在のキーが期限が切れる数分前と新しい主要な寿命が始まる数分前に新しいキーでそれぞれの交信しているRIP-2システムをアップデートしなければなりません。 新しいキーには、古いキーが期限が切れる数分前に始まる寿命があるはずです。 これはそのキーが使用される前に各システムが新しいRIP-2 Authentication Keyを知る時間を与えます。 また、それは、新しいキーが使用され始めるのを確実にします、そして、現在のキーの寿命が期限が切れる前に現在のキーは使用から動くでしょう。 主要な生涯のオーバラップの持続時間のために、システムは、どちらのキーも使用することでメッセージを受け取って、メッセージを認証するかもしれません。 受信されたメッセージのKey-IDは、認証のための適切なキーを選択するのに使用されます。
4.3. Pathological Cases
4.3. 病理学的なケース
Two pathological cases exist which must be handled, which are failures of the network manager. Both of these should be exceedingly rare.
扱わなければならなくて、ネットワークマネージャの失敗である2つの病理学的なケースが、存在しています。 これらの両方がきわめてまれであるはずです。
During key switchover, devices may exist which have not yet been successfully configured with the new key. Therefore, routers SHOULD implement (and would be well advised to implement) an algorithm that detects the set of keys being used by its neighbors, and transmits its messages using both the new and old keys until all of the neighbors are using the new key or the lifetime of the old key expires. Under normal circumstances, this elevated transmission rate will exist for a single update interval.
主要な転換の間、新しいキーでまだ首尾よく構成されていないデバイスは存在するかもしれません。 したがって、ルータSHOULDが隣人によって使用されるキーのセットを検出して、隣人が皆、新しいキーを使用するまで両方の新しくて古いキーを使用することでメッセージを送るアルゴリズムを実装するか(そして、上手にアドバイスされた道具でしょう)、または古いキーの寿命は期限が切れます。 通常の状況下で、この高い通信速度は単一のアップデート間隔の間、存在するでしょう。
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.
インタフェースに関連している最後のキーが期限が切れる場合、ルーティングを混乱させるのは、非認証された状態に振り向けるのにおいて容認できなくて、賢明ではありません。 したがって、ルータが、「最後の認証の主要な満了」通知をネットワークマネージャに送って、寿命が拡張されるまで無限の生涯を持っているとしてキーを扱うべきですか、キーがネットワークマネージメントで削除されるか、または新しいキーは構成されます。
5. Conformance Requirements
5. 順応要件
To conform to this specification, an implementation MUST support all of its aspects. The Keyed MD5 authentication algorithm MUST be implemented by all conforming implementations. MD5 is defined in RFC-1321. A conforming implementation MAY also support other authentication algorithms such as Keyed Secure Hash Algorithm (SHA). Manual key distribution as described above MUST be supported by all conforming implementations. All implementations MUST support the
この仕様に従うために、実装は局面のすべてをサポートしなければなりません。 実装を従わせて、すべてでKeyed MD5認証アルゴリズムを実装しなければなりません。 MD5はRFC-1321で定義されます。 また、従う実装は、他の認証がKeyed Secure Hash Algorithm(SHA)などのアルゴリズムであるとサポートするかもしれません。 実装を従わせて、上で説明される手動の主要な分配はすべてで後押しされていなければなりません。 すべての実装がサポートしなければなりません。
Baker & Atkinson Standards Track [Page 9] RFC 2082 RIP-2 MD5 Authentication January 1997
1997年のベイカーとアトキンソン標準化過程[9ページ]RFC2082MD5認証1月2日裂け目-
smooth key rollover described under "Key Change Procedures."
「キーチェンジ手順」の下で説明された主要なロールオーバーを整えてください。
The user documentation provided with the implementation MUST contain clear instructions on how to ensure that smooth key rollover occurs.
実装が提供されたユーザドキュメンテーションは滑らかな主要なロールオーバーが起こるのをどう保証するかに関する明確な指示を含まなければなりません。
Implementations SHOULD support a standard key management protocol for secure distribution of RIP-2 Authentication Keys once such a key management protocol is standardized by the IETF.
そのようなかぎ管理プロトコルがIETFによっていったん標準化されると、実装SHOULDはRIP-2 Authenticationキーズの安全な分配のために標準のかぎ管理プロトコルをサポートします。
6. Acknowledgments
6. 承認
This work was done by the RIP-2 Working Group, of which Gary Malkin is the Chair. This suggestion was originally made by Christian Huitema on behalf of the IAB. Jeff Honig (Cornell) and Dennis Ferguson (ANS) built the first operational prototype, proving out the algorithms. The authors gladly acknowledge significant inputs from each of these sources.
この仕事がRIP-2作業部会によって行われました。(ゲーリー・マルキンはそれで議長です)。 この提案は元々、IABを代表してクリスチャンのHuitemaによってされました。 ジェフ・ホニッグ(コーネル)とデニスファーガソン(ANS)は最初の操作上のプロトタイプを築き上げました、外でアルゴリズムを立証して。作者は喜んでそれぞれのこれらの源からの重要な入力を承諾します。
7. References
7. 参照
[1] Malkin, G., "RIP Version 2 Carrying Additional Information",
RFC 1388, January 1993.
[1] マルキン、G.、「追加情報を運ぶ裂け目のバージョン2」、RFC1388、1993年1月。
[2] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April
1992.
[2] 1992年4月、最もRivestなR.、「MD5メッセージダイジェストアルゴリズム」RFC1321。
[3] Malkin, G., and F. Baker, "RIP Version 2 MIB Extension",
RFC 1389, Xylogics, Inc., Advanced Computer Communications,
January 1993.
1993年1月の[3] RFC1389(Xylogics Inc.)が進めたマルキン、G.、およびF.ベイカー、「裂け目のバージョン2MIB拡張子」コンピュータコミュニケーション。
[4] S. Bellovin, "Security Problems in the TCP/IP Protocol Suite",
ACM Computer Communications Review, Volume 19, Number 2,
pp.32-48, April 1989.
[4] S.Bellovin、「TCP/IPにおける警備上の問題はスイートについて議定書の中で述べます」、ACMコンピュータCommunications Review、Volume19、Number2、pp.32-48、1989年4月。
[5] Haller, N., and R. Atkinson, "Internet Authentication
Guidelines", RFC 1704, October 1994.
[5] ハラー、N.とR.アトキンソン、「インターネット認証ガイドライン」、RFC1704、1994年10月。
[6] Braden, R., Clark, D., Crocker, S., and C. Huitema, "Report
of IAB Workshop on Security in the Internet Architecture",
RFC 1636, June 1994.
[6] ブレーデン、R.、クラーク、D.、クロッカー、S.、およびC.Huitema、「インターネットアーキテクチャにおけるセキュリティに関するIABワークショップのレポート」、RFC1636(1994年6月)。
[7] Atkinson, R., "IP Authentication Header", RFC 1826, August 1995.
[7] アトキンソン、R.、「IP認証ヘッダー」、RFC1826、1995年8月。
[8] Atkinson, R., "IP Encapsulating Security Payload", RFC 1827,
August 1995.
[8] アトキンソン、R.、「セキュリティが有効搭載量であるとカプセル化するIP」、RFC1827、1995年8月。
Baker & Atkinson Standards Track [Page 10] RFC 2082 RIP-2 MD5 Authentication January 1997
1997年のベイカーとアトキンソン標準化過程[10ページ]RFC2082MD5認証1月2日裂け目-
8. Security Considerations
8. セキュリティ問題
This entire memo describes and specifies an authentication mechanism for the RIP-2 routing protocol that is believed to be secure against active and passive attacks. Passive attacks are clearly widespread in the Internet at present. Protection against active attacks is also needed because active attacks are becoming more common.
この全体のメモは、アクティブで受け身の攻撃に対して安全であると信じられているRIP-2ルーティング・プロトコルに、認証機構を説明して、指定します。 受け身の攻撃は現在のところ、インターネットで明確に広範囲です。 また、活発な攻撃が、より一般的になるので、活発な攻撃に対する保護が必要です。
Users need to understand that the quality of the security provided by this mechanism depends completely on the strength of the implemented authentication algorithms, the strength of the key being used, and the correct implementation of the security mechanism in all communicating RIP-2 implementations. This mechanism also depends on the RIP-2 Authentication Key being kept confidential by all parties. If any of these incorrect or insufficiently secure, then no real security will be provided to the users of this mechanism.
ユーザは、このメカニズムによって提供されたセキュリティの品質をRIP-2実装をすべて伝える際に完全実装している認証アルゴリズムの強さ、使用されるキーの強さ、およびセキュリティー対策の正しい実装に依存するのを理解する必要があります。 また、このメカニズムはすべてのパーティーによって秘密にされるRIP-2 Authentication Keyによります。 これらのいずれであるならも、不正確であるか、または不十分に安全であることで、そして、このメカニズムのユーザに物上担保を全く提供しないでしょう。
Specifically with respect to the use of SNMP, compromise of SNMP security has the necessary result that the various RIP-2 configuration parameters (e.g. routing table, RIP-2 Authentication Key) manageable via SNMP could be compromised as well. Changing Authentication Keys using non-encrypted SNMP is no more secure than sending passwords in the clear.
特にSNMPの使用に関して、SNMPセキュリティの感染には、また、SNMPを通して処理しやすい様々なRIP-2設定パラメータ(例えば、経路指定テーブル、RIP-2 Authentication Key)が感染されるかもしれないという必要な結果があります。 非暗号化されたSNMPを使用することでAuthenticationキーズを変えるのは明確でパスワードを送るほど安全ではありません。
Confidentiality is not provided by this mechanism. Recent work in the IETF provides a standard mechanism for IP-layer encryption. [8] That mechanism might be used to provide confidentiality for RIP-2 in the future. Protection against traffic analysis is also not provided. Mechanisms such as bulk link encryption might be used when protection against traffic analysis is required.
秘密性はこのメカニズムによって提供されません。 IETFの近作はIP-層の暗号化に標準のメカニズムを提供します。 [8] そのメカニズムは、将来秘密性をRIP-2に供給するのに使用されるかもしれません。 また、トラヒック分析に対する保護は提供されません。 トラヒック分析に対する保護が必要であるときに、大量のリンク暗号化などのメカニズムは使用されるかもしれません。
The memo is written to address a security consideration in RIP Version 2 that was raised during the IAB's recent security review [6].
メモは、セキュリティがIABの最近の安全レビュー[6]の間に提起されたRIPバージョン2で考慮であると扱うために書かれています。
9. Chairman's Address
9. 委員長のアドレス
Gary Scott Malkin Xylogics, Inc. 53 Third Avenue Burlington, MA 01803
ゲーリースコットマルキンXylogics Inc.53第3アベニューバーリントン、MA 01803
Phone: (617) 272-8140 EMail: gmalkin@Xylogics.COM
以下に電話をしてください。 (617) 272-8140 メールしてください: gmalkin@Xylogics.COM
Baker & Atkinson Standards Track [Page 11] RFC 2082 RIP-2 MD5 Authentication January 1997
1997年のベイカーとアトキンソン標準化過程[11ページ]RFC2082MD5認証1月2日裂け目-
10. Authors' Addresses
10. 作者のアドレス
Fred Baker cisco Systems 519 Lado Drive Santa Barbara, California 93111
Lado Driveサンタバーバラ、フレッドベイカーコクチマスSystems519カリフォルニア 93111
Phone: (805) 681 0115 Email: fred@cisco.com
以下に電話をしてください。 (805) 681 0115はメールされます: fred@cisco.com
Randall Atkinson cisco Systems 170 West Tasman Drive San Jose, CA 95134-1706
西タスマン・Driveサンノゼ、ランドルアトキンソンコクチマスSystems170カリフォルニア95134-1706
Phone: (408) 526-6566 EMail: rja@cisco.com
以下に電話をしてください。 (408) 526-6566 メールしてください: rja@cisco.com
Baker & Atkinson Standards Track [Page 12]
ベイカーとアトキンソン標準化過程[12ページ]
一覧
スポンサーリンク
