Subject: [paws] Rev 4 of the Threat model

From: <[email-masked]>
Date: Wed, 8 Feb 2012 22:20:56 +0000

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.