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
