MMDVM User Authentication


Rod - KC7AAD
 

Is there a way to have an "authorized user" list in the MMDVM Server? While we offer a publicly available connection for those who are outside our area, we also have several that we use for various purposes. It would be nice if we could have a list of those users who we authorize.
I've looked through the files, but don't see anything for the users auth, only the IPSC auth.


thanks!!
Rod / KC7AAD


Matthew 2E0SIP
 

Hi Rod,

The MMDVM protocol doesn't contain a "Username" as such, it's password only.

Do you mean you want no password at all for connecting clients, or IP authentication? 

Cheers



Peter M0NWI
 

Rod,

Are you talking about not allowing RF users to flow out over the network, see the sub_acl.py file to create a black or white list, or to stop them using the RF side totally?

Sent from Outlook
From: main@DVSwitch.groups.io <main@DVSwitch.groups.io> on behalf of Rod - KC7AAD <kc7aad@...>
Sent: 30 June 2018 23:59:54
To: main@DVSwitch.groups.io
Subject: [DVSwitch] MMDVM User Authentication
 
Is there a way to have an "authorized user" list in the MMDVM Server? While we offer a publicly available connection for those who are outside our area, we also have several that we use for various purposes. It would be nice if we could have a list of those users who we authorize.
I've looked through the files, but don't see anything for the users auth, only the IPSC auth.


thanks!!
Rod / KC7AAD


Rod - KC7AAD
 

Ideally, the admin could have a list of Authorized users. Consider it a whitelist. That list would probably contain their ID, as it's what get's sent in during the registration process of the hotspots. The list, if the user was in it, would allow the user to connect to the server and use the path into the cBridge.
If the user was not in the whitelist, the user would be denied any access to the server. Their client could (and like would) retry.. retry.. retry.. rety.. 'til the cows come home.. but would never get access!

I get that we have the password, but when the password is passed out among friends of friends, and mentioned in conversations or posts.. It get's to be a little like a run-away train eventually. Our group just went through a password change of 3 of our servers. We required the users to send us a request for the new info before we give it out. But you can only imaging that it's only a short bit of time before it get's out again.
Our group does offer a "public" server with a handfull of talkgroups on it. But folks always want the Cadillac, and are barely paying for a unicycle!


Thanks!!
Rod / KC7AAD


Rod - KC7AAD
 

Anyone?? Ideas? Thoughts?


Cort N0MJS <n0mjs@...>
 

First off, in your original post you said: "Is there a way to have an "authorized user" list in the MMDVM Server?”

I don’t know what an “MMDVM Server” is because I didn’t write any programs called that. I *think* what you want is a black/white list option for allowing clients to connect to hblink.py when it’s configured as a master. Is this what you’re asking for? I know you’re probably cussing me right now for being pedantic, but believe me, after 5 years on this project, I’ve learned we have to be accurate and explicit. If it is what you’re asking, here are my thoughts:

1) HBlink wasn’t written to be a hotspot aggregator, though I realize it’s become that to a number of users.
2) This sounds like a solution b/c systems operators are not adequately controlling their end-users – I know, it’s really hard to control some people.

So how would we go about doing this? IP address isn’t good because too many NAT addresses change too often. It would almost have to be by the radio ID of the client connecting. But if you have users tossing about the password, would they not do the same with the radio ID of their hotspot? The only reasonable way I can think of is by radio ID.

Adding the “feature” would not be complicated. I could kick it out in the next few days. My concern is whether or not it would adequately address the issue, or just push it off into yet another issue. Because there’s one thing I will not do, which is keep chasing solutions for problems that only exist because bad actors are passing around login credentials on one system out there.

I’d like more than one person to say “this would be really beneficial to me”, and all of you who say that to tell me that if the users just find another way to be bad, you won’t be back for another technical solution to an administrative problem – because using technology to continually solve an administrative (human) problem usually creates collateral damage and diminishing returns.

I’d like to see 5 YES votes before I proceed. I can make a poll for the group, but would rather just see some replies to this with one word “YES” or “NO”.

0x49 DE N0MJS


On Jul 6, 2018, at 8:12 AM, Rod - KC7AAD <kc7aad@...> wrote:

Anyone?? Ideas? Thoughts?

--
Cort Buffington
H: +1-785-813-1501
M: +1-785-865-7206






Matthew 2E0SIP
 

Cort - I think to make this work reliably as you would need a 1:1 mapping between Radio IDs and Passwords, and potentially limit the clients that can connect using those credentials. That way if someone shares their credentials they would then get kicked from the server.

It would be quite nice if authentication on the MMDVM protocol was improved (I quite like BM's OpenBridge implementation) but that's a discussion for another day and would also some collaboration with G4KLX etc

That said, Rod - Have you considered controlling access using a VPN ? Something like https://www.zerotier.com/ would work very well for this application


Cort N0MJS <n0mjs@...>
 

To Matthew’s point, I won’t modify HBP. It’s bad enough that BM, MMDVM and DMR+ can’t stay on the same page, I won’t be the 4th dialect :)

But agree that a better way would be nice!


On Jul 6, 2018, at 8:59 AM, Matthew 2E0SIP <groups.io@...> wrote:

Cort - I think to make this work reliably as you would need a 1:1 mapping between Radio IDs and Passwords, and potentially limit the clients that can connect using those credentials. That way if someone shares their credentials they would then get kicked from the server.

It would be quite nice if authentication on the MMDVM protocol was improved (I quite like BM's OpenBridge implementation) but that's a discussion for another day and would also some collaboration with G4KLX etc

That said, Rod - Have you considered controlling access using a VPN ? Something like https://www.zerotier.com/ would work very well for this application


Peter M0NWI
 

Rod,


I thought I'd offered a response about using sub_acl.py last Sunday, did that not suit your needs, to allow/deny bridging for given radio ID's?


If you really want to lock it down, and I know it's a bit of work, but you could stand a master up for each client with a unique password, define specific bridge rules between these masters, and switch on sub_ACL so only those who have both the correct radio Id, correct talk group and correct password for the master instance will get in?


73,

Peter




From: main@DVSwitch.groups.io <main@DVSwitch.groups.io> on behalf of Rod - KC7AAD <kc7aad@...>
Sent: 06 July 2018 14:12
To: main@DVSwitch.groups.io
Subject: Re: [DVSwitch] MMDVM User Authentication
 
Anyone?? Ideas? Thoughts?


Steve N4IRS
 

I think OpenBridge is fine for server to server but it requires BM admin intervention. Not suited for most of what we want to do.

Steve

On 7/6/2018 11:14 AM, Cort N0MJS via Groups.Io wrote:
To Matthew’s point, I won’t modify HBP. It’s bad enough that BM, MMDVM and DMR+ can’t stay on the same page, I won’t be the 4th dialect :)

But agree that a better way would be nice!


On Jul 6, 2018, at 8:59 AM, Matthew 2E0SIP <groups.io@...> wrote:

Cort - I think to make this work reliably as you would need a 1:1 mapping between Radio IDs and Passwords, and potentially limit the clients that can connect using those credentials. That way if someone shares their credentials they would then get kicked from the server.

It would be quite nice if authentication on the MMDVM protocol was improved (I quite like BM's OpenBridge implementation) but that's a discussion for another day and would also some collaboration with G4KLX etc

That said, Rod - Have you considered controlling access using a VPN ? Something like https://www.zerotier.com/ would work very well for this application



Jon K1IMD <jon@...>
 

Cort,
As you pointed out not the original intention but I have seen numerous c-Bridges using HBlink for dongle/hotspot access.

I had a discussion with a couple c-Bridge ops 2 months ago and they were concerned and wishing for some sort of control of access.  So I get the problem as dongles & hotspots almost equals the number of DMR users so it seems and it would be pretty possible to overload a wimpy network connection.

Although not for really necessary for my own application, I will say "YES" it would be helpful for the sake of the couple c-Bridge ops I know.

However, Matthew 2E0SIP makes a very good point... VPN access could control the users as well.  I use a VPN called SoftEther that is very flexible and configurable.  Check it out!

73
Jon


On 7/6/2018 9:32 AM, Cort N0MJS via Groups.Io wrote:
First off, in your original post you said: "Is there a way to have an "authorized user" list in the MMDVM Server?”

I don’t know what an “MMDVM Server” is because I didn’t write any programs called that. I *think* what you want is a black/white list option for allowing clients to connect to hblink.py when it’s configured as a master. Is this what you’re asking for? I know you’re probably cussing me right now for being pedantic, but believe me, after 5 years on this project, I’ve learned we have to be accurate and explicit. If it is what you’re asking, here are my thoughts:

1) HBlink wasn’t written to be a hotspot aggregator, though I realize it’s become that to a number of users.
2) This sounds like a solution b/c systems operators are not adequately controlling their end-users – I know, it’s really hard to control some people.

So how would we go about doing this? IP address isn’t good because too many NAT addresses change too often. It would almost have to be by the radio ID of the client connecting. But if you have users tossing about the password, would they not do the same with the radio ID of their hotspot? The only reasonable way I can think of is by radio ID.

Adding the “feature” would not be complicated. I could kick it out in the next few days. My concern is whether or not it would adequately address the issue, or just push it off into yet another issue. Because there’s one thing I will not do, which is keep chasing solutions for problems that only exist because bad actors are passing around login credentials on one system out there.

I’d like more than one person to say “this would be really beneficial to me”, and all of you who say that to tell me that if the users just find another way to be bad, you won’t be back for another technical solution to an administrative problem – because using technology to continually solve an administrative (human) problem usually creates collateral damage and diminishing returns.

I’d like to see 5 YES votes before I proceed. I can make a poll for the group, but would rather just see some replies to this with one word “YES” or “NO”.

0x49 DE N0MJS


On Jul 6, 2018, at 8:12 AM, Rod - KC7AAD <kc7aad@...> wrote:

Anyone?? Ideas? Thoughts?

--
Cort Buffington
H: +1-785-813-1501
M: +1-785-865-7206







Rod - KC7AAD
 

YES!


Rod - KC7AAD
 

That out of the way...

Cort, I agree that by DMR ID would be the better way. It's easy enough to blacklist (or remove from whitelist) if a user shares his ID with others. 
I do agree that administratively the user issue is tough to control. We have a few folks in our group that seem to flaunt that they push the line. Even after outright banning a user, they still continue to try and push. This is no different.
We will change the passwords at intervals, and that takes care of them for a while, until someone leaks it out.
We have around 70 users connecting to 8 servers up here in the PNW. 1 of which we allow "public" access and do share those credentials. The others have specific talkgroups allowed through them.

The VPN solution might work, though to make it seamless, it would require some work on the pi-star device and / or the openspot device. Neither of those options are easy to implement, if even possible.
I have thought about standing up instances for each user, then they could 'auth' to their own. We are using Docker to run multiple instances on one VM, varying them by UDP ports and passwords. The problem becomes how much administration would there be of this, and could the user dynamically change his own TG group? Or do we just give him one set? I'd be interested to see how Brandmeister does their setup for each hotspot being able to set up its own TG deck lineup, and having hundreds (thousands?) or users!


Regardless, Cort.. thanks for your work. I think that making a black / white list approach makes sense, barring any better way to do this without changes here as well as to the hotspots, too. That coordinated effort might not be easy.

Rod / KC7AAD


Rod - KC7AAD
 

I think white listing would be better. Deny all unless they match in a list.


Cort N0MJS <n0mjs@...>
 

I have 2.5 days of vacation left and one project ahead of this. I *should* be able to get to this before the end of vacation.

My goal is to, assuming it works, is to list the relatively simpler ACL code from confbridge/hb_confbridge and put that into hblink.py as an option, and it will be regarding radio IDs and registration to hblink.py as a master.

0x49 DE N0MJS



On Jul 11, 2018, at 8:42 AM, Rod - KC7AAD <kc7aad@...> wrote:

I think white listing would be better. Deny all unless they match in a list.

--
Cort Buffington
H: +1-785-813-1501
M: +1-785-865-7206






Cort N0MJS <n0mjs@...>
 

Alright boys… give that a shot.

On Jul 11, 2018, at 8:42 AM, Rod - KC7AAD <kc7aad@...> wrote:

I think white listing would be better. Deny all unless they match in a list.

--
Cort Buffington
H: +1-785-813-1501
M: +1-785-865-7206