Re: [stir] Potential security vulnerability in STIR/DIV

David Hancock <davidhancock.ietf@gmail.com> Thu, 23 July 2020 15:35 UTC

Return-Path: <davidhancock.ietf@gmail.com>
X-Original-To: stir@ietfa.amsl.com
Delivered-To: stir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09CCD3A0909; Thu, 23 Jul 2020 08:35:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tFM4CI3HjpI6; Thu, 23 Jul 2020 08:35:16 -0700 (PDT)
Received: from mail-qk1-x72b.google.com (mail-qk1-x72b.google.com [IPv6:2607:f8b0:4864:20::72b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 048893A0817; Thu, 23 Jul 2020 08:35:16 -0700 (PDT)
Received: by mail-qk1-x72b.google.com with SMTP id l23so5753830qkk.0; Thu, 23 Jul 2020 08:35:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=h9qf0tgqeYb5Cs964qrq9EXwu6dykfSE0D6OlA95o6w=; b=dS1dpQ+oh1vj0K7YKQpSLJX7e1KSWQunQQnTXKxHj9m9XsJZ1ZvLIxzca3nfsBjDA3 ui3/QD+Pk2aI4AW6OxA7WXRs5rFEZE0wJa4xogrWZobvhccfwHZvRZ9GfmSyncrXMA38 54yJTBxFZwxX16sR9/FV5CFddTdwJHW03K+XdsvdsJqFX5HQBtHOjdPFRYu1aLm2z8Dt 5w6JoeHpvSBf6g2VouYYXs0rEWGf9JB9UYB4FuwkXuEatRdIYXFY2jaPnl0vF7m4lchJ J/r+mzQf39NZoLsRf9Nsu9LA+WGOF9QqFvuyjKqHAjCQXIcOc6ZdXFuX0TF5rDgLKLJD n54Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=h9qf0tgqeYb5Cs964qrq9EXwu6dykfSE0D6OlA95o6w=; b=KAIXukCeYpd2hqrvj7ZTJ19N4J2/4X3Il8hBr01OQdFY8WaTG8GfHIYY8ZBPqEDqXm TFkiLWrjymD8R+eakydfNHlMMe11C7Kc4ymOBSAgNC9lbQW9MMVR9liNWuIR2/j7HKdt iuSRqB0FTH+Ov/BvEVT8a6wTIkKE0moDzcRVODHxuNOUOaarq699O8QJZsSEN8cr1bPW 0ju2dkPKBdvtnTZXHvLilSOCkql4zYv0NK7vr35B7s9QrTEbVVhfDpbJSqGg98HgOMro j0Ri/niK1clKVMoh5T1pmZ62KRaIou5UYwj+mpm9KJzM7/TAwz33JavtRUzH505RzGqD MV1w==
X-Gm-Message-State: AOAM531bWiJtMxa88haqbTNQqhJPZDWvxSjMk2hALqDojZPSAABC05+k tuL4AJtuw/x7t3Y3XzPHNVBFROtwFBw2L5UDMrU=
X-Google-Smtp-Source: ABdhPJyWzIbhdP45o30opmbnuZaLdhYzIj1HBH6HmPxlTsqBLlVjrBmJCBeB/sOiBHNFaN5B7AYIhOcrRyChM8i8KW4=
X-Received: by 2002:a05:620a:4d5:: with SMTP id 21mr5457953qks.439.1595518515066; Thu, 23 Jul 2020 08:35:15 -0700 (PDT)
MIME-Version: 1.0
References: <BYAPR02MB5189FF21A49BA034796C44F1F3790@BYAPR02MB5189.namprd02.prod.outlook.com> <89AC11DC-7E1A-4D1E-9CB8-96C98E790EF5@team.neustar> <BYAPR02MB5189A165DCE3CDE106FEDD6EF3760@BYAPR02MB5189.namprd02.prod.outlook.com>
In-Reply-To: <BYAPR02MB5189A165DCE3CDE106FEDD6EF3760@BYAPR02MB5189.namprd02.prod.outlook.com>
From: David Hancock <davidhancock.ietf@gmail.com>
Date: Thu, 23 Jul 2020 09:35:04 -0600
Message-ID: <CAM7yphYScKetxMg894szmcRm-FEHt5c1CUVzgen=c+-hjp+W4A@mail.gmail.com>
To: Jack Rickard <Jack.Rickard=40metaswitch.com@dmarc.ietf.org>
Cc: "Peterson, Jon" <jon.peterson@team.neustar>, "stir@ietf.org" <stir@ietf.org>, "draft-ietf-stir-passport-divert@ietf.org" <draft-ietf-stir-passport-divert@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000052c17f05ab1d9aff"
Archived-At: <https://mailarchive.ietf.org/arch/msg/stir/L0qTqWDgOExdQ6QjG72RZho1Ocw>
Subject: Re: [stir] Potential security vulnerability in STIR/DIV
X-BeenThere: stir@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Secure Telephone Identity Revisited <stir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/stir>, <mailto:stir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/stir/>
List-Post: <mailto:stir@ietf.org>
List-Help: <mailto:stir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/stir>, <mailto:stir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 23 Jul 2020 15:35:19 -0000

Could the verification service in step-5 detect/block the attack using this
procedure described in Section 12.1 of RFC 8224?

  "... servers can keep
   state of recently received requests, and thus if an Identity header
   field is replayed by an attacker within the Date interval, verifiers
   can detect that it is spoofed because a message with an identical
   Date from the same source had recently been received."

David Hancock
Comcast

On Thu, Jul 23, 2020 at 7:22 AM Jack Rickard <Jack.Rickard=
40metaswitch.com@dmarc.ietf.org> wrote:

> I agree that div does make this kind of attack more difficult, and
> requiring that there is some trust of every retargeting entity does make
> sense. My assumption was that by only trusting the signers of the passports
> I can trust the orig is the entity calling me, I now see you have to trust
> the signers and the diverting parties. To clarify this I propose that
> something like your explanation is added to the spec, i.e.
>
> It is Carol who needs to decide if a forwarded call from Bob should be
> trusted or not – “div” is certainly not suggesting that trust is automatic,
> nor that the presence of a “div” that correctly chains to the original
> PASSporT is a substitute for the policy and trust decision made on the
> terminating side of a call. As with baseline STIR, just because something
> validates at a protocol level doesn’t mean you should trust it, nor that
> local policy does not determine how you treat calls.
>
>
>
>
>
> To be clear, my original email was based on the belief that div passports
> would provide a "chain-of-trust", allowing you to essentially ignore that
> diversions had occurred once you had established there was a valid chain of
> div passports from the originator to the final destination. Although, after
> reading your response I realise that's not the case.
>
>
>
> My worry is that this model makes div difficult to use and police in
> practice, specifically:
>
>    - This model makes implementations more complicated as you can't
>    separate verification from policy decisions. You have to filter out
>    untrusted parties before doing the chain finding step of verification, as
>    otherwise you might decide upon a chain containing an untrusted party when
>    there does exist a valid chain containing only trusted parties (granted
>    this situation is unlikely).
>    - This model introduces complexity in what should be displayed to a
>    user, the simple verified/not verified can't be used unless you require
>    complete trust of all diverting parties, and that could cause false
>    negatives.
>    - If a diverted call does get reported as a robocall, it's not clear
>    whose reputation should be tarnished. It may have been that the original
>    caller was a robocaller and the call got legitimately diverted to you, or
>    it was the below attack where the caller is trustworthy but the diverter
>    was the robocaller.
>
>
>
> Thanks,
>
> Jack
>
>
>
> *From:* Peterson, Jon <jon.peterson@team.neustar>
> *Sent:* 22 July 2020 23:53
> *To:* Jack Rickard <Jack.Rickard@metaswitch.com>; stir@ietf.org;
> draft-ietf-stir-passport-divert@ietf.org
> *Subject:* Re: Potential security vulnerability in STIR/DIV
>
>
>
> NOTE: Message is from an external sender
>
>
>
> Potential “baiting” attacks of this form emerge when you combine baseline
> STIR with call forwarding, and are the main threat articulated in the IETF
> “div” draft. The introduction describes them as follows:
>
>
>
>    If Alice calls Bob, for example, Bob might
>
>    attempt to cut-and-paste the Identity header field in Alice's INVITE
>
>    into a new INVITE that Bob sends to Carol, and thus be able to fool
>
>    Carol into thinking the call came from Alice and not Bob. With the
>
>    signature over the To header field value, the INVITE Carol sees will
>
>    clearly have been destined originally for Bob, and thus Carol can
>
>    view the INVITE as suspect.
>
>
>
> That describes the situation in a world without “div”, so the question is,
> does “div” make these sorts of attacks easier to harder to mount?
>
>
>
> Without “div”, in the example above, Carol will see that the original
> called number does not match hers, and can decide on those grounds to
> reject the call. But bear in mind this is also what Carol would see in
> legitimate forwarding cases, so a more nuanced logic would probably be
> used. She could decide that if the original called number is a number that
> should be forwarding calls to her (say, if it was her office), that she
> should accept the call anyway. You could even imagine application behavior
> that would enforce policies along those lines on her behalf. However, Carol
> has no assurance that it was really her office that forwarded this call,
> rather than some eavesdropper who somehow captured the PASSporT, nor how
> many times it might have been redirected before reaching her, or anything
> along those lines.
>
>
>
> Those are the gaps that “div” is meant to fill. It is not a substitute for
> the rest of the logic and policy described above, but it gives Carol more
> information to help figure out if the call is suspect and what to do about
> it. With “div”, what Carol sees is a second PASSporT created and signed by
> Bob, which actually gives Carol the assurance of whether the intended
> called party is one who retargeted the call, which you don’t get in the
> absence of “div”. If Bob is doing this maliciously, the “div” he provided
> has given Carol the means to hunt him down for redress, which is not
> exactly a strong incentive for him to use “div”. But at the end of the day,
> it is Carol who needs to decide if a forwarded call from Bob should be
> trusted or not – “div” is certainly not suggesting that trust is automatic,
> nor that the presence of a “div” that correctly chains to the original
> PASSporT is a substitute for the policy and trust decision made on the
> terminating side of a call. As with baseline STIR, just because something
> validates at a protocol level doesn’t mean you should trust it, nor that
> local policy does not determine how you treat calls.
>
>
>
> But all that said, if you’re serious about security, then yes, using
> DTLS-SRTP with “mkey” is going to provide you with a better assurance.
>
>
>
> Jon Peterson
>
> Neustar, Inc.
>
>
>
> *From: *Jack Rickard <Jack.Rickard@metaswitch.com>
> *Date: *Wednesday, July 22, 2020 at 9:47 AM
> *To: *"stir@ietf.org" <stir@ietf.org>, "
> draft-ietf-stir-passport-divert@ietf.org" <
> draft-ietf-stir-passport-divert@ietf.org>, "Peterson, Jon" <
> jon.peterson@team.neustar>
> *Subject: *Potential security vulnerability in STIR/DIV
> *Resent-From: *<alias-bounces@ietf.org>
> *Resent-To: *<jon.peterson@team.neustar>
> *Resent-Date: *Wednesday, July 22, 2020 at 9:47 AM
>
>
>
> Hello,
>
>
>
> I believe I've come across a security vulnerability in the STIR system
> that is made exploitable by the introduction of DIV passports, that I
> haven't seen discussed here in any detail (sorry if it has been). There are
> currently mitigations for it in the passport spec, however I don't believe
> they go far enough to prevent this attack.
>
>
>
> The high level summary is that an attacker can impersonate an entity that
> called them by pretending they redirected that call to the recipient.
>
>
>
> An example:
>
>
>
> Trusted: A party trusted by Subject, which Attacker wishes to impersonate
>
> Attacker: The party wishing to impersonate Trusted
>
> Subject: The intended target of Attacker, who will see a verified call
> coming from Trusted
>
>
>
> 1.       Attacker gets Trusted to call them.
>
> This is a reasonable operation, and is actually quite a common feature of
> support companies so you don't have to sit on hold.
>
> 2.       Attacker answers/rejects the call and saves off the SHAKEN
> passport for Trusted -> Attacker.
>
> 3.       Attacker sets up a redirect from them to their intended Subject.
>
> 4.       Attacker constructs a call (claiming to be) from Trusted to
> Attacker with the previously saved SHAKEN passport.
>
> 5.       The call will be verified, then redirected to Subject with a DIV
> passport for Attacker -> Subject.
>
> This does rely on the certificate signing the DIV to belong to a trusted
> entity, this seems possible, as the redirect could be carried out by
> Attacker's service provider.
> Attacker's SP may refuse to redirect after some time due to IaT timeouts,
> but this is not required by the spec and I believe this can be worked
> around by, for example, repeatedly bouncing new calls off an accomplice.
>
> 6.       Subject receives a call claiming to be from Trusted (albeit
> redirected from Attacker) with a valid passport chain of Trusted ->
> Attacker -> Subject.
>
> Both passports will be signed by trusted entities: Trusted's SP and
> Attacker's SP.
>
> IaT doesn't provide much protection here as, in the presence of DIV
> passports, the valid time range must be set reasonably high to allow for
> the possibility of ring-arounds.
>
> The origid and attest will be associated with Trusted, eroding any
> automated databases of robocalls based on the origid.
>
>
>
>
>
>
>
> The "mky" claim seems to be the solution that is currently built into
> passports, however, it is currently optional, and as far as I am aware
> using certificates to authenticate the ends of a media stream is very rare
> in practice.
>
>
>
> Unfortunately, I'm not able to come up with a solution and I am hoping
> that is where you will be able to step in. I believe to avoid this, there
> needs to be more validation of the media stream that is created, either in
> the form of more data being signed or enforcing that the media participants
> are authenticated.
>
>
>
> Thank you,
>
> *Jack Rickard | Software Engineer | Metaswitch*
> The Faster Way Forward
> Office +44 20 8196 9801
>
> Metaswitch is a Microsoft company
>
>
> _______________________________________________
> stir mailing list
> stir@ietf.org
> https://www.ietf.org/mailman/listinfo/stir
>