Subject: Re: [Ace] U1.2 in Use Case Document

From: Stefanie Gerdes <[email-masked]>
Date: Mon, 09 Mar 2015 11:06:42 +0100

Hi Göran,

I think you forgot to include the mailing list.

On 03/09/2015 10:08 AM, Göran Selander wrote:
> Hi Steffi,
>
> Let’s be brief, since you are probably also working on other drafts.
>
> This is a use case document. We should just describe what we consider are
> the relevant to understand the access control problems of the use cases.
> What you describe as acccess control problem (or authorization problems)
> on the client is
> not what I call an access control problem. Hence when you refer to
> authorizations of a client I don’t consider that to be in scope of ACE.

Yes, we should describe the problems that we have in certain use cases. 
Your proposal that we do authorization solely on the server side is not 
a problem. It is a solution.

>
> For the same reason, I don’t propose a new formulation, because you will
> not approve of one which doesn’t explicitly mention the client, right?

Wrong. I only want to make sure that the phrasing does not indicate that 
authorization on the server side is more important.

> Or
> would you accept something more general such as "Principal is an entity
> setting access control polices” (I haven’t polished on this formulation as
> it may be just a waste of time)

How about "Principal: The subject who is in charge of granting 
authorizations".

>
> I don’t expect anyone of us to change opinion about this today, do you?
>
> When do you want an update of the security considerations?

Since the client side / server side authorization problem is not 
mentioned in the security considerations as far as I can see, I don't 
see a need to update this section. If you see a problem there, please 
point it out to me.

Concerning the problem summary sections, do we agree on the proposal in 
http://www.ietf.org/mail-archive/web/ace/current/msg01042.html:

U1.1 Fruit vendors, transloading personnel and container owners want to 
define authorizations for their resources and endpoints.

We can change this to:

U1.1 Fruit vendors, transloading personnel and container owners want to 
grant different authorizations for their resources and/or endpoints to 
different parties.

or to:

U1.1 Fruit vendors, transloading personnel and container owners want to 
grant different authorizations to different parties.

U1.2 The fruit vendor requires the integrity of the sensor data that 
pertains the state of the goods for climate control and to ensure the 
quality of the monitored recordings.

U1.3 The container owner requires the integrity of the sensor data that 
is used for climate control.

U1.4 The fruit vendor requires the confidentiality of the sensor data 
that pertains the state of the goods.

U1.5 The fruit vendor may have several types of data that may be 
controlled by the same endpoint, e.g., sensor data and the data used for 
logistics.

U1.6 The fruit vendor requires the confidentiality of the data that is 
used to locate the goods.

U1.7 The fruit vendor requires the integrity of the data that is used to 
locate the goods.

U1.8 The transloading personnel requires the integrity of the data that 
is used to locate the goods.

U1.9 The container owner and the fruit vendor may not be present at the 
time of access and cannot manually intervene in the authorization process.

U1.10 The fruit vendor, container owner and transloading company want to 
grant temporary access permissions to a party.

U1.11 Messages between client and resource server might need to be 
forwarded over multiple hops.

U1.12 The constrained devices might not always be able to reach the 
Internet.

Best regards,
Steffi

---

From: Göran Selander <[email-masked]>
Date: Mon, 9 Mar 2015 10:48:03 +0000

Hi Steffi,

>I think you forgot to include the mailing list.

Well, no I didn't, I responded to a mail directly from you.

>a problem. It is a solution.

My proposal is to describe the problems you see in each use cases and
don’t hide behind terminology.

>How about "Principal: The subject who is in charge of granting

I think there may be a problem if we would agree on a term that we both
know is interpreted differently. And I don’t think the term is necessary.
Please find at the end of this mail a proposed update to the security and
privacy considerations (sections 3 & 4) without the terms “Principal”,
“Client” and “Resource Server”.

>U1.12 The constrained devices might not always be able to reach the

This is fine by me.

Best Regards,
Göran

>Steffi

Below are sections 3 & 4 with duplicate paragraphs labelled them “OLD” and
NEW” for comparison.

3.  Security Considerations

   As the use cases listed in this document demonstrate, constrained
   devices are used in various application areas.  The appeal of these
   devices is that they are small and inexpensive.  That makes it easy
   to integrate them into many aspects of everyday life.  Therefore, the
   devices will be entrusted with vast amounts of valuable data or even
   control functions, that need to be protected from unauthorized
   access.  Moreover, the aggregation of data must be considered:
   attackers might not only collect data from a single device but from
   many devices, thus increasing the potential damage.

   Not only the data on the constrained devices themselves is
   threatened, the devices might also be abused as an intrusion point to
   infiltrate a network.  Once an attacker gained control over the
   device, it can be used to attack other devices as well.  Due to their
   limited capabilities, constrained devices appear as the weakest link
   in the network and hence pose an attractive target for attackers.

   This section summarizes the security problems highlighted by the use
   cases above and provides guidelines for the design of protocols for
   authentication and authorization in constrained RESTful environments.

3.1.  Attacks

OLD
   This document lists security problems that principals of constrained
   devices want to solve.  Further analysis of attack scenarios is not
   in scope of the document.  However, there are attacks that must be
   considered by solution developers.
NEW
   This document lists security problems of constrained-node networks.
   Further analysis of attack scenarios is not
   in scope of the document.  However, there are attacks that must be
   considered by solution developers.

   Because of the expected large number of devices and their ubiquity,
   constrained devices increase the danger from Pervasive Monitoring
   [RFC7258] attacks.

   As some of the use cases indicate, constrained devices may be
   installed in hostile environments where they are physically
   accessible (see Section 2.5).  Protection from physical attacks is
   not in the scope of ACE, but should be kept in mind by developers of
   authorization solutions.

   Denial of service (DoS) attacks threaten the availability of services
   a device provides.  E.g., an attacker can induce a device to perform
   steps of a heavy weight security protocol (e.g.  Datagram Transport
   Layer Security (DTLS) [RFC6347]) before authentication and
   authorization can be verified, thus exhausting the device's system
   resources.  This leads to a temporary or - e.g. if the batteries are
   drained - permanent failure of the service.  For some services of
   constrained devices, availability is especially important (see
   Section 2.3).  Because of their limitations, constrained devices are
   especially vulnerable to denial of service attacks.  Solution
   designers must be particularly careful to consider these limitations
   in every part of the protocol.  This includes:

   o  Battery usage

   o  Number of message exchanges required by security measures

   o  Size of data that is transmitted (e.g. authentication and access
      control data)

   o  Size of code required to run the protocol

   o  Size of RAM memory and stack required to run the protocol

   Another category of attacks that needs to be considered by solution
   developers is session interception and hijacking.

3.2.  Configuration of Access Permissions

OLD
   o  The access control policies of the principals need to be enforced
      (all use cases): The information that is needed to implement the
      access control policies of the Principals need to be provided to
      the device that enforces the authorization and applied to every
      incoming request.
NEW
   o  The access control policies need to be enforced
      (all use cases): The information that is needed to implement the
      access control policies need to be provided to
      the device that enforces the authorization and applied to every
      incoming request.

   o  A single resource might have different access rights for different
      requesting entities (all use cases).

      Rationale: In some cases different types of users need different
      access rights, as opposed to a binary approach where the same
      access permissions are granted to all authenticated users.

   o  A device might host several resources where each resource has its
      own access control policy (all use cases).

   o  The device that makes the policy decisions should be able to
      evaluate context-based permissions such as location or time of
      access (see e.g.  Section 2.2, Section 2.3, Section 2.4).  Access
      may depend on local conditions, e.g. access to health data in an
      emergency.  The device that makes the policy decisions should be
      able to take such conditions into account.

3.3.  Design Considerations for Authorization Solutions

OLD
   o  Devices need to be enabled to enforce the principal's
      authorization policies without the principal's intervention at the
      time of the access request (see e.g.  Section 2.1, Section 2.2,
      Section 2.4, Section 2.5).
NEW
   o  Devices need to be enabled to enforce
      authorization policies without human intervention at the
      time of the access request (see e.g.  Section 2.1, Section 2.2,
      Section 2.4, Section 2.5).

   o  Authorization solutions need to consider that constrained devices
      might not have internet access at the time of the access request
      (see e.g.  Section 2.1, Section 2.3, Section 2.5, Section 2.6).

   o  It should be possible to update access control policies without
      manually re-provisioning individual devices (see e.g.
      Section 2.2, Section 2.3, Section 2.5, Section 2.6).

      Rationale: Peers can change rapidly which makes manual re-
      provisioning unreasonably expensive.

OLD
   o  Principals might define authorization policies for a large number
      of devices that might only have intermittent connectivity.
      Distributing policy updates to every device for every update might
      not be a feasible solution (see e.g.  Section 2.5).
NEW
   o  Authorization policies may be defined to apply to a large number
      of devices that might only have intermittent connectivity.
      Distributing policy updates to every device for every update might
      not be a feasible solution (see e.g.  Section 2.5).

   o  It must be possible to dynamically revoke authorizations (see e.g.
      Section 2.4).

   o  The authentication and access control protocol can put undue
      burden on the constrained system resources of a device
      participating in the protocol.  An authorization solutions must
      take the limitations of the constrained devices into account (all
      use cases, see also Section 3.1).

   o  Secure default settings are needed for the initial state of the
      authentication and authorization protocols (all use cases).

      Rationale: Many attacks exploit insecure default settings, and
      experience shows that default settings are frequently left
      unchanged by the end users.

   o  Access to resources on other devices should only be permitted if a
      rule exists that explicitly allows this access (default deny) (see
      e.g.  Section 2.4).

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

3.4.  Proxies

OLD
   In some cases, the traffic between Client and Resource Server might
   go through intermediary nodes (e.g. proxies, gateways).  This might
   affect the function or the security model of authentication and
   access control protocols e.g. end-to-end security between Client and
   Resource Server with DTLS might not be possible (see Section 2.5).
NEW
   In some cases, the traffic between endpoints might
   go through intermediary nodes (e.g. proxies, gateways).  This might
   affect the function or the security model of authentication and
   access control protocols e.g. end-to-end security between endpoints
   with DTLS might not be possible (see Section 2.5).

4.  Privacy Considerations

   Many of the devices that are in focus of this document register data
   from the physical world (sensors) or affect processes in the physical
   world (actuators), which may involve data or processes belonging to
   individuals.  To make matters worse the sensor data may be recorded
   continuously thus allowing to gather significant information about an
   individual subject through the sensor readings.  Therefore privacy
   protection is especially important, and Authentication and Access
   control are important tools for this, since they make it possible to
   control who gets access to private data.
OLD
   Privacy protection can also be weighted in when evaluating the need
   for end-to-end confidentiality, since otherwise intermediary nodes
   will learn the content of potentially sensitive messages sent between
   a client and a resource server and thereby endanger the privacy of
   the individual that may be subject of this data.
NEW
   Privacy protection can also be weighted in when evaluating the need
   for end-to-end confidentiality, since otherwise intermediary nodes
   will learn the content of potentially sensitive messages sent between
   endpoints and thereby endanger the privacy of
   the individual that may be subject of this data.

OLD
   In some cases, even the possession of a certain type of device can be
   confidential, e.g. principals might not want to others to know that
   they are wearing a certain medical device (see Section 2.3).
NEW
   In some cases, even the possession of a certain type of device can be
   confidential, e.g. individuals might not want to others to know that
   they are wearing a certain medical device (see Section 2.3).

OLD
   The personal health monitoring use case (see Section 2.3) indicates
   the need for secure audit logs which impose specific requirements on
   a solution.  Auditing is not in the scope of ACE.  However, if an
   authorization solution provides means for audit logs, it must
   consider the impact of logged data for the privacy of the principal
   and other parties involved.  Suitable measures for protecting and
   purging the logs must be taken during operation, maintenance and
   decommissioning of the device.
NEW
   The personal health monitoring use case (see Section 2.3) indicates
   the need for secure audit logs which impose specific requirements on
   a solution.  Auditing is not in the scope of ACE.  However, if an
   authorization solution provides means for audit logs, it must
   consider the impact of logged data for the privacy of all parties
involved.  
   Suitable measures for protecting and
   purging the logs must be taken during operation, maintenance and
   decommissioning of the device.

---

From: Stefanie Gerdes <[email-masked]>
Date: Mon, 09 Mar 2015 15:01:19 +0100

Hi Göran

> Well, no I didn't, I responded to a mail directly from you.

Oh I see, my mistake, sorry.

> don’t hide behind terminology.

Great, then we agree on this.

>> U1.12 The constrained devices might not always be able to reach the

Okay, I will change the draft accordingly.

>     considered by solution developers.

Maybe we can replace the first sentence with:
This document lists authorization problems that users of 
constrained-node networks want to solve.

"Security problem" was a bit too broad in the first place and the 
document focuses on owner/principal/user problems.

<snip>

>        the device that enforces the authorization and applied to every

Okay.

<snip>

>        Section 2.4, Section 2.5).

Okay.

<snip>

>        not be a feasible solution (see e.g.  Section 2.5).

Okay.

<snip>

>     with DTLS might not be possible (see Section 2.5).

Okay.

<snip>

>     the individual that may be subject of this data.

Okay.

>     they are wearing a certain medical device (see Section 2.3).

Okay.

>     decommissioning of the device.

Okay.

So if you agree to the change in the attack section I suggested above, I 
will update the draft accordingly.

Additionally, I will go through the sections and replace the term 
principal with terms such as "user" or "individual".

I assume that we remove the terms "resource", "resource server", 
"client", "resource owner", "client owner" and "principal" from the 
terminology section?

Best regards,
Steffi

---

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

Hi Steffi,

I’m fine with your suggestions. Please go ahead and make a proposal for
updated problem descriptions.

Best regards,
Göran

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

>>>> setting access control polices” (I haven’t polished on this
>>>>formulation
>>>> as