Re: [T2TRG] RESTful Design & Security

[Hannes Tschofenig <[e-mail]>]

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:
> 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:
>> 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
>>
>>
>>
>> Sent from my phone, limitations might apply.
>>
>> -----Original Message-----
>> *From:* Hannes Tschofenig [[e-mail]]
>> *Received:* Tuesday, 07 Mar 2017, 20:10
>> *To:* Kovatsch, Matthias (CT RDA NEC EMB-DE)
>> [[e-mail]]; [e-mail]
>> [[e-mail]]
>> *CC:* [e-mail] [[e-mail]]
>> *Subject:* Re: [T2TRG] RESTful Design & Security
>>
>> 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:
>> > On big propaganda tour? :P
>> >
>> > Regards
>> > Matthias
>> >
>> >
>> > Sent from my phone, limitations might apply.
>> >
>> > -----Original Message-----
>> > *From:* Hannes Tschofenig [[e-mail]]
>> > *Received:* Tuesday, 07 Mar 2017, 19:39
>> > *To:* Michael Richardson [[e-mail]]
>> > *CC:* [e-mail] [[e-mail]]
>> > *Subject:* Re: [T2TRG] RESTful Design & Security
>> >
>> > 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 =-
>> >>
>> >>
>> >>
>> >
>> >
>> >
>> > _______________________________________________
>> > T2TRG mailing list
>> > [e-mail]
>> > https://www.irtf.org/mailman/listinfo/t2trg
>> >
>>
>>
>>
>> _______________________________________________
>> T2TRG mailing list
>> [e-mail]
>> https://www.irtf.org/mailman/listinfo/t2trg
>