spf-discuss
[Top] [All Lists]

Back to the future (email path authentication in 1975)

2005-06-30 04:48:22

On the topic of history of email authentication I came on to the following:

---------------------------------------------------------------------------
http://www.ietf.org/rfc/rfc644.txt
 Network Working Group                                   Bob Thomas
 Request for Comments: 644                               BBN-TENEX
                                                        Jul 1974

     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

   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?
 ....

 2.  An Approach

 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.
 ...
 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.
 ...
 3.  Proposed Implementation of Approach

 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:
 ...
 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.

 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
 ....
    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:

        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.

        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.

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

--------------------------------------------------------------------------

Am I dreaming or is almost all of the above still true? If so it seems it took Internet only about 30 years to start practical work on the proposed
solution to the problem :)

--
William Leibzon
Elan Networks
william(_at_)elan(_dot_)net


<Prev in Thread] Current Thread [Next in Thread>