Subject: Re: [paws] Threat model

From: <[email-masked]>
Date: Thu, 2 Feb 2012 18:36:06 +0000

The discussions on this mail thread have slowed down.
Raj, can you implement the comments received on the list so far and post the text again for further input?
- Gabor

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Patil Basavaraj (Nokia-CIC/Dallas)
Sent: Monday, January 30, 2012 9:57 AM
To: [email-masked]; [email-masked]
Subject: Re: [paws] Threat model

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

---

From: <[email-masked]>
Date: Thu, 2 Feb 2012 20:30:26 +0000

Hi Paul, 

Comment inline:

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

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

Raj> The context and scope of this threat analysis is limited to the
protocol and communication between a master device and the white space
database. What you are proposing above is a much broader scope in terms of
the white space technology itself. We need to limit our scope to the
protocol aspect here and that is what the proposed threat analysis is
intended to do.

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

Raj> Okay. 

> - malicious denial of service or intentional interference with incumbents
> - impersonation of white space database to enable operation of a device
>that may 

Raj> Okay. Will add the additional consequences text.

> - provide unauthorized channel usage (most likely risk IMHO)

Raj> Will keep them separate for now and see if there is a significant
overlap.

>Threat: Unauthorized use of channels by an uncertified device.

Raj> Okay.

>paws can do to stop it operating in available or non-available channels.

Raj> Sure. But regulation requires a certain behavior. Anything outside
that expected behavior is illegal and PAWS cannot do anything about that.

>   Likely a valuable commodity to sell for advertizing with no technical
>design or policy for privacy

Raj> Okay. Will add these to the next rev. Please review and provide
additional text when I post the revised threat analysis shortly.

Thanks for your comments. Appreciate your help in improving the text.

-Raj

---

From: <[email-masked]>
Date: Thu, 2 Feb 2012 20:37:07 +0000

Based on comments received from Paul and others I have updated the threat
analysis text. Please review and comment.

-Raj

Rev 2 (2/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.

Threat 1: User modifies a device to masquerade as another valid
       certified device

       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.

       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

       A master device needs to provide its location to the white
       space database in order to obtain the channel availability
       information at that location. Such location information can be
       gleaned by an eavesdropper. A master device may prefer to keep
       the location information secret. Hence the protocol should
       provide a means to protect the location information and prevent
       tracking of locations associated with a white space database.

Threat 7: Database owner 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 messages to a master
       device. This results in denial of service to the master
       device.

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 02 Feb 2012 20:48:40 +0000

Pretty good overall. I'll keep on my usual track since I seem
stuck on it here;-)

>         tracking of locations associated with a white space database.

What's wrong with not wanting the DB to track me (as a master
device)? Could be that current known regulators don't like
anonymous masters, but that may change. (So I think 3rd party
here is wrong.)

Why is it only location tracking that's of concern? Why is
exposing identity not an equal deal? Same logic as above.

S.

---

From: <[email-masked]>
Date: Thu, 2 Feb 2012 20:53:26 +0000

>anonymous masters, but that may change. (So I think 3rd party

The issue is not with the database tracking your location. It is a a
malicious node which could be eavesdropping on the link between the master
device and the database. The database will always have the master device's
location. Whether it saves that location is an orthogonal issue, but its
not the one that is captured in this threat.

>exposing identity not an equal deal? Same logic as above.

The concern is not about exposing location of identity to the white space
database.

-Raj

---

From: Nancy Bravin <[email-masked]>
Date: Thu, 2 Feb 2012 12:57:14 -0800

Guys, 

I think given the Global community that will be using this Protocol,

---

From: Nancy Bravin <[email-masked]>
Date: Thu, 2 Feb 2012 12:59:35 -0800

oops sorry I was about to say what Raj just said…ditto. Nancy

---

From: <[email-masked]>
Date: Thu, 2 Feb 2012 21:39:38 +0000

I think that's a different threat from the one addressed below in threat 6.

If in a regulatory domain the DB requires the master to provide its identity, then there's nothing to be done to prevent tracking of the masters by the DB. But if some other regulatory domain will not require the master to send its identity when querying the DB, the master may decide not to send its identity, to prevent the DB to track it.

We could add this as another threat.

- Gabor

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of ext Stephen Farrell
Sent: Thursday, February 02, 2012 12:49 PM
To: Patil Basavaraj (Nokia-CIC/Dallas)
Cc: [email-masked]
Subject: Re: [paws] Threat model (Rev 2)

Pretty good overall. I'll keep on my usual track since I seem stuck on it here;-)

>         tracking of locations associated with a white space database.

What's wrong with not wanting the DB to track me (as a master device)? Could be that current known regulators don't like anonymous masters, but that may change. (So I think 3rd party here is wrong.)

Why is it only location tracking that's of concern? Why is exposing identity not an equal deal? Same logic as above.

S.

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 3 Feb 2012 09:30:36 +0000

> If in a regulatory domain the DB requires the master to provide its identity, then there's nothing to be done to prevent tracking of the masters by the DB. But if some other regulatory domain will…

That's precisely what I think needs to be remembered and taken into account in developing the protocol

> We could add this as another threat.

Sure, or modify the existing one, I've no strong opinion,

S

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 3 Feb 2012 09:36:11 +0000

Hi,

> The concern is not about exposing location of identity to the white space

It seems like you're maybe conflating location and identity above, not sure. But those are different and will need to be differentiated in the protocol, and hence also in the requirements,

S

---

From: <[email-masked]>
Date: Fri, 3 Feb 2012 19:34:03 +0000

Below is Rev 3 of the threat model based on feedback from Stephen, Nancy
and Gabor (Thanks).

-Raj

Rev 3 (3/2/12)

Assumptions:
............

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.

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 03 Feb 2012 14:51:17 -0500

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

---

From: "Rosen, Brian" <[email-masked]>
Date: Fri, 3 Feb 2012 14:55:49 -0500

<as individual>
Where do you see this assumption in the threat model?

I took a quick look and didn't spot it.  It would be "database information leaked to bad guys" or something like it, right?

I don't think that is a threat, and I don't think we need to protect anyone from that threat.

I would say, however, that if you could know the content of the database, and you can observe a responses over a period of time, you may be able to infer the location of the querier.

Brian

---

From: <[email-masked]>
Date: Fri, 3 Feb 2012 19:57:39 +0000

Hi Joel,

Do you want to propose some text that I could include as part of the
assumptions in the threat analysis section?
The intent of this threat analysis text is to include it as a subsection
of the security considerations section.

-Raj

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 03 Feb 2012 15:00:41 -0500

In the unauthorized use section, there is still the text saying:
        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.

I still find this totally mind-bending, as it is about the hardest way 
imaginable to undertake this attack.

---

From: "Rosen, Brian" <[email-masked]>
Date: Fri, 3 Feb 2012 15:11:32 -0500

Huh, since that section was about misuse of channel data, I missed the point you were making.

So, should we get rid of that use case (leaving the Law Enforcement case)?

It does seem to me that if a rogue device existed, it would ignore the database rather than eavesdrop.

One thing we may wish to consider that got triggered by this exchange -
the database may be operated by a commercial entity.  That entity may wish to restrict access to only authorized users.  That means there is some kind of identity/authorization requirement, with a threat of theft of service.

Brian

---

From: <[email-masked]>
Date: Fri, 3 Feb 2012 20:19:22 +0000

Inline:

On 2/3/12 2:11 PM, "ext Rosen, Brian" <[email-masked]> wrote:

>the database may be operated by a commercial entity.  That entity may
>wish to restrict access to only authorized users.  That means there is
>some kind of identity/authorization requirement, with a threat of theft
>of service.

Threat 1 sort of implies the need for identity/authorization. That is
essentially the requirement that I was hoping would fall out of that
description. The protocol needs to be capable of an eavesdropper from
replaying credentials of a valid master device.
It could be expanded to cover what you state above.

-Raj

---

From: <[email-masked]>
Date: Fri, 3 Feb 2012 20:31:27 +0000

How about the following revised text for Threat 1:

       Regulatory environments require that devices be certified and
       register in ways that accurately reflect their certification.
       Without suitable protection mechanisms, devices could simply
       listen to registration exchanges, and later registering
       claiming to be those other devices. Such replays would allow
       fasle registration, violating regulatory regimes.
       A white space database may be operated by a commercial entity
       which restricts access to authorized users. A master device
       needs to identify itself to the database and be authorized to
       obtain information about available channels.

---

From: "Rosen, Brian" <[email-masked]>
Date: Fri, 3 Feb 2012 15:32:51 -0500

WFM

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 3 Feb 2012 20:47:53 +0000

Isn't "needs to" wrong? "MAY need to" would seem much better 

S

---

From: <[email-masked]>
Date: Fri, 3 Feb 2012 20:50:55 +0000

Agree. 
S/A master device needs to identify itself to the database and be
authorized to
      obtain information about available channels./A master device
      May need to identify itself to the database and be authorized to
      obtain information about available channels.

---

From: Paul Lambert <[email-masked]>
Date: Fri, 3 Feb 2012 14:26:05 -0800

>>>         device. This results in denial of service to the master

No clue what you mean by "malicious node" ... this could be a Database, Master, random MiM, etc. 

I was really thinking more about the misuse of the Database, or Master to:
 - turn off devices presumed to be violating the DCMA
 - limiting spectrum usage based on the type or purpose of the traffic (e.g. Oakland BART)
 - limitation of spectrum usage based on political affiliation, race, gender, ideology, 
   individual identity, etc.

We may not be able to prevent (at a protocol level) unfair allocation or disablement. We should at least be able to have adequate logging and records that given an expectation of fair allocation - we can detect and complain when our mobile devices are turned off.

Paul

>From: [email-masked] [mailto:[email-masked]] On Behalf Of
>Joel M. Halpern
>Sent: Friday, February 03, 2012 12:01 PM
>To: Rosen, Brian
>Cc: [email-masked]
>Subject: Re: [paws] Threat model (Rev 3)
>
>> I took a quick look and didn't spot it.  It would be "database
>information leaked to bad guys" or something like it, right?
>>
>> I would say, however, that if you could know the content of the
>database, and you can observe a responses over a period of time, you may
>be able to infer the location of the querier.
>>
>> Brian
>>
>>

---

From: <[email-masked]>
Date: Fri, 3 Feb 2012 22:35:15 +0000

Hi Paul.

>No clue what you mean by "malicious node" ... this could be a Database,

My interpretation of the additional threat you had suggested in a previous
emailŠ.
The point about this threat is that we have discussed about the
possibility of the database having the capability to send an unsolicited
push notification (to the master device) for revoking the previously
allocated channels and ceasing operation.
So the "malicious node" in this case is an entity which pretends to be the
database and sends such a push notification message to the master device.

> - turn off devices presumed to be violating the DCMA

DCMA?
The aspect of a device being switched off is covered in this threat.

>   individual identity, etc.

I don't get the above two. Care to expand on these?

>
>We may not be able to prevent (at a protocol level) unfair allocation or
>disablement. We should at least be able to have adequate logging and
>records that given an expectation of fair allocation - we can detect and
>complain when our mobile devices are turned off.

So do we need to capture this in the form of a threat? Do we want to have
a requirement that the protocol needs to enable logging and record
keeping? That¹s more of an implementation issue.

-Raj

---

From: Paul Lambert <[email-masked]>
Date: Fri, 3 Feb 2012 14:58:11 -0800

Hi Raj,

First - a threat needs an actor or source.  We seem to have different views of possible sources.

>>>>> Threat 7: Termination of device service for reasons other than
Termination of device service is the end-impact (a useful starting point, but not exactly the threat). 

Some of the associated threat events are:

 a) Government (related to regulatory authority or not) uses WS Database to terminate or unfairly limit
    spectrum access of devices for reasons other than incumbent protection.
 b) Service provider or DB provider uses WS Database to terminate or unfairly limit
    spectrum access of devices for reasons other than incumbent protection.
 c) Owner of a Master device uses WS Database to terminate or unfairly limit
    spectrum access of devices for reasons other than incumbent protection.
 d) Malicious individual acts as a PAWS entity (spoofing DB or as MiM) to terminate or unfairly limit
    spectrum access of devices for reasons other than incumbent protection
 e) Natural disaster knocks out communications to the database preventing spectrum access.

It seems silly for us to rush so quickly into building the fastest possible kill switch for communications.  Push notifications are a cool mechanisms, but we also need some level of assurance that we will have continuity of usage of a set of channels.  Ideally we'd have some looser limits on the on-channel times. 

Paul

>From: [email-masked] [mailto:[email-masked]]
>Sent: Friday, February 03, 2012 2:35 PM
>To: Paul Lambert; [email-masked]; [email-masked]
>Cc: [email-masked]
>>>>> But I am still trying to get my head around this.  There are going
>to
>>>be
>>>>>>         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
>>>>>>         private. A malicious device should not be able to
>eavesdrop
>>>on
>>>>>>         such communications.
>>>>>>
>>>>>>         regulations do not require the identity of the master
>device
>>>to

---

From: Paul Lambert <[email-masked]>
Date: Fri, 3 Feb 2012 15:03:32 -0800

> Threat 3: Modifying a query response

Not a threat ... perhaps a vulnerability if restated.  
Suggest as a mechanism - any modification or spoofing of paws messages all look about the same from the threat model. It's the actor, and end impact that is interesting.

Paul

>[email-masked]
>Sent: Friday, February 03, 2012 11:34 AM
>To: [email-masked]; [email-masked]

---

From: Paul Lambert <[email-masked]>
Date: Fri, 3 Feb 2012 15:19:29 -0800

>As such, what is the role of confidentiality with regard to this

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

>Sent: Friday, February 03, 2012 11:51 AM
>To: [email-masked]
>Cc: [email-masked]

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 03 Feb 2012 23:42:32 +0000

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.

---

From: Nancy Bravin <[email-masked]>
Date: Fri, 3 Feb 2012 15:49:25 -0800

I am in favor of a kill switch, and agree with Paul, further, the scenarios must be severe to cut communications totally, or they are cut as  in e) where there is no access. Any other potential
threats can be defined that warrant its use as he has, to me, explained well. 

Sincerely, Nancy

---

From: Paul Lambert <[email-masked]>
Date: Fri, 3 Feb 2012 17:43:43 -0800

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

>Stephen Farrell
>Sent: Friday, February 03, 2012 3:43 PM
>To: [email-masked]
>Subject: [paws] wondering why a device identifier is needed (was: Re:
>Threat model (Rev 3))
>
>
>> 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.
>>
>to a

---

From: <[email-masked]>
Date: Sat, 4 Feb 2012 02:03:05 +0000

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

Kind Regards,
Scott

On 2/3/12 7:43 PM, "ext Paul Lambert" <[email-masked]> 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
>
>

---

From: Peter Stanforth <[email-masked]>
Date: Sat, 4 Feb 2012 08:30:07 -0500

Section 4.1.2 below describes the registration protocol

4.1.2. Device registration with trusted Database

<Delete>This use case</Delete><Insert>Registration</Insert> is
preliminary to creating a radio network using <Delete>TV</Delete>
white space; it is a prerequisite to
<Delete>other</Delete><Insert>the</Insert> use cases
<Insert>below</Insert>. The radio
network is created by a master device. Before the master device can
transmit in <Delete>TV</Delete> white space spectrum, it must contact a
trusted
database where the device can learn if any channels are available for
it to use. Before the database will provide information on available
<Delete>TV</Delete><Insert>radio</Insert> channels, the master device
must register with the trusted
database. Specific requirements for registration come from
individual regulatory domains and may be different.

This does not include any acknowledgement. This is something we do support in our FCC protocol. The reason being so we can accurately inform the device if the registration attempt fails. Listed below are some of the reasons, though I am sure there are more, we consider returning a failure code to the device:

malformed request (e.g., required fields missing)
FCC identifier not recognized or supported
FCC designated no channels available
location outside of regulatory domain
antenna height above 30 meters
HAAT above 76 meters

---

From: Stephen Farrell <[email-masked]>
Date: Sat, 04 Feb 2012 15:25:18 +0000

Hi Scott,

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

> '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-masked]>  wrote:
>
>>
>> Good question.
>>
>>> It does also interact with privacy&  security of course.

---

From: <[email-masked]>
Date: Mon, 6 Feb 2012 20:29:35 +0000

Hi Peter,

Good comment. I will add another step to the registration service, step 3, to include an acknowledgement from the database to the master, with a result code.

Kind Regards,
Scott

From: "ext com>" <[email-masked]<mailto:[email-masked]>>
Date: Sat, 4 Feb 2012 08:30:07 -0500
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: [paws] registration protocol

_______________________________________________ paws mailing list [email-masked]<mailto:[email-masked]> https://www.ietf.org/mailman/listinfo/paws

---

From: Paul Lambert <[email-masked]>
Date: Mon, 6 Feb 2012 12:57:02 -0800

>Device manufacturers are interested in ability to switch off stolen

No.  This is not a valid use case for a license exempt usage of a regulatory database.  Any payment system or authorization to use a device outside of the regulatory limitations should not be part of the regulatory focused protocol.

How would a device manufacture contact a regulatory authority to "kill" a device?
How would a user report a stolen device?
How would you prevent incorrect reports of stolen devices being used to shut off a device.

Why do we need a kill switch for a single non-conforming device - when the certification is for a device class.  If one device is interfering, it's likely all like device types would interfere at the same location.  The enabled region could be changed, or the device type black listed.

If a device is able to operate in a manner that ignores the database, than it may interfere, but would not be able to "killed" since it is already ignoring the database.

The is a history of needing unique identifiers for licensed devices.  Correct operation for most licensed devices is based on human configuration and correct usage of the system.  A unique identifier is required to allow such human controlled usage to be tracked and action taken if the device operates outside of it's license considerations.

"killing devices" should not be a mandatory feature of the paws protocol and should only be based a model of the regulatory requirements for a region.

Unique device identifiers shoul also be optional.

Paul

>From: [email-masked] [mailto:[email-masked]]
>Sent: Friday, February 03, 2012 6:03 PM
>To: Paul Lambert; [email-masked]; [email-masked]
>Subject: Re: [paws] wondering why a device identifier is needed (was:
>Re: Threat model (Rev 3))
>
>Hi,
>
>>>>> From: [email-masked] [mailto:[email-masked]] On
>Behalf
>>>Of
>>>>> Joel M. Halpern
>>>>>>          channels or max transmit power allowed. The result of
>such
>>>an
>>>>>>          attack is that the master device would cause
>intereference
>>>to
>>>>>>          space database to a master device. The channel
>information
>>>or

---

From: <[email-masked]>
Date: Mon, 6 Feb 2012 21:12:29 +0000

Hi Paul,

I am not proposing a use case, merely replying to Stephen's side-issue.

Kind Regards,
Scott

On 2/6/12 2:57 PM, "ext Paul Lambert" <[email-masked]> wrote:

>No.  This is not a valid use case for a license exempt usage of a
>regulatory database.  Any payment system or authorization to use a device
>outside of the regulatory limitations should not be part of the
>regulatory focused protocol.
>
>Why do we need a kill switch for a single non-conforming device - when
>the certification is for a device class.  If one device is interfering,
>it's likely all like device types would interfere at the same location.
>The enabled region could be changed, or the device type black listed.
>
>If a device is able to operate in a manner that ignores the database,
>than it may interfere, but would not be able to "killed" since it is
>already ignoring the database.
>
>The is a history of needing unique identifiers for licensed devices.
>Correct operation for most licensed devices is based on human
>configuration and correct usage of the system.  A unique identifier is
>required to allow such human controlled usage to be tracked and action
>taken if the device operates outside of it's license considerations.
>
>"killing devices" should not be a mandatory feature of the paws protocol
>and should only be based a model of the regulatory requirements for a
>region.
>

---

From: <[email-masked]>
Date: Tue, 7 Feb 2012 22:45:02 +0000

Minor rewording of threat 6:

"A white space database in a regulatory domain 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 and used for tracking purposes. A master device may prefer to keep the location/identity information hidden from eavesdroppers, 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 query. 
When the master device sends both its identity and location to the DB, the DB is able to track it. If a regulatory domain does not require the master device to provide its identity to the white space database, the master device may decide not to send its identity, to prevent being tracked by the DB."

- Gabor

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Patil Basavaraj (Nokia-CIC/Dallas)
Sent: Friday, February 03, 2012 11:34 AM
To: [email-masked]; [email-masked]
Subject: Re: [paws] Threat model (Rev 3)

Below is Rev 3 of the threat model based on feedback from Stephen, Nancy and Gabor (Thanks).

-Raj

Rev 3 (3/2/12)

Assumptions:
............

---

From: <[email-masked]>
Date: Wed, 8 Feb 2012 22:00:28 +0000

Hi Paul,

>but not exactly the threat).

Assuming that there exists the ability to send an unsolicited push
notification to the master device to curtail service from the database,
the threat here is the possibility of an attacker sending such a message
to a master device.
Of course the protocol could be designed to ensure that the master device
verifies the message for authenticity etc., but the threat itself exists.

>It seems silly for us to rush so quickly into building the fastest
>possible kill switch for communications.  Push notifications are a cool
>mechanisms, but we also need some level of assurance that we will have
>continuity of usage of a set of channels.

We previously discussed the need for a kill switch and my recollection is
that it is a nice-to-have feature and not something that is mandatory.
Regulatory environments will choose to define whether it is required or
not.  The threat described in (7) is simply based on the assumption of
such a feature existing.

-Raj

>Ideally we'd have some looser limits on the on-channel times.
>
>Paul
>
>
>

---

From: <[email-masked]>
Date: Wed, 8 Feb 2012 22:02:42 +0000

Inline: 

On 2/3/12 5:03 PM, "ext Paul Lambert" <[email-masked]> wrote:

>Suggest as a mechanism - any modification or spoofing of paws messages
>all look about the same from the threat model. It's the actor, and end
>impact that is interesting.

The point with this threat (or vulnerability if you wish) is to derive a
requirement for the protocol to ensure integrity protection for the
request/response messages. And the same applies to Threat 4.

-Raj

---

From: Paul Lambert <[email-masked]>
Date: Wed, 8 Feb 2012 14:28:51 -0800

Hi Raj,

...
>>Termination of device service is the end-impact (a useful starting
>point,
>>but not exactly the threat).
>
[Paul]
You missed my point below.  There are many sources of threats.  Not all can be directly mitigated by protocol mechanisms, but there may be ways with associated policies, procedures and agreements to limit the impact.

If we are performing a threat analysis we should look at the full suite of threats.

Paul

>> a) Government (related to regulatory authority or not) uses WS
>Database
>>to terminate or unfairly limit
>> d) Malicious individual acts as a PAWS entity (spoofing DB or as MiM)
>to
>>terminate or unfairly limit
>> e) Natural disaster knocks out communications to the database
>preventing
>>spectrum access.
>>
>>
>>>>No clue what you mean by "malicious node" ... this could be a
>Database,
>>>>Master, random MiM, etc.
>>>
>>>>I was really thinking more about the misuse of the Database, or
>Master
>>>to:
>>>> - limiting spectrum usage based on the type or purpose of the
>traffic
>>>>(e.g. Oakland BART)
>>>>>> I don't think that is a threat, and I don't think we need to
>protect
>>>>>anyone from that threat.
>>>>>>
>>>>>>>> Below is Rev 3 of the threat model based on feedback from
>Stephen,
>>>>>Nancy
>>>>>>>> and Gabor (Thanks).
>>>>>>>>
>>>>>>>> -Raj
>>>>>>>>
>>>>>>>>
>>>>>>>> Rev 3 (3/2/12)
>>>>>>>>
>>>>>>>>         device to a white space database. The attacker may
>change
>>>>>the
>>>>>>>>         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.
>>>>>>>>
>>>>>>>>         An attacker may be a master device which is not
>certified
>>>>>for
>>>>>>>>         the communication between a valid master device and
>white
>>>>>space
>and
>>>>>identity
>>>>>>>>         and channels allocated to a master device can be
>revoked.
>>>A

---

From: <[email-masked]>
Date: Thu, 9 Feb 2012 06:02:34 +0000

This is a good point. But from the list provided below, only d) seems to be a security related threat fit to be included into the security considerations section of the draft. The other events look other than security related to me.

If we replace Threat 7 with the text in point d) below, I think we address Paul's point.

s/ Threat 7: Termination of device service for reasons other than incumbent protection./ Threat 7: Malicious individual acts as a PAWS entity (spoofing DB or as MiM) to terminate or unfairly limit spectrum access of devices for reasons other than incumbent protection.

- Gabor

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of ext Paul Lambert
Sent: Friday, February 03, 2012 2:58 PM
To: Patil Basavaraj (Nokia-CIC/Dallas); [email-masked]; [email-masked]
Cc: [email-masked]
Subject: Re: [paws] Threat model (Rev 3)

Hi Raj,

Paul

>>Database, Master, random MiM, etc.
>
>My interpretation of the additional threat you had suggested in a 
>previous emailŠ.
>possibility of the database having the capability to send an 
>unsolicited push notification (to the master device) for revoking the 
>previously allocated channels and ceasing operation.
>So the "malicious node" in this case is an entity which pretends to be 
>the database and sends such a push notification message to the master 
>device.
>
>>
>>
>So do we need to capture this in the form of a threat? Do we want to 
>have a requirement that the protocol needs to enable logging and record 
>>>I still find this totally mind-bending, as it is about the hardest 
>>>way imaginable to undertake this attack.
>>>
>>>
>>>>> confidentiality mechanisms in the solutions.) But I am still 
>>>>> trying to get my head around this.  There are going
>to
>>>be

---

From: <[email-masked]>
Date: Thu, 9 Feb 2012 17:01:08 +0000

Okay. It sounds better.
Revised text is as follows:

Threat 7: Malicious individual acts as a PAWS entity (spoofing DB or
       as MiM) to terminate or unfairly limit spectrum access of devices
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 by
       sending an unsolicited message. A malicious node can pretend to
       be the white space database with which a master device has
       registered or obtained channel information from and send a
       revoke message to that device. This results in denial of
       service to the master device.

-Raj

On 2/9/12 12:02 AM, "ext [email-masked]" <[email-masked]>
wrote:

>This is a good point. But from the list provided below, only d) seems to
>be a security related threat fit to be included into the security
>considerations section of the draft. The other events look other than
>security related to me.
>
>s/ Threat 7: Termination of device service for reasons other than
>incumbent protection./ Threat 7: Malicious individual acts as a PAWS
>entity (spoofing DB or as MiM) to terminate or unfairly limit spectrum
>access of devices for reasons other than incumbent protection.
>
>- Gabor
>
>ext Paul Lambert
>continuity of usage of a set of channels.  Ideally we'd have some looser
>limits on the on-channel times.
>
>Paul
>
>
>

---

From: <[email-masked]>
Date: Thu, 9 Feb 2012 17:04:53 +0000

On 2/8/12 4:28 PM, "ext Paul Lambert" <[email-masked]> wrote:

>[Paul]
>You missed my point below.  There are many sources of threats.  Not all
>can be directly mitigated by protocol mechanisms, but there may be ways
>with associated policies, procedures and agreements to limit the impact.
>

The list in the current threat models text that I proposed is by no means
exhaustiveŠ Or intended to be. The intent is to derive a key set of
security requirements for the protocol. The focus is on those threats that
are relevant to the device-2-database protocol rather than to the much
more expansive topic of white space technology.

-Raj

---

From: Paul Lambert <[email-masked]>
Date: Thu, 9 Feb 2012 13:32:22 -0800

>more expansive topic of white space technology.

Yes, but ...

Without determining if there are technical mitigation mechanisms we should not be rejecting threats.  The threats should all be examined and we should explicitly determine what is in scope versus unilaterally as part of the editing process.

As an interesting example - if there is a natural disaster, should there be protocol mechanisms to enable use of emergency services without direct Internet connectivity to the DB?

Loss of service (emergency and normal) usage of WS is a threat that should be listed and may or may not be addressed by technical or procedural mechanisms.  

Paul

---

From: <[email-masked]>
Date: Fri, 10 Feb 2012 18:09:57 +0000

HI Paul,

On 2/9/12 3:32 PM, "ext Paul Lambert" <[email-masked]> wrote:

>Without determining if there are technical mitigation mechanisms we
>should not be rejecting threats.  The threats should all be examined and
>we should explicitly determine what is in scope versus unilaterally as
>part of the editing process.

No doubt. I don't think there is any unilateral proposal here. I am happy
to incorporate all relevant threats through the consensus process and
discussion on the mailing list. The threat model has evolved from Rev 1 to
Rev 4 as a result of feedback from you and others.

>
>As an interesting example - if there is a natural disaster, should there
>be protocol mechanisms to enable use of emergency services without direct
>Internet connectivity to the DB?

Would you consider this as a threat or a feature that the protocol needs
to be concerned with regarding reachability of the database?

>
>Loss of service (emergency and normal) usage of WS is a threat that
>should be listed and may or may not be addressed by technical or
>procedural mechanisms.

If you can elaborate or (preferably) provide the text describing the
threat and consequences, I would be happy to include it.

-Raj

---

From: Rex Buddenberg <[email-masked]>
Date: Fri, 10 Feb 2012 12:28:50 -0800

Raj, 

I'll try ...

The public safety users of spectrum are very concerned with an issue
they call 'talk around'.  It's not at all defined, but certainly
includes a definition in which internet infrastructure  or simply (in a
single segment net) a base station does not exist.  In IEEE 802
terminology, two erstwhile subscriber stations need to communicate.  

The prism through which most public safety folks look at this is the LMR
radio ... if I have the same freq as the guy over there that I can see
then I can talk with him.  
	Once this migrates to internet, the information power is amplified
enormously, but what happens if I can't see a DNS server or a SIP server
or ...?  The PAWS concern is 'what if I can't see the white space server
in order to get a freq allocation to use'.  

A suitable use case would be a sizable disaster where a lot of internet
infrastructure ceases to function.  Emergency services users need to
reconstitute quickly and they will need radio WANs to do that.  We can
estimate that a lot of radio WAN gear that has been unused suddenly
needs to be pressed into action.   And the radio WANs need frequency
authorizations to function.  

That work?

---

From: <[email-masked]>
Date: Fri, 10 Feb 2012 21:00:46 +0000

Hi Rex,

Thanks for the description. I understand the use case itself better now.
However I am still trying to parse the threat.
In the case of a natural disaster, I can imagine all types of radio
equipment being pressed into use.
So the statement:
"And the radio WANs need frequency authorizations to function."

Is the threat then the inability to reach the entity that authorizes the
use of spectrum?
Is the reachability and inability to obtain authorization a result of a
malicious node preventing such communication?

Rgds,
-Raj

---

From: Rex Buddenberg <[email-masked]>
Date: Fri, 10 Feb 2012 13:16:47 -0800

> Is the threat then the inability to reach the entity that authorizes the

Yes.  

> malicious node preventing such communication?

I did not consider this in the use case.  What I was considering was
that the disaster itself prevented comms, including those to the
whitespace data server ... but not sure it would make a difference.
However I would, in all use cases, consider authenticity of the data
communicated (both ways) to be a requirement.

---

From: Paul Lambert <[email-masked]>
Date: Fri, 10 Feb 2012 13:57:15 -0800

>to be concerned with regarding reachability of the database?

A threat analysis provides requirements that might be met with specific features of technical proposals.  Too often we carry implicit ideas on the features and implementation (like FCC rules, or TLS+509 for all security requirements) that impact our view of the problem area. 

Here specifically (the disaster scenario), we should allow devices (perhaps only empowered emergency service devices) to continue to use spectrum when the database is not available due to a natural disaster. 

Since we are all looking at what this would mean for a protocol mechanism - the implication is that we need to support more than one type of policy for enabling transmission.  The ".. stop immediately if you've not been enabled in the last 60 seconds ..." model may be one approach, but if we are trying to plan for the future and develop a robust communication technology, then we need to have protocol mechanism that indicates differences in the application of policies.  Some policies should allow more lenient interpretation of the temporary spectrum usage authorization provided by the DB.  WE should not hard code current FCC rules into devices, but have some ability to 

I'm not at this time proposing a specific mechanism at this time ... just the requirement (in the form of threat models).

>threat and consequences, I would be happy to include it.

I did before ... time permitting I'll resubmit.

Paul

---

From: Paul Lambert <[email-masked]>
Date: Fri, 10 Feb 2012 14:01:56 -0800

>> Is the threat then the inability to reach the entity that authorizes

However - a malicious node blocking communication is a different threat than a natural disaster.

In a natural disaster (or perceived disaster)  it may be possible to allow some devices (like emergency services) more lee-way to not shut down immediately when a database is not accessible.  Some level of default capabilities and channels could be provided.  Authorization or enablement using a lower duty cycle (no push, lower time limits) might be possible.

>communicated (both ways) to be a requirement.

Both prevent access ... but are different scenarios. 

Paul

>> >> >>The list in the current threat models text that I proposed is by
>no
>> >> >>means
>> >> >>security requirements for the protocol. The focus is on those
>threats
>> >> >>that
>> >> >should not be rejecting threats.  The threats should all be
>examined
>> >>and
>> >> discussion on the mailing list. The threat model has evolved from
>Rev 1
>> >>to

---

From: <[email-masked]>
Date: Fri, 10 Feb 2012 23:00:43 +0000

Hi Paul/Rex,

How about adding the following threat to the list:

Threat 8: Natural disaster resulting in inability to obtain authorization
for 
	       spectrum use by emergency responders

In the case of a sizable natural disaster a lot of internet
infrastructure ceases to function.  Emergency services users need to
reconstitute quickly and will rely on establishing radio WANs. The
potential for lot of radio WAN gear that has been unused suddenly
needs to be pressed into action. And the radio WANs need frequency
authorizations to function. Regulatory entities may also authorize
usage of additional spectrum in the affected areas. The white space
radio entities may need to establish communication with a database and
obtain authorizations. Alternatively there may be other mechanisms
which allow the use of spectrum by emergency service equipment without
strict authorization or with liberal interpretation of the regulatory
policy for white space usage.

Please suggest additional text or changes as needed.

-Raj

---

From: Paul Lambert <[email-masked]>
Date: Fri, 10 Feb 2012 15:08:00 -0800

ThanKs ... that catching the concept .. Paul

>Sent: Friday, February 10, 2012 3:01 PM
>To: [email-masked]
>Cc: Paul Lambert; [email-masked]
>>> >> >>are relevant to the device-2-database protocol rather than to
>the
>>>much
>>> >> >we should explicitly determine what is in scope versus
>unilaterally
>>>as
>>> >> No doubt. I don't think there is any unilateral proposal here. I
>am
>>> >>happy
>>> >> >As an interesting example - if there is a natural disaster,
>should
>>> >>there
>>> >> >be protocol mechanisms to enable use of emergency services
>without
>>> >>direct

---

From: Teco Boot <[email-masked]>
Date: Sat, 11 Feb 2012 13:17:18 +0100

Sure this added threat is important for ws users. Not only for 
emergency responders, all users are affected by communication 
breakdown between wsd and wsdb.

Question is: is this a thread on the protocol, or on the whole 
ws system? I think the latter.

If included, I suggest the title: "Inability to obtain authorization
for white spectrum use".

And some text like this:
   The white space model makes use of a more centralized white
   space database an a communication protocol between the
   white space devices and the white space database. In cases
   where communication with the white space database fails,
   the white space devices cannot utilize white space spectrum.
   Emergency services, which require more spectrum precisely 
   on locations where network infrastructure is malfunctioning 
   or overloaded, backup communication channels and distributed 
   white space databases are needed to overcome such circumstances.

The first responders use case already suggests the required
backup facilities (satcom link). It is also deployed that way, but 
I have to agree not everyone pays enough attention (and $€¥) to it.

So yes, adding this threat description may help spending enough money
for it. Or help when we make decisions on wsdb discovery.

Teco

---

From: Nancy Bravin <[email-masked]>
Date: Sun, 12 Feb 2012 05:42:32 -0800

In addition, the protocol should cover if one or more of the DB's are unable to provide services as well. 
Nancy

---

From: Rex Buddenberg <[email-masked]>
Date: Mon, 13 Feb 2012 08:59:52 -0800

Raj,

Since I recognize a great deal of pasting here, I don't think I could
object.  Seriously, looks like you've captured.