Subject: [Ace] ACE Use Case document

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 21 Aug 2014 15:41:04 +0200

Hi all,

we started a call for adoption of draft-seitz-ace-usecases as a starting
point for the use case charter item in July and we were hoping to get a
lot of feedback.

Unfortunately, it turned out that only very few responded, namely
Robert, Michael, Peter, and Rene (whereby Rene voiced concerns).

Of course, you may have been on vacation and therefore unable to review
the draft and to respond.

With the vacation period coming to an end we hope to receive additional
feedback from other working group participants.

Ciao
Hannes & Kepeng

---

From: Anthony Nadalin <[email-masked]>
Date: Tue, 26 Aug 2014 03:12:33 +0000

My major issues and comments with the document is that it does not cover a lot of the use case that we see in the marketplace, the use case document can be broader than the scope of the WG (even though I don't see much in the charter that limits the scope).

-----Original Message-----
From: Ace [mailto:[email-masked]] On Behalf Of Hannes Tschofenig
Sent: Thursday, August 21, 2014 6:41 AM
To: [email-masked]
Subject: [Ace] ACE Use Case document

Hi all,

we started a call for adoption of draft-seitz-ace-usecases as a starting point for the use case charter item in July and we were hoping to get a lot of feedback.

Unfortunately, it turned out that only very few responded, namely Robert, Michael, Peter, and Rene (whereby Rene voiced concerns).

Of course, you may have been on vacation and therefore unable to review the draft and to respond.

With the vacation period coming to an end we hope to receive additional feedback from other working group participants.

Ciao
Hannes & Kepeng

---

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

On 08/26/2014 05:12 AM, Anthony Nadalin wrote:
> My major issues and comments with the document is that it does not cover a lot of the use case that we see in the marketplace,
> the use case document can be broader than the scope of the WG (even though I don't see much in the charter that limits the scope).

If you want to contribute more use cases that are relevant, you are most 
welcome.

Do you think the use cases in the  current document are relevant?
Are there aspects of these use cases that you feel are missing in the 
document?

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: Jong-Hyouk Lee <[email-masked]>
Date: Tue, 26 Aug 2014 16:12:08 +0900

Hi all

As like Anthony, I think that the use-cases document should be broader than the current one. The working group should try to get some more inputs from folks before trying to fire the call for adoption. 

J.
--
Jong-Hyouk Lee, living somewhere between /dev/null and /dev/random
Protocol Engineering Lab., Sangmyung University

#email: [email-masked]
#webpage: https://sites.google.com/site/hurryon

On Aug 26, 2014, at 12:12 PM, Anthony Nadalin <[email-masked]> wrote:

> _______________________________________________
> Ace mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ace

---

From: "Kumar, Sandeep" <[email-masked]>
Date: Tue, 26 Aug 2014 07:34:49 +0000

Hi Anthony

Can you clarify if you are missing use cases that you wish were there or you also see requirements (that are in scope of the charter) missing that should have been derived from those missing use cases. If latter, can you be more specific about those missing requirements.

Thanks
Sandeep

-----Original Message-----
From: Ace [mailto:[email-masked]] On Behalf Of Hannes Tschofenig
Sent: Thursday, August 21, 2014 6:41 AM
To: [email-masked]
Subject: [Ace] ACE Use Case document

Hi all,

Ciao
Hannes & Kepeng

________________________________
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: "Kumar, Sandeep" <[email-masked]>
Date: Tue, 26 Aug 2014 07:37:39 +0000

The call for adoption is only to make this a WG document so that folks can contribute to a single document. The document can only get broader with consensus if it is a WG document. Do you think there are issues in the current use cases that should be removed?

Sandeep

-----Original Message-----
From: Ace [mailto:[email-masked]] On Behalf Of Jong-Hyouk Lee
Sent: Tuesday, August 26, 2014 9:12 AM
To: Anthony Nadalin
Cc: Hannes Tschofenig; [email-masked]
Subject: Re: [Ace] ACE Use Case document

Hi all

J.
--
Jong-Hyouk Lee, living somewhere between /dev/null and /dev/random Protocol Engineering Lab., Sangmyung University

---

From: Jong-Hyouk Lee <[email-masked]>
Date: Tue, 26 Aug 2014 18:06:54 +0900

On Aug 26, 2014, at 4:37 PM, Kumar, Sandeep <[email-masked]> wrote:

> The call for adoption is only to make this a WG document so that folks can contribute to a single document. The document can only get broader with consensus if it is a WG document.

I do not think so. When an individual document has enough supports for adoption, the document can be a WG document. Not necessary, first adopted and then improved. In other words, I do not think that the current document is matured enough for calling the adoption.

> Do you think there are issues in the current use cases that should be removed?

As stated in the abstract, the use-cases document is intended to be a guideline for developing a comprehensive authentication and access control approach while deriving security requirements. However, what I concern from the current document is possibilities of lacking of deriving security requirements from the limited use-cases in the document. 

In addition, I would like to see the document’s improvement in its organisation and structure. For instance, it must help if the document contains a table showing comparisons of the use-cases listed in the document in terms of environment (network, protocol, etc) and security requirement.

J.

---

From: Anthony Nadalin <[email-masked]>
Date: Tue, 26 Aug 2014 15:54:34 +0000

I have made comments on the missing use cases

1)      High-end devices (I'm defining high-end as capable of TLS).  Scenario is : the device, like an industrial pump, presents an identity proof to a gateway service, the service verifies the proof and authenticates the device. Once authenticated, the device can upload telemetry information, query for information, receive notifications and/or receive commands.  We  can accomplish this today with the OAuth 2.0 assertion profile, with client acting as itself, sending a signed assertion to the gateway. The key is pre-provisioned on the device at the manufacture.
a.      The first scenario is to improve on the above. Specific areas of improvement
i.      Lighter weight protocol, reduced amount of bytes sent on the wire, and reduced cpu cycles on the device.
ii.     Address mid-range devices (that have TCP/IP stack but no TLS built in). One candidate that is being looked at is TKS PKS, to allow a shared symmetric key to be used to enable transport level security.
2)      Secret provisioning is another important problem to solve. Scenario is : I bring home my new thermostat and want to associate it with my account, how is it paired? Later when I sell my house, how to I transfer ownership of the thermostat? The most common pattern seems to be having the user get a code from the device, enter it in a pc, than acknowledge the pairing from the device. There are similar patterns for mid-range devices without displays (like https://www.spark.io/), they have a photo resistor, that literally let a phone app flash a code to the device to complete the pairing. Provisioning protocol, should allow for various ways to communicate keys.

Some Interesting consumer scenarios might be:
1)      When I install a new light bulb, how does my wife get access to control it from her phone? This should be seamless, since there can't be an onboarding experience for everything I bring into the home.
2)      If somebody sides a malicious "puck" device under my door, what keeps it from joining the other things in the home and attacking the house.
3)      If I have guests and I want to give control of some parts of my home, how is that done? Use of proximity is one interesting idea I've heard here, if you are in my house you can turn lights on and off.

-----Original Message-----
From: Ace [mailto:[email-masked]] On Behalf Of Ludwig Seitz
Sent: Tuesday, August 26, 2014 12:02 AM
To: [email-masked]
Subject: Re: [Ace] ACE Use Case document

On 08/26/2014 05:12 AM, Anthony Nadalin wrote:
> My major issues and comments with the document is that it does not
> cover a lot of the use case that we see in the marketplace, the use case document can be broader than the scope of the WG (even though I don't see much in the charter that limits the scope).

If you want to contribute more use cases that are relevant, you are most welcome.

Do you think the use cases in the  current document are relevant?
Are there aspects of these use cases that you feel are missing in the document?

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: Anthony Nadalin <[email-masked]>
Date: Tue, 26 Aug 2014 15:57:44 +0000

Agree its call for adoption and it's not a final draft but before we adopt some of us would like to know the direction of this document the ability to add/supplement the use cases

-----Original Message-----
From: Kumar, Sandeep [mailto:[email-masked]] 
Sent: Tuesday, August 26, 2014 12:38 AM
To: Jong-Hyouk Lee; Anthony Nadalin
Cc: Hannes Tschofenig; [email-masked]
Subject: RE: [Ace] ACE Use Case document

Sandeep

-----Original Message-----
From: Ace [mailto:[email-masked]] On Behalf Of Jong-Hyouk Lee
Sent: Tuesday, August 26, 2014 9:12 AM
To: Anthony Nadalin
Cc: Hannes Tschofenig; [email-masked]
Subject: Re: [Ace] ACE Use Case document

Hi all

J.

---

From: Ludwig Seitz <[email-masked]>
Date: Wed, 27 Aug 2014 08:53:50 +0200

> Agree its call for adoption and it's not a final draft but before we adopt some of us would like to know the direction of this document the ability to add/supplement the use cases

When a draft is adopted, the direction of the document is entirely up to 
the WG. Right now we, the authors, can do what we want with the 
document, so I'd say by adopting it you would gain more control about 
the contents.

/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: Ludwig Seitz <[email-masked]>
Date: Wed, 27 Aug 2014 09:40:05 +0200

On 08/26/2014 05:54 PM, Anthony Nadalin wrote:
>  1. High-end devices (I’m defining high-end as capable of TLS).
>     Scenario is : the device, like an industrial pump, presents an
>     identity proof to a gateway service, the service verifies the proof
>     and authenticates the device. Once authenticated, the device can
>     upload telemetry information, query for information, receive
>     notifications and/or receive commands.  We  can accomplish this
>     today with the OAuth 2.0 assertion profile, with client acting as
>     itself, sending a signed assertion to the gateway. The key is
>     pre-provisioned on the device at the manufacture.
>
>  1. The first scenario is to improve on the above. Specific areas of
>     improvement
>
>  1. Lighter weight protocol, reduced amount of bytes sent on the wire,
>     and reduced cpu cycles on the device.
>  2. Address mid-range devices (that have TCP/IP stack but no TLS built
>     in). One candidate that is being looked at is TKS PKS, to allow a
>     shared symmetric key to be used to enable transport level security.
>

Ok, let me try to separate the solutions bits here from what I consider 
to be a use case:

You have a high-end device that is part of an industrial control system.
The system is using an internal network that is separated from the 
Internet and communicates outside this network through a gateway that 
performs authentication (and supposedly authorization). The problems 
that need to be solved here are:
- how to keep unauthorized parties outside of the internal network
- how to allow authorized parties to access devices inside the internal 
network
- how to keep the resource consumption of the protocols solving the 
problems above to a minimum

Does that roughly represent what you meant?
I'd gladly flesh that out into a full ICS use case with your help, but 
I'd like to keep solution related details out of the use case draft, in 
order to avoid biasing this document towards a specific solution.

>  2. Secret provisioning is another important problem to solve. Scenario
>     is : I bring home my new thermostat and want to associate it with my
>     account, how is it paired? Later when I sell my house, how to I
>     transfer ownership of the thermostat? The most common pattern seems
>     to be having the user get a code from the device, enter it in a pc,
>     than acknowledge the pairing from the device. There are similar
>     patterns for mid-range devices without displays (like
>     _https://www.spark.io/_), they have a photo resistor, that literally
>     let a phone app flash a code to the device to complete the pairing.
>     Provisioning protocol, should allow for various ways to communicate
>     keys.
>
>  1. When I install a new light bulb, how does my wife get access to
>     control it from her phone? This should be seamless, since there
>     can’t be an onboarding experience for everything I bring into the home.
>  2. If somebody sides a malicious “puck” device under my door, what
>     keeps it from joining the other things in the home and attacking the
>     house.
>  3. If I have guests and I want to give control of some parts of my
>     home, how is that done? Use of proximity is one interesting idea
>     I’ve heard here, if you are in my house you can turn lights on and off.

To cover this we could extend the home automation use case. Would you 
like to propose an extension to that section of the draft?

/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: Ludwig Seitz <[email-masked]>
Date: Wed, 27 Aug 2014 14:26:00 +0200

On 08/26/2014 11:06 AM, Jong-Hyouk Lee wrote:
> I do not think so. When an individual document has enough supports for adoption, the document can be a WG document. Not necessary, first adopted and then improved.
 > In other words,I do not think that the current document is matured 
enough for calling the adoption.

Could you elaborate on this perceived lack of maturity? The document has 
been around for some time and has been discussed in several IETF 
meetings (IETF 88-90).
> As stated in the abstract, the use-cases document is intended to be a guideline for developing a comprehensive authentication and access control approach
> while deriving security requirements. However, what I concern from the current document is possibilities of lacking of deriving security requirements from the limited use-cases in the document.

I agree with your point that the documents needs a broader set of use 
cases. I think that if the document was adopted, it would be easier to 
get more people to contribute their use cases. Currently it is a private 
submission, and I suspect people might be weary to invest time in a 
document with such an uncertain future.
>
> In addition, I would like to see the document’s improvement in its organisation and structure. For instance, it must help if the document contains a table showing comparisons of the use-cases
> listed in the document in terms of environment (network, protocol, etc) and security requirement.

There is a list of aggregated security requirements in section 3 for 
what it's worth. Fitting that into a table would be difficult and 
probably not very helpful.

As for the network and protocols, since ACE is spawned off CoRE, the 
underlying assumption is that we concentrate on a protocol stack roughly 
like this (*=optional) at start:

CoAP - DTLS* - IPv6 - 6LoWPAN - IEEE 802.15.4

This doesn't preclude the usefulness of our solutions for other protocol 
stacks, but as a baseline it seems useful to me. I have however tried to 
keep such details out of the use case document, and I'd like to hear a 
good argument on why this would be useful, before I start making such 
distinctions in the use cases.

/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: <[email-masked]>
Date: Wed, 27 Aug 2014 16:01:10 +0000

Hello all,

I've read the draft, and notably Section 2.5 with particular interest.
Although I would discuss some of the rationales presented in sections 2.5.1 and 2.5.2, they do not impact the requirements in 2.5.4., which I agree with.
Section 3 also seems good to me.
I therefore recommend adopting the draft as a WG document so that further efforts can be funneled into making it even better.
Best,

Dominique

-----Message d'origine-----
De : Ace [mailto:[email-masked]] De la part de Hannes Tschofenig
Envoyé : jeudi 21 août 2014 15:41
À : [email-masked]
Objet : [Ace] ACE Use Case document

Hi all,

Ciao
Hannes & Kepeng

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: Jong-Hyouk Lee <[email-masked]>
Date: Thu, 28 Aug 2014 12:00:23 +0900

On Aug 27, 2014, at 9:26 PM, Ludwig Seitz <[email-masked]> wrote:

> > In other words,I do not think that the current document is matured enough for calling the adoption.
> 
> Could you elaborate on this perceived lack of maturity? The document has been around for some time and has been discussed in several IETF meetings (IETF 88-90).

You see there are people thinking the current document is immature. The long live and discussion does not mean the document is mature. 

> I agree with your point that the documents needs a broader set of use cases. I think that if the document was adopted, it would be easier to get more people to contribute their use cases. Currently it is a private submission, and I suspect people might be weary to invest time in a document with such an uncertain future.

No more, no less.

> There is a list of aggregated security requirements in section 3 for what it's worth. Fitting that into a table would be difficult and probably not very helpful.

Must be helpful. Try to include a new section containing such a comparison table. If needed, you will have inputs from me.

> 
> As for the network and protocols, since ACE is spawned off CoRE, the underlying assumption is that we concentrate on a protocol stack roughly like this (*=optional) at start:
> 

Could you explicitly write the protocol stack in the document? 

> 
> This doesn't preclude the usefulness of our solutions for other protocol stacks, but as a baseline it seems useful to me. I have however tried to keep such details out of the use case document, and I'd like to hear a good argument on why this would be useful, before I start making such distinctions in the use cases.

Do not expect readers would only people in this room.

J.

---

From: "Kumar, Sandeep" <[email-masked]>
Date: Thu, 28 Aug 2014 07:27:07 +0000

> been around for some time and has been discussed in several IETF meetings
> (IETF 88-90).
>
> You see there are people thinking the current document is immature. The
> long live and discussion does not mean the document is mature.
>

To be frank, you not liking this draft because some other people do not like it is unfortunate. However we are here to discuss it based on technical merits.

---

From: Ludwig Seitz <[email-masked]>
Date: Thu, 28 Aug 2014 10:11:52 +0200

> I therefore recommend adopting the draft as a WG document so that further efforts can be funneled into making it even better.

Dominique,

please share your points about how sections 2.5.1 and 2.5.2 could be 
improved, your input would be much appreciated.

/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: Rene Struik <[email-masked]>
Date: Thu, 28 Aug 2014 08:51:32 -0400

Hi Hannes:

I think also Dorothy Gellert, Anthony Nadalin, Kathleen Moriarty, and 
Mike Jones weighed in on during your first "call for adoption" time 
window. {For their feedback, please see the email archive.}

Given traffic so far, it seems prudent to take the draft off the table 
for now and morph it into something more palatable to the group first.

There are lots of groups working on internet of things style use cases, 
both in home control, industrial control, smart grid, and, e.g., 
critical infrastructure. Shouldn't the efforts of ACE aim to be as 
ambitious as serving all those application domains?

Best regards, Rene

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