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
