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 protected]" <[email protected]>
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.
>
>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 protected] [mailto:[email protected]] On Behalf Of
>ext Paul Lambert
>Sent: Friday, February 03, 2012 2:58 PM
>To: Patil Basavaraj (Nokia-CIC/Dallas); [email protected];
>[email protected]
>Cc: [email protected]
>Subject: Re: [paws] Threat model (Rev 3)
>
>
>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
>>>>>> incumbent protection
>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
>
>
>
>>-----Original Message-----
>>From: [email protected] [mailto:[email protected]]
>>Sent: Friday, February 03, 2012 2:35 PM
>>To: Paul Lambert; [email protected]; [email protected]
>>Cc: [email protected]
>>Subject: Re: [paws] Threat model (Rev 3)
>>
>>
>>Hi Paul.
>>
>>On 2/3/12 4:26 PM, "ext Paul Lambert" <[email protected]> wrote:
>>
>>>
>>>>>> 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.
>>>
>>>No clue what you mean by "malicious node" ... this could be a
>>>Database, Master, random MiM, etc.
>>
>>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.
>>
>>>
>>>
>>>I was really thinking more about the misuse of the Database, or Master
>>to:
>>> - turn off devices presumed to be violating the DCMA
>>
>>DCMA?
>>The aspect of a device being switched off is covered in this threat.
>>
>>> - 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.
>>
>>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
>>
>>>
>>>Paul
>>>
>>>
>>>
>>>
>>>
>>>>-----Original Message-----
>>>>From: [email protected] [mailto:[email protected]] On Behalf
>>Of
>>>>Joel M. Halpern
>>>>Sent: Friday, February 03, 2012 12:01 PM
>>>>To: Rosen, Brian
>>>>Cc: [email protected]
>>>>Subject: Re: [paws] Threat model (Rev 3)
>>>>
>>>>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.
>>>>
>>>>
>>>>On 2/3/2012 2:55 PM, Rosen, Brian wrote:
>>>>> <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
>>>>>
>>>>>
>>>>> On Feb 3, 2012, at 2:51 PM, Joel M. Halpern wrote:
>>>>>
>>>>>> 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
>>>>>>
>>>>>> On 2/3/2012 2:34 PM, [email protected] wrote:
>>>>>>>
>>>>>>> Below is Rev 3 of the threat model based on feedback from
>>>>>>> Stephen,
>>>>Nancy
>>>>>>> and Gabor (Thanks).
>>>>>>>
>>>>>>> -Raj
>>>>>>>
>>>>>>>
>>>>>>> Rev 3 (3/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.
>>>>>>>
>>>>>>> o It is assumed that the master device or the white space database
>>>>>>> have NOT been compromised from a security standpoint.
>>>>>>>
>>>>>>> Threat 1: User modifies a device to masquerade as another valid
>>>>>>> certified device
>>>>>>>
>>>>>>> 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: 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 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.
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> paws mailing list
>>>>>>> [email protected]
>>>>>>> https://www.ietf.org/mailman/listinfo/paws
>>>>>>>
>>>>>> _______________________________________________
>>>>>> paws mailing list
>>>>>> [email protected]
>>>>>> https://www.ietf.org/mailman/listinfo/paws
>>>>>
>>>>>
>>>>_______________________________________________
>>>>paws mailing list
>>>>[email protected]
>>>>https://www.ietf.org/mailman/listinfo/paws
>>>_______________________________________________
>>>paws mailing list
>>>[email protected]
>>>https://www.ietf.org/mailman/listinfo/paws
>
>_______________________________________________
>paws mailing list
>[email protected]
>https://www.ietf.org/mailman/listinfo/paws
>_______________________________________________
>paws mailing list
>[email protected]
>https://www.ietf.org/mailman/listinfo/paws
_______________________________________________
paws mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/paws
