[Info-vax] Some SEARCH commands

[Simon Clubley]

On 2019-03-01, Mark Berryman <mark at theberrymans.com> wrote:
> On 3/1/19 1:25 AM, Simon Clubley wrote:
>> On 2019-02-28, Mark Berryman <mark at theberrymans.com> wrote:
>>> On 2/27/19 4:39 PM, Simon Clubley wrote:
>>>>
>>>> And while you are all pondering this, also ponder that if you try
>>>> fixing the problem by using proxies instead of hardcoded passwords
>>>> then you are very likely to make your system _LESS_ secure and not
>>>> more secure.
>>>
>>> Eh?  Not in any configuration I have ever used.
>>>
>> 
>> So where exactly is the shared secret support in DECnet Phase IV ?
>
> I don't need a shared secret to make the use of proxies MORE secure than 
> not using them.
>

Yes you do. When you are using proxies an attacker only needs to be
able to pretend to be a trusted system - they no longer even need to
know the password.

If you can pretend to be another DECnet Phase IV node, which is reasonably
easy in the native DECnet Phase IV world, you can gain access without
needing to know the password.

You talk about using IPsec. Ignoring the fact that means you need to use
another networking stack to provide the protection which DECnet Phase IV
lacks, then it actually means you _are_ using a shared secret with IPsec
to protect your DECnet Phase IV network which can either be certificates
or a password.

>> 
>> Oh, I see. You need to use the security features in another network
>> stack (TCP/IP) to protect your DECnet Phase IV nodes because DECnet
>> Phase IV doesn't even have any such basic protections (by today's
>> standards).
>> 
>> It also means all your TCP/IP stacks need to support the routing of
>> DECnet Phase IV over TCP/IP and it also means you are no longer running
>> a DECnet Phase IV network, but a TCP/IP network with DECnet being
>> merely an application level protocol.
>
> I see you do not understand networking very well.  Both DECnet and IP 
> operate at layer 3 and above.  Both require other protocols below layer 
> 3 to communicate.  Both DECnet and IP use CSMA/CD to talk over Ethernet. 
>   DECnet usually uses DDCMP to talk over serial lines.  IP has a number 
> of choices, HDLC being a common one.  Using IP to provide the layer-2 
> path for DECnet does not in any way require IP to know anything at all 
> about DECnet.  You are simply using a different transport mechanism than 
> the one built into DECnet.  One that is easily encrypted.  It is still a 
> DECnet network.  DECnet still establishes its neighbors and DECnet 
> commands are still used for network maintenance.
>

I understand networking just fine. IPsec runs on top of IP, not under it.

Your TCP/IP stack also needs support to be able to hook into the DECnet
stack so DECnet packets can be routed over IP.

>>> It is actually easier to prevent the spoofing of a given DECnet address
>>> that it is to prevent the spoofing of IP addresses.  This is because all
>>> DECnet IV addresses are tied to a specific MAC address, which is not the
>>> case for IP.  Even though DECnet has not been updated in a few decades,
>>> one can make DECnet communications even more secure than, say, SMB2
>>> communications; which is a LOT more prevalent and used for similar
>>> functions.
>>>
>> 
>> Sorry Mark, but that is wrong as when they are setup correctly you can
>> make it vastly harder to spoof an IP node than it is to spoof a DECnet
>> Phase IV node.
>> 
>> That is because you can protect IP based nodes from spoofing by using
>> certificates which is simply not possible with DECnet Phase IV.
>> The certificate acts as a shared secret between IP nodes.
>
> Nope.  IP knows nothing about certificates.  Applications built on IP 
> can use certificates but not IP itself.  I can just as easily write an 
> application using DECnet, or other network protocols, that uses 
> certificates.  (Of course, all of the weaknesses in certificates are 
> fodder for a different discussion).
>

IPsec, which are you proposing as a solution to the security limitations
in the DECnet Phase IV stack, runs directly on top of IP and does support
certificates.

Simon.

-- 
Simon Clubley, clubley at remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world