Hi Christian,
Thanks for your review. I agree with your general concerns and this has been an ongoing discussion for both SIP more generally and recently with stir as a mechanism that is supporting larger security frameworks that impose an ecosystem specific set of policies for the participation in the SIP network, but also for the importance of vetting of entities behind a telephone number and the information and metadata that is asserted within frameworks like call-info and rich call data.
I propose adding the following paragraphs to the security considerations section:
~~~~~~~
The SIP framework, defined in {{RFC3261}} and the various extensions to SIP, which stir {{RFC8224}} and rich call data {{I-D.ietf-stir-passport-rcd}} are included, since its existence has provided mechanisms to assert information about the person or entity behind the call. This can be a feature that can be a benefit to the SIP network that allows users to help identify the calling party behind an abstract telephone number. It can also enable the ability for actors to impersonate a calling party they are not authorized to represent. The core security consideration that either explicitly or implicitly have been acknowledged with any of the SIP and stir specifications is that there is a management and policy layer that validates the participants in the ecosystem and their use of a SIP network with telephone number identifiers and identity related information. The use of this specification should weigh this responsibility and make the appropriate considerations to validate the proper participation and use of these tools follow these larger security, impersonation prevention, and privacy considerations.
The use of this specification with the insertion of meta data related to a caller or the purpose of the call should recognize the risk that this information can be viewed by those network elements and participants in the delivery of the SIP call. Largely, any information that is included in rich call data should be considered public and this specification does not define any mechanism to protect this information beyond the security and privacy associated with the SIP signalling itself. This is a property that is consistent with SIP more generally and this specification follows a similar pattern for its use.
This specification contains the ability to include media resources and URI and URL resource references to media resources that could pose a threat when referencing or decoding the content of these media resources similar to threats that web browsers and other media decoding applications must be concerned about. A network specific set of policies or best practices for the use and hosting of media content that is agreed to contain validated media resources that have been evaluated to not pose a security threat to the participants or the devices supported in the ecosystem should be considered.
~~~~~~~
Hopefully those statements help address your concerns. If you aren’t aware, much of these security related policies and frameworks are being put in place and many of your concerns have been echoed my many technical and product leaders and policy makers associated with telephone networks around the world already. The telecommunications industry is absolutely taking this very seriously. Obviously there is a lot of potential liability associated with getting it wrong, so we are on a good path to carefully, slowly, purposefully add these important features that are common in many communications apps to the public telephone network. It’s very important work that no one is taking lightly.
I will submit a -14 that adds these changes along with addressing other review comments.
Thanks!
-Chris
> On Feb 15, 2025, at 3:18 PM, Christian Huitema via Datatracker <noreply@xxxxxxxx> wrote:
>
> Reviewer: Christian Huitema
> Review result: Has Issues
>
> I have reviewed this document as part of the security directorate's
> ongoing effort to review all IETF documents being processed by the
> IESG. These comments were written primarily for the benefit of the
> security area directors. Document editors and WG chairs should treat
> these comments just like any other last call comments.
>
> The summary of the review is Almost Ready.
>
> I have a major concern about the whole idea of providing "Rich
> Call Data" (RCD) in SIP calls. Making the call data richer is a tradeoff
> between ease of use and increased attack surface, with possible
> implications for privacy and safety of the called parties. Many
> users may fell that the ease of use is worth the increased risks,
> but we cannot assume that "one size fits all". Journalists or
> political opponents, for example, should be reluctant to make
> such tradeoffs. I will detail these risks in the reminder of
> the review. I wish that risks and tradeoffs be explicitly
> delineated in a revised security section.
>
> This document defines a framework for the use of Call-Info
> header field to carry RCD in SIP [RFC3261].
> It expands the use of parameters such as "purpose", "icon",
> adds a "jcard" token to the purpose token, and add new
> parameters such as "call-reason", "verified" and "integrity".
>
> The design "assumes that the called party UA
> can trust the SIP network or the SIP provider to assign, deliver, and
> protect the correct RCD information as an end-to-end security policy",
> but also recommends 'that the calling party signs the caller
> information through the use of RCD or the "rcd" PASSporT defined in
> [I-D.ietf-stir-passport-rcd].'
>
> In this review, I assume that the "STIR PASSporT" mechanism works as
> intended, and that when it is use the receivers can safely assume that
> the received information matches the values set by the calling party.
> That assurance would be greater if it was mandatory to sign using
> "STIR PASSporT" instead of merely optional. But "matching the callers
> intent" is not the same as "matching the callee's privacy and
> safety requirements".
>
> My first concern is that the richer information may be used to
> make spam more convincing, and maybe in harassment campaigns. The
> callers can state a "call purpose" of their choice, and pick any
> icon. Displaying the caller's picture when the phone rings seems
> cool, but spammers will love displaying a picture of the wares
> that they are pushing, and harassment campaigns can use purpose
> and icons to great effects.
>
> The second concern is the leakage of richer meta-data along the call path.
> We all heard the classic quote about "killing people because of metadata",
> adding purpose of call surely helps that. One of the examples
> has the call reason set to "For your ears only", which is not the
> kind of data J. Bond and Q might want to see stored in a variety
> of network archives. Users and UI designers should be aware that
> the call data is not encrypted end-to-end.
>
> Then there is the call home effect: visualizing the elements in the vcard
> requires downloading data from a URI designated by the caller. If the URI
> points to a server controlled by the caller, contacting the server informs
> this caller about the processing of the call. The caller will learn
> the current IP address of the callee and thus its location -- and they will
> learn that whether the callee accepts the call or not.
>
> Finally, there is the risk of Pegasus-like attacks. Remember how Pegasus was
> exploiting bugs in the handling of various media formats to install a virus
> on a target phone? I think we have similar risks here. Callers could use creative
> JSON syntax, or ask the receiver to parse a logo or icon in an obscure format.
> Automatically loading media and structured data substantially increases the
> attack surface of the calling system.
>
> Different users may have different risk profiles. We see that is current
> deployments, with phones treating calls differently if the caller is "unknown",
> and at risk users adopting a very restricted communication profile. An
> example of restriction would be to never display "rich call data" from
> unknown callers. Another would be to never download information from
> remote servers. Yet another would be to never process rich call data
> if not signed using "STIR PASSporT". These are all different levels of
> tradeoffs between ease of use and safety. I think that the security
> section should point out the risk and suggest that UA designs allow
> different users to pick different configurations.
>
>
--
last-call mailing list -- last-call@xxxxxxxx
To unsubscribe send an email to last-call-leave@xxxxxxxx
