> 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.
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
