Subject: [Ecrit] Review of <draft-taylor-ecrit-security-threats-00.txt> by Steven Kent

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 22 Nov 2005 01:21:39 +0100

Hi all,

Steven Kent reviewed <draft-taylor-ecrit-security-threats-00.txt>. As 
part of his review he provided comments throughout the entire document 
(fixing language issues etc.). Finally, he concluded with the following 
statements:

------

Frankly, the document should be re-written from scratch, preferably
from a different perspective. I'd suggest the following format:

1. start with a brief description of all the steps and entities
involved in an emergency call. (maybe do this for the PSTN, the
extend to VoIP.)

2. discuss what the emergency call system relies on to function
correctly, e.g., in the absence of attacks, i.e., a correct/secure
operation model.

3. describe the threats model, i.e., classes of adversaries and their
motivations and capabilities.

4. now articulate security requirements, motivated by the threat
model and the correct/secure operation model.

5. maybe prioritize these requirements.

Do not discuss countermeasures in this document. put them in a
separate document. there are many places where the discussion of
countermeasures was vague or incomplete, and others where the
countermeasure description was technically wrong.

------

His review is quite tough but important. We should discuss it.

Here are my first response concerning his review:

ad 1) To some extend we provide a brief description of the involved 
entities in the requirements document (although only very brief). It 
might be useful to extend the description a bit (but i do not want to go 
into a description about the PSTN world).

ad 2) It might be possible to make some statements about the ideal world 
but i see difficulties doing this since emergency call handling is not 
an easy system to secure (from a deployment perspective). For example, 
we might want to state that the identity of the emergency caller should 
be authentic and the provided location is the "true" location. I am, 
however, not quite sure how far we could get with these types of 
statements.

ad 3) Regarding the threat model i thinmk it is possible to indicate 
what the impact of an adversary with regard to its location and its 
capabilities are. Since there are a number of protocols that are 
executed in sequence the task might be quite lengthy with a lot of 
repetition.

ad 4) This again might be quite difficult since the ideal requirements 
are most likely not accomplishable in a real-world environment. For 
example, authentication of the emergency caller towards the PSAP would 
be nice from a security point of view, easy to mandate in a 
specification but quite difficult to accomplish in  the real world. In 
some sense we have this functionality already in the SIP specification 
with the usage of end-to-end security mechanisms, such as S/MIME or 
MIKEY/SRTP (for media traffic) in case of SIP.

ad 5) It might be difficult to achieve a ranking since every one of us 
might have a different perception of the threat impacts.

Steven's concluding remark about not including any countermeasures 
sounds reasonable. In some sense we are then back where we came from, 
namely at:
http://www.ietf-ecrit.org/cache/draft-tschofenig-ecrit-security-threats-01.txt

Ciao
Hannes

ps: Steven's editorial review can be found at:
http://www.ietf-ecrit.org/TEMP/ecrit-security-threats-00.pdf

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

---

From: "Tom-PT Taylor" <[email-masked]>
Date: Mon, 21 Nov 2005 19:53:14 -0500

I'll get to work on it.  Familiar ground to many of us!

---

From: Andrew Newton <[email-masked]>
Date: Tue, 22 Nov 2005 09:01:13 -0500

> countermeasure description was technically wrong.

I have to say that this does sound different than what he was  
describing at the microphone.

> entities in the requirements document (although only very brief).  
> It might be useful to extend the description a bit (but i do not  
> want to go into a description about the PSTN world).

I'm not in favor of describing the PSTN as well, but if we know of a  
security issue that would affect the PSTN (such as the one discussed  
on this list), then we should include them.

> ad 2) It might be possible to make some statements about the ideal  
> world but i see difficulties doing this since emergency call  
> handling is not an easy system to secure (from a deployment  
> perspective). For example, we might want to state that the identity  
> of the emergency caller should be authentic and the provided  
> location is the "true" location. I am, however, not quite sure how  
> far we could get with these types of statements.

Even if there is no solution to a particular security threat, we  
ought to document it.

> ad 5) It might be difficult to achieve a ranking since every one of  
> us might have a different perception of the threat impacts.

Yeah, that's gonna be one long food fight.

-andy