Re: [Ace] New Version of Proposed Charter

[Göran Selander <[e-mail]>]

I think the charter in its current version is setting the stage very well
and provides a good motivation for the work needed. Some further comments
inline. Some comments are partially answered by Kepeng in a recent email.


(Thanks for considering some of my previous comments!)


On 20/01/14 16:49, "Stefanie Gerdes" <[e-mail]> wrote:

>Hi everybody,
>
>Due to several complaints about the readability of the proposed charter,
>we revised it and, with the assistance of Hannes, came up with a new
>proposal which provides some more motivation and background to our work.
>
>We hope that this version includes the relevant topics and reflects the
>previous discussion. Please let us know if something relevant is missing.
>
>In six weeks, at the IETF meeting, we should be able to present a
>readable charter that has wide consensus in the IETF. So this is a good
>time to check that we agree about the charter within the ACE community.
>
>Best regards,
>Kepeng and Steffi
>
>Draft Charter V0.3 - Authentication and Authorization for Constrained
>Environment (ACE)
>
>New developments in the IETF include protocols with a specific focus on
>energy-efficiency to be used e.g. in environments where network nodes
>are limited in CPU, memory, and power-resources. It was observed that
>Internet protocols can be applied to these constrained environments,
>often only requiring minor tweaking and profiling. In other cases, new
>protocols such as the Constrained Application Protocol (CoAP) have been
>defined to address the specific requirements of constrained devices and
>networks.
>
>Constrained devices raise authentication and authorization questions.
>For example, a door lock has to authorize the person seeking access
>using a digital key. Where are the authorization decisions stored? How
>does the digital key communicate with the lock? Does the lock interact
>with an authorization server to obtain authorization information? How
>can access be granted to other persons temporarily? How can access be
>revoked? 

1. Yes this is good, and I think the issues around authorisation lifetime
or revocation deserves should also be listed in the tasks below

>These types of questions have been answered by existing
>protocols for use cases outside the constrained environment. But in
>constrained environment, constrained devices cannot readily handle these
>issues due to resource constraints.

2. The weighing of different resource constraints against each other is
a task for this work, see 3. below.

>CoAP provides a DTLS binding for
>authentication but does not address authorization.
>
> The IETF has a long history in developing three party authentication
>and authorization protocols for distributed environments. Examples
>include Kerberos, the Public Key Infrastructure (PKI), the
>Authentication, Authorization, and Accounting (AAA) infrastructure, and
>the Web Authorization Protocol (OAuth). All these protocols enjoy
>widespread deployment on the Internet. Although they all aim to solve
>the same goal they offer quite different functions and utilize different
>message exchanges. These differences are motivated by the main
>deployment use cases they were designed for.
>
>Requirements derived from use cases indicate the suitability of already
>existing work, such as OAuth, as a solution for constrained
>environments. These protocols were, however, not optimized for
>constrained environments. Additional requirements that need to be taken
>into account are the lack of a suitable user-interface for obtaining the
>consent of the user and the inability of embedded devices to contact an
>identity management/authorization server in real-time with every access
>request.
>
>This working group therefore aims for a standardized solution for
>authentication and authorization 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 requests for 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).
>
>Existing authentication and authorization protocols are used and
>re-applied for use with constrained devices, where applicable. This
>requires relevant specifications to be reviewed for suitability,
>selecting a subset of them, restricting the options within each of the
>specifications. Some functionalities  may, however, not be available in
>existing protocols and for those cases new functionality has to be
>standardized. Thus, existing work can be leveraged and the group
>benefits from available security analysis, implementation, and
>deployment experience.

3. Here I¹m missing the step that we need to agree on and specify design
constraints when profiling existing protocols or designing new. There are
trade-offs to make e.g. in terms of either doing crypto on a constrained
device or instead communicating with supporting less-constrained device.

>Moreover, a standardized solution for federated
>authentication and authorization will help to stimulate the deployment
>of IoT devices offering increased security.
>
>To be successful this working group requires expertise in security,
>privacy, and a good understanding of usability in the constrained
>environment space. This work does not make the assumption that the party
>offering application layer services is always the same party offering
>network access services.
>
>The ACE WG has the following tasks:
>
> Document the use cases and high-level requirements for secured
>communication between constrained devices.
>
> Define profiles for certificates used for authenticated authorization.


4. This has been discussed before, e.g.
http://www.ietf.org/mail-archive/web/ace/current/msg00104.html

- The term ³authenticated authorization² is not defined or referenced.

- It sounds like it excludes things like Bearer Tokens (which may be OK,
but that has not been discussed at all).

- I¹m fine with including this particular optimisation of DTLS handshake,
but would like to get acknowledged that other work on optimisations of
DTLS handshake in this context is also in scope, such as trusted third
party assisted key management (e.g. draft-seitz-core-security-modes). Any
work in this space is of course is conditional on what design constraints
are relevant for this work.


>
> Document the applicability of the main authentication and key exchange
>protocols with respect to resource usage (RAM, message round trips,
>power consumption etc.) and their suitability for the use cases.

5. Referring to 3. above, it is in this context I see the need to specify
design constraints, to be able to make a comparison and to decide what to
standardise.


Göran

>
> 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).
>
>_______________________________________________
>Ace mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/ace