Inline: On 2/3/12 5:03 PM, "ext Paul Lambert" <[email protected]> wrote:
> >> Threat 3: Modifying a query response > >Not a threat ... perhaps a vulnerability if restated. >Suggest as a mechanism - any modification or spoofing of paws messages >all look about the same from the threat model. It's the actor, and end >impact that is interesting. The point with this threat (or vulnerability if you wish) is to derive a requirement for the protocol to ensure integrity protection for the request/response messages. And the same applies to Threat 4. -Raj > >Paul > > >>-----Original Message----- >>From: [email protected] [mailto:[email protected]] On Behalf Of >>[email protected] >>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
