Date: Fri, 11 Jun 93 04:30:09 PDT
From: Advanced Amateur Radio Networking Group <tcp-group@ucsd.edu>
Errors-To: TCP-Group-Errors@UCSD.Edu
Reply-To: TCP-Group@UCSD.Edu
Precedence: Bulk
Subject: TCP-Group Digest V93 #150
To: tcp-group-digest
TCP-Group Digest Fri, 11 Jun 93 Volume 93 : Issue 150
Today's Topics:
Broken address (5 msgs)
Network Unreachable Proposal (4 msgs)
New WAMPES version (2 msgs)
Password security (6 msgs)
UN*X Support
WG7J Nos and Dialup PPP help needed (2 msgs)
Send Replies or notes for publication to: <TCP-Group@UCSD.Edu>.
Subscription requests to <TCP-Group-REQUEST@UCSD.Edu>.
Problems you can't solve otherwise to brian@ucsd.edu.
Archives of past issues of the TCP-Group Digest are available
(by FTP only) from UCSD.Edu in directory "mailarchives".
We trust that readers are intelligent enough to realize that all text
herein consists of personal comments and does not represent the official
policies or positions of any party. Your mileage may vary. So there.
----------------------------------------------------------------------
Date: Thu, 10 Jun 1993 1:05:31 -0400 (EDT)
From: MIKEBW@ids.net (Mike Bilow, <MIKEBW@ids.net>)
Subject: Broken address
To: jangus@skyld.tele.com, tcp-group@ucsd.edu
I have no idea why your mailer is unable to mail to me. Since I am
receiving the mailing list with no problem, I don't think that Brian
would mind if you sent your mail to "mikebw%ids.net@ucsd.edu".
Reading the mail refusal transcript, your system seems to think that
MIKEBW is a machine in the UUCP sense, as if my mail address was
"ids.net!MIKEBW!MIKEBW". It isn't; MIKEBW is my mailbox on a fully
connected Internet host.
I apologize for having to bother the mailing list with this.
-- Mike Bilow, <mikebw@ids.net> (Internet)
N1BEE @ WA1PHY.#EMA.MA.USA.NA (AX.25)
------------------------------
Date: Thu, 10 Jun 1993 1:05:31 -0400 (EDT)
From: MIKEBW@ids.net (Mike Bilow, <MIKEBW@ids.net>)
Subject: Broken address
To: jangus@skyld.tele.com, tcp-group@ucsd.edu
I have no idea why your mailer is unable to mail to me. Since I am
receiving the mailing list with no problem, I don't think that Brian
would mind if you sent your mail to "mikebw%ids.net@ucsd.edu".
Reading the mail refusal transcript, your system seems to think that
MIKEBW is a machine in the UUCP sense, as if my mail address was
"ids.net!MIKEBW!MIKEBW". It isn't; MIKEBW is my mailbox on a fully
connected Internet host.
I apologize for having to bother the mailing list with this.
-- Mike Bilow, <mikebw@ids.net> (Internet)
N1BEE @ WA1PHY.#EMA.MA.USA.NA (AX.25)
------------------------------
Date: Thu, 10 Jun 1993 1:05:31 -0400 (EDT)
From: MIKEBW@ids.net (Mike Bilow, <MIKEBW@ids.net>)
Subject: Broken address
To: jangus@skyld.tele.com, tcp-group@ucsd.edu
I have no idea why your mailer is unable to mail to me. Since I am
receiving the mailing list with no problem, I don't think that Brian
would mind if you sent your mail to "mikebw%ids.net@ucsd.edu".
Reading the mail refusal transcript, your system seems to think that
MIKEBW is a machine in the UUCP sense, as if my mail address was
"ids.net!MIKEBW!MIKEBW". It isn't; MIKEBW is my mailbox on a fully
connected Internet host.
I apologize for having to bother the mailing list with this.
-- Mike Bilow, <mikebw@ids.net> (Internet)
N1BEE @ WA1PHY.#EMA.MA.USA.NA (AX.25)
------------------------------
Date: Thu, 10 Jun 1993 1:05:31 -0400 (EDT)
From: MIKEBW@ids.net (Mike Bilow, <MIKEBW@ids.net>)
Subject: Broken address
To: jangus@skyld.tele.com, tcp-group@ucsd.edu
I have no idea why your mailer is unable to mail to me. Since I am
receiving the mailing list with no problem, I don't think that Brian
would mind if you sent your mail to "mikebw%ids.net@ucsd.edu".
Reading the mail refusal transcript, your system seems to think that
MIKEBW is a machine in the UUCP sense, as if my mail address was
"ids.net!MIKEBW!MIKEBW". It isn't; MIKEBW is my mailbox on a fully
connected Internet host.
I apologize for having to bother the mailing list with this.
-- Mike Bilow, <mikebw@ids.net> (Internet)
N1BEE @ WA1PHY.#EMA.MA.USA.NA (AX.25)
------------------------------
Date: Thu, 10 Jun 1993 1:05:31 -0400 (EDT)
From: MIKEBW@ids.net (Mike Bilow, <MIKEBW@ids.net>)
Subject: Broken address
To: jangus@skyld.tele.com, tcp-group@ucsd.edu
I have no idea why your mailer is unable to mail to me. Since I am
receiving the mailing list with no problem, I don't think that Brian
would mind if you sent your mail to "mikebw%ids.net@ucsd.edu".
Reading the mail refusal transcript, your system seems to think that
MIKEBW is a machine in the UUCP sense, as if my mail address was
"ids.net!MIKEBW!MIKEBW". It isn't; MIKEBW is my mailbox on a fully
connected Internet host.
I apologize for having to bother the mailing list with this.
-- Mike Bilow, <mikebw@ids.net> (Internet)
N1BEE @ WA1PHY.#EMA.MA.USA.NA (AX.25)
------------------------------
Date: Thu, 10 Jun 1993 0:50:05 -0400 (EDT)
From: MIKEBW@ids.net (Mike Bilow, <MIKEBW@ids.net>)
Subject: Network Unreachable Proposal
To: ke9yq@ke9yq.ampr.org, tcp-group@ucsd.edu
I have no idea what benefit would be expected from creating a NOS routing
command to declare something unreachable. NOS has long returned an ICMP
Host Unreachable or Net Unreachable message for anything which did not
have a route defined. In other words, if you want NOS to return an ICMP
unreachability message for frames addressed a certain way, just declare
no routes to that address and it will happen.
For example, let's say I have a routing table like this:
44.104.0.0/16 ax0 direct
44.56.0.0/24 ax1 44.56.0.1
44.56.4.0/24 ax1 44.56.4.1
This is, in fact, very close to a limited subset of what is in place at
the Newport, RI switch. If an IP frame is received addressed to host
128.54.16.1, NOS will find no route and respond with an ICMP message.
The same result would occur for an IP frame to 44.128.0.1, or for an IP
frame to 44.56.10.1.
Don't forget that implied entries on the routing table can be created
through the use of the "ifconfig <label> netmask" command.
-- Mike Bilow, <mikebw@ids.net> (Internet)
N1BEE @ WA1PHY.#EMA.MA.USA.NA (AX.25)
------------------------------
Date: Thu, 10 Jun 93 08:52:08 -0700
From: "Kyle Rhorer" <rhorer@medics.jsc.nasa.gov>
Subject: Network Unreachable Proposal
To: tcp-group@ucsd.edu
In message <930610005005.979c@ids.net> MIKEBW@ids.net (Mike Bilow, writes:
> I have no idea what benefit would be expected from creating a NOS routing
> command to declare something unreachable. NOS has long returned an ICMP
> Host Unreachable or Net Unreachable message for anything which did not
> have a route defined. In other words, if you want NOS to return an ICMP
> unreachability message for frames addressed a certain way, just declare
> no routes to that address and it will happen.
>
Ah, but you are forgetting about the case of a host with a defined route that
has for some reason *become* unreachable. Maybe it is down, or an intervening
gateway can not make contact with it, or whatever.
Kyle
----------------------
"Recent study shows 5 out of 4 Americans have trouble with fractions."
rhorer@medics.jsc.nasa.gov (Kyle Rhorer)
------------------------------
Date: Thu, 10 Jun 1993 08:28:29 -0600
From: ke9yq@ke9yq.ampr.org (Bob Van Valzah, ke9yq)
Subject: Network Unreachable Proposal
To: MIKEBW@ids.net (Mike Bilow, <MIKEBW@ids.net>)
>I have no idea what benefit would be expected from creating a NOS routing
>command to declare something unreachable. NOS has long returned an ICMP
>Host Unreachable or Net Unreachable message for anything which did not
>have a route defined. In other words, if you want NOS to return an ICMP
>unreachability message for frames addressed a certain way, just declare
>no routes to that address and it will happen.
I see your perspective for amateur IP islands. I'm trying to solve a minor
annoyance for those of us who're trying to stitch these islands together
into a cohesive network.
We'd be lost without default routes (the Internet is far too large a place
for explicit routes everywhere). When NOS has a default route, I don't
know how to make it send an unreachable. All I am asking for is a
mechanism to allow me to send an unreachable before it falls thru to my
default route.
>For example, let's say I have a routing table like this:
>
>44.104.0.0/16 ax0 direct
>44.56.0.0/24 ax1 44.56.0.1
>44.56.4.0/24 ax1 44.56.4.1
>
>This is, in fact, very close to a limited subset of what is in place at
>the Newport, RI switch. If an IP frame is received addressed to host
>128.54.16.1, NOS will find no route and respond with an ICMP message.
Your Newport switch may soon be served by an Internet gateway at MIT.
You'll probably want to add a default route to it at that point and I think
you'll miss the unreachable messages.
73, Bob, ke9yq
------------------------------
Date: Thu, 10 Jun 1993 08:28:29 -0600
From: ke9yq@ke9yq.ampr.org (Bob Van Valzah, ke9yq)
Subject: Network Unreachable Proposal
To: MIKEBW@ids.net (Mike Bilow, <MIKEBW@ids.net>)
>I have no idea what benefit would be expected from creating a NOS routing
>command to declare something unreachable. NOS has long returned an ICMP
>Host Unreachable or Net Unreachable message for anything which did not
>have a route defined. In other words, if you want NOS to return an ICMP
>unreachability message for frames addressed a certain way, just declare
>no routes to that address and it will happen.
I see your perspective for amateur IP islands. I'm trying to solve a minor
annoyance for those of us who're trying to stitch these islands together
into a cohesive network.
We'd be lost without default routes (the Internet is far too large a place
for explicit routes everywhere). When NOS has a default route, I don't
know how to make it send an unreachable. All I am asking for is a
mechanism to allow me to send an unreachable before it falls thru to my
default route.
>For example, let's say I have a routing table like this:
>
>44.104.0.0/16 ax0 direct
>44.56.0.0/24 ax1 44.56.0.1
>44.56.4.0/24 ax1 44.56.4.1
>
>This is, in fact, very close to a limited subset of what is in place at
>the Newport, RI switch. If an IP frame is received addressed to host
>128.54.16.1, NOS will find no route and respond with an ICMP message.
Your Newport switch may soon be served by an Internet gateway at MIT.
You'll probably want to add a default route to it at that point and I think
you'll miss the unreachable messages.
73, Bob, ke9yq
------------------------------
Date: Thu, 10 Jun 93 14:59:13 MDT
From: Dieter Deyke <deyke@mdddhd.fc.hp.com>
Subject: New WAMPES version
To: tcp-group@ucsd.edu
I have uploaded a new version of WAMPES (wampes-930610) to UCSD.EDU.
New features:
- support for A/UX 3.0 (thanks to Paul Traina)
- login handling now configurable
- distribution in compressed (.Z) and gzipped (.gz) format
- cleanup in conversd
- use of writev() in n8250.c and conversd.c
I want to point out that people from within Hewlett Packard may get the
newest WAMPES version anytime by ninstalling it from mdddhd.fc.hp.com,
or by anonymous ftp from mdddhd.fc.hp.com.
This is the README file:
-------------------------------------------------------------------------------
wampes-930610.tar.Z (compressed) and wampes-930610.tar.gz (gzipped) are
tar archives of WAMPES, which is a NET/NOS port to HP-UX. It currently
supports HP 9000 series 300, 400, 700, and 800 computers, running HP-UX
08.xx or HP-UX 09.xx.
I ported WAMPES to SunOS 4.1.2 and to 386BSD 0.1.34, and it compiles
there, but I do not have enough time to really test it. Feedback is
welcome.
WAMPES was ported to Linux running on a 386 by Olaf Erb, dc1ik. He also
ported it to ULTRIX 4.2A on a Decstation 5000 with gcc 2.3.3, but it
wasn't tested properly, too. Comments and questions about the Linux and
Ultrix port of WAMPES please to Olaf Erb,
<erb@insu1.etec.uni-karlsruhe.de>.
To unpack this archive you should create the directory /tcp and cd to
it. After unpacking please read the file /tcp/doc/intro.txt.
wampes-930610.tar.Z, wampes-930610.tar.gz, and all followups should go
into /hamradio/packet/tcpip/wampes on UCSD.EDU.
73,
Dieter Deyke, DK5SG / N0PRA, <deyke@fc.hp.com>
-------------------------------------------------------------------------------
From: Paul Traina <pst@cisco.com>
The A/UX 3.0 port is fully functional now. This is a straight-across
port with no operational changes.
-------------------------------------------------------------------------------
Now it's here!
This is the documentation for the RISC iX (Acorn R260 etc) port of
DK5SG's Wampes.
To install it, unpack the archive in a directory named /tcp. Then copy
the files *.R into /usr/lib (you must be root of course). Then cd to
/tcp/src, run make (without arguments...) and ignore the compiler
warnings...
To compile convers, cd to /tcp/convers and run make.
I hope, the port is 100 percent correct. It works here at least :-)
Have fun with it.
73 de Felix, dl6sdc. For bug reports and questions related to the RISC
iX port please mail to
BBS-Net: dl6sdc@db0sao.deu.eu
Amprnet: dl6sdc@db0sao.ampr.org
Bitnet: uk1o@DKAUNI2
Internet: uk1o@ibm3090.rz.uni-karlsruhe.de or
s_schroeter@irav1.ira.uka.de
For questions related to Wampes in general please mail to Dieter
although I would really try to answer such a question too.
------------------------------
Date: Thu, 10 Jun 93 14:59:13 MDT
From: Dieter Deyke <deyke@mdddhd.fc.hp.com>
Subject: New WAMPES version
To: tcp-group@ucsd.edu
I have uploaded a new version of WAMPES (wampes-930610) to UCSD.EDU.
New features:
- support for A/UX 3.0 (thanks to Paul Traina)
- login handling now configurable
- distribution in compressed (.Z) and gzipped (.gz) format
- cleanup in conversd
- use of writev() in n8250.c and conversd.c
I want to point out that people from within Hewlett Packard may get the
newest WAMPES version anytime by ninstalling it from mdddhd.fc.hp.com,
or by anonymous ftp from mdddhd.fc.hp.com.
This is the README file:
-------------------------------------------------------------------------------
wampes-930610.tar.Z (compressed) and wampes-930610.tar.gz (gzipped) are
tar archives of WAMPES, which is a NET/NOS port to HP-UX. It currently
supports HP 9000 series 300, 400, 700, and 800 computers, running HP-UX
08.xx or HP-UX 09.xx.
I ported WAMPES to SunOS 4.1.2 and to 386BSD 0.1.34, and it compiles
there, but I do not have enough time to really test it. Feedback is
welcome.
WAMPES was ported to Linux running on a 386 by Olaf Erb, dc1ik. He also
ported it to ULTRIX 4.2A on a Decstation 5000 with gcc 2.3.3, but it
wasn't tested properly, too. Comments and questions about the Linux and
Ultrix port of WAMPES please to Olaf Erb,
<erb@insu1.etec.uni-karlsruhe.de>.
To unpack this archive you should create the directory /tcp and cd to
it. After unpacking please read the file /tcp/doc/intro.txt.
wampes-930610.tar.Z, wampes-930610.tar.gz, and all followups should go
into /hamradio/packet/tcpip/wampes on UCSD.EDU.
73,
Dieter Deyke, DK5SG / N0PRA, <deyke@fc.hp.com>
-------------------------------------------------------------------------------
From: Paul Traina <pst@cisco.com>
The A/UX 3.0 port is fully functional now. This is a straight-across
port with no operational changes.
-------------------------------------------------------------------------------
Now it's here!
This is the documentation for the RISC iX (Acorn R260 etc) port of
DK5SG's Wampes.
To install it, unpack the archive in a directory named /tcp. Then copy
the files *.R into /usr/lib (you must be root of course). Then cd to
/tcp/src, run make (without arguments...) and ignore the compiler
warnings...
To compile convers, cd to /tcp/convers and run make.
I hope, the port is 100 percent correct. It works here at least :-)
Have fun with it.
73 de Felix, dl6sdc. For bug reports and questions related to the RISC
iX port please mail to
BBS-Net: dl6sdc@db0sao.deu.eu
Amprnet: dl6sdc@db0sao.ampr.org
Bitnet: uk1o@DKAUNI2
Internet: uk1o@ibm3090.rz.uni-karlsruhe.de or
s_schroeter@irav1.ira.uka.de
For questions related to Wampes in general please mail to Dieter
although I would really try to answer such a question too.
------------------------------
Date: 09 Jun 1993 14:50:12 -0500 (CDT)
From: schellew@wu2.wl.aecl.ca (Wayne Schellekens)
Subject: Password Security
To: TCP-Group@UCSD.Edu
> Subject: Password security
>
> I wrote some code that does secure password security that you are welcome
> to. It's purpose was to secure radio logins to a Unix box and for that
>.... stuff deleted ...
I may be missing something here, but I don't see how this technique of
sending the S99 hash over the air to log in. To me it would be very
easy for someone to monitor the airwaves and look for a response to a
password request. Then that person could capture the S99 hash and
simply re-send it whenever he/she decides they want to log in.
To me a much more secure method is for the host computer to send out a
random hex sequence (of say 64 bits) which the user's software can use
as a key for encryption of their password. In this way someone who is
just 'eavesdropping' on the airwaves will not capture a useful
'password'. The host computer will encrypt the user's correct password
with the key and compare it with what the user sent.
Comments are welcome.
Wayne.
--
Wayne Schellekens, VE4WTS Internet: schellew@wu2.wl.aecl.ca
AECL Research AX.25: VE4WTS@VE4KV.#WPG.MB.CAN
Whiteshell Laboratories Twisted pair: (204)753-2311 x2317
PINAWA, MB Canada R0E 1L0 Fax: (204)753-2455
------------------------------
Date: Wed, 9 Jun 93 20:34:10 PDT
From: enge@almaden.ibm.com
Subject: Password Security
To: TCP-GROUP@UCSD.EDU
In <9306091950.AA01843@wu2.wl.aecl.ca> Wayne Schellekens writes:
> ....
>
>To me a much more secure method is for the host computer to send out a
>random hex sequence (of say 64 bits) which the user's software can use
>as a key for encryption of their password. In this way someone who is
>just 'eavesdropping' on the airwaves will not capture a useful
>'password'. The host computer will encrypt the user's correct password
>with the key and compare it with what the user sent.
>...
Currently the AA4RE BBS has the "NETROM" style password verification
for users. I am working on a new version that includes a system
similar to the one proposed for BBS to BBS authentication. A user
could also authenticate via this system.
In my implementation, one system challenges the other with a random
number of up to 32 bits. The other system responds by DES encrypting
the number. One other operation is taken to produce a result and that
is used as the response. The latter step is taken to be secure
against decryption even if you knew the key. In that manner, the
software for the algorithm will meet US export rules.
Roy, AA4RE
------------------------------
Date: Thu, 10 Jun 1993 1:13:49 -0400 (EDT)
From: MIKEBW@ids.net (Mike Bilow, <MIKEBW@ids.net>)
Subject: Password security
To: jt@fuw.edu.pl, tcp-group@ucsd.edu
RFC 1321 gives the MD5 algorithm with C source code. RFC 1320 gives MD4.
-- Mike Bilow, <mikebw@ids.net> (Internet)
N1BEE @ WA1PHY.#EMA.MA.USA.NA (AX.25)
------------------------------
Date: Thu, 10 Jun 1993 08:44:10 -0700
From: George Farris <george@ve7frg.ampr.org>
Subject: Password Security
To: tcp-group@ucsd.edu
On Jun 9, 8:34pm, ucsd.edu!sol.uvic.ca!almaden.ibm.com!enge@sol.uvic wrote:
} Subject: Re: Password Security
> In <9306091950.AA01843@wu2.wl.aecl.ca> Wayne Schellekens writes:
> > ....
> >
> >To me a much more secure method is for the host computer to send out a
> >random hex sequence (of say 64 bits) which the user's software can use
> >as a key for encryption of their password. In this way someone who is
> >just 'eavesdropping' on the airwaves will not capture a useful
> >'password'. The host computer will encrypt the user's correct password
> >with the key and compare it with what the user sent.
> >...
>
> In my implementation, one system challenges the other with a random
> number of up to 32 bits. The other system responds by DES encrypting
> the number. One other operation is taken to produce a result and that
> is used as the response. The latter step is taken to be secure
> against decryption even if you knew the key. In that manner, the
> software for the algorithm will meet US export rules.
>
> Roy, AA4RE
>-- End of excerpt from ucsd.edu!sol.uvic.ca!almaden.ibm.com!enge@sol.uvic
While the above solutions may work, they assume that the resources are
available to modify the host computer login. This is not always
feasible. Remember that in order for a solution to be acceptable it
must work on many different platforms: NOS, Linux, 386bsd, SUN, SCO,
Ultrix, AIX, HPUX, etc etc etc.
--
==========================================================================
George Farris - VE7FRG Internet : george@ve7frg.ampr.org
Amprnet : george@ve7frg.ampr.org
Sidney, B.C. UUCP : sol.uvic.ca!ve7frg!george
(604) 656-0342 AX.25 : ve7frg@ve7vbb.bc.can.noam
------------------------------
Date: Thu, 10 Jun 93 09:50:26 PDT
From: djc@samisen.UVic.CA
Subject: Password security
To: tcp-group@ucsd.edu
Apparently I did a poor job of explaining the algorithm. The basic
plan is to use successively S99, S98, S97, S96 ... until you get to S0,
the original password. Then you have to start all over again. The
host will only accept a string that hashes to what it accepted last
time. Therefore, if you monitor S53 (for example) you can't use it as a
password to break in because, having already accepted S53, the host
will now only accept something that *hashes* to S53 - that is, S52.
But if you don't have one of S0, S1, ... S51 you have to calculate S52
from S53 by cryptographically breaking MD5. If you can do that you have
better things to do with your life than cracking passwords...
The really elegant property of this method is that the password is
never transmitted in cleartext in any channel, unlike the
challenge-and-response system recently proposed.
This method was mentioned in tcp-group by Phil Karn some years back and
how I found out about it. Apparently, he got it from someone else who
proposed it many years ago.
> Here's a note I sent to J.R.Jagger that sounds like it would be of
> interest to some of the rest of the group. I believe that this code
> essentially solves the problem of password security on a broadcast
> medium like radio or ethernet. It does not solve the IP authentication
> problem. I forgot to tell him that it can also be compiled with MD4,
> which is another algorithm that is faster than MD5 and still quite secure,
> though less so than MD5.
>
> > From djc Fri Jun 04 13:01:14 1993
> > Date: Fri, 4 Jun 93 13:01:14 PDT
> > Reply-To: sol.uvic.ca!samisen!djc
> > To: J.R.Jagger@sheffield-hallam.ac.uk
> > Subject: Password security
> >
> > I wrote some code that does secure password security that you are welcome
> > to. It's purpose was to secure radio logins to a Unix box and for that
> > purpose did not require any mods to NOS. It is simple but slightly clunky
> > to use in that mode but the mods to NOS to make it totally automatic
> > would be trivial.
> >
> > It is based on the MD5 message digesting algorithm and works as follows:
> >
> > 1) choose a password, call it S0.
> > 2) use MD5 to hash it securely getting S1.
> > 3) repeat 2) until you have S100 and store it locally.
> > 4) communicate S100 to the host you wish to log in to and store it there.
> >
> > Now to log in to the host you must present a string that produces S100
> > when hashed by MD5. This is S99 - but knowing S100 does not help you
> > find S99 because MD5 is a one-way hash. So it is secure from observers
> > who saw S100.
> >
> > Here's how a login works:
> > YOU: connect, ask for a login.
> > HOST: asks for a password.
> > YOU: start up a little program, type in S0, and the program will MD5 until
> > it has the S100 stored previously. Then it has S99, whatever hashed
> > to S100. The program stores this in the file and sends it to the host.
> > HOST: hashes whatever it gets once and compares it with what is in its
> > file. If it does not match you are an imposter and it kicks you out.
> > If it does match it stores what you sent (S99) in its file and
> > lets you in.
> >
> > When you log out you are all ready to start all over again with S98 instead
> > of S99. You can continue this process until you get to S0; then you have
> > to call up the sysadmin and get your account reset so you can start with
> > a new S0.
> >
> > This sounds complex but it is really very simple to use: just type in
> > your password and the programs on both ends take care of all the rest.
> > The actual code I have extends the concept to allow S98,S97,or S96 to
> > be used when it is expecting S99 - this allows for some screw-ups on either
> > end, which are bound to occur. The string is nice and long, 12 chars or
> > so, which makes brute-force impossible. The MD5 algorithm is very fast
> > so 2 or 3 hundred iterations is no problem on any reasonable computer.
> > I use it on a 12 MHz XT and it only takes a few seconds to calculate
> > 200 MD5s even though the XT is a VERY slow machine.
> >
> > But best of all, nothing useful to an interloper is kept anywhere on
> > either side! The one-way nature of MD5 makes it very difficult to
> > calculate Sn-1 if you know Sn.
--
/\/\/\/\/\/
Doug Collinge, try: sol.uvic.ca!samisen!djc
or: samisen!djc@sol.uvic.ca
or: dcolling@ve7frg.ampr.org
VE7GNU PBBS: VE7GNU@VE7VBB.#ISLAND.BC.CAN.NOAM
------------------------------
Date: Thu, 10 Jun 93 09:50:26 PDT
From: djc@samisen.UVic.CA
Subject: Password security
To: tcp-group@ucsd.edu
Apparently I did a poor job of explaining the algorithm. The basic
plan is to use successively S99, S98, S97, S96 ... until you get to S0,
the original password. Then you have to start all over again. The
host will only accept a string that hashes to what it accepted last
time. Therefore, if you monitor S53 (for example) you can't use it as a
password to break in because, having already accepted S53, the host
will now only accept something that *hashes* to S53 - that is, S52.
But if you don't have one of S0, S1, ... S51 you have to calculate S52
from S53 by cryptographically breaking MD5. If you can do that you have
better things to do with your life than cracking passwords...
The really elegant property of this method is that the password is
never transmitted in cleartext in any channel, unlike the
challenge-and-response system recently proposed.
This method was mentioned in tcp-group by Phil Karn some years back and
how I found out about it. Apparently, he got it from someone else who
proposed it many years ago.
> Here's a note I sent to J.R.Jagger that sounds like it would be of
> interest to some of the rest of the group. I believe that this code
> essentially solves the problem of password security on a broadcast
> medium like radio or ethernet. It does not solve the IP authentication
> problem. I forgot to tell him that it can also be compiled with MD4,
> which is another algorithm that is faster than MD5 and still quite secure,
> though less so than MD5.
>
> > From djc Fri Jun 04 13:01:14 1993
> > Date: Fri, 4 Jun 93 13:01:14 PDT
> > Reply-To: sol.uvic.ca!samisen!djc
> > To: J.R.Jagger@sheffield-hallam.ac.uk
> > Subject: Password security
> >
> > I wrote some code that does secure password security that you are welcome
> > to. It's purpose was to secure radio logins to a Unix box and for that
> > purpose did not require any mods to NOS. It is simple but slightly clunky
> > to use in that mode but the mods to NOS to make it totally automatic
> > would be trivial.
> >
> > It is based on the MD5 message digesting algorithm and works as follows:
> >
> > 1) choose a password, call it S0.
> > 2) use MD5 to hash it securely getting S1.
> > 3) repeat 2) until you have S100 and store it locally.
> > 4) communicate S100 to the host you wish to log in to and store it there.
> >
> > Now to log in to the host you must present a string that produces S100
> > when hashed by MD5. This is S99 - but knowing S100 does not help you
> > find S99 because MD5 is a one-way hash. So it is secure from observers
> > who saw S100.
> >
> > Here's how a login works:
> > YOU: connect, ask for a login.
> > HOST: asks for a password.
> > YOU: start up a little program, type in S0, and the program will MD5 until
> > it has the S100 stored previously. Then it has S99, whatever hashed
> > to S100. The program stores this in the file and sends it to the host.
> > HOST: hashes whatever it gets once and compares it with what is in its
> > file. If it does not match you are an imposter and it kicks you out.
> > If it does match it stores what you sent (S99) in its file and
> > lets you in.
> >
> > When you log out you are all ready to start all over again with S98 instead
> > of S99. You can continue this process until you get to S0; then you have
> > to call up the sysadmin and get your account reset so you can start with
> > a new S0.
> >
> > This sounds complex but it is really very simple to use: just type in
> > your password and the programs on both ends take care of all the rest.
> > The actual code I have extends the concept to allow S98,S97,or S96 to
> > be used when it is expecting S99 - this allows for some screw-ups on either
> > end, which are bound to occur. The string is nice and long, 12 chars or
> > so, which makes brute-force impossible. The MD5 algorithm is very fast
> > so 2 or 3 hundred iterations is no problem on any reasonable computer.
> > I use it on a 12 MHz XT and it only takes a few seconds to calculate
> > 200 MD5s even though the XT is a VERY slow machine.
> >
> > But best of all, nothing useful to an interloper is kept anywhere on
> > either side! The one-way nature of MD5 makes it very difficult to
> > calculate Sn-1 if you know Sn.
--
/\/\/\/\/\/
Doug Collinge, try: sol.uvic.ca!samisen!djc
or: samisen!djc@sol.uvic.ca
or: dcolling@ve7frg.ampr.org
VE7GNU PBBS: VE7GNU@VE7VBB.#ISLAND.BC.CAN.NOAM
------------------------------
Date: Tue, 8 Jun 1993 09:36:00 -0600
From: bdmc@oifis.mcc.ab.ca (Brian McCullough)
Subject: UN*X Support
To: tcp-group@ucsd.edu (Anyone Who Can Help)
I have been doing the "haunt ucsd" and "ask friends" things for some time now, but have so far come up empty, so I guess it's time to ask the WORLD!
:-)
I am running QNX, both the older 3.15 version and the POSIX 4.11 version, and am looking for something which will allow me to support KISS modems as well as the other hardware used by all of the variants of KA9Q's work. (or at least some of that hardware!)
I have looked at several of the DOS-based variants, as well as WAMPES, but have noticed something which seems to me to be rather strange. I can understand the habit that the DOS variants have of creating a single monolithic program which takes over the machine and runs NOS. That was NOT the model which I expected from WAMPES! Certainly in QNX, the usual method is to create small, fairly single-purpose programs which can pass messages, or files, or pipes, back and forth to accomplish some task. (QNX is a message-based architecture.)
Does ANYBODY have any suggestions for software which I could adapt to my environment, whether strictly KA9Q-based or not, to produce a QNX TCP/IP packet station?
Thanks,
Brian
--- Qtach2 v1.14beta
-------------------------------------------------------------------
Internet bdmc@oifis.mcc.ab.ca | UUCP {alberta!ncc}!apin!bdmc
Ham VE6BDM | iNet MCCULLOUGH
-------------------------------------------------------------------
------------------------------
Date: Tue, 8 Jun 93 08:50:42 -0400
From: Randy Nelson VE3WRN <rnelson@watserv1.uwaterloo.ca>
Subject: WG7J Nos and Dialup PPP help needed
To: tcp-group@ucsd.edu
I would like to use WG7J Nos and Dialup PPP. I do not have access to
a compiler. Would anyone using PPP to call a unix box please drop me
a line.
I would also like to hear from anyone using PA0GRI 2.0 and PPP. I have
a PPP version but cannot get it working.
Thanks
Randy
------------------------------
Date: Tue, 8 Jun 93 08:50:42 -0400
From: Randy Nelson VE3WRN <rnelson@watserv1.uwaterloo.ca>
Subject: WG7J Nos and Dialup PPP help needed
To: tcp-group@ucsd.edu
I would like to use WG7J Nos and Dialup PPP. I do not have access to
a compiler. Would anyone using PPP to call a unix box please drop me
a line.
I would also like to hear from anyone using PA0GRI 2.0 and PPP. I have
a PPP version but cannot get it working.
Thanks
Randy
------------------------------
Date: Wed, 09 Jun 93 13:43:00 PDT
From: uunet!maildrop.ota.gov!mcallaham%isc.ota.gov
To: <tcp-group@ucsd.edu-request>
------------------------------
End of TCP-Group Digest V93 #150
******************************
******************************