RFC644 日本語訳

Network Working Group                                   Bob Thomas
Request for Comments: 644                               BBN-TENEX
                                                        Jul 1974

コメントを求めるワーキンググループボブトーマスRequestをネットワークでつないでください: 644 BBN-TENEX1974年7月

     On the Problem of Signature Authentication for Network Mail

ネットワークメールのための署名認証の問題に関して

This note describes the problem of signature authentication for network
mail, presents a general approach to the problem and proposes a specific 
implementation of that approach.

この注意は、ネットワークメールのための署名認証の問題について説明して、問題への一般的方法を提示して、そのアプローチの特定の実装を提案します。

1. The Problem

1. 問題

   The problem we wish to consider is:

考えたいと思う問題は以下の通りです。

      How can the recipient of a network mail message be "certain"
      that the signature (e.g., the name in the "FROM" field) is
      authentic; that is, that the message is really from whom it
      claims to be?

ネットワークメール・メッセージの受取人は、署名(例えば、“FROM"分野の名前)が正統であることをどのように「あるであることができるか」。 すなわち、本当にそれが、だれを主張するかからメッセージがありますか?

We are interested in the problem of signature authenticity in the network
context.  For purposes of this note we shall assume a solution to the
signature authentication problem for local mail (i.e., messages from one
user to another within a single host).  That is, we assume that for any
host, either the host regards the problem as important and has a mechanism
for guaranteeing signatures on local mail or that the host does not regard the
problem as important and does not guarantee signature authentication.  It
should become clear how this assumption relates to our approach to the network
signature problem.

私たちはネットワーク文脈における署名の信憑性の問題に興味を持っています。 この注意の目的のために、私たちはローカルのメール(すなわち、独身のホストの中の1人のユーザから別のユーザまでのメッセージ)のための署名認証問題にソリューションを仮定するつもりです。 すなわち、私たちは、ホストがどんなホストに関しても、ホストが問題が重要であるとみなして、ローカルのメールで署名を保証するためのメカニズムを持つか、問題が重要であるとみなさないで、またまたは署名認証を保証しないと思います。 それはこの仮定がどのようにネットワーク署名問題への私たちのアプローチに関連するかが明確になるべきです。

We shall discuss our approach using the following simple model for network
mail:

私たちはネットワークメールに以下の単純モデルを使用することでアプローチについて議論するつもりです:

      To send net mail a user invokes a mail sending process (SP) on
      his local host (SH).  The process SP acts on behalf of the user
      to deliver the message to an appropriate mailbox at the
      receiving host (RH).  It does that by interacting with a
      receiving process (RP) that runs on host RH.  RP accepts the
      message from SP and deposits it in the appropriate mailbox.

ネットのメールにユーザを送るのは、彼のローカル・ホスト(SH)にプロセス(SP)を送りながら、メールを呼び出します。 プロセスSPは、受信ホスト(RH)で適切なメールボックスにメッセージを提供するためにユーザを代表して行動します。 それは、ホストRHの上で作業する受信プロセス(RP)と対話することによって、それをします。 RPはSPからメッセージを受け入れて、適切なメールボックスにそれを預けます。

In the current implementation of network mail, the receiving process RP is 
typically an FTP server process.  For the current TENEX implementation the 
mail sending process SP is either a process running SNDMSG or a "background" 
MAILER process which sends "queued" (previously posted but undelivered) mail.

ネットワークメールの現在の実装では、通常、受信プロセスRPはFTPサーバプロセスです。 現在のTENEX実装のために、メール送付プロセスSPは「列に並ばせられた」(以前に、掲示されますが、非提供される)メールを送るプロセス実行SNDMSGか「バックグラウンド」メイラープロセスのどちらかです。

2.  An Approach

2. アプローチ

We seek a solution which will allow RP, the receiving process, to mark
the signature on messages it receives as authenticated or not with
respect to SH, the sending host.  If RP can so mark incoming messages,
a user reading his mail at RH would be able to see the signature on each
message as authenticated or not with respect to the host of origin.  The
authenticity of the signature on a piece of mail is understood to be 
responsibility of the originating host.  The credibility a user gives a
particular message which is marked as authentic can be based on the user's
own estimate of the source host's user authentication and access control
mechanisms.
                                     -1-

私たちはRP、受信プロセスがSH(送付ホスト)に関して認証されるようにそれが受け取るメッセージに署名をマークできるソリューションを求めます。 したがって、RPが入力メッセージをマークできるなら、RHで彼のメールを読んでいるユーザは認証されるように各メッセージで発生源のホストに関して署名を見ることができるでしょう。 メールの断片における署名の信憑性は送信元ホストの責任であることが理解されています。 ユーザが正統であるとしてマークされる特定のメッセージを与える真実性がユーザのアクセス管理機構送信元ホストのユーザー認証と-1の自己の見積りに基づくことができる、-

    The success of this approach depends upon two things:

このアプローチの成功は2つのものによります:

    a.  Users develop estimates of the security of various host user
        authentication and access control mechanisms.  We have seen that
        users who are concerned about data privacy and security are
        already doing this within the ARPANET.

a。 ユーザは様々なホストユーザー認証とアクセス管理機構のセキュリティの見積りを発生します。私たちは、データプライバシーとセキュリティに関して心配しているユーザがアルパネットの中で既にこれをしているのを見ました。

    b.  The existence of a mechanism which RP, the receiving process,
        can use to distinguish mail authenticated with respect to the
        sending host from mail that has not been authenticated by the
        sending host.  That is, a mechanism is required which will allow a
        properly authorized (by the sending host) mail sending process to
        identify itself as such to the mail receiving process.  The
        receiving process can then mark mail from such an authenticated
        process as authentic.  Nonauthorized processes (e.g., a user
        process attempting to pose as an authorized mail sending process)
        may try to send mail to mailboxes at RH; in such a case the
        receiving process has the option of refusing to accept the message
        or accepting them marking them as unauthenticated.

b。 RP(受信プロセス)が送付ホストによって認証されていないメールと送付ホストに関して認証されたメールを区別するのに使用できるメカニズムの存在。 すなわち、適切に認可された(送付ホストで)メール送付プロセスがそういうものとしてメール受信プロセスにそれ自体を特定できるメカニズムが必要です。 そして、受信プロセスは正統であるような認証されたプロセスからのメールにマークできます。 Nonauthorizedプロセス(例えば、認可されたメール送付プロセスのふりをするのを試みるユーザ・プロセス)はRHのメールボックスにメールを送ろうとするかもしれません。 このような場合には受信プロセスには、メッセージを受け入れるのを拒否するか、または非認証されるようにそれらをマークしながらそれらを受け入れるオプションがあります。

3.  Proposed Implementation of Approach

3. アプローチの提案された実装

The use of passwords is one possible way to accomplish sending process
authentication.  Only an authorized sending process would know the password
and thus be able to properly identify itself to a mail receiving process.
We reject the password mechanism as operationally impractical for the following
reasons:

パスワードの使用は送付プロセス認証を実行する1つの可能な方法です。 認可された送付プロセスだけが、パスワードを知って、その結果、適切にメール受信プロセスにそれ自体を特定できるでしょう。 私たちは、パスワードメカニズムが以下の理由で操作上非実用的であると拒絶します:

    a.  Use of a password requires that the password be stored in
        the sending program or be accessible to it in some way thereby
        increasing the likelihood that the privacy of such a password will
        be compromised.

a。 パスワードの使用は、パスワードがそのようなパスワードのプライバシーが感染される可能性を広げるのにおいて送付プログラムに保存されるか、またはその結果、何らかの方法でそれにアクセス可能であることを必要とします。

    b.  If a password is compromised, it must be changed at both
        sending and receiving hosts; a synchronization problem.

b。 パスワードに感染するなら、発信と受信ホストの両方でそれを変えなければなりません。 同期問題。

    c.  Truly secure mail would probably require passwords for each
        pair of hosts; this requires N*N passwords for an N host network.

c。 本当に安全なメールはホストの各組のためにたぶんパスワードを必要とするでしょう。 これはNホストネットワークのためのN*Nパスワードを必要とします。

As an alternative to the use of passwords as a means for process
authentication, we propose that authentication be based on the
communication path itself between the sending and receiving process.
In the ARPANET, a communication path is uniquely identified by its two
ends: the send host-socket pair and the receive host-socket pair.  A
process can accurately determine the host-socket pair at the remote end
of a communication path.  We propose that the receiving process
consider the sending process to be a properly authorized (by the
sending host) sender of mail only if the sending end of the
communication path is (one of) the socket(s) reserved for transmission
of authenticated mail.  The mail sending socket(s) would be reserved
by prior host agreement.
                                   -2-

手段としてのパスワードのプロセス認証の使用に代わる手段として、私たちは、認証が送付と受信プロセスの間の通信路自体に基づいているよう提案します。 アルパネットでは、通信路は2つの終わりまでに唯一特定されます: そして、ホストソケット組を送ってください、ホストソケット組を受けてください。 プロセスは通信路のリモートエンドで正確にホストソケット組を決定できます。 通信路の送信側が提案する場合にだけ私たちが、受信プロセスが、送付プロセスがメールの適切に認可された(送付ホストで)送付者であると考えるよう提案する、(1つ、)、ソケットは認証されることのトランスミッションのためにメールを予約しました。 メール送付ソケットは先のホスト協定で予約されるでしょう。 -2-

The responsibility of the sending host is to allow only authorized
mail sending processes to access the mail sending socket(s).  The
responsibility of the user concerned about the authenticity of his
mail is to understand that mail marked as authentic means that the
sending host has determined the identity of the sender and that the
signature on such mail is only as good or bad as the user authentication
and access control procedures of the sending host.

送付ホストの責任は認可されたメール送付プロセスだけがメール送付ソケットにアクセスするのを許容することです。 彼のメールの信憑性に関して心配しているユーザの責任はユーザー認証とアクセスが送付ホストの手順を制御するとき、そのようなメールにおける署名が正統であるとしてマークされたメールが、送付ホストが送付者のアイデンティティを決定したことを意味して、同じくらい良いだけであるか、または悪いのを理解することです。

4.  Additional Remarks

4. 付記

    a.  The use of sockets for process authentication is not a new concept
        within the ARPANET.  By host agreement, the TELNET logger process
        responds to connections to socket #1, the FTP logger process to socket
        #3, etc.  In fact, the privacy of net mail depends upon how well the
        host controls access to the FTP logger socket; that is, the
        authenticity of the mail receiving process is based upon that fact
        that it is the process reached by ICP'ing to socket #3.  This note
        proposes that the same mechanism be used to provide authentication of
        mail sending processes.

a。 ソケットのプロセス認証の使用はアルパネットの中の新しい概念ではありません。 ホスト協定で、TELNETきこりのプロセスは接続にソケット#1まで応じます、ソケット#3などへのFTPきこりのプロセス 事実上、ネットのメールのプライバシーはホストがFTPきこりのソケットへのアクセスをどれくらいよく制御するかによります。 すなわち、メール受信プロセスの信憑性はそれがICP'ingによってソケット#3に達せられたプロセスであるというその事実に基づいています。 この注意は、同じメカニズムがプロセスを送りながらメールの認証を提供するのに使用されるよう提案します。

    b.  Planned TENEX Experiment

b。 計画されたTENEX実験

        A set of sockets has been assigned for mail transmission.  They are
       (all numbers are decimal)

1セットのソケットはメール送信のために割り当てられました。 それらはそうです。(すべての数が10進です)

           ICP "from" socket - 232
           FTP user command sockets:  receive, send = 234, 235
           Default data transfer (user, send) socket = 237

ICP “from"ソケット--232 FTPユーザコマンドソケット: 受信してください、そして、=234、235Defaultデータ転送(ユーザは発信する)ソケット=237を送ってください。

        We intend to modify the TENEX mail sending, receiving and reading
        software as suggested above.  Mail sent by TENEX to remote hosts
        which is authentic (with respect to TENEX) will be sent by initiating
        the ICP to the remote FTP server socket 232.  Mail received from
        remote hosts will be marked as authentic only if the ICP to the TENEX
        FTP server was initiated from remote socket 232.  The TENEX mail
        reading software will indicate for each message whether or not the
        signature on the message was source authenticated.

私たちは上に示されるようにソフトウェアを送って、受け取って、読むTENEX郵便配達人を変更するつもりです。 リモートFTPサーバソケット232にICPを開始することによって、リモートホストへの正統の(TENEXに関する)TENEXによって送られたメールを送るでしょう。 TENEX FTPサーバへのICPがリモートソケット232から開始された場合にだけ、リモートホストから受け取られたメールは正統であるとしてマークされるでしょう。 TENEXメール読書ソフトウェアは、各メッセージのためにメッセージにおける署名が認証されたソースであったかどうかを示すでしょう。

    c.  Contention for the Mail Sending Socket

c。 メール送信ソケットのための主張

        Depending upon the implementation of the sending host's NCP and
        its mail net sending software, it may be the case that several users
        concurrently sending network mail may be competing for the single
        ICP "from" socket.  If socket contention turns out to be a serious
        problem in practice, a set of ICP "from" sockets could be reserved
        for authenticated network mail.

ソフトウェアを送る送付ホストのNCPとそのメールネットの実装によって、同時にネットワークメールを送る数人のユーザが単一のICP “from"ソケットを競争しているかもしれないのは、事実であるかもしれません。 ソケット主張が実際には深刻な問題であると判明するなら、1セットのICP “from"ソケットは認証されたネットワークメールのために予約されるかもしれません。

    d.  The local mail signature authentication problem is nearly independent
        of the network mail signature authentication problem as we have
        discussed it.  For example, the following observations can be made:

d。 私たちがそれについて議論したとき、ローカルのメール署名認証問題はネットワークメール署名認証問題からほとんど独立しています。 例えば、以下の観測をすることができます:

                                     -3-
        1.  The local users of a host which does not authenticate local mail
            probably should not expect the host to reliably deliver
            authenticated network  mail to them.  Because local mail is not
            authenticated, it is likely that a malicious local user could
            add to other users' mail boxes forged messages which are formatted
            identically to net mail and are marked as authentic in the way
            the host's mail receiving process marks mail.

-3- 1. 確かに提供するローカルのメールを認証しないものがたぶんホストを予想するべきでないホストの地元のユーザはネットワークメールを彼らに認証しました。 ローカルのメールが認証されないので、悪意がある地元のユーザは、箱が同様にネットのメールにフォーマットされて、ホストのメール受信プロセスがメールにマークする方法で正統であるとしてマークされるメッセージを作り出したと他のユーザのメールに追加できそうです。

        2. A host that has strong user authentication procedures and
           authenticates local mail is not necessarily a reliable source
           of authenticated network mail.  In order to be a reliable source,
           it must limit access to the net mail transmission socket(s) to
           authorized mail sending processes.

2. 強いユーザー認証手順を持って、ローカルのメールを認証するホストは必ず認証されたネットワークメールの信頼すべき筋であるというわけではありません。 信頼すべき筋になるように、それはアクセスを認可されたメール送付プロセスへのネットのメールトランスミッションソケットに制限しなければなりません。

       3.  A host which does not support local authentic mail could be a
           reliable source of authentic net mail.

3. 正統のネットの信頼すべき筋がメールであったかもしれないならローカルの正統のメールをサポートしないホスト。

                                   -4-

-4-