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 On Feb 3, 2012, at 2:57 PM, <[email protected]> wrote: > > 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 > > On 2/3/12 1:51 PM, "ext Joel M. Halpern" <[email protected]> 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
