Subject: [Ace] Use Case draft

From: Kathleen Moriarty <[email-masked]>
Date: Mon, 28 Jul 2014 16:29:48 -0400

Hello,

I had read through the draft before the meeting and noted that in section
2.2.1, I thought the roles of the people involved in the use case were
distracting.  Changing this may help keep people focused on the scenario as
opposed to details that don't matter for ACE.  FYI - A single woman letting
an acquaintance into her home without her there would be unusual.  Most
women would not do that for safety reasons.  The interpretation of
acquaintance may vary between regions, but for me, an acquaintance is
someone I don't really know well.  If you make Jeffrey her brother, or
switch the roles of Jeffrey & Jane, the scenario is much more plausible and
will help to prevent people from getting distracted while reading this
scenario.

In reading through the draft, I noticed a few things missing from the
Security Requirements section that could be helpful for the next editorial
pass.  If there were reasons they were not included, please let me know.

1. Threats such as session intercept/hijacking or monitoring are not
covered yet.

2. Logging, protection of logs (and purging) is mentioned in one of the use
cases, but not in the security section.  This would be a good addition, but
should also include privacy considerations associated with the logs as well
(correlation of events, etc.).

3. There will also be a number of privacy considerations that should be
noted in this section or one on privacy.  This might include concerns of
being able to profile habits of a person or other similar concerns.

Thanks!
-- 

Best regards,
Kathleen

---

From: Ludwig Seitz <[email-masked]>
Date: Tue, 29 Jul 2014 10:01:49 +0200

On 07/28/2014 10:29 PM, Kathleen Moriarty wrote:
> Hello,
>
> I had read through the draft before the meeting and noted that in
> section 2.2.1, I thought the roles of the people involved in the use
> case were distracting.  Changing this may help keep people focused on
> the scenario as opposed to details that don't matter for ACE.  FYI - A
> single woman letting an acquaintance into her home without her there
> would be unusual.  Most women would not do that for safety reasons.  The
> interpretation of acquaintance may vary between regions, but for me, an
> acquaintance is someone I don't really know well.  If you make Jeffrey
> her brother, or switch the roles of Jeffrey & Jane, the scenario is much
> more plausible and will help to prevent people from getting distracted
> while reading this scenario.
>
I'll update this in the next version if we don't change the use case 
entirely.

> Security Requirements section that could be helpful for the next
> editorial pass.  If there were reasons they were not included, please
> let me know.
>

The idea of this draft was to cover issues concerning authentication and 
authorization (and a few  directly related issues) since that is the 
topic of ACE. I think the problems you mention above are not directly 
relevant for ACE, therefore I left them out of the document.

>
> 2. Logging, protection of logs (and purging) is mentioned in one of the
> use cases, but not in the security section.  This would be a good
> addition, but should also include privacy considerations associated with
> the logs as well (correlation of events, etc.).

We had a discussion about Auditing (the third A of AAA) and logging 
during the chartering process, and some people thought it would make the 
focus of the group too broad to try and also cover Auditing (including 
logging).

Therefore I have left out questions of auditing (and privacy) for the 
moment.

> being able to profile habits of a person or other similar concerns.

See above.

Regards,

Ludwig Seitz

-- 
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: Stefanie Gerdes <[email-masked]>
Date: Tue, 29 Jul 2014 14:16:20 +0200

Hi Kathleen and Ludwig,

> Therefore I have left out questions of auditing (and privacy) for the

I think privacy is interesting to consider. The reason for using
authorization mechanisms is to protect data, i.e. to achieve certain
security objectives such as integrity and confidentiality. Privacy is
interesting to consider as it stresses the need for confidentiality.

Thanks
Steffi

---

From: Kathleen Moriarty <[email-masked]>
Date: Tue, 29 Jul 2014 09:32:17 -0400

Hello,

On Tue, Jul 29, 2014 at 4:01 AM, Ludwig Seitz <[email-masked]> wrote:

> authorization (and a few  directly related issues) since that is the topic
> of ACE. I think the problems you mention above are not directly relevant
> for ACE, therefore I left them out of the document.
>
> Understood, however, if you leave out any type of encryption (or
motivation for it), for authentication and authorization you'll need replay
protection as a requirement to prevent fraud or other attacks.

In terms of other types of attacks that are possible, but not a focus for
this working group, you'll still need to list them to cover you bases for
readers of the work.  This doesn't mean that you have to solve all of the
problems, but rather list them as "Security Considerations".  One way to do
it would be through another section that is called security considerations.
 Then when you have subsequent drafts that implement, you can point to that
section for 'additional considerations' for the developer, implementer, and
user.  Monitoring (RFC7258 - for PM) and session intercept should be listed
as considerations, but don't have to be solved by the WG.  You can state
that the considerations are important, but out of scope for ACE.

> We had a discussion about Auditing (the third A of AAA) and logging during
> the chartering process, and some people thought it would make the focus of
> the group too broad to try and also cover Auditing (including logging).
>

Sure, I should have been more clear, I'm just looking or the set of
considerations to be listed and I think adding this into a Security
Considerations section would be good.  I'm not asking the WG to cover it
and agree that the specification of this functionality is out-of-scope.
 You can then point to it from other drafts as the set of considerations.

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

-- 

Best regards,
Kathleen

---

From: Anthony Nadalin <[email-masked]>
Date: Tue, 29 Jul 2014 16:37:52 +0000

So it looks like the use cases so far are more geared toward device to cloud, with a central cloud service that provides orchestration between devices and not towards peer to peer and on-prem services ?

-----Original Message-----
From: Ace [mailto:[email-masked]] On Behalf Of Ludwig Seitz
Sent: Tuesday, July 29, 2014 1:02 AM
To: [email-masked]
Subject: Re: [Ace] Use Case draft

On 07/28/2014 10:29 PM, Kathleen Moriarty wrote:
> would be unusual.  Most women would not do that for safety reasons.  
> The interpretation of acquaintance may vary between regions, but for 
> me, an acquaintance is someone I don't really know well.  If you make 
> Jeffrey her brother, or switch the roles of Jeffrey & Jane, the 
> scenario is much more plausible and will help to prevent people from 
> getting distracted while reading this scenario.
>
I'll update this in the next version if we don't change the use case entirely.

> 1. Threats such as session intercept/hijacking or monitoring are not 

The idea of this draft was to cover issues concerning authentication and authorization (and a few  directly related issues) since that is the topic of ACE. I think the problems you mention above are not directly relevant for ACE, therefore I left them out of the document.

>
> 2. Logging, protection of logs (and purging) is mentioned in one of 
> the use cases, but not in the security section.  This would be a good 
> addition, but should also include privacy considerations associated 
> with the logs as well (correlation of events, etc.).

We had a discussion about Auditing (the third A of AAA) and logging during the chartering process, and some people thought it would make the focus of the group too broad to try and also cover Auditing (including logging).

Therefore I have left out questions of auditing (and privacy) for the moment.

See above.

Regards,

Ludwig Seitz

-- 
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: Stefanie Gerdes <[email-masked]>
Date: Tue, 29 Jul 2014 20:21:01 +0200

Hi Anthony,

The aim is to enable peer to peer communication between two devices
which may both be constrained.

The scenario we are discussing is:
 * A Client (C) wants to access a Resource (R) on a Resource Server (RS).
 * A priori, C and RS do not necessarily know each other and have no
security relationship.
 * C and / or RS are constrained.
(cf. [1])

The goal is to enable C and RS to communicate securely and to enforce
the authorization policies of their respective owners.

To achieve this, Authorization Servers are introduced which relieve the
constrained devices from performing more difficult tasks and help them
with authentication and authorization.

Does this answer your question?

Steffi

[1] http://tools.ietf.org/pdf/draft-gerdes-ace-actors-01.pdf

-- 
Stefanie Gerdes			Tel: +49 421 218 63906
TZI Universität Bremen		E-Mail: [email-masked]
Bibliothekstr. 1, MZH 5150
28359 Bremen, Germany

---

From: Dorothy Gellert <[email-masked]>
Date: Tue, 29 Jul 2014 23:15:15 +0000

Hi Anthony-

We should consider both device to cloud and peer to peer - otherwise the
protocol will have design in preventive measures against unsupported
deployment models. 

Best Regards,
Dorothy Gellert
Silver Spring Networks
Director, Standards and Technology
E [email-masked]
O +1 650 839 4378
C +1 650 556-5994

On 7/29/14, 9:37 AM, "Anthony Nadalin" <[email-masked]> wrote:

>So it looks like the use cases so far are more geared toward device to
>cloud, with a central cloud service that provides orchestration between
>devices and not towards peer to peer and on-prem services ?
>

---

From: Anthony Nadalin <[email-masked]>
Date: Wed, 30 Jul 2014 17:42:28 +0000

I totally agree bit I'm just not seeing the peer-2-peer in the current use case document.

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: Dorothy Gellert [mailto:[email-masked]]
Sent: Tuesday, July 29, 2014 4:15 PM
To: Anthony Nadalin; Ludwig Seitz; [email-masked]
Subject: Re: [Ace] Use Case draft

Hi Anthony-

We should consider both device to cloud and peer to peer - otherwise the protocol will have design in preventive measures against unsupported deployment models.

Best Regards,

Dorothy Gellert

Silver Spring Networks

E [email-masked]<mailto:[email-masked]>

O +1 650 839 4378

C +1 650 556-5994

>To: [email-masked]<mailto:[email-masked]>

>> the scenario as opposed to details that don't matter for ACE.  FYI -

>> A single woman letting an acquaintance into her home without her

>> there would be unusual.  Most women would not do that for safety reasons.

>The idea of this draft was to cover issues concerning authentication

>and authorization (and a few  directly related issues) since that is

>the topic of ACE. I think the problems you mention above are not

>directly relevant for ACE, therefore I left them out of the document.

>during the chartering process, and some people thought it would make

>the focus of the group too broad to try and also cover Auditing

>(including logging).

>> 3. There will also be a number of privacy considerations that should

>> be noted in this section or one on privacy.  This might include

>> concerns of being able to profile habits of a person or other similar concerns.

>[email-masked]<mailto:[email-masked]>

---

From: Michael Richardson <[email-masked]>
Date: Wed, 30 Jul 2014 16:44:53 -0400

Stefanie Gerdes <[email-masked]> wrote:
    > The scenario we are discussing is: * A Client (C) wants to access a
    > Resource (R) on a Resource Server (RS).  * A priori, C and RS do not
    > necessarily know each other and have no security relationship.  * C and
    > / or RS are constrained.  (cf. [1])

No, his question was:

    >> cloud, with a central cloud service that provides orchestration
    >> between devices and not towards peer to peer and on-prem services ?

and the answer is that having a "central" "cloud" service is only *one*
possible location for the Authorization Manager and Authorization Server.

They could also be located on-site (of a factory, or home. Behind the
"NAT"^W"security firewall"..),  or be co-located inside a non-constrained C
or RS.

[Obviously, if both are non-constrained, there appears to be no point, but
that also assumes all RS and all C are such]

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

---

From: Michael Richardson <[email-masked]>
Date: Wed, 30 Jul 2014 16:49:01 -0400

> 1) High-end devices (I'm defining high-end as capable of TLS).
    > Scenario is : the device, like an industrial pump, presents an identity

There are many people who would define a device capable of TLS as class-2,
not high end, and would say that it barely does DTLS, and maybe can not do
more than a few DTLS session setups per battery charge.
Can it do OAUTH2? it's a code space issue.

    > The key is pre-provisioned on the device at
    > the manufacture.

    > 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

Out of scope for ACE at this time.
See UCAN BOF.

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

all out of scope for *this* WG.

---

From: Mike Jones <[email-masked]>
Date: Wed, 30 Jul 2014 22:15:39 +0000

If all of this is out of scope, how will these problems be solved end-to-end?  Are there specific other working groups working on these issues?  Which ones does ACE plan to restrict itself to?

				-- Mike

-----Original Message-----
From: Ace [mailto:[email-masked]] On Behalf Of Michael Richardson
Sent: Wednesday, July 30, 2014 1:49 PM
To: [email-masked]
Subject: Re: [Ace] Use Case draft

    > Scenario is : the device, like an industrial pump, presents an identity

There are many people who would define a device capable of TLS as class-2, not high end, and would say that it barely does DTLS, and maybe can not do more than a few DTLS session setups per battery charge.
Can it do OAUTH2? it's a code space issue.

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

---

From: Likepeng <[email-masked]>
Date: Thu, 31 Jul 2014 07:59:21 +0000

Here is the IETF 90 ACE meeting minutes:
http://www.ietf.org/proceedings/90/minutes/minutes-90-ace

Thanks to Kerry Lynn for taking the minutes.

Kind Regards
Kepeng

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 31 Jul 2014 13:44:59 +0200

On 30 Jul 2014, at 22:49, Michael Richardson <[email-masked]> wrote:

>> account, how is it paired?

ACE needs to enable this.  (And it may want to work without requiring the concept of “account”.)
The initial method of pairing or whatever is out of scope (being able to keep it here is one of the points of the differentiation between AM and AS).

>> Later when I sell my house, how to I

Ownership transfer is an important authorization use case.
(The more interesting question, how do you forcibly gain ownership for the contents of a foreclosed home, is way out of scope, though.)

> See UCAN BOF.

I don’t think UCAN discusses ownership transfer.

>> be an onboarding experience for everything I bring into the home.

The ACE specifications definitely need to enable this.
The entire problem may not be solved by them (but what is).

>> keeps it from joining the other things in the home and attacking the

If the ACE protocols are not secure against this I have no idea whatsoever what we are trying to do.
(It’s not exactly a “use case” in the classical sense; maybe we should be explicit about misuse cases and threats in general.)

>> heard here, if you are in my house you can turn lights on and off.

Again, ACE needs to enable this.
The method of proximity/in-perimeter detection is out of scope.

> all out of scope for *this* WG.

Not so sure about that.

Grüße, Carsten

---

From: Martin Murillo <[email-masked]>
Date: Fri, 01 Aug 2014 02:11:08 -0400

Hi,

The shipping container use case is an example of the need of a peer to 
peer connection. As it is right now, it describes a very ideal situation 
in which a client has access to the resource (i.e. there's no objects in 
the path, no interference, the node is assumed to be working good). This 
is during transportation inside a container and during individual box 
handling to/from container/distribution point.

In a real scenario, also present in industrial areas where sensor 
networks are used for non critical tasks, a node does not always have 
direct access to the resource (i.e. base station). This can be due to 
objects on the way, interference of other devices (even though they work 
with spread spectrum), or the node not working properly.

Thus peer to peer connection is used in the form of mesh networking (or 
other scheme) so nodes in the proximity can talk to each other and have 
better chances to reach the base station or resource or just disseminate 
their information. In some scenarios when there's hundreds of nodes, 
master nodes are also used in addition to the base station.

Martin

On 7/30/2014 1:42 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.
>
> 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 
> 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 
> 2)If somebody sides a malicious "puck" device under my door, what 
> 3)If I have guests and I want to give control of some parts of my 
> We should consider both device to cloud and peer to peer - otherwise 
> the protocol will have design in preventive measures against 
> unsupported deployment models.
>
> Best Regards,
>
> Dorothy Gellert
>
> Silver Spring Networks
>
> E [email-masked] <mailto:[email-masked]>
>
> O +1 650 839 4378
>
> C +1 650 556-5994
>
> >To: [email-masked] <mailto:[email-masked]>
>
> >[email-masked] <mailto:[email-masked]>
>