[118429] in Cypherpunks
The Baton Protocol
daemon@ATHENA.MIT.EDU (RProcess)
Mon Sep 27 18:49:22 1999
Date: 27 Sep 1999 21:40:34 -0000
Message-ID: <19990927214034.29123.qmail@nym.alias.net>
From: RProcess <rprocess@nym.alias.net>
To: mail2news_nospam@anon.lcs.mit.edu, potatoware.reliable@listbot.com,
potatoware@listbot.com, remailer-operators@anon.lcs.mit.edu
CC: cypherpunks@cyberpass.net
Reply-To: RProcess <rprocess@nym.alias.net>
The following is a very (read: very) rough sketch of a design for a remailer
system which is not as vulnerable to selective DoS and other attacks. There
is nothing to say this or another system will be built, merely that several
people have asked for my input on what might work so I've scratched out a few
ideas. A colleague may be opening a mailing list soon to discuss 'next
generation' remailers. This is a starter for any discussion which can then
migrate to that list. I would like to hear users' input on this as well as
operators and programmers.
If you missed the bit on Selective DoS, you may want to read that first.
http://www.skuz.net/potatoware/PSKB-035.html
I may write a summary in english as well. <g> Do your best. I was just
trying to get the framework down.
Baton Protocol Description:
"Baton" refers to a baton, as runners pass hand-to-hand from one to the
next. The Baton protocol provides an integrated method for systems of
any platform to 1) transfer encrypted data; 2) authenticate one another
and the data; 3) correct (resend) damaged or unauthentic data. It is
intended as the basic building block of a more resilient and secure
anonymous remailer system.
The Baton Protocol:
0a. An anonuser [anonymous mailer] is defined as an unauthenticated
sender of its own anonymous data. An anonuser may request a
connection but does not receive requests. (Client)
0b. An authuser [nym user] is defined as an authenticated sender or
recipient of its own data. An authuser may request a connection but
does not receive requests. (Server)
0c. A carrier [remailer/nym-server] is defined as an authenticated
sender and recipient of others' data. (Server)
0d. A client (anonuser) is defined as a system (TCP/IP, any
platform, etc.) which establishes a connection without identifying
itself (no public key, no signature). Clients do not receive
connection requests.
0e. A server (authuser or carrier) is defined as a system (TCP/IP,
any platform, etc.) which establishes or receives a connection and
identifies itself with its signature. Each server must have one or
more public encryption/signing key pairs.
0f. A system is defined as a client or server connected to the
internet via TCP/IP (any OS, hardware platform, etc.).
1. Two servers, or one client and one server may establish a direct
connection, refered to as a Baton Direct Connection (BDC).
2. Any system may have a dynamic IP address which is fixed for the
duration of the BDC.
3a. For a BDC to be established the server receiving the connection
request must be in the "ready state", else the BDC is refused with
suitable feedback as to reason for refusal (ie problem, busy, no
BDCs allowed to clients, no permission, etc.)
3b. A carrier may choose to send and/or receive data with only a
select list of systems, and will refuse BDCs with others. This
information is included in the carrier's config file (see 11).
4. BDCs are established by a client when it has data to be sent to
a server, or by a server when it has data to be sent to or retrieved
from a server. If a server has data belonging to an authuser, it
must wait for the authuser to connect and collect the data. If a
server has data belonging to a carrier, it may request a BDC to send
the data. Unsent data may expire.
5a. The system requesting a BDC (a user or carrier) sends a random
session key, algorithm request, a unique session ID, time, its own
current IP, the receiving system's current IP, and reason (send or
receive) encrypted with the receiving system's public key. If the
system requesting connection is a server it must identify itself by
including its Baton identifier (BID) and signing the request.
5b. The receiving server responds with a signed packet containing
its BID, both IP addresses, the time, and whether the authentication
(if required) succeeded. This packet indicates (outside of the
encryption) the algorithm and number of bits used for the
encryption.
6. If there is an authentication error, connection is refused and
all relevant information is logged by both systems.
7. If authentication succeeds, data transmission commences. Data
is encrypted with the session key. Error correction and data
authentication (via digest) is performed at regular intervals.
Unauthentic or damaged data is re-sent. The connection fails if too
many retries occur, and the error is logged with appropriate
information.
8. When the BDC is terminated, successfully or not, minimal general
logging is performed on carrier connections, for diagnsotic
purposes. No logging is performed of anonuser and authuser
connections.
9. Carriers act as "DNS servers". Each time a carrier with a
dynamic IP comes online, it BDCs to any (preferably static) carrier,
identifies itself, supplies its current IP, and requests DNS
propagation. This information is then transferred in a timely
manner to all other carriers. A client or server may BDC to any
carrier and request the last known IP address of any configured
carrier via its BID. (If the carrier limits BDCs to only some
systems (see 3b), only those listed with permission to connect may
receive the IP address.)
10. Each carrier stores a group of configuration files belonging to
servers (carriers and authusers). Each (signed) configuration file
contains:
1. A valid unique Baton identifier (BID) (carrier or authuser
name)
2. The server type (carrier or authuser)
3. Public keys (a server may have multiple keys of different
types, several keys during changing, etc.)
4. Preferred key(s) to be used for encryption
5. Options supported. For carriers, this is the information
client software uses to determine features supported.
6. Contact or Admin Information/Address (optional)
7. Connection types supported (BDC, BEC, BHTTP, BFTP, etc.)
8. Static IP if available (This may be omitted by 'middleman'
type carriers, carriers with dynamic IP addresses, and
authusers.)
9. Baton Email Address (BEA) (For receiving email)
10. Receive BIDs, addresses, allowed to send data (If BIDs are
limited, only those listed may receive the IP of this server
from the 'DNS' subsystem.)
11. Send BIDs, addresses, newsgroups, allowed to receive data
(This information is provided for users, and their software, to
consult)
12. Data handling. Specifies how data received for the server
is to be handled: encrypted, held for BDC, attempt to send BDC,
sent to anonymous BDC chain, BEC, Cypherpunked, Mixmastered,
plain email, messages over a certain size deleted, messages
digested, etc. Carriers may not support all types of message
handling (this information is included in the Options supported
(10-5) of the holding carrier. The data handling section is
used by carriers to specify how messages are to be sent to them
by clients and servers. It is used by authusers to specify how
data (mail) is to be delivered [a reply-block]. The data
handling section may be encrypted to the carriers holding it, in
which case it is unreadable to others downloading the
configuration file.
Servers update their own configuration files by sending the
signed file to the carrier. [The carrier admin may lock server
config files (belonging to carriers for example) and view/verify
update requests manually.] Servers automatically update their
keyrings based on the current config file, removing revoked
keys.
11. Any server (carrier or authuser) may establish a configuration
file on any carrier providing: it has a unique BID not reserved or
in use; and the carrier accepts configs from the server type
(carrier or authuser). Some servers may limit carrier config files
to a select list (see 3b).
12. Servers update their own configuration files by sending the
signed file to the carrier. (The carrier admin may lock server
config files (belonging to carriers for example) and view/verify
update requests manually.)
13. Servers and clients may request a list of carrier config files
held by any carrier, and available carrier config files may be
downloaded. (The signature of the creator on the file is retained
by the carrier holding it.)
14. Some servers accept Baton Email Connections (BEC), an
alternative to sending and receiving data BDC, and/or
Cyherpunk/Mixmaster remail requests, and/or plain mail. (Some
servers can accept only email if they so choose, and not accept
BDCs.) Like BDC, BEC messages are encrypted to the public key of
the server. If sent by a server (carrier or authuser) it is signed
and dated. These are fixed-size packets. Large packets are sent in
parts. If requested, once per day the receiving server sends a
signed message listing packets received. (If the sender does not
receive this acknowledgement, or if packets are missing, they may be
resent.) BEC packets are handled identically to BDC data (see 15).
15. Data received, if it is intended for a configured server
(carrier or authuser) is sent via that server's config file data
handling specification (see 10-12). Data intended for an email
address or newsgroup may be mailed or posted, if supported. (The
latter may be accomplished via a default config file on the server
which handles data to unknown addresses and newsgroups, etc.)
Special data, such as DNS requests and config file requests are also
handled.
16. Some servers handle other connections in real time, supporting
HTTP (BHTTP), FTP (BFTP), etc., allowing the server network to act
as a chained anonymous access proxy, with data originating from
authusers, flowing through carriers, and returning through carriers
to authusers.
A lot of toys cam be built with the Baton protocol:
If I want to run a carrier [remailer], I send my carrier-type config
file to each carrier. I specify in my config who is allowed to connect
to me, and who I will send to. If anyone can connect to me via BEC, I
provide a BEA (email address). If anyone can connect to me via BDC
(including clients and servers), I specify that in my Receive BIDs list.
Likewise I specify who I will send to. If I'm 'middleman' I can limit
the list to selected BIDs. Anyone with my config file can see which
BIDs I will send to.
This also allows some carriers to be 'middle middleman', in that they
can choose to receive and send only to selected BIDs. Their
IP addresses (and thus ISP) is only known to selected carrier operators
(and network watchers). This will help create a fleet of quite
anonymous carriers isolated from the abuse and complaints.
In addition, carriers can specify a chain in the data handling section
[reply-block] which sends the data through other carriers to an authuser
[nym account] on another carrier (which supports authuser config files -
or a "nym-server"). The authuser can BDC (or BEC) to the carrier,
collect the data, process it, and BDC, BEC, email, or post it to its
destination. Thus an authuser [nym account] can be used to run a
carrier with complete anonymity for the admin.
Further, virtual carriers and authusers can be created which send the
data through a chain of carriers, the last of which processes it.
As stated above, authuser config files, sent to carriers which hold
authuser-type config files [nym-servers], create what we call a nym
account. Authuser data handling [reply-block] can send data through a
chain to a final authuser on the same or another carrier (or to an email
address like is done with nym accounts). Authusers can BDC to the
carrier (if it supports BDC from authusers) and retrieve the data. [A
nym-server with a built-in encrypted pop3 server]. By specifying a BEA
people can email the authuser. Or they can send via carriers directly
to his BID on that carrier, so that the message never is in email, never
unencrypted, and never in losable form - all connections are direct with
error checking.
Anyone can run a 'nym-server', even anonymously through an authuser.
One piece of software (on each platform) can act as both client and
server, as many of the functions are duplicated. The client is really a
limited server. Everyone has the ability to set up a carrier by sending
a few carrier and authuser configs. The software would know which
carriers need to be checked for data, and received data intended for
another carrier would be sent.
If it's not clear enough in the protocol description, to send "anonymous
email" my software would form a nested PK encrypted message (much like
Mixmaster) and preferably connect directly to a carrier via BDC. From
there the message would travel from carrier to carrier, and finally to
an authuser [a nym account holder] or to an email address or newsgroup.
Software would have all the information to determine if the destinations
and features at each stage are valid.
To retrieve my 'nym mail' I can either have it emailed to me via BEC, or
I can BDC to the carrier holding my authuser [the nym server] and
retrieve my data. This data could be mine, or if I'm a carrier, data to
be resent or delivered. This could all be handled automatically, with
the operator/user specifying what he wants - authuser 'accounts' or to
run a carrier, etc. The software would know whether the data is mine or
others' data to be sent.
Client software can BDC or BEC to a carrier, or each carrier, and get
all the config files, which the software would process automatically,
checking signatures and updating keyrings (the same code the carrier
part of the software uses to stay up to date).
Problems:
1. It seems like the potential for infinite mail loops might be
there, this would need to be addressed, perhaps using MD5 digests to
prevent repeats.
2. There could be the same BIDs on different carriers (just as we
have the same username in two different domains now). This would be
a problem if they are carriers. Naming conflicts would have to be
resolved if two people try to introduce two carriers with the same
BID at the same time, or if a renegade group of carriers suddenly
merges with the flock, like what happens on IRC servers. To
facilitate this BIDs should use special naming conventions for
carriers (R. Daneel Olivaw) so they don't collide with existing
authuser BIDs. But there's still a problem there that needs to be
considered.
3. If a carrier's key is compromised, what becomes possible?
4. If someone runs an evil carrier (one which selectively deletes
mail, etc.), what would the effects be on the system?
