Subject: [core] Clarification of coap-08 multicast security requirements

From: "Dijk, Esko" <[email-masked]>
Date: Mon, 28 Nov 2011 15:59:43 +0000

Dear all,

There's a possible issue I see with the definition of CoAP multicast security - the current core-coap-08 states:
  "To limit the possibility of malicious use, CoAP servers SHOULD NOT accept
    multicast requests that can not be authenticated."

The "SHOULD NOT" seems too strong here. I would expect that in deployments using NoSec mode, authentication would typically not be available.
For example, if I configure my network using NoSec in CoAP clients/servers, without object security, without IPSec, that seems to be allowed for unicast CoAP messages.  But not for multicast then? There is some specific text to cover this case:
  "The system is secured only by keeping attackers from
  being able to send or receive packets from the network with the CoAP nodes"

I would assume this also applies then to multicast CoAP messages. Of course the section 10 remark "Alternative techniques to provide lower layer security SHOULD be used when appropriate." still holds. This could be realized by IPSec but also link-layer encryption methods that may not provide authentication, or even nothing - if that is appropriate for the use case.

best regards,

Esko Dijk

Philips Corporate Technologies, Research
High Tech Campus 34, Eindhoven, The Netherlands
[email-masked]

________________________________
The information contained in this message may be confidential and legally protected under applicable law. The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender by return e-mail and destroy all copies of the original message.

---

From: Kerry Lynn <[email-masked]>
Date: Mon, 28 Nov 2011 13:01:03 -0500

On Mon, Nov 28, 2011 at 10:59 AM, Dijk, Esko <[email-masked]> wrote:

>  Dear all,
>
>
>
> There’s a possible issue I see with the definition of CoAP multicast
> security - the current core-coap-08 states:
>
>   “To limit the possibility of malicious use, CoAP servers SHOULD NOT
> accept
>
>     multicast requests that can not be authenticated.”
>
>
>
> The “SHOULD NOT” seems too strong here. I would expect that in deployments
> using NoSec mode, authentication would typically not be available.
>

Is your suggestion to change SHOULD NOT to MAY NOT?  That seems the only
option.
My own personal opinion is that the choice of security protocol will
ultimately be dictated
by the application (e.g. lighting control) and not by the application
protocol (e.g. CoAP).
One thing I'd be wary of is any language that requires devices to operate
at some
least common security level, but this change wouldn't do that.  IOW, if my
*application*
requires authenticated multicast requests, my devices will certainly reject
any requests
that aren't authenticated.

-K-

> For example, if I configure my network using NoSec in CoAP
> clients/servers, without object security, without IPSec, that seems to be
> allowed for unicast CoAP messages.  But not for multicast then? There is
> some specific text to cover this case:
>
>   “The system is secured only by keeping attackers from
>
>   being able to send or receive packets from the network with the CoAP
> nodes”
>
>
>
> I would assume this also applies then to multicast CoAP messages. Of
> course the section 10 remark “Alternative techniques to provide lower layer
> security SHOULD be used when appropriate.” still holds. This could be
> realized by IPSec but also link-layer encryption methods that may not
> provide authentication, or even nothing - if that is appropriate for the
> use case.
>
>
>
> best regards,
>
>
>
> Esko Dijk
>
>
>
> ------------------------------
> The information contained in this message may be confidential and legally
> protected under applicable law. The message is intended solely for the
> addressee(s). If you are not the intended recipient, you are hereby
> notified that any use, forwarding, dissemination, or reproduction of this
> message is strictly prohibited and may be unlawful. If you are not the
> intended recipient, please contact the sender by return e-mail and destroy
> all copies of the original message.
>
> _______________________________________________
> core mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/core
>
>

---

From: Thomas Fossati <[email-masked]>
Date: Mon, 28 Nov 2011 21:23:14 +0100

I fully agree with the point raised by Esko: there exist many use cases where a network can be assumed trusted by its end-points, with no crypto involved.  And this is valid independently of the communication protocol.

Further, if we allow unicast with NoSec, I don't see any stringent motivation to disallow the same security model with multicast.

So, +1 on substituting SHOULD NOT with MAY NOT, which would make it an application option, if I read RFC 2119 correctly.
It'd be also ok to remove the sentence altogether to avoid any doubt to CoAP implementers.

---

From: "Dijk, Esko" <[email-masked]>
Date: Tue, 29 Nov 2011 09:14:21 +0000

Thomas, Kerry,

Suggested text would be:

"In NoSec security mode, a CoAP server MAY refuse to accept multicast requests that can not be authenticated in order to limit the possibilities of malicious use of multicast requests. In all other security modes, a CoAP server SHOULD NOT accept multicast requests that can not be authenticated in order to limit the possibilities of malicious use of multicast requests."

(Note in the above text it is implicitly stated that the optional authentication in the NoSec mode would have to be done below or above the transport layer.) Using "MAY NOT" would be a bit confusing and seems not defined in RFC2119.

regards,
Esko

---

From: Thomas Fossati <[email-masked]>
Date: Tue, 29 Nov 2011 15:11:54 +0100

Hi Esko,

> "In NoSec security mode, a CoAP server MAY refuse to accept multicast requests that can not be authenticated in order to limit the possibilities of malicious use of multicast requests. In all other…

sounds good to me.  It acknowledges the risk of unauthenticated messaging over multicast (but again, unicast too is vulnerable...), and at the same time it does not prevent an application to define its own security model.  There is still some residual risk for interoperability issues in case an implementer chooses to hardcode the MAY, but that would be an implementation error :-)

> (Note in the above text it is implicitly stated that the optional authentication in the NoSec mode would have to be done below or above the transport layer.)

Perhaps it would be nice to state explicitly which mechanisms may be used, though.

> Using "MAY NOT" would be a bit confusing and seems not defined in RFC2119.

You are right.

---

From: TianLinyi <[email-masked]>
Date: Thu, 01 Dec 2011 05:40:53 +0000

Hi, Thomas and All

I am wondering whether we should change SHOULD NOT to MAY NOT. In most cases the authentication should be one either in transport layer or in application protocol layer. SHOULD NOT mean it can be avoided until there is a reason to do that. The case mentioned here is the case where authentication is not needed but not always. Therefore SHOULD NOT still make sense.

Cheers,
Linyi