Hi Paul, I am not proposing a use case, merely replying to Stephen's side-issue.
Kind Regards, Scott On 2/6/12 2:57 PM, "ext Paul Lambert" <[email protected]> wrote: > >>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
