Hi Stefanie

Thanks for considering our input, below are some more detailed comments.
Sorry for iterating some things that has already been discussed on the list.


On 1/14/14 9:34 AM, "Stefanie Gerdes" <gerdes@tzi.de<mailto:gerdes@tzi.de>> wrote:

Hi everyone,

We updated the draft charter according to helpful input from Ludwig
Seitz and Göran Selander. I hope this improves the readability of the
charter and clarifies the scope of ACE.

We also added an item to the task list for documenting the applicability
of various security mechanisms to address for example symmetric vs
public key approaches.

Please feel free to provide further comment.

Best regards,
Steffi


Draft Charter V0.1- Authentication and Authorization for Constrained
Environment (ACE)

The CoAP (Constrained Application Protocol) is a light-weight
application layer protocol, especially suitable for applications such as
smart energy, smart home, building automation, remote patient monitoring
etc. Due to the nature of these applications, including a critical,
unattended infrastructure and usage in the personal sphere, security and
privacy protection are critical components.

There are certain, necessary security functions that constrained
devices cannot readily perform due to resource constraints. In
particular, constrained devices often have no or very limited user
interfaces.

I can't see that this property of constrained devices that you single out
(limited user interface) is specifically relevant to the work proposed for ACE.
How about instead mentioning properties like limited processing and power
capabilities or just refer to LWIG terminology?

While authentication is well understood, at least for
communication security,

I agree that CoRE has decided for DTLS, but as we know DTLS was not
designed for constrained environments and there are improvements to be
made, e.g. the ongoing work in DICE. There are also potential improvements
to the DTLS handshake. Considering this, I would say that authentication
is not yet "well understood".

there are only unsufficient means for
authenticated authorization.

"authenticated authorization" has been discussed on this list, but those
who did not follow that thread may interpret this concept in different
ways. I think it would be good to stick to the word "authorization" in the
charter. More below.

I propose to replace the previous sentence with something spelling out
what the problem is, like:

"The CoRE WG has selected DTLS as the preferred protocol for
authentication and communication security in constrained devices. For
authorization, however, it may be infeasible for a constrained device to
make authorization decisions and manage authorization policies."


Especially cases where pre-provisioned
ACLs scale badly or where more sophisticated identity and access
management is needed are not covered. This includes the case where it
is infeasible for a constrained server to perform the authorization
decision and thus needs access to externally generated authorization
information to be able to enforce the decision.

To harmonize with previous proposed text replace last sentence with:

"This includes the case where a constrained device enforces an
externally made authorization decision."


Authentication is
considered in this context as it is needed as a prerequisite to
performing authorization,

I guess this is intended as explanation of "authenticated authorization".

I have two comments (this is in part continuing the thread of
http://www.ietf.org/mail-archive/web/core/current/msg05132.html):

1. I agree that some sort of verification of access token is needed for
authorization, but do we exclude the case of (OAuth) Bearer Tokens? I.e. that
there is no information binding the entity making the request to the
access token besides being in possession of the token. In the case
of Bearer Tokens I'm not sure the term "authentication" is correct as
it is just a matter of verifying a digital signature or a MAC (RFC4949 "authenticate").

2. What I think this all boils down to is that the consumer of the
authorization decision is:
(a) verifying the integrity of the authorization information, and
(b) verifying that the source of the authorization information is allowed
by local policy ("trusted") to issue authorization decisions, and
(c) verifying that the subject of the authorization decision coincides with
the requesting entity.
If we accept Bearer Tokens then (c) is optional, else mandatory.

Maybe (some parts of) this what you refer to as "authenticated authorization"?
I don't think we need go into such details in the charter, just to see if we agree
on the lower level.

including the authorization to change the
authorization state.

This latter part is important, but IMHO is not specifically associated to the
discussion about the need for authentication. How about:

"The authorization solution needs to consider the ability to change
authorization state in an authorized way, including expiry or revocation
of authorization decisions."?


The ACE WG aims to enable authorized access to resources in constrained
environments, using CoAP and leveraging DTLS security where possible.
Constrained devices will thus be enabled to authenticate operations from

Replace "authenticate operations" with "authenticate requests for
operations"

other (constrained or less-constrained) devices, to communicate securely
with them and to verify their individual authorization to access
specific resources. To achieve this, ACE will be able to employ
additional less-constrained devices in order to relieve the constrained
nodes from complex security related tasks (e.g. managing authorization
policies and a large number of keys).

Proposal: remove "a large number of". The number of keys per constrained
device is not necessarily a problem, but it may benefit from support with
key management, e.g. derivation of session keys.


The ACE WG has the following tasks:

    Document the use cases and high-level requirements for secured
communication between constrained devices. (This task is pursued as a
means to the other ends, not as an end in itself.)

I think the second sentence can be left out. Use cases and requirements is
commonly understood as an initial activity to set the scope and
constraints for the work.

   Flesh out profiles for certificates used for authenticated
authorization.

If I understand this right, this is about the X.509 certificates used in
CoAP/DTLS for the certificate security mode. What about security modes
that do not make use of certificates (e.g. as in draft-seitz-security-modes)?
How about generalizing slightly to

"Optimize existing and design new security modes for CoAP, e.g. profiles
for X.509 certificates used in the CoAP/DTLS certificate security mode"


   Document the applicability of the various security mechanisms with
respect to resource usage (RAM, message round trips, power consumption
etc.).

I think this is valuable, I'm just reflecting of the scope of the current text.

Say that you can save one round trip by making a some symmetric crypto
operation on the constrained resource server. Now we need to decide if we
should make that trade off, i.e. introduce crypto to save on communication
needs and thus reduce power consumption. This is wider than just
"applicability of security mechanisms"?

Another naive example: say you have the option to have a security protocol
with either a few large messages or several small messages, what is
preferred?

How about formulating this as "design criteria for security protocol"  or
something similar instead of "applicability of security mechanisms"?
Maybe there is already a good reference to use as a starting point? LWIG?

   Define a mechanism for authenticated and protected transfer of
authorization information suitable for constrained device to constrained
device communication.

In a recent ACE thread, we discussed the option of either client or server
being non-constrained. How about replacing "constrained device to constrained
device communication" with "constrained environments"?

Best regards,
Göran



   Define formats for access tokens and for authorization information
that are suitable for constrained devices.
   Define bootstrapping for authorization information using the Resource
Directory (see ​
http://tools.ietf.org/html/draft-ietf-core-resource-directory).

Existing work:

Use Cases:

    ​http://tools.ietf.org/id/draft-garcia-core-security
    ​http://tools.ietf.org/id/draft-greevenbosch-core-authreq
    ​http://tools.ietf.org/id/draft-seitz-core-sec-usecases

Solutions:

    ​http://tools.ietf.org/id/draft-gerdes-core-dcaf-authorize
    ​http://tools.ietf.org/id/draft-kang-core-secure-reconfiguration
    ​http://tools.ietf.org/id/draft-selander-core-access-control
    ​http://tools.ietf.org/id/draft-zhu-core-groupauth
    ​http://tools.ietf.org/id/draft-pporamba-dtls-certkey
    ​http://tools.ietf.org/id/draft-schmitt-two-way-authentication-for-iot
    ​http://tools.ietf.org/id/draft-seitz-core-security-modes
    ​http://tools.ietf.org/html/draft-sarikaya-ace-secure-bootstrapping