This is a good point. But from the list provided below, only d) seems to be a security related threat fit to be included into the security considerations section of the draft. The other events look other than security related to me.
If we replace Threat 7 with the text in point d) below, I think we address Paul's point. s/ Threat 7: Termination of device service for reasons other than incumbent protection./ Threat 7: Malicious individual acts as a PAWS entity (spoofing DB or as MiM) to terminate or unfairly limit spectrum access of devices for reasons other than incumbent protection. - Gabor -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of ext Paul Lambert Sent: Friday, February 03, 2012 2:58 PM To: Patil Basavaraj (Nokia-CIC/Dallas); [email protected]; [email protected] Cc: [email protected] Subject: Re: [paws] Threat model (Rev 3) Hi Raj, First - a threat needs an actor or source. We seem to have different views of possible sources. >>>>> Threat 7: Termination of device service for reasons other than >>>>> incumbent protection Termination of device service is the end-impact (a useful starting point, but not exactly the threat). Some of the associated threat events are: a) Government (related to regulatory authority or not) uses WS Database to terminate or unfairly limit spectrum access of devices for reasons other than incumbent protection. b) Service provider or DB provider uses WS Database to terminate or unfairly limit spectrum access of devices for reasons other than incumbent protection. c) Owner of a Master device uses WS Database to terminate or unfairly limit spectrum access of devices for reasons other than incumbent protection. d) Malicious individual acts as a PAWS entity (spoofing DB or as MiM) to terminate or unfairly limit spectrum access of devices for reasons other than incumbent protection e) Natural disaster knocks out communications to the database preventing spectrum access. It seems silly for us to rush so quickly into building the fastest possible kill switch for communications. Push notifications are a cool mechanisms, but we also need some level of assurance that we will have continuity of usage of a set of channels. Ideally we'd have some looser limits on the on-channel times. Paul >-----Original Message----- >From: [email protected] [mailto:[email protected]] >Sent: Friday, February 03, 2012 2:35 PM >To: Paul Lambert; [email protected]; [email protected] >Cc: [email protected] >Subject: Re: [paws] Threat model (Rev 3) > > >Hi Paul. > >On 2/3/12 4:26 PM, "ext Paul Lambert" <[email protected]> wrote: > >> >>>>> 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. > >My interpretation of the additional threat you had suggested in a >previous emailŠ. >The point about this threat is that we have discussed about the >possibility of the database having the capability to send an >unsolicited push notification (to the master device) for revoking the >previously allocated channels and ceasing operation. >So the "malicious node" in this case is an entity which pretends to be >the database and sends such a push notification message to the master >device. > >> >> >>I was really thinking more about the misuse of the Database, or Master >to: >> - turn off devices presumed to be violating the DCMA > >DCMA? >The aspect of a device being switched off is covered in this threat. > >> - 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. > >I don't get the above two. Care to expand on these? > >> >>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. > >So do we need to capture this in the form of a threat? Do we want to >have a requirement that the protocol needs to enable logging and record >keeping? That¹s more of an implementation issue. > >-Raj > >> >>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 _______________________________________________ paws mailing list [email protected] https://www.ietf.org/mailman/listinfo/paws _______________________________________________ paws mailing list [email protected] https://www.ietf.org/mailman/listinfo/paws
