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

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 16 Aug 2007 22:42:45 +0200

Gen-ART Review ....

-----Ursprüngliche Nachricht-----
Von: Christian Vogt [mailto:[email-masked]]
Gesendet: Donnerstag, 12. Juli 2007 11:11
An: Gen-ART Mailing List
Cc: [email-masked]; [email-masked]; Tschofenig, Hannes; 
[email-masked]; [email-masked]; 
[email-masked]
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 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.

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.

Best regards,
- Christian

_______________________________________________
Ecrit mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ecrit

---

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 20 Aug 2007 17:49:46 +0200

Hallo Christian,

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

Hannes Tschofenig wrote:
> 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.priv.at/svn/draft-ietf-ecrit-security-threats/draft-ietf-ecrit-security-threats-05.txt

> I think that some clarification would be
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.

> verifying whether there actually exists an emergency case at that 
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.priv.at/wp/?p=131. We hope to make some 
progress on that topic as well since it appeared to be a difficult one.

Ciao
Hannes

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 20 Aug 2007 12:02:39 -0400

Just to add to this: I think we should state explicitly that we're  
not trying to solve all security problems related to emergency  
services. False dispatch is unlikely to be something that we can  
reasonably address; the best we can do is say that next-generation  
systems may make checking on incident reports easier. For example, a  
call taker might be able to easily see the picture on a surveillance  
camera for the area, to see if there smoke where there's supposed to  
be a large fire. In the UK, this presumably will capture just about  
any corner of the cities. (Whether that's desirable from a privacy  
perspective is probably best left to other discussion forums.) From  
what I can tell, good call takers also develop a hunch that the  
giggling teenager may deserve an additional question or two before  
sending a fire truck. Having additional site information may also  
allow the call taker to ask questions. If you have the new Google  
street-level views, you can ask "what store is this accident next  
to?" or you can see that the supposed house fire is in an open field.  
In many cases, sending a squad car to check things out is a much  
better choice than not responding, since the consequences of that may  
be dire.

All of this is well beyond what a protocol working group can do. We  
shouldn't promise to solve all the emergency services world's  
security problems.

On Aug 20, 2007, at 11:49 AM, Hannes Tschofenig wrote:

>
> 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.priv.at/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
>>
>>
>>
>>

---

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 27 Aug 2007 14:33:56 +0200

Hi Christian,

I hope that the new draft version addresses your comments.
http://www.ietf.org/internet-drafts/draft-ietf-ecrit-security-threats-05.txt

Ciao
Hannes

Christian Vogt wrote:
> Henning and Hannes, one brief comment:
>
>   
> Right, and this is in line with what I was saying:  Verification of the
> truthfulness of (the extent of) a reported incident cannot be solved by the
> ECRIT protocol.  I was suggesting to clarify this in the requirements section.
>
> Best,
> - Christian
>
>