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

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

On Fri, Oct 23, 2015 at 4:24 AM, Stephen Farrell
<stephen.farrell@cs.tcd.ie> wrote:
>
> Hiya,
>
> On 23/10/15 09:04, Ludwig Seitz wrote:
>> On 2015-10-22 15:29, Stephen Farrell wrote:
>> [...]
>>>
>>> 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
>>>
>>
>> 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?
>
> 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
>
>>
>>
>> /Ludwig
>>
>>
>>
>
> _______________________________________________
> Ace mailing list
> Ace@ietf.org
> https://www.ietf.org/mailman/listinfo/ace

-- 

Best regards,
Kathleen