Subject: [Ace] Updated ACE Charter V0.4

From: Likepeng <[email-masked]>
Date: Sun, 16 Feb 2014 18:55:18 +0000

Hello all,

I just updated ACE draft charter according to the recent discussions.

Link: http://trac.tools.ietf.org/wg/core/trac/wiki/ACE_charter

Here are the changes to the task list:

Change 1:
OLD: Define profiles for certificates used for authenticated authorization.
NEW: Define profiles for encoding authentication and authorization data.

Change 2:
OLD: 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.
NEW: Document design criteria for the required security protocols with respect to resource usage (RAM, message round trips, power consumption etc.).

Change 3:
OLD: Define a mechanism for authenticated and protected transfer of authorization information suitable for constrained device to constrained device communication.
NEW: Define a mechanism for authenticated and protected transfer of authorization information suitable for constrained environments, and taking into account expiry/revocation.

Change 4:
Add two new related drafts:
​http://tools.ietf.org/id/draft-porambage-core-ace-x509
​http://tools.ietf.org/id/draft-tschofenig-ace-overview

Please review it and feel free to provide comments/suggestions.

Thanks,
Kind Regards
Kepeng

Draft Charter V0.4 - 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? 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. 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. 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 encoding authentication and authorization data.

  *   Document design criteria for the required security protocols 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 environments, and taking into account expiry/revocation.

  *   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<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-garcia-core-security>
  *   ​http://tools.ietf.org/id/draft-greevenbosch-core-authreq<http://tools.ietf.org/id/draft-greevenbosch-core-authreq>
  *   ​http://tools.ietf.org/id/draft-seitz-core-sec-usecases<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-gerdes-core-dcaf-authorize>
  *   ​http://tools.ietf.org/id/draft-kang-core-secure-reconfiguration<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-selander-core-access-control>
  *   ​http://tools.ietf.org/id/draft-zhu-core-groupauth<http://tools.ietf.org/id/draft-zhu-core-groupauth>
  *   ​http://tools.ietf.org/id/draft-pporamba-dtls-certkey<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-schmitt-two-way-authentication-for-iot>
  *   ​http://tools.ietf.org/id/draft-seitz-core-security-modes<http://tools.ietf.org/id/draft-seitz-core-security-modes>
  *   ​http://tools.ietf.org/id/draft-sarikaya-ace-secure-bootstrapping<http://tools.ietf.org/id/draft-sarikaya-ace-secure-bootstrapping>
  *   ​http://tools.ietf.org/id/draft-bormann-core-ace-aif<http://tools.ietf.org/id/draft-bormann-core-ace-aif>
  *   ​http://tools.ietf.org/id/draft-porambage-core-ace-x509<http://tools.ietf.org/id/draft-porambage-core-ace-x509>
  *   ​http://tools.ietf.org/id/draft-tschofenig-ace-overview<http://tools.ietf.org/id/draft-tschofenig-ace-overview>

---

From: Ludwig Seitz <[email-masked]>
Date: Mon, 17 Feb 2014 09:05:29 +0100

> Hello all,
...

> Use Cases:
...
>   * ​http://tools.ietf.org/id/draft-seitz-core-sec-usecases
that should now be
http://tools.ietf.org/html/draft-seitz-ace-usecases

and this is neither use case nor solution, but definitely aimed at ACE:
http://tools.ietf.org/html/draft-seitz-ace-design-considerations-00

/Ludwig

-- 
Ludwig Seitz, PhD
SICS Swedish ICT AB
Ideon Science Park
Building Beta 2
Scheelevägen 17
SE-223 70 Lund

Phone +46(0)70-349 92 51
http://www.sics.se

---

From: Likepeng <[email-masked]>
Date: Mon, 17 Feb 2014 11:02:04 +0000

>that should now be: http://tools.ietf.org/html/draft-seitz-ace-usecases

OK, changed.

>http://tools.ietf.org/html/draft-seitz-ace-design-considerations-00

It seems to be related to solution design considerations. Let's put it in solution for now. 

Thanks,

Kind Regards
Kepeng

-----邮件原件-----
发件人: Ace [mailto:[email-masked]] 代表 Ludwig Seitz
发送时间: 2014年2月17日 9:05
收件人: [email-masked]
主题: Re: [Ace] Updated ACE Charter V0.4

...

...
that should now be

/Ludwig

-- 
Ludwig Seitz, PhD
SICS Swedish ICT AB
Ideon Science Park
Building Beta 2
Scheelevägen 17
SE-223 70 Lund

Phone +46(0)70-349 92 51
http://www.sics.se