Skip to main content
  • IETF mailing lists delivery issues resolved

    During a period from May 6 to May 9, a number of messages intended for IETF, IRTF, IAB, IESG, and RFC-Editor email lists were accepted by email services, but not forwarded to the list members or the list archives. All identified messages have now been processed by intended mailing lists for delivery to current list subscribers, and will appear in list archives.

    21 May 2024
  • Experimental survey of meeting non-returners

    We are experimenting with a new survey to help understand why people participate in one IETF meeting but not the meeting following.

    26 Apr 2024
  • IETF Community Survey 2023

    The final report on the IETF Community Survey 2023 is now available.

    25 Apr 2024
  • IETF Snapshot 2023

    Want to catch up on IETF activity in 2023? The IETF Snapshot provides a short summary of IETF activity for the previous year.

    17 Apr 2024
  • UN Report Calls for New Era for Digital Governance in which Tech Standards Respect Human Rights

    In a major milestone in the movement to consider human rights impacts of technology, the United Nations High Commissioner for Human Rights details the obstacles and opportunities posed by technical standards setting to the enjoyment of human rights in a new report.

    16 Apr 2024

Filter by topic and date

Filter by topic and date

Causing a STIR

12 Aug 2019

Recently, the output of the IETF Secure Telephony Identity Revisited (STIR) working group has received considerable attention from service providers, regulators, and the press because it addresses some of the root causes of the illegal robocalling which has crippled the telephone network.

In just the last few months, information about robocalling and STIR has appeared in the The New York TimesUSA Todayindustry 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 “”, the signing certificate had to be for “”. 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 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. 


  • [1]RFC 3261

    SIP: Session Initiation Protocol

    This document describes Session Initiation Protocol (SIP), an application-layer control (signaling) protocol for creating, modifying, and terminating sessions with one or more participants. These sessions include Internet telephone calls, multimedia distribution, and multimedia conferences. [STAND…

  • [2]RFC 4474

    Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP)

    The existing security mechanisms in the Session Initiation Protocol (SIP) are inadequate for cryptographically assuring the identity of the end users that originate SIP requests, especially in an interdomain context. This document defines a mechanism for securely identifying originators of SIP mes…

  • [3]RFC 8224

    Authenticated Identity Management in the Session Initiation Protocol (SIP)

    The baseline security mechanisms in the Session Initiation Protocol (SIP) are inadequate for cryptographically assuring the identity of the end users that originate SIP requests, especially in an interdomain context. This document defines a mechanism for securely identifying originators of SIP requ…

  • [4]RFC 8225

    PASSporT: Personal Assertion Token

    This document defines a method for creating and validating a token that cryptographically verifies an originating identity or, more generally, a URI or telephone number representing the originator of personal communications. The Personal Assertion Token, PASSporT, is cryptographically signed to pr…

  • [5]RFC 8226

    Secure Telephone Identity Credentials: Certificates

    In order to prevent the impersonation of telephone numbers on the Internet, some kind of credential system needs to exist that cryptographically asserts authority over telephone numbers. This document describes the use of certificates in establishing authority over telephone numbers, as a componen…

  • [6]RFC 8588

    Personal Assertion Token (PaSSporT) Extension for Signature-based Handling of Asserted information using toKENs (SHAKEN)

    This document extends the Personal Assertion Token (PASSporT), which is a token object that conveys cryptographically signed information about the participants involved in communications. The extension is defined based on the "Signature-based Handling of Asserted information using toKENs (SHAKEN)"…

  • [7]Automated Certificate Management Environment

    Automated Certificate Management Environment

Share this page