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- 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 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 , 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