Hi Raj, >From: [email protected] [mailto:[email protected]] ... >Hi Paul, > >On 2/3/12 4:58 PM, "ext Paul Lambert" <[email protected]> wrote: > >> >>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). > >Assuming that there exists the ability to send an unsolicited push >notification to the master device to curtail service from the database, >the threat here is the possibility of an attacker sending such a message >to a master device. >Of course the protocol could be designed to ensure that the master >device >verifies the message for authenticity etc., but the threat itself >exists. [Paul] You missed my point below. There are many sources of threats. Not all can be directly mitigated by protocol mechanisms, but there may be ways with associated policies, procedures and agreements to limit the impact.
If we are performing a threat analysis we should look at the full suite of threats. Paul >> >> >> >>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. > >We previously discussed the need for a kill switch and my recollection >is >that it is a nice-to-have feature and not something that is mandatory. >Regulatory environments will choose to define whether it is required or >not. The threat described in (7) is simply based on the assumption of >such a feature existing. > >-Raj > >>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
