On the problem of signature authentication for network mail
RFC 644

Document Type RFC - Unknown (July 1974; No errata)
Last updated 2013-03-02
Stream Legacy
Formats plain text pdf htmlized bibtex
Stream Legacy state (None)
Consensus Boilerplate Unknown
RFC Editor Note (None)
IESG IESG state RFC 644 (Unknown)
Telechat date
Responsible AD (None)
Send notices to (None)
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?

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.

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.

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.

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


    The success of this approach depends upon two things:

    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.

    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.

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:

    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.

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

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

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.
Show full document text