On 02/05/2012 02:54 PM, Rosen, Brian wrote:
Well, it is a requirement, for both governments,
Clearly. And I'm not trying to say "don't meet that
requirement." (Much as that might be a logically pure
approach.)
but it's based on the notion that you could have a device that is interfering
but not a whole class of devices. This can occur for a number of reasons
including antenna modification.
You mean using the wrong antenna? Seems like that'd
fit into a "modified device" category of problem in
which case I'd wonder if the modder could've also
changed the device identifier. But I guess there may
be accidental interference cases where this could
help maybe.
I'm still puzzled by how this paws device identifier
might be used though, but presumably one of the drafts
will explain that.
S.
Brian
-----Original Message-----
From: Stephen Farrell [mailto:[email protected]]
Sent: Saturday, February 04, 2012 10:25 AM Eastern Standard Time
To: [email protected]
Cc: [email protected]
Subject: Re: [paws] wondering why a device identifier is needed (was:
Re: Threat model (Rev 3))
Hi Scott,
On 02/04/2012 02:03 AM, [email protected] wrote:
Hi,
A couple of motivations for device-specific identifiers are
* ability to black-list or disable a specific device. Regulators are
interested in ability to switch off a device that causes interference.
So a) that's a "regulator says" response and b) is that really
specific to an individual device instance or not rather more
likely to be something done to a device-type? (I don't know, but
would be surprised to hear manufacturing leads to such variability
such that turning off just one device is useful enough to justify
the costs.)
> Device manufacturers are interested in ability to switch off stolen
> devices.
* ability to directly address a specific device. One example here is the
'kill switch' described by Ofcom.
Neither of the above seem to be very paws-like though, what
have those features got to do with whitespace?
They also seem to implicitly assume some way to correlate that
identifier across a whole bunch of protocols and only seem
relevant to certain business models and not others.
And of course, if the so-called "kill switch" is really a
"pretty please kill yourself switch" then we're into the land
of pretense as well.
Gotta say I'm only really seeing "the FCC said so" here.
S
Kind Regards,
Scott
On 2/3/12 7:43 PM, "ext Paul Lambert"<[email protected]> wrote:
Good question.
If a set of certified devices (vendor / model type) are all supposed to
act the same, then any interference problem could be handled by changing
contours or blocking all of the model/types.
Paul
-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of
Stephen Farrell
Sent: Friday, February 03, 2012 3:43 PM
To: [email protected]
Subject: [paws] wondering why a device identifier is needed (was: Re:
Threat model (Rev 3))
So this is a bit of a side-issue maybe but I do wonder
if there's any functional/technical reason, other than
"the FCC said so," to identify a specific device in the
paws protocol with a long-lived identifier?
I can see why you'd want a device type of some sort,
and the DB might need some kind of session ID, but
I don't get the long-lived device identifier thing
at all as a functional requirement. Can anyone explain?
I'm not asking now from the privacy or security p-o-v,
but rather because its easier and cheaper and simpler to
not bother if you don't have to.
It does also interact with privacy& security of course.
Once you have to manage the identifier then you may need
to go to some trouble to protect that, but that's a
secondary question.
Thanks,
S.
On 02/03/2012 11:19 PM, Paul Lambert wrote:
using it themselves or retransmitting it. The resulting data one
whitespace availability will be visible to people and or devices
which
are not completely controlled by the regulatory agencies.
As such, what is the role of confidentiality with regard to this
information?
All channel availability (at least for the FCC) is openly available.
There is no threat of disclosure of this information. It's actually the
reverse. For planning purposes to buy and use WS devices - you really
would like a good picture of available spectrum. It would be very
detremental to market adoption to limit access to the available
channels.
That said - the current incumbants we discuss are just TV and
microphones. In the future, we might be sharing with public saftey or
military applications that would not want readily accessable maps of
their locations disseminated. "Open" consumer devices might in these
scenarios see no spectrum and the approved devices would get
allocations. This still should be out-of-scope. These types of devices
are not in our use case scenarios.
Privacy as you point out alone is a good justification for some form
of confidentiality. But protecting a devices identity may not require
encryption of the full paws messages.
Intgrity and data origin authentication seem more important for the
protocol design considerations.
Paul
-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf
Of
Joel M. Halpern
Sent: Friday, February 03, 2012 11:51 AM
To: [email protected]
Cc: [email protected]
Subject: Re: [paws] Threat model (Rev 3)
Can we please include in this document some articulation of the
confidentiality assumption we are making with regard to the
whitespace
data itself? I am not trying to object to the threats. (And the
personal information collection issues are enough to jsutify include
confidentiality mechanisms in the solutions.)
But I am still trying to get my head around this. There are going to
be
hoards of whitespace devices. They will be getting the data, and
either
using it themselves or retransmitting it. The resulting data one
whitespace availability will be visible to people and or devices
which
are not completely controlled by the regulatory agencies.
As such, what is the role of confidentiality with regard to this
information?
Yours,
Joel
On 2/3/2012 2:34 PM, [email protected] wrote:
Below is Rev 3 of the threat model based on feedback from Stephen,
Nancy
and Gabor (Thanks).
-Raj
Rev 3 (3/2/12)
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
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: 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 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. A master device may prefer to keep the
location/identity information secret. 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. If
regulations do not require the identity of the master
device
to
be provided to the white space database, the master is not
required to include its identity in the query.
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. A
malicious node can send a revoke message to a master
device. This results in denial of service to the master
device.
_______________________________________________
paws mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/paws
_______________________________________________
paws mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/paws
_______________________________________________
paws mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/paws
_______________________________________________
paws mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/paws
_______________________________________________
paws mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/paws
_______________________________________________
paws mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/paws
_______________________________________________
paws mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/paws
