Subj : Two changes to BinkP inquiry...
To   : Ozz Nixon
From : Joachim Probst
Date : Thu Mar 12 2020 05:21 pm

Hello Ozz!

09 Mar 20 05:16, you wrote to me:

>> *.req files follow the FTS-0006.002 guideline of file requests. That
>> file format is supporting passwords. Each line in the *.req file
>> starts with the filename of the requested file and may be followed by
>> a blank, an exclamation mark and the password.

ON> M_NUL OPT MD5-CRAM-<string> was introduced to produce a more secure
ON> protocol over insecure sessions. The HMAC repliy from the originator
ON> makes it next to impossible for MTM packet snooping like you have
ON> mentioned to monitor how a protocol is working (which only happens
ON> over insecure sessions), thus your *.REQ file with its antiquated !pwd
ON> would allow MTM attacks to see a password in plain text. My concept
ON> avoids this, as the M_REQ password on a HMAC session cannot be
ON> "replayed", it was only valid for that session.

Yes, see that. Ok, that would be a pro to have file requests within the sesison
scope of the transmission for this reason!

ON> Having multiple handshakes on a single port, I understand can muddy
ON> the water, however, the companies I have worked for, getting more than
ON> one protocol port open on the front-end firewall is a challenge let
ON> along security compliance requirements for auditing the need for
ON> multiple ports.

ON> I have successfully communicated with a FroDo 2.33ml using the
ON> **EMSIREQ<crc16> header before my M_NUL OPT MD5-CRAM string, and still
ON> receive my BinkP mail also. So, it does not seem to "break" either
ON> protocol ~ and simplifies the nodelist to just say <domain>, and BINKP
ON> or EMSI, or whatever else may still be in operation. Ports can trigger
ON> off the BINKP, EMSI, CM, HO, flags. And the ITA, ITB, ITN strings for
ON> the BinkP only environments that may or may not be running a BBS.

I did not think about possibilities. I had been using FroDo in my former Fido
time on calling lines. As I said, there it was even necessary to get it working
at all.

For today on IP lines, I just do not see the advantage for the more complex (it
is more complex) and more implicit asumptions to the nodelist. It's - in my
eyes - a protocol change for personal view to a topic without getting an
objective advantage for everyone.

So I still will keep not going along with you in this part. You see more
advantages, I see no advantages being worth a protocol change :)

ON> Thank you for your eyes/thoguhts!
ON> Ozz

Joachim


--- GoldED+/LNX 1.1.5--b20170303
* Origin:  ----> FidoPI  (2:240/6309)