<div dir="ltr">James,<div><br></div><div>By the DOCSIS standard and every North American MSO's ToS I've seen (I've worked with or for about 200 different cable operators over the last 20 years) your cable modem is always managed and the cable operator _always_ has access to its configuration and settings via SNMP.  The configuration file for a DOCSIS cable modem is nothing more than a list of SNMP OIDs with their values set the way the operator wants them.  This has been true since DOCSIS 1.0 (which doesn't make it correct, just common).  Now, DOCSIS is primarily deployed with SNMP version 2c though more and more operators, especially the larger ones, are moving or have to SNMPv3.  I mention this because every cable modem on a given CMTS that's deployed in SNMPv2c mode will (should for proper functioning) have the same SNMP READ and WRITE strings.  SNMPv2c traffic is clear text UDP with no standardized methods of encryption available to the industry.  To mitigate this to an extent part of the cable modem's configuration will (best practice anyway) have filtering rules to only accept SNMP traffic from a given IP address or subnet and traffic between the CMTS and the modem should be encrypted via BPI+ for some minimal security.  (A minor note, the router interface for a combo unit by CableLabs OSS standards will not respond to SNMP traffic on its public address by default and almost all of the SNMP traffic will be to the modem's RFC1918 address.)  What I'm getting at is that the for DOCSIS (and FTTH and most DSL flavors as well) the service provider has and has had access to all the settings for a very long time.  What's changed is that customers wanted to WiFi to be provided by the operator and importantly supported by the operator.</div><div><br></div><div>"
I have yet to hear any discussion of the business value of access to WiFi network password, especially as compared to billing and identity data. Also, remote management of local networks by definition requires credentials stored off site from the customer. To the typical customer, loss of connectivity is much worse than a small chance of sharing the WiFi."<br><br>Let me provide something in this regard.  The most common support call category, by a large number, is the WiFi category.  In excess of 55% of all support calls (regardless of how the customer describes them) end up being WiFi issues.  The most common specific call in that category is some variation of, "I've forgotten my WiFi password and I need to get my new iPad online."  As a service provider your choices are to say I can reset your WiFi PSK, which allows the new device to come online but breaks everything else that was connected, or to allow the support rep and/or customer to recover the passphrase.  In short, the ability to recover the passphrase is strongly preferred by end users over resetting it and frankly is much less expensive for the operator.<br><br>I've helped supply this functionality to a large number of operators and in general the implementations _should_ at a minimum be able to capture the agent who recovered the passphrase, the time/date, who the agent was on the phone with, whether the agent correctly verified the identity of the caller, and if the agent followed all other procedures laid by the service provider.  <br><br clear="all"><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr">Scott Helms<br><br></div></div></div></div></div></div></div></div></div></div></div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Apr 25, 2019 at 8:38 AM James R Cutler <<a href="mailto:james.cutler@consultant.com">james.cutler@consultant.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="overflow-wrap: break-word;"><div><blockquote type="cite"><div>On Apr 25, 2019, at 8:26 AM, K. Scott Helms <<a href="mailto:kscott.helms@gmail.com" target="_blank">kscott.helms@gmail.com</a>> wrote:</div><br class="gmail-m_-8167661826491381945Apple-interchange-newline"><div><div dir="ltr"><div dir="ltr">People are missing the point here.  This is _not_ a Comcast "issue" this same data is available to every single cable operator in the US who deploys bundled modem/router/APs that follow the CableLabs standard.  They may or may not expose the data to their end customers, but it's stored in their systems and is often available to their support teams.<br><br><a href="http://mibs.cablelabs.com/MIBs/wireless/CLAB-WIFI-MIB-2017-09-07.txt" target="_blank">http://mibs.cablelabs.com/MIBs/wireless/CLAB-WIFI-MIB-2017-09-07.txt</a>  </div><div dir="ltr"><br></div><div dir="ltr">The same thing applies to most FTTH and xDSL deployments.  They use TR-069 to collect the data instead of SNMP but the object model is the same.  The WiFi MIB above is explicitly built to mimic TR-181 functionality.<br><br clear="all"><div><div dir="ltr" class="gmail-m_-8167661826491381945gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr">Scott Helms<br><br></div></div></div></div></div></div></div></div></div></div></div><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Apr 24, 2019 at 5:48 PM Rich Kulawiec <<a href="mailto:rsk@gsp.org" target="_blank">rsk@gsp.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Wed, Apr 24, 2019 at 03:13:33PM +0000, Benjamin Sisco wrote:<br>
> The bigger concern should be the cleartext portion of the subject.<br>
<br>
Yes, and the availability of all this to anyone who hacks Comcast<br>
customer support.<br>
<br>
—rsk</blockquote></div></div></div></blockquote><br></div><div>I have yet to hear any discussion of the business value of access to WiFi network password, especially as compared to billing and identity data. Also, remote management of local networks by definition requires credentials stored off site from the customer. To the typical customer, loss of connectivity is much worse than a small chance of sharing the WiFi.</div><div><br></div><div>Narrowing the discussion back to Comcast, credentials for “guest” WiFi seem to be more used than purloined SNMP MIB data.</div></div></blockquote></div>