Re: [Ace] New Version of Proposed Charter

[Likepeng <[e-mail]>]

> I think the issues around authorisation lifetime or revocation deserves should also be listed in the tasks below

Currently we have this task in the list:
•Define a mechanism for authenticated and protected transfer of authorization information suitable for constrained device to constrained device communication.

Do you have any proposal to merge the lifetime/revocation into the sentence above? 

Or have another general task? If we have a separate bullet just for lifetime/revocation, that may be too emphasized.

Thanks,

Kind Regards
Kepeng

> -----邮件原件-----
> 发件人: Ace [mailto:[e-mail]] 代表 G?ran Selander
> 发送时间: 2014年1月23日 19:23
> 收件人: [e-mail]
> 主题: Re: [Ace] New Version of Proposed Charter
> 
> 
> 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
> 
> _______________________________________________
> Ace mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ace