Subject: Re: [paws] Threats, Services and Predicatable Availability

From: "Rosen, Brian" <[email-masked]>
Date: Tue, 31 Jan 2012 20:22:44 -0500

We have nice tools to discover the right database.  I don't think we will need to use anything but LoST, RFC5222, to discover the right one.  Query with your location and a service urn related to the type of device/band/whatever and get back a list of URIs to the database.  It's the base of emergency call routing, another government service, so making it secure should be straightforward.

Brian

 -----Original Message-----
From: 	Stephen Farrell [mailto:[email-masked]]
Sent:	Tuesday, January 31, 2012 05:55 PM Eastern Standard Time
To:	Paul Lambert
Cc:	[email-masked]
Subject:	Re: [paws] Threats, Services and Predicatable Availability

On 01/31/2012 07:13 PM, Paul Lambert wrote:
>
> One more observation on threat modeling.  Discovering the database is a service:
>
> 4) Support discovery of all authorized databases services for a geographic region.

Good one. (And presumably withstanding related spoofs will turn out to
be desired too.)

> Associated threat event would be:
>   - Modification of paws protocol messages in transit to prevent discovery of authorized databases
>
>
> When there are multiple authorized database services we need to make sure that all authorized services are available to end devices.
>
> This implies a trust hierarchy with the regulatory authority (Gov based) as a root for a region. New regions are not going to be easy to add ...  which is good since any new region also requires some level of regional conformance.

Well, a hierarchy is a design choice for later I guess. (But clearly
one that'll be a natural idea for some of the involved parties.)

S

>
> Paul
>
>
>
>> -----Original Message-----
>> From: Stephen Farrell [mailto:[email-masked]]
>> Sent: Monday, January 30, 2012 3:35 PM
>> To: Paul Lambert
>> Cc: [email-masked]; [email-masked]
>> 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-masked]>   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-masked]
>>> https://www.ietf.org/mailman/listinfo/paws
>>>
>
_______________________________________________
paws mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/paws