>Device manufacturers are interested in ability to switch off stolen >devices.
No. This is not a valid use case for a license exempt usage of a regulatory database. Any payment system or authorization to use a device outside of the regulatory limitations should not be part of the regulatory focused protocol. How would a device manufacture contact a regulatory authority to "kill" a device? How would a user report a stolen device? How would you prevent incorrect reports of stolen devices being used to shut off a device. Why do we need a kill switch for a single non-conforming device - when the certification is for a device class. If one device is interfering, it's likely all like device types would interfere at the same location. The enabled region could be changed, or the device type black listed. If a device is able to operate in a manner that ignores the database, than it may interfere, but would not be able to "killed" since it is already ignoring the database. The is a history of needing unique identifiers for licensed devices. Correct operation for most licensed devices is based on human configuration and correct usage of the system. A unique identifier is required to allow such human controlled usage to be tracked and action taken if the device operates outside of it's license considerations. "killing devices" should not be a mandatory feature of the paws protocol and should only be based a model of the regulatory requirements for a region. Unique device identifiers shoul also be optional. Paul >-----Original Message----- >From: [email protected] [mailto:[email protected]] >Sent: Friday, February 03, 2012 6:03 PM >To: Paul Lambert; [email protected]; [email protected] >Subject: Re: [paws] wondering why a device identifier is needed (was: >Re: Threat model (Rev 3)) > >Hi, > >A couple of motivations for device-specific identifiers are >* ability to black-list or disable a specific device. Regulators are >interested in ability to switch off a device that causes interference. >Device manufacturers are interested in ability to switch off stolen >devices. >* ability to directly address a specific device. One example here is the >'kill switch' described by Ofcom. > >Kind Regards, >Scott > > >On 2/3/12 7:43 PM, "ext Paul Lambert" <[email protected]> wrote: > >> >>Good question. >> >>If a set of certified devices (vendor / model type) are all supposed to >>act the same, then any interference problem could be handled by >changing >>contours or blocking all of the model/types. >> >>Paul >> >> >>>-----Original Message----- >>>From: [email protected] [mailto:[email protected]] On Behalf >Of >>>Stephen Farrell >>>Sent: Friday, February 03, 2012 3:43 PM >>>To: [email protected] >>>Subject: [paws] wondering why a device identifier is needed (was: Re: >>>Threat model (Rev 3)) >>> >>> >>>So this is a bit of a side-issue maybe but I do wonder >>>if there's any functional/technical reason, other than >>>"the FCC said so," to identify a specific device in the >>>paws protocol with a long-lived identifier? >>> >>>I can see why you'd want a device type of some sort, >>>and the DB might need some kind of session ID, but >>>I don't get the long-lived device identifier thing >>>at all as a functional requirement. Can anyone explain? >>> >>>I'm not asking now from the privacy or security p-o-v, >>>but rather because its easier and cheaper and simpler to >>>not bother if you don't have to. >>> >>>It does also interact with privacy & security of course. >>>Once you have to manage the identifier then you may need >>>to go to some trouble to protect that, but that's a >>>secondary question. >>> >>>Thanks, >>>S. >>> >>>On 02/03/2012 11:19 PM, Paul Lambert wrote: >>>>> 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? >>>> >>>> All channel availability (at least for the FCC) is openly available. >>>There is no threat of disclosure of this information. It's actually >the >>>reverse. For planning purposes to buy and use WS devices - you really >>>would like a good picture of available spectrum. It would be very >>>detremental to market adoption to limit access to the available >>>channels. >>>> >>>> That said - the current incumbants we discuss are just TV and >>>microphones. In the future, we might be sharing with public saftey or >>>military applications that would not want readily accessable maps of >>>their locations disseminated. "Open" consumer devices might in these >>>scenarios see no spectrum and the approved devices would get >>>allocations. This still should be out-of-scope. These types of >devices >>>are not in our use case scenarios. >>>> >>>> Privacy as you point out alone is a good justification for some form >>>of confidentiality. But protecting a devices identity may not require >>>encryption of the full paws messages. >>>> >>>> Intgrity and data origin authentication seem more important for the >>>protocol design considerations. >>>> >>>> Paul >>>> >>>> >>>>> -----Original Message----- >>>>> From: [email protected] [mailto:[email protected]] On >Behalf >>>Of >>>>> Joel M. Halpern >>>>> Sent: Friday, February 03, 2012 11:51 AM >>>>> To: [email protected] >>>>> Cc: [email protected] >>>>> Subject: Re: [paws] Threat model (Rev 3) >>>>> >>>>> 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
