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 protected]> wrote: >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 protected] wrote: >> >> 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 >> >> On 1/27/12 1:49 PM, "ext Joel M. Halpern"<[email protected]> wrote: >> >>> 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 protected] wrote: >>>> >>>> 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. >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> paws mailing list >>>> [email protected] >>>> https://www.ietf.org/mailman/listinfo/paws >>>> >> >> _______________________________________________ paws mailing list [email protected] https://www.ietf.org/mailman/listinfo/paws
