Hi Paul, Comment inline:
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. Raj> The context and scope of this threat analysis is limited to the protocol and communication between a master device and the white space database. What you are proposing above is a much broader scope in terms of the white space technology itself. We need to limit our scope to the protocol aspect here and that is what the proposed threat analysis is intended to do. > >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. Raj> Okay. > >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 Raj> Okay. Will add the additional consequences text. > >>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) Raj> Will keep them separate for now and see if there is a significant overlap. > >>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. Raj> Okay. > >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. Raj> Sure. But regulation requires a certain behavior. Anything outside that expected behavior is illegal and PAWS cannot do anything about that. > >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 Raj> Okay. Will add these to the next rev. Please review and provide additional text when I post the revised threat analysis shortly. Thanks for your comments. Appreciate your help in improving the text. -Raj > > > >Paul > > _______________________________________________ paws mailing list [email protected] https://www.ietf.org/mailman/listinfo/paws
