Re: [T2TRG] RESTful Design & Security
Hannes Tschofenig <hannes.tschofenig@gmx.net> Wed, 08 March 2017 10:17 UTC
Return-Path: <hannes.tschofenig@gmx.net>
X-Original-To: t2trg@ietfa.amsl.com
Delivered-To: t2trg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF12D129466 for <t2trg@ietfa.amsl.com>; Wed, 8 Mar 2017 02:17:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.102
X-Spam-Level:
X-Spam-Status: No, score=-2.102 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ga0YVSEAqwdE for <t2trg@ietfa.amsl.com>; Wed, 8 Mar 2017 02:17:52 -0800 (PST)
Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C1961293D8 for <T2TRG@irtf.org>; Wed, 8 Mar 2017 02:17:51 -0800 (PST)
Received: from [192.168.91.177] ([80.92.114.23]) by mail.gmx.com (mrgmx102 [212.227.17.168]) with ESMTPSA (Nemesis) id 0MRjd7-1crqBT3KDB-00SwNd; Wed, 08 Mar 2017 11:17:43 +0100
To: Göran Selander <goran.selander@ericsson.com>, Michael Richardson <mcr+ietf@sandelman.ca>
References: <c15a387f-9dd3-987e-2901-b86fd8f60108@gmx.net> <10144.1488908366@obiwan.sandelman.ca> <952c4a16-174f-2457-1f11-8f733e738f90@gmx.net> <D4E5582E.78797%goran.selander@ericsson.com>
From: Hannes Tschofenig <hannes.tschofenig@gmx.net>
Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9
Message-ID: <ac6d1edc-e884-726e-9b70-1d26f917ea33@gmx.net>
Date: Wed, 08 Mar 2017 11:17:39 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0
MIME-Version: 1.0
In-Reply-To: <D4E5582E.78797%goran.selander@ericsson.com>
Content-Type: multipart/signed; micalg="pgp-sha512"; protocol="application/pgp-signature"; boundary="1CsoP06rTijdAvDFWntsTwmn8fM13uFjv"
X-Provags-ID: V03:K0:PU5uLGiiFKepb05+K5YYg03kmMUiAjCfwqUdAx/RL6pOdVIaodC rp3gb1Aj4T1nBgCYspqlFSopXUNZgYYQ42rjbhWSdJDFz24MB5upniPdqIj0vZxLFKYyo7t I5agmcTzYBU1zf+onCBuuGiIpL0OgZRo4y0aEQYKYMj/5wNigdSpu1BpR6MZiZx/YbfcdMj YeiK/kmMdFYGfqyhryujg==
X-UI-Out-Filterresults: notjunk:1;V01:K0:UD0Vvz+i/tY=:dqKonnaf2WWZ0pjmW3I4xP JxL203d0u1oYvq7qCnU8i9MmHARXt4JnQqtsVz5K6KuagGz7+ChLBEZZKUGX4ZjVzEusimWe5 bYNz6eelXYzpaY59BwT8UeV4U+kxt7EYMnJpY+rhC54jSqnAc/leNbViz35S0pEJJmmFPEtBh bAdiT8eWZRPRimmhiRq4OqHdSzEw0zBq1t4VXzqAfWO2XP6NPx1JcSrnUDK3rTKQfZ7PNeNZM uPBQf9g5B0BX7OQbujAwmERU+CCm98dB8WQJ6IV9Rs16utaNwD3sZMHWt8mHDSDf6gsnzmHsY NjinSLUoxLq8FVu3AhGNRUEzdKBNCZUvfqiDs5w67YU6B92Lej35p2uCOYJlvaOuSSvZw4GTv PzZ+vYzdNXJo9GkLu/5ZKOg/reYx8b8RJs5zc44zdfC8uAkDkYSm+FCnjNeUKO6kFyHUgX9mB Up0brb94r2DlM0tPfHPOu/66JLYPDr5pWxITiKMm8P+z7Jj1iQtI/jiLNIqhT8DBMBybNsH/Z ajqTuNsW6K0rB3eODZeqsZrbhqa2hcUalNBtAD1CFfQJVQwf1DU9ce1DyJrWztU2F91ncXqfi gidMHjKtCSf1p0GkD9WV0rHOAYuOC/4kDnrZM2eYyAUSm5c8Wa3gOLOxB+BcF27MkbGwqaBMh 6alxX+9w8af+jdT7us+qZgv0ROPaQBpq5GEW3P6mjoxTsXXSJ29z1J8b3siUyXjnlb1NbKyOB y8Utn+c4e8jdBaFtswfwy4BI8UDedeXzybSh71Vfgbx6yrBdqvSeYgXLPYE=
Archived-At: <https://mailarchive.ietf.org/arch/msg/t2trg/96tf4Ga0CadMzA3PeqkJYIMzGc4>
Cc: "t2trg@irtf.org" <T2TRG@irtf.org>
Subject: Re: [T2TRG] RESTful Design & Security
X-BeenThere: t2trg@irtf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "IRTF Thing-to-Thing \(T2T\) Research-Group-in-creation" <t2trg.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/t2trg>, <mailto:t2trg-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/t2trg/>
List-Post: <mailto:t2trg@irtf.org>
List-Help: <mailto:t2trg-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/t2trg>, <mailto:t2trg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Wed, 08 Mar 2017 10:17:56 -0000
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" > <t2trg-bounces@irtf.org on behalf of hannes.tschofenig@gmx.net> 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 <hannes.tschofenig@gmx.net> 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 <mcr+IETF@sandelman.ca>, Sandelman Software Works >>> -= IPv6 IoT consulting =- >>> >>> >>> >> >
- [T2TRG] RESTful Design & Security Hannes Tschofenig
- Re: [T2TRG] RESTful Design & Security Ari Keränen
- Re: [T2TRG] RESTful Design & Security Michael Richardson
- Re: [T2TRG] RESTful Design & Security Hannes Tschofenig
- Re: [T2TRG] RESTful Design & Security Kovatsch, Matthias
- Re: [T2TRG] RESTful Design & Security Hannes Tschofenig
- Re: [T2TRG] RESTful Design & Security Kovatsch, Matthias
- Re: [T2TRG] RESTful Design & Security Simpson, Robby (GE Energy Connections)
- Re: [T2TRG] RESTful Design & Security Kovatsch, Matthias
- Re: [T2TRG] RESTful Design & Security Göran Selander
- Re: [T2TRG] RESTful Design & Security Hannes Tschofenig
- Re: [T2TRG] RESTful Design & Security Carsten Bormann
- Re: [T2TRG] RESTful Design & Security Carsten Bormann
- Re: [T2TRG] RESTful Design & Security Eliot Lear
- Re: [T2TRG] RESTful Design & Security Carsten Bormann
- Re: [T2TRG] RESTful Design & Security Hannes Tschofenig
- Re: [T2TRG] RESTful Design & Security Göran Selander
- Re: [T2TRG] RESTful Design & Security Hannes Tschofenig
- Re: [T2TRG] RESTful Design & Security Hannes Tschofenig
- [T2TRG] The Many Headed Hydra Nightingale, J. Stephen (Fed)
- Re: [T2TRG] The Many Headed Hydra Carsten Bormann
- Re: [T2TRG] RESTful Design & Security Garcia-Morchon O, Oscar
- Re: [T2TRG] RESTful Design & Security Eliot Lear
- Re: [T2TRG] RESTful Design & Security Hannes Tschofenig
- Re: [T2TRG] RESTful Design & Security Mohit Sethi
- Re: [T2TRG] RESTful Design & Security Garcia-Morchon O, Oscar
- Re: [T2TRG] RESTful Design & Security Hasan Derhamy
- Re: [T2TRG] RESTful Design & Security Eliot Lear