Link RFC Addendum 2

[David A. Gatwood]

This addendum is short and tentative, so no "complete" version including
these ideas exists. However, these notes are available, along with
previous versions of the rfc, updates, etc. at the URL below.

http://globegate.utm.edu/~davagatw/nutsrfc

-------------------------- BEGIN ADDENDUM --------------------------
NETLINK EXTENDED EXCHANGE PROTOCOL (12-29-97)

The following changes are being considered at this time:

The use of an ATTENTION signal may be eliminated. The alternative
method currently under consideration for telling the remote host
that the newline before the EMSG should be stripped (or more
accurately, should not be readded) is simply adding a '\' as
the last character in the line.

Possible additional commands:

ECHO -- tells the user's originating talker
NOECHO to start and stop echoing characters.
Usage: [NO]ECHO user

PASSWORD -- Asks the user's originating talker to
prompt him/her for a password and then
encrypt it using the salt provided using
the unix crypt() function, before sending
it across the network.
Usage: PASSWORD username salt [promptstring]

Other extensions that have been proposed are:

PRM username [NOECHO] string -- an alternative to the '\' method (*1*)
DENIED CONNECT [reason#] -- *instead* of NUTS #.#.# if refused
for reasons other than incorect
password.
"Connection Refused" -- a single error message for why a
connection was refused that could
be used by security-conscious
admins as the *only* outbound
error message other than possibly
user password invalid, instead of
telling other talkers why the
connection was refused.

Also, the use of DES has been proposed as a possible encryption
method for passwords across the network, instead of sending the
salt and a crypt() encrypted password. (*2*)

Finally, the use of xor has been propsed for a similar purpose.
The idea being that the initial transmission of the password is
in clear text, so no additional security is warranted. (*3*)

Comments:

1. PRM extensions would require more additional code than the \ method.

2. DES is not exportable from the U.S., even though it's freely
available outside the U.S. While preventing reexport of technology
that's already out there may seem stupid, the U.S. Government
apparently thinks it's a risk to National Security, and of course,
they must be right because they're the government... right? :-P

Seriously, though, however stupid the law may be, it would
cause lots of headaches if DES were used. crypt(), since it
exists on nearly all unix and compatible systems, seems better
suited for this purpose.

3. The initial transmission may not be in clear text for all talk
servers. This limits the security unnecessarily.

-------------------------- END ADDENDUM --------------------------

Comments?
David