>-----Original Message----- >From: Stephen Farrell [mailto:[email protected]] ... >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)" ?
Excellent idea. As you state it, this works for both database and user devices. > >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...) Seems like a encrypted tunnel (TLS, IPsec, etc) would prevent MiTM viewing of PII. - don't send PII - encrypt/mask PII - encrypt message end-to-end between ... hum, is a master a potential adversary? maybe I see where you were going with the field encryption Master-to-DB TLS/IPSec whatever is adequate Client-through-Master-to-DB is a little more difficult to ensure PII privacy Database use and of PII is a difficult topic. Not sure if we should facilitate users authorization or controlled release of their information. The PAWS protocol could perhaps have bits that express a requested policy (disclose or not). Enforcement would be left to trusting the DB to do the right thing with the request. Paul > >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
