Authentication and Authorization for Constrained Environments
charter-ietf-ace-01

WG review announcement

From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Cc: ace WG <ace@ietf.org> 
Subject: WG Review: Authentication and Authorization for Constrained Environments (ace)

A new IETF working group has been proposed in the Security Area. The IESG
has not made any determination yet. The following draft charter was
submitted, and is provided for informational purposes only. Please send
your comments to the IESG mailing list (iesg at ietf.org) by 2014-06-14.

Authentication and Authorization for Constrained Environments (ace)
------------------------------------------------
Current Status: Proposed WG

Chairs:
  Hannes Tschofenig <Hannes.Tschofenig@gmx.net>
  Kepeng Li <likepeng@huawei.com>

Assigned Area Director:
  Kathleen Moriarty <Kathleen.Moriarty.ietf@gmail.com>

Mailing list
  Address: ace@ietf.org
  To Subscribe: https://www.ietf.org/mailman/listinfo/ace
  Archive: http://www.ietf.org/mail-archive/web/ace/current/maillist.html

Charter:

Authentication and Authorization for Constrained
Environment (ACE)

The IETF has recently developed protocols for use in constrained
environments, where network nodes are limited in CPU, memory and power.  
REST architecture is widely used for such constrained environments.
It has been observed that Internet protocols can be applied to these
constrained environments, often only requiring minor tweaking and
profiling. In other cases, new protocols have been defined to address
the specific requirements of constrained environments. An example of
such a protocol is the Constrained Application Protocol (CoAP).

As in other environments, authentication and authorization questions
also arise in constrained environments. For example, a door lock has to
authorize the person seeking access using a "digital key". Where is the
authorization policy 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 temporarily granted to
other persons? How can access be revoked? These types of questions have
been answered by existing protocols for use cases outside constrained
environments, however in constrained environments, additional and
different requirements pose challenges for the use of various security
protocols. In particular, the need arises for a dynamic and fine grained
access control mechanism, where clients and/or resource servers are
constrained.

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 a similar
goal, at an abstract level, they offer quite different functions and
utilize different message exchanges. These differences result from the
main deployment use cases they were designed for respectively.

Requirements derived from use cases may indicate that existing work is
useful as basis for a solution for constrained environments. These
protocols, however, were not optimized for constrained environments. 
Additional requirements that need to be taken into account are the lack 
of a suitable user-interface and the inability of embedded devices to 
contact an authorization server in real-time with every resource access 
request due to intermittent connectivity, etc.

This working group therefore aims to produce a standardized solution for
authentication and authorization to enable authorized access (Get, Put,
Post, Delete) to resources identified by a URI and hosted on a resource
server in constrained environments. As a starting point, the working
group will assume that access to resources at a resource server by a
client device takes place using CoAP and is protected by DTLS. Both
resource server and client may be constrained. This access will be
mediated by an authorization server, which is not considered to be
constrained.

Existing authentication and authorization protocols will be evaluated 
and used where applicable to build the constrained-environment solution. 
This requires relevant specifications to be reviewed for suitability,
selecting a subset of them and restricting the options within each of 
the specifications. Some functionality, however, may not be available in
existing protocols, in which case the solution may also involve new
protocol work. Leveraging existing work means the working 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 constrained devices that provide increased security.

Once progress in identifying suitable candidate solutions has been made,
the working group will verify whether the same mechanisms are also
applicable beyond the use of CoAP and DTLS, which are the two main
protocols the group will focus on for access to resources. In
particular, the ability to use the developed solution over HTTP and TLS
will be investigated. Note that the initial focus is on CoAP and HTTP
with DTLS and TLS. Other security protocols may be considered as long as 
the primary focus is maintained. The group is scoped to work only on the 
web protocols and data carried within them. Furthermore, to guarantee 
smooth transition, the integration with existing deployments will be 
studied, particularly concerning the use of protocol translation 
proxies.

This work does not make the assumption that the party offering
application layer services is always the same party offering network
access services.

The working group has the following tasks:

1) Produce use cases and requirements

2) Identify authentication and authorization mechanisms suitable for
resource access in constrained environments.

Milestones:

Jul 2014 Submit "Use cases and Requirements" as a WG item.
Dec 2014 Submit "Authentication and Authorization Solution" as a WG 
         item.
Apr 2015 Optionally, submit "Use cases and Requirements" document to the
         IESG for publication as an Informational RFC.
Jul 2016 Submit "Authentication and Authorization Solution"
         specification to the IESG for publication as a Proposed 
         Standard.

WG action announcement

From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Cc: ace WG <ace@ietf.org> 
Subject: WG Action: Formed Authentication and Authorization for Constrained Environments (ace)

A new IETF working group has been formed in the Security Area. For
additional information please contact the Area Directors or the WG
Chairs.

Authentication and Authorization for Constrained Environments (ace)
------------------------------------------------
Current Status: Proposed WG

Chairs:
  Hannes Tschofenig <Hannes.Tschofenig@gmx.net>
  Kepeng Li <likepeng@huawei.com>

Assigned Area Director:
  Kathleen Moriarty <Kathleen.Moriarty.ietf@gmail.com>

Mailing list
  Address: ace@ietf.org
  To Subscribe: https://www.ietf.org/mailman/listinfo/ace
  Archive: http://www.ietf.org/mail-archive/web/ace/current/maillist.html

Charter:

The IETF has recently developed protocols for use in constrained
environments, where network nodes are limited in CPU, memory and power.  
REST architecture is widely used for such constrained environments.
It has been observed that Internet protocols can be applied to these
constrained environments, often only requiring minor tweaking and
profiling. In other cases, new protocols have been defined to address
the specific requirements of constrained environments. An example of
such a protocol is the Constrained Application Protocol (CoAP).

As in other environments, authentication and authorization questions
also arise in constrained environments. For example, a door lock has to
authorize the person seeking access using a "digital key". Where is the
authorization policy 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 temporarily granted to
other persons? How can access be revoked? These types of questions have
been answered by existing protocols for use cases outside constrained
environments, however in constrained environments, additional and
different requirements pose challenges for the use of various security
protocols. In particular, the need arises for a dynamic and fine grained
access control mechanism, where clients and/or resource servers are
constrained.

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 a similar
goal, at an abstract level, they offer quite different functions and
utilize different message exchanges. These differences result from the
main deployment use cases they were designed for respectively.

Requirements derived from use cases may indicate that existing work is
useful as basis for a solution for constrained environments. These 
protocols, however, were not optimized for constrained environments. 
Additional requirements that need to be taken into account are the lack 
of a suitable user-interface and the inability of embedded devices to 
contact an authorization server in real-time with every resource access 
request due to intermittent connectivity, etc.

This working group therefore aims to produce a standardized solution for
authentication and authorization to enable authorized access (Get, Put,
Post, Delete) to resources identified by a URI and hosted on a resource
server in constrained environments. As a starting point, the working
group will assume that access to resources at a resource server by a
client device takes place using CoAP and is protected by DTLS. Both
resource server and client may be constrained. This access will be
mediated by an authorization server, which is not considered to be
constrained.

Existing authentication and authorization protocols will be evaluated 
and used where applicable to build the constrained-environment solution. 
This requires relevant specifications to be reviewed for suitability, 
selecting a subset of them and restricting the options within each of 
the specifications. Some functionality, however, may not be available in
existing protocols, in which case the solution may also involve new
protocol work. Leveraging existing work means the working 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 constrained devices that provide increased security.

Once progress in identifying suitable candidate solutions has been made,
the working group will verify whether the same mechanisms are also
applicable beyond the use of CoAP and DTLS, which are the two main
protocols the group will focus on for access to resources. In 
particular, the ability to use the developed solution over HTTP and TLS
will be investigated. Note that the initial focus is on CoAP and HTTP 
with DTLS and TLS. Other security protocols may be considered as long as 
the primary focus is maintained. The group is scoped to work only on the 
web protocols and data carried within them. Furthermore, to guarantee 
smooth transition, the integration with existing deployments will be 
studied, particularly concerning the use of protocol translation 
proxies.

This work does not make the assumption that the party offering
application layer services is always the same party offering network
access services.  ACE will need to interact with CORE and LWIG to
ensure coordination.

The working group has the following tasks:

1) Produce use cases and requirements

2) Identify authentication and authorization mechanisms suitable for
resource access in constrained environments.

Milestones:
  Jul 2014 - Submit "Use cases and Requirements" as a WG item.
  Dec 2014 - Submit "Authentication and Authorization Solution" as a WG
item.
  Apr 2015 - Optionally, submit "Use cases and Requirements" document to
the IESG for publication as an Informational RFC.
  Jul 2015 - Submit "Authentication and Authorization Solution"
specification to the IESG for publication as a Proposed Standard.


Ballot announcement