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