Subject: [Ace] Comments to the ACE use case document

From: "Kepeng Li" <[email-masked]>
Date: Wed, 01 Jul 2015 18:45:51 +0800

Hello all,

Please find my review comments to the use case document:
http://www.ietf.org/id/draft-ietf-ace-usecases-04.txt

1) 2.2.1 Add full spelling for HVAC, that is: (Heating, Ventilation and Air
Conditioning).

2) U3.4 Devices are often used with default access control settings.
It is not clear what is the authorization problem. Is it desired to have
default settings or do we want to change the settings? If it is desired, we
should change the sentence to:
The wearer of an eHealth device wants his device to have default access
control settings.

3) U3.6 Security mechanisms themselves could provide opportunities for
denial of service attacks on the device.
Denail of service attack can also happen to Authorization Server. My
suggestion is to remove "on the device“, or add "and Authorization Server“.

4) U1.9 Messages between client and resource server might need to be
forwarded over multiple hops.
   U5.8 Messages between endpoints may need to be stored and forwarded over
multiple nodes.
It is not clear what is the authorization problem with these two. The
sentence sounds like a condition. My suggestion is to change it to something
like: messages between endpoints need to be protected for intergrity and
confidentially when they are stored or forwarded over multiple nodes.

5)  U1.10 The constrained devices might not always be able to reach the
Internet.
    U5.5 The devices may have intermittent Internet connectivity.
    U7.3 Some devices do not have direct Internet connection.
    U7.4 Some devices have wired connection while others use wireless.
About these four, it is not clear about the authorization problem. It is a
condition. My suggestion is to change it to something like: Some devices do
not have direct Internet connection, and can’t get authorization decision in
real time.

6)  3.2 Configuration of Access Permission
It is important to protect the authorization decisions not to be reused,
stolen or intercepted.
I suggest adding one bullet as a security consideration: The device should
prove its possission of policy decisions when it presents them to
Authorization Server.

7) 3.3.  Design Considerations for Authorization Solutions
I am not sure why this part belongs to Security Considerations. Should it be
a separate section?

Thanks,
Kind Regards
Kepeng Li (Individual)

---

From: Stefanie Gerdes <[email-masked]>
Date: Wed, 01 Jul 2015 15:15:14 +0200

Hi Kepeng,

Thank you for your review. Some comments inline.

> The wearer of an eHealth device wants his device to have default access

U3.4 refers to the problem that users often don't change the default
settings. A solution designer needs to keep this in mind. We might
change this to "Devices are often used with default access control
settings which might threaten the security objectives of the device's
users." or something like that.

> suggestion is to remove "on the device“, or add "and Authorization Server“.

How about: "Security mechanisms themselves could provide opportunities
for denial of service attacks, especially on the constrained devices."

> confidentially when they are stored or forwarded over multiple nodes.

This is a bit difficult to change. The use cases draft aims at listing
problems, not requirements. And we don't know if the principals always
need integrity AND confidentiality. The best I can think of is: "Users
want their security objectives to be achieved even if the messages
between endpoints are forwarded over multiple hops."

> not have direct Internet connection, and can’t get authorization decision in

But the devices might be able to get authorization decisions, just not
from a server somewhere in the Internet. They may have a local
Authorization Server or may even ask their users if they are available.

> prove its possission of policy decisions when it presents them to

I don't really understand this comment. Can you elaborate that?

> I am not sure why this part belongs to Security Considerations. Should it be

Section 3.3. derives from the problem summary sections which problems
solution designers should consider. Doesn't that fit into a security
considerations section? Do you think that the contents don't fit or is
the heading a misnomer?

Thanks
Steffi

---

From: "Kepeng Li" <[email-masked]>
Date: Wed, 01 Jul 2015 22:46:45 +0800

Hi Steffi,

Thanks for the feedback.

Please find my comments inline.

And I add another new comment:

Section 2.2, in case of renting a house, we should consider a new
authorziation problem below:

U2.X The home owners want to grant access permissions to a party in a
specified timeframe.

We have U2.4 which talks about granting temporary access permissions, but
to me, temporary usually means one-time permission, it is different from
one year permission.

Kind Regards
Kepeng

>users." or something like that.

OK.

>for denial of service attacks, especially on the constrained devices."

OK.

>between endpoints are forwarded over multiple hops."

In fact, we already have several sentences about intergrity and
confidentiality, e.g. U1.2, U1.3, U1.4, U1.6.

But the new wording is fine with me.

>Authorization Server or may even ask their users if they are available.

Maybe we need a better wording. My point is, we should make it clear, what
is the authorization problem if the device does not have internet
connection.

Something like: The devices need to be authorized even if the devices do
not have direct Internet connection.

>I don't really understand this comment. Can you elaborate that?

For example, I got the room key (authorization decision) from the hotel.
But it is lost and picked up by Guest A. Guest A got my room key and
entered my room.

We should aviod this situation to happen. So I propose the add one
security consideration bullet above.

>From the content, it talks about how to enforce and update ploicies, how
to revoke decisions, usabilities, etc. It does not really fit into a
security consideration.

It seems to me design considerations and security considerations should be
in parallel sections.

---

From: Stefanie Gerdes <[email-masked]>
Date: Wed, 01 Jul 2015 17:39:54 +0200

Hi Kepeng,

Thank you for your comments.

> to me, temporary usually means one-time permission, it is different from

I would think that temporary can also mean a one year permission, but I
guess we can just change U2.4 to "The home owners want to grant access
permissions to a party in a specified timeframe."

> not have direct Internet connection.

But the problem at this point is that they don't always have the
Internet connection. How about: "The constrained devices might not
always be able to reach the Internet but still need to enact the
authorization policies of their principals."?

> security consideration bullet above.

I agree that we should avoid this to happen, but it seems to me that
this is a very specific implementation detail. There will be a lot of
requirements that solutions must meet, but the use cases document is not
about requirements. The items listed in 3.2, 3.3 and 3.4 derive from the
problem summary sections and just summarize them.

> It seems to me design considerations and security considerations should be

As I said above, the sections 3.2 and 3.3 and 3.4 are just summarizing
the problem summary sections. To make this a bit more understandable, we
divided the summary into three sections. It will be very difficult to
keep the focus of the draft (the listing of authorization problems) if
we have a distinct design consideration section.

Best regards,
Steffi

---

From: "Kepeng Li" <[email-masked]>
Date: Thu, 02 Jul 2015 07:28:17 +0800

Hi Steffi,

Thanks for your feedback.

My comments are inline.

Another editorial one: "want“ is missing in the sentence below.

U6.4 Sports equipment owners to protect the confidentiality of
      their data for privacy reasons.

Kind Regards
Kepeng

>permissions to a party in a specified timeframe."

OK. Fine with me.

>authorization policies of their principals."?

OK, fine with me.

>problem summary sections and just summarize them.

Let me find an alternative proposal.

>we have a distinct design consideration section.

How about this, change the title to "Authorization Considerations“? Then
it sounds more like a security consideration.