On Apr 20, 2011, at 3:41 PM, <[email protected]> <[email protected]> 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: [email protected] [mailto:[email protected]] On Behalf Of ext > Stephen Farrell > Sent: Tuesday, April 19, 2011 4:28 PM > To: IETF-Discussion > Cc: [email protected]; [email protected] > 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 > [email protected] > https://www.ietf.org/mailman/listinfo/paws > _______________________________________________ > Ietf mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/ietf > _______________________________________________ Ietf mailing list [email protected] https://www.ietf.org/mailman/listinfo/ietf
