Introducing a M_REQ command, MsgHdr Len M_REQ FILENAME
accepts a connection and sends the MD5 CRAM and waits. If I do not
receive a MsgHdr Len M_<command> then I assume (a) User, (b) port
scanner, (c) EMSI Session (because I could send **REQ before the CRAM).
The other part of the workflow change is not to present all M_ADR as a couple networks I have joined prefer to be a little more under the
radar ~ the easy way to help improve this would be to require the
client (polling process) to share the address(es) associated with the connection it is expecting (incase we share two or more networks and
said connection is my uplink/downlink). This tweak of course is
Now that my mailer (listener) and poller (client) are in production
on a few sites ~ and I have joined a couple of networks that wish
to be "under the radar". I wanted to check around about 2 possibly
changes to the BinkP protocol.
I wanted to check around about 2 possibly changes to the BinkP protocol.
Now that my mailer (listener) and poller (client) are in production on
a few sites ~ and I have joined a couple of networks that wish to be "under the radar". I wanted to check around about 2 possibly changes
to the BinkP protocol.
Introducing a M_REQ command, MsgHdr Len M_REQ FILENAME
Multiple files, MsgHdr Len M_REQ FILENAME1,FILENAME2,FILENAME3
Passworded files, MsgHdr Len M_REQ FILENAME1 PASS,FILENAME2
Optional support for .REQ files could stay for backward compatability.
The other change to the BinkP protocol - really applies to the
workflow of the protocol ~ for example, if you telnet to my BinkP
mailer, it accepts a connection and sends the MD5 CRAM and waits. If I
do not receive a MsgHdr Len M_<command> then I assume (a) User, (b)
port scanner, (c) EMSI Session (because I could send **REQ before the CRAM).
The other part of the workflow change is not to present all M_ADR as a couple networks I have joined prefer to be a little more under the
radar ~ the easy way to help improve this would be to require the
client (polling process) to share the address(es) associated with the connection it is expecting (incase we share two or more networks and
said connection is my uplink/downlink). This tweak of course is
optional for products still in development ~ but adds a small layer of anonymity for said networks.
I am in the process of implementing these changes to the systems
running my mailer, so we can iron out any quirks. However, it was suggested that I present my thoughts in FTSC_PUBLIC.
Introducing a M_REQ command, MsgHdr Len M_REQ FILENAME
Multiple files, MsgHdr Len M_REQ FILENAME1,FILENAME2,FILENAME3
Passworded files, MsgHdr Len M_REQ FILENAME1 PASS,FILENAME2
Optional support for .REQ files could stay for backward compatability. However, this approach would help define an M_REQ means a POLL
request, instead of how it is documented now, as a if you didn't get
any M_FILE from the client, it must be assumed as being a POLL.
The other change to the BinkP protocol - really applies to the
workflow of the protocol ~ for example, if you telnet to my BinkP
mailer, it accepts a connection and sends the MD5 CRAM and waits. If I
do not receive a MsgHdr Len M_<command> then I assume (a) User, (b)
port scanner, (c) EMSI Session (because I could send **REQ before the CRAM.
The other part of the workflow change is not to present all M_ADR as a couple networks I have joined prefer to be a little more under the
radar ~ the easy way to help improve this would be to require the
client (polling process) to share the address(es) associated with the connection it is expecting (incase we share two or more networks and
said connection is my uplink/downlink). This tweak of course is
optional for products still in development ~ but adds a small layer of anonymity for said networks.
Ozz Nixon
--- Legacy/X FTN Tosser/JAM v1-Alpha6
* Origin: Legacy/X WHQ (Legacy ANSI at Today's Speed) (1:1/123)
Introducing a M_REQ command, MsgHdr Len M_REQ FILENAME
This sounds OK to me - how is it different to REQ, ie: why is it better, or >why does it need to change?
What happens when it is a) User or c) EMSI - is it your intention that binkp >becomes a "frontdoor", and if it isnt a mail (in the case of a) - you launch >the BBS login screen. For the later, C) EMSI, is it enabling EMSI on thebinkp
port? Why would this be needed over just connecting to a different port that >serves EMSI?
I'm not sure I understand the value of this one - if the server wants to not >reveal who it is first (because the sysop doesnt want the connect mailer to >know it is part of secret network), is it possible that the client would want >that as well (not to reveal which network its a part of until the server >reveals itself)?
Nice idea, like that part, but I do not see the necessaty of a protocol >change. FTS does not request that you show all addresses you have. It just >requests that the originating side does not wait for any response before >sending M_PWD and that for password checking all presented addresses (by the >originating side, no other makes sense) are using the same password, if any.
The originating side could just present the networks it wants to present >(hiding akas is already sugested in the FTS for the purpose of working with >different passwords on different akas). If the answering side only presents >'public' akas and akas fitting to those presented by the originating side, I >do not see any violence of the current binkp protocol and can see no harm to >the network, too. Maybe I am overlooking something?
a) I did not grow up on BinkleyTerm, nor did I jump onto BinkD.
b) by providing MsgHdr LEN M_REQ (where LEN=1) - then I know its a
poll. If LEN>1 then its a CVS string of 1 or more requests. And to
keep with security (.REQ lacks) if the M_REQ file is passworded, the system cound using the same MD5-CRAM logic for the individual
file password(s). Why? Security.
What happens when it is a) User or c) EMSI - is it your intentionbinkp
that binkp becomes a "frontdoor", and if it isnt a mail (in the case
of a) - you launch the BBS login screen. For the later, C) EMSI, is
it enabling EMSI on the
port? Why would this be needed over just connecting to a different
port that serves EMSI?
* For systems that the Mailer/BBS work as one ~ yes, I let the user
login - like a "FroDo" design (and MANY other systems).
One port vs multiple ports. Security acceptance. The companies I have worked for over the years, network CISO do not like to open multiple
ports for any reason. And while many may run a BBS at home ~ in the corporate world, it would be nice to see the BBS and the MAILER serve
a purpose again.
Ozz
Nice idea, like that part, but I do not see the necessaty of a
protocol change. FTS does not request that you show all addresses you
have. It just requests that the originating side does not wait for
any response before sending M_PWD and that for password checking all
presented addresses (by the originating side, no other makes sense)
are using the same password, if any.
The originating side could just present the networks it wants to
present (hiding akas is already sugested in the FTS for the purpose
of working with different passwords on different akas). If the
answering side only presents 'public' akas and akas fitting to those
presented by the originating side, I do not see any violence of the
current binkp protocol and can see no harm to the network, too. Maybe
I am overlooking something?
* Okay, it may not be a protocol improvement ~ however, as you see, it introduces a little layer of security ~ which they want to achieve. However, if it was mentioned in the specification that you do not have
to present all of your addresses (to me AKAs is wrong wording) you
could simply reply wiht the matching zones ~ so M_PWD can proceed as planned. And a snoopy nose does not see, oh, he's a member of 666
network.
Ozz
*.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.
With all due respect, are you not in the wrong echo ?
I do not know - am I in the wrong echo for acking something that is related to FTSC documents, may require some wording changes, etc.?
Its not an FTSC submission, it is not a BINKD patch, it is not a
BinkP (oh no echo for this)
topic yet, and my NET_DEV echo has been empty for almost 2 years.
so I assumed this would be the best place to get all the kickback
on a change
The binkp protocol is discussed in RU.Binkd
Obviously, only in Russian: this safely keeps away people like you.
You could notice that nobody of binkd|binkp developers answered you.
Guess why :-)
*.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.
M_NUL OPT MD5-CRAM-<string> was introduced to produce a more secure protocol over insecure sessions. The HMAC repliy from the originator
makes it next to impossible for MTM packet snooping like you have mentioned to monitor how a protocol is working (which only happens
over insecure sessions), thus your *.REQ file with its antiquated !pwd would allow MTM attacks to see a password in plain text. My concept
avoids this, as the M_REQ password on a HMAC session cannot be
"replayed", it was only valid for that session.
Having multiple handshakes on a single port, I understand can muddy
the water, however, the companies I have worked for, getting more than
one protocol port open on the front-end firewall is a challenge let
along security compliance requirements for auditing the need for
multiple ports.
I have successfully communicated with a FroDo 2.33ml using the **EMSIREQ<crc16> header before my M_NUL OPT MD5-CRAM string, and still receive my BinkP mail also. So, it does not seem to "break" either protocol ~ and simplifies the nodelist to just say <domain>, and BINKP
or EMSI, or whatever else may still be in operation. Ports can trigger
off the BINKP, EMSI, CM, HO, flags. And the ITA, ITB, ITN strings for
the BinkP only environments that may or may not be running a BBS.
Thank you for your eyes/thoguhts!
Ozz
The binkp protocol is discussed in RU.Binkd
Obviously, only in Russian: this safely keeps away people like you.
topic yet, and my NET_DEV echo has been empty for almost 2 years.
so I assumed this would be the best place to get all the kickback
on a change
You could notice that nobody of binkd|binkp developers answered you.
Guess why :-)
Sysop: | digital man |
---|---|
Location: | Riverside County, California |
Users: | 1,033 |
Nodes: | 15 (0 / 15) |
Uptime: | 123:47:27 |
Calls: | 529 |
Calls today: | 23 |
Files: | 95,154 |
D/L today: |
4,428 files (585M bytes) |
Messages: | 298,876 |
Posted today: | 12 |