Re: [paws] Kathleen Moriarty's Discuss on draft-ietf-paws-protocol-14: (with DISCUSS)

Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com> Thu, 21 August 2014 19:44 UTC

Return-Path: <kathleen.moriarty.ietf@gmail.com>
X-Original-To: paws@ietfa.amsl.com
Delivered-To: paws@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F8031A8A4D; Thu, 21 Aug 2014 12:44:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qG_cebuIfRti; Thu, 21 Aug 2014 12:44:21 -0700 (PDT)
Received: from mail-lb0-x236.google.com (mail-lb0-x236.google.com [IPv6:2a00:1450:4010:c04::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A74511A8A4C; Thu, 21 Aug 2014 12:44:20 -0700 (PDT)
Received: by mail-lb0-f182.google.com with SMTP id z11so8742933lbi.27 for <multiple recipients>; Thu, 21 Aug 2014 12:44:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=QapssmwV95tkCCd3uPdreNNZGN7GNaTlFK0F7auUyss=; b=mxtShrOF0SYrxz+T7IDC7oIiUagj19woDCNCHH8Mj3nG4JOYGIX/CuoWeAxRYIbUnu SrhbKVzat0G/BTQ1OYAk66HDGTA4WfEBG/hv4mBvVLyR+vnWm5cyJpwP6VZef5CGZIsu c2+2ftfR/bRlE3tFve0NzmXGYC7CFNTGDTgs+3HUQuV5vAxOD5S8uZtbGuAIwKIGMZ+v WN/zrRzL0pmCFSK6UFoTJ2oEObk8j19+GHE2BmSa4MKrYfdI8dltzjlGsBl0UEHzhmes WG6Z0wqgv19xQ6vDalC24FFd4v9GzT0Lcf0lXBDh/VKiLDrJUorXtbfr0IBV+ZHE2DPj hkIg==
MIME-Version: 1.0
X-Received: by 10.152.245.171 with SMTP id xp11mr487702lac.61.1408650258723; Thu, 21 Aug 2014 12:44:18 -0700 (PDT)
Received: by 10.112.64.170 with HTTP; Thu, 21 Aug 2014 12:44:18 -0700 (PDT)
In-Reply-To: <CABEV9RPHCq14oF9CYdVmn0NHaqfQf1mton0WE9-Hn1zMCHyfqw@mail.gmail.com>
References: <20140820203127.25270.64032.idtracker@ietfa.amsl.com> <53F50D2D.2010203@qti.qualcomm.com> <CAHbuEH4RsF4kkUd8qO+bsCbzs6xRB=TL6hg2GyGWKf8OvJjViw@mail.gmail.com> <CABEV9RP7Dzk46JsUQ15z8kMvTGNOUCUjWmzQkVGyQbnjpvkLRA@mail.gmail.com> <CAHbuEH4+=tUQNRmURd3r047UYhSe=LPyJVZUEq4X+uYDMOaWrw@mail.gmail.com> <CAHbuEH7Ms5QuMwgFXy9OuXTcgvGR-9AyDJMnX-T7qEHema84-Q@mail.gmail.com> <CABEV9RPHCq14oF9CYdVmn0NHaqfQf1mton0WE9-Hn1zMCHyfqw@mail.gmail.com>
Date: Thu, 21 Aug 2014 15:44:18 -0400
Message-ID: <CAHbuEH5DSi86tndZLXRqJzkS4pGTp3vSpZKU2tnja2Y1nN0ScQ@mail.gmail.com>
From: Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com>
To: Vincent Chen <vchen@google.com>
Content-Type: multipart/alternative; boundary="001a11345e1248ba26050128f20e"
Archived-At: http://mailarchive.ietf.org/arch/msg/paws/xO9WzcJP4wYcSSy6crfQN4-XXoY
X-Mailman-Approved-At: Thu, 21 Aug 2014 12:47:27 -0700
Cc: "paws@ietf.org" <paws@ietf.org>, "paws-chairs@tools.ietf.org" <paws-chairs@tools.ietf.org>, Pete Resnick <presnick@qti.qualcomm.com>, The IESG <iesg@ietf.org>, draft-ietf-paws-protocol@tools.ietf.org
Subject: Re: [paws] Kathleen Moriarty's Discuss on draft-ietf-paws-protocol-14: (with DISCUSS)
X-BeenThere: paws@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Protocol to Access White Space database \(PAWS\)" <paws.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/paws>, <mailto:paws-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/paws/>
List-Post: <mailto:paws@ietf.org>
List-Help: <mailto:paws-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/paws>, <mailto:paws-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 21 Aug 2014 19:44:26 -0000

Hi Vincent,


On Thu, Aug 21, 2014 at 1:25 PM, Vincent Chen <vchen@google.com> wrote:

> Kathleen,
>
> Apologies for my poorly worded response. The first paragraph of Section 10
> states:
>
>    PAWS is a protocol whereby a Master Device requests a schedule of
>    available spectrum at its location (or location of its Slave Devices)
>    before it (they) can operate using those frequencies.
>
>
> The fact that it's "public information" is parenthetical in my response.
>

OK, this isn't my area of expertise, so I didn't read it the same way in
that information was limited to requests of public data.

>
> Section 8 discusses extensibility. Should there just be a statement in
> there that no extensions
> should be made to return sensitive information about devices? That it
> should be focused
> on just returning available-spectrum information?
>
> Yes, that would help, thank you.


> Would that be sufficient?
>
> Thanks.
>
>
>
> On Thu, Aug 21, 2014 at 8:13 AM, Kathleen Moriarty <
> kathleen.moriarty.ietf@gmail.com> wrote:
>
>> Chatted a bit with Pete and he sees the point we are down to now.  To be
>> clear, I think we are down to a comment and would just like to finish up
>> the discussion and then I'll update the tracker since we are close here.
>>
>>
>> On Thu, Aug 21, 2014 at 8:05 AM, Kathleen Moriarty <
>> kathleen.moriarty.ietf@gmail.com> wrote:
>>
>>>
>>>
>>>
>>> On Thu, Aug 21, 2014 at 4:15 AM, Vincent Chen <vchen@google.com> wrote:
>>>
>>>> Thanks to Pete for responding.
>>>>
>>>> Additional comments inline.
>>>>
>>>>
>>>> On Wed, Aug 20, 2014 at 3:09 PM, Kathleen Moriarty <
>>>> kathleen.moriarty.ietf@gmail.com> wrote:
>>>>
>>>>>
>>>>>
>>>>>
>>>>> On Wed, Aug 20, 2014 at 5:03 PM, Pete Resnick <
>>>>> presnick@qti.qualcomm.com> wrote:
>>>>>
>>>>>> On 8/20/14 3:31 PM, Kathleen Moriarty wrote:
>>>>>>
>>>>>>> ------------------------------------------------------------
>>>>>>> ----------
>>>>>>> DISCUSS:
>>>>>>> ------------------------------------------------------------
>>>>>>> ----------
>>>>>>> [...]
>>>>>>>
>>>>>>> Can clients query any database entries or is the interface
>>>>>>> restricted to
>>>>>>> the list of supported interactions?   I assume the answer is that it
>>>>>>> is
>>>>>>> limited to the set of database interactions defined, but could not
>>>>>>> find
>>>>>>> any statement saying that in this draft or the prior requirements in
>>>>>>> RFC6953.
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> I'm not sure exactly what you mean here. Are you asking whether the
>>>>>> client or server ask for/send back more than the minimum data? Sure, that's
>>>>>> what the "*other" business is about. Or are you asking whether additional
>>>>>> queries/responses can be defined? I suppose they could. But I'm not sure
>>>>>> what you're asking, or what the concern is. Can you elaborate?
>>>>>
>>>>>
>>>>> There wasn't an explicit statement that you need to define new
>>>>> query/responses through extensions, so that coupled with the possibility of
>>>>> unauthenticated sessions had me worrying that more data could be exposed
>>>>> then intended.  A statement in the security considerations section (maybe)
>>>>> after the MAY for authentication that helps state the limitation of the
>>>>> interface to this and approved extensions would help.  The risk would be
>>>>> additional query/responses that let you get at more data than was intended
>>>>> (some of the privacy related information or fingerprinting possibilities
>>>>> would be the concern.
>>>>>
>>>>
>>>> The security considerations section started by saying that the Database
>>>> provides
>>>> available spectrum information, which is public information. Nothing
>>>> else can be retrieved
>>>> from the Database.
>>>>
>>>
>> I don't see this text, can you point it out?  I may be missing it, but
>> would have expected it as one of the listed protection steps in section 10
>> or maybe as part of 10.1.
>>
>> I really think what I am looking for should have been in the requirements
>> document for the protocol and any extensions.  With an assumption that only
>> public information will be provided over the unauthenticated sessions,
>> limiting the scope of access to public information access through the
>> defined interface (which you are doing) would be good to close out with a
>> statement to that requirement.
>>
>> Since I think this does really belong in the prior document, but could go
>> here, I will consider this at the comment level and would appreciate it if
>> you could point out where I might be missing text that only public
>> information is available through the defined interface.
>>
>> Thank you!
>>
>>
>>>> Does Pete's point about the DeviceDescriptor being an echo of the
>>>> request also resolve this
>>>> concern?
>>>>
>>>>
>>>>>
>>>>> Earlier in the draft it sounds as if authentication is required until
>>>>> you get to that statement towards the end of the security considerations
>>>>> section.
>>>>>
>>>>
>>>> NOTE: Since the Database returns the same available-spectrum answer for
>>>> the same combination of (device type, location), regardless of what
>>>> requests came before or after, authentication of the client seems to add
>>>> little benefit. I.e., spoofing by rogue devices does not impact the answer
>>>> given to well-behaved devices.
>>>>
>>>
>>> Yes, Pete's point on DeviceDescriptor did help with some of my concerns
>>> and sorry that I somehow missed it on my first read of the draft.   I'm not
>>> asking for authentication to be required, so maybe that was misunderstood.
>>>  I didn't see anywhere a statement that extensions to this interface have
>>> to be defined and should consider this premise information (authentication
>>> is not required and the larger database does contain information that could
>>> be used for profiling the overall system or fingerprinting devices.
>>>  Although, watching the other discusses, some of the requirements on fields
>>> are changing a bit and maybe the concerns are lowering as a result, but
>>> we'll have to see where that winds up.  I understand that the current
>>> interface limits what can be retrieved.  In some other protocols, I've seen
>>> an informational statement to ensure those writing extensions are cognizant
>>> of the reasons for the limitations imposed.  It looks like you have done a
>>> pretty good job on it and I was hoping to see a statement on the
>>> limitations for the purpose of possible extensions in the future following
>>> the patterns.  I don't think I saw them spelled out in the requirements RFC.
>>>
>>> Thanks,
>>> Kathleen
>>>
>>>>
>>>>
>>>>
>>>>>
>>>>>>
>>>>>>  Authentication is only a MAY in the Security Considerations Section,
>>>>>>> which raises another possible concern for me.
>>>>>>>
>>>>>>> Since clients can get back pretty much all of the defined datatypes
>>>>>>> (DeviceDescriptor is one example)
>>>>>>>
>>>>>>
>>>>>> The client only gets back the DeviceDescriptor that it sent to the
>>>>>> server in the request so that the client can match the response to the
>>>>>> query.
>>>>>>
>>>>>> Sorry, I missed that very important point in the query/response
>>>>> description somehow.
>>>>>
>>>>>
>>>>>>
>>>>>>  and authentication is not required,
>>>>>>> there should be a discussion on the risks of revealing this
>>>>>>> information
>>>>>>> for both the privacy reasons Stephen and Alissa outlined as well as
>>>>>>> possible security concerns.  I think this should be on a field basis
>>>>>>> in
>>>>>>> terms of sensitive elements where relevant.
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> The rest of the responses are the publicly available spectrum
>>>>>> information. I'm not seeing sensitive data there.
>>>>>>
>>>>>> Yep, for the current queries, I missed that you were only getting the
>>>>> response that included the DeviceDescriptor information you sent.  Sorry
>>>>> about that!
>>>>>
>>>>>>
>>>>>>  I could see how you might want/need the types of information gathered
>>>>>>> within an administrative domain or accessed by a restricted set of
>>>>>>> users,
>>>>>>> but revealing data like what is contained in deviceDescriptor
>>>>>>> (includes
>>>>>>> model) as well as sensitive fields in other classes
>>>>>>> (AntennaCharacteristics) seems like a risk as it could be used in
>>>>>>> targeted attacks if there are known vulnerabilities to those devices.
>>>>>>> The attacks could target specific regions at specific times to effect
>>>>>>> events or to be used as part of some larger attack (could include
>>>>>>> physical).  This may sound crazy, but layered attacks are very real.
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> This seems like it would be a problem for sniffing unencrypted data
>>>>>> *from* another client, but I'm not getting how this sort of attack works by
>>>>>> a client owned by the attacker querying the database.
>>>>>>
>>>>>  This is just the kind of thing you might be able to do with the full
>>>>> set of info.  I think just responding on the first item would be good
>>>>> enough as I missed an important point.
>>>>>
>>>>>>
>>>>>> Before I get back to the rest of your query, help me understand this
>>>>>> far.
>>>>>
>>>>>
>>>>> Thank you!
>>>>>
>>>>>>
>>>>>>
>>>>>> pr
>>>>>>
>>>>>> --
>>>>>> Pete Resnick<http://www.qualcomm.com/~presnick/>
>>>>>> Qualcomm Technologies, Inc. - +1 (858)651-4478
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>>
>>>>> Best regards,
>>>>> Kathleen
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> -vince
>>>>
>>>
>>>
>>>
>>> --
>>>
>>> Best regards,
>>> Kathleen
>>>
>>
>>
>>
>> --
>>
>> Best regards,
>> Kathleen
>>
>
>
>
> --
> -vince
>



-- 

Best regards,
Kathleen