OpenSIPit#01 Part 2: STIR/SHAKEN

OpenSIPit 2021 was held back in April with myself and Ben Ford representing Asterisk.  There were two main interoperability focuses this year:  the support of additional authentication digest algorithms specified by RFC-8760, and STIR/SHAKENPart 1 of this series addressed the former.  This post addresses the latter.

STIR/SHAKEN: Combating Spoofed Robocalls with Caller ID Authentication

A Bit Of History

In the past month, how many legitimate vs spoofed robocall phone calls did you receive?  ‘Nuff said. 🙂

Last year, Ben Ford described in STIR/SHAKEN in Asterisk the changes we were making to Asterisk to support the STIR/SHAKEN initiative.  Looking back though, we may have been a little premature in our implementation.  At that time, there weren’t many details about how user agents should actually implement their support so we took our best guesses in order to at least get a framework in place.  The very first interoperability test we did at OpenSIPit however demonstrated just how far we were off.  In fact, I don’t think we passed a single test.  Disaster you say?  NO!  We consider OpenSIPit01 to be wildly successful because it showed us what we really needed to implement.  We just wish we’d been able to do interoperability testing sooner.

Here’s What We Discovered:

Without going into too much detail:

  • X509 certificates need to be used instead of EC certificates.
  • The “dest->tn” wasn’t being set in our outgoing Identity header.
  • A SIP “Date” header wasn’t being added.
  • Requests with invalid certificate URLs weren’t being rejected.
  • Documentation around the 3 types of certificate expiration wasn’t very clear.
  • Handling of missing “Cache-Control” or “Expires” headers in the HTTP responses to GET requests for certificates needed to be tightened up.
  • Base64 encoding was being used instead of Base64URL encoding.
  • Orgids should be using randomly generated UUIDs.
  • There were name collisions  for cached certificates.
  • Responses to error conditions can’t be left to the user where the RFC says we MUST return a certain response code.


The list looks ominous but in reality the framework implemented last year is still valid.  There are only a few things on the list that require us to re-visit the approach but the rest  just need gaps filled.

Here’s Where We Stand:

By the time you read this, most of the list above will have been addressed.  There are still some outstanding implementation details that we’re trying to get clarification on but most of them concern off-nominal conditions.

More Info:

Keep an eye on the change logs for the next few Asterisk releases to see progress.  In the mean time, here are a few links for more info on STIR/SHAKEN:

FCC: Combating Spoofed Robocalls with Caller ID Authentication

Wikipedia: STIR/SHAKEN

 

 

Leave a Reply

Your email address will not be published. Required fields are marked *


The reCAPTCHA verification period has expired. Please reload the page.

About the Author

What can we help you find?