[Gen-art] Re: [Ecrit] WG: Review of draft-ietf-ecrit-security-threats-04.txt

[Hannes Tschofenig <[e-mail]>]

Hallo Christian,

thanks for your review. Please find a few comments below:

Hannes Tschofenig wrote:
> Gen-ART Review ....
>
> -----Ursprüngliche Nachricht-----
> Von: Christian Vogt [mailto:[e-mail]]
> Gesendet: Donnerstag, 12. Juli 2007 11:11
> An: Gen-ART Mailing List
> Cc: [e-mail]; [e-mail]; Tschofenig, Hannes; 
> [e-mail]; [e-mail]; 
> [e-mail]
> Betreff: Review of draft-ietf-ecrit-security-threats-04.txt
>
> I have been selected as the General Area Review Team (Gen-ART)
> reviewer for this draft (for background on Gen-ART, please see
> http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).
>
> Please resolve these comments along with any other Last Call comments
> you may receive.
>
> Document: draft-ietf-ecrit-security-threats-04.txt
> Reviewer: Christian Vogt
> Review Date:  July 12, 2007
> IETF LC End Date: --
> IESG Telechat date: (if known)
>
> Summary:
>
> This document identifies and describes threats that affect emergency
> call mechanisms.  As the Requirements document, this document is already
> in good shape.  However, as explained below, there is one attack
> objective that I think is very important, and that should be attended to
> a bit closer.
>
> Comments:
>
> The following attack objective described in the document is important
> enough to be attended to a bit closer IMO:
>
> >   o  to divert emergency responders to non-emergency sites. This memo
> >      has not identified any attacks within its intended scope that
> >      achieve this objective, so it will not be mentioned further.
>
> Diverting emergency responders to non-emergency sites is actually not an
> objective that an attacker might have, but rather a technique of
> reaching the objective described in the first bullet ("to deny system
> services to all users in a given area").  So the draft actually does
> address this objective.
>
> Still, I think the /possibility/ for an attacker to divert emergency
> responders to non-emergency sites -- as a means of reaching the DoS
> objective -- is important enough to get a bit further elaborated on, in
> particular with respect to its relationship to the mechanism to be
> developed by the Ecrit WG.

I agree with you that diverting emergency callers to non-emergency sites 
is within the scope of ECRIT and is actually a form of DoS attack.

The paragraph in the draft will be changed. A first proposal can be 
found here:
http://www.tschofenig.com/svn/draft-ietf-ecrit-security-threats/draft-ietf-ecrit-security-threats-05.txt


> I think that some clarification would be
> useful along these lines:
>
> Preventing diversion of emergency calls would likely require some
> evidence about the existence of a reported emergency case, such as a
> photograph, a video clip, or N previous calls reporting the same
> emergency case.  The decision of which proof would be acceptable, and
> whether requiring such proof is something desirable in the first place,
> is likely something that cannot be decided in the Ecrit WG.  Preventing
> diversion of emergency calls is hence something that is likely not to be
> in scope of the Ecrit WG.
With today's system none of these "checks" are performed (at least not 
for small incidents).
For large scale disasters I am sure that the PSAP operator runs some 
verification procedures before sending a huge number of first responders 
to the scene.

While these aspects are interesting from a security point of view 
regarding the question "How can you show that there is really an 
emergency?" to deal with hoax <ende?lp=ende&p=eL4jU.&search=hoax> calls 
I am also not sure how these aspects relate to the DoS attack you 
mention. I understood this DoS attack more in the following sense: For 
example, an adversary manages to modify the LoST mapping database and 
re-writes PSAP URIs to URIs that point to a conference bridge. Then, 
when an emergency call happens a person finds itself talking to the 
conference bridge rather than to the PSAP operator.

>
> Maybe this should be clarified either in this document, or in the
> Requirements document -- in particular because the Requirements document
> currently only talks about verifying the caller's location, rather than
> verifying whether there actually exists an emergency case at that 
> location.
The future emergency services infrastructure might be able to handle 
more media types and accept additional data. However, it is quite likely 
that the PSAP operator will not be able to use these things for a long 
time since the capabilities are just not supported by end systems and in 
some cases it might actually be difficult to expect the emergency caller 
to take pictures (given the level of stress they are likely to 
experience during an emergency situation).

Finally, an adversary can easily exploit such a system by not attaching 
videos or pictures since the emergency call will not rejected anyway.

I think the best we can hope for at the moment is that the capabilities 
built into SIP are used to a maximum extent and that the PSAP operator 
accepts supplementary data about the emergency scene.

We are, to some extend, trying to capture some of these attacks. Our 
focus was more on the attack against the PSAP itself when faked location 
information was used. We have published a few documents on this subject 
already, see http://www.tschofenig.com/wp/?p=131. We hope to make some 
progress on that topic as well since it appeared to be a difficult one.

Ciao
Hannes

>
> Best regards,
> - Christian
>
>
>
>
> _______________________________________________
> Ecrit mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/ecrit



_______________________________________________
Gen-art mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/gen-art