Subject: [T2TRG] RESTful Design & Security

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 6 Mar 2017 17:59:56 +0100

Hi all,

reading through
https://tools.ietf.org/html/draft-keranen-t2trg-rest-iot-03 I was
wondering whether there are some thoughts regarding security protection.

From the web we know that TLS goes very well with RESTful designs.

However, when dealing with intermediaries in the IoT space, such as it
happens with interconnecting different IoT islands, RESTful protocols
appear to run into challenges.

The challenge is quite simple: an application layer security for a
RESTful protocol has to protect some (or must?) header fields.
Intermediaries often change or, in case of a protocol translation from
one IoT technology to another one, completely rebuild header fields.
This breaks application layer security mechanisms.

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?

Ciao
Hannes

---

From: Ari Keränen <[email-masked]>
Date: Mon, 6 Mar 2017 20:20:02 +0000

Hi Hannes,

I agree that the draft is currently thin on the security side and some recommendations would be useful.

What would you recommend for the application security issue you mentioned below?

Cheers,
Ari

> On 06 Mar 2017, at 18:59, Hannes Tschofenig <[email-masked]> wrote:
> 
> Hi all,
> 
> reading through
> _______________________________________________
> T2TRG mailing list
> [email-masked]
> https://www.irtf.org/mailman/listinfo/t2trg

---

From: Michael Richardson <[email-masked]>
Date: Tue, 07 Mar 2017 12:39:26 -0500

> What is the story for providing application layer security?

OSCOAP seems to be end-to-end to me.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 7 Mar 2017 19:39:24 +0100

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

---

From: "Kovatsch, Matthias" <[email-masked]>
Date: Tue, 7 Mar 2017 18:45:05 +0000

On big propaganda tour? :P

Regards
Matthias

Sent from my phone, limitations might apply.

-----Original Message-----
From: Hannes Tschofenig [[email-masked]]
Received: Tuesday, 07 Mar 2017, 19:39
To: Michael Richardson [[email-masked]]
CC: [email-masked] [[email-masked]]
Subject: Re: [T2TRG] RESTful Design & Security

* you mix protocols,

Ciao
Hannes

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 7 Mar 2017 20:10:35 +0100

Hi Matthias,

I know that this is a research group and everyone can create whatever
they want.

We briefly talked about security at the IoT directorate conference call
and I would be interesting to hear what works and what does not work for
others.

Ciao
Hannes

On 03/07/2017 07:45 PM, Kovatsch, Matthias wrote:
> *From:* Hannes Tschofenig [[email-masked]]
> *Received:* Tuesday, 07 Mar 2017, 19:39
> *To:* Michael Richardson [[email-masked]]
> *CC:* [email-masked] [[email-masked]]
> *Subject:* Re: [T2TRG] RESTful Design & Security
>

---

From: "Kovatsch, Matthias" <[email-masked]>
Date: Tue, 7 Mar 2017 19:36:35 +0000

Fair enough.

Yes, I am on this IoT Directorate. I would say a large fraction of the T2TRG participants has been arguing that the Internet of Gateways is not a good approach. Your security-related summary proves this point.

I personally don't see end-to-end security happening if we keep mixing application protocols, keep using black-magic middleboxes, and keep using proprietary interfaces at the device level. We need something end-to-end (or T2T) for end-to-end security.

Best wishes
Matthias

-----Original Message-----
From: Hannes Tschofenig [[email-masked]]
Received: Tuesday, 07 Mar 2017, 20:10
To: Kovatsch, Matthias (CT RDA NEC EMB-DE) [[email-masked]]; [email-masked] [[email-masked]]
CC: [email-masked] [[email-masked]]
Subject: Re: [T2TRG] RESTful Design & Security

Hi Matthias,

Ciao
Hannes

---

From: "Simpson, Robby (GE Energy Connections)" <[email-masked]>
Date: Tue, 7 Mar 2017 19:47:04 +0000

Personally, I’m a big fan of end-to-end and think that is the correct approach.

However, pragmatically, I realize this is not always possible.

I haven’t followed it for a while, but there was some activity in httpbis at one point for resource/object-level security (https://tools.ietf.org/wg/httpbis/draft-ietf-httpbis-encryption-encoding/).  If we limit the discussion to protocols that support content codings (e.g., HTTP and CoAP), then I would think defining a coding that specifies the resource-level security aspects would achieve quite a lot and would be able to preserve aspects through protocol conversion.

- Robby

Robby Simpson, PhD
System Architect
GE
Grid Solutions
M: +1 404 219 1851
[email-masked]

From: T2TRG <[email-masked]> on behalf of "Kovatsch, Matthias" <[email-masked]>
Date: Tuesday, March 7, 2017 at 2:36 PM
To: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: EXT: Re: [T2TRG] RESTful Design & Security

Fair enough.

Best wishes
Matthias

-----Original Message-----
From: Hannes Tschofenig [[email-masked]]
Received: Tuesday, 07 Mar 2017, 20:10
To: Kovatsch, Matthias (CT RDA NEC EMB-DE) [[email-masked]]; [email-masked] [[email-masked]]
CC: [email-masked] [[email-masked]]
Subject: Re: [T2TRG] RESTful Design & Security
Hi Matthias,

Ciao
Hannes

On 03/07/2017 07:45 PM, Kovatsch, Matthias wrote:
> https://www.irtf.org/mailman/listinfo/t2trg<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.irtf.org_mailman_listinfo_t2trg&d=DwMF-g&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI&r=4w13vdCVEUj_vaCSQNdKRf25O0P4iaVn04ElXLrB_ak&m=k7IqC4lOSBeG5yZT3lwAYgfq7isPTJ1x7lhosU4sI0U&s=6FyGiDTW-U31FpvuMwpkVdhppH4XLcvlAPPiMqvTUIo&e=>
>

---

From: "Kovatsch, Matthias" <[email-masked]>
Date: Tue, 7 Mar 2017 20:02:24 +0000

Yes, that sounds very reasonable. It does include changing the (end-)devices to support this new approach.

In the W3C Web of Things, we have the idea to retrofit information such as encoding and security aspects through interface descriptions that can be used across multiple IoT protocols (WoT Thing Description). Still it requires to upgrade what is accepted and served by the devices within the protocol used...

Ciao
Matthias

-----Original Message-----
From: Simpson, Robby (GE Energy Connections) [[email-masked]]
Received: Tuesday, 07 Mar 2017, 20:47
To: Kovatsch, Matthias (CT RDA NEC EMB-DE) [[email-masked]]; [email-masked] [[email-masked]]; [email-masked] [[email-masked]]
CC: [email-masked] [[email-masked]]
Subject: Re: [T2TRG] RESTful Design & Security

- Robby

Robby Simpson, PhD
System Architect
GE
Grid Solutions
M: +1 404 219 1851
[email-masked]

Fair enough.

Best wishes
Matthias

-----Original Message-----
From: Hannes Tschofenig [[email-masked]]
Received: Tuesday, 07 Mar 2017, 20:10
To: Kovatsch, Matthias (CT RDA NEC EMB-DE) [[email-masked]]; [email-masked] [[email-masked]]
CC: [email-masked] [[email-masked]]
Subject: Re: [T2TRG] RESTful Design & Security
Hi Matthias,

Ciao
Hannes

---

From: Göran Selander <[email-masked]>
Date: Wed, 8 Mar 2017 08:30:30 +0000

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.

> OSCOAP does not work when

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

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

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

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 8 Mar 2017 10:25:48 +0100

Thanks for the pointer to the document, Robby. I wasn't aware of this
spec and I have to gain a better understanding of why JOSE/COSE isn't
applicable but it is certainly a worthwhile path to explore.

Ciao
Hannes

On 03/07/2017 08:47 PM, Simpson, Robby (GE Energy Connections) wrote:
> I haven’t followed it for a while, but there was some activity in
> httpbis at one point for resource/object-level security
> (https://tools.ietf.org/wg/httpbis/draft-ietf-httpbis-encryption-encoding/). 
> If we limit the discussion to protocols that support content codings
> (e.g., HTTP and CoAP), then I would think defining a coding that
> specifies the resource-level security aspects would achieve quite a lot
> and would be able to preserve aspects through protocol conversion.
> 
>  
> 
> - Robby
> 
>  
> 
>  
> 
> Robby Simpson, PhD
> 
> System Architect
> 
> GE
> 
> Grid Solutions
> 
> M: +1 404 219 1851
> 
> [email-masked]
> 
>  
> 
>  
> 
> *From: *T2TRG <[email-masked]> on behalf of "Kovatsch, Matthias"
> <[email-masked]>
> *Date: *Tuesday, March 7, 2017 at 2:36 PM
> *To: *"[email-masked]" <[email-masked]>,
> "[email-masked]" <[email-masked]>
> *Cc: *"[email-masked]" <[email-masked]>
> *Subject: *EXT: Re: [T2TRG] RESTful Design & Security
> 
>  
> 
> Fair enough.
> 
> Yes, I am on this IoT Directorate. I would say a large fraction of the
> T2TRG participants has been arguing that the Internet of Gateways is not
> a good approach. Your security-related summary proves this point.
> 
> I personally don't see end-to-end security happening if we keep mixing
> application protocols, keep using black-magic middleboxes, and keep
> using proprietary interfaces at the device level. We need something
> end-to-end (or T2T) for end-to-end security.
> 
> Best wishes
> Matthias
> 
> 
> 
> *Received:* Tuesday, 07 Mar 2017, 20:10
> *To:* Kovatsch, Matthias (CT RDA NEC EMB-DE)
> [[email-masked]]; [email-masked]
> [[email-masked]]
> *CC:* [email-masked] [[email-masked]]
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.irtf.org_mailman_listinfo_t2trg&d=DwMF-g&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI&r=4w13vdCVEUj_vaCSQNdKRf25O0P4iaVn04ElXLrB_ak&m=k7IqC4lOSBeG5yZT3lwAYgfq7isPTJ1x7lhosU4sI0U&s=6FyGiDTW-U31FpvuMwpkVdhppH4XLcvlAPPiMqvTUIo&e=>
>> 
>

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 8 Mar 2017 10:43:04 +0100

On 8 Mar 2017, at 10:25, Hannes Tschofenig <[email-masked]> wrote:
> 
> why JOSE/COSE isn’t applicable

JOSE/COSE is generally applicable to the problem space.

The specific draft mentioned additionally undertakes to do some streaming integrity, where partially delivered messages can already be authenticated as such.  Compare the ongoing discussion of block-wise transfer for OSCOAP.

Grüße, Carsten

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 8 Mar 2017 10:59:33 +0100

> From the web we know that TLS goes very well with RESTful designs.

HTTPS works well as long as your security is binary: You switch it off or you switch it on; there are no different security requirements for different applications.  With this restriction, you can encode “security=on” in the URI (here: by choosing a different URI scheme, which unfortunately has other side effects).  (The disadvantages of coloring all cases with the same brush are also well known in the Big Web; I’m not discussing this here.  EV certs are a weird way to try escaping this restriction, but aren’t generally applicable to REST applications.)

It is well understood that we currently don’t have a good way to associate more extensive security information with a URI when that is required.  This comes up again and again (say, https://github.com/core-wg/oscoap/issues/41).  Is augmenting the URI by other information as in link-format the right way to do this in a more general scope?  This is an interesting subject for discussion.

Grüße, Carsten

---

From: Eliot Lear <[email-masked]>
Date: Wed, 8 Mar 2017 11:02:45 +0100

Matthias,

I think the key question that everyone seems to be dancing around is this:

What is an Internet host in the context of IoT?  What are the minimum
qualities it must possess?  I don't mean this to be a vote, but more of
a law of physics sort of thing.  For instance, does a host have a secure
unique identity?  What capabilities must it have?  I would expect them
to be very few, but there are assuredly some...

Eliot

On 3/7/17 8:36 PM, Kovatsch, Matthias wrote:
> T2TRG participants has been arguing that the Internet of Gateways is
> not a good approach. Your security-related summary proves this point.
>

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 8 Mar 2017 11:08:54 +0100

> the context, e.g. CoAP pub/sub.

Apart from the HTTPS straightjacket I just discussed, this is the other interesting design issue about RESTful security.

Should we design all objects being interchanged in such a way that they can be signed by themselves, which implies that they don’t need context to interpret them?

E.g., if I

GET coap://bathroom.cabo.space/temperature

a typical result in a REST world might be a CBOR or JSON object saying

[{"u":"Cel","v":23.125}]

But there is no point in signing that object by itself; it does not mean anything useful.

A signed object would need to include the fact that this is about my bathroom, and some freshness information (such as the current time).  If you don’t want to use absolute time for freshness, you would include a request nonce, which makes this object useless for a different request, so you might as well bind it to the request in other ways (e.g., include the URI instead of some generic semantic information tying this to my bathroom).

The OSCOAP approach is to simply bind responses to the relevant information in the request, so all this happens “automatically” (you wish).

Grüße, Carsten

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 8 Mar 2017 11:17:39 +0100

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

---

From: Göran Selander <[email-masked]>
Date: Wed, 8 Mar 2017 10:31:00 +0000

Hi Hannes,

>about the challenges we encounter in our deployments.

I am interested in the challenges you meet in your deployments. But if
OSCOAP doesn’t address your issues it doesn’t mean that it is useless,
which is the impression I have got (right or wrong) from your previous
inputs to the IETF on the topic.

Göran

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 8 Mar 2017 15:13:56 +0100

Hi Goeran,

> inputs to the IETF on the topic.

When Michael said that OSCOAP is the solution for end-to-end security I
had to respond. Either Michael is not aware of the limitations or they
do not matter for his use cases.

But more generally, there are two ways to do standardization:

Approach A: Let a thousand flowers bloom
Approach B: Try to minimize the number of solutions

We seem to be more and more focused on approach A. This has the benefit
that both the leadership and the folks working on the specifications are
happy. Unfortunately, there is a price to pay in the future when
companies end up having lots of solutions to choose from. They are
confused and fewer products are interoperable as a result. This is not
necessarily a new situation since we have seen the results also in other
security areas.

Ciao
Hannes

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 8 Mar 2017 15:13:17 +0100

Hi Eliot,

this would indeed be a good conversation to have. I have tried to
trigger it a couple of times in context of the IoT device classes but it
is very hard to get people to state what their minimum assumptions are.

I believe it has to do with the type of standardization approach we are
exercising today and this gives us a hard time to describe the big
picture of how the various building blocks are supposed to work
together. In fact, the picture becomes extremely complex and fragmented
since there are just so many options while at the same time we envision
super constrained devices. The T2TRG security document
(draft-irtf-t2trg-iot-seccons-01) confirms this and happily talks about
normal IPsec/IKE, diet IPsec, HIP, MIKEY, OSCOAP, JOSE, COSE, etc. etc.

Ciao
Hannes

---

From: "Nightingale, J. Stephen (Fed)" <[email-masked]>
Date: Wed, 8 Mar 2017 09:54:04 -0500

.. of failing to unsubscribe from this mailgroup.
After going to the mailman site listed at the bottom of each message, thus:

   T2TRG mailing list
   [email-masked]

and trying to unsubscribe and failing, the next step is to send a direct 
message to t2trg-request.  Of course the well-known typo site 'ietf.org' 
fails to recognize any such group as t2trg, so finally you land on 
[email-masked]' with a subject and body marked unsubscribe. 
And yet the flood of T2TRG messages continues unabated.

I shouldn't have to deal with this through my mail service's Spam 
filter.  I'm running a dozen mailman groups myself and am familiar 
enough with the interface. People on my mailgroups don't have a problem 
unsubscribing.  So don't give me any snarky RTFM responses.

Please make it possible to unsubscribe from this mailgroup.

Stephen Nightingale.

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 8 Mar 2017 16:28:28 +0100

Hi Stephen,

This list has the headers inserted that should allow a modern mail reader to offer an unsubscribe button (my iphone certainly does). If you tried something else and that failed, please do send the error messages you got to Ari or me.

Sent from mobile

> On 8 Mar 2017, at 15:54, Nightingale, J. Stephen (Fed) <[email-masked]> wrote:
> 
> 
> and trying to unsubscribe and failing, the next step is to send a direct message to t2trg-request.  Of course the well-known typo site 'ietf.org' fails to recognize any such group as t2trg, so finally you land on [email-masked]' with a subject and body marked unsubscribe. And yet the flood of T2TRG messages continues unabated.
> 
> I shouldn't have to deal with this through my mail service's Spam filter.  I'm running a dozen mailman groups myself and am familiar enough with the interface. People on my mailgroups don't have a problem unsubscribing.  So don't give me any snarky RTFM responses.
>

---

From: "Garcia-Morchon O, Oscar" <[email-masked]>
Date: Wed, 8 Mar 2017 15:31:46 +0000

Hi Hannes,

the document " draft-irtf-t2trg-iot-seccons-01" summarizes protocols.  But I do not think that we do this happily but seriously. Summarizing existing protocols/work is one of the goals of the document.

The document also acknowledges that devices have different capabilities and requirements, also in terms of security. In my view, this fits with the idea of minimum requirements. It would be great to have your input on your use cases and your views on minimum assumptions in different deployment scenarios/security capabilities of different types of devices.

Cheers, Oscar.

-----Original Message-----
From: T2TRG [mailto:[email-masked]] On Behalf Of Hannes Tschofenig
Sent: Wednesday, March 8, 2017 3:13 PM
To: Eliot Lear <[email-masked]>; Kovatsch, Matthias <[email-masked]>; [email-masked]
Cc: [email-masked]
Subject: Re: [T2TRG] RESTful Design & Security

Hi Eliot,

this would indeed be a good conversation to have. I have tried to trigger it a couple of times in context of the IoT device classes but it is very hard to get people to state what their minimum assumptions are.

I believe it has to do with the type of standardization approach we are exercising today and this gives us a hard time to describe the big picture of how the various building blocks are supposed to work together. In fact, the picture becomes extremely complex and fragmented since there are just so many options while at the same time we envision super constrained devices. The T2TRG security document
(draft-irtf-t2trg-iot-seccons-01) confirms this and happily talks about normal IPsec/IKE, diet IPsec, HIP, MIKEY, OSCOAP, JOSE, COSE, etc. etc.

Ciao
Hannes

On 03/08/2017 11:02 AM, Eliot Lear wrote:
> qualities it must possess?  I don't mean this to be a vote, but more
> of a law of physics sort of thing.  For instance, does a host have a
> secure unique identity?  What capabilities must it have?  I would
> expect them to be very few, but there are assuredly some...
>
> Eliot
>
>
>> Yes, I am on this IoT Directorate. I would say a large fraction of
>> the T2TRG participants has been arguing that the Internet of Gateways
>> is not a good approach. Your security-related summary proves this point.
>>
>> I personally don't see end-to-end security happening if we keep
>> mixing application protocols, keep using black-magic middleboxes, and
>> keep using proprietary interfaces at the device level. We need
>> something end-to-end (or T2T) for end-to-end security.
>>
>> Best wishes
>> Matthias
>>
>>
>>
>> We briefly talked about security at the IoT directorate conference
>> call and I would be interesting to hear what works and what does not
>> work for others.
>>
>> Ciao
>> Hannes
>>
>>
>> >>     > Needless to say that these challenges have also been
>> >> observed
>> in other
>> >> Michael Richardson <[email-masked]>, Sandelman Software
>> >> Works  -= IPv6 IoT consulting =-
>> >>
>> >>
>> >>
>> >
>> >
>> >

________________________________
The information contained in this message may be confidential and legally protected under applicable law. The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender by return e-mail and destroy all copies of the original message.

---

From: Eliot Lear <[email-masked]>
Date: Wed, 8 Mar 2017 16:46:58 +0100

Oscar,

That's a great document.  In some ways, it's really several documents
all rolled up into one.  But Let me ask some leading questions:

  * Is my network-connected refrigerator a Thing or a component?
  * Is the thermostat in my network-connected refrigerator a Thing or a
    component?
  * Is my network-connected car a Thing or a component?
  * Is the engine that sits on the CAN bus a Thing or a component?

What distinguishes a Thing from a component and when do your security
considerations apply, and when do they not?

Eliot

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 8 Mar 2017 20:14:50 +0100

Hi Carsten,

an additional consideration is that confidentiality protection of the
payload still reveals a lot of information about what is being accessed
via the URI.

Ciao
Hannes

On 03/08/2017 11:08 AM, Carsten Bormann wrote:
>> 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.
> 
> Apart from the HTTPS straightjacket I just discussed, this is the
> other interesting design issue about RESTful security.
> 
> Should we design all objects being interchanged in such a way that
> they can be signed by themselves, which implies that they don’t need
> context to interpret them?
> 
> E.g., if I
> 
> A signed object would need to include the fact that this is about my
> bathroom, and some freshness information (such as the current time).
> If you don’t want to use absolute time for freshness, you would
> include a request nonce, which makes this object useless for a
> different request, so you might as well bind it to the request in
> other ways (e.g., include the URI instead of some generic semantic
> information tying this to my bathroom).
> 
> The OSCOAP approach is to simply bind responses to the relevant
> information in the request, so all this happens “automatically” (you
> wish).
> 
> Grüße, Carsten
> 
> _______________________________________________ T2TRG mailing list 
> [email-masked] https://www.irtf.org/mailman/listinfo/t2trg
>

---

From: Mohit Sethi <[email-masked]>
Date: Thu, 9 Mar 2017 16:27:55 +0200

Hi Elliot

I wonder what difference does it make if we call something a thing, 
component, device, or machine. We have the terms thing-to-thing, 
device-to-device and machine-to-machine communication from different 
(standards) folks.

I would believe that if a thing is connected to another thing or 
network, then the security considerations apply.

Thanks
Mohit

On 03/08/2017 05:46 PM, Eliot Lear wrote:
>   * Is the thermostat in my network-connected refrigerator a Thing or
>     a component?
>> To: Eliot Lear<[email-masked]>; Kovatsch, Matthias<[email-masked]>;[email-masked]
>> Cc:[email-masked]
>>>> [[email-masked]];[email-masked]
>>>> [[email-masked]]
>>>> *CC:[email-masked]  [[email-masked]]
>>>>> *CC:[email-masked]  [[email-masked]]
>>>>>> Hannes Tschofenig<[email-masked]>  wrote:
>>>>>> Michael Richardson<[email-masked]>, Sandelman Software

---

From: "Garcia-Morchon O, Oscar" <[email-masked]>
Date: Thu, 9 Mar 2017 14:32:38 +0000

Hi Eliot,

i believe that your two examples (fridge and car) describe a system (fridge and car) within a larger system (smart home or V2X). More complex scenarios exist.

You could analyze such scenarios by decomposing the larger system into subsystems (domains) and applying the security considerations to each of the domains in which the "smart things or smart components" in that domain talk to each other.

Does this help you further?Would you analyze this in a different way? Do you think that this explanation should be included in the our document?

Cheers, Oscar.

________________________________
From: Eliot Lear <[email-masked]>
Sent: Wednesday, March 8, 2017 4:46 PM
To: Garcia-Morchon O, Oscar; Hannes Tschofenig; Kovatsch, Matthias; [email-masked]
Cc: [email-masked]
Subject: Re: [T2TRG] RESTful Design & Security

Oscar,

That's a great document.  In some ways, it's really several documents all rolled up into one.  But Let me ask some leading questions:

  *   Is my network-connected refrigerator a Thing or a component?
  *   Is the thermostat in my network-connected refrigerator a Thing or a component?
  *   Is my network-connected car a Thing or a component?
  *   Is the engine that sits on the CAN bus a Thing or a component?

What distinguishes a Thing from a component and when do your security considerations apply, and when do they not?

Eliot

Hi Hannes,

Cheers, Oscar.

-----Original Message-----
From: T2TRG [mailto:[email-masked]] On Behalf Of Hannes Tschofenig
Sent: Wednesday, March 8, 2017 3:13 PM
To: Eliot Lear <[email-masked]><mailto:[email-masked]>; Kovatsch, Matthias <[email-masked]><mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [T2TRG] RESTful Design & Security

Hi Eliot,

Ciao
Hannes

Matthias,

Eliot

Fair enough.

Best wishes
Matthias

-----Original Message-----
*From:* Hannes Tschofenig [[email-masked]<mailto:[email-masked]>]
*Received:* Tuesday, 07 Mar 2017, 20:10
*To:* Kovatsch, Matthias (CT RDA NEC EMB-DE)
[[email-masked]<mailto:[email-masked]>]; [email-masked]<mailto:[email-masked]>
[[email-masked]<mailto:[email-masked]>]
*CC:* [email-masked]<mailto:[email-masked]> [[email-masked]<mailto:[email-masked]>]
*Subject:* Re: [T2TRG] RESTful Design & Security

Hi Matthias,

Ciao
Hannes

Regards
Matthias

-----Original Message-----
*From:* Hannes Tschofenig [[email-masked]<mailto:[email-masked]>]
*Received:* Tuesday, 07 Mar 2017, 19:39
*To:* Michael Richardson [[email-masked]<mailto:[email-masked]>]
*CC:* [email-masked]<mailto:[email-masked]> [[email-masked]<mailto:[email-masked]>]
*Subject:* Re: [T2TRG] RESTful Design & Security

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

Ciao
Hannes

observed

in other

--
Michael Richardson <[email-masked]><mailto:[email-masked]>, Sandelman Software
Works  -= IPv6 IoT consulting =-

_______________________________________________
T2TRG mailing list
[email-masked]<mailto:[email-masked]>
https://www.irtf.org/mailman/listinfo/t2trg

_______________________________________________
T2TRG mailing list
[email-masked]<mailto:[email-masked]>
https://www.irtf.org/mailman/listinfo/t2trg

---

From: Hasan Derhamy <[email-masked]>
Date: Thu, 9 Mar 2017 14:59:00 +0000

Hi,

Would be interesting to see how systems of systems gets mapped within your considerations.

http://sebokwiki.org/wiki/Systems_of_Systems_(SoS)

-Hasan

From: T2TRG [mailto:[email-masked]] On Behalf Of Garcia-Morchon O, Oscar
Sent: den 9 mars 2017 15:33
To: Eliot Lear; Hannes Tschofenig; Kovatsch, Matthias; [email-masked]
Cc: [email-masked]
Subject: Re: [T2TRG] RESTful Design & Security

Hi Eliot,

Cheers, Oscar.

________________________________
From: Eliot Lear <[email-masked]<mailto:[email-masked]>>
Sent: Wednesday, March 8, 2017 4:46 PM
To: Garcia-Morchon O, Oscar; Hannes Tschofenig; Kovatsch, Matthias; [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [T2TRG] RESTful Design & Security

Oscar,

Eliot

Hi Hannes,

Cheers, Oscar.

-----Original Message-----

Hi Eliot,

Ciao

Hannes

Matthias,

Eliot

Fair enough.

Best wishes

Matthias

-----Original Message-----

Hi Matthias,

they want.

work for others.

Ciao

Hannes

Regards

Matthias

-----Original Message-----

* you mix protocols,

aggregation), and

or MQTT.

Ciao

Hannes

observed

in other

--

T2TRG mailing list

T2TRG mailing list

---

From: Eliot Lear <[email-masked]>
Date: Thu, 9 Mar 2017 16:00:02 +0100

Hi Oskar,

I'm sorry I wasn't clear, but my point is that one needs to be able to
answer these sorts of questions in order to determine what the end is in
"end to end" security and shat the identity model for these things are. 
There may be little if any networking available to the "end"  in some cases.

Eliot

On 3/9/17 3:32 PM, Garcia-Morchon O, Oscar wrote:
>
> Hi Eliot,
>
>
> i believe that your two examples (fridge and car) describe a system
> (fridge and car) within a larger system (smart home or V2X). More
> complex scenarios exist.
>
>
> You could analyze such scenarios by decomposing the larger system into
> subsystems (domains) and applying the security considerations to each
> of the domains in which the "smart things or smart components" in that
> domain talk to each other. 
>
>
> Does this help you further?Would you analyze this in a different way?
> Do you think that this explanation should be included in the our
> document? 
>
>
> Cheers, Oscar.
>
>
> ------------------------------------------------------------------------
> *From:* Eliot Lear <[email-masked]>
> *Sent:* Wednesday, March 8, 2017 4:46 PM
> *To:* Garcia-Morchon O, Oscar; Hannes Tschofenig; Kovatsch, Matthias;
> [email-masked]
> *Cc:* [email-masked]