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
