Subject: [core] Securing coap-tcp-tls

From: Brian Raymor <[email-masked]>
Date: Thu, 22 Dec 2016 23:20:46 +0000

Apologies for the long delay in preparing this proposal. An extended illness after Seoul conspired against me.

Following the security discussion for coap-tcp-tls at IETF 97, Göran and I have been iterating on more nuanced
text.  I've applied the changes to the editor's draft, but kept - https://github.com/core-wg/coap-tcp-tls/issues/11 - open
for tracking and further updates until there's broader agreement.

Summary of Changes:

* Added a "Securing CoAP" section which is a mind-meld between the related RFC7252 section and the RFC7925 profile.
  The draft attempts to avoid too much duplication, but may be too minimal for some tastes.

* Added an informative reference to draft-ietf-core-object-security to illustrate an alternative approach
* Added an informative reference to Security Challenges for the Internet of Things from the IAB workshop

There is one question that needs broader review. In RFC7252, the NoSec and RawPublicKey modes were mandatory-to-implement.
Should this requirement be maintained for coap-tcp-tls ? For the moment, the current draft follows the direction of RFC7925:

   The mandatory-to-implement functionality will depend on the
   credential type used with IoT devices.

7.  Securing CoAP

   Security Challenges for the Internet of Things [SecurityChallenges]
   recommends:

      ... it is essential that IoT protocol suites specify a mandatory
      to implement but optional to use security solution.  This will
      ensure security is available in all implementations, but
      configurable to use when not necessary (e.g., in closed
      environment).  ... even if those features stretch the capabilities
      of such devices.

   A security solution MUST be implemented to protect CoAP over TCP and
   MUST be enabled by default.  This document defines the TLS binding,
   but alternative solutions at different layers in the protocol stack
   MAY be used to protect CoAP over TCP when appropriate.  Note that
   there is ongoing work to support a data object-based security model
   for CoAP that is independent of transport (see
   [I-D.ietf-core-object-security]).

7.1.  TLS binding for CoAP over TCP

   The TLS usage guidance in [RFC7925] applies.

   During the provisioning phase, a CoAP device is provided with the
   security information that it needs, including keying materials,
   access control lists, and authorization servers.  At the end of the
   provisioning phase, the device will be in one of four security modes
   with the following information for the given mode.  The "NoSec" mode
   in mandatory-to-implement for the TLS binding.  The remaining
   mandatory-to-implement mode depends on the credential type used with
   the device.  "PreSharedKey", "RawPublicKey", or "Certificate" is
   mandatory-to-implement for the TLS binding.

   NoSec:  TLS is disabled.

   PreSharedKey:  TLS is enabled.  The guidance in Section 4.2 of
      [RFC7925] applies.

   RawPublicKey:  TLS is enabled.  The guidance in Section 4.3 of
      [RFC7925] applies.

   Certificate:  TLS is enabled.  The guidance in Section 4.4 of
      [RFC7925] applies.

   In the "NoSec" mode, the system simply sends the packets over normal
   TCP which is indicated by the "coap+tcp" scheme and the TCP CoAP
   default port.  The system is secured only by keeping attackers from
   being able to send or receive packets from the network with the CoAP
   nodes.

   The other three security modes are achieved using TLS and are
   indicated by the "coaps+tcp" scheme and TLS-secured CoAP default
   port.

---

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 23 Dec 2016 15:09:38 +0000

Hi Brian,

Thanks for the write-up. It looks good for me.

Regarding the question below: Yes, there is indeed the risk that devices using different TLS profiles do not talk to each other.
But since we already added an option for object security I think we have made it already worse (in terms of options) than it was previously. Hence, saying that "The remaining mandatory-to-implement mode depends on the credential type used with the device." sounds reasonable to me.

A small editorial issue: s/The "NoSec" mode in mandatory-to-implement for the TLS binding./ The "NoSec" mode is mandatory-to-implement.

Ciao
Hannes

From: Brian Raymor [mailto:[email-masked]]
Sent: 23 December 2016 00:21
To: [email-masked] WG
Cc: Göran Selander; Francesca Palombini; Hannes Tschofenig; Juan Perez
Subject: Securing coap-tcp-tls

Summary of Changes:

7. Securing CoAP

NoSec: TLS is disabled.

The other three security modes are achieved using TLS and are
indicated by the "coaps+tcp" scheme and TLS-secured CoAP default
port.
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

---

From: Brian Raymor <[email-masked]>
Date: Thu, 29 Dec 2016 23:56:11 +0000

Resending with corrected CoRE WG address.

+ [email-masked]<mailto:[email-masked]>

Thanks Hannes. I updated the editor's draft to include your editorial comment - https://github.com/core-wg/coap-tcp-tls/pull/100

Could the core-coap-websockets authors suggest any WebSocket-specific guidance (or pull requests) for WebSockets in the Securing CoAP section? I'm unfamiliar with any production CoAP over WebSocket deployments as a source of best practices to review.

Thanks,
...Brian

From: Hannes Tschofenig [mailto:[email-masked]]
Sent: Friday, December 23, 2016 7:10 AM
To: Brian Raymor <[email-masked]<mailto:[email-masked]>>; [email-masked] WG' <[email-masked]<mailto:[email-masked]>>
Cc: 'Göran Selander' <[email-masked]<mailto:[email-masked]>>; 'Francesca Palombini' <[email-masked]<mailto:[email-masked]>>; Juan Perez <[email-masked]<mailto:[email-masked]>>
Subject: RE: Securing coap-tcp-tls

Hi Brian,

Ciao
Hannes

To: [email-masked]<mailto:[email-masked]> WG

Summary of Changes:

7. Securing CoAP

NoSec: TLS is disabled.