Subject: Re: [T2TRG] New Version Notification for draft-irtf-t2trg-iot-seccons-02.txt

From: "Garcia-Morchon O, Oscar" <[email-masked]>
Date: Mon, 3 Apr 2017 07:10:38 +0000

Hi,

we have submitted a new version of the Internet Draft on security considerations for the IoT.
Comments are welcome.

https://tools.ietf.org/html/draft-irtf-t2trg-iot-seccons-02

Regards, Oscar.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Friday, March 31, 2017 2:11 PM
To: Mohit Sethi <[email-masked]>; Kumar, Sandeep <[email-masked]>; Kumar, Sandeep <[email-masked]>; Garcia-Morchon O, Oscar <[email-masked]>; [email-masked]; [email-masked]
Subject: New Version Notification for draft-irtf-t2trg-iot-seccons-02.txt

A new version of I-D, draft-irtf-t2trg-iot-seccons-02.txt
has been successfully submitted by Oscar Garcia-Morchon and posted to the IETF repository.

Name:draft-irtf-t2trg-iot-seccons
Revision:02
Title:State of the Art and Challenges for the Internet of Things
Document date:2017-03-31
Group:t2trg
Pages:56
URL:            https://www.ietf.org/internet-drafts/draft-irtf-t2trg-iot-seccons-02.txt
Status:         https://datatracker.ietf.org/doc/draft-irtf-t2trg-iot-seccons/
Htmlized:       https://tools.ietf.org/html/draft-irtf-t2trg-iot-seccons-02
Htmlized:       https://datatracker.ietf.org/doc/html/draft-irtf-t2trg-iot-seccons-02
Diff:           https://www.ietf.org/rfcdiff?url2=draft-irtf-t2trg-iot-seccons-02

Abstract:
   The Internet of Things concept refers to the usage of standard
   Internet protocols to allow for human-to-thing or thing-to-thing
   communication.  The security needs are well-recognized and and many
   standardization steps have been taken, for example, specification of
   CoAP over DTLS.  However, security challenges still exist and there
   are some use cases that lack a suitable solution.  This document
   first provides an overview of security architecture, its deployment
   model, security needs in the context of the lifecycle of a thing, as
   well as the state of the art on IoT security.  Then, we discuss the
   concept of security profiles for the successful roll-out of secure
   IoT applications and describe remaining security challenges in the
   IoT.

Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

________________________________
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: Tue, 4 Apr 2017 12:32:18 +0200

Hi Oscar,

While I appreciate the draft, there is an elephant in the room.  Not a
day passes when we hear of yet another compromise of a so-called "IoT"
system.  Sometimes these compromises are trivial, and sometimes they are
involved.  At the end of the day, the sheer quantity of Things mandates
some form of network-level protection that the draft should discuss, to
protect those devices from attack.  As was mentioned in the f2f, what if
Bob turns out to be, or becomes evil, or is otherwise 0wn3d by Chuck?

Eliot

On 4/3/17 9:10 AM, Garcia-Morchon O, Oscar wrote:
> _______________________________________________
> T2TRG mailing list
> [email-masked]
> https://www.irtf.org/mailman/listinfo/t2trg
>

---

From: Barry Raveendran Greene <[email-masked]>
Date: Tue, 4 Apr 2017 07:22:03 -0700

Hi Team,

I agree with Eliot. The draft is disconnected with reality. I attend a lot of “IoT  Hack-a-thons” out in Asia (my wife is usually a judge). These are always huge events whose participation exceeds the organizer’s expectations. At no time do I see any of the teams ever think about security. The few times I offer to give “mini-IoT security workshops” get little interest. Why? Because everyone is focused on the IoT coding for the function - not the lifecycle. 

The reality with IoT devices is that drafts like this are idea, but don’t match reality. I’m now thinking a head what we have to do on the Network in Operators when my “rate of customer infection” goes from 20% - 30% (today) to 70% - 80%. Connected Appliances with a +10 year lifecycle with the owners not maintaining them, is a new world for us.

I survey of all the IoT Security “standards” and “guidelines” assumes we can remediate the violated IoT device. I put forward for the IETF that we cannot assume remediation. We have to assume that we cannot remediate. Hence, we need other tools in the network to mitigate the risk. 

Barry

> On Apr 4, 2017, at 3:32 AM, Eliot Lear <[email-masked]> wrote:
> 
> Hi Oscar,
> 
> saag mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/saag

---

From: Peter Gutmann <[email-masked]>
Date: Wed, 5 Apr 2017 06:44:27 +0000

Barry Raveendran Greene <[email-masked]> writes:

>I survey of all the IoT Security “standards” and “guidelines” assumes we can
>remediate the violated IoT device. I put forward for the IETF that we cannot
>assume remediation. We have to assume that we cannot remediate. Hence, we
>need other tools in the network to mitigate the risk.

That's always struck me as a bit odd as well when I read some standard for
secure firmware update, for IoS devices like the Raspberry Pi and similar
Linux-based/like devices the update process is already sorted (apt-get update)
and for SCADA/embedded or whatever running some RTOS it can't be updated,
whatever you ship today will be used in that form for the next ten to twenty
years (or more, I've seen fifty-year-old ladder logic controllers still in
active use).  So the diagram in Figure 1 is replaced after "application
running" with a dotted line leading up to the present day, there's no updates,
no reconfiguration, no maintenance and re-bootstrapping, it just keeps running
once put into service.

I don't want to start nitpicking individual bits of the draft, but I think it
would help if it laid out what's meant by "IoT", are we talking Android phones
(mentioned in one place), fridges, PLCs, routers, what?  Or perhaps come up
with a few sample device profiles and provide specific advice for each case.
At the moment it's so generic that it seems to be one-size-fits-nothing...
it's like trying to write safe-driving instructions that have to cover cars,
buses, trucks, motorbikes, locomotives, boats, oil tankers, jet skis, jet
aircraft, jet bikes, scooters, and submarines.

Peter.

---

From: Barry Raveendran Greene <[email-masked]>
Date: Wed, 5 Apr 2017 06:56:22 -0700

> On Apr 4, 2017, at 11:44 PM, Peter Gutmann <[email-masked]> wrote:
> 
> I don't want to start nitpicking individual bits of the draft

I’m OK with the draft. It is a good solid document for anyone who is taking an interest in secure IoT or looking to build a “RFP security requirements” checklist. We need this. Good work. 

But, from an IETF POV …. where we have to think forward to the next set of engineering problems, we need to be mindful of your illustration …

> So the diagram in Figure 1 is replaced after "application

What does a network do? Lets start digging into that problem.

---

From: "Garcia-Morchon O, Oscar" <[email-masked]>
Date: Thu, 6 Apr 2017 07:27:18 +0000

Hi Barry,

It is sad to hear your experience during the hack-a-thons. Network security can indeed mitigate threats if devices have certain security vulnerabilities. Which methods would you suggest to include in the document? What are the key challenges in your opinion for IoT network security?

There are other required functionalities next to network security, for instance, transport security or security software updates. We believe that it is also important to mention those. Do you agree? It can always happen that devices (even networking devices such as IoT routers,...) have vulnerabilities and we have to remediate them.

The document describes them in the context of the lifecycle of a device since this summarizes the interactions of users, manufacturers, and network operators. We believe that it is important to describe these interactions since they show how users use the IoT systems, the challenges for manufactures, etc. Do you agree?

Regards, Oscar.

-----Original Message-----
From: T2TRG [mailto:[email-masked]] On Behalf Of Barry Raveendran Greene
Sent: Tuesday, April 4, 2017 4:22 PM
To: Eliot Lear <[email-masked]>
Cc: Garcia-Morchon O, Oscar <[email-masked]>; Mohit Sethi <[email-masked]>; [email-masked]; [email-masked]; Kumar, Sandeep <[email-masked]>
Subject: Re: [T2TRG] [saag] New Version Notification for draft-irtf-t2trg-iot-seccons-02.txt

Hi Team,

Barry

> system.  Sometimes these compromises are trivial, and sometimes they 
> are involved.  At the end of the day, the sheer quantity of Things 
> mandates some form of network-level protection that the draft should 
> discuss, to protect those devices from attack.  As was mentioned in 
> the f2f, what if Bob turns out to be, or becomes evil, or is otherwise 0wn3d by Chuck?
> 
> Eliot
> 
> 
>> To: Mohit Sethi <[email-masked]>; Kumar, Sandeep 
>> <[email-masked]>; Kumar, Sandeep 
>> <[email-masked]>; Garcia-Morchon O, Oscar 
>> <[email-masked]>; [email-masked]; 
>> [email-masked]
>> Document date:2017-03-31 Group:t2trg
>> Pages:56

---

From: "Garcia-Morchon O, Oscar" <[email-masked]>
Date: Thu, 6 Apr 2017 07:27:38 +0000

Dear Peter,

Thanks for your remark. IoT is indeed a broad concept. We will refer to the definition of device classes. Do you think that this is a good approach?

>>>" At the moment it's so generic that it seems to be one-size-fits-nothing...
it's like trying to write safe-driving instructions that have to cover cars, buses, trucks, motorbikes, locomotives, boats, oil tankers, jet skis, jet aircraft, jet bikes, scooters, and submarines."

I agree that writing safe-driving instructions for cars, jets, etc ... is difficult. The jet goes faster than the car so I fully agree, recommending a common speed limit does not make sense. However, there are common guidelines, for instance, do not collide as a general rule.

It is not the intention of the draft to create common instructions. As for the cars, jets, ... this does not make sense.

The main goals are:
- summarize existing solutions out there and in IETF
- summarize security considerations and challenges that should be addressed in the future

Which existing solutions, security considerations, or challenges apply to an given IoT system depend on the IoT system itself and how it is used (this is similar to the example of cars, ...). In the document:
- we have some text on the process to identify risks, threats, and mitigation strategies that should help system designers and implementers.
- Similarly to the different transportation means that require different safety guidelines, we also have some initial text discussing security profiles. In an abstract way, this is the same idea... IoT systems (transportation systems) are very diverse and addressing the security threats require some specific type of solutions. A security profile could include some recommendations/guidelines for a specific type of IoT systems.

Does this make sense to you?

Kind regards, Oscar.

-----Original Message-----
From: saag [mailto:[email-masked]] On Behalf Of Peter Gutmann
Sent: Wednesday, April 5, 2017 8:44 AM
To: Barry Raveendran Greene <[email-masked]>; Eliot Lear <[email-masked]>
Cc: Mohit Sethi <[email-masked]>; [email-masked]; [email-masked]; Kumar, Sandeep <[email-masked]>
Subject: Re: [saag] [T2TRG] New Version Notification for draft-irtf-t2trg-iot-seccons-02.txt

Barry Raveendran Greene <[email-masked]> writes:

>I survey of all the IoT Security "standards" and "guidelines" assumes
>we can remediate the violated IoT device. I put forward for the IETF
>that we cannot assume remediation. We have to assume that we cannot
>remediate. Hence, we need other tools in the network to mitigate the risk.

That's always struck me as a bit odd as well when I read some standard for secure firmware update, for IoS devices like the Raspberry Pi and similar Linux-based/like devices the update process is already sorted (apt-get update) and for SCADA/embedded or whatever running some RTOS it can't be updated, whatever you ship today will be used in that form for the next ten to twenty years (or more, I've seen fifty-year-old ladder logic controllers still in active use).  So the diagram in Figure 1 is replaced after "application running" with a dotted line leading up to the present day, there's no updates, no reconfiguration, no maintenance and re-bootstrapping, it just keeps running once put into service.

I don't want to start nitpicking individual bits of the draft, but I think it would help if it laid out what's meant by "IoT", are we talking Android phones (mentioned in one place), fridges, PLCs, routers, what?  Or perhaps come up with a few sample device profiles and provide specific advice for each case.
At the moment it's so generic that it seems to be one-size-fits-nothing...
it's like trying to write safe-driving instructions that have to cover cars, buses, trucks, motorbikes, locomotives, boats, oil tankers, jet skis, jet aircraft, jet bikes, scooters, and submarines.

Peter.

---

From: "Garcia-Morchon O, Oscar" <[email-masked]>
Date: Thu, 6 Apr 2017 07:28:08 +0000

Hi Eliot,

It is a very good point. Thanks.

IoT involves very different aspects that we try to reflect in the document. One of them is indeed network security with the goal to protect devices from attack but also the network from compromised devices.

In the document, we refer to your ongoing work on MUD. Which other type of methods do you have in mind or do you think that should be included in the document?

Regards, Oscar.

-----Original Message-----
From: Eliot Lear [mailto:[email-masked]] 
Sent: Tuesday, April 4, 2017 12:32 PM
To: Garcia-Morchon O, Oscar <[email-masked]>; [email-masked]; [email-masked]
Cc: Mohit Sethi <[email-masked]>; Kumar, Sandeep <[email-masked]>
Subject: Re: [T2TRG] New Version Notification for draft-irtf-t2trg-iot-seccons-02.txt

Hi Oscar,

While I appreciate the draft, there is an elephant in the room.  Not a day passes when we hear of yet another compromise of a so-called "IoT"
system.  Sometimes these compromises are trivial, and sometimes they are involved.  At the end of the day, the sheer quantity of Things mandates some form of network-level protection that the draft should discuss, to protect those devices from attack.  As was mentioned in the f2f, what if Bob turns out to be, or becomes evil, or is otherwise 0wn3d by Chuck?

Eliot

---

From: Eliot Lear <[email-masked]>
Date: Thu, 6 Apr 2017 10:47:24 +0200

Hi Oscar,

First of all, I realized I was reading the old version of the draft.  My
apologies.  This having been said, I would suggest the following:

  * In discussing bootstrapping in Section 7.2, assuredly we should talk
    about the work going on in the ANIMA working group
    (draft-ietf-anima-bootstrapping-keyinfra).  Not all devices are so
    constrained as to be unable to use the established PKI, and indeed
    the cost of doing so for onboarding is dropping by the day.
  * Consider refocusing Section 7.11 on the role of firewalls, access
    points, and access switches in protecting IoT (really all) devices. 
    I would resituate it or directly next to E2E security, and then
    discuss the relative merits and risks.  If it is possible to do so,
    match the flow you have built in Section 3.2 (the numbered points)
    in later sections.
  * In Section 4, you've done an excellent job of discussing threat
    vectors.  Without being hyperbolic about it (and this might be
    hard), it might be good to remind people of some consequences of
    penetration.  Broadly speaking I see this as enabling of direct
    attacks (e.g., causing the device to fail to correctly perform its
    function), or indirect attacks (making use of the device to attack
    other devices).  These are obviously not mutually exclusive.
  * I would move the attack discussion in 7.11 into Section 4, and I
    would move Section 4 above Section 3, the logic here being to first
    have the threat discussion, and then discuss how they are remediated.
  * Bullet point 6 on extraction of private information is important to
    include.  However, I would suggest NOT making generalizations as to
    how well a device protects private data.  It is sufficient to say
    that when a device does not go to some pains to protect that data,
    if the device is physically unprotected, so then is the data.

Hope this helps...

Eliot

---

From: Peter Gutmann <[email-masked]>
Date: Thu, 6 Apr 2017 14:32:56 +0000

>- summarize security considerations and challenges that should be addressed

The problem is that almost everyone else who has any interest in the IoS has
also published their own checklist or guidelines or BCP or whatever they felt
like doing.  It's not that we have a lack of guidelines, we have as many as
you like (and that's not just IoS-specific stuff but includes any book on
secure programming, security engineering, and so on), but no-one uses them.
So it seems like we need to look at why people aren't using them, and how we
can get them used.  Why does every J.Random Linux distro come with hardened
system binaries and libraries and books and howto's on further hardening
things, but every IoS device feature strcpy() into fixed-size buffers and XSS
and directory-traversal bugs like it was 1995?

The problem with the non-specificity of many of the guidelines is that you end
up with something that tries to cover, for example, a Raspberry Pi, which is
essentially a Unix server and for which you don't need any new guidelines
because any reference on setting up and hardening a Unix box will do, and at
the other end of the spectrum a PLC running what's labelled as an RTOS but
which is really just a big binary blob containing device drivers, a task
scheduler, a network stack, and the application, all running in ring zero with
no protection features.

So the document currently is an interesting overview of IoS security issues,
and better than most I've seen, but there's no obvious answer to a question
like "I have a PLC, what steps should I take to secure it?".  Instead, it's a
survey of every possible technology and mechanism that could be applied to the
problem, which leads to an obvious suggestion of submitting it as a paper for
Computing Surveys instead of publishing it as an RFC, since it reads very much
like a Computing Surveys paper and would probably work well there.

Peter.

---

From: Thorsten Dahm <[email-masked]>
Date: Fri, 7 Apr 2017 15:16:49 +0100

Hi all,

I also agree with the statements of the folks who previously commented on
the topic. Before the IETF in Chicago I had a private chat with Oscar and
pointed out the missing details on mitigation of the risks he points out in
his document. Not sure if that should be added to an already long document
or if we should split it into a separate document. And yes, while it is a
good document and we should have it, documents alone don't change much.
What we need are products that implement the best practices as well as
network operators and consumers who refuse to connect insecure dishwashers
to their enterprise or home network. Without market pressure and holding
manufacturers accountable for the damage their products may cause it's hard
to convince them to spend money on IoT security.

Taking a step back, I doubt that IoT will be able to take care of itself in
the next couple of years, so we have to rely on operators to do the job for
the manufacturers while we push BCPs and standards like the current
document to them. IMHO the extensive usage of features like private VLANs
is still very painful and even in combination with stuff like MUD, it would
only solve parts of the problem. We as operators probably need to rethink
the stack from L1 to L7 and reach out to other Working Groups outside of
the IoT / Security space to address the need. The bootstrapping work in
ANIMA is a good example for that. We may can't avoid completely connecting
devices that use strcpy() into fixed-size buffers to our networks, but we
can prevent them from disturbing other devices on the network and limiting
the blast radius in case of a (unavoidable?) compromise.

Maybe a good topic to be picked up by the T2TRG is the question of how to
protect the network from compromised devices, the majority of the work as I
can see it focuses currently on the security of the Thing itself.

cheers,
Thorsten

On 6 April 2017 at 15:32, Peter Gutmann <[email-masked]> wrote:

> >- summarize security considerations and challenges that should be
> addressed
> >  in the future
>

-- 
Thorsten Dahm

Network Engineer
Google Ireland Ltd.
The Gasworks, Barrow Street
Dublin 4,  Ireland

Registered in Dublin, Ireland
Registration Number: 368047

---

From: "Garcia-Morchon O, Oscar" <[email-masked]>
Date: Mon, 10 Apr 2017 07:26:04 +0000

Hi Thorsten,

I fully agree with your email.

Regarding: “I had a private chat with Oscar and pointed out the missing details on mitigation of the risks he points out in his document. Not sure if that should be added to an already long document or if we should split it into a separate document.”

I agree that having such a document would be great. Personally, I would not include the mitigation strategies in this document since this document is already pretty long. I also think that just a list of mitigation strategies will be rather long and also confusing for designers. A designer will still ask himself, what do I really need to protect “my” IoT system?

What about the following? We could have a different document that includes:

-          Extended text related to how to deal with threats (page 12 in the current document starting with “Dealing with above threats and finding suitable security mitigations is challenging: there are very sophisticated threats that a very powerful attacker could use; also, new threats and exploits appear in a daily basis.  Therefore, the existence of proper secure product creation processes that allow managing and minimizing risks during the lifecycle of the IoT devices is at least as important as being aware of the threats.  A non-exhaustive list of relevant processes include:”

-          Mitigation strategies: here we can list main mitigation strategies to deal with different types of threats.

-          Security profiles (section 6 in current document, this section would be removed from the current document) that illustrate which mitigation strategies should be applied to different classes of use cases (I believe that this makes lots of sense since not all classes of use cases will be exposed to the same threats, and thus, mitigation strategies will also be different.)

Regards, Oscar.

From: Thorsten Dahm [mailto:[email-masked]]
Sent: Friday, April 7, 2017 4:17 PM
To: [email-masked]; [email-masked]
Cc: Garcia-Morchon O, Oscar <[email-masked]>; Barry Raveendran Greene <[email-masked]>; Eliot Lear <[email-masked]>; Mohit Sethi <[email-masked]>; Kumar, Sandeep <[email-masked]>; Peter Gutmann <[email-masked]>
Subject: Re: [saag] [T2TRG] New Version Notification for draft-irtf-t2trg-iot-seccons-02.txt

Hi all,

I also agree with the statements of the folks who previously commented on the topic. Before the IETF in Chicago I had a private chat with Oscar and pointed out the missing details on mitigation of the risks he points out in his document. Not sure if that should be added to an already long document or if we should split it into a separate document. And yes, while it is a good document and we should have it, documents alone don't change much. What we need are products that implement the best practices as well as network operators and consumers who refuse to connect insecure dishwashers to their enterprise or home network. Without market pressure and holding manufacturers accountable for the damage their products may cause it's hard to convince them to spend money on IoT security.

Taking a step back, I doubt that IoT will be able to take care of itself in the next couple of years, so we have to rely on operators to do the job for the manufacturers while we push BCPs and standards like the current document to them. IMHO the extensive usage of features like private VLANs is still very painful and even in combination with stuff like MUD, it would only solve parts of the problem. We as operators probably need to rethink the stack from L1 to L7 and reach out to other Working Groups outside of the IoT / Security space to address the need. The bootstrapping work in ANIMA is a good example for that. We may can't avoid completely connecting devices that use strcpy() into fixed-size buffers to our networks, but we can prevent them from disturbing other devices on the network and limiting the blast radius in case of a (unavoidable?) compromise.

Maybe a good topic to be picked up by the T2TRG is the question of how to protect the network from compromised devices, the majority of the work as I can see it focuses currently on the security of the Thing itself.

cheers,
Thorsten

On 6 April 2017 at 15:32, Peter Gutmann <[email-masked]<mailto:[email-masked]>> wrote:

Peter.
_______________________________________________
saag mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/saag

--
Thorsten Dahm

Network Engineer
Google Ireland Ltd.