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

[Michael Thomas <[e-mail]>]

On 7/23/20 8:35 AM, David Hancock wrote:
> 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."
>
If this is to prevent an attack, it needs requirement language like 
MUST. "can" to dev managers means: ignore.

Mike


> David Hancock
> Comcast
>
> On Thu, Jul 23, 2020 at 7:22 AM Jack Rickard 
> <Jack.Rickard=[e-mail] 
> <mailto: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 <[e-mail]>
>     *Sent:* 22 July 2020 23:53
>     *To:* Jack Rickard <[e-mail]
>     <mailto:[e-mail]>>; [e-mail]
>     <mailto:[e-mail]>; [e-mail]
>     <mailto:[e-mail]>
>     *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 <[e-mail]
>     <mailto:[e-mail]>>
>     *Date: *Wednesday, July 22, 2020 at 9:47 AM
>     *To: *"[e-mail] <mailto:[e-mail]>" <[e-mail]
>     <mailto:[e-mail]>>, "[e-mail]
>     <mailto:[e-mail]>"
>     <[e-mail]
>     <mailto:[e-mail]>>, "Peterson,
>     Jon" <[e-mail] <mailto:[e-mail]>>
>     *Subject: *Potential security vulnerability in STIR/DIV
>     *Resent-From: *<[e-mail]
>     <mailto:[e-mail]>>
>     *Resent-To: *<[e-mail]
>     <mailto:[e-mail]>>
>     *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 [phone]
>
>     Metaswitch is a Microsoft company
>
>     _______________________________________________
>     stir mailing list
>     [e-mail] <mailto:[e-mail]>
>     https://www.ietf.org/mailman/listinfo/stir
>
>
> _______________________________________________
> stir mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/stir