The most common approaches we see in networks are, with the strongest at the top, are: 1. Mutual TLS with X.509 Attribute Validation 2. Mutual TLS without X.509 Attribute Validation 3. Per-device credentials (HTTP username/password) 4. Per-device-type credentials (HTTP username/password) 5. IP allow-list to permit only certain clients to download 6. Funny filenames (like https://xsp.serviceprovider.com/dms/CustomModifiedPolycomVVX/ ) The first one, Mutual TLS (verifying the device's certificate created by proper manufacturer) with X.509 Attribute Validation (like MAC address) requires this: -- HTTPS -- When the client connects, the server requests the client certificate -- The server checks to see if the client certificate matches the requested file type. For example, if you're requesting a Cisco MPP file, then the client should be presenting a certificate signed by Cisco. -- The server checks the content of the certificate against the specific file. For example, if the file requested is /0abcdef12345.cfg then the Certificate X.509 attributes SAN or CN should contain the MAC address 0ABCDEF12345. The formatting of the SAN or CN can vary. Because devices don't generally have Hardware Security Modules to protect the TLS secret key for the certificate signed by the manufacturer, I believe some attackers will, someday, determine how to retrieve the secret key and certificate from some device. Though I've analyzed many attacks on SIP device management, I am not personally aware of any examples of the disclosure of a secret key from a device. I expect it to occur someday because of the way the software on certain devices manages those keys. To defend against that eventuality, and the ability to weaponize it into a tool, I would not want to rely only on a client's ability to provide any signed certificate provided by one of my trusted vendors to download any configuration file. For example, I would not want to allow a HTTPS client with a Yealink certificate to download a Poly config file. Further, by validating the MAC address inside the X.509 attributes, I am defending against this case by ensuring that the disclosed certificate and key can only be used to access files for a single MAC address from a specific manufacturer. In our case, we've implemented this in multiple networks with F5 Labs LTM. The builtin BroadWorks support doesn't do all that is needed. Mark R Lindsey, SMTS | +1-229-316-0013 | mark at ecg.co | https://ecg.co/lindsey/ <https://ecg.co/lindsey/>
On Oct 20, 2021, at 10:36 AM, Dave Sill <dave at socket.net> wrote:
All,
I?m interested in what you?re doing to protect Broadworks device profile files. Unique credentials for access, IP whitelist, HTTPS, something else?
Thanks,
Dave Sill IT Director, Socket Telecom <https://www.socket.net/> 573-817-0000 ext 211
_______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops