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

From: Robert Cragie <[email-masked]>
Date: Fri, 01 Aug 2014 14:08:38 +0100

Rene,

I think you're missing the point of use cases. A use case is a depiction 
of a real world scenario. What you describe below are the models and 
patterns which can be interpreted from use cases. That is separate and 
should be treated as such.

Therefore I do support adoption of the document but I do also think 
there is value in trying to solicit a larger and wider set of use cases 
to add to the document, focusing on e.g, "bananas" as opposed to "devices".

Robert

On 01/08/2014 5: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:
> 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:
>> 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
>>
>>
>>
>> _______________________________________________
>> 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
>
>
> _______________________________________________
> Ace mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ace

---

From: Rene Struik <[email-masked]>
Date: Fri, 01 Aug 2014 09:39:42 -0400

Hi Robert:

Describing use case more abstractly than others does not suddenly make 
these no use cases (as you seem to suggest). See below, if this is more 
concrete to you.

Ad #1) below:
a) I want to be able to add a device to my network (new kid on the block);
this can be temporarily (e.g., friend has access to printer while 
visiting, but not after) or permanently (add new stick-on-window 
temperature meter to home control system).
b) I want to replace a malfunctioning device, e.g., pressure pump has to 
go to repair shop (temporary decommissioning) or ditch a broken one 
(permanent decommissioning);
c) I have a complete subsystem (skid) I want to add to a network on an 
oil platform (union), resp. want to sell off a subsystem or logically 
split a network/system into two (partitioning).

Ad #2) below:
a) I want my remote control to control a new gadget (new role assigned 
to device); I want to remove the capability of this remote control 
(retract from device);
b) etc., etc.

The draft needs a major rewrite to accommodate this all in a succinct 
manner. Hence, my "no vote". Again, having a draft on the shelf does not 
by itself make it worthy of adoption as a WG document as is.

{BTW - during the draft charter discussion, one of the co-editors, 
Steffi Gerdes, agreed with earlier suggestion to have use case draft 
milestone for adoption in December, see
http://www.ietf.org/mail-archive/web/ace/current/msg00632.html. It was 
unclear why this was changed (it came out of the blue)}

Rene

==

On 8/1/2014 9:08 AM, Robert Cragie wrote:
> Rene,
>
> I think you're missing the point of use cases. A use case is a 
> depiction of a real world scenario. What you describe below are the 
> models and patterns which can be interpreted from use cases. That is 
> separate and should be treated as such.
>
> there is value in trying to solicit a larger and wider set of use 
> cases to add to the document, focusing on e.g, "bananas" as opposed to 
> "devices".
>
> Robert
>
>> draft-seitz-ace-usecases-01, and saw the email discussions that 
>> ensued since the meeting.
>>
>> disagreement as to whether certain use cases (discussed on the 
>> mailing list over the last few days, but mostly not in the draft) are 
>> (repair) or permanently (disposed) decommissioned device; temporary 
>> or permanent network union, resp. partitioning;
>> retracted from device; assignment of meta-roles and retraction 
>> hereof; roles based on global policies, resp. local decisions;
>> 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.
>>
>> 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 
>> 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 
>> 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 

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

---

From: Kathleen Moriarty <[email-masked]>
Date: Fri, 1 Aug 2014 15:06:53 -0400

Hi Rene,

Sent from my iPhone

> On Aug 1, 2014, at 9:39 AM, Rene Struik <[email-masked]> wrote:
> 
> Hi Robert:
> 
> Describing use case more abstractly than others does not suddenly make these no use cases (as you seem to suggest). See below, if this is more concrete to you.
> 
> Ad #1) below:
> this can be temporarily (e.g., friend has access to printer while visiting, but not after) or permanently (add new stick-on-window temperature meter to home control system).
> b) I want to replace a malfunctioning device, e.g., pressure pump has to go to repair shop (temporary decommissioning) or ditch a broken one (permanent decommissioning);
> c) I have a complete subsystem (skid) I want to add to a network on an oil platform (union), resp. want to sell off a subsystem or logically split a network/system into two (partitioning).
> 
> Ad #2) below:
> a) I want my remote control to control a new gadget (new role assigned to device); I want to remove the capability of this remote control (retract from device);
> b) etc., etc.
> 
> The draft needs a major rewrite to accommodate this all in a succinct manner. Hence, my "no vote". Again, having a draft on the shelf does not by itself make it worthy of adoption as a WG document as is. 
> 
> {BTW - during the draft charter discussion, one of the co-editors, Steffi Gerdes, agreed with earlier suggestion to have use case draft milestone for adoption in December, see
> http://www.ietf.org/mail-archive/web/ace/current/msg00632.html. It was unclear why this was changed (it came out of the blue)}

The change happened during the IESG review, a result of past experience.  With other WGs, if the use cases and other formative work takes too long, the WG looses steam and potentially interest from the developers who would normally kick in once this base work is complete.

If you want to submit an alternate draft, please do it soon to provide a choice or the WG can build on and modify this one.

Regards,
Kathleen

> 
> Rene
> 
> ==
> 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 think you're missing the point of use cases. A use case is a depiction of a real world scenario. What you describe below are the models and patterns which can be interpreted from use cases. That is separate and should be treated as such.
>> 
>> Therefore I do support adoption of the document but I do also think there is value in trying to solicit a larger and wider set of use cases to add to the document, focusing on e.g, "bananas" as opposed to "devices".
>> 
>> Robert
>> 
>>> 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
>>>

---

From: Michael Richardson <[email-masked]>
Date: Sat, 02 Aug 2014 16:44:59 -0400

Rene Struik <[email-masked]> wrote:
    > Ad #1) below: a) I want to be able to add a device to my network (new
    > kid on the block); this can be temporarily (e.g., friend has access to

All of this (joining network, leaving, initial pairing with non-constrained
node) was agreed to be out of scope for ACE (at this time: a recharter could
change that in the future).

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

---

From: Robert Cragie <[email-masked]>
Date: Tue, 05 Aug 2014 13:39:17 +0100

Hi Rene,

The way I view use cases is more along the lines as written in e.g. 
http://www.visual-paradigm.com/tutorials/writingeffectiveusecase.jsp, 
hence my comment (note I am not promoting Visual Paradigm, it was the 
first relevant article I came across). Therefore, as a collection of 
examples in different application areas, I think the use case document 
as written works well. As mentioned, I also think it could be extended 
and you have made some of your examples more specific, which I think 
would work for inclusion in this document. I think others which have 
been highlighted in the mailing list would also be useful, for example 
the peer-to-peer in-home use cases in Anthony Nadalin's e-mail (Wed, 30 
Jul 2014 17:42:28 +0000).

If I have any comment on the use case document, it would be to remove or 
alter Section 3, as it starts to make assumptions about architecture 
without going through any obvious analysis to distil this architecture 
from the use cases.

However, on the wider question of the usefulness re. use cases: I would 
concur that too much time can be spent on use cases to the detriment of 
reaching the charter goal. IMHO, it is usually expedient to use a 
"bottom-up" approach in conjunction with the "top down" approach of use 
cases, though these two approaches should be distinguishable in the 
process. The bottom-up approach assumes architectures and possible 
protocols based on assessment of existing implementation and then 
testing them for suitability against the use cases. Regarding existing 
protocols, initially it is less "how can we use it?", more "what can we 
apply from it?"; the difference may seem subtle but it is important. On 
the same token, that doesn't rule out using an existing protocol 
subsequently if it meets the requirements. This approach also does not 
preclude work from starting if the use case document is not finished.

Robert

On 01/08/2014 2:39 PM, Rene Struik wrote:
> these no use cases (as you seem to suggest). See below, if this is 
> more concrete to you.
>
> Ad #1) below:
> b) I want to replace a malfunctioning device, e.g., pressure pump has 
> to go to repair shop (temporary decommissioning) or ditch a broken one 
> manner. Hence, my "no vote". Again, having a draft on the shelf does 
> not by itself make it worthy of adoption as a WG document as is.
>
>> cases to add to the document, focusing on e.g, "bananas" as opposed 
>> to "devices".
>>
>> Robert
>>
>>> 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 
>>> I would provide a more succinct description of use cases that 
>>> capture security-relevant events, including the following:
>>> 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 
>>> 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.
>>>
>>> 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.
>>>
>>> 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
>>>

---

From: Ludwig Seitz <[email-masked]>
Date: Tue, 26 Aug 2014 09:22:59 +0200

On 08/01/2014 06:08 AM, Rene Struik wrote:
> list over the last few days, but mostly not in the draft) are considered
> inside scope of this working group.
>
> 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.

> 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
Perhaps you could clarify how that affects authentication and 
authorization solutions? Unless you want ACE to do network access control.

> 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

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

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

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

> 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 +46(0)70-349 92 51
http://www.sics.se

---

From: Bert Greevenbosch <[email-masked]>
Date: Wed, 27 Aug 2014 07:28:59 +0000

Hi all,

I think the use case and requirements document is in good shape.

Of course there is still work to be done on it, but this is not a WG last call, just a call for adoption.

B.t.w., about a year ago, I submitted a use case document myself:
tools.ietf.org/html/draft-greevenbosch-core-authreq-00

We may consider whether use-cases 3.1 (authorised and unauthorised devices), 3.4 (maintaining and extending a network of sensors and actuators) and 3.8 (mixing nodes from different vendors) make sense for adoption in the new use case document.

3.1 and 3.8 use certification to block sensors from joining the network, based on their credentials, which in the story are used to determine the type of sensor or are absent.
3.4 illustrates maintenance, especially replacing a single unit or adding a group of sensors.

Anyway I support WG adoption of draft-seitz-ace-usecases-01.

Best regards,
Bert

> -----Original Message-----
> From: Ace [mailto:[email-masked]] On Behalf Of Hannes Tschofenig
> Sent: 21 July 2014 22:47
> To: [email-masked]
> Subject: [Ace] Call for adoption on draft-seitz-ace-usecases-01 ("ACE
> Use Cases")
> 
> 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.
>