Subject: Re: [paws] Security Requirements (was: next steps for the wg)

From: <[email-masked]>
Date: Thu, 19 Jan 2012 14:54:20 +0000

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-masked]] 
Sent: Tuesday, January 17, 2012 3:41 PM
To: Patil Basavaraj (Nokia-CIC/Dallas); Bajko Gabor (Nokia-CIC/SiliconValley); [email-masked]
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-masked]"
<[email-masked]> wrote:

>
>Gabor,
>
>On 1/12/12 8:26 PM, "ext [email-masked]" <[email-masked]>
>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-masked]
>https://www.ietf.org/mailman/listinfo/paws

---

From: <[email-masked]>
Date: Thu, 19 Jan 2012 16:02:59 +0000

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

---

From: Peter Saint-Andre <[email-masked]>
Date: Fri, 27 Jan 2012 08:46:27 -0700

> approach for dealing with such security needs.

Typically, IETF protocols specify a baseline (e.g., minimum TLS version,
rules for cert checking) so that we can ensure basic interoperability.
Is there a reason why we would not do the same here?

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 27 Jan 2012 16:15:51 +0000

> Is there a reason why we would not do the same here?

I do hope not:-)

Also, not sure if the WG are treating privacy and security in
one go, but the charter does say;

"Robust privacy and security mechanisms are needed..."

So I also hope that gets considered. I don't see it in the current
reqs. draft but have not read that fully.

Cheers,
S