Gesendet: Dienstag, 14. Januar 2014 um 08:34 Uhr
Von: "Stefanie Gerdes" <gerdes@tzi.de>
An: ace@ietf.org
Cc: "Bert Greevenbosch" <Bert.Greevenbosch@huawei.com>, "Göran Selander" <goran.selander@ericsson.com>, "Ludwig Seitz" <ludwig@sics.se>, Likepeng <likepeng@huawei.com>
Betreff: [Ace] Charter Update

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. While authentication is well understood, at least for
communication security, there are only unsufficient means for
authenticated authorization. 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. Authentication is
considered in this context as it is needed as a prerequisite to
performing authorization, including the authorization to change the
authorization state.

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

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.)
Flesh out profiles for certificates used for authenticated authorization.
Document the applicability of the various security mechanisms with
respect to resource usage (RAM, message round trips, power consumption
etc.).
Define a mechanism for authenticated and protected transfer of
authorization information suitable for constrained device to constrained
device communication.
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" target="_blank" rel="nofollow">http://tools.ietf.org/html/draft-ietf-core-resource-directory).

Existing work:

Use Cases:

​http://tools.ietf.org/id/draft-garcia-core-security" target="_blank" rel="nofollow">http://tools.ietf.org/id/draft-garcia-core-security
​http://tools.ietf.org/id/draft-greevenbosch-core-authreq" target="_blank" rel="nofollow">http://tools.ietf.org/id/draft-greevenbosch-core-authreq
​http://tools.ietf.org/id/draft-seitz-core-sec-usecases" target="_blank" rel="nofollow">http://tools.ietf.org/id/draft-seitz-core-sec-usecases

Solutions:

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

_______________________________________________
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace" target="_blank" rel="nofollow">https://www.ietf.org/mailman/listinfo/ace