>>> Threat 7: Termination of device service for reasons other than >>> incumbent protection >>> >>> A white space database may include a mechanism by which service >>> and channels allocated to a master device can be revoked. A >>> malicious node can send a revoke message to a master >>> device. This results in denial of service to the master >>> device.
No clue what you mean by "malicious node" ... this could be a Database, Master, random MiM, etc. I was really thinking more about the misuse of the Database, or Master to: - turn off devices presumed to be violating the DCMA - limiting spectrum usage based on the type or purpose of the traffic (e.g. Oakland BART) - limitation of spectrum usage based on political affiliation, race, gender, ideology, individual identity, etc. We may not be able to prevent (at a protocol level) unfair allocation or disablement. We should at least be able to have adequate logging and records that given an expectation of fair allocation - we can detect and complain when our mobile devices are turned off. Paul >-----Original Message----- >From: [email protected] [mailto:[email protected]] On Behalf Of >Joel M. Halpern >Sent: Friday, February 03, 2012 12:01 PM >To: Rosen, Brian >Cc: [email protected] >Subject: Re: [paws] Threat model (Rev 3) > >In the unauthorized use section, there is still the text saying: > 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. > >I still find this totally mind-bending, as it is about the hardest way >imaginable to undertake this attack. > > >On 2/3/2012 2:55 PM, Rosen, Brian wrote: >> <as individual> >> Where do you see this assumption in the threat model? >> >> I took a quick look and didn't spot it. It would be "database >information leaked to bad guys" or something like it, right? >> >> I don't think that is a threat, and I don't think we need to protect >anyone from that threat. >> >> I would say, however, that if you could know the content of the >database, and you can observe a responses over a period of time, you may >be able to infer the location of the querier. >> >> Brian >> >> >> On Feb 3, 2012, at 2:51 PM, Joel M. Halpern wrote: >> >>> Can we please include in this document some articulation of the >>> confidentiality assumption we are making with regard to the >whitespace >>> data itself? I am not trying to object to the threats. (And the >>> personal information collection issues are enough to jsutify include >>> confidentiality mechanisms in the solutions.) >>> But I am still trying to get my head around this. There are going to >be >>> hoards of whitespace devices. They will be getting the data, and >either >>> using it themselves or retransmitting it. The resulting data one >>> whitespace availability will be visible to people and or devices >which >>> are not completely controlled by the regulatory agencies. >>> As such, what is the role of confidentiality with regard to this >>> information? >>> >>> Yours, >>> Joel >>> >>> On 2/3/2012 2:34 PM, [email protected] wrote: >>>> >>>> Below is Rev 3 of the threat model based on feedback from Stephen, >Nancy >>>> and Gabor (Thanks). >>>> >>>> -Raj >>>> >>>> >>>> Rev 3 (3/2/12) >>>> >>>> Threat model for the PAWS protocol >>>> ---------------------------------- >>>> >>>> Assumptions: >>>> ............ >>>> >>>> o It is assumed that an attacker has full access to the network >medium >>>> between the master device and the white space database. The >attacker >>>> may be able to eavesdrop on any communications between these >>>> entities. The link between the master device and the white space >>>> database can be wired or wireless and provides IP connectivity. >>>> >>>> o It is assumed that the master device or the white space database >>>> have NOT been compromised from a security standpoint. >>>> >>>> Threat 1: User modifies a device to masquerade as another valid >>>> certified device >>>> >>>> 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. >>>> >>>> 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. >>>> >>>> Threat 3: Modifying a query request >>>> >>>> An attacker may modify the query request sent by a master >>>> device to a white space database. The attacker may change >the >>>> location of the device or the capabilities in terms of its >>>> transmit power or antenna height etc. which could result in >the >>>> database responding with incorrect information about >available >>>> channels or max transmit power allowed. The result of such >an >>>> attack is that the master device would cause intereference >to >>>> the primary user of the spectrum. It could also result in a >>>> denial of service to the master device by indicating that no >>>> channels are available. >>>> >>>> Threat 4: Modifying a query response >>>> >>>> An attacker could modify the query response sent by the >white >>>> space database to a master device. The channel information >or >>>> transmit power allowed type of parameters carried in the >>>> response could be modified by the attacker resulting in the >>>> master device using channels that are not available at a >>>> location or transmitting at a greater power level than >allowed >>>> resulting in interference to the primary user of that >>>> spectrum. Alternatively the attacker may indicate no channel >>>> availability at a location resulting in a denial of service >to >>>> the master device. >>>> >>>> Threat 5: Unauthorized use of channels by an uncertified device >>>> >>>> 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. >>>> The master device querying the white space database may be >>>> operated by a law-enforcement agency and the communications >>>> between the device and the database are intended to be kept >>>> private. A malicious device should not be able to eavesdrop >on >>>> such communications. >>>> >>>> Threat 6: Third party tracking of white space device location and >identity >>>> >>>> A white space database may require a master device to >provide >>>> its identity in addition to its location in the query >request. >>>> Such location/identity information can be gleaned by an >>>> eavesdropper. A master device may prefer to keep the >>>> location/identity information secret. Hence the protocol >should >>>> provide a means to protect the location and identity >>>> information of the master device and prevent tracking of >>>> locations associated with a white space database. If >>>> regulations do not require the identity of the master device >to >>>> be provided to the white space database, the master is not >>>> required to include its identity in the query. >>>> >>>> >>>> Threat 7: Termination of device service for reasons other than >>>> incumbent protection >>>> >>>> A white space database may include a mechanism by which >service >>>> and channels allocated to a master device can be revoked. A >>>> malicious node can send a revoke message to a master >>>> device. This results in denial of service to the master >>>> device. >>>> >>>> >>>> _______________________________________________ >>>> 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 _______________________________________________ paws mailing list [email protected] https://www.ietf.org/mailman/listinfo/paws
