Subject: [paws] Threat model

From: <[email-masked]>
Date: Fri, 27 Jan 2012 19:39:00 +0000

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.

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 27 Jan 2012 14:49:38 -0500

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-masked] wrote:
> _______________________________________________
> paws mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/paws
>

---

From: <[email-masked]>
Date: Fri, 27 Jan 2012 20:01:14 +0000

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

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 27 Jan 2012 15:08:07 -0500

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-masked] wrote:
> On 1/27/12 1:49 PM, "ext Joel M. Halpern"<[email-masked]>  wrote:
>
>> Most of this looks good.

---

From: Peter Saint-Andre <[email-masked]>
Date: Fri, 27 Jan 2012 13:30:36 -0700

<hat type='individual'/>

> derived from this threat model.

As always, it can be helpful to revisit RFC 3552 and look at some other
protocol specifications that describe threat models (e.g., RFC 3833).

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: <[email-masked]>
Date: Fri, 27 Jan 2012 21:48:46 +0000

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-masked]> wrote:

>>>> section of the Use-case and Requirements I-D. Security requirements
>>>>can
>>>> be

---

From: <[email-masked]>
Date: Fri, 27 Jan 2012 21:57:05 +0000

Thanks for the pointers.

The proposed threat model for PAWS is specifically dealing with the
following aspect mentioned in Sec 3 of RFC3522:
"
   By contrast, we assume that the attacker has nearly complete control
   of the communications channel over which the end-systems communicate.
   This means that the attacker can read any PDU (Protocol Data Unit) on
   the network and undetectably remove, change, or inject forged packets
   onto the wire.  This includes being able to generate packets that
   appear to be from a trusted machine.  Thus, even if the end-system
   with which you wish to communicate is itself secure, the Internet
   environment provides no assurance that packets which claim to be from
   that system in fact are.

"

The intent is to derive a set of requirements that are applicable for the
protocol between the master device and the white space database. Most of
the actual security work itself will be done in the solution
specifications.

-Raj

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 27 Jan 2012 16:58:23 -0500

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-masked] wrote:
> On 1/27/12 2:08 PM, "ext Joel M. Halpern"<[email-masked]>  wrote:
>

---

From: <[email-masked]>
Date: Fri, 27 Jan 2012 22:10:58 +0000

That¹s fine. If we as a group agree that this is not a threat that we need
to be concerned about, then we do not need a requirement for encryption of
the request/response messages.

-Raj

On 1/27/12 3:58 PM, "ext Joel M. Halpern" <[email-masked]> wrote:

>>>> Threat 5 is about master devices which have not been
>>>>approved/certified
>>>> by
>>>>>> While discussing the requirements we concluded that it would be
>>>>>>useful
>>>>>> to
>>>>>>           replaying the stolen authentication/authorization secrets
>>>>>>to
>>>>>> a
>>>>>>           white space database.
>>>>>>
>>>>>>           which can confirm the validity/authenticty of the
>>>>>>database.
>>>>>> An
>>>>>>           transmit power or antenna height etc. which could result
>>>>>>in
>>>>>> the
>>>>>>           availability at a location resulting in a denial of
>>>>>>service
>>>>>> to
>>>>>>           the master device.
>>>>>>
>>>>>>           use by the relevant regulatory body. The attacker may
>>>>>>listen
>>>>>> to

---

From: "Rosen, Brian" <[email-masked]>
Date: Fri, 27 Jan 2012 17:21:00 -0500

I don't think we have a use case that would have such a requirement, but I'd like to make sure we don't preclude it.

Here is a use case:

Law Enforcement or other security people on an ad-hoc network.  Any communication would provide information useful to an eavesdropper.

I don't think we should add that use case, just to get the encryption requirement.  What we have is a authentication and integrity protection requirement.  The solutions we have for those also allow encryption (like TLS/DTLS).

Brian

---

From: Paul Lambert <[email-masked]>
Date: Fri, 27 Jan 2012 15:24:52 -0800

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.  

>       replaying the stolen authentication/authorization secrets to a
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.

>       result in the master device causing interference to the primary

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)

>       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

---

From: <[email-masked]>
Date: Mon, 30 Jan 2012 17:54:15 +0000

Hi Brian,

I don’t know if there are any requirements from a law-enforcement
perspective in the FCC recommendations or Ofcom consultations. So while
the law-enforcement use-case is good, I am not sure if we should include
it in the I-D yet as another use case in the set.

-Raj

On 1/27/12 4:21 PM, "ext Rosen, Brian" <[email-masked]> wrote:

>I don't think we have a use case that would have such a requirement, but
>I'd like to make sure we don't preclude it.
>
>Here is a use case:
>
>Law Enforcement or other security people on an ad-hoc network.  Any
>communication would provide information useful to an eavesdropper.
>
>I don't think we should add that use case, just to get the encryption
>requirement.  What we have is a authentication and integrity protection
>requirement.  The solutions we have for those also allow encryption (like
>TLS/DTLS).
>
>Brian
>
>>>>>> What threat 5 essentially implies in terms of security requirements
>>>>>>is
>>>>>> the
>>>>>>> I can imagine privacy-driven confidentiality with regard to
>>>>>>>requests.
>>>>>>> I

---

From: <[email-masked]>
Date: Mon, 30 Jan 2012 17:57:18 +0000

Hi Paul,

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

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

---

From: Paul Lambert <[email-masked]>
Date: Mon, 30 Jan 2012 14:29:13 -0800

Hi Raj,

>>>       replaying the stolen authentication/authorization secrets to a

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

>> - impersonation of white space database to enable operation of a
>device
>>that may
>>   Likely a valuable commodity to sell for advertizing with no
>technical
>>design or policy for privacy

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 30 Jan 2012 23:35:14 +0000

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:
>> On 1/27/12 5:24 PM, "ext Paul Lambert"<[email-masked]>  wrote:
>>

---

From: Paul Lambert <[email-masked]>
Date: Mon, 30 Jan 2012 18:35:59 -0800

>-----Original Message-----
>From: Stephen Farrell [mailto:[email-masked]]
...
>personally identifying information (PII)" ?

Excellent idea.  As you state it, this works for both database and user devices.  

>there's a simple enough answer in the end...)

Seems like a encrypted tunnel (TLS, IPsec, etc) would prevent MiTM viewing of PII.
 - don't send PII
 - encrypt/mask PII
 - encrypt message end-to-end between ... hum, is a master a potential adversary?
   maybe I see where you were going with the field encryption
   Master-to-DB TLS/IPSec whatever is adequate
   Client-through-Master-to-DB is a little more difficult to ensure PII privacy

Database use and of PII is a difficult topic.  Not sure if we should facilitate users authorization or controlled release of their information.  The PAWS protocol could perhaps have bits that express a requested policy (disclose or not).  Enforcement would be left to trusting the DB to do the right thing with the request.

Paul

>> 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:
>>
>> 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:
>>
>> 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
>>
>>
>>>
>>>> Most of the real threats that we have are nearly impossible to
>prevent
>>> at
>>>> Threat: User modifies a device to masquerade as another valid
>certified
>>>> device.
>>>>
>>>> Seems like these two could be lumped together ...MiTM modifies
>protocol
>>>> messages to:
>>>> - deny service
>>>> Threat: Database owner termination of device service for reasons
>other
>>>> than incumbent protection
>>>>
>>>>
>>>>
>>>> Paul
>>>>
>>>>
>>

---

From: Paul Lambert <[email-masked]>
Date: Tue, 31 Jan 2012 11:13:51 -0800

One more observation on threat modeling.  Discovering the database is a service:

4) Support discovery of all authorized databases services for a geographic region.

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.

Paul

>Sent: Monday, January 30, 2012 3:35 PM
>To: Paul Lambert
>Cc: [email-masked]; [email-masked]
>Subject: Re: [paws] Threats, Services and Predicatable Availability
>
>

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 31 Jan 2012 22:54:41 +0000

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

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

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