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:[EMAIL PROTECTED]
Gesendet: Donnerstag, 12. Juli 2007 11:11
An: Gen-ART Mailing List
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; Tschofenig, Hannes;
[EMAIL PROTECTED]; [EMAIL PROTECTED];
[EMAIL PROTECTED]
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
[EMAIL PROTECTED]
https://www1.ietf.org/mailman/listinfo/ecrit
_______________________________________________
Gen-art mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/gen-art
