Skip to main content
  • New Internet Architecture Board, IETF Trust, IETF LLC and Internet Engineering Task Force Leadership Announced

    Members of the incoming Internet Architecture Board (IAB), the IETF Trust, the IETF Administration LLC (IETF LLC) Board of Directors, and the Internet Engineering Steering Group (IESG)—which provides leadership for the Internet Engineering Task Force (IETF)—have been officially announced, with new members selected by the 2021-2023 IETF Nominating Committee.

      13 Feb 2023
    • Informing the community on third-party correspondence regarding the W3C

      In accordance with our policy of transparency, this blog post is being published in order to keep the community informed about recent correspondence with lawyers acting on behalf of the Movement for an Open Web.

      • Lars EggertIETF Chair
      8 Feb 2023
    • Six Applied Networking Research Prizes Awarded for 2023

      Six network researchers have received Internet Research Task Force Applied Networking Research Prize (ANRP), an award focused on recent results in applied networking research and on interesting new research of potential relevance to the Internet standards community.

      • Grant GrossIETF Blog Reporter
      9 Jan 2023
    • Travel grants allow Ph.D. students to participate at IETF meeting in-person

      Sergio Aguilar Romero and Martine Sophie Lenders, both Ph.D. students in technology fields, attended and participated in the IETF 115 meeting in London with assistance through travel grants from the Internet Research Task Force.

      • Grant GrossIETF Blog Reporter
      7 Jan 2023
    • Impressions from the Internet Architecture Board E-Impact Workshop

      The IAB ran an online workshop in December 2022 to begin to explore and understand the environmental impacts of the Internet. The discussion was active, and it will take time to summarise and produce the workshop report – but the topic is important, so we wanted to share some early impressions of the outcomes.

      • Colin PerkinsIAB Member
      • Jari ArkkoIAB Member
      6 Jan 2023

    Filter by topic and date

    Filter by topic and date

    Causing a STIR

    • Jon Peterson

    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