Subject: [core] Security aspects in CoAP over TCP

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 18 Nov 2016 05:03:56 +0100

Hi all,

we had a somewhat inconclusive discussion in the CORE working group this
week about the security aspects of CoAP over TCP.

I thought I should write down my thoughts about this topic again in the
hope that we can find a solution relatively quickly.

When we started the CoAP over TCP work we were under the impression that
we can get it done fast since it related to a deployment artifact when
using CoAP in enterprise environments where UDP traffic gets blocked.

We have an implementation already and so does Microsoft.
We both use TLS to secure the communication.

Our intention was to document what we were doing already and to get
moving forward.

With the work in the group we had to make a compromise and had to add
stuff that does not necessarily have anything to do with what we are
implementing and deploying today. An example of that functionality is
Websocket.

We lost that battle and as a consequence the document is more verbose
than we had initially envisioned and took much longer to finalize.

CoAP over TCP/TLS is, however, not necessarily the long-term goal.
Instead of adding various features to CoAP in a step-by-step fashion we
could as well in the long run go to HTTP/2, for example, instead. Hence,
I see it as an intermediate approach to deal with deployment challenges,
get it done as quickly as possible, and then to move on.

The discussion about application layer security for CoAP goes into a
direction that I am not necessarily comfortable with. In our deployment
model the interaction of the IoT device with the server-side
infrastructure is currently CoAP over DTLS/TLS. Then, we use HTTPS to
connect with other application-based services.

Funny enough, we can neither re-use the work on
draft-ietf-core-http-mapping nor can we use the OSCOAP work in our
current deployment. I hope there are deployments out there that are very
different from what we are doing. It could, however, well be that there
is a lack of deployment experience and we do the "sounds good"-type of
standardization instead. In the CORE-HTTP-MAPPING case, for example, we
are not just relaying CoAP (or HTTP) requests but the server-side is
actually providing some functionality that changes the nature of the
protocol interaction on the HTTP side. The experience with HTTP signing
in OAuth also shows me that there are lots of problems when securing
RESTful API interactions in general. I expect to see the same problems
with the OSCOAP work in practice. I would go as far as saying that
RESTful APIs are very difficult (if not impossible) to secure end-to-end
in any practical multi-protocol environment.

In a nutshell, I prefer a solution for CoAP over TCP that allows us
 * to move the document forward as soon as possible, and
 * to document what we are doing today.

On the question about what credentials are being used with TLS I believe
the discussion at the meeting was a bit misleading since the arguments
on why some people prefer to use pre-shared secrets was actually not
related to TLS. Maybe it is possible to leave this issue open and
instead refer to RFC 7925.

Ciao
Hannes

---

From: Göran Selander <[email-masked]>
Date: Fri, 18 Nov 2016 06:52:20 +0000

Hi Hannes and all,

I find the CoAP over TCP work very valuable also outside the use case you
present. Although this draft may be an intermediate solution in that use
case, I believe it will be useful in many other contexts. For this reason
we should be careful to avoid unnecessary limiting the security protocols
that may be used with it.

I don’t see any reason to stall the progress of this draft, what is
requested is nothing more than what is in RFC7252. I didn’t participate in
the Thursday breakfast meeting on the topic but I know there is some
proposed alternative text snippet being drafted for discussion on the list.

As for deployment of OSCOAP, the draft has just recently become stable and
so only a few applications are considered so far, for example:
https://tools.ietf.org/html/draft-vucinic-6tisch-minimal-security-00

Although OSCOAP was designed for the most constrained settings where UDP
is a natural transport protocol, by being an in-layer protocol, i.e. only
relying on CoAP, it works equally well over TCP. So whereas we at this
moment can’t demonstrate any concrete applications of OSCOAP over TCP, I
hope it is possible to see the value of being able to do end-to-end
security of a CoAP exchange from a client making a TCP request through one
or more proxies to a server only running UDP (or no transport protocol at
all such as with 
https://tools.ietf.org/html/draft-bormann-6lo-coap-802-15-ie-00).

As for your scepticism of OSCOAP, it would be very helpful if you or
someone else familiar with the issues of HTTP signing could review the
draft and provide some comments on concrete issues rather than making
sweeping remarks. Also, we requested in the WG for a CoAP/REST expert to
do a review to address possible similar concerns (don’t worry Klaus, no
one is looking at you J).

But, again, the discussion here should not be about OSCOAP, it is about
allowing other security protocols for CoAP in the same way as RFC7252 does.

Göran

---

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 18 Nov 2016 08:17:56 +0100

~snip~

> allowing other security protocols for CoAP in the same way as RFC7252 does.

The discussion started with the question about what should be stated as
mandatory-to-implement (MTI). The problem is that the discussion then
turned into OSCOAP vs. TLS. I argue that we should have TLS as MTI.

---

From: Ludwig Seitz <[email-masked]>
Date: Fri, 18 Nov 2016 09:14:42 +0100

> turned into OSCOAP vs. TLS. I argue that we should have TLS as MTI.

I think you are missing Göran's point here.

Can you please explain why do you think this draft should have a 
different statement than the one that is in the CoAP RFC?

If I understood RFC 7252 correctly (please feel free to correct me), 
CoAP specifies a binding to DTLS and MTI algorithms iff you use DTLS. It 
allows for other security protocols (such as e.g. IPSec, so this is not 
limited to OSCOAP) by allowing to use NoSec mode at application layer.

Göran is only asking that we apply the same principle to the CoAP-TLS 
specification.

/Ludwig

-- 
Ludwig Seitz, PhD   SICS Swedish ICT AB
Ideon Science Park, Building Beta 2
Scheelevägen 17, SE-223 70 Lund
Phone +46(0)70-349 92 51

The RISE institutes SP, Swedish ICT and Innventia are merging in order 
to create a unified institute sector and become a stronger innovation 
partner for businesses and society. At the end of the year we will 
change our name to RISE. Read more at www.ri.se/en/about-rise