Minor rewording of threat 6: "A white space database in a regulatory domain 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 and used for tracking purposes. A master device may prefer to keep the location/identity information hidden from eavesdroppers, 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 query. When the master device sends both its identity and location to the DB, the DB is able to track it. If a regulatory domain does not require the master device to provide its identity to the white space database, the master device may decide not to send its identity, to prevent being tracked by the DB."
- Gabor -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Patil Basavaraj (Nokia-CIC/Dallas) Sent: Friday, February 03, 2012 11:34 AM To: [email protected]; [email protected] Subject: Re: [paws] Threat model (Rev 3) 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
