> On Dec 31, 2019, at 11:06 AM, Pete Eisengrein <peeip...@gmail.com> wrote:
> > Thoughts on implementation/technologies? Where in the network would you do > your assertion (softswitch, SBC, other?), Many of the implementations allow SHAKEN over SIP, using a 302 to add the Identity header. This is much more convenient than having to use the original HTTPS interface, because you really do have the options to do it in many places. The signing gadgets (STI-AS) are fairly blind... they'll sign anything that comes in to them with proper authentication. I'm guessing one of the big risks will be sending calls through the STI-AS that shouldn't go through it. So for A-level attestation (the "highest levels of trust" in the word of the TRACED Act), we really want authentication to be done by a device that knows the call originated from a known user, and the known user was calling from a phone number they had rights to call from. The STI-AS doesn't know whether call screening (which ensures the user only calls from a number directly assigned to that user) is active. What we really want is the BroadWorks AS or the Metaswitch CFS to send the call to the STI-AS only if the user is calling from their own number. > and where would you authenticate incoming (my inclination is to do it at the > SBC edge)? Two points to be made here: 1. The idea of "authenticating the incoming calls" only applies if you're really going to block incoming calls. The mood of the industry is that -- (A) We want to Display information about the authenticity of the call. "Call Verified" or "Spam likely", etc. (B) We need an Analytics that make the best guess about the caller's authenticity. (Think: AT&T Call Protect, powered by Hiya.) (C) SHAKEN/STIR is one of those inputs to the Analytics systems. That is to say: callers are concerned about blocking, but carriers who are testing SHAKEN/STIR right now aren't really thinking of doing blocking. 2. Because the big goal of the verification is display, not blocking, we can expect verification (STI-VS) before the analytics platform, which is before the call is sent to the final recipient. Slides from my SIPNOC presentation on hacking SHAKEN/STIR: Lindsey_SHAKEN_STIR_White-Hat_Security_Analysis_-_SIPNOC_2019-2019-11-02-1820.pdf <https://www.ecg.co/files/resources/files/2/Lindsey_SHAKEN_STIR_White-Hat_Security_Analysis_-_SIPNOC_2019-2019-11-02-1820.pdf> https://www.ecg.co/files/resources/files/2/Lindsey_SHAKEN_STIR_White-Hat_Security_Analysis_-_SIPNOC_2019-2019-11-02-1820.pdf My presentation focused Bad Actors who don't register with anybody. But after my presentation, Jon Peterson (who wrote much of the SHAKEN RFCs) added another security gap in the American implementation: anybody can get an OCN and CLLI code, access to numbers, get a Service Provider Token and a signing Certificate from the PA/CA, and then sign every call they want to from any number they want to. Mark R Lindsey, SMTS | +1-229-316-0013 | m...@ecg.co | https://ecg.co/lindsey/ <https://ecg.co/lindsey/>
_______________________________________________ VoiceOps mailing list VoiceOps@voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
