Re: [T2TRG] RESTful Design & Security

[Hannes Tschofenig <[e-mail]>]

Hi Goeran,

as you have seen that Michael asked me about OSCOAP; I didn't want to go
there.

I had initially planned to provide a response addressing each of your
points but I guess it is time for me to realize that you do not care
about the challenges we encounter in our deployments.

Ciao
Hannes

On 03/08/2017 09:30 AM, Göran Selander wrote:
> 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 =-
>>>
>>>
>>>
>>
>