Date: Thu, 1 Jul 93 04:30:10 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 #169
To: tcp-group-digest
TCP-Group Digest Thu, 1 Jul 93 Volume 93 : Issue 169
Today's Topics:
fixed rcsdsrc.zip on ucsd.edu
password use
secure access scribblings (4 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, 1 Jul 93 00:54:03 -0700
From: Phil Karn <karn@unix.ka9q.ampr.org>
Subject: fixed rcsdsrc.zip on ucsd.edu
To: tcp-group@ucsd.edu
The last time I updated some files in /hamradio/packet/tcpip/ka9q/rcsdsrc.zip
on ucsd.edu, I inadvertently put in the extracted source files instead of the
RCS versions. I just fixed that. No other changes.
Phil
------------------------------
Date: Wed, 30 Jun 1993 07:34:14 PDT
From: "Jeffrey D. Angus" <jangus@skyld.tele.com>
Subject: password use
To: tcp-group@ucsd.edu
On encryption of passwords. I'm taking the position that they
are legal until given an NAL from the FCC. My opinion is that
they fall into the catagory of system control, and I will argue
that point if need be.
--
J. Angus: jangus@skyld.tele.com -- "Als ik Kan", Gustav Stickley
US Mail: PO Box 4425 Carson, CA 90749-4425 1 (310) 324-6080
------------------------------
Date: Wed, 30 Jun 93 07:26:44 PDT
From: enge@almaden.ibm.com
Subject: secure access scribblings
To: TCP-GROUP@UCSD.EDU
In <MAILQUEUE-101.930630100547.352@oak.shu.ac.uk> Jon Jagger <J.R.Jagger@sheffield-hallam.ac.uk> writes:
>Hi,
>general wafflings on a couple of things I was thinking about
>
>1. I was looking at some c code that does secure access by
>a) gateway sends you a random string.
>b) you des encode it, and send it back.
>c) gateway verifies you cos it knows your des key
> (or maybe an md5 hash of it).
>
> ....
This was discussed a week or two ago. The consensus is to use a
variation of RFC1334. This involves sending a challenge and receiving
a response which is a combination of the challenge and a "secret"
hashed using MD5.
The advantages of this are:
1) Since MD5 is undecryptable, you can't be accused of sending
encoded communications. Most regulatory authorities allow
authentications.
2) Since MD5 is undecryptable, it passes the US export laws.
I have implemented an authentication protocol for AX.25 BBS but
am not sure what has been done by others for TCP/IP connections.
Roy, AA4RE
------------------------------
Date: Thu, 1 Jul 1993 10:28:52 +1000
From: makinc@hhcs.gov.au
Subject: secure access scribblings
To: tcp-group@ucsd.edu
Jon writes;
> 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
> packet? Would the coded info still count as being coded, seeing as the
> uncoded version would be right next to it ?
Yep, I'd say so.
This seems a silly point anyway. There have been arguments for the past
couple of years that I've been on tcp-group regarding encryption vs
compression and encrypted password strings.
Here in Australia and, as far as I can see, the US, it is illegal to code
the data such as the meaning is hidden. With a password there is no
meaning in the word itself so how can recoding the password for security
obscure the meaning? It would be exactly the same as if I had 100
passwords of random characters and cycled through them. Check the regs in
your country however I would guess that they would say something similar.
Also before this explodes into another flamewar please reply direct to me
and not to the group. I'll summarise if need be.
Carl.
--
Carl Makin (VK1KCM) Systems Programmer
Internet: makinc@hhcs.gov.au
Amprnet: vk1kcm@vk1kcm.act.aus.oc
Work Phone: +61 6 289-8443
------------------------------
Date: Wed, 30 Jun 93 18:39:08 EDT
From: "William Allen Simpson" <bill.simpson@um.cc.umich.edu>
Subject: secure access scribblings
To: Jon Jagger <J.R.Jagger@sheffield-hallam.ac.uk>
> 1. I was looking at some c code that does secure access by
> a) gateway sends you a random string.
> b) you des encode it, and send it back.
> c) gateway verifies you cos it knows your des key
> (or maybe an md5 hash of it).
> I was thinking why do stage a) ?
> The main reason I can see is that it prevents replay attacks.
> However you can avoid this by using a once only string based on
> the time. Here's how it might work
> a) you get the sytem time,
> b) you des encrypt it.
> c) you send it to the gateway.
> d) the gateway decrypts, and verifies you
> i) does it decrpyt to a valid time-stamp
> ii) does it decrypt to a time > your previous time
> e) the gateway updates you personal time
> This reduces retwork traffic and does not introduce a delay
> caused if you have to des encrypt the random string yourself
> using a separate program.
>
Yes, people have thought about these before. In your case, the attacker
is in control of the frequency and timing of the attacks.
One of the advantages of the authenticator sending the "random
challenge" is that it is unpredicatable to the attacker. Your method
makes it completely predictable and controllable by the attacker.
Also, the "true" user is completely out of your authentication scheme.
It may never even know that someone else is spoofing it -- you just send
the authentication directly to the authenticator.
When the "random challenge" is sent by the authenticator, there is the
implied knowledge that the "true" user is at least one of the
recipients. Others may hear it too, operating in promiscuous mode, but
at least the "true" user knows that he has been challenged.
Bill.Simpson@um.cc.umich.edu
------------------------------
Date: Thu, 1 Jul 93 01:39:23 -0700
From: karn@qualcomm.com (Phil Karn)
Subject: secure access scribblings
To: J.R.Jagger@sheffield-hallam.ac.uk, bsimpson@morningstar.com
I invite all those interested in really solving the IP security problem
to participate in the IP Security Working Group of the IETF. This
group was formed largely at my urging to come up with a way to
authenticate and/or encrypt individual IP datagrams, independent of
TCP connections, user sessions, etc. The mailing list is ipsec@ans.net;
follow the usual convention of sending mail to ipsec-request@ans.net to
get on the list (NOT to ipsec itself!)
Phil
------------------------------
End of TCP-Group Digest V93 #169
******************************
******************************