Re: [Ace] Call for adoption on draft-seitz-ace-usecases-01 ("ACE Use Cases")

[Ludwig Seitz <[e-mail]>]

On 08/01/2014 06:08 AM, Rene Struik wrote:
> Dear colleagues:
>
> I participated in the ACE discussions in Toronto last week, read
> draft-seitz-ace-usecases-01, and saw the email discussions that ensued
> since the meeting.
>
> Unfortunately, I cannot support adopting the use case draft in its
> current form.
>
> I think it is far from ready to be a fruitful base for incremental
> improvements as a WG document. Moreover, there seems to be quite some
> disagreement as to whether certain use cases (discussed on the mailing
> list over the last few days, but mostly not in the draft) are considered
> inside scope of this working group.
>
> We should not simply adopt a draft, just because it is there. It also
> should have sufficient merit to have a chance progressing to an
> informational RFC or document that otherwise would guide the development
> of an authorization and authentication solution as a proposed standard.
> Right now, I feel it does not have these qualities.

> I would provide a more succinct description of use cases that capture
> security-relevant events, including the following:

It is not really clear to me what you find lacking with the current
draft. The use case descriptions are rather succinct, with a minimum of
flavor text to keep them readable and give some real world application
context.

They do capture security-relevant events (or rather Authentication and
Authorization relevant, since its ACE and not SCE), such as

> 1) change of network composition: new kid on the block;
  See e.g. the home automation use case, requirement U2.1 and U2.2

> temporary (repair) or permanently (disposed) decommissioned device;
See e.g. the building automation use case section 2.4.1.4

> temporary or
> permanent network union, resp. partitioning;
Perhaps you could clarify how that affects authentication and 
authorization solutions? Unless you want ACE to do network access control.

> 2) change of roles of devices: new role assigned to device; role
> retracted from device; assignment of meta-roles and retraction hereof;
> roles based on global policies, resp. local decisions;

Why the focus on role-based access control?  Do you mean changes in 
access rights and/or access control policies? I think these are covered 
quite extensively in the use cases, e.g. U2.1, U2.2, U3.1, U3.2



> 3) initialization or roles of devices and evolution hereof during
> lifecycle of devices and networks, all the way from conception (e.g.,
> chip manufacturing) to system integration, etc. (e.g., change of
> ownership/control, logical/procedural transfer operation), to
> operational use, replacement, disposition.

The security lifecycle of devices is covered in the building automation
use case. Feel free to make concrete suggestions where you think more
details would be useful.

>
> I would also go into more details as to what might be different with
> constrained networks. Simply allocating a single third-party device to
> do arbitrage may not do the job, since delegation of computational or
> storage cost may be offset by communication cost, energy consumption,
> and denial of service risk. One should support both peer-to-peer
> (localized) and outsourced ("cloud based", if one wishes) scenarios.

The use cases make no general assumption about a single third-party
device to do arbitraging. There is some reference to authorization 
servers in the building automation use case (an oversight on my part). 
This should be removed in the next update.


> I would also pay lots of attention to distinction between homogeneous
> and heterogeneous trust domain scenarios. After all, one should
> facilitate "mix and match" scenarios, where devices may be procured from
> multiple vendors, that may not know each other and, even if they would,
> not trust each other.

See e.g. U2.5 and to some extent U4.6

> Having any presumption that manufacturers should
> do secret handshakes for their devices to be able to communicate
> securely may hamper significantly deployment in ease of use manner and
> never bring the full potential of internet of things forward. Moreover,
> it could stifle innovation, since baking in pre-established
> relationships may force the hand of contractual parties in favor of
> vested interests and the bigger party.

I don't quite see how the use case draft makes any presumptions on
secret handshakes. Could you elaborate on what you mean?

> Use cases should focus on both consumer and non-consumer style scenarios
> and include, industrial control, critical infrastructure, etc.

Consumer style scenarios like e.g. home automation and personal health
monitoring?
Non-consumer style scenarios like container monitoring and smart metering?
I don't quite see what your issue with the current document is in that
respect. I agree that we should have a good SCADA/ICS use case, that's
why I asked for input on that one.

> I am happy to contribute to use cases that incorporate the above feedback and
> that borrow from experience gained in discussions with industrial
> control and other wireless sensor standardization groups, covering both
> security, ease of use, and ease of deployment and provisioning, over the
> last 5-10 years.

By all means please do contribute them.

> Lastly, it would be good to take the viewpoint as to what
> functionalities are required and emphasize slghtly less those
> constraints that may become less of an issue over time (e.g., those in
> the digital vs. the analog domain). As we heard during the ACE session
> in Toronto, lots of crypto can be considered (or can soon be considered)
> a commodity for low-hanging fruit applications one may wish to target.

I really don't see how the use case draft makes any assumptions on the 
hardware crypto capabilities. The only thing it states is that 
constrained devices have limited resources (especially battery) and that 
the authentication and authorization measures should take these into 
account.


Regards,

Ludwig

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

Phone [phone]
http://www.sics.se