On Wed, Aug 20, 2014 at 5:03 PM, Pete Resnick <= ;presnick@qt= i.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?=C2=A0 =C2=A0I 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.
=C2=A0 =C2=A0

I'm not sure exactly what you mean here. Are you asking whether the cli= ent 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= 9;m not sure what you're asking, or what the concern is. Can you elabor= ate?

There wasn't an explicit statement that you need to= define new query/responses through extensions, so that coupled with the po= ssibility of unauthenticated sessions had me worrying that more data could = be exposed then intended. =C2=A0A statement in the security considerations = section (maybe) after the MAY for authentication that helps state the limit= ation of the interface to this and approved extensions would help. =C2=A0Th= e risk would be additional query/responses that let you get at more data th= an was intended (some of the privacy related information or fingerprinting = possibilities would be the concern.=C2=A0

Earlier in the draft it sounds as if authentication is = required until you get to that statement towards the end of the security co= nsiderations section.

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 i= n the request so that the client can match the response to the query.

Sorry, I missed that very important p= oint in the query/response description somehow.

=C2=A0

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.=C2=A0 I think this should be on a field basis i= n
terms of sensitive elements where relevant.
=C2=A0 =C2=A0

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. =C2= =A0Sorry about that!=C2=A0

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).=C2=A0 This may sound crazy, but layered attacks are very real. =C2=A0 =C2=A0

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. =C2=A0I think just responding on the first item would be good enough= as I missed an important point.=C2=A0

Before I get back to the rest of your query, help me understand this far.

Thank you!=C2=A0

pr

--
Pete Resnick<http://www.qualcomm.com/~presnick/>
Qualcomm Technologies, Inc. - +1 (858)651-4478

Best regards,

Kathleen