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

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 21 Jul 2014 16:46:43 +0200

Hi all,

we have a milestone for a use case document in ACe and
draft-seitz-ace-usecases is a promising candidate for this milestone.

This email is a call for adoption for draft-seitz-ace-usecases-01.

Please respond if you support, or object to, the adoption of this
document as the basis for this work item. Deadline for your response:
31. July 2014

Ciao
Hannes & Kepeng

---

From: Michael Richardson <[email-masked]>
Date: Mon, 21 Jul 2014 12:46:21 -0400

> document as the basis for this work item. Deadline for your response:

I have read the document and I agree that it a good place to start.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Rene Struik <[email-masked]>
Date: Fri, 01 Aug 2014 00:08:02 -0400

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:
1) change of network composition: new kid on the block; temporary 
(repair) or permanently (disposed) decommissioned device; temporary or 
permanent network union, resp. partitioning;
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;
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.

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.

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. 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.

Use cases should focus on both consumer and non-consumer style scenarios 
and include, industrial control, critical infrastructure, etc. 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.

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.

What is needed in the end is a design incorporating the right type of 
crypto primitives and protocols and a language that expresses device 
roles and meta-roles that can be conveyed over the air. Design then 
centers around which crypto, which protocols, which roles, how to 
express things, which granularity, etc. This would, of course, be part 
of the design of the solution and not part of the use cases, but 
certainly relates to requirements (if one wishes to tie this in with use 
cases).

Best regards, Rene

On 7/21/2014 10:46 AM, Hannes Tschofenig wrote:
> _______________________________________________
> Ace mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ace

-- 
email: [email-masked] | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363