Re: [core] Security aspects in CoAP over TCP

[Göran Selander <[e-mail]>]

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




On 2016-11-18 05:03, "core on behalf of Hannes Tschofenig"
<[e-mail] on behalf of [e-mail]> wrote:

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