Skip to main content
  • IETF 117 Highlights

    IETF 117 is a few weeks behind us and Dhruv Dhody, IAB Member and liaison to the IESG, took the opportunity to report on a few highlights and some impressions.

    • Dhruv DhodyIAB Member and liaison to the IESG
    21 Aug 2023
  • Proposed response to meeting venue consultations and the complex issues raised

    The IETF Administration LLC recently sought feedback from the community on the possibility of holding an IETF Meeting in the cities of Beijing, Istanbul, Kuala Lumpur and Shenzhen, with received feedback including views that were well expressed and well argued but strongly conflicting. The IETF LLC has considered this feedback in-depth and now seeks community feedback on its proposed response.

    • Jay DaleyIETF Executive Director
    21 Aug 2023
  • Submit Birds of a Feather session proposals for IETF 118

    Now's the time to submit Birds of a Feather session (BOFs) ideas for the IETF 118 meeting 4-10 November 2023, with proposals due by 8 September.

      16 Aug 2023
    • Applied Networking Research Workshop 2023 Review

      More than 250 participants gathered online and in person for ANRW 2023, the academic workshop that provides a forum for researchers, vendors, network operators, and the Internet standards community to present and discuss emerging results in applied networking research.

      • Maria ApostolakiANRW Program co-chair
      • Francis YanANRW Program co-chair
      16 Aug 2023
    • IETF 117 post-meeting survey

      IETF 117 San Francisco was held 22-28 July 2023 and the results of the post-meeting survey are now available on a web-based interactive dashboard.

      • Jay DaleyIETF Executive Director
      11 Aug 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