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

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)

.