ietf
[Top] [All Lists]

Re: [paws] WG Review: Protocol to Access White Space database (paws)

2011-04-21 20:36:22
On 4/21/2011 8:05 PM, scott(_dot_)probasco(_at_)nokia(_dot_)com wrote:

Hi,

I agree with the concept, just want to be sure the PAWS is not expected to 
develop these security mechanisms (i.e. the tools) as contrasted to including 
or using in PAWS the security tools developed by appropriate expert groups.


I agree.

"Inclusion of robust security mechanisms is required:..."
??

Regards,
Scott



-----Original Message-----
From: ext Alissa Cooper [mailto:acooper(_at_)cdt(_dot_)org] 
Sent: Thursday, April 21, 2011 6:01 AM
To: Probasco Scott (Nokia-CIC/Dallas)
Cc: stephen(_dot_)farrell(_at_)cs(_dot_)tcd(_dot_)ie; 
ietf(_at_)ietf(_dot_)org; paws(_at_)ietf(_dot_)org; iesg(_at_)ietf(_dot_)org
Subject: Re: [paws] WG Review: Protocol to Access White Space database (paws)

On Apr 20, 2011, at 3:41 PM, <scott(_dot_)probasco(_at_)nokia(_dot_)com> 
<scott(_dot_)probasco(_at_)nokia(_dot_)com> wrote:

Hi Stephen, All,

I believe the current wording
Robust security mechanisms are required to prevent:
device identity spoofing, modification of device requests, modification
of channel enablement information, ...
is acceptable because "mechanisms are required" means they should be in the 
protocol, it does not mean they cannot be optional. PAWS should support 
Regulator requirements globally, and thus I believe there will be procedures 
or capabilities which are "required" to be in the protocol but will be 
"optional" during run time. Thus different or conflicting requirements from 
different regions of the world can be supported. (Several regulatory groups 
around the world are still developing their views and requirements).


Agreed on this point, although I think the charter could make it a little 
less ambiguous by saying "Development of robust security mechanisms is 
required . . .," that way it's not indicating that the actual mechanisms 
themselves will always be required.

Given that device identity will have to be shared in some circumstances, I 
would also add its protection to the end of the list of mechanisms: 

Development of security mechanisms is required to prevent:
device identity spoofing, modification of device requests, modification
of channel enablement information, impersonation of registered database
services and unauthorized disclosure of a user's location and/or device 
identity.

Alissa

It's not the time to dig deep into proposed solutions, just my opinion is 
the current proposed wording is an acceptable definition to allow a Work 
Group to get started defining the details.

Regards,
Scott

-----Original Message-----
From: paws-bounces(_at_)ietf(_dot_)org 
[mailto:paws-bounces(_at_)ietf(_dot_)org] On Behalf Of ext Stephen Farrell
Sent: Tuesday, April 19, 2011 4:28 PM
To: IETF-Discussion
Cc: paws(_at_)ietf(_dot_)org; iesg(_at_)ietf(_dot_)org
Subject: Re: [paws] WG Review: Protocol to Access White Space database (paws)


I think this is a good and timely thing for the IETF to do.

One part of this where I think it might be useful to get
some broader input (which may have happened already, I'm not
sure) is the following:

On 19/04/11 17:56, IESG Secretary wrote:
The protocol must protect both the channel enablement process and the
privacy of users. 

That part is fine but it goes on to say:

Robust security mechanisms are required to prevent:
device identity spoofing, modification of device requests, modification
of channel enablement information, ...

I'm told (and believe) this in response to (at least) US
FCC requirements that call for a device ID and sometimes
serial number to be (securely, for some value of securely)
sent with the query.

Those appear to be real regulatory requirements in the
US, presumably so the regulator can stomp on someone who
messes about in the wrong spectrum at the wrong time.
(The link below [1] may be to the right or wrong bit of
those US regulations, I'm not at all sure, not being
from there;-)

So my questions:

Are there may be similar (or conflicting!) requirements
elsewhere?

Does this bit of the charter text need changes to work
well for other regions?

Separately, I'm not sure how to square those kinds of
regulatory requirements with protecting privacy where the
device is carried by a person and has some FCC device ID
(which lots do I guess) and the person might not want
the database operator to know who's asking. But I think
that's ok as something for the WG to figure out since
the charter already calls for respecting privacy.

I'm more concerned in case e.g. some other regional regulation
called for this protocol to be completely anonymous or
something, in which case the current charter text might
be problematic.

Cheers,
Stephen.

[1]
http://ecfr.gpoaccess.gov/cgi/t/text/text-idx?c=ecfr&sid=3e9c322addf1f7e897d8c84a6c7aca78&rgn=div8&view=text&node=47:1.0.1.1.14.8.243.9&idno=47
_______________________________________________
paws mailing list
paws(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/paws
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf



_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf


Attachment: gwz.vcf
Description: Vcard

_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf