Subject: [stir] Comments on draft-peterson-stir-threats-00

From: "Rosen, Brian" <[email-masked]>
Date: Tue, 1 Oct 2013 17:01:12 +0000

I think this document is a very good start as a threat analysis and should be adopted by the work group.

In the Introduction, I think the most stark example of these attacks is swatting, where the caller impersonates a victim and causes a massive law enforcement action without any real basis.

There is a paragraph that talks about post set-up changes.  It's correct that we don't consider them, but the way SIP works, any INVITE (say from a bridge) could be protected.

Do you want to at least reference cnit?  Maybe just as "further work will be needed".

In Attackers, I'm not sure I understand an attacker that observes but does not replay.  We are not encrypting anything, so observation will always be possible.  The voicemail hack would require a replay to be successful (if it were possible) unless they had the keys.

When you talk about not including intermediaries as attackers, perhaps it would be good to explain in the intro that we don't consider service providers to be directly participating, but we do see some of them turning a blind eye to bad things their customers are doing.  We're not assuming the service providers are the attackers, but we are assuming some of them are indirectly complicit.

In Voicemail Attacks, I got lost in the paragraph beginning "If the voicemail service could know ahead of time that it should always expect authenticated identity.."  I'm not sure what it's trying to say and wonder if it could be deleted without losing anything important.

In Commercial impersonation Attacks, I am bothered by the sentence "If there were a directory that could inform the terminating side of that fact, however, that would help in the robocalling case."  I have no idea what directory that is referring to, and ISTM that you can rarely assure you can ALWAYS get authenticated identity from a given TN.  I guess you mean the out of band directory, but that would depend on the called party having credentials, so there is at least some qualification needed.

I'd like the swatting case documented.  I can send text if desired.

In IP-PSTN attack scenario, if we did adopt some of the ideas in Hadriel's proposal, we might get the in band solution to work with IP-PSTN GWs.  I also want to get the notion that if there is an intermediary on the IP side, including the IP-PSTN GW, it could validate.

Isn't it a stretch to say that the out of band mechanism could work for a PSTN-PSTN connection?  It assumes an Internet-aware origination (device or service) with both IP and PSTN connectivity. That would not cover any existing device or service, so you are talking about an upgraded service that did not also upgrade to SIP origination.  Possible, sure, but worth documenting?   Dunno.

IP-PSTN-IP - same comments as IP-PSTN

Brian

---

From: Michael Hammer <[email-masked]>
Date: Tue, 1 Oct 2013 17:32:30 +0000

sentence "If there were a directory that could inform...

This sounds like it is getting into solutions.  Better to not go there in a
definition of the threats.

Mike

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Rosen, Brian
Sent: Tuesday, October 01, 2013 1:01 PM
To: [email-masked] List
Subject: [stir] Comments on draft-peterson-stir-threats-00

I think this document is a very good start as a threat analysis and should
be adopted by the work group.

In the Introduction, I think the most stark example of these attacks is
swatting, where the caller impersonates a victim and causes a massive law
enforcement action without any real basis.

There is a paragraph that talks about post set-up changes.  It's correct
that we don't consider them, but the way SIP works, any INVITE (say from a
bridge) could be protected.

Do you want to at least reference cnit?  Maybe just as "further work will be
needed".

In Attackers, I'm not sure I understand an attacker that observes but does
not replay.  We are not encrypting anything, so observation will always be
possible.  The voicemail hack would require a replay to be successful (if it
were possible) unless they had the keys.

When you talk about not including intermediaries as attackers, perhaps it
would be good to explain in the intro that we don't consider service
providers to be directly participating, but we do see some of them turning a
blind eye to bad things their customers are doing.  We're not assuming the
service providers are the attackers, but we are assuming some of them are
indirectly complicit.

In Voicemail Attacks, I got lost in the paragraph beginning "If the
voicemail service could know ahead of time that it should always expect
authenticated identity.."  I'm not sure what it's trying to say and wonder
if it could be deleted without losing anything important.

In Commercial impersonation Attacks, I am bothered by the sentence "If there
were a directory that could inform the terminating side of that fact,
however, that would help in the robocalling case."  I have no idea what
directory that is referring to, and ISTM that you can rarely assure you can
ALWAYS get authenticated identity from a given TN.  I guess you mean the out
of band directory, but that would depend on the called party having
credentials, so there is at least some qualification needed.

In IP-PSTN attack scenario, if we did adopt some of the ideas in Hadriel's
proposal, we might get the in band solution to work with IP-PSTN GWs.  I
also want to get the notion that if there is an intermediary on the IP side,
including the IP-PSTN GW, it could validate.

Isn't it a stretch to say that the out of band mechanism could work for a
PSTN-PSTN connection?  It assumes an Internet-aware origination (device or
service) with both IP and PSTN connectivity. That would not cover any
existing device or service, so you are talking about an upgraded service
that did not also upgrade to SIP origination.  Possible, sure, but worth
documenting?   Dunno.

Brian
_______________________________________________
stir mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/stir

---

From: "Peterson, Jon" <[email-masked]>
Date: Tue, 8 Oct 2013 18:22:03 +0000

Thanks for these detailed notes, Brian. A few comments inline.

>enforcement action without any real basis.

True, and we can mention it - though my understanding is that swatting
attacks can be performed without impersonating any caller ID, since
effectively you can just contact emergency services and claim there's a
disturbance at a location and the response will be sent there. Having a
caller ID for that location isn't integral to the attack. Certainly having
the right caller ID provides a good corroborating detail.

>that we don't consider them, but the way SIP works, any INVITE (say from
>a bridge) could be protected.

Protected from what attack? That's the question for a threats document.

>Do you want to at least reference cnit?  Maybe just as "further work will

Is the second-to-last paragraph of the Introduction not sufficient? The
problem-statement document already has a statement that this effort isn't
considering display name validation as well.

>In Attackers, I'm not sure I understand an attacker that observes but
>does not replay.  We are not encrypting anything, so observation will
>always be possible.  The voicemail hack would require a replay to be
>successful (if it were possible) unless they had the keys.

The attacker postulated in that TBD isn't entirely passive: the question
there is if we should consider attackers who can replay signaling that
wasn't sent directly to them. So, say, an attacker at the IETF who can
listen to the public WiFi there, captures signaling going from you to your
voicemail service, and then wants to impersonate you to your voicemail
service. 

So the point of that TBD is to ask, are we considering only attackers who
replay signaling that they received, or also attackers who might replay
signaling that they captured be eavesdropping?

>providers to be directly participating, but we do see some of them
>turning a blind eye to bad things their customers are doing.  We're not
>assuming the service providers are the attackers, but we are assuming
>some of them are indirectly complicit.

I suspect that subtlety is probably better suited for the
problem-statement than for this document. Unless we're saying that we want
to implement protocol mechanisms to defend against careless service
providers, I'm not sure what we'd say about this in a threat document that
would change the recommendations.

>authenticated identity.."  I'm not sure what it's trying to say and
>wonder if it could be deleted without losing anything important.

The rest of the paragraph does give a concrete example of this
countermeasure: if I call a voicemail service regularly, and my call is
signed with an identity signature, the voicemail service should be wary if
it receives a call purporting to be from my number without a signature.
But we want to say something more general than that, to take into account
DANE-like mechanisms for advertising "you should expect identity in a call
from this number." So, I went with "if you could know ahead of time"
language there.

In general, we want to discuss this sort of mechanism in a high-level
overview of countermeasures because identity is necessarily opt-in and
will be adopted only incrementally, so anything we can do to improve the
prospect that incremental identity will be practically useful is very
helpful. 

>In Commercial impersonation Attacks, I am bothered by the sentence "If
>there were a directory that could inform the terminating side of that
>fact, however, that would help in the robocalling case."  I have no idea
>what directory that is referring to, and ISTM that you can rarely assure
>you can ALWAYS get authenticated identity from a given TN.  I guess you
>mean the out of band directory, but that would depend on the called party
>having credentials, so there is at least some qualification needed.

Same as the last note. "Directory" here is again referring to DANE-like
mechanisms. I agree you can rarely assure that you can always get identity
in a call, but your policies can know to treat calls without identity with
greater suspicion when you have an expectation it will be used.

>I'd like the swatting case documented.  I can send text if desired.

Please do, but please do focus on the degree to which the calling party
number actually changes what emergency responders do.

>In IP-PSTN attack scenario, if we did adopt some of the ideas in
>Hadriel's proposal, we might get the in band solution to work with
>IP-PSTN GWs.  I also want to get the notion that if there is an
>intermediary on the IP side, including the IP-PSTN GW, it could validate.

Certainly I thought about this question when writing these threats, though
just for the IP-PSTN-IP case, not for the IP-PSTN case. For IP-PSTN the
terminating gateway could validate, and say, not send the call to the PSTN
if there's no identity signature - we've talked about things like that
before. I'd be willing to add that as a scenario where in-band helps with
the IP-PSTN case, though it's not an end-to-end indication in that case.

Regarding gateway the identity signature, I suspect this question is
largely one of terminology, about what is "in-band" versus "out-of-band."
If "in-band" is understood strictly to mean "in SIP," then I don't think
gatewaying would be in the scope of "in-band." We could even define some
kind of "hybrid" designation for gatewaying.

The reason why I didn't, thus far anyway, is because I'm interested in how
much overlap there is in the information that we imagine would be
gatewayed (stored in a field in XMPP somewhere, say) and the information
that would be shared via out-of-band for identity. If the overlap turns
out to be very large, then maybe these cases are closer than they might
look right now. But that depends very much on the details of the solution
space, and is certainly beyond the scope of a threats document.

>PSTN-PSTN connection?  It assumes an Internet-aware origination (device
>or service) with both IP and PSTN connectivity. That would not cover any

This is a cornerstone case for out-of-band: a case where two mobile
phones, say, can exchange out-of-band identity even though their call goes
over the PSTN. It does indeed assume an Internet-aware device with both
PSTN and IP connectivity. I'd say every iPhone meets that description, so
I'm not sure what distinction you're drawing here that I'm missing.

>IP-PSTN-IP - same comments as IP-PSTN

See above.

Thanks again,

Jon Peterson
Neustar, Inc.