It looks like we are creating a requirement where there isn't one.
And if we can avoid mandating encryption, that would seem to make life
simpler for all concerned.
In fact, for an actual attacker, I think the information from the
response is almsot useless. After all, their goal is to interfere with
actual use. The numbers from the response presumably icnlude guard
regions and safety margins. The attacker is far more likely to be able
to actually measure activity, observe multiple locations, and decide
what trouble he wants to cause. None of that requires eavesdropping.
I would really prefer we as a group not invent requirements that do not
respond to meaningful threats.
Yours,
Joel
On 1/27/2012 4:48 PM, [email protected] wrote:
Resultant harm from an eavesdropper capable of behaving as a master device
is causing interference to the primary owner of the spectrum by
transmitting at power levels greater than what is authorized for example.
Of course a malicious device could do that without necessarily
eavesdropping on the link between an authorized/valid master device and
database. But the information about available channels and allowed xmit
power limits for example can be used to fine-tune the attack.
An unauthorized master device may offer service to other devices using the
available channel information for example. This is another resultant harm.
It is indeed the case that the database is responding to a
valid/authorized master device but the response message is being
eavesdropped upon and hence IMO it does raise the requirement for avoiding
eavesdropping.
-Raj
On 1/27/12 2:08 PM, "ext Joel M. Halpern"<[email protected]> wrote:
can you please elaborate on the resultant harm if a non-authorized user
receives a copy of the data? Depending upon what that threat is, I can
imagine a number of additional issues that would need to be elucidates.
Note that if this is because the regulations say that the database must
only respond to requests from authorized master, that does not actually
lead to a requirement to prevent eavesdropping. The database is still
only responding to requests from authorized participants.
Yours,
Joel
On 1/27/2012 3:01 PM, [email protected] wrote:
Joel,
A white space database MUST respond with available channel information
only to a certified master device.
Threat 5 is about master devices which have not been approved/certified
by
a regulatory body in a specific country.
What threat 5 essentially implies in terms of security requirements is
the
need for the data to be encrypted. The response message MUST be
encrypted
by the white space database so that a MiTM cannot read the data and use
that information.
-Raj
On 1/27/12 1:49 PM, "ext Joel M. Halpern"<[email protected]> wrote:
Most of this looks good.
The last one does not seem to make sense to me.
I presume I am missing something. What follows is why I am confused,
with apologies if I have overlooked something.
Given the nature of the system, the number of ways for a
non-cooperative
client to get the information about what the compliant clients are
allowed to do seems myriad. And the number of ways a non-compliant
client can mis-behave is also myriad.
So I do not actually understand the threat.
I can imagine privacy-driven confidentiality with regard to requests.
I
hope we don't have to go there, but that would be a threat that I would
think was more of an issue than receving a copy of a response.
Yours,
Joel M. Halpern
On 1/27/2012 2:39 PM, [email protected] wrote:
Hello,
While discussing the requirements we concluded that it would be useful
to
have a threat model for PAWS. Below is an initial writeup of the
threat
model. This threat model can be included in the Security
considerations
section of the Use-case and Requirements I-D. Security requirements
can
be
derived from this threat model.
Comments welcome.
-Raj
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: Obtain master device authentication/authorization secrets
The master device needs to authenticate itself with the white
space database prior to requesting channel information. The
attacker may try to get access to the secrets of the master
device which can be used maliciously. The effect of such an
attack being successful would result in a malicious client
replaying the stolen authentication/authorization secrets to
a
white space database.
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: Using query response information
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.
_______________________________________________
paws mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/paws
_______________________________________________
paws mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/paws
