RFC1004 日本語訳

Network Working Group                                         D.L. Mills
Request for Comments:  1004                       University of Delaware
                                                              April 1987

L.工場がコメントのために要求するワーキンググループD.をネットワークでつないでください: 1004 デラウエア大学1987年4月

              A Distributed-Protocol Authentication Scheme

分配されたプロトコル認証体系

Status of this Memo

このMemoの状態

   The purpose of this RFC is to focus discussion on authentication
   problems in the Internet and possible methods of solution.  The
   proposed solutions this document are not intended as standards for
   the Internet at this time.  Rather, it is hoped that a general
   consensus will emerge as to the appropriate solution to
   authentication problems, leading eventually to the adoption of
   standards.  Distribution of this memo is unlimited.

このRFCの目的はインターネットの認証問題とソリューションの可能なメソッドに議論の焦点を合わせることです。 これが記録する提案されたソリューションはこのとき、インターネットの規格として意図しません。 むしろ、全体的な合意が適切なソリューションに関して認証問題に現れることが望まれています、結局規格の採用に通じて。 このメモの分配は無制限です。

1. Introduction and Overview

1. 序論と概要

   This document suggests mediated access-control and authentication
   procedures suitable for those cases when an association is to be set
   up between multiple users belonging to different trust environments,
   but running distributed protocols like the existing Exterior Gateway
   Protocol (EGP) [2], proposed Dissimilar Gateway Protocol (DGP) [3]
   and similar protocols. The proposed prcedures are evolved from those
   described by Needham and Shroeder [5], but specialized to the
   distributed, multiple-user model typical of these protocols.

協会が異なった信頼環境に属す複数のユーザの間に設立されることになっているとき、このドキュメントは調停されたアクセスコントロールとそれらのケースに適した認証手順を示しますが、稼働は既存のExteriorゲートウェイプロトコル(EGP)[2]、提案されたDissimilarゲートウェイプロトコル(DGP)[3]、および同様のプロトコルのようなプロトコルを分配しました。 提案されたprceduresはニーダムとShroeder[5]によって説明されたものから発展されますが、これらのプロトコルの典型の分配されて、複数のユーザのモデルに専門にされます。

   The trust model and threat environment are identical to that used by
   Kent and others [1]. An association is defined as the end-to-end
   network path between two users, where the users themselves are
   secured, but the path between them is not. The network may drop,
   duplicate or deliver messages with errors. In addition, it is
   possible that a hostile user (host or gateway) might intercept,
   modify and retransmit messages. An association is similar to the
   traditional connection, but without the usual connection requirements
   for error-free delivery.  The users of the association are sometimes
   called associates.

信頼モデルと脅威環境はケントと他のもの[1]によって使用されたそれと同じです。 協会は2人のユーザの間の終わりから端へのネットワーク経路と定義されますが、彼らの間の経路は定義されるというわけではありません。(そこでは、ユーザ自身が機密保護されます)。 ネットワークは、誤りでメッセージを下げるか、コピーするか、または提供するかもしれません。 さらに、敵対的なユーザ(ホストかゲートウェイ)がメッセージを妨害して、変更して、再送するのは、可能です。 協会は、伝統的な接続と同様ですが、エラーのない配送のための普通の接続要件なしで同様です。 協会のユーザは時々仲間と呼ばれます。

   The proposed procedures require each association to be assigned a
   random session key, which is provided by an authentication server
   called the Cookie Jar. The procedures are designed to permit only
   those associations sanctioned by the Cookie Jar while operating over
   arbitrary network topologies, including non-secured networks and
   broadcast-media networks, and in the presence of hostile attackers.
   However, it is not the intent of these procedures to hide the data

提案された手順はCookie Jarと呼ばれる認証サーバによって提供される無作為のセッションキーが割り当てられる各協会を必要とします。 手順は、非機密保護しているネットワークと電波媒体ネットワークを含む任意のネットワークtopologiesの上と敵対的な攻撃者の面前で作動している間にCookie Jarによって認可されたそれらの協会だけを可能にするように設計されています。 しかしながら、データを隠すのは、これらの手順の意図ではありません。

Mills                                                           [Page 1]

RFC 1004                                                      April 1987

1987年4月にRFC1004を製粉します[1ページ]。

   (except for private keys) transmitted via these networks, but only to
   authenticate messages to avoid spoofing and replay attacks.

(秘密鍵を除いた) しかし、これらのネットワークを通して伝えられますが、だますのを避けるメッセージと反射攻撃を認証します。

   The procedures are intended for distributed systems where each user i
   runs a common protocol automaton using private state variables for
   each of possibly several associations simultaneously, one for each
   user j. An association is initiated by interrogating the Cookie Jar
   for a one-time key K(i,j), which is used to encrypt the checksum
   which authenticates messages exchanged between the users. The
   initiator then communicates the key to its associate as part of a
   connection establishment procedure such as described in [3].

手順が分散システムのために意図する、どこ、各ユーザ、私は同時にそれぞれのことによるといくつかの協会に個人的な州の変数を使用することで一般的なプロトコルオートマトンを動かします、各ユーザjあたり1つ。 協会は、1回の主要なK(i、j)のためにCookie Jarについて査問することによって、開始されます。(Kは、ユーザの間で交換されたメッセージを認証するチェックサムを暗号化するのに使用されます)。 そして、創始者は[3]で説明されるようにコネクション確立手順の一部として仲間のキーを伝えます。

   The information being exchanged in this protocol model is largely
   intended to converge a distributed data base to specified (as far as
   practical) contents, and does not ordinarily require a reliable
   distribution of event occurances, other than to speed the convergence
   process. Thus, the model is intrinsically resistant to message loss
   or duplication. Where important, sequence numbers are used to reduce
   the impact of message reordering. The model assumes that associations
   between peers, once having been sanctioned, are maintained
   indefinitely.  The exception when an association is broken may be due
   to a crash, loss of connectivity or administrative action such as
   reconfiguration or rekeying. Finally, the rate of information
   exchange is specifically designed to be much less than the nominal
   capabilities of the network, in order to keep overheads low.

(はるかに同じくらい実用的)のコンテンツを指定して、通常、イベントoccurancesの信頼できる分配を必要としないようにこのプロトコルモデルで交換される情報が分散形データベースを一点に集めることを主に意図します、集合プロセスを促進するのを除いて。 したがって、モデルは本質的にメッセージの損失か複製に抵抗力があります。 重要であるところでは、一連番号が、メッセージ再命令の影響を減少させるのに使用されます。 モデルは、一度認可されたことがあって、同輩の間の協会が無期限に維持されると仮定します。 協会が壊れているとき、例外はクラッシュ(接続性か管理動作の再構成か「再-合わせ」ることなどの損失)のためであるかもしれません。 最終的に、情報交換比率はネットワークの名目上の能力よりはるかに少なくなるように明確に設計されています、オーバーヘッドを低く保つために。

2. Procedures

2. 手順

   Each user i is assigned a public address A(i) and private key K(i) by
   an out-of-band procedure beyond the scope of this discussion. The
   address can take many forms: an autonomous system identifier [2], an
   Internet address [6] or simply an arbitrary name. However, no matter
   what form it takes, every message is presumed to carry both the
   sender and receiver addresses in its header. Each address and its
   access-control list is presumed available in a public directory
   accessable to all users, but the private key is known only to the
   user and Cookie Jar and is not disclosed in messages exchanged
   between users or between users and the Cookie Jar.

iがこの議論の範囲を超えたバンドで出ている手順で公共のアドレスA(i)と秘密鍵K(i)割り当てられる各ユーザ。 アドレスは多くの形を取ることができます: 自律システム識別子[2]、インターネット・アドレス[6]または単に任意の名前。 しかしながら、それがどんな形を取っても、送付者と受信機アドレスの両方があえてヘッダーであらゆるメッセージが伝えられます。 各アドレスとそのアクセスコントロールリストがすべてのユーザへの公共のディレクトリアクセス可能で利用可能であると推定されますが、秘密鍵は、ユーザとCookie Jarだけにおいて知られていて、ユーザの間、または、ユーザの間で交換されたメッセージとCookie Jarで明らかにされません。

   An association between i and j is identified by the bitstring
   consisting of the catenation of the addresses A(i) and A(j), together
   with a one-time key K(i,j), in the form [A(i),A(j),K(i,j)]. Note that
   the reciprocal association [A(j),A(i),K(j,i)] is distinguished only
   by which associate calls the Cookie Jar first. It is the intent in
   the protocol model that all state variables and keys relevant to a
   previous association be erased when a new association is initiated
   and no caching (as suggested in [5]) is allowed.

iとjとの協会はアドレスのA(i)とA(j)の染色体の連結のbitstringの成ることで特定されます、1回の主要なK(i、j)と共に、フォーム[A(i)、A(j)、K(i、j)]で。 どの仲間が最初に単にCookie Jarを呼ぶかによって相互的な協会[A(j)、A(i)、K(j、i)]が区別されることに注意してください。 新連合が開始されるとき、前の協会に関連している変数とキーが消されるとすべて述べるプロトコルモデルの意図にもかかわらず、それはキャッシュではありません。(示されるように、[5])は許容されています。

Mills                                                           [Page 2]

RFC 1004                                                      April 1987

1987年4月にRFC1004を製粉します[2ページ]。

   The one-time key K(i,j) is generated by the Cookie Jar upon receipt
   of a request from user i to associate with user j. The Cookie Jar has
   access to a private table of entries in the form [A(i),K(i)], where i
   ranges over the set of sanctioned users. The public directory
   includes for each A(i) a list L(i) = {j1, j2, ...} of permitted
   associates for i, which can be updated only by the Cookie Jar. The
   Cookie Jar first checks that the requested user j is in L(i), then
   rolls a random number for K(i,j) and returns this to the requestor,
   which saves it and passes it along to its associate during the
   connection establishment procedure.

1回の主要なK(i、j)は要求を受け取り次第ユーザjと共にCookie Jarによってユーザiから仲間まで生成されます。 Cookie Jarはフォームでエントリーの個人的なテーブルに近づく手段を持っています。[A(i)、K(i)]。(そこでは、iが認可されたユーザのセットに広がっています)。 公共のディレクトリは各A(i)のために単にCookie Jarがアップデートできるiのための仲間に受入れられて、j1、j2、…とL(i)が等しいリストを含んでいます。 Cookie Jarは最初に、要求されたユーザjがL(i)にいるのをチェックして、次に、K(i、j)のための乱数を回転させて、これを要請者に返して、コネクション確立手順の間、それを仲間に回します。(その要請者は、それを保存します)。

   In the diagrams that follow all fields not specifically mentioned are
   unencrypted. While the natural implementation would include the
   address fields of the message header in the checksum, this raises
   significant difficulties, since they may be necessary to determine
   the route through the network itself. As will be evident below, even
   if a perpetrator could successfully tamper with the address fields in
   order to cause messages to be misdelivered, the result would not be a
   useful association.

従うダイヤグラムで、明確に言及されなかったすべての分野が非暗号化されます。 自然な実装はチェックサムにメッセージヘッダーのアドレス・フィールドを含んでいるでしょうが、これは著しい困難を上げます、それらがネットワーク自体を通してルートを決定するのに必要であるかもしれないので。 明白であるように、加害者が首尾よくそうすることができても、以下では、misdeliveredされるべきメッセージを引き起こすためにアドレス・フィールドをいじってください、そして、結果は役に立つ協会でないでしょう。

   The checksum field is computed by a algorithm using all the bits in
   the message including the address fields in the message header, then
   is ordinarily encrypted along with the sequence-number field by an
   appropriate algorithm using the specified key, so that the intended
   receiver is assured only the intended sender could have generated it.
   In the Internet system, the natural choice for checksum is the 16-
   bit, ones-complement algorithm [6], while the natural choice for
   encryption is the DES algorithm [4] (see the discussion following for
   further consideration on these points). The detailed procedures are
   as follows:

チェックサム分野は、メッセージヘッダーのアドレス・フィールドを含んでいて、メッセージですべてのビットを使用することでアルゴリズムによって計算されて、次に、通常、一連番号分野と共に指定されたキーを使用しながら、適切なアルゴリズムで暗号化されます、所定の受信者が意図している送付者だけがそれを生成したかもしれないことが保証されるように。 インターネット・システムでは、チェックサムのための自然な選択は16ビットです、もの補数のアルゴリズム[6]、暗号化のための自然な選択がDESアルゴリズム[4]です(これらのポイントの上で議論がさらなる考慮のために続いているのを見てください)が。 詳細手順書は以下の通りです:

      1. The requestor i rolls a random message ID I and sends it and
      the association specifier [A(i),A(j)] as a request to the Cookie
      Jar. The message header includes the addresses [A(i),A(C)], where
      A(C) is the address of the Cookie Jar. The following schematic
      illustrates the result:

1. 要請者、私が無作為のメッセージIDを回転させる、私、それと協会の特許説明書の作成書を送る、[A(i)(Cookie Jarへの要求としてのA(j)])。 メッセージヘッダーはアドレスを入れます。[A(i)、A(C)]、どこA(C)はCookie Jarのアドレスであるか。 以下、概要、結果を例証します:

      +-----------+-----------+
      |   A(i)    |   A(C)    |       message header
      +-----------+-----------+
      |     I     | checksum  |       message ID
      +-----------+-----------+
      |   A(i)    |   A(j)    |       assoc specifier
      +-----------+-----------+

+-----------+-----------+ | A(i)| A(C)| メッセージヘッダー+-----------+-----------+ | I| チェックサム| メッセージID+-----------+-----------+ | A(i)| A(j)| assoc特許説明書の作成書+-----------+-----------+

      2. The Cookie Jar checks the access list to determine if the
      association [A(i),A(j)] is valid. If so, it rolls a random number
      K(i,j) and constructs the reply below. It checksums the message,

2. Cookie Jarは協会であるなら決定するアクセスリストをチェックします。[A(i)、A(j)]は有効です。 そうだとすれば、それは、乱数K(i、j)を回転させて、以下での回答を構成します。 それ、チェックサム、メッセージ

Mills                                                           [Page 3]

RFC 1004                                                      April 1987

1987年4月にRFC1004を製粉します[3ページ]。

      encrypts the j cookie field with K(j), then encrypts it and the
      other fields indicated with K(i) and finally sends the reply:

K(j)でjクッキー分野を暗号化して、次に、それとK(i)で示された他の分野を暗号化して、最終的に回答を送ります:

      +-----------+-----------+
      |   A(C)    |   A(i)    |       message header
      +-----------+-----------+
      |     I     | checksum  |       message ID (encrypt K(i))
      +-----------+-----------+
      |   K(i,j)  |                   i cookie (encrypt K(i))
      +-----------+
      |   K(i,j)  |                   j cookie (encrypt K(j)K(i))
      +-----------+

+-----------+-----------+ | A(C)| A(i)| メッセージヘッダー+-----------+-----------+ | I| チェックサム| メッセージID、(K(i))+を暗号化してください。-----------+-----------+ | K(i、j)| iクッキー、(K(i))+を暗号化してください。-----------+ | K(i、j)| jクッキー、(K(j)K(i))+を暗号化してください。-----------+

      3. Upon receipt of the reply the requestor i decrypts the
      indicated fields, saves the (encrypted) j cookie field and copies
      the i cookie field to the j cookie field, so that both cookie
      fields are now the original K(i,j) provided by the Cookie Jar.
      Then it verifies the checksum and matches the message ID with its
      list of outstanding requests, retaining K(i,j) for its own use. It
      then rolls a random number X for the j cookie field (to confuse
      wiretappers) and another I' for the (initial) message ID, then
      recomputes the checksum.  Finally, it inserts the saved j cookie
      field in the i cookie field, encrypts the message ID fields with
      K(i,j) and sends the following message to its associate:

3. 回答を受け取り次第、私が示された分野を解読して、(暗号化される)のjクッキーであることを救う要請者は、jクッキー分野にiクッキー分野をさばいて、コピーします、現在両方のクッキー分野がCookie Jarによって提供されたオリジナルのK(i、j)であるように。 次に、傑出している要求のリストにチェックサムについて確かめて、メッセージIDを合わせます、それ自身の使用のためのK(i、j)を保有して。 'それは、次に、jクッキー分野(盗聴者を混乱させる)への乱数Xと(初期)のメッセージIDのための別のI'を回転させて、次に、チェックサムを再計算します。 最終的に、保存しているjクッキー野原をiクッキー分野に挿入して、K(i、j)と共にメッセージID分野を暗号化して、以下のメッセージを仲間に送ります:

      +-----------+-----------+
      |   A(i)    |   A(j)    |       message header
      +-----------+-----------+
      |     I'    | checksum  |       message ID (encrypt K(i,j))
      +-----------+-----------+
      |  K(i,j)   |                   i cookie (encrypt K(j))
      +-----------+
      |     X     |                   j cookie (noise)
      +-----------+

+-----------+-----------+ | A(i)| A(j)| メッセージヘッダー+-----------+-----------+ | '私'| チェックサム| メッセージID(K(i、j)を暗号化する)+-----------+-----------+ | K(i、j)| iクッキー、(K(j))+を暗号化してください。-----------+ | X| jクッキー(雑音)+-----------+

      4. Upon receipt of the above message the associate j decrypts the
      i cookie field, uses it to decrypt the message ID fields and
      verifies the checksum, retaining the I' and K(i,j) for later use.
      Finally, it rolls a random number J' as its own initial message
      ID, inserts it and the checksum in the confirm message, encrypts
      the message ID fields with K(i,j) and sends the message:

4. '仲間jは、上記のメッセージを受け取り次第iクッキー分野を解読して、メッセージがID分野であると解読するのにそれを使用して、チェックサムについて確かめます、後の使用のためのI'とK(i、j)を保有して。 それ自身のものがメッセージIDに頭文字をつけるように'最終的に、乱数Jを回転すること'がそれとチェックサムを差し込む、通信するように確認して、K(i、j)と共にメッセージID分野を暗号化して、メッセージを送ります:

      +-----------+-----------+
      |   A(j)    |   A(i)    |       message header
      +-----------+-----------+
      |     J'    | checksum  |       message ID (encrypt K(i,j))
      +-----------+-----------+

+-----------+-----------+ | A(j)| A(i)| メッセージヘッダー+-----------+-----------+ | 'J'| チェックサム| メッセージID(K(i、j)を暗号化する)+-----------+-----------+

Mills                                                           [Page 4]

RFC 1004                                                      April 1987

1987年4月にRFC1004を製粉します[4ページ]。

      5. Subsequent messages are all coded in the same way. As new data
      are generated the message ID is incremented, a new checksum
      computed and the message ID fields encrypted with K(i,j). The
      receiver decrypts the message ID fields with K(i,j) and discards
      the message in case of incorrect checksum or sequence number.

5. 同様に、その後のメッセージはすべてコード化されます。 新しいデータがメッセージであると生成されるのに従って、IDは増加されていました、そして、新しいチェックサムは計算されました、そして、メッセージID分野はKと共に(i、j)を暗号化しました。 受信機は、K(i、j)と共にメッセージがID分野であると解読して、不正確なチェックサムか一連番号の場合にメッセージを捨てます。

3. Discussion

3. 議論

   Since the access lists are considered public read-only, there is no
   need to validate Cookie Jar requests. A perpetrator might intercept,
   modify and replay portions of Cookie Jar replies or subsequent
   messages exchanged between the associates. However, presuming the
   perpetrator does not know the keys involved, tampered messages would
   fail the checksum test and be discarded.

アクセスリストが公共の書き込み禁止であると考えられるので、Cookie Jar要求を有効にする必要は全くありません。 加害者は、仲間の間で交換されたCookie Jar回答かその後のメッセージの部分を妨害して、変更して、再演するかもしれません。 しかしながら、加害者が、キーがかかわったのを知らないと推定して、いじられたメッセージは、チェックサムテストに失敗して、捨てられるでしょう。

   The "natural" selection of Internet checksum algorithm and DES
   encryption should be reconsidered. The Internet checksum has several
   well-known vulnerabilities, including invariance to word order and
   byte swap. In addition, the checksum field itself is only sixteen
   bits wide, so a determined perpetrator might be able to discover the
   key simply by examining all possible permutations of the checksum
   field. However, the procedures proposed herein are not intended to
   compensate for weaknesses of the checksum algorithm, since this
   vulnerability exists whether authentication is used or not. Also note
   that the encrypted fields include the sequence number as well as the
   checksum. In EGP and the proposed DGP the sequence number is a
   sixteen-bit quantity and increments for each successive message,
   which makes tampering even more difficult.

インターネットチェックサムアルゴリズムとDES暗号化の「自然な」選択は再考されるべきです。 インターネットチェックサムには、注文とバイトがスワップされるという単語に不変性を含むいくつかのよく知られる脆弱性があります。 さらに、チェックサム分野自体が幅16ビットであるだけであるので、断固とした加害者は単にチェックサム分野のすべての可能な順列を調べることによって、キーを発見できるかもしれません。 しかしながら、ここに提案された手順がチェックサムアルゴリズムの弱点を補うことを意図しません、認証が使用されているか否かに関係なく、この脆弱性が存在しているので。 また、暗号化された分野がチェックサムと同様に一連番号を含んでいることに注意してください。 EGPと提案されたDGPでは、一連番号は、16ビットの量とそれぞれの連続したメッセージのための増分です。(それは、改ざんをさらに難しくします)。

   In the intended application to EGP, DGP and similar protocols
   associations may have an indefinite lifetime, although messages may
   be sent between associates on a relatively infrequent basis.
   Therefore, every association should be rekeyed occasionally, which
   can be done by either associate simply by sending a new request to
   the Cookie Jar and following the above procedure. To protect against
   stockpiling private user keys, each user should be rekeyed
   occasionally, which is equivalent to changing passwords. The
   mechanisms for doing this are beyond the scope of this proposal.

EGPへの意図しているアプリケーションでは、DGPと同様のプロトコル協会は無期生涯を持っているかもしれません、比較的珍しいベースで仲間の間にメッセージを送るかもしれませんが。 したがって、あらゆる協会が時折「再-合わせ」られるべきです(どちらの仲間も単に、新しい要求をCookie Jarに送って、上の手順に従うことでできます)。 個人的なユーザキーを備蓄しないように保護するために、各ユーザは時折「再-合わせ」られるべきです(パスワードを変えるのに同等です)。 これをするためのメカニズムはこの提案の範囲を超えています。

   It is a feature of this scheme that the private user keys are not
   disclosed, except to the Cookie Jar. This is why two cookies are
   used, one for i, which only it can decrypt, and the other for j,
   decrypted first by i and then by j, which only then is valid. An
   interceptor posing as i and playing back the Cookie Jar reply to j
   will be caught, since the message will fail the checksum test. A
   perpetrator with access to both the Cookie Jar reply to i and the
   subsequent message to j will see essentially a random permutation of

Cookie Jarを除いて、明らかにされて、それは個人的なユーザキーがないこの体系の特徴です。 これは、2個のクッキーが使用されている理由と、iのための1つと、最初に、iとそして、jによって解読されたjのための次に有効であるだけであるもう片方です。(それだけがそれを解読することができます)。 私とCookie Jarを再生するのがjに答えるのでポーズをとる迎撃戦闘機は捕らえられるでしょう、メッセージがチェックサムテストに失敗するので。 iに関するCookie Jar回答とjへのその後のメッセージが本質的には無作為の順列を見る両方へのアクセスの加害者

Mills                                                           [Page 5]

RFC 1004                                                      April 1987

1987年4月にRFC1004を製粉します[5ページ]。

   all fields. In all except the first message to the Cookie Jar, the
   checksum field is encrypted, which makes it difficult to recover the
   original contents of the cookie fields before encryption by
   exploiting the properties of the checksum algorithm itself.

すべての分野。 Cookie Jarへの最初のメッセージを除いて、チェックサム分野は全部で、暗号化されています(暗号化の前にチェックサムアルゴリズム自体の特性を利用することによってクッキー分野に関するオリジナルコンテンツを回復するのを難しくします)。

   The fact that the addresses in the message headers are included in
   the checksum protects against playbacks with modified addresses.
   However, it may still be possible to destabilize an association by
   playing back unmodified messages from prior associations. There are
   several possibilities:

メッセージヘッダーのアドレスがチェックサムに含まれているという事実は変更されたアドレスで再生から守ります。 しかしながら、先の協会から変更されていないメッセージを再生することによって協会を動揺させるのはまだ可能であるかもしれません。 いくつかの可能性があります:

      1. Replays of the Cookie Jar messages 1 and 2 are unlikely to
      cause damage, since the requestor matches both the addresses and
      once-only sequence number with its list of pending requests.

1. マッチの要請者両方以来メッセージ1と2が引き起こしそうにないCookie Jarの再生は未定の要求のリストでアドレスとかつて唯一の一連番号を破損します。

      2. Replays of message 3 may cause user j to falsely assume a new
      association. User j will return message 4 encrypted with the
      assumed session key, which might be an old one or even a currently
      valid one, but with invalid sequence number. Either way, user i
      will ignore message 4.

2. メッセージ3の再生で、ユーザjは間違って新連合を仮定するかもしれません。 ユーザjは古いものか現在有効なものでさえあるかもしれない想定されたセッションキーにもかかわらず、無効の一連番号で暗号化されたメッセージ4を返すでしょう。 いずれにせよ、ユーザiはメッセージ4を無視するでしょう。

      3. Replays of message 4 or subsequent messages are unlikely to
      cause damage, since the sequence check will eliminate them.

3. 系列チェックがそれらを排除するので、メッセージ4かその後のメッセージの再生は損害を与えそうにはありません。

   The second point above represents an issue of legitimate concern,
   since a determined attacker may stockpile message 3 interceptions and
   replay them at speed. While the attack is unlikely to succeed in
   establishing a working association, it might produce frequent
   timeouts and result in denial of service. In the Needham-Shroeder
   scheme this problem is avoided by requiring an additional challenge
   involving a message sent by user j and a reply sent by user i, which
   amounts to a three-way handshake.

上の2番目のポイントは当然の懸念の問題を表します、断固とした攻撃者がメッセージ3妨害を備蓄して、速度でそれらを再演するかもしれないので。 攻撃が、働く協会を設立するのに成功していそうにない間、それはサービスの否定における頻繁なタイムアウトと結果を生むかもしれません。 ニーダム-Shroeder計画では、この問題は、ユーザjによって送られたメッセージにかかわる追加挑戦とユーザiによって送られた回答を必要とすることによって、避けられます。(回答は3方向ハンドシェイクに達します)。

   However, even if a three-way handshake were used, the additional
   protocol overhead induced by a determined attacker may still result
   in denial of service; moreover, the protocol model is inherently
   resistant to poor network performance, which has the same performance
   signature as the attacker. The conclusion is that the additional
   expense and overhead of a three-way handshake is unjustified.

しかしながら、3方向ハンドシェイクが使用されたとしても、断固とした攻撃者によって引き起こされた追加議定書オーバーヘッドはまだサービスの否定をもたらしているかもしれません。 そのうえ、プロトコルモデルは本来不十分なネットワーク性能に抵抗力があります。(それは、攻撃者と同じ性能署名を持っています)。 結論は3方向ハンドシェイクの追加費用とオーバーヘッドが不正であるということです。

4. Application to EGP and DGP

4. EGPとDGPへのアプリケーション

   This scheme can be incorporated in the Exterior Gateway Protocol
   (EGP) [2] and Dissimilar Gateway Protocol (DGP) [3] models by adding
   the fields above to the Request and Confirm messages in a
   straightforward way. An example of how this might be done is given in
   [3]. In order to retain the correctness of the state machine, it is

簡単な方法でRequestへの上記の分野とConfirmメッセージを加えることによって、Exteriorゲートウェイプロトコル(EGP)[2]とDissimilarゲートウェイプロトコル(DGP)[3]モデルにこの計画を取り入れることができます。 これがどう完了しているかもしれないかに関する例は[3]で出されます。 州のマシンの正当性を保有するために、それは保有します。

Mills                                                           [Page 6]

RFC 1004                                                      April 1987

1987年4月にRFC1004を製粉します[6ページ]。

   convenient to treat the Cookie Jar reply as a Start event, with the
   understanding that the Cookie Jar request represents an extrinsic
   event which evokes that response.

Cookie Jarがその応答を喚起する付随的な出来事を表すよう要求する理解があるStart出来事としてCookie Jar回答を扱うために、便利です。

   The neighbor-acquisition strategy intended in the Dissimilar Gateway
   Protocol DGP follows the strategy in EGP. The stability of the EGP
   state machine, used with minor modifications by DGP, was verified by
   state simulation and discussed in an appendix to [2]. Either
   associate can send a Request command at any time, which causes both
   the sender and the receiver to reinitialize all state information and
   send a Confirm response. In DGP the Request operation involves the
   Cookie Jar transaction (messages 1 and 2) and then the Request
   command itself (message 3). In DGP the keys are reinitialized as well
   and each retransmission of a Request command is separately
   authenticated.

DissimilarゲートウェイプロトコルDGPで意図する隣人企業買収戦略はEGPの戦略に従います。 小さい方の変更と共にDGPによって使用されたEGP州のマシンの安定性について、州のシミュレーションで確かめられて、付録で[2]と議論しました。 どちらの仲間も、いつでもRequestコマンドを送って、Confirm応答を送ることができます。(送付者と受信機の両方がコマンドですべての州の情報を再初期化します)。 DGPに、Request操作は、Cookie Jar取引(メッセージ1と2)にかかわって、次に、Requestコマンド(メッセージ3)自体にかかわります。 DGPでは、また、キーは再初期化されます、そして、Requestコマンドの各「再-トランスミッション」は別々に認証されます。

   In DGP the Request command (message 3) and all subsequent message
   exchanges assume the keys provided by the Cookie Jar. Use of any
   other keys results in checksum discrepancies and discarded messages.
   Thus the sender knows its command has been effected, at least at the
   time the response was sent. If either associate lost its state
   variables after that time, it would ignore subsequent messages and it
   (or its associate) would eventually time out and reinitiate the whole
   procedure.

DGPでは、Requestコマンド(メッセージ3)とすべてのその後の交換処理がCookie Jarによって提供されたキーを仮定します。 いかなる他のキーの使用もチェックサム食い違いと捨てられたメッセージをもたらします。 したがって、送付者は、コマンドが少なくとも応答が送られた時代に作用したのを知っています。 どちらの仲間もそれ以後州の変数を失うなら、その後のメッセージを無視して、結局無視するだろう、タイムアウト、全体の手順を再開始します。

   If both associates attempt to authenticate at the same time, they may
   wind up with the authentication sequences crossing in the network.
   Note that the Request message is self-authenticating, so that if a
   Request command is received by an associate before the Confirm
   response to an earlier Request command sent by that associate, the
   keys would be reset.  Thus when the subsequent Confirm response does
   arrive, it will be disregarded and the Request command resent
   following timeout. The race that results can only be broken when, due
   to staggered timeouts, the sequences do not cross in the network.
   This is a little more complicated than EGP and does imply that more
   attention must be paid to the timeouts.

両方が同時に認証する試みを関連づけるなら、認証系列がネットワークで交差して、彼らは終わるかもしれません。 Requestメッセージが自己認証であることに注意してください、Requestコマンドがその仲間によって送られた以前のRequestコマンドへのConfirm応答の前に仲間によって受け取られるなら、キーがリセットされるように。 したがって、その後のConfirm応答が到着すると、それは無視されるでしょう、そして、Requestはタイムアウトに続くのに憤慨するように命令します。 よろめかせられたタイムアウトのため、系列がネットワークで交差しないときだけ、結果として生じるレースは壊すことができます。 これは、EGPより複雑であり、より多くの注意をタイムアウトに向けなければならないのを含意します。

   A reliable dis-association is a slippery concept, as example TCP and
   its closing sequences. However, the protocol model here is much less
   demanding. The usual way an EGP association is dissolved is when one
   associate sends a Cease command to the other, which then sends a
   Cease-ack response; however, this is specifically assumed a non-
   reliable transaction, with timeouts specified to break retry loops.
   In any case, a new Request command will erase all history and result
   in a new association as described above.

信頼できるA、協会をけなす、例のTCPとその終わりの系列としての滑りやすい概念はそうです。 しかしながら、ここのプロトコルモデルはあまりそれほど過酷ではありません。 EGP協会が解散する普通の方法は1人の仲間がもう片方へのCease-ack応答がその時発信するCeaseコマンドを送る時です。 しかしながら、これはタイムアウトがリトライループを壊すために指定されている非信頼できる取引であると明確に思われます。 どのような場合でも、新しいRequestコマンドは上で説明されるように新連合ですべての歴史と結果を消すでしょう。

   Other than the above, the only way to reliably dis-associate is by
   timeout. In this protocol model the associates engage in a

上記を除いて、確かに分離する唯一の方法はタイムアウトを使用します。 仲間がaに従事しているこのプロトコルモデルで

Mills                                                           [Page 7]

RFC 1004                                                      April 1987

1987年4月にRFC1004を製粉します[7ページ]。

   reachability protocol, which requires each to send a message to the
   other from time to time. Each associate individually times out after
   a period when no messages are heard from the other.

可到達性プロトコル。(そのプロトコルは、時々メッセージをもう片方に送るためにそれぞれを必要とします)。 それぞれ、メッセージが全くもう片方から聞かれない1回の時代の回後に個別に関連づけます。

5. Acknowledgments

5. 承認

   Dan Nessett and Phil Karn both provided valuable ideas and comments
   on early drafts of this report. Steve Kent and Dennis Perry both
   provided valuable advice on its review strategy.

ダンNessettとフィルKarnはともにこのレポートの早めの草稿の貴重な考えとコメントを提供しました。 スティーブ・ケントとデニスPerryはレビュー戦略でともに有益な助言を提供しました。

6. References

6. 参照

   [1]  Kent, S.T., "Encryption-Based Protection for Interactive
        User/Computer Communication", Proc. Fifth Data Communications
        Symposium, September 1977.

[1] ケント、S.T.、「対話的なユーザ/コンピュータコミュニケーションのための暗号化ベースの保護」、Proc。 1977年9月の第5データ通信シンポジウム。

   [2]  Mills, D.L., "Exterior Gateway Protocol Formal Specification",
        DARPA Network Working Group Report RFC-904, M/A-COM Linkabit,
        April 1984.

[2] 工場、D.L.、「外のゲートウェイプロトコル形式仕様」、DARPAネットワーク作業部会は、RFC-904、M/が1COM Linkabitであると報告して、4月は1984です。

   [3]  Mills, D.L., "Dissimilar Gateway Protocol Draft Specification",
        in preparation, University of Delaware.

[3]工場、D.L.、準備、デラウエア大学の「異なったゲートウェイプロトコル草稿仕様。」

   [4]  National Bureau of Standards, "Data Encryption Standard",
        Federal Information Processing Standards Publication 46, January
        1977.

[4]規格基準局、「データ暗号化規格」、連邦政府の情報処理規格公表46、1月1977日

   [5]  Needham, R.M., and M.D. Schroeder, "Using Encryption for
        Authentication in Large Networks of Computers", Communications
        of the ACM, Vol. 21, No. 12, pp. 993-999, December 1978.

[5] ニーダム、R.M.、およびM.D.シュローダー、「認証にコンピュータの大きいネットワークに暗号化を使用します」、ACM、Vol.21、No.12、ページのCommunications 993-999と、1978年12月。

   [6]  Postel, J., "Internet Protocol", DARPA Network Working Group
        Report RFC-791, USC Information Sciences Institute, September
        1981.

[6] ポステル、J.、「インターネットプロトコル」、DARPAネットワークワーキンググループレポートRFC-791、科学が1981年9月に設けるUSC情報。

Mills                                                           [Page 8]

工場[8ページ]