Trustworthy Location
RFC 7378
Yes
No Objection
Note: This ballot was opened for revision 08 and is now closed.
(Alissa Cooper; former steering group member) Yes
One extra comment at the end that I failed to include in my first mail ... Section 1: I would suggest using the "Target" definition from RFC 6280 (unless there's an explicit reason to use the older definition). Section 3.1: "With location signing, a location server signs the location information before it is sent to the end host, (the entity subject to the location determination process). The signed location information is then verified by the location recipient and not by the target." This explanation is unclear. I think this is what was meant here: "With location signing, a location server signs the location information before it is sent to the Target. The signed location information is then sent to the location recipient, who verifies it." Also, I thought we stopped using the term "Geopriv Using Protocol" a long time ago. Please find some other term ("protocol that conveys location" would do the trick I think). Same comment in Section 3.2. Section 3.2: The specification of the DHCP location-by-reference URI option is not moving forward, so reference to it should be removed.
(Richard Barnes; former steering group member) Yes
(Spencer Dawkins; former steering group member) Yes
I like this draft. It's quite clear.
I have some comments that I'd like you to consider along with other comments you may receive.
In this text:
1. Introduction
Since prank emergency calls can endanger bystanders or emergency
services personnel, or divert resources away from legitimate
emergencies, they can be life threatening. A particularly dangerous
form of prank call is "swatting" - a prank emergency call that draws
a response from law enforcement (e.g. a fake hostage situation that
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Most television viewers in the US would understand the danger, but I wonder if readers throughout the world would have the same understanding. I might have suggested "a response from law enforcement prepared for a violent confrontation" or something ("brandishing automatic weapons").
results in dispatching of a "Special Weapons And Tactics" (SWAT)
team). In 2008 the Federal Bureau of Investigation (FBI) issued a
warning [Swatting] about an increase in the frequency and
sophistication of these attacks.
In this text:
2. Threats
Since we do not focus
on attackers gaining control of infrastructure elements (e.g.,
location servers, call route servers) or the emergency services IP
network, the threats arise from end hosts.
I am not suggesting any additional work to cover threats that don't arise from end hosts, and I'm not challenging this scope, but you might consider adding a sentence (perhaps at the end of this section) explaining why you chose this scope (because that's where most threats come from? Because subverting infrastucture/emergency services IP networks is hard, because defending against threats that don't originate from end hosts require different countermeasures ... I'd believe any of these or anything else that's plausible).
In this text:
3.2. Location by Reference
I confess to thinking about the issue because of another doc on this week's telechat agenda, but I agree with your suggestion here
For location-by-reference, the location server needs to maintain one
or several URIs for each target, timing out these URIs after a
certain amount of time. References need to expire to prevent the
recipient of such a Uniform Resource Locator (URL) from being able to
permanently track a host and to offer garbage collection
functionality for the location server.
and wonder if you should also suggest not reusing URLs for some period of time (especially if that qualifies as location-swapping, listed as a threat, and you're using "Authorization by Possession" of the URL).
In this text:
4. Location Trust Assessment
Where attacks are frequent and continuous, automated mechanisms are
required. For example, it might be valuable to develop mechanisms to
exchange audit trails information in a standardized format between
ISPs and PSAPs / VSPs and PSAPs or heuristics to distinguish
potentially fraudulent emergency calls from real emergencies. While
a Completely Automated Public Touring test to tell Computers and
^^^^^^^
I'm betting that's "Turing" ...
Humans Apart (CAPTCHA) may be applied to suspicious calls to lower
the risk from bot-nets, this is quite controversial for emergency
services, due to the risk of delaying or rejecting valid calls.
In this text:
5. Security Considerations
However, within an IP-based emergency services a number of these
attacks become much easier to mount. Emergency services have three
finite resources subject to denial of service attacks: the network
and server infrastructure, call takers and dispatchers, and the first
responders, such as fire fighters and police officers. Protecting
the network infrastructure is similar to protecting other high-value
service providers, except that location information may be used to
filter call setup requests, to weed out requests that are out of
area. PSAPs even for large cities may only have a handful of PSAP
call takers on duty, so even if they can, by questioning the caller,
^^^^
eliminate a lot of prank calls, they are quickly overwhelmed by even
^^^^
are the "they"s referring to the same thing? "PSAPs" and "call takers" are both plural, so this isn't easy to parse.
a small-scale attack. Finally, first responder resources are scarce,
particularly during mass-casualty events.
(Adrian Farrel; former steering group member) No Objection
I have no objection to the publication of this document. --- I'm interested in two scenarios. The first is whether we would ever reach a position where an emergency call that did not contain authenticatable location information would be discarded or treated as less urgent: "90 year-old widow burns to death because she used an old telephone". The second is whether there is a risk of false negatives that might lead the PSAP to mark a call as containing false information when it is in fact genuine: "Screw-up at high tech call center leads to death of 3 year-old girl". Perhaps this is covered by Section 4's if automated location information is understood to be highly suspect, a call taker can put more effort into obtaining location information from the caller. Maybe you could make this statement (adding "or absent") in the Introduction. But note that the thrust of the document is that if the location info is suspect then the whole call is suspect. So perhaps you need to modify this text as... if automated location information is understood to be highly suspect or is absent, a call taker can put more effort into verifying the authenticity of the call and to obtaining location information from the caller. --- A paragraph in the Introduction gives a false impression: EENA [EENA] has attempted to define terminology and describe best current practices for dealing with false emergency calls, which in certain European countries can constitute as much as 70% of all emergency calls. Reducing the number of prank calls represents a challenge, since emergency services authorities in most countries are required to answer every call (whenever possible). Where the caller cannot be identified, the ability to prosecute is limited. This leaves the reader believing that 70% of of all emergency calls are pranks, where the definition of "false" in the referenced document is quite different. Since the purpose of this work has two prongs (correctly locating a real emergency caller, and helping to identify prank calls - with the possibility of taking additional action) I think that the reference to 70% could be reasonably removed. --- In the Introduction... Ideally, a call taker at a Public Service Answering Point (PSAP) should be put in the position to assess, in real-time, the level of trust that can be placed on the information provided within a call. This includes automated location conveyed along with the call and location information communicated by the caller, as well as identity information about the caller. Where real-time assessment is not possible, it is important to be able to determine the source of the call in a post-mortem, so as to be able to enforce accountability. Can "identity information about the caller" really be determined? Do you mean "identity of the calling equipment? Do you really mean "post-mortem"? That sounds a bit dramatic. Maybe "after the fact". -- The term PIDF-LO is used before it is expanded in Section 2.1. --- LSP Great. Just what we needed. More meanings for the same old acronyms. Would you consider including a reference to RFC 5513? --- Shouldn't "Identity Spoofing" appear in Section 1.1? --- In Section 3 This section presents three mechanisms which can be used to convey location securely Is this exactly what you meant to say? "Convey securely" implies to me "protect against tampering on wire" and possibly "protect against snooping". but you are talking about source-signing which is equally about making the information authenticatable.
(Alia Atlas; former steering group member) No Objection
(Benoît Claise; former steering group member) No Objection
(Jari Arkko; former steering group member) No Objection
(Joel Jaeggli; former steering group member) No Objection
(Kathleen Moriarty; former steering group member) No Objection
I support Stephen's position
(Martin Stiemerling; former steering group member) No Objection
(Pete Resnick; former steering group member) No Objection
1: I think the word "prank" is incorrect here. A prank is normally done as a joke or to be mildly mischievous or a nuisance. (See the wikipedia entry for "Prank Call".) Instead, "hoax call" is probably the better term, and the one that is used in the EENA document. I think the reference to "swatting" makes the intro read as hype rather than a serious piece of technical work. It's not referred to elsewhere in the document. It's fine to refer to the EENA document, and mention the types of attacks, but remove the reference "swatting", and the FBI. They're not appropriate for this document. Leave it to the press releases. Ideally, a call taker at a PSAP should be put in the position to assess, in real-time, the level of trust that can be placed on the information provided within a call. Do you mean that the "call taker at a PSAP should *not* be put in the position to..."? (That is, this shouldn't be the responsibility of a human.) Or do you rather mean that the "call taker at a PSAP should be able to..."? Something's weird in the sentence as written. 2.1: Points 2 and 3 aren't end host attacks. I have a question about Location swapping: So Trudy gets Malory's location information. Then Malory can contact Trudy's PSAP and report an emergency at Trudy's location. But in this case, when the emergency turns out to be false, Trudy gets blamed *and that's right*, because Trudy colluded. Is the concern simply that somehow Malory won't get any of the blame for participating? What's the spoof here? 2.2: I don't understand how bot-net attacks are relevant here. The lack of doing strong authentication makes the system vulnerable to false identity attacks by the end host, but that's not a bot-net attack. If a bot-net attack is relevant here, you had best explain it. 3.1: I presume the bot-net attack described here (still not defined) is that the bots would be used for a DoS of the PSAP itself. But the damage is done with or without location information, isn't it? Or it could be that you're referring to bots set up to make a particular PSAP think that there was a set of calls from the same location (even though no human was on the other end of the line) and therefore increase the likelihood of an actual emergency. But you don't explain how that attack works. Either way, I'm not clear on what you're talking about here. Henning thanking himself in the acknowledgements is...creepy. Stephen and Adrian's comments are well-said. Saved me writing more.
(Stephen Farrell; former steering group member) (was Discuss) No Objection
- Thanks for adding text in 1.2.1 which is sufficient to handle the discuss. However, I think you're maybe missing the punch line at the end of 1.2.1 so I'd suggest maybe something like "Given the above, SIP UAs in practice provide no privacy for location information whenever the UA is able to determine location. This will likely lead to some proportion of users taking whatever steps are possible to prevent location information being available to the UAC. In the end, the consequence of not honoring the user's wishes within the network, will be that location will not be available (or will be spoofed) for some emergency calls." But, I doubt you'd want to go that far, so I won't insist:-) (As an aside, I'd be interested in thinking about whether or not we think the whole geopriv effort has been a success in privacy terms. I've no idea if there'd be energy for that, but it might be a useful bit of navel gazing for the IETF to do.) The comment below is from March. It remains valid I believe. I don't recall any response to it. - The title is misleading. I expected to be told how to do something or how someone had done something but instead the draft actually discusses pros and cons of many ways of providing location information for emergency calls. And no firm conclusion is reached. So I suggest a tile such as "Issues with Trusting Location" would be a more appropriate title.