Subject: [Ecrit] Review of Security Threats Draft

From: Ron Watro <[email-masked]>
Date: Mon, 22 May 2006 09:41:45 -0400

Here are some brief comments on draft-ietf-ecrit-security-threats-01, dated 
April 17 2006

Good job by Tom to persevere through the various versions of this document.

General comment:  The current draft focuses on the security requirements 
for just the parts of the VoIP emergency response system that are ECRIT 
work items.  Some of the previous incarnations of this document also 
included an overview of the full system security concept, so that one could 
see that the security being proposed for the ECRIT work items was 
consistent with at least one full-scale plan.  At the interim meeting, it 
was decided to drop any discussion of system security as a whole.  This 
decision was influenced by several issues, including the desire for ECRIT 
to make speedy progress and the lack of any consensus on the full system 
approach.  There were some dissenting opinions at the interim meeting, 
arguing that a properly caveated, strawman view of the full system and its 
security concept was needed to provide a basis for the security services 
allocated to ECRIT work items.  In any event, we currently have the version 
without the system view, and going forward we can expect comments asking 
why the component security requirements were not derived from a set of 
system security requirements (as is commonly done).

Specific comments are below:

Abstract

--doubled "the" in the last sentence

1 Introduction

--suggest changing the two "must be" wordings in the 1st paragraph to "is 
being" .  The marking idea and the mapping server are not the only feasible 
solutions to the problems at hand.
--mixture of commas and periods as list separators in the last paragraph

4 Objectives of attackers

--for the third bullet, it seems conceivable that a structured emergency 
service marker could help support the process of preventing fraudulent 
emergency calls (by assisting in track-back of the call, for example).  In 
this case, there could be interaction with ECRIT work items
--inconsistent punctuation at the end of bulleted items

5 Potential Attacks

5.1 Identifier attacks

--Is the emergency identifier known to be just a single bit, or could it 
contain data that can be use for other proposes (time stamp, cryptographic 
signature?)
--You say that theft-of-service calls most probably will not include any 
location information - but wouldn't they mostly likely include falsified 
location information so that they look legit but cannot be tracked back to 
the source?

6  Security requirements

from section 5.1 fraudulent calls
--How will a URI be verified as a PSAP?  Will the mapping server be used or 
is this a non-ECRIT security requirement?
--Are long distance calls to remote PSAPs always fraudulent?  For example, 
a disreputable foreign entity might set up a phony PSAP for its people to 
call.  Can a service provider refuse to carry or perhaps reroute a long 
distance emergency request?

from section 5.2.1 impersonation of the mapping server
--mapping server discovery is apparently outside the scope of ECRIT topic, 
so does ECRIT simply assume that this will be done in a secure manner?
--will the protocol allow exchange with unauthenticated servers if no 
authenticated ones can be found?
--does it ever make sense to return mapping server audit data to the 
client?  Is this data encrypted to make it inaccessible by the client?  Is 
this design intended to address rogue servers?  If not, then why not just 
store the data on the server?

from section 5.2.3 snooping attack
-- the protocol or system must provide confidentiality mechanisms but the 
mapping server should respond to non-complaint clients with unprotected 
data if that is the only option

Final comment:  Any concern about "insider attack" -- rogue PSAPs, SIP 
proxies, etc?

Ron Watro

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

---

From: Hannes Tschofenig <[email-masked]>
Date: Sun, 28 May 2006 15:08:42 +0200

Hi Ron,

thanks a lot for your draft review.

Ron Watro wrote:
> Here are some brief comments on draft-ietf-ecrit-security-threats-01,
>  dated April 17 2006
> 
> General comment:  The current draft focuses on the security
> requirements for just the parts of the VoIP emergency response system
> that are ECRIT work items.  Some of the previous incarnations of this
> document also included an overview of the full system security
> concept, so that one could see that the security being proposed for
> the ECRIT work items was consistent with at least one full-scale
> plan.  At the interim meeting, it was decided to drop any discussion
> of system security as a whole. This decision was influenced by
> several issues, including the desire for ECRIT to make speedy
> progress and the lack of any consensus on the full system approach.
> There were some dissenting opinions at the interim meeting, arguing
> that a properly caveated, strawman view of the full system and its
> security concept was needed to provide a basis for the security
> services allocated to ECRIT work items.  In any event, we currently
> have the version without the system view, and going forward we can
> expect comments asking why the component security requirements were 
> not derived from a set of system security requirements (as is
> commonly done).

Good summary.

The document had an interesting history.

> --suggest changing the two "must be" wordings in the 1st paragraph to
>  "is being" .  The marking idea and the mapping server are not the
> only feasible solutions to the problems at hand. --mixture of commas
> and periods as list separators in the last paragraph
> 
Fine with me.

> --for the third bullet, it seems conceivable that a structured
> emergency service marker could help support the process of preventing
> fraudulent emergency calls (by assisting in track-back of the call,
> for example). In this case, there could be interaction with ECRIT
> work items --inconsistent punctuation at the end of bulleted items

I guess you refer to this bullet:

    o  to divert emergency responders to non-emergency sites.  No attacks
       affecting the ECRIT Working Group's decisions on the emergency
       identifier and mapping protocol have been identified that achieve
       this objective

We don't need to worry too much about the solution space in this 
document. Luckily.

> 
> 5 Potential Attacks
> 
> 5.1 Identifier attacks
> 
> --Is the emergency identifier known to be just a single bit, or could
> it contain data that can be use for other proposes (time stamp, 
> cryptographic signature?) --You say that theft-of-service calls most
> probably will not include any location information - but wouldn't
> they mostly likely include falsified location information so that
> they look legit but cannot be tracked back to the source?

The solution for the emergency identifier is described in
http://www.ietf.org/internet-drafts/draft-ietf-ecrit-service-urn-03.txt

> 
> 6  Security requirements
> 
> from section 5.1 fraudulent calls --How will a URI be verified as a
> PSAP?  Will the mapping server be used or is this a non-ECRIT
> security requirement?

That's subject for investigations in the solution space. I see the 
mapping server as one possible way to deal with it.

  --Are long distance calls to remote PSAPs
> always fraudulent?

No, certainly not since there is no concept of "long distant" anymore.

   For example, a disreputable foreign entity might
> set up a phony PSAP for its people to call.  Can a service provider
> refuse to carry or perhaps reroute a long distance emergency request?

That's largely a policy decision. I hope that they do not refuse such 
message routing practices. Additionally, you have to consider that you 
would like to get in touch with a PSAP that is close to your physical 
location. That's the whole point of this mapping protocol work. Hence, 
you shouldn't need to get in touch with, for example, your home PSAP 
when you roam to another country.

> 
> 
> from section 5.2.1 impersonation of the mapping server --mapping
> server discovery is apparently outside the scope of ECRIT topic, so
> does ECRIT simply assume that this will be done in a secure manner? 

Well, that's an interesting point. It is not out-of-scope anymore based 
on the DNS SRV solution we added to 
http://www.ietf.org/internet-drafts/draft-ietf-ecrit-service-urn-03.txt

I went through the section again. We do not state that the discovery 
procedure is outside the scope of the working group. It is, however, 
also not the case that we go into a long discussion about its 
vulernabilities either.

>  authenticated ones can be found? --does it ever make sense to return
> mapping server audit data to the client?  Is this data encrypted to
> make it inaccessible by the client? Is this design intended to
> address rogue servers?  If not, then why not just store the data on
> the server?
The discovery procedure as described in
http://www.ietf.org/internet-drafts/draft-ietf-ecrit-service-urn-03.txt
uses DNS. Currently, the procedures for selecting an appropriate server, 
if you receive multiple onces are described in the same draft.

What do you mean by audit data?

> from section 5.2.3 snooping attack -- the protocol or system must
> provide confidentiality mechanisms but the mapping server should
> respond to non-complaint clients with unprotected data if that is the
> only option

I wouldn't call it "non-compliant clients". There are potentially cases 
where the end host cannot get the TLS working and hence he shouldn't 
fail to make an emergency call.

> 
> Final comment:  Any concern about "insider attack" -- rogue PSAPs,
> SIP proxies, etc?

Good point. I guess we haven't been very explicit about it. I wonder 
where to state something about the fact that "insider attacks" are not 
covered in this document. As with many other protocol insider attacks 
are something hard to deal with.

Thanks again for the review.

Ciao
Hannes

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