Causing a STIR

In just the last few months, information about robocalling and STIR has appeared in the The New York Times, USA Today, industry outlets, regulatory authority statements, and company press releases.

The Session Initiation Protocol (SIP) RFC 3261 is an IETF real-time communications protocol which has seen widespread use in Voice over Internet Protocol (VoIP) telephone network deployment. While we were working on SIP in the early 2000s, we recognized that it faced some challenges when it came to authenticating user identities. SIP borrowed the “From” header field from email but, like email, SIP offered no way for the recipient of a message to verify that the From was trustworthy. Many early SIP deployments adopted the existing security features of the telephone network, so in the short term we added a new SIP header called “P-Asserted-Identity” which providers could fill in with the “real” identity of a caller, much as telephone services do based on a “trusted network” model.

In parallel, we started an effort for a long-term SIP identity solution based on cryptographic tools, which would provide a more robust foundation for assertions about a caller’s identity. That began with a 2002 Internet-Draft (draft-peterson-sip-identity) which defined a new “authentication service” role for SIP that would generate a cryptographic signature over a subset of the header field values in a SIP request, including the From field. Requests would be signed by the certificate of the originating domain: so if the From header field read “sip:alice@example.com”, the signing certificate had to be for “example.com”. This initial work concluded with the publication of RFC 4474 in 2006, which defined the SIP Identity header field.

RFC 4474 did not, however, see any practical deployment for a couple of reasons. First, it only worked well for calls placed from email-style identities like alice@example.com. Because, in practice, most commercial SIP services remained telephone-number based and there were no recognized certification authorities for telephone numbers, you could not readily get a certificate for an identity like +1-510-555-4141. Second, the cryptographic protection for header fields it specified was too strict, which caused false negatives when network intermediaries routinely altered SIP signaling in transit, as valid calls would look suspicious.

Meanwhile, as SIP adoption ramped up, so did widespread telephone calling number impersonation, which has become a key enabler of illegal robocalling and fraud. We thus decided to revisit the secure telephone identity problem. The first informal STIR meeting was held on May 31, 2013, in Washington, D.C., followed shortly thereafter by a Birds of a Feather (BoF) session at IETF 87 in Berlin, and then the formation of a working group. 

Work towards STIR proceeded cautiously, capturing requirements and threats, as well as exploring several fundamentally different technical approaches. It was crucial to deliver a mechanism that would work in the SIP carrier environment, which led us to work jointly with the IP Network-to-Network interface (IP-NNI) Joint Task Force of the Alliance for Telecommunication Industry Standards (ATIS) and the SIP Forum. The IP-NNI developed SHAKEN (Signature-based Handling of Asserted information using tokeN), a profile of STIR that is aligned with North American operator practices. It includes additional attributes carried in signaling, as well as a governance model for distributing certificates. ATIS also publishes call flows and operational practice documents that are essential to carrier adoption.

A revision of RFC 4474 would be published as RFC 8224 in 2018, along with the new, more flexible “PASSporT” signature format document (RFC 8225) and a specification for issuing certificates for telephone numbers and related telephone network identifiers (RFC 8226). PASSporT extensions to support SHAKEN are now captured in RFC 8588. It is our aim that this core STIR/SHAKEN protocol suite will help rid the telephone network of the impersonation attacks facing it today, which will facilitate the identification of illegal robocalls and their perpetrators. As the regulatory environment evolves, STIR will provide a key input to the analytics that service providers will use to block robocalls so they never reach consumers.

As initial deployments roll out in 2019, we will continue to expand and refine the solution. Today, the STIR working group is looking at subjects such as securing non-SIP calls using the same credentials and signature formats (draft-ietf-stir-oob), providing richer display information about callers (draft-ietf-stir-passport-rcd), and issuing certificates to non-carrier service providers (draft-ietf-stir-cert-delegation). Work also continues jointly in the Automated Certificate Management Environment of the IETF on simplifying STIR certificate management. Ultimately, we aspire to build a robust set of tools that can rid us of this public nuisance and restore trust in telephone calls.