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
- Re: [paws] Kathleen Moriarty's Discuss on draft-i… Pete Resnick
- Re: [paws] Kathleen Moriarty's Discuss on draft-i… Vincent Chen
- [paws] Kathleen Moriarty's Discuss on draft-ietf-… Kathleen Moriarty
- Re: [paws] Kathleen Moriarty's Discuss on draft-i… Kathleen Moriarty
- Re: [paws] Kathleen Moriarty's Discuss on draft-i… Kathleen Moriarty
- Re: [paws] Kathleen Moriarty's Discuss on draft-i… Kathleen Moriarty
- Re: [paws] Kathleen Moriarty's Discuss on draft-i… Vincent Chen
- Re: [paws] Kathleen Moriarty's Discuss on draft-i… Kathleen Moriarty
- Re: [paws] Kathleen Moriarty's Discuss on draft-i… Stephen Farrell
- Re: [paws] Kathleen Moriarty's Discuss on draft-i… Kathleen Moriarty
- Re: [paws] Kathleen Moriarty's Discuss on draft-i… Kathleen Moriarty
- Re: [paws] Kathleen Moriarty's Discuss on draft-i… Vincent Chen
- Re: [paws] Kathleen Moriarty's Discuss on draft-i… Ray Bellis