From: rfranken@mcs213i.cs.umr.edu (Richard Brett Frankenberger)
Subject: Re: Leak in Novell
Date: Thu, 15 Oct 1992 00:19:32 GMT
Organization: University of Missouri - Rolla

In article <Bw4DEn.1vr@uxa.ecn.bgu.edu> mgmam@uxa.ecn.bgu.edu (Mark A. Morrell) writes:
>
>I don't think they will work...
>
>> (1) If you are now worried about some sending a packet to a workstation that 
>>looks like it came from the server (which may not be a concern since the 
>>workstation would probably ignore it if it wasn't expecting it anyway), 
>
>The problem would be sending to the server looking like it came from
>another workstation, not to a workstation saying it was the server.
>It's only a single Netware call to add SUPERVISOR rights to a single
>user.
>
>>the
>>workstation can send its public key out unencrypted, and then the server 
>
>Grab the key...
>
>>could encrypt its public key with the workstations public key and send it
>>back.  
>
>then grab that key... done.  "Make me SUPERVISOR."
>
>>Of course, this would require that the server have a separate
>>public key for each workstation.
>
>>     - Brett    (rfranken@cs.umr.edu)
>
>After looking at this type of thing, I'm beginning to wonder whether
>it's possible to have a secure communications channel.
>
>Mark A. Morrell

It will work.  I made a typo in (1) - the work NOW should be NOT.  (But the
explanation below it is correct and does describe a system whereby a hacker
cannot forge a packet from the workstation to the server).
 
My first step was for the workstation to send its public key out unencrypted.
 
You said the hacking workstation could then grab that key.  That is correct,
and with that key, the hacking workstation could send a packet to the
workstation that looks like it came from the server.  (However, the premise of
this method is that that is OK - we just don't want any packets going to
the server that look like they came from the workstation if they really didn't).
 
The server then encrypts its public key using the workstations public key, and
sends that to the workstation.  The workstation uses its private key and
unencrypts the frame, and now knows the public key for sending stuff to the
server, so it can send stuff to the server.
 
You said the hacking workstation could grab the packet from the server to the
workstation that contained the servers public key.  This is true, but that
packet would be useless to the hacking workstation, since it could not
unencrypt it.  (It knows the public key that was used to encrypt the message,
but it can't unencrypt it without the private key).  This system if, of course,
based on a public key large enough that you can't factor it to get the
private key in any reasonable amount of time.  (Working with a key that
large would likely slow performance to well below acceptable levels, but
thats another topic).
 
Also, you mentioned that the request to make an ID supervisor equiv is a 
signle packet, and the workstation needs only send it to the server (without
needing to receive anything from the server).  This is true now, but we are
talking about a major redesign of NCP (netware core protocol) most llikely, so
the requirements to change security equiv could change (although with
a secure encryption system like above, it wouldn't matter).  BUt once again,
even on a fast 486 machine, I think you would see performance loss at least
an order of magnitude to implement such a public/private key system with large
enough keys that a hacker couldn't factot the public key.
 
      - Brett    (rfranken@cs.umr.edu)