Re: [T2TRG] RESTful Design & Security

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

Hi Hannes, and all,

Since Hannes is so eager to state what he thinks OSCOAP doesn’t work for
(which we all understand is the reason for starting this thread in the
first place J), allow me to balance this by outlining the end-to-end
security settings where people plan to use OSCOAP so far.

But first the story about application layer security, REST and
intermediary nodes (which was the question asked):

If the intermediary is required to perform operations on encrypted data
(such as data aggregation by non-trusted intermediary), there are
techniques such as homomorphic encryption, but the application in the
cloud would in this case anyway have to trust the intermediary to perform
the required operation since the integrity of the message would not be
preserved. Clearly, this is not a limitation specifically of OSCOAP.

The type of operations you can expect an intermediary to perform and still
preserve integrity end-to-end is more like the support for RESTful
operations performed by a CoAP proxy - the proxy reads CoAP meta-data and
performs various message-related operations. If you apply security on
transport layer or below (DTLS, IPsec etc.) then the CoAP meta-data is
only visible to the trusted endpoint for the secure channel, which either
makes it useless for the intermediary or makes the intermediary a trusted
endpoint. If you apply security on application layer then it is possible
for an intermediary to perform these operations while preserving
integrity. There are two options:

1. Apply security above the web transfer layer, i.e. to CoAP/HTTP payload,
e.g. by wrapping the payload in the COSE format. In this case the secure
COSE object is independent of web transfer mechanism so you can switch
between e.g. HTTP and CoAP. However, the web transfer metadata, including
e.g. the RESTful method, resource etc. is not protected. This is anyway
useful if the method/resource etc. is implicit or the application provides
the context, e.g. CoAP pub/sub.

2. Apply security to the web transfer layer, i.e. protect not only CoAP
payload but also CoAP meta data (headers and options) in such a way that
certain CoAP proxy operations can still be performed (e.g. only integrity
protecting the RESTful method allowing the proxy to read but not change).
This is what OSCOAP does.

The reasons why people are interested in OSCOAP, besides end-to-end
security and support for CoAP proxy operations which is e.g. used in
6tisch secure join, include:

- OSCOAP works essentially wherever CoAP works (UDP, TCP, SMS, BLE,
802.15.4 IE,  . . .) and provides end-to-end security independently of how
the underlying layers are being switched along the path.
 

- OSCOAP is possible to extended to secure CoAP over multicast IP (or CoAP
group communication in general RFC7390):
https://tools.ietf.org/html/draft-tiloca-core-multicast-oscoap

- OSCOAP is very lightweight. Recent optimisations to be published by the
IETF submission cutoff shrink the message overhead down to 13 bytes in the
CoAP request and 9 bytes in the OSCOAP response. This includes the 8 bytes
MAC. With existing CoAP and COSE implementation, OSCOAP is a minor
addition in terms of code.


Now for the statements made about OSCOAP:

> OSCOAP does not work when
> * you mix protocols,

for general web transfer protocols this either requires protection on a
lower layer, which prevents an intermediary from reading the metadata as
we have seen, or you can restrict protection to CoAP/HTTP payload as in 1.
above. But if you consider specific protocols with similar semantics such
as HTTP and CoAP, it is possible to define a mapping for a subset of the
metadata for which OSCOAP would preserve integrity and confidentiality
along the lines elaborated by Matthias in this thread. We started
sketching on this during IETF94 (with some of the authors of RFC8075) but
have not had time to continue the work. We are happy to pursue this work
if people think this is interesting.

> * use a middlebox for some processing interactions (such as data
> aggregation), and
>

This is not a limitation specifically of OSCOAP as motivated above.

> * when one of the protocols is a non-RESTful protocol, such as BLE or
>MQTT.
>


I thought the question was how to protect the RESTful operations, which
clearly isn’t relevant when one of the protocols is non-RESTful J. Anyway,
OSCOAP works where CoAP does, e.g. over BLE. Plain COSE works anywhere
(but does not protect the REST semantics).

We were considering to start implementing OSCOAP in mbed right after the
upcoming IETF, but maybe we should go for some other OS since ARM is so
negative. If anyone is considering implementating OSCOAP or has a
preference for a particular OS, please let us know. (Existing
implementations I know of are Contiki OS (Martin Gunnarsson), C-sharp (Jim
Schaad), Python (Christian Amsüss), Java (Joakim Brorsson/Ludwig Seitz)
and Mališa Vučinić has announced to implement in OpenWSN before the
summer.)

Göran



On 2017-03-07 19:39, "T2TRG on behalf of Hannes Tschofenig"
<[e-mail] on behalf of [e-mail]> wrote:

>OSCOAP does not work when
>
>* you mix protocols,
>* use a middlebox for some processing interactions (such as data
>aggregation), and
>* when one of the protocols is a non-RESTful protocol, such as BLE or
>MQTT.
>
>Unfortunately, these the use cases we are facing in current IoT
>deployments. For similar reasons we cannot use RFC 8075 either.
>
>Maybe you are seeing different deployment environments.
>
>Ciao
>Hannes
>
>On 03/07/2017 06:39 PM, Michael Richardson wrote:
>> 
>> Hannes Tschofenig <[e-mail]> wrote:
>>     > Needless to say that these challenges have also been observed in
>>other
>>     > protocols as well, such as HTTP and even SIP.
>> 
>>     > What is the story for providing application layer security?
>> 
>> OSCOAP seems to be end-to-end to me.
>> 
>> --
>> Michael Richardson <[e-mail]>, Sandelman Software Works
>>  -= IPv6 IoT consulting =-
>> 
>> 
>> 
>