Hi Vincent,
On Thu, Aug 21, 2014 at 1:25 PM, Vincent Chen <[email protected]> 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 < > [email protected]> 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 < >> [email protected]> wrote: >> >>> >>> >>> >>> On Thu, Aug 21, 2014 at 4:15 AM, Vincent Chen <[email protected]> wrote: >>> >>>> Thanks to Pete for responding. >>>> >>>> Additional comments inline. >>>> >>>> >>>> On Wed, Aug 20, 2014 at 3:09 PM, Kathleen Moriarty < >>>> [email protected]> wrote: >>>> >>>>> >>>>> >>>>> >>>>> On Wed, Aug 20, 2014 at 5:03 PM, Pete Resnick < >>>>> [email protected]> 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
_______________________________________________ paws mailing list [email protected] https://www.ietf.org/mailman/listinfo/paws
