Hi Gabor, Peter's comment : "I think it would be better to consider the various threat levels and then decide how to provide reasonable protection against them in a comprehensive way." makes sense. It is unnecessary to specify requirements such as the need for OCSP in case certificate based authentication is used etc. Rather, lets specify a broader set of security requirements based on the threat model and let the solution(s) decide what would be the best approach for dealing with such security needs.
-Raj On 1/19/12 8:54 AM, "Bajko Gabor (Nokia-CIC/SiliconValley)" <[email protected]> wrote: >In order to avoid contacting a spoofed database, a client has to check >the identity of it. Assuming we use certs, that means that the client has >to be able to authenticate the db based on its cert (this is currently >requirement P.6, P.12), but it may also need to check if that cert is >valid, so OCSP may also be needed (requirement P.13). > >It seems to me that you would require the above requirements to make sure >you avoid talking with a spoofed database, but you may not necessarily >require the message exchanges be encrypted; integrity protection may be >necessary though, as you want to make sure the answer from db is not >modified by a mitm. > >If that is the case, then we would keep requirements P.6, P.12, P.13 and >remove integrity protection from requirement P.5 > >Is my understanding correct? > >- Gabor > > >-----Original Message----- >From: ext Peter Stanforth [mailto:[email protected]] >Sent: Tuesday, January 17, 2012 3:41 PM >To: Patil Basavaraj (Nokia-CIC/Dallas); Bajko Gabor >(Nokia-CIC/SiliconValley); [email protected] >Subject: Re: [paws] next steps for the wg > >This comment is a compound response to the "Security between the database >and the white space radio". >I have always believed that there is little reason to need to trust the >radio - after all if it was going to do something malicious or illegal >why would it even contact the database and request a channel list. In >addition the impact of a single rouge radio is fairly limited. However >the implications of a spoofed database that provides "all channels >available everywhere" in response to channel queries could be >catastrophic. I am finding it hard to evaluate this requirement, and >the previous requirements in isolation. I think it would be better to >consider the various threat levels and then decide how to provide >reasonable protection against them in a comprehensive way. > >On TueJan/17/12 Tue Jan 17, 6:14 PM, "[email protected]" ><[email protected]> wrote: > >> >>Gabor, >> >>On 1/12/12 8:26 PM, "ext [email protected]" <[email protected]> >>wrote: >> >>>P.13: A master device MUST be capable of checking the validity of >>> the WS Database certificate and whether it has been revoked >>> or not. >>> >>>Note, P.13 requires support for OCSP (RFC2560) in the client, I am not >>>sure if that is needed, please send your opinions. >>> >> >> >>If certificate based authentication is used by the protocol, then there >>would be a need to mandate the above requirement. But at this time we >>have no visibility about the authentication protocol to be used between >>the master device and the WS database. So it is premature to specify >>the above requirement. Hence I would favor dropping this requirement. >> >>-Raj >> >>_______________________________________________ >>paws mailing list >>[email protected] >>https://www.ietf.org/mailman/listinfo/paws > _______________________________________________ paws mailing list [email protected] https://www.ietf.org/mailman/listinfo/paws
