I don't think we have a use case that would have such a requirement, but I'd like to make sure we don't preclude it.
Here is a use case: Law Enforcement or other security people on an ad-hoc network. Any communication would provide information useful to an eavesdropper. I don't think we should add that use case, just to get the encryption requirement. What we have is a authentication and integrity protection requirement. The solutions we have for those also allow encryption (like TLS/DTLS). Brian On Jan 27, 2012, at 5:10 PM, <[email protected]> <[email protected]> wrote: > > 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 _______________________________________________ paws mailing list [email protected] https://www.ietf.org/mailman/listinfo/paws
