Subject: [Ecrit] Review of draft-taylor-ecrit-security-threats-02.txt

From: Hannes Tschofenig <[email-masked]>
Date: Sun, 19 Feb 2006 13:43:14 +0100

Hi Tom,
Hi All,

I went through the recently submitted ECRIT security threats draft (see 
draft-taylor-ecrit-security-threats-02.txt).

My impression is that the document is more focused than the previous 
versions. Good job, Tom!

Here are some minor review comments:
http://www.ietf-ecrit.org/TEMP/draft-taylor-ecrit-security-threats-02_hannes.txt

The challenge in the near future will be to capture security threats and 
  security requirements that show up in the context of the work on the 
mapping protocol.

Request to all: Please review the document and submit you comments.

Ciao
Hannes

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

---

From: "Tom-PT Taylor" <[email-masked]>
Date: Sun, 19 Feb 2006 18:34:37 -0500

Thanks for the comments. In most cases I will reword to clarify. Details 
to follow in another E-mail.

I worded a number of the requirements carefully to say that "The 
protocol must permit ..." or "The protocol must not prevent ...". This 
was to meet the criticism that the proposed measures were too expensive 
in the real world. Your suggested rewording sometimes seems to restore 
mandatory implementation. Perhaps we need a discussion on whether we 
want security measures to be mandatory to deploy (most stringent), 
mandatory to implement, or simply possible to implement and deploy. Or 
has this issue already been settled?

---

From: "Tom-PT Taylor" <[email-masked]>
Date: Sun, 19 Feb 2006 19:52:01 -0500

Here are my detailed responses.

Comment: section 1, first sentence, delete "unique".
Response: OK.

Comment: section 5.1, end of third para, what is meant by "installing 
filters"?
Response: What I meant by this was to say "intercept and discard mapping 
queries relating to the target at a router on the query-response path or 
at the mapping server". Because this is rather longer than the original, 
I'll rework the sentence structure to handle it.

Comment: same section, immediately following sentence talking about 
man-in-the-middle attacks, what is meant by "taking control of the channel"?
Response: I meant "taking control of a router in the query-response 
path", and I'll say that instead.

And BTW, I'm told that taking control of routers is indeed a credible 
threat.

Comment: end of section 5.1, after mention of impersonation of the 
mapping server, a suggestion that we should also talk about attacks on 
the process of mapping server discovery.
Response: OK, though this gets close to the configuration issues I had 
to get rid of because they were out of scope.

Comment: more detailed and precise wording for bullet c. of section 5.3.
Response: Looks good -- I'll take it.

Comment: bullet d., section 5.3, wondering if we should add a remark to 
the effect that one cannot tell from the URI itself whther it points to 
a PSAP.
Response: OK, that's the point -- just wonder if it's too obvious.

Comment: last para of section 5.3 -- described attack by caller is way 
too elaborate -- he just has to hack his device to mark an ordinary call 
as an emergency, rather than substitute for the result of mapping.
Response: agreed, will change accordingly. The attack on the mapping 
database is a separate one and will remain, though it is probably a bit 
far-fetched.

Comment: beginning of section 6, wording changes.
Response: OK.

Comment: section 6, spell out man-in-the-middle threat.
Response: This is the requirements section. I suggest spelling out of 
attacks belongs in section 5.1. I'd like to make the requirements stand 
out clearly by having most of the words in section 6 deal with them 
rather than the attacks to which they respond.

BTW I see "returning no results" as denial of service, whereas 
"returning incorrect results" is the MITM attack. If this seems overly 
picky, I'll reclassify the attacks by what they attack (caller's device, 
router, mapping server + impersonation as a separate category) instead.

Comment: section 6, requirements in response to man-in-the-middle 
threat. Proposed alternative wording.
Response: Your wording introduces the issue I mentioned in my previous 
E-mail: do we require implementation or only make it possible to implement?

Comment: section 6, different words for the impersonation threat, and 
for the response to it.
Response: again, I'd propose that expanded descriptions of attacks 
belong in section 5. And your requirement wording appears to go beyond 
requirements by becoming a discussion of ways and means.

Comment: section 6, confidentiality. Alternative wording.
Response: short rewording OK. Longer wording of threat belongs in section 5.

Comment: section 6, fraudulent calls, remark that reverse lookup is an 
unnecessary requirement.
Response: You're half right -- it is mostly an optimization. But then 
you're assuming that the VSP/ASP proxy is capable of reading the 
location from the INVITE so it can redo the lookup. Is this sufficiently 
problematic that we need the reverse lookup anyway?

---

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 24 Feb 2006 14:47:04 +0100

hi tom,

thanks for your response.
please find some comments inline:

> I'll rework the sentence structure to handle it.

the problem is: how do you setup these filters to only drop queries by
adversaries. this sounds like a difficult problem to me.
furthermore, we are supposed to be indicating requirements rather than
specific solutions.

> path", and I'll say that instead.
ok.

> And BTW, I'm told that taking control of routers is indeed a credible 
sure, i agree with you.

> to get rid of because they were out of scope.

hmmm. in some sense you are right and on the other hand we have already
discussed solutions that effect the "configuration" problem (e.g.,
recall the discussion we had about the emergency identifier / dial
string discussion).

> Response: Looks good -- I'll take it.

ok.

> Response: OK, that's the point -- just wonder if it's too obvious.
maybe it is too obvious; i don't know.

> database is a separate one and will remain, though it is probably a bit 

ok.

> Comment: beginning of section 6, wording changes.

ok.

> rather than the attacks to which they respond.

ok.

> router, mapping server + impersonation as a separate category) instead.

it is indeed difficult to assign the attacks to specific groups since
there is some overlap.

> E-mail: do we require implementation or only make it possible to implement?

you mean: implementation vs. usage

my impression is that we have to be explicit as whether we talk about
usage or implementation when we use RFC 2119 language. we ask roger to
walk through the requirements draft todo the same. hence, i think we
should also apply it to this draft.

you are right that a MUST use in this particular case is really
difficult to accomplish in all cases.

what about MUST implement and SHOULD use?

> requirements by becoming a discussion of ways and means.

yes, maybe i went too far with my description of the requirement.
(btw, i noticed that i used the word countermeasures and that's a
copy-and-paste mistake. it should be read as 'requirement' instead.)

> Response: short rewording OK. Longer wording of threat belongs in 

ok.

> problematic that we need the reverse lookup anyway?
we are entering solution specific teritory here. maybe we should talk
about this at all in the draft.

here is my impression about this stuff in relationship to the ongoing
solution specific work:
we do not have the infrastructure to perform reverse lookups. we only
worried about "Location -> URI" mapping. We have never looked at the URI
-> Location mapping.

we should keep an eye on this issue.

ciao
hannes

> 
> Hannes Tschofenig wrote:
> 
>> Hi Tom,
>> Hi All,
>>
>> I went through the recently submitted ECRIT security threats draft 
>> (see draft-taylor-ecrit-security-threats-02.txt).
>>
>> The challenge in the near future will be to capture security threats 
>> and  security requirements that show up in the context of the work on 
>> the mapping protocol.
>>

---

From: "Tom-PT Taylor" <[email-masked]>
Date: Fri, 24 Feb 2006 09:11:38 -0500

I'm pleased to get your response. I never got my copy of my E-mail to 
the list,so I was afraid it had disappeared into a black hole.

Just a couple of items to discuss, see below. Other stuff snipped away.

>> Here are my detailed responses.
...
>> Response: What I meant by this was to say "intercept and discard 
>> mapping queries relating to the target at a router on the 
>> query-response path or at the mapping server". Because this is rather 
>> longer than the original, I'll rework the sentence structure to handle 
>> it.
> 
> 
[PTT] No, I meant that the attacker installs the filters. Presumably the 
attacker has the information to construct them.
...
> what about MUST implement and SHOULD use?
[PTT] We've heard objections that MUST implement is unrealistic for a 
couple of reasons -- client resources and effect on call setup times. 
Anyway, a "MUST implement" provision would be part of the protocol 
specification rather than the requirements. What we would distinguish at 
the requirements level is "the protocol must provide" vs. "the protocol 
must not prevent". I am suggesting we use the latter.
...
>> location from the INVITE so it can redo the lookup. Is this 
>> sufficiently problematic that we need the reverse lookup anyway?
> 
[PTT] The requirement doesn't go that far. What is needed is to be able 
to look up a URI and get back an assurance that the URI points to a PSAP 
-- a "yes" or "no". I'll make sure the wording is clear on this point.
> hannes
...