RFC 644

On the Problem of Signature Authentication for Network Mail ✨

Network Working Group 🎀 Request for Comments: 644 🦋 Author: Bob Thomas (BBN-TENEX) 💖 Date: Jul 1974. This one has no category, and it doesn't obsolete or update anything. It's just a note, bestie 🫶

okay so this note is all about signature authentication for network mail 📬 It explains the problem, gives a general approach, and then proposes one specific way to make it work. Let's go 💅

---

1. The Problem 💌

The core question is this 👀

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 care about signature authenticity in the network context 🌐 For this note, we're just going to assume that local mail (messages from one user to another on the same host) is already sorted out 🙈 Basically, each host either thinks this problem matters and guarantees signatures on local mail, or it doesn't care and doesn't guarantee anything. Either way, it'll make sense how that connects to the network version as we go ✨

Here's the simple model we're using 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 network mail setup, the receiving process RP is usually an FTP server process 🧚 On the TENEX side, the sending process SP is either a process running SNDMSG, or a "background" MAILER process that sends "queued" mail (stuff that was posted earlier but hasn't been delivered yet) 📮

---

2. An Approach 🌸

We want a solution that lets RP, the receiving process, mark the signature on each incoming message as either authenticated or not, with respect to SH, the sending host 💅 If RP can do that, a user reading mail at RH can see on each message whether the signature was authenticated against the originating host 👀 The authenticity of that signature is the originating host's responsibility 🏠 How much a user trusts a message marked as authentic can be based on how much they personally trust the source host's user authentication and access control mechanisms 🔐

The whole approach depends on two things 🫶

• a. Users need to form their own opinions on how secure each host's user authentication and access control mechanisms are. This is already happening on the ARPANET, since users who care about data privacy and security are doing exactly that ✨
• b. RP needs a way to tell apart mail that was authenticated by the sending host from mail that wasn't. So there needs to be a mechanism that lets a properly authorized (by the sending host) mail sending process identify itself to the receiving process as one 🎀 RP can then mark that mail as authentic. Unauthorized processes (like a regular user process pretending to be an authorized mail sender) might still try to send mail to mailboxes at RH 🙄 In that case, RP gets to choose: refuse the message, or accept it and mark it as unauthenticated 🚫

---

3. Proposed Implementation of Approach 🧚‍♀️

Passwords are one obvious way to do sending-process authentication 🔑 Only an authorized sending process would know the password, so it could identify itself properly to the receiving process. BUT 😤 the note rejects passwords as operationally impractical, for these reasons:

• a. The password has to be stored in the sending program, or at least be reachable by it somehow. That makes it more likely the password's privacy gets compromised 😭
• b. If a password leaks, it has to be changed on both the sending and receiving hosts. That's a synchronization problem 🙃
• c. Really secure mail would probably need a password for every pair of hosts. For an N host network, that's N*N passwords 💀

So instead, the proposal is to base authentication on the communication path itself between the sending and receiving processes 🛤️ On 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 figure out the host-socket pair at the remote end of its path ✨

Here's the key idea 👑 The receiving process treats the sender as a properly authorized (by the sending host) mail sender only if the sending end of the path is one of the socket(s) reserved for sending authenticated mail. Those sockets get reserved through prior host agreement 🤝

Splitting up the responsibilities 💖

The sending host's job is to make sure only authorized mail sending processes can get to the mail sending socket(s) 🚪

The user who cares about their mail's authenticity has a job too: understand that "authentic" means the sending host figured out who the sender was, and that the signature is only as good (or as bad) as that host's user authentication and access control procedures 🧐

---

4. Additional Remarks 🎀

• a. Using sockets for process authentication isn't a new idea on the ARPANET 🙌 By host agreement, the TELNET logger process answers connections on socket #1, the FTP logger process on socket #3, and so on. Honestly, the privacy of network mail depends on how well the host controls access to the FTP logger socket 🔒 The receiving process is considered authentic because it's the process you reach by ICP'ing to socket #3. This note proposes using that same mechanism to authenticate mail sending processes too 💅
• b. Planned TENEX Experiment 🧪 A set of sockets has been set aside for mail transmission (all numbers are decimal):

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

The plan is to modify TENEX's mail sending, receiving and reading software the way this note describes 🛠️ Mail that TENEX sends to remote hosts, and that counts as authentic (with respect to TENEX), gets sent by initiating the ICP to the remote FTP server socket 232 ✨ Mail TENEX receives from remote hosts only gets marked as authentic if the ICP to the TENEX FTP server was started from remote socket 232 💌 The TENEX mail reading software will show, for each message, whether its signature was source authenticated or not 👀

• c. Contention for the Mail Sending Socket 🚦 Depending on how the sending host's NCP and its network mail sending software are built, several users sending network mail at the same time might end up fighting over the single ICP "from" socket 😩 If that turns out to be a real problem in practice, a set of ICP "from" sockets could be reserved for authenticated network mail instead 🫶
• d. Local mail signature authentication is pretty much its own separate problem from the network one we've been talking about 🙃 A few observations:
  1. Users on a host that doesn't authenticate local mail probably shouldn't expect that host to reliably deliver authenticated network mail to them 😬 Since local mail isn't authenticated, a malicious local user could drop forged messages into other users' mailboxes. Those forgeries would look exactly like network mail and get marked as authentic the same way the host's receiving process marks mail 💀
  2. A host with strong user authentication procedures that also authenticates local mail isn't automatically a reliable source of authenticated network mail 🤷‍♀️ To be reliable, it has to limit access to the net mail transmission socket(s) to authorized mail sending processes 🔐
  3. A host that doesn't support authentic local mail could still be a reliable source of authentic net mail 🌈

---

That's the whole note, bestie 💜 Sockets, not passwords, doing the authenticating. Iconic 👑