Subject: [Ecrit] Changes in the ECRIT security draft

From: "Tom-PT Taylor" <[email-masked]>
Date: Mon, 26 Jun 2006 16:17:18 -0400

I updated the ECRIT security draft to take account of comments Hannes
and by Kamran Aquil. The following changes are reflected in
draft-ietf-ecrit-security-threats-02.txt:

1. Abstract: eliminated reference to ECRIT and highlighted the two
topics of the analysis by breaking them out into bullets. Added the word
"identified" in front of "threats" in the last senttence (typo noted).

2. Changed the section headings to capitalized style.

3. Introduction second para: deleted the parenthetic reference to
attempts to get free calling in the PSTN. Deleted the reference to the
ECRIT WG further down, replacing
   "In view of the mandate of the ECRIT Working Group"
with
   "While this can be a broad topic".

4. Next para: replaced "ECRIT" with "emergency calling".

5. Section 3 first para modified to eliminate references to ECRIT.

Old:

   "The ECRIT Working Group has two work items relating to the routing of
    emergency calls to their proper destination.  The first is to enable
    entities along the signalling path to recognize that a particular
    signalling message is associated with an emergency call.  The ECRIT
    Working Group is defining content that can be added to the signalling
    messages, an emergency identifier, for this purpose.  Signalling
    containing the emergency identifier may be given priority treatment,
    special processing, and/or special routing."

New:

   "This memo deals with two topics relating to the routing of emergency
    calls to their proper destination.  The first is the marking of call
    signalling to enable entities along the signalling path to recognize
    that a particular signalling message is associated with an emergency
    call.  Signalling containing the emergency identifier may be given
    priority treatment, special processing, and/or special routing."

6. Next para: deleted a reference to ECRIT.

7. Section 4,third bullet of "attacks against the emergency response
system": deleted reference to ECRIT and rephrased to make the meaning
clearer.

Old:

   "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"

New:

   "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."

7. Section 5.1 bullet b. rewritten for more clarity:

Old:

   "b.  The call routing system assumes that the emergency caller's
        device addresses emergency calls using the result of mapping
        based on the caller's location."

New:

   "b.  The call routing system assumes that the emergency caller's
        device signals the correct PSAP URI for the caller's location."

8. Section 5.2.1 first para rewritten to take account of a point raised
by Hannes: that the call may never get to a PSAP at all.

Old:

   "This section considers attacks intended to reduce the effectiveness
    of the emergency response system for all callers in a given area.  If
    the mapping operation is disabled, the immediate effect is to
    increase the probability that emergency calls are routed to the wrong
    PSAP.  This has a double consequence: emergency response to the
    affected calls is delayed, and PSAP call taker resources outside the
    immediate area of the emergency are consumed due to the extra effort
    required to redirect the calls.  Alternatively, attacks that cause
    the client to receive a URI that does not lead to a PSAP have the
    immediate effect of causing emergency calls to fail."

New:

   "This section considers attacks intended to reduce the effectiveness
    of the emergency response system for all callers in a given area.  If
    the mapping operation is disabled, then the emergency caller's device
    might not have the correct PSAP URI.  As a consequence, the
    probability that emergency calls are routed to the wrong PSAP is
    increased.  In the worst case the emergency caller's device might not
    be able to obtain a PSAP URI at all.  Routing to the wrong PSAP has a
    double consequence: emergency response to the affected calls is
    delayed, and PSAP call taker resources outside the immediate area of
    the emergency are consumed due to the extra effort required to
    redirect the calls.  Alternatively, attacks that cause the client to
    receive a URI that does not lead to a PSAP have the immediate effect
    of causing emergency calls to fail."

9. Section 5.2.1, para beginning "In an impersonation attack, ..."
following the bullets, rewrote final sentence to make it clearer.

Old:

   "However, the mapping protocol may help to protect against
    acceptance of responses from an impersonating entity."

New:

   "However, the mapping protocol may allow impersonation to
    be detected, thereby preventing acceptance of responses from an
    impersonating entity and possibly triggering a more secure discovery
    procedure."

10. Section 5.2.3 first para: added the word "Alternatively" at the
start of the sentence.

11. Added Kamran Aquil to the Acknowledgements section (typo noted, sorry).

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

---

From: Ron Watro <[email-masked]>
Date: Mon, 26 Jun 2006 18:23:57 -0400

Tom,

I posted a few comments on the threats document back in late May and Hannes 
posted some replies.  I did not follow up at that time and you may not have 
noticed these comments.  For example, in section 5.1, you say that 
signalling to obtain fraudulent service will most likely not include any 
location information.  Are you assuming that there is some mechanism that 
prevents a caller from creating spoofed location information?  If not, then 
those attempting to obtain fraudulent service would seem likely to include 
bogus location data, to make their calls appear more genuine without 
revealing their true location.

In general, to make VoIP E911 work, one will need a deterrent to DoS 
attacks against a PSAP.  If a VoIP user can make a large number of calls to 
a PSAP without fear of retribution, then we are in trouble.   When a VoIP 
caller is getting free service to reach a PSAP, there will be no 
authentication of that caller by a VoIP service provider.  If that caller 
is generating its own (bogus) location information to insert into the free 
call, then it seems that we have the potential for a DoS attack.  ECRIT 
could help address this problem by designing a protocol where a location 
server or an ISP issues a cryptographic token to a phone for use in marking 
its emergency calls.  This could provide some deterrent to launching a DoS 
attack.  Steve Kent and I have had brief discussions about this 
possibility.  We haven't worked out any details yet but we would be happy 
to have discussions with interested parties either on this list or in 
Montreal next month.

Cheers

Ron Watro

---

From: "Tom-PT Taylor" <[email-masked]>
Date: Mon, 26 Jun 2006 17:38:21 -0700

I apologize, Ron. I noted the discussion when it happened, but failed to 
file it where it would pop out when I got around to updating the draft.

Hannes gave you a response. I think there are one or two points I want 
to address, so I will go back and give one of my own. I might as well 
start with the points you carried over in this E-mail, then go back for 
the others.

Ron Watro wrote:
> Tom,
> 
> I posted a few comments on the threats document back in late May and 
> Hannes posted some replies.  I did not follow up at that time and you 
> may not have noticed these comments.  For example, in section 5.1, you 
> say that signalling to obtain fraudulent service will most likely not 
> include any location information.  Are you assuming that there is some 
> mechanism that prevents a caller from creating spoofed location 
> information?  If not, then those attempting to obtain fraudulent service 
> would seem likely to include bogus location data, to make their calls 
> appear more genuine without revealing their true location.

[PTT] I was trying to state a case that would make the difficulties 
clear -- that it would not be a simple matter of the network checking 
the URI in the signalling against location also given in that 
signalling, because the attacker would not be so obliging as to include 
the necessary information. Your idea is even messier, but doesn't change 
the basic point that the URI has to be checked out on its own merits. 
I'll change the text to say: "... or there could be location 
information, but it is false."
> attacks against a PSAP.  If a VoIP user can make a large number of calls 
> to a PSAP without fear of retribution, then we are in trouble.   When a 
> VoIP caller is getting free service to reach a PSAP, there will be no 
> authentication of that caller by a VoIP service provider.  If that 
> caller is generating its own (bogus) location information to insert into 
> the free call, then it seems that we have the potential for a DoS 
> attack.  ECRIT could help address this problem by designing a protocol 
> where a location server or an ISP issues a cryptographic token to a 
> phone for use in marking its emergency calls.  This could provide some 
> deterrent to launching a DoS attack.  Steve Kent and I have had brief 
> discussions about this possibility.  We haven't worked out any details 
> yet but we would be happy to have discussions with interested parties 
> either on this list or in Montreal next month.

[PTT] Leaving aside the solution, which must be the subject of a 
different I-D, the question is whether I have overlooked a requirement. 
DOS attacks on the PSAP are not in scope of the present document. Use of 
the emergency identifier or location mapping to generate such attacks is 
in scope, but that's not what you're talking about here.
> Ron Watro
...

---

From: Ron Watro <[email-masked]>
Date: Tue, 27 Jun 2006 09:27:28 -0400

Tom,

Thanks for the quick reply.  I agree with your first point.  Regarding the 
2nd issue, I understand your logic, which (roughly put) is that the 
location/URI servers and protocols aren't the root source of the DOS on 
PSAP problem, so they don't need to deal with it; they just shouldn't make 
it any worse.  Unfortunately though, *somebody* needs to deal with this 
problem somewhere in the VoIP E911 system, and the location servers and 
protocols are one obvious candidate.  If ECRIT wants to pass on this issue, 
I think the security doc should at least point out that future 
modifications to the protocols may be needed to address these sorts of 
security problems.  Ideally, we should have a system security analysis for 
VoIP E911, and this would drive what is in scope and out of scope for ECRIT.

Cheers

Ron

At 08:38 PM 6/26/2006, Tom-PT Taylor wrote:
>Hannes gave you a response. I think there are one or two points I want to 
>address, so I will go back and give one of my own. I might as well start 
>with the points you carried over in this E-mail, then go back for the others.
>
>Ron Watro wrote:
>>Tom,
>>Hannes posted some replies.  I did not follow up at that time and you may 
>>not have noticed these comments.  For example, in section 5.1, you say 
>>that signalling to obtain fraudulent service will most likely not include 
>>any location information.  Are you assuming that there is some mechanism 
>>that prevents a caller from creating spoofed location information?  If 
>>not, then those attempting to obtain fraudulent service would seem likely 
>>to include bogus location data, to make their calls appear more genuine 
>>without revealing their true location.
>
>[PTT] I was trying to state a case that would make the difficulties clear 
>-- that it would not be a simple matter of the network checking the URI in 
>the signalling against location also given in that signalling, because the 
>attacker would not be so obliging as to include the necessary information. 
>Your idea is even messier, but doesn't change the basic point that the URI 
>has to be checked out on its own merits. I'll change the text to say: "... 
>or there could be location information, but it is false."
>>is generating its own (bogus) location information to insert into the 
>>free call, then it seems that we have the potential for a DoS 
>>where a location server or an ISP issues a cryptographic token to a phone 
>>for use in marking its emergency calls.  This could provide some 
>[PTT] Leaving aside the solution, which must be the subject of a different 
>I-D, the question is whether I have overlooked a requirement. DOS attacks 
>on the PSAP are not in scope of the present document. Use of the emergency 
>identifier or location mapping to generate such attacks is in scope, but 
>that's not what you're talking about here.
>>Cheers
>>Ron Watro
>...