The discussions on this mail thread have slowed down. Raj, can you implement the comments received on the list so far and post the text again for further input? - Gabor
-----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Patil Basavaraj (Nokia-CIC/Dallas) Sent: Monday, January 30, 2012 9:57 AM To: [email protected]; [email protected] Subject: Re: [paws] Threat model Hi Paul, 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 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
