-----Original Message-----
From: Stephen Farrell [mailto:[email protected]]
Sent: Monday, January 30, 2012 3:35 PM
To: Paul Lambert
Cc: [email protected]; [email protected]
Subject: Re: [paws] Threats, Services and Predicatable Availability
Sorry to keep on on the same thing, but it doesn't seem
to be resonating much;-)
The charter says: "Robust privacy and security mechanisms
are needed..."
I'm guessing its possible an analysis starting from your
suggestions below should produce a good result wrt security
but maybe less so for privacy (which is less well
understood by us all).
How about adding "Prevent unnecessary exposure of
personally identifying information (PII)" ?
Note that the above could me met via encryption of
PII, (with possibly high-cost key management) or by
just not sending PII when you don't need to which is
fairly cheap if you're not forced by regulation to
send it. (Since some devices presumably are not
personally identifying but others are, then maybe
there's a simple enough answer in the end...)
S
On 01/30/2012 10:29 PM, Paul Lambert wrote:
Hi Raj,
Do you have any proposals or text w.r.t the threat model writeup?
Also
>from an IETF perspective regarding threat models, please see Peter's
email: http://www.ietf.org/mail-
archive/web/paws/current/msg00592.html
-Raj
I'll spend a little time formalizing the ideas I submitted below.
However, "threats" are part of a complete set of requirements and
looking at the current proposal, I feel we need to clarify the service
that we offer before we can say what are real threats. Specifically,
the threat:
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.
This is not a threat as worded... but why?
We need to define what we offer, and then things that prevent or break
these offered services are potential risks that can be mapped to
threats. As a start, I propose (which I hope is mostly in line with the
use cases) two main services with some subtopics:
1) Prevent Interference of License-exempt Use with Licensed Operation
- Support changes in channel, time Period and region for licensed
operation
- Support predictable availability of licensed channels
- Support the ability to disable specific vendor/model-types from
operation when
they are determined to be causing interference
2) Enable Authorized Channel Utilization for License-exempt Operation
- Facilitate fixed use of channels
- Facilitate mobile use of channels
- Facilitate indoor use of channels
- Support predictable availability of license-exempt channels
- Support changing of authorized channels to prevent interference
with licensed usage
So, threat event is something that has a result of preventing the
promised services. The threat event either causes unapproved
interference with licensed operation, or it prevents White Space
"license-exempt" operation.
The "Support Predictable Availability" is something new I'd like to
introduce for discussion. There needs to be a expectation that once you
are using a channel that your use will not be terminated abruptly in an
unanticipated manner. Right now - we are creating mechanism to quickly
cutoff a device for any reason at all (for the use case of mobile
microphones). This is actually supposed to be a predictable event with
some type of scheduling. An license-exempt devices needs to be able to
determine how long it might operate under the regulations in a
particular channel/region. Building a system where you never know when
your communications might get cut off seems like a bad idea.
Paul
On 1/27/12 5:24 PM, "ext Paul Lambert"<[email protected]> wrote:
It's good to have requirements based on such an analysis. This is
an
interesting start, but we may be mixing threats, vulnerabilities and
mechanisms.
Threats are typically tied to an actor ... human or not. I'm not
sure
it's worth going hard over to something like the NIST 800-30
definitions
of threats, but within this framework the threats are Governments,
disgruntled insiders, tsunamis etc. Being the IETF we can jump more
quickly to the threat event and specifics of an attack, but should
at
least expand threats to include natural events and connectivity
problems.
Robustness or emergency modes might be interesting to consider.
We also have a problem in this analysis of perspective - are we
considering threats as viewed from regulatory agency or the end
device
owner or both. We should consider both - but they are contradictory
perspectives. Users want continuity of service. Governments (the
regulators) want control of the airwaves.
Most of the real threats that we have are nearly impossible to
prevent
at
the protocol level. It's still worth examining the threats to see
where
we stand.
On the current document threats:
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.
This does not seem consistent with the prior statement of "not
compromised".
Restatement
Threat: User modifies a device to masquerade as another valid
certified
device.
This is an interesting case where threat/vulnerability/risk play
together. The FCC or other regulatory agencies want traceability of
devices. If a user wants to run a rogue radio, there is no reason
to
access the database (low risk - no payoff). The only reason this
would
be an interesting attack might be to avoid tracking and have some
anonymity.
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.
I think this is two types of threat events:
- malicious denial of service or intentional interference with
incumbents
- impersonation of white space database to enable operation of a
device
that may
not otherwise be possible (blocked device, unallocated channels).
This may or may not
interfere with incumbent devices
Threat 3: Modifying a query request
...
Threat 4: Modifying a query response
Seems like these two could be lumped together ...MiTM modifies
protocol
messages to:
- deny service
- interfere with incumbents
- provide unauthorized channel usage (most likely risk IMHO)
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.
As stated this is a mechanism - a clearer statement might be.
Threat: Unauthorized use of channels by an uncertified device.
Anyone can already go to a database and find available channels. If
a
device can operate without going to the database there is nothing
that
paws can do to stop it operating in available or non-available
channels.
Just to get some discussion going -here's a couple more possible
threats..
Threat: Third party tracking of white space device location
Likely a valuable commodity to sell for advertizing with no
technical
design or policy for privacy
Threat: Database owner termination of device service for reasons
other
than incumbent protection
Paul
_______________________________________________
paws mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/paws
