On 4/21/2011 8:05 PM, scott.proba...@nokia.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:acoo...@cdt.org] > Sent: Thursday, April 21, 2011 6:01 AM > To: Probasco Scott (Nokia-CIC/Dallas) > Cc: stephen.farr...@cs.tcd.ie; ietf@ietf.org; p...@ietf.org; i...@ietf.org > Subject: Re: [paws] WG Review: Protocol to Access White Space database (paws) > > On Apr 20, 2011, at 3:41 PM, <scott.proba...@nokia.com> > <scott.proba...@nokia.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-boun...@ietf.org [mailto:paws-boun...@ietf.org] On Behalf Of ext >> Stephen Farrell >> Sent: Tuesday, April 19, 2011 4:28 PM >> To: IETF-Discussion >> Cc: p...@ietf.org; i...@ietf.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 >> p...@ietf.org >> https://www.ietf.org/mailman/listinfo/paws >> _______________________________________________ >> Ietf mailing list >> Ietf@ietf.org >> https://www.ietf.org/mailman/listinfo/ietf >> > > > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www.ietf.org/mailman/listinfo/ietf > >
<<attachment: gwz.vcf>>
_______________________________________________ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
