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

From: Stephen Farrell <[email-masked]>
Date: Wed, 01 Feb 2012 10:39:18 +0000

On 02/01/2012 01:22 AM, Rosen, Brian wrote:
> 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.

Right. I guess this work might or might not (I dunno)
require something different or additional in terms of
TLS server identity checking but that could be figured
out later.

S

>
> 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