Subject: [Ace] Stephen Farrell's Yes on draft-ietf-ace-usecases-09: (with COMMENT)

From: "Stephen Farrell" <[email-masked]>
Date: Thu, 22 Oct 2015 06:29:03 -0700

Stephen Farrell has entered the following ballot position for
draft-ietf-ace-usecases-09: Yes

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-ace-usecases/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Excellent and well written document, thanks. I think there are
five things you could usefully add, see below. That said, I
agree that this cannot and should not try to be fully complete
so I won't argue (much:-) if you prefer to omit these. We/you
can figure out what if any text to add I'm sure, but I'm happy
to chat about that.

1. Software update is really needed and often missing and
usually hard. There's at least a need to authenticate and
authorize new firmware, when there is any update. That may not
be the same as authorizing a new config.

2. Alice buys a new device, and would like to know if it is
calling home or what it is doing before she configures it, or
perhaps before she accepts it in her network. Even if she
accepts it, she may want to be able to monitor the data it
is sending "home" e.g. to ensure her TV is not sending 
data when she inserts a USB stick, if that is undesired.

3. Device fingerprinting is a threat that ought be considered
by solution developers, especially if there is no reliable
software update. Probably the best to be done is to try to
make it hard for unauthorized parties to fingerprint a device,
but that's also hard.

4. Commercial Devices will be end-of-lifed by vendors, and yet
Alice still needs to be able to use, and perhaos to update,
the device. That calls for some kind of authorization handover
which is not quite the same as a change of ownership.

5. Penetration testing will happen and devices should not barf
even then. Maybe that's a security consideration worth a
mention.

See also the secdir review. [1] It'd be good to see a 
response to that.

   [1] https://www.ietf.org/mail-archive/web/secdir/current/msg06101.html

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 22 Oct 2015 15:59:18 +0200

Hi Stephen,

I agree with all of these.
However, they are not specific to ACE; they are general security considerations for constrained devices (or IoT things in general).
I think what we need to do is collect the security considerations we have in, say, RFC 7252, RFC 7228, etc., combine this with the points below and a few more that came up, and generate a referenceable “Security Considerations for Constrained Devices on the Internet” document.  I’d love to reference that from any document I’m working on.

Grüße, Carsten

> On 22 Oct 2015, at 15:29, Stephen Farrell <[email-masked]> wrote:
> 
> _______________________________________________
> Ace mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ace
>

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 22 Oct 2015 15:06:21 +0100

On 22/10/15 14:59, Carsten Bormann wrote:
> Hi Stephen,
> 
> I agree with all of these. However, they are not specific to ACE;
> they are general security considerations for constrained devices (or
> IoT things in general). I think what we need to do is collect the
> security considerations we have in, say, RFC 7252, RFC 7228, etc.,
> combine this with the points below and a few more that came up, and
> generate a referenceable “Security Considerations for Constrained
> Devices on the Internet” document.  I’d love to reference that from
> any document I’m working on.

Such a document would indeed be a fine thing. Do we have folks who
are willing and able already?

That said, I do think there may be ace-specific use-cases to be
derived from (some of) the points raised, e.g. handling end of
life is maybe not the same as a handover after the vendor is off
the stage.

S.

>> When responding, please keep the subject line intact and reply to
>> all email addresses included in the To and CC lines. (Feel free to
>> cut this introductory paragraph, however.)
>> 
>> 
>> Please refer to
>> https://www.ietf.org/iesg/statement/discuss-criteria.html for more
>> information about IESG DISCUSS and COMMENT positions.
>> 
>> 
>> The document, along with other ballot positions, can be found
>> here: https://datatracker.ietf.org/doc/draft-ietf-ace-usecases/
>> 
>> 
>> 
>> five things you could usefully add, see below. That said, I agree
>> that this cannot and should not try to be fully complete so I won't
>> argue (much:-) if you prefer to omit these. We/you can figure out
>> what if any text to add I'm sure, but I'm happy to chat about
>> that.
>> 
>> 1. Software update is really needed and often missing and usually
>> hard. There's at least a need to authenticate and authorize new
>> firmware, when there is any update. That may not be the same as
>> authorizing a new config.
>> 
>> 2. Alice buys a new device, and would like to know if it is calling
>> home or what it is doing before she configures it, or perhaps
>> before she accepts it in her network. Even if she accepts it, she
>> may want to be able to monitor the data it is sending "home" e.g.
>> to ensure her TV is not sending data when she inserts a USB stick,
>> if that is undesired.
>> 
>> 3. Device fingerprinting is a threat that ought be considered by
>> solution developers, especially if there is no reliable software
>> update. Probably the best to be done is to try to make it hard for
>> unauthorized parties to fingerprint a device, but that's also
>> hard.
>> 
>> Alice still needs to be able to use, and perhaos to update, the
>> device. That calls for some kind of authorization handover which is
>> not quite the same as a change of ownership.
>> 
>> 5. Penetration testing will happen and devices should not barf even
>> then. Maybe that's a security consideration worth a mention.
>> 
>> See also the secdir review. [1] It'd be good to see a response to
>> that.
>> 
>> [1]
>> https://www.ietf.org/mail-archive/web/secdir/current/msg06101.html
>> 
>> 
>> _______________________________________________ Ace mailing list 
>> [email-masked] https://www.ietf.org/mailman/listinfo/ace
>> 
>

---

From: "Kumar, Sandeep" <[email-masked]>
Date: Thu, 22 Oct 2015 21:47:04 +0000

draft-garcia-core-security-06 was such an attempt. Maybe a good time to resurrect it.

Sandeep

-----Original Message-----
From: Stephen Farrell [mailto:[email-masked]]
Sent: Thursday, October 22, 2015 4:06 PM
To: Carsten Bormann
Cc: [email-masked]; The IESG; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [Ace] Stephen Farrell's Yes on draft-ietf-ace-usecases-09: (with COMMENT)

On 22/10/15 14:59, Carsten Bormann wrote:
> Hi Stephen,
>
> I agree with all of these. However, they are not specific to ACE; they
> are general security considerations for constrained devices (or IoT
> things in general). I think what we need to do is collect the security
> considerations we have in, say, RFC 7252, RFC 7228, etc., combine this
> with the points below and a few more that came up, and generate a
> referenceable “Security Considerations for Constrained Devices on the
> Internet” document.  I’d love to reference that from any document I’m
> working on.

Such a document would indeed be a fine thing. Do we have folks who are willing and able already?

That said, I do think there may be ace-specific use-cases to be derived from (some of) the points raised, e.g. handling end of life is maybe not the same as a handover after the vendor is off the stage.

S.

>> email addresses included in the To and CC lines. (Feel free to cut
>> this introductory paragraph, however.)
>>
>>
>> Please refer to
>> what if any text to add I'm sure, but I'm happy to chat about that.
>>
>> home or what it is doing before she configures it, or perhaps before
>> she accepts it in her network. Even if she accepts it, she may want
>> to be able to monitor the data it is sending "home" e.g.
>> to ensure her TV is not sending data when she inserts a USB stick, if
>> that is undesired.
>>
>> unauthorized parties to fingerprint a device, but that's also hard.
>>
>> 4. Commercial Devices will be end-of-lifed by vendors, and yet Alice
>> still needs to be able to use, and perhaos to update, the device.
>> That calls for some kind of authorization handover which is not quite
>> the same as a change of ownership.
>>

________________________________
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: Carsten Bormann <[email-masked]>
Date: Fri, 23 Oct 2015 01:10:46 +0200

> draft-garcia-core-security-06 was such an attempt. Maybe a good time to resurrect it.

Absolutely.  I keep wanting to find a good home for it.  One approach
would be to work on it as a T2TRG deliverable.

That said, the document I had in mind may be even more useful if it is
shorter, more focused on a few points we want implementers to
understand.  So maybe we'll have two documents in the end, that kind of
brief security considerations, and the more encompassing document that
is like core-security (the latter also now has a few more documents it
actually can delegate things to, such as ace-actors).

Grüße, Carsten

---

From: Kathleen Moriarty <[email-masked]>
Date: Thu, 22 Oct 2015 22:33:07 -0400

As long as it happens as we've discussed this option (and I like it) before without progress.

Thank you,
Kathleen 

Sent from my iPhone

> On Oct 22, 2015, at 7:10 PM, Carsten Bormann <[email-masked]> wrote:
> 
> Kumar, Sandeep wrote:

---

From: Ludwig Seitz <[email-masked]>
Date: Fri, 23 Oct 2015 10:04:17 +0200

On 2015-10-22 15:29, Stephen Farrell wrote:
[...]

Hi Stephen,

Thank you for your comments!

We are making final adjustments to the document based on the *-DIR and 
the ballot comments.

In the light of the discussion of your comments, Steffi and I are 
leaning towards not including them in this draft, since they are of a 
more general nature and would fit better in a general IoT/CoRE security 
document.

Would that be ok with you?

/Ludwig

-- 
Ludwig Seitz, PhD
SICS Swedish ICT AB
Ideon Science Park
Building Beta 2
Scheelevägen 17
SE-223 70 Lund

Phone +46(0)70-349 92 51
http://www.sics.se

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 23 Oct 2015 09:24:50 +0100

Hiya,

> Would that be ok with you?

That is ok, but I disagree of course:-)

I do think there are ace-specific use-cases arising from
the above. But I can fully understand not wanting to take
on such additions at this stage as well.

S

---

From: Kathleen Moriarty <[email-masked]>
Date: Fri, 23 Oct 2015 08:37:23 -0400

I just went through Stephen's comments again before approving the
draft, and I do think his first comment should be added in since it is
specific to authentication and authorization.  Is there a place this
can fit in nicely?

The problem he calls out is one that has been a thorn in the side for
vendors of other products (not constrained), so it would be good to
require updates to be authenticated and authorized.  SUpply chain
attacks are easier when these measures are not in place.  A possible
scenario (derived from real world events) is that you could
manufacture a knock off and have it use a specific vendors firmware in
an update without this protection in place.

It would be appropriate to have this in a general document, but since
this is authentication and authorization focused, it would be good to
see it here as well.  This is a very well written document and may get
more not-as-technical readers using it for education, so it would be a
shame to leave this out and get burned by it later.  It might not be
in scope for ACE, but you can also just state that so the concern is
known.

Thank you,
Kathleen

-- 

Best regards,
Kathleen

---

From: Ludwig Seitz <[email-masked]>
Date: Fri, 23 Oct 2015 15:29:43 +0200

On 2015-10-23 14:37, Kathleen Moriarty wrote:
>[....]
[...]
>> be the same as authorizing a new config.

Isn't this covered in section 2.4.1.3. ?

"At some point the facility management company wants to update the
firmware of lighting devices in order to eliminate software bugs.
Before accepting the new firmware, each device checks the
authorization of the facility management company to perform this
update."

There is simply not a specific authorization problem listed for this, I 
could argue that it is subsumed under U4.4 but if you think it deserves 
specific mention under the problems section I can live with adding a point.

/Ludwig

-- 
Ludwig Seitz, PhD
SICS Swedish ICT AB
Ideon Science Park
Building Beta 2
Scheelevägen 17
SE-223 70 Lund

Phone +46(0)70-349 92 51
http://www.sics.se

---

From: Stefanie Gerdes <[email-masked]>
Date: Fri, 23 Oct 2015 16:58:15 +0200

Hi all,

> specific mention under the problems section I can live with adding a point.

I think adding a point in 2.4.3 is a good idea. We could also add an
item to 3.3 that emphasizes the problem.

Thanks,
Steffi

---

From: Kathleen Moriarty <[email-masked]>
Date: Fri, 23 Oct 2015 11:21:44 -0400

Sent from my iPhone

> On Oct 23, 2015, at 10:58 AM, Stefanie Gerdes <[email-masked]> wrote:
> 
> Hi all,
> 

Great, I think adding a point would be helpful.  You'd be authenticating the device to receive the update preventing fraud, which is different from the existing point referenced.

Thanks,
Kathleen

---

From: Ludwig Seitz <[email-masked]>
Date: Mon, 26 Oct 2015 08:39:46 +0100

On 2015-10-23 17:21, Kathleen Moriarty wrote:
>>>>> authorize new firmware, when there is any update. That may
>>>>> not be the same as authorizing a new config.
>>>
>>>
>>> "At some point the facility management company wants to update
>>> the firmware of lighting devices in order to eliminate software
>>> bugs. Before accepting the new firmware, each device checks the
>>> There is simply not a specific authorization problem listed for
>>> this, I could argue that it is subsumed under U4.4 but if you
>>> think it deserves specific mention under the problems section I
>>> can live with adding a point.
>>
>> I think adding a point in 2.4.3 is a good idea. We could also add
>> an item to 3.3 that emphasizes the problem.
>>
>
> Great, I think adding a point would be helpful.  You'd be
> authenticating the device to receive the update preventing fraud,
> which is different from the existing point referenced.
>

Hello Kathleen,

I'm a bit puzzled by this last sentence. That is not at all how I read 
Stephen's comment, which was, in my understanding, all about 
authenticating and authorizing the software update, not the receiver of 
the update.

Now obviously, authenticating the receiver of a software update is not a 
bad idea either, but do you think this also requires specific mention?

/Ludwig

-- 
Ludwig Seitz, PhD
SICS Swedish ICT AB
Ideon Science Park
Building Beta 2
Scheelevägen 17
SE-223 70 Lund

Phone +46(0)70-349 92 51
http://www.sics.se

---

From: Kathleen Moriarty <[email-masked]>
Date: Mon, 26 Oct 2015 08:53:42 -0400

Yes, it should be both.

Thanks,
Kathleen 

Sent from my iPhone

> On Oct 26, 2015, at 3:39 AM, Ludwig Seitz <[email-masked]> wrote:
> 
> I'm a bit puzzled by this last sentence. That is not at all how I read Stephen's comment, which was, in my understanding, all about authenticating and authorizing the software update, not the receiver of the update.
> 
> Now obviously, authenticating the receiver of a software update is not a bad idea either, but do you think this also requires specific mention?
> 
> /Ludwig
> 
> 
> -- 
> Ludwig Seitz, PhD
> SICS Swedish ICT AB
> Ideon Science Park
> Building Beta 2
> Scheelevägen 17
> SE-223 70 Lund
> 
> Phone +46(0)70-349 92 51
> http://www.sics.se
>