Date: Fri,  2 Jul 93 04:30:11 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 #170
To: tcp-group-digest


TCP-Group Digest            Fri,  2 Jul 93       Volume 93 : Issue  170

Today's Topics:
                         NOS with POP SERVER?
                  secure access scribblings (2 msgs)
                          T1000 nos problems

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: 1 Jul 93 10:32:59 CST
From: "Pat Davis"  <PGD@osnnov1.adp.wisc.edu>
Subject: NOS with POP SERVER?
To: tcp-group@ucsd.edu

Sorry to bug the group but....

I need a recent version of NOS, that has a POP SERVER in it.  While I
see reference to POP in the .MAN file for NOS_1229, there SERVER
portion doesn't seem to be compiled into GRI 2.0P, and others.
Certain local HAMS have their TNC tied up with DX cluster stuff, yet
still desire to be an active part of INFO-HAMS, etc...
So, if YOU have a recent version of NOS, with full POP SERVER (not
just the client) capability, PLEASE drop me an E-MAIL to:

PGD@osnnov1.adp.wisc.edu, or home@pgd.adp.wisc.edu

FYI, the onair%n9gbj.ampr.org@pgd.adp.wisc.edu alias expands out to
HAM IPers in Madison, Wisconsin USA, and has for some years.

Tnx,

Pat Davis, Wisconsin//Michigan U.P. AMPR.ORG address coordinator
608-262-2747 (Ofc.)

------------------------------

Date: Thu, 1 Jul 93 16:38:56 +0200
From: jt@fuw.edu.pl
Subject: secure access scribblings
To: J.R.Jagger@sheffield-hallam.ac.uk, tcp-group@ucsd.edu

> Message-Id: <MAILQUEUE-101.930630100547.352@oak.shu.ac.uk>
> From: Jon Jagger <J.R.Jagger@sheffield-hallam.ac.uk>
> Date: 30 Jun 93 10:05:47 GMT
> 
> 2. radio restrictions on sending coded information
> I'm thinking here of the problem of verfying a user, not of
> wanting to send data securely. A problem is that radio regs state
> that you can't send coded info. However, what if I send both
> versions of the info, i.e., the coded and non-coded in the same

What's about sending packet containing string like:
challenge value=18731293237, MD5 of password and challenge=
10198493b27c3de3af28ec29be6ab1929c ?

------------------------------

Date: Thu, 1 Jul 93 13:40:37 -0700
From: karn@qualcomm.com (Phil Karn)
Subject: secure access scribblings
To: J.R.Jagger@sheffield-hallam.ac.uk, jt@fuw.edu.pl, tcp-group@ucsd.edu

Please, let's not bring up this legality issue again. As far as I'm
concerned, using cryptography solely for authentication (as opposed to
hiding information) is perfectly okay by the current rules.

If you *really* wanted to squash this issue, you could use public
key signatures on every packet. Then anyone with your public key could
verify that the signature field really is what it claims to be, and
not a covert channel masquerading as an authentication field.

Phil

------------------------------

Date: Thu, 1 Jul 93 22:48 EDT
From: gws@n8emr.cmhnet.org (Gary Sanders)
Subject: T1000 nos problems
To: tcp-group@ucsd.edu

One of my BBS users has been having problems getting nos to run
on his T1000 laptop. From his messages, it appears that it will startup
but he cant any data in and out and often gets a TMP file error on the
floppy. ANyone know of this problem? I think the laptop has dos in rom
is this a problem?

-- 
Gary W. Sanders gws@n8emr.cmhnet.org, 72277,1325
N8EMR @ N8JYV (ip addr) 44.70.0.1 [Ohio AMPR address coordinator]
HAM BBS 614-895-2553 (1200/2400/V.32/PEP) Voice: 614-895-2552 (eves/weekends)

------------------------------

End of TCP-Group Digest V93 #170
******************************
******************************