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

[Vincent Chen <[e-mail]>]

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.

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?

Would that be sufficient?

Thanks.



On Thu, Aug 21, 2014 at 8:13 AM, Kathleen Moriarty <
[e-mail]> 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 <
> [e-mail]> wrote:
>
>>
>>
>>
>> On Thu, Aug 21, 2014 at 4:15 AM, Vincent Chen <[e-mail]> wrote:
>>
>>> Thanks to Pete for responding.
>>>
>>> Additional comments inline.
>>>
>>>
>>> On Wed, Aug 20, 2014 at 3:09 PM, Kathleen Moriarty <
>>> [e-mail]> wrote:
>>>
>>>>
>>>>
>>>>
>>>> On Wed, Aug 20, 2014 at 5:03 PM, Pete Resnick <
>>>> [e-mail]> 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. - [phone]
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>>
>>>> Best regards,
>>>> Kathleen
>>>>
>>>
>>>
>>>
>>> --
>>> -vince
>>>
>>
>>
>>
>> --
>>
>> Best regards,
>> Kathleen
>>
>
>
>
> --
>
> Best regards,
> Kathleen
>



-- 
-vince