Dean Willis wrote:
On Nov 20, 2008, at 5:52 PM, Jiri Kuthan wrote:
I'm just wondering, if folks could help to explain me this:
apparently when I asked if people in the WG feel safe about
IETF's mechanisms deployable to prevent spoofed From, nobody
spoke up. At the same time, there were some who felt that
we don't have a problem statement. I would be thankful if
representatives of the latter group could share with me
what is the missing piece here to state a problem.
So let's define a "spoofed From."
Are we talking about a real UA generating an INVITE request with a bogus
identity asserted in it's From: field, or are we talking about a DOS
attack (like a voice-hammer generator) where a device that is not a UA
is generating an INVITE request that causes the UAS to deliver the
attack to the victim?
For the first threat, in our current spec family, we have strong
identity (aka RFC 4474) as a general solution, and weak identity (RFC
3325) as a point solution for single-domains or federations with
identity enforcement points in trusted proxies.
I think it belongs in this class, but I don't think we have a practicable
solution -- one is too strong, the other one too weak. (whoever doesn't
wish to indulge in a lengthy debate is invited to share his SIP address
with me -- I'll be happy to demonstrate that)
RFC4474 is simply not there. Despite we=iptel/TKLC have implemented in SER,
we found ourselves to be rather alone with it. I think the root reason
is it is heavier than it seems. Body integrity protection and dependence
on CAs
makes it just too impracticable. I would say as a hand waving
guesstimate 90% of
all SDPs on this planet gets rewritten for sake of NAT traversal and
there is 0%
SIP deployments leaning on a CA.
RFC3325, to the same extent as RFC3261 (From header field), buy really too
little. It is to some extent workable within single-domain, but not even
that
really reliably. (UAs would have to trust an IP address, but we run into the
questions like "which", or UAs would have to use TLS which appears largely
unused as well).
For the second threat, we have null-authentication; the UAS can
challenge the request (which tests direct return routability to the UAC)
and wait for a response before proceeding to the alerting phase. By
direct return routability, I mean that we can follow the via-stack back
to the originating UAS (possibly with help for a via-pruning SBC).
So where does DERIVE fit in?
I believe it attempts to address both problems. It's clearly heavier
than the existing solution for the second threat, but if we use DERIVE,
we get this problem fixed for free. So the question of the work really
seems to be its applicability to the first threat.
Yes.
Let us move to an examination of the assumptions. DERIVE assumes that
the identity expressed in the request being examined is a routable
identity, and that there is a indirect return routability for that
identity. By indirect return routability, I mean that a new request
targeted to that identity will reach the user agent that originated the
request. Further, DERIVE assumes that the UA reached by the indirect
return routability path has knowledge of the request being examined and
that it can attest to that knowledge, thereby establishing the veracity
of the identity expressed in the request to the level of "this identity
resolves in the routing topology to the node that sent the request".
Yes.
Therein lies the differentiator: Whereas RFC 4474 proves the identity
cryptographically (that is, through secrets known to the identity-holder
or to a trusted third party working on behalf of the identity-holder),
DERIVE proves it functionally (by the definition of "functionally"
meaning "it works", sorry you Haskell fans!).
Two questions remain:
1) Is a functional verification through indirect return routability
testing of the identity expressed in a request actually useful?
2) Is the mechanism used by DERIVE reasonable for implementing an
indirect return routability check?
Let's attack these one at a time.
Question 1: Usefulness of indirect request return-routability checks in SIP
Many attacks seen in the Internet rely on forged transmission
identifiers. For example, consider the once wildly popular Smurf attack:
http://en.wikipedia.org/wiki/Smurf_attack
The Smurf attack uses a ICMP echo request with a forged IPsource
address, where the victim's address is used as its source address (i.e,
it's "From:"). This initial request is addressed to the broadcast
address of a remote subnet. If the attack succeeds, each host on the
remote subnet replies, thereby flooding the victim with unexpected ICMP
echo request responses.
Although we have not identified a Smurf-like direct amplification attack
in SIP, it's still obviously possible to use a forged From: to cause the
victim's phone to ring, thereby making the target UA an attack amplifier
against the person (or sanity) of the end user. One might call this the
"ring ring ditch" or "ring ring ginger" attack, from the similar
childish doorbell prank"
http://en.wikipedia.org/wiki/Knock_down_ginger
DERIVE clearly reduces the opportunity to use a forged From: to bypass
controls on the victim's phone. Not perfect, but it passes the
script-kiddie test.
Consider however the SIP Voice Hammer attack:
http://tools.ietf.org/id/draft-ietf-mmusic-ice-19.txt, section 18.15.1
This works similarly to Smurf, but it uses a second level of
indirection. Rather than spoofing the victim's From: address, Voice
Hammer insert's the victim;s address into the SDP of a SIP INVITE. When
the target of the request "answers" the call, the target becomes an
amplifier, spewing RTP packets at the victim.
Indirect return routability testing gives us no direct defense here, in
that provides some validation of the from: address but we have no way of
correlating this address with the one used in the SDP. However, it does
make it harder to originate the attack anonymously, as it requires that
the attacker establish indirect return routability at the SIP level,
which presumably gives us a little better chance of hunting the
perpetrator down and apply other mechanisms (such as summary execution)
in order to prevent further offenses.
In other words, it's good enough to stop script kiddies.
I think that's about it indeed.
I think what we are seeking is something between zero-security and
heavy-weight
security. None of these two is really practicable. Like in the web -- we
have
no plain-text HTTP for online shoping, but the shopper don't really
prove their
identity protocol-wise either (other than sharing credit card number
over TLS).
Identity is a hard thing to solve, and it is really not easy to get to one's
DNA. (probably it is good so) Therefore what you called "functional proof"
appears more attractive to me.
In a third attack scenario, presume the attacker's goal is to
impersonate a caller, such as the infamous "Radio-Show Sarkozy/Palin"
calls.
http://www.huffingtonpost.com/2008/11/01/masked-avengers-prank-cal_n_140023.html
Here the goal is not necessarily to prevent the call, but to give the
called party some level of comfort as to the authenticity of the
caller's expression of identity.
Right -- the consolation comes in that she can trace the caller if she
accepted a DERIVE-tested call and found it uncomfortable.
Indirect return routability checks clearly establish that the calling
party is sufficiently in-control of the expressed identity as to be able
to receive calls directed toward that identity. This is better than
nothing; it can't prove identity, but it greatly decreases the
probability of a random radio DJ being able to make a prank call.
Yes. Thank you indeed for catching this nuances. I think that addresses
some of the concerns on the mailing list, which were result on somehow
inadequately high expectations on DERIVE. This is what it can and can't
do.
Question 2: Does DERIVE provide a reasonable solution?
In order to impact the DoS attacks described in 1, the solution has to
be "strong enough" that we can reasonably reject a call, at the automata
level, without bothering the user. No arguments have been made that the
mechanism in DERIVE is sufficiently widely deployed that one can reject
calls not using it. One might argue that one could add an extension
detection mechanism (such as including a modifier in the identity) that
says "You can expect calls from me to support DERIVE; if they don't, it
isn't me" that might help. But it's still a pretty weak defense against
DoS. In the general case, DERIVE does NOT stop script kiddies from known
DoS attacks, so it may not be useful here.
So it is. I think success of DERIVE-like tests depends largely on gaining
the critical mass. For that, the key prerequisite is it must be very simple.
Consider however the "Radio-Show Sarkozy/Palin" calls; here the
requirement is not to block the call entirely, but to give additional
guidance to the user as to how to evaluate the caller's claimed
identity. Here DERIVE might be useful. It's more use if we have a reason
to believe that calls from a given party should support DERIVE. In the
end, it comes down to breadth of availability. Will DERIVE be widespread
enough that anybody bothers with it? My hunch is that this is unlikely,
but this might be a useful point of discussion.
honestly, I don't know how its adoption will develop. I would historically
compare it to SPF, which required minimum changes and achieved its function
and current level of deployment by simplicity. a 2007 study shows 5%
penetration for it.
http://www.onlamp.com/pub/a/onlamp/2007/01/11/dns-extensions.html
Introduction of SPF for our own domain has quite increased the rejection
rate.
One of the ideas would be actually to give up the reverse check on SIP level
in exchange for DNS. That would similarly show that the caller (at domain
level) is in control of its name. Less granular, still better-than-nothing.
-jiri
--
Dean
_______________________________________________
Sip mailing list https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [EMAIL PROTECTED] for questions on current sip
Use [EMAIL PROTECTED] for new developments on the application of sip
