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

From: Pete Resnick <[email-masked]>
Date: Wed, 20 Aug 2014 16:03:41 -0500

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?

> 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.

> 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.

> 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.

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

pr

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

---

From: Vincent Chen <[email-masked]>
Date: Thu, 21 Aug 2014 01:15:54 -0700

Thanks to Pete for responding.

Additional comments inline.

On Wed, Aug 20, 2014 at 3:09 PM, Kathleen Moriarty <
[email-masked]> wrote:

>
>
>
> On Wed, Aug 20, 2014 at 5:03 PM, Pete Resnick <[email-masked]>
> wrote:
>
>> 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.

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.

>> 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.
>
>
>>
>> Yep, for the current queries, I missed that you were only getting the
> response that included the DeviceDescriptor information you sent.  Sorry
> about that!
>
>>
>> *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.
>
>>
> Thank you!
> Best regards,
> Kathleen

-- 
-vince

---

From: "Kathleen Moriarty" <[email-masked]>
Date: Wed, 20 Aug 2014 13:31:27 -0700

Kathleen Moriarty has entered the following ballot position for
draft-ietf-paws-protocol-14: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
http://datatracker.ietf.org/doc/draft-ietf-paws-protocol/

Thanks for doing this work, the draft looks good and my discuss should be
easy enough to address as I am just looking for some clarifying
information that may be helpful if I didn't miss the answer somewhere
else.

(DeviceDescriptor is one example) and authentication is not required,

Is there anything that prevents a client from fingerprinting?

Perhaps recommendations at the field level would help implementors
understand these risks (privacy & security) and then they may be more
motivated to enable authenticated and encrypted access.  This wouldn't be
necessary for all fields, just the ones that could be used in attacks or
reveal privacy related information.  Implementers may take the optional
field use more seriously or create options in application interfaces so
that users are then aware of the risks with these fields and make
different choices.  Ideally, there would be a limited set of data
returned based on role information so that devices or other clients only
get what they need as opposed to what is available.  I didn't see any
mention of restrictions on who could access what (role based access), is
that possible?  I'm not sure if the primary & secondary users allow for
this?

Thanks in advance.

---

From: Kathleen Moriarty <[email-masked]>
Date: Wed, 20 Aug 2014 18:09:12 -0400

On Wed, Aug 20, 2014 at 5:03 PM, Pete Resnick <[email-masked]>
wrote:

> 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

description somehow.

> The rest of the responses are the publicly available spectrum information.
> I'm not seeing sensitive data there.
>

> 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.

Thank you!

-- 

Best regards,
Kathleen

---

From: Kathleen Moriarty <[email-masked]>
Date: Thu, 21 Aug 2014 08:05:07 -0400

On Thu, Aug 21, 2014 at 4:15 AM, Vincent Chen <[email-masked]> wrote:

> 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

-- 

Best regards,
Kathleen

---

From: Kathleen Moriarty <[email-masked]>
Date: Thu, 21 Aug 2014 11:13:12 -0400

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-masked]> wrote:

>>> On Wed, Aug 20, 2014 at 5:03 PM, Pete Resnick <[email-masked]
>>> > wrote:
>>>
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!

>>> 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.
>>>
>>
> 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
>>>  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.
>>>
>>>>

-- 

Best regards,
Kathleen

---

From: Vincent Chen <[email-masked]>
Date: Thu, 21 Aug 2014 10:25:58 -0700

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 <
[email-masked]> wrote:

>>>> On Wed, Aug 20, 2014 at 5:03 PM, Pete Resnick <
>>>> [email-masked]> wrote:
>>>>
>>> available spectrum information, which is public information. Nothing
>>> else can be retrieved
>>> from the Database.
>>>
>>
>>> Does Pete's point about the DeviceDescriptor being an echo of the
>>> request also resolve this
>>> concern?
>>>
>>>
>>>>

-- 
-vince

---

From: Kathleen Moriarty <[email-masked]>
Date: Thu, 21 Aug 2014 15:44:18 -0400

Hi Vincent,

> 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.

> Yes, that would help, thank you.

-- 

Best regards,
Kathleen

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 21 Aug 2014 20:49:56 +0100

Hiya,

> that information was limited to requests of public data.

Nothing really to do with IESG processing of this but I'm
curious...

Is the full DB information really considered public? My
impression was rather that trying to extract the full DB
of information via repeated queries would be frowned upon.

S.

---

From: Kathleen Moriarty <[email-masked]>
Date: Thu, 21 Aug 2014 15:51:02 -0400

On Thu, Aug 21, 2014 at 3:49 PM, Stephen Farrell <[email-masked]>
wrote:

> Is the full DB information really considered public?

I'm glad it wasn't just me ;-)  Maybe stating that explicitly would be
good.

My

-- 

Best regards,
Kathleen

---

From: Kathleen Moriarty <[email-masked]>
Date: Thu, 21 Aug 2014 15:54:03 -0400

On Thu, Aug 21, 2014 at 3:51 PM, Kathleen Moriarty <
[email-masked]> wrote:

>
>
>
> On Thu, Aug 21, 2014 at 3:49 PM, Stephen Farrell <
> [email-masked]> wrote:
>
>>
>> Hiya,
>>
> Just to be clear - As I understand it now, the database may have sensitive
information, but the interface via PAWS only allows access to data that is
not sensitive.  If you can query it, it is public.  If you have database
access or other extensions are written, then it could be possible to get
access to sensitive data.

-- 

Best regards,
Kathleen

---

From: Vincent Chen <[email-masked]>
Date: Thu, 21 Aug 2014 14:57:25 -0700

Stephen, Kathleen,

A Spectrum Database is not a typical database; "full contents" is not well
defined.

In practice, available spectrum needs to be computed on each query, based
on the device's
location (and device type) and a host of other stored information about
location and spectrum usage
of "protected" entities, such as TV stations, wireless mics of theaters,
stadiums, etc.

The reason to use a Database is not that the data is sensitive in any way,
but that the Database has
been certified to be able to compute accurate answers, based on algorithms
and rules defined
by a regulator.

There's no other data that can be accessed...it's just the results of its
computations.

> Just to be clear - As I understand it now, the database may have
sensitive information, but the interface via PAWS only
> allows access to data that is not sensitive.  If you can query it, it is
public.  If you have database access or other extensions
> are written, then it could be possible to get access to sensitive data.

As mentioned elsewhere, I will add a statement to Section 8 to put some
limits on extensions.

-vince

On Thu, Aug 21, 2014 at 12:54 PM, Kathleen Moriarty <
[email-masked]> wrote:

>> Just to be clear - As I understand it now, the database may have
> sensitive information, but the interface via PAWS only allows access to
> data that is not sensitive.  If you can query it, it is public.  If you
> have database access or other extensions are written, then it could be
> possible to get access to sensitive data.
>
>>
>>> S.
>>>
>>
>>
>>
>> --
>>
>> Best regards,
>> Kathleen
>>
>
>
>
> --
>
> Best regards,
> Kathleen
>

-- 
-vince