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

From: "Tschofenig, Hannes" <[email-masked]>
Date: Tue, 22 Nov 2005 14:30:14 +0100

hi tom, 

thanks for immediately showing interest to fix the problem. before you start your editing work we should get an idea what the right approach is to address steven's feedback. 

ciao
hannes

> -----Ursprüngliche Nachricht-----
> Von: [email-masked] [mailto:[email-masked]] 
> Im Auftrag von Tom-PT Taylor
> Gesendet: Dienstag, 22. November 2005 01:53
> An: Hannes Tschofenig
> Cc: [email-masked]
> Betreff: Re: [Ecrit] Review of 
> <draft-taylor-ecrit-security-threats-00.txt>by Steven Kent
> 
> I'll get to work on it.  Familiar ground to many of us!
> 
> Hannes Tschofenig wrote:
> > 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-securit
> y-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
> > 
> > 
> 
> 
> _______________________________________________
> Ecrit mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/ecrit
> 

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