Subject: [Ecrit] initial thoughts on draft-taylor-ecrit-security-threats-01.txt

From: Andrew Newton <[email-masked]>
Date: Wed, 1 Feb 2006 06:52:43 -0500

Though I haven't had the chance to review this draft as thoroughly as  
I would have liked, here are my comments on this revision:

1) Overall, I like the changes.  Tom, you have done a very good job.   
I especially appreciate the requirements changes from things like  
"MUST do channel security" to "MUST provide integrity".  Again, good  
job.

2) My two main points from the last revision still stand.  Here they  
are from that email:

> a) First, I question whether or not they are overly burdensome with  
> regard to performance.  Invoking channel security is more than just  
> a few roundtrips and is CPU intensive.  Additionally, the  
> requirement for object signing may be even more burdensome, as it  
> requires the triple of location info, URI, and timestamp (that's a  
> lot of data to sign -- especially in the geo x,y,z case, and just  
> how often does it need resigning).  And I certainly don't think  
> both of these measures are required.

Now, this isn't to say that what is stated in the draft is  
incorrect.  The point here is that there is a real-world gap between  
what we would like to have and what we can deploy.  Any system that  
requires channel-based integrity & confidentiality while also  
dictating multiple objects signed on-the-fly is going to be its own  
denial of service attack.

> b) There is no discussion regarding what a user would do if  
> authentication fails.  What does it mean?  Do they just put down  
> the phone and let their house burn down?  Or do they continue on  
> with the call in hopes that the authentication failure is false  
> indicator?

Understanding the use case will likely lighten the load.  After all,  
authentication is worthless if there is no authorization that can be  
applied to it.  I believe this point was made in Vancouver as well.

3) Section 6.1 says that LI configured manually must be authenticated  
and authorized.  If this is true, then in reality you are ruling out  
manually configured LI.  But going beyond that, how is GPS acquired  
LI any better than manually configured LI?  If all an attacker has to  
do is set the "I got this from GPS" flag to true, doesn't that just  
circumvent the protection placed against manual configuration?  So do  
we then need to authenticate and authorize GPS acquired LI?  If so,  
just how will that be accomplished?

4) Section 5.4 should include the threat that information gained from  
the IP network could be used by attackers in the PSTN against the  
PSAPs, as has been discussed on this list many times.

-andy

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