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
