Subject: [core] coap-09 review (security)

From: Alper Yegin <[email-masked]>
Date: Thu, 5 Apr 2012 14:58:05 +0300

Hello,

Please see below for my review comments on CoAP security.

Section 10.

NoSec:  There is no protocol level security (DTLS is disabled).
      Alternative techniques to provide lower layer security SHOULD be
      used when appropriate.  The use of IPsec is discussed in
      Section 10.2.

Alper> This "SHOULD when appropriate" is likely to lead to use of "insufficient" solutions. Without clear guidance, people cannot know if their alternative is really "appropriate", and they'd most probably be unreasonably optimistic about it. We need to provide some guidance here. Otherwise we are leaving a security hole behind.

   PreSharedKey:  DTLS is enabled and there is a list of pre-shared keys
      and each key includes a list of which nodes it can be used to
      communicate with as described in Section 10.1.1.  At the extreme
      there may be one key for each node this CoAP node needs to
      communicate with (1:1 node/key ratio).

Alper> Pairwise PSK (1:1) is what we should recommend, if not mandate. Anything less than that (PSK shared among multiple entities) is weak security. We should discourage, if not prohibit it.

   Certificate:  DTLS is enabled and the device has an asymmetric key
      pair with an X.509 [RFC5280] certificate that binds it to its
      Authority Name and is signed by some common trust root as
      described in Section 10.1.3.  The device also has a list of root
      trust anchors that can be used for validating a certificate.

Alper> For this to interoperate "out-of the box", we need to make sure the device is provisioned with the public key of Root CA that signed the other end-point's cert. There needs to be some coordination, as random selection of root CAs would fail interop. Need to be clear about that, otherwise people think putting a cert on the device gets them a fully interoperating solution.

Section 10.1.3

   When a new connection is formed, the certificate from the remote
   device needs to be verified.  If the CoAP node has a source of
   absolute time, then the node SHOULD check the validity dates are of

Alper> Why not "MUST check"? Unless there is a valid reason to relax this rule, we'd be opening a potential hole without a good justification.

Section 10.3.3

   CoAP also supports the use of multicast IP addresses in requests, an
   important requirement for M2M. Multicast CoAP requests may be the
   source of accidental or deliberate denial of service attacks,
   especially over constrained networks.  This specification attempts to
   reduce the amplification effects of multicast requests by limiting
   when a response is returned.  To limit the possibility of malicious
   use, CoAP servers SHOULD NOT accept multicast requests that can not
   be authenticated.  

Alper> Why not "MUST NOT accept"? Again, unless there is a valid reason to relax this rule, we'd be opening a potential hole without a good justification. 

Section 10.3.4

   Due to the lack of a handshake in UDP, a rogue endpoint which is free
   to read and write messages carried by the constrained network (i.e.
   NoSec or PreSharedKey deployments with nodes/key ratio > 1:1), 

Alper> We shall advise against "nodes/key ratio > 1:1:", if not prohibit...

Section 10.3.5

   o  the attacker sends a message to a CoAP end-point with a fake
      source address,

   o  the CoAP end-point replies with a message to the given source
      address,

   o  the victim at the given source address receives a UDP packet that
      it interprets according to the rules of a different protocol.

Alper> Assuming the victim is listening on the src port used by the attacker, right? And the victim is in server mode ready to accept asynchronously sent request packets (otherwise, there'd be some state on the victim which would be harder to match with the reflect packet).

Appendix D.1

   The RawPublicKey mode was designed to be easily provisioned in M2M
   deployments.  It is assumed that each device has an appropriate
   asymmetric public key pair installed, and an identity from that
   public key has been calculated as described in Appendix D.1.1.
   During provisioning, the identity of each node is collected, for
   example by reading a barcode on the outside of the device or by
   obtaining a pre-compiled list of the identities.  These identities
   are then installed in the corresponding end-point, for example an M2M
   data collection server.  The identity is used for two purposes, to
   associate the end-point with further device information and to
   perform access control.  During provisioning, an access control list
   of identities the device may start DTLS sessions with SHOULD also be
   installed.

Alper> Either that SHALL happen, or the device SHALL securely learn the IDs by some other means. 
We cannot possibly be more specific than that, but we shall force "secure learning".

Appendix D.2.2

   In this mode the identity of the public key for a device is used for
   access control.  An end-point SHOULD keep a list of identities that
   it allows to access its resource, and MAY also support more detailed
   access control on the method or resource level.  When a DTLS session
   is negotiated, a CoAP server that has an access control list MUST
   check the identity of the client.  This is done by calculating the
   identity of the client's public key as described in Appendix D.1.1.
   A client SHOULD also verify the identity of the server if it has been
   configured with the appropriate access control list.

Alper> "MUST also verify".
Alper> I'd even say remove "if it has been configured with the appropriate access control list."
What we don't know is how that access control list got on the device -- pre-provisoning, some other secure means, etc. But we know that we must use it, otherwise we are not talking about a secure solution. If we are thinking about some cases where it does not matter who the device is communicating with, then we can blend in "policy" into the text. For example, according to such policy, device may not care about the identity of its peer in certain types of communication (e.g., sending the temperature reading of a public place).

Regards,

Alper

---

From: "Dijk, Esko" <[email-masked]>
Date: Thu, 12 Apr 2012 14:44:01 +0000

Hi Alper,

> Alper> Why not "MUST NOT accept"? Again, unless there is a valid reason to relax this rule,
> we'd be opening a potential hole without a good justification.

There was a previous discussion on why the "SHOULD NOT" is used here, see e.g. reasons
http://www.ietf.org/mail-archive/web/core/current/msg02477.html

I assumed by the way that having L2 security does not mean requests are "authenticated" , while Carsten suggested in this thread that having L2 security does constitute a form of authentication (belonging to a group) if that level of authentication is sufficient for the application. Using my interpretation would mean that banning unauthenticated multicast implies banning multicast alltogether.

Esko

From: [email-masked] [mailto:[email-masked]] On Behalf Of Alper Yegin
Sent: Thursday 5 April 2012 13:58
To: [email-masked] WG
Subject: [core] coap-09 review (security)

Hello,

Section 10.

      pair with an X.509 [RFC5280<http://tools.ietf.org/html/rfc5280>] certificate that binds it to its

Section 10.1.3

Section 10.3.3

Section 10.3.4

Section 10.3.5

Appendix D.1

Appendix D.2.2

Regards,

Alper

________________________________
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.