Inline: On 2/3/12 2:11 PM, "ext Rosen, Brian" <[email protected]> wrote:
>Huh, since that section was about misuse of channel data, I missed the >point you were making. > >So, should we get rid of that use case (leaving the Law Enforcement case)? > >It does seem to me that if a rogue device existed, it would ignore the >database rather than eavesdrop. > >One thing we may wish to consider that got triggered by this exchange - >the database may be operated by a commercial entity. That entity may >wish to restrict access to only authorized users. That means there is >some kind of identity/authorization requirement, with a threat of theft >of service. Threat 1 sort of implies the need for identity/authorization. That is essentially the requirement that I was hoping would fall out of that description. The protocol needs to be capable of an eavesdropper from replaying credentials of a valid master device. It could be expanded to cover what you state above. -Raj > >Brian > >On Feb 3, 2012, at 2:57 PM, <[email protected]> wrote: > >> >> Hi Joel, >> >> Do you want to propose some text that I could include as part of the >> assumptions in the threat analysis section? >> The intent of this threat analysis text is to include it as a subsection >> of the security considerations section. >> >> -Raj >> >> On 2/3/12 1:51 PM, "ext Joel M. Halpern" <[email protected]> wrote: >> >>> 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
