Hi Brian, I don’t know if there are any requirements from a law-enforcement perspective in the FCC recommendations or Ofcom consultations. So while the law-enforcement use-case is good, I am not sure if we should include it in the I-D yet as another use case in the set.
-Raj On 1/27/12 4:21 PM, "ext Rosen, Brian" <[email protected]> wrote: >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
