Yes. I did see your comment and incorporated it into Threat 8. -Raj
On 2/13/12 2:10 PM, "ext Teco Boot" <[email protected]> wrote: >Raj, others, > >I posted comments on your first outline. >http://www.ietf.org/mail-archive/web/paws/current/msg00765.html >Does it make sense? > >Thanks, Teco > >Op 13 feb. 2012, om 19:06 heeft <[email protected]> ><[email protected]> het volgende geschreven: > >> >> Please find Rev 5 of the threat model. If we have consensus on this >>version, I will incorporate it as part of the security considerations >>section of the I-D. >> >> -Raj >> >> >> Rev 5 (2/13/12) >> >> Changes: >> >> 1. Added threat 8 with feedback from Rex B., Paul L. Nancy B. and, Teco >>Boot >> >> >> >> 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 >> >> Regulatory environments require that devices be certified and >> register in ways that accurately reflect their certification. >> Without suitable protection mechanisms, devices could simply >> listen to registration exchanges, and later registering >> claiming to be those other devices. Such replays would allow >> fasle registration, violating regulatory regimes. >> A white space database may be operated by a commercial entity >> which restricts access to authorized users. A master device >> MAY need to identify itself to the database and be authorized to >> obtain information about available channels. >> >> 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 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. >> >> Threat 7: Malicious individual acts as a PAWS entity (spoofing DB or >> as MiM) to terminate or unfairly limit spectrum access of devices >>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 by >> sending an unsolicited message. A malicious node can pretend to >> be the white space database with which a master device has >> registered or obtained channel information from and send a >> revoke message to that device. This results in denial of >> service to the master device. >> >> Threat 8: Natural disaster resulting in inability to obtain >>authorization >> for white space spectrum use by emergency responders >> >> In the case of a sizable natural disaster a lot of internet >> infrastructure ceases to function. Emergency services users >> need to reconstitute quickly and will rely on establishing >> radio WANs. The potential for lot of radio WAN gear that has >> been unused suddenly needs to be pressed into action. And >> the radio WANs need frequency authorizations to >> function. Regulatory entities may also authorize usage of >> additional spectrum in the affected areas. The white space >> radio entities may need to establish communication with a >> database and obtain authorizations. In cases where >> communication with the white space database fails, the white >> space devices cannot utilize white space spectrum. Emergency >> services, which require more spectrum precisely at locations >> where network infrastructure is malfunctioning or >> overloaded, backup communication channels and distributed >> white space databases are needed to overcome such >> circumstances.Alternatively there may be other mechanisms >> which allow the use of spectrum by emergency service >> equipment without strict authorization or with liberal >> interpretation of the regulatory policy for white space >> usage. >> >> >> _______________________________________________ >> paws mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/paws > _______________________________________________ paws mailing list [email protected] https://www.ietf.org/mailman/listinfo/paws
