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
