As per Relevance of the word receiving, we have this rfc below:
Network Working Group Bob
Request for Comments: 644 BBN-
Jul 1974
On the Problem of Signature Authentication for Network
This note describes the problem of signature authentication for
mail, presents a general approach to the problem and proposes a specific
implementation of that approach
1. The
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)
authentic; that is, that the message is really from whom
claims to be
We are interested in the problem of signature authenticity in the
context. For purposes of this note we shall assume a solution to
signature authentication problem for local mail (i.e., messages from
user to another within a single host). That is, we assume that for
host, either the host regards the problem as important and has a
for guaranteeing signatures on local mail or that the host does not regard
problem as important and does not guarantee signature authentication.
should become clear how this assumption relates to our approach to the
signature problem
We shall discuss our approach using the following simple model for
mail
To send net mail a user invokes a mail sending process (SP)
his local host (SH). The process SP acts on behalf of the
to deliver the message to an appropriate mailbox at
receiving host (RH). It does that by interacting with
receiving process (RP) that runs on host RH. RP accepts
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
We seek a solution which will allow RP, the receiving process, to
the signature on messages it receives as authenticated or not
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
message as authenticated or not with respect to the host of origin.
authenticity of the signature on a piece of mail is understood to be
responsibility of the originating host. The credibility a user gives
particular message which is marked as authentic can be based on the user'
own estimate of the source host's user authentication and access
mechanisms
-1-
The success of this approach depends upon two things
a. Users develop estimates of the security of various host
authentication and access control mechanisms. We have seen
users who are concerned about data privacy and security
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
sending host from mail that has not been authenticated by
sending host. That is, a mechanism is required which will allow
properly authorized (by the sending host) mail sending process
identify itself as such to the mail receiving process.
receiving process can then mark mail from such an
process as authentic. Nonauthorized processes (e.g., a
process attempting to pose as an authorized mail sending process
may try to send mail to mailboxes at RH; in such a case
receiving process has the option of refusing to accept the
or accepting them marking them as unauthenticated
3. Proposed Implementation of
The use of passwords is one possible way to accomplish sending
authentication. Only an authorized sending process would know the
and thus be able to properly identify itself to a mail receiving process
We reject the password mechanism as operationally impractical for the
reasons
a. Use of a password requires that the password be stored
the sending program or be accessible to it in some way
increasing the likelihood that the privacy of such a password
be compromised
b. If a password is compromised, it must be changed at
sending and receiving hosts; a synchronization problem
c. Truly secure mail would probably require passwords for
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
authentication, we propose that authentication be based on
communication path itself between the sending and receiving process
In the ARPANET, a communication path is uniquely identified by its
ends: the send host-socket pair and the receive host-socket pair.
process can accurately determine the host-socket pair at the remote
of a communication path. We propose that the receiving
consider the sending process to be a properly authorized (by
sending host) sender of mail only if the sending end of
communication path is (one of) the socket(s) reserved for
of authenticated mail. The mail sending socket(s) would be
by prior host agreement
-2-
The responsibility of the sending host is to allow only
mail sending processes to access the mail sending socket(s).
responsibility of the user concerned about the authenticity of
mail is to understand that mail marked as authentic means that
sending host has determined the identity of the sender and that
signature on such mail is only as good or bad as the user
and access control procedures of the sending host
4. Additional
a. The use of sockets for process authentication is not a new
within the ARPANET. By host agreement, the TELNET logger
responds to connections to socket #1, the FTP logger process to
#3, etc. In fact, the privacy of net mail depends upon how well
host controls access to the FTP logger socket; that is,
authenticity of the mail receiving process is based upon that
that it is the process reached by ICP'ing to socket #3. This
proposes that the same mechanism be used to provide authentication
mail sending processes
b. Planned TENEX
A set of sockets has been assigned for mail transmission. They
(all numbers are decimal
ICP "from" socket - 232
FTP user command sockets: receive, send = 234, 235
Default data transfer (user, send) socket = 237
We intend to modify the TENEX mail sending, receiving and
software as suggested above. Mail sent by TENEX to remote
which is authentic (with respect to TENEX) will be sent by
the ICP to the remote FTP server socket 232. Mail received
remote hosts will be marked as authentic only if the ICP to the
FTP server was initiated from remote socket 232. The TENEX
reading software will indicate for each message whether or not
signature on the message was source authenticated
c. Contention for the Mail Sending
Depending upon the implementation of the sending host's NCP
its mail net sending software, it may be the case that several
concurrently sending network mail may be competing for the
ICP "from" socket. If socket contention turns out to be a
problem in practice, a set of ICP "from" sockets could be
for authenticated network mail
d. The local mail signature authentication problem is nearly
of the network mail signature authentication problem as we
discussed it. For example, the following observations can be made
-3-
1. The local users of a host which does not authenticate local
probably should not expect the host to reliably
authenticated network mail to them. Because local mail is
authenticated, it is likely that a malicious local user
add to other users' mail boxes forged messages which are
identically to net mail and are marked as authentic in the
the host's mail receiving process marks mail
2. A host that has strong user authentication procedures
authenticates local mail is not necessarily a reliable
of authenticated network mail. In order to be a reliable source
it must limit access to the net mail transmission socket(s)
authorized mail sending processes
3. A host which does not support local authentic mail could be
reliable source of authentic net mail
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
