Subject: [Ace] New problem summary sections

From: Stefanie Gerdes <[email-masked]>
Date: Mon, 09 Mar 2015 18:39:03 +0100

Hi all,

Please find below the new problem summary sections. Since we want to 
update the draft before the Internet Draft submission cut-off please 
respond quickly (until 21:00 UTC) if you have any objections.

The problem summary section for the home automation use case was not 
changed.

Health Monitoring:

Old:

   o  U3.1 A principal, such as the owner of a health monitoring device,
       wants to pre-configure access rights to specific data for persons
       or groups, in the context of an emergency.
    o  U3.2 A principal wants to selectively allow different persons or
       groups to access medical data.
    o  U3.3 The security measures could affect battery lifetime of the
       devices and should changes of battery are highly inconvenient.
    o  U3.4 Devices are often used with default access control settings.
    o  U3.5 Principals are often not trained in computer use and
       especially computer security.
    o  U3.6 Security mechanisms themselves could provide opportunities
       for denial of service attacks on the device.
    o  U3.7 The device provides a service that can be fatal for the
       principal if it fails.  Accordingly, the principal wants a
       security mechanism to provide a high level of security.

New:

* U3.1  The wearer of an eHealth device (John in the example above) 
wants to pre-configure special access rights in the context of an emergency.
* U3.2 The wearer of an eHealth device wants to selectively allow 
different persons or groups access to medical data.
* U3.3 The Security measures could affect battery lifetime of the device 
and changing the battery is very inconvenient.
* U3.4 Devices are often used with default access control settings.
* U3.5 Wearers of eHealth devices are often not trained in computer use, 
and especially computer security.
* U3.6 Security mechanisms themselves could provide opportunities for 
denial of service attacks on the device.
* U3.7 The device provides a service that can be fatal for the wearer if 
it fails.  Accordingly, the wearer wants a security mechanism to provide 
a high level of security.

Building Automation:

old:

    o  U4.1 Principals want to be able to add a new device to their
       administrative domain (commissioning).
    o  U4.2 Principals want to be able to integrate a device that
       formerly belonged to a different administrative domain to their
       own administrative domain (handover).
    o  U4.3 Principal want to be able to remove a device from their
       administrative domain (decomissioning).
    o  U4.4 Principals want to be able to delegate selected
       administration tasks for their devices to others.
    o  U4.5 The principal wants to be able to define context-based
       Authorization rules.
    o  U4.6 The principal wants to be able to revoke granted permissions
       and delegations.
   o  U4.7 The principal wants to allow authorized entities to send data
       to their endpoints (default deny).
    o  U4.8 The principal wants to be able to authorize a device to
       control several devices at the same time using a multicast
       protocol.
    o  U4.9 Principals want to be able to interconnect their own
       subsystems with those from a different operational domain while
       keeping the control over the authorizations (e.g. granting and
       revoking permissions) for their endpoints and devices.

new:

* U4.1 The building owner and the companies want to be able to add new 
devices to their administrative domain (commissioning).
* U4.2 The building owner and the companies want to be able to integrate 
a device that formerly belonged to a different administrative domain to 
their own administrative domain (handover).
* U4.3 The building owner and the companies want to be able to remove a 
device from their administrative domain (decomissioning).
* U4.4 The building owner and the companies want to be able to delegate 
selected administration tasks for their devices to others.
* U4.5 The building owner and the companies want to be able to define
   context-based authorization rules.
* U4.6 The building owner and the companies want to be able to revoke 
granted permissions and delegations.
* U4.7 The building owner and the companies want to allow authorized 
entities to send data to their endpoints (default deny).
* U4.8 The building owner and the companies want to be able to authorize 
a device to control several devices at the same time using a multicast 
protocol.
* U4.9 The companies want to be able to interconnect their own 
subsystems with those from a different operational domain while keeping 
the control over the authorizations (e.g. granting and revoking 
permissions) for their endpoints and devices.

Smart Metering:

* U5.1  Devices are installed in hostile environments where they are 
physically accessible by attackers.  The service operator and the 
utility company	want to make sure that an attacker cannot use a captured 
device to attack other parts of their infrastructure.
* U5.2  The utility company wants to restrict which entities are allowed 
to send data to their endpoints and to ensure the integrity of the data 
on their endpoints.	
* U5.3  The utility company wants to control which entities are allowed 
to read data on their endpoints and protect such data in transfer.
* U5.4  The devices may have intermittent Internet connectivity.
* U5.5  Neither the service operator nor the utility company are 
always present	at the time of access and cannot manually intervene in 
the authorization process.
* U5.6  When authorization policies are updated it is impossible, or at 
least very inefficient to contact all affected endpoints directly.

Old:

* U5.7 Messages between clients and resource servers may need to be 
stored and forwarded over multiple nodes.

New:

* U5.7 Messages between endpoints may need to be stored	and forwarded 
over multiple nodes.

Sports and Entertainment:

Old:
    o  U6.1 The principal wants to be able to grant access rights
       dynamically when needed.
    o  U6.2 The principle wants the configuration of access rights to
       work with very little effort.
    o  U6.3 The principal wants to be able to preconfigure access
       policies that grant certain access permissions to endpoints with
       certain attributes (e.g. endpoints of a certain user) without
       additional configuration effort at the time of access.
    o  U6.4 Principals wants to protect the confidentiality of their data
       for privacy reasons.
    o  U6.5 Devices might not have an Internet connection at the time of
       access.

New:
* U6.1 Sports equipment owners want to be able to grant access rights
   dynamically when needed.
* U6.2 Sports equipment owners want the configuration of access rights
   to work with very little effort.
* U6.3 Sports equipment owners want to be able to preconfigure access
   policies that grant certain access permissions to endpoints with
   certain attributes (e.g. endpoints of a certain user) without
   additional configuration effort at the time of access.
* U6.4 Sports equipment owners to protect the confidentiality of their
   data for privacy reasons.
* U6.5 Devices might not have an Internet connection at the time of
   access.

Industrial Control Systems:

Old:
    o  U7.1 The principal wants to ensure that only authorized clients
       can read data from sensors and sent commands to actuators.
    o  U7.2 The principal wants to ensure that data coming from sensors
       and commands sent to actuators are authentic.
    o  U7.3 Some devices do not have direct Internet connection.
    o  U7.4 Some devices have wired connection while others use wireless.
    o  U7.5 The execution of unauthorized commands in an ICS can lead to
       significant financial damage, and threaten the availability of
       critical infrastructure services.  Accordingly, the principal
       wants a security solution that provides a very high level of
       security.

New:
* U7.1 The operator of the platform wants to ensure the
   confidentiality of sensor data and the integrity of actuator data.
* U7.2 The operator wants to ensure that data coming from sensors and
   commands sent to actuators are authentic.
* U7.3 Some devices do not have direct Internet connection.
* U7.4 Some devices have wired connection while others use wireless.
* U7.5 The execution of unauthorized commands in an ICS can lead to
   significant financial damage, and threaten the availability of
   critical infrastructure services.  Accordingly, the operator wants a
   security solution that provides a very high level of security.

Best regards,
Steffi

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

---

From: Alper Yegin <[email-masked]>
Date: Mon, 9 Mar 2015 20:16:46 +0200

Hello,

I've just read the ace-usecases-02 I-D, and here are my comments.

Title: ACE use cases

It seems the document is more than just description of the use cases. It includes authorization problems, design considerations (sometimes reading like requirements), attacks, etc. It'd be better to rename the document to capture the actual scope.

   These use cases aim at identifying authorization
   problems that arise during the lifecycle of a constrained device.
   Note that this document does not aim at collecting all possible use
   cases.

At times the document also talks about authentication, integrity protection, and confidentiality. Again, scope is not really limited to "authorization" only as the aforementioned text states.

   They
   are connected to the Internet through an intermediary base-station,
   using wireless technologies.  

Later smartphone is given as an example of "access point." It may be better to replace the term "base-station" with "device, such as smartphone, access point, or base station."

   The device includes some authentication mechanism, in order to
   prevent other persons who get physical access to it from acting as
   the owner and messing up the access control and security settings.

s/authentication/authentication and authorization

   o  U5.6 When authorization policies are updated it is impossible, or
      at least very inefficient to contact all affected endpoints
      directly.

s/directly/simultaneously??

   Due to their
   limited capabilities, constrained devices appear as the weakest link
   in the network and hence pose an attractive target for attackers.

Physical accessibility is an important factor here too.

   o  Usability is important for all use cases.  The configuration of
      authorization policies as well as the gaining access to devices
      must be simple for the users of the devices.  Special care needs
      to be taken for home scenarios where access control policies have
      to be configured by users that are typically not trained in
      security (see Section 2.2, Section 2.3, Section 2.6).

Actually, in addition to the home scenario, sports&entertainment, personal health care, and even building automation have same kind of non-techie users involved.

Question: is this document supposed to cover the requirements as well, or will there be a separate document for that? If former, then I think there's more work needed on the document.

Thanks.

Alper

---

From: Göran Selander <[email-masked]>
Date: Mon, 9 Mar 2015 18:52:17 +0000

Hi Steffi,

This is much better! As you know, I’m not convinced that everything is in
scope of ACE, but this text is much more readable and transparent and thus
allows anyone to form an opinion on the topic.

Thanks
Göran

On 2015-03-09 18:39, "Stefanie Gerdes" <[email-masked]> wrote:

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

---

From: Stefanie Gerdes <[email-masked]>
Date: Mon, 09 Mar 2015 21:34:14 +0100

Hi Alper,

Thank you for your comments.

>     Note that this document does not aim at collecting all possible use

The focus of the draft is the description of authorization problems from 
a user/owner/principal perspective. The listed problems are more useful 
if we summarize them in the end. That is why we have a part for this in 
the security summary section. However, the draft is not intended to be a 
requirements document and I don't think it should be. Summarizing the 
relevant problems was difficult enough. I can't imagine that we will be 
able to collect the relevant requirements.

Kathleen suggested to add attacks to the security considerations section 
(cf. http://www.ietf.org/mail-archive/web/ace/current/msg00765.html)

> At times the document also talks about authentication, integrity protection, and confidentiality. Again, scope is not really limited to "authorization" only as the aforementioned text states.

I think it will be difficult to talk about authorization without 
mentioning integrity and confidentiality since these security objectives 
are the reason why we need authorization in the first place (see also 
section 3 of [1])

Authentication and authorization need to work together to be useful as 
described in section 4 of [1].

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

> Later smartphone is given as an example of "access point." It may be better to replace the term "base-station" with "device, such as smartphone, access point, or base station."

I don't have a strong opinion on that.

> s/authentication/authentication and authorization

Although some unauthorized entity gets permissions in this case, 
impersonating as someone else is solved by an authentication solution. 
Nevertheless, I think that we need both to protect the access control 
and security settings: An authorization mechanism that makes sure that 
only authorized entities are able to configure access control and 
security settings and an authentication mechanism that prevents 
impersonation. I think we should change the draft accordingly.

I am not sure about the physical access part and if an authentication 
mechanism will help against a physical attack. I think we should replace 
"physical access" with "access".

> s/directly/simultaneously??

The problem that is addressed here is that there are a lot of devices, 
and that we would need to reach all of them if authorization policies 
are updated. I don't know if it is necessary to contact them 
simoultaneously.

> Physical accessibility is an important factor here too.

Yes, it is mentioned in the attacks section.

> Actually, in addition to the home scenario, sports&entertainment, personal health care, and even building automation have same kind of non-techie users involved.

With home scenarios we meant non-corporate scenarios. Would it help to 
replace "home scenario" with "non-corporate scenario"?

The building automation use case is a bit different because the 
authorization policies will likely be configured by trained administrators.

Best regards,
Steffi

---

From: Alper Yegin <[email-masked]>
Date: Tue, 10 Mar 2015 00:17:19 +0200

Hi Steffi,

On Mar 9, 2015, at 10:34 PM, Stefanie Gerdes wrote:
> The problem that is addressed here is that there are a lot of devices, and that we would need to reach all of them if authorization policies are updated. I don't know if it is necessary to contact them simultaneously.

OK, I'm trying to understand what the issue is. Or, what this text is really pointing to.
Is it implying that, not all affected endpoints need to be contacted?
Or, not all affected endpoints need to be contacted directly (i.e., indirect contact is OK -- and we need to understand what's meant by that)?
I thought the text was trying to say simultaneous contact is not possible.

> With home scenarios we meant non-corporate scenarios. Would it help to replace "home scenario" with "non-corporate scenario"?
> 
> The building automation use case is a bit different because the authorization policies will likely be configured by trained administrators.
> 

OK, home scenario is an "example". It's not meant to be provided as an exclusive list of scenarios. So, an "e.g.," would help in there.

Regards,

Alper

---

From: Ludwig Seitz <[email-masked]>
Date: Tue, 10 Mar 2015 13:14:48 +0100

On 03/09/2015 11:17 PM, Alper Yegin wrote:
>> simultaneously.

It is implying that it is a problem if all affected endpoints need to be 
contacted every time an authorization policy changes.

So 'directly' was meant to express some close temporal relation between 
the update of authorization policies and the need to contact all 
affected endpoints.

Perhaps this warrants a clarification in the draft?

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: Stefanie Gerdes <[email-masked]>
Date: Tue, 10 Mar 2015 13:57:48 +0100

> Perhaps this warrants a clarification in the draft?

Maybe we should describe the underlying problem a bit more. As far as I 
understand it, the problem is that we need to make sure that a device 
can enforce the new authorization policies. Therefore it must know at 
the time of a new request what the new authorization policies are. One 
way to solve this would be to provide the update of the authorization 
policies to all devices as fast as possible. But this might be 
impossible or very inefficient.

It might be good to point this out more clearly.

Best regards,
Steffi