We have nice tools to discover the right database. I don't think we will need to use anything but LoST, RFC5222, to discover the right one. Query with your location and a service urn related to the type of device/band/whatever and get back a list of URIs to the database. It's the base of emergency call routing, another government service, so making it secure should be straightforward.
Brian -----Original Message----- From: Stephen Farrell [mailto:[email protected]] Sent: Tuesday, January 31, 2012 05:55 PM Eastern Standard Time To: Paul Lambert Cc: [email protected] Subject: Re: [paws] Threats, Services and Predicatable Availability On 01/31/2012 07:13 PM, Paul Lambert wrote: > > One more observation on threat modeling. Discovering the database is a > service: > > 4) Support discovery of all authorized databases services for a geographic > region. Good one. (And presumably withstanding related spoofs will turn out to be desired too.) > Associated threat event would be: > - Modification of paws protocol messages in transit to prevent discovery of > authorized databases > > > When there are multiple authorized database services we need to make sure > that all authorized services are available to end devices. > > This implies a trust hierarchy with the regulatory authority (Gov based) as a > root for a region. New regions are not going to be easy to add ... which is > good since any new region also requires some level of regional conformance. Well, a hierarchy is a design choice for later I guess. (But clearly one that'll be a natural idea for some of the involved parties.) S > > Paul > > > >> -----Original Message----- >> From: Stephen Farrell [mailto:[email protected]] >> Sent: Monday, January 30, 2012 3:35 PM >> To: Paul Lambert >> Cc: [email protected]; [email protected] >> Subject: Re: [paws] Threats, Services and Predicatable Availability >> >> >> Sorry to keep on on the same thing, but it doesn't seem >> to be resonating much;-) >> >> The charter says: "Robust privacy and security mechanisms >> are needed..." >> >> I'm guessing its possible an analysis starting from your >> suggestions below should produce a good result wrt security >> but maybe less so for privacy (which is less well >> understood by us all). >> >> How about adding "Prevent unnecessary exposure of >> personally identifying information (PII)" ? >> >> Note that the above could me met via encryption of >> PII, (with possibly high-cost key management) or by >> just not sending PII when you don't need to which is >> fairly cheap if you're not forced by regulation to >> send it. (Since some devices presumably are not >> personally identifying but others are, then maybe >> there's a simple enough answer in the end...) >> >> S >> >> On 01/30/2012 10:29 PM, Paul Lambert wrote: >>> >>> Hi Raj, >>> >>>> Do you have any proposals or text w.r.t the threat model writeup? >> Also >>> >from an IETF perspective regarding threat models, please see Peter's >>>> email: http://www.ietf.org/mail- >> archive/web/paws/current/msg00592.html >>>> >>>> -Raj >>> >>> I'll spend a little time formalizing the ideas I submitted below. >> However, "threats" are part of a complete set of requirements and >> looking at the current proposal, I feel we need to clarify the service >> that we offer before we can say what are real threats. Specifically, >> the threat: >>> >>>>>> device which can be used maliciously. The effect of such an >>>>>> attack being successful would result in a malicious client >>>>>> replaying the stolen authentication/authorization secrets to >> a >>>>>> white space database. >>> >>> This is not a threat as worded... but why? >>> >>> We need to define what we offer, and then things that prevent or break >> these offered services are potential risks that can be mapped to >> threats. As a start, I propose (which I hope is mostly in line with the >> use cases) two main services with some subtopics: >>> >>> 1) Prevent Interference of License-exempt Use with Licensed Operation >> >>> - Support changes in channel, time Period and region for licensed >> operation >>> - Support predictable availability of licensed channels >>> - Support the ability to disable specific vendor/model-types from >> operation when >>> they are determined to be causing interference >>> 2) Enable Authorized Channel Utilization for License-exempt Operation >> >>> - Facilitate fixed use of channels >>> - Facilitate mobile use of channels >>> - Facilitate indoor use of channels >>> - Support predictable availability of license-exempt channels >>> - Support changing of authorized channels to prevent interference >> with licensed usage >>> >>> So, threat event is something that has a result of preventing the >> promised services. The threat event either causes unapproved >> interference with licensed operation, or it prevents White Space >> "license-exempt" operation. >>> >>> The "Support Predictable Availability" is something new I'd like to >> introduce for discussion. There needs to be a expectation that once you >> are using a channel that your use will not be terminated abruptly in an >> unanticipated manner. Right now - we are creating mechanism to quickly >> cutoff a device for any reason at all (for the use case of mobile >> microphones). This is actually supposed to be a predictable event with >> some type of scheduling. An license-exempt devices needs to be able to >> determine how long it might operate under the regulations in a >> particular channel/region. Building a system where you never know when >> your communications might get cut off seems like a bad idea. >>> >>> >>> >>> Paul >>> >>> >>>> >>>> On 1/27/12 5:24 PM, "ext Paul Lambert"<[email protected]> wrote: >>>> >>>>> It's good to have requirements based on such an analysis. This is >> an >>>>> interesting start, but we may be mixing threats, vulnerabilities and >>>>> mechanisms. >>>>> >>>>> Threats are typically tied to an actor ... human or not. I'm not >> sure >>>>> it's worth going hard over to something like the NIST 800-30 >>>> definitions >>>>> of threats, but within this framework the threats are Governments, >>>>> disgruntled insiders, tsunamis etc. Being the IETF we can jump more >>>>> quickly to the threat event and specifics of an attack, but should >> at >>>>> least expand threats to include natural events and connectivity >>>> problems. >>>>> Robustness or emergency modes might be interesting to consider. >>>>> >>>>> We also have a problem in this analysis of perspective - are we >>>>> considering threats as viewed from regulatory agency or the end >> device >>>>> owner or both. We should consider both - but they are contradictory >>>>> perspectives. Users want continuity of service. Governments (the >>>>> regulators) want control of the airwaves. >>>>> >>>>> Most of the real threats that we have are nearly impossible to >> prevent >>>> at >>>>> the protocol level. It's still worth examining the threats to see >>>> where >>>>> we stand. >>>>> >>>>> On the current document threats: >>>>> >>>>>> o It is assumed that the master device or the white space database >>>>>> have NOT been compromised from a security standpoint. >>>>>> >>>>>> Threat 1: Obtain master device authentication/authorization secrets >>>>>> The master device needs to authenticate itself with the >> white >>>>>> space database prior to requesting channel information. The >>>>>> attacker may try to get access to the secrets of the master >>>>>> device which can be used maliciously. The effect of such an >>>>>> attack being successful would result in a malicious client >>>>>> replaying the stolen authentication/authorization secrets to >> a >>>>>> white space database. >>>>> This does not seem consistent with the prior statement of "not >>>>> compromised". >>>>> Restatement >>>>> >>>>> Threat: User modifies a device to masquerade as another valid >> certified >>>>> device. >>>>> >>>>> This is an interesting case where threat/vulnerability/risk play >>>>> together. The FCC or other regulatory agencies want traceability of >>>>> devices. If a user wants to run a rogue radio, there is no reason >> to >>>>> access the database (low risk - no payoff). The only reason this >> would >>>>> be an interesting attack might be to avoid tracking and have some >>>>> anonymity. >>>>> >>>>>> Threat 2: Spoofed white space database >>>>>> A master device discovers a white space database(s) thru >> which >>>>>> it can query for channel information. The master device >> needs >>>>>> to ensure that the white space database with which it >>>>>> communicates with is an authentic entity. The white space >>>>>> database needs to provide its identity to the master device >>>>>> which can confirm the validity/authenticty of the database. >> An >>>>>> attacker may attempt to spoof a white space database and >>>>>> provide responses to a master device which are malicious and >>>>>> result in the master device causing interference to the >> primary >>>>>> user of the spectrum. >>>>> >>>>> I think this is two types of threat events: >>>>> - malicious denial of service or intentional interference with >>>> incumbents >>>>> - impersonation of white space database to enable operation of a >>>> device >>>>> that may >>>>> not otherwise be possible (blocked device, unallocated channels). >>>>> This may or may not >>>>> interfere with incumbent devices >>>>> >>>>>> Threat 3: Modifying a query request >>>>> ... >>>>> >>>>>> Threat 4: Modifying a query response >>>>> Seems like these two could be lumped together ...MiTM modifies >> protocol >>>>> messages to: >>>>> - deny service >>>>> - interfere with incumbents >>>>> - provide unauthorized channel usage (most likely risk IMHO) >>>>> >>>>>> Threat 5: Using query response information >>>>>> An attacker may be a master device which is not certified >> for >>>>>> use by the relevant regulatory body. The attacker may listen >> to >>>>>> the communication between a valid master device and white >> space >>>>>> database and utilize the information about available >> channels >>>>>> in the response message by utilizing those channels. The >> result >>>>>> of such an attack is unauthorized use of channels by a >> master >>>>>> device which is not certified to operate. >>>>> As stated this is a mechanism - a clearer statement might be. >>>>> >>>>> Threat: Unauthorized use of channels by an uncertified device. >>>>> >>>>> Anyone can already go to a database and find available channels. If >> a >>>>> device can operate without going to the database there is nothing >> that >>>>> paws can do to stop it operating in available or non-available >>>> channels. >>>>> >>>>> Just to get some discussion going -here's a couple more possible >>>> threats.. >>>>> >>>>> Threat: Third party tracking of white space device location >>>>> Likely a valuable commodity to sell for advertizing with no >>>> technical >>>>> design or policy for privacy >>>>> Threat: Database owner termination of device service for reasons >> other >>>>> than incumbent protection >>>>> >>>>> >>>>> >>>>> Paul >>>>> >>>>> >>> >>> _______________________________________________ >>> paws mailing list >>> [email protected] >>> https://www.ietf.org/mailman/listinfo/paws >>> > _______________________________________________ paws mailing list [email protected] https://www.ietf.org/mailman/listinfo/paws _______________________________________________ paws mailing list [email protected] https://www.ietf.org/mailman/listinfo/paws
