Hello,
Please find Rev 4 of the threat model. With the objective being "Deriving
security requirements for the protocol", this version of the threat model
is sufficient for the stated purpose. Hence unless you have serious
issues/concerns with this threat model I would suggest that we incorporate
this into the security section of the use-cases and requirements I-D and
move forward.
-Raj
Rev 4 (2/8/12)
Changes:
1. Text for Threat 1 is updated courtesy of Joel Halpern and Brian
Rosen.
2. Text for Threat 6 updated with text provided by Gabor Bajko.
3. Updated text for Threat 7 indicating that the existence of a
kill-switch is an
assumption.
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: 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 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.
_______________________________________________
paws mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/paws
