Subject: Re: [Ecrit] Review of Security Threats Draft

From: "Tom-PT Taylor" <[email-masked]>
Date: Wed, 12 Jul 2006 10:19:24 -0400

Responses below. I've made some changes in response. Thanks for your 
comments.

Ron Watro wrote:
> 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).

[PTT] Already discussed, no action for the moment.
> 
> Specific comments are below:
> 
> Abstract
> 
> --doubled "the" in the last sentence

[PTT] Fixed.
> 
> 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.
[PTT] Fixed.
> --mixture of commas and periods as list separators in the last paragraph
> 
[PTT] This is prose, not a list. I combined the last three sections in 
one run-on sentence because putting them into individual sentences would 
be too boring.

> 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

[PTT] Wrong end of the stick. This is a potential solution based on 
ECRIT work, rather than a potential problem created by ECRIT work.

> --inconsistent punctuation at the end of bulleted items

[PTT] Fixed, I think.
> 
> 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?)

[PTT] Something that would be used for other purposes should be a 
separate field. It is bad protocol design to overload individual fields.

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

[PTT] Fixed as discussed in another E-mail (by mentioning additional 
possibility of false data).
> 
> 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?

[PTT] This is in the realm of solution, hence out of scope. However, I 
visualize a database listing every PSAP URI in the world. It seems to me 
there is an obvious relationship to the mapping service.

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

[PTT] No, one can easily imagine use cases where long distance calls are 
legitimate -- typically third party reports of emergencies.
> 
> 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?

[PTT] The security I-D does state a requirement:

   "Requirement: the security considerations for any discussion of
    mapping server discovery MUST address measures to prevent
    impersonation of the mapping server."

> --will the protocol allow exchange with unauthenticated servers if no 
> authenticated ones can be found?

[PTT] That's policy, I assume. The requirement is phrased in the 
opposite sense, that authentication must be possible.

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

[PTT] I think you make a valid point. First off, to be clear, the 
measure is aimed at the case of a legitimate (not rogue) mapping server 
that has errors in its database. The requirement was stated the way it 
was because I figured identification of these errors needed the 
cooperation of the client. But I was assuming a particular solution that 
I don't think will work.

I rephrased to be less directive:

"Requirement: the protocol SHOULD include information in the response 
that allows subsequent correlation of that response with internal logs 
that may be kept on the mapping server, to allow debugging of 
mis-directed calls. One example of a way to meet this requirement would 
be by means of an opaque parameter in the returned URI."
> 
> 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

[PTT] I think the draft is talking about mandatory-to-implement 
capabilities. Local policy will undoubtedly accommodate non-compliant 
clients, but we've had this discussion in various forms before and have 
decided that the security considerations document should take a firm line.
> 
> Final comment:  Any concern about "insider attack" -- rogue PSAPs, SIP 
> proxies, etc?

[PTT] Legitimate concern, but in scope only to the extent dealt with in 
terms of DOS attacks on mapping server.
> 
> Ron Watro
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> _______________________________________________
> Ecrit mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/ecrit
> 
> 

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

---

From: Ron Watro <[email-masked]>
Date: Wed, 12 Jul 2006 12:46:54 -0400

Thanks Tom.  This looks good to me.  After attending the GEOPRIV and ECRIT 
meetings yesterday, I have a better understanding of how the two groups are 
working together.

At 10:19 AM 7/12/2006 -0400, Tom-PT Taylor wrote:
>Responses below. I've made some changes in response. Thanks for your comments.
>
>Ron Watro wrote:
>>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.
>>not derived from a set of system security requirements (as is commonly done).
>
>>--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 
>[PTT] This is prose, not a list. I combined the last three sections in one 
>run-on sentence because putting them into individual sentences would be 
>too boring.
>
>[PTT] Wrong end of the stick. This is a potential solution based on ECRIT 
>work, rather than a potential problem created by ECRIT work.
>
>[PTT] Something that would be used for other purposes should be a separate 
>field. It is bad protocol design to overload individual fields.
>
>>topic, so does ECRIT simply assume that this will be done in a secure manner?
>
>[PTT] That's policy, I assume. The requirement is phrased in the opposite 
>sense, that authentication must be possible.
>
>[PTT] I think you make a valid point. First off, to be clear, the measure 
>is aimed at the case of a legitimate (not rogue) mapping server that has 
>errors in its database. The requirement was stated the way it was because 
>I figured identification of these errors needed the cooperation of the 
>client. But I was assuming a particular solution that I don't think will work.
>
>"Requirement: the protocol SHOULD include information in the response that 
>allows subsequent correlation of that response with internal logs that may 
>be kept on the mapping server, to allow debugging of mis-directed calls. 
>One example of a way to meet this requirement would be by means of an 
>opaque parameter in the returned URI."
>>-- 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
>