Well, it is a requirement, for both governments, but it's based on the notion that you could have a device that is interfering but not a whole class of devices. This can occur for a number of reasons including antenna modification.
Brian -----Original Message----- From: Stephen Farrell [mailto:[email protected]] Sent: Saturday, February 04, 2012 10:25 AM Eastern Standard Time To: [email protected] Cc: [email protected] Subject: Re: [paws] wondering why a device identifier is needed (was: Re: Threat model (Rev 3)) Hi Scott, On 02/04/2012 02:03 AM, [email protected] wrote: > 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. So a) that's a "regulator says" response and b) is that really specific to an individual device instance or not rather more likely to be something done to a device-type? (I don't know, but would be surprised to hear manufacturing leads to such variability such that turning off just one device is useful enough to justify the costs.) > 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. Neither of the above seem to be very paws-like though, what have those features got to do with whitespace? They also seem to implicitly assume some way to correlate that identifier across a whole bunch of protocols and only seem relevant to certain business models and not others. And of course, if the so-called "kill switch" is really a "pretty please kill yourself switch" then we're into the land of pretense as well. Gotta say I'm only really seeing "the FCC said so" here. S > > 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 _______________________________________________ paws mailing list [email protected] https://www.ietf.org/mailman/listinfo/paws
