Date: Wed, 30 Jun 93 04:30:08 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 #168
To: tcp-group-digest


TCP-Group Digest            Wed, 30 Jun 93       Volume 93 : Issue  168

Today's Topics:
                      secure access scribblings

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: 30 Jun 93 10:05:47 GMT
From: Jon Jagger <J.R.Jagger@sheffield-hallam.ac.uk>
Subject: secure access scribblings
To: tcp-group@ucsd.edu

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).
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.

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 ?

3. Say I've got a gateway at work that gives telnet access
to local machines from home via radio. Some of the these local
computers have powerful accounts that may need to be used over a
radio. My problem is how can I avoid sending the password
over the air? I was thinking of something like the following.
a) you verify yourself to the gateway (say using 1 above)
a) you tell the gateway you want to start a telnet session on
  computer x, using account y,
c) the gateway looks up you password for that computer/user
   and initiates the telnet by sending the password itself.
   i.e., the password is never sent over the air, it is supplied
   by the gateway.
Clearly you'd want to make sure that the gateway was secure itself
and that telnet passwords were securely stored.


Has anyone looked into these before, or done any work on them?
Any replies appreciated.
Thanks
JJ
:: Jon Jagger , Sheffield Hallam University, S1 1WB, UK
:: Work J.R.Jagger@shu.ac.uk   Home 2E1BSD (44.131.2.111)
:: Tel 0742 533802/432889 (work/home) Fax 0743 533840
:: Newspaper ad: Men wanted for expanding contracting company!

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

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