Subject: Re: [Ace] ACE Rechartering

From: "Kepeng Li" <[email-masked]>
Date: Wed, 30 Sep 2015 20:58:45 +0800

Updated version：

Charter for Working Group

RFC 7228 has defined terminology for Internet of Things environments
and describes different classes of constraints nodes and networks have.
The limitations may be in terms of power, memory, and processing
resources. 
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
requirements pose challenges for the use of various security
protocols. For example, 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, HTTP/2,
and TLS will be investigated. The ability to distribute keys for use
with secure group communication including multicast security and
application layer security solutions. 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 various other IETF
working groups, such as CORE, LWIG, and 6LO, 6TISCH, and ANIMA, to
avoid overlap.

The working group has the following tasks:

1) Produce use cases

2) Define an architecture

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

Kind Regards
Hannes & Kepeng

在 25/8/15 10:15 pm， "Hannes Tschofenig" <[email-masked]> 写入:

>That's good for me.
>
>
>On 08/25/2015 04:00 PM, Somaraju Abhinav wrote:
>> Hi Hannes,
>> Just one quick point which was raised by somebody (don’t remember who)
>>at Prague. From my memory it was agreed at the meeting that we want to
>>talk about security for group communication and not just multicast
>>security. So does it makes sense to change the statement
>> "The ability to distribute keys for use with multicast security will
>>also be explored as well as application layer security solutions"
>> to
>> "The ability to distribute keys for use with secure group communication
>>including multicast security and application layer security solutions"
>> Abhinav
>> 
>> -----Original Message-----
>> From: Ace [mailto:[email-masked]] On Behalf Of Hannes Tschofenig
>> Sent: Dienstag, 25. August 2015 13:18
>> To: [email-masked]
>> Subject: [Ace] ACE Rechartering
>> 
>> Hi all,
>> 
>> at the last IETF meeting we discussed the inclusion of the architecture
>>document into the charter (and into the milestone list) of the ACE
>>working group. The participants of f2f meeting agreed to the adoption of
>>the document and the subsequent confirmation call on the mailing list
>>did not lead to a different conclusion.
>> 
>> Since the architecture document was not part of our charter we have to
>>update the charter text. You can find three files in the attachment,
>>namely
>>  1) the current charter text,
>>  2) the new charter text, and
>>  3) a diff version (as PDF).
>> 
>> The changes to the current charter text are as follows:
>> 
>>  * editorial changes,
>>  * added the architecture document,
>>  * added a note about multicast, and
>>  * included a remark about application layer security.
>> 
>> Are you OK with the updated charter text?
>> If not, what other changes you would like to see?
>> 
>> Deadline for feedback: September 6th 2015
>> 
>> Ciao
>> Hannes & Kepeng
>> ________________________________________________________ The contents
>>of this e-mail and any attachments are confidential to the intended
>>recipient. They may not be disclosed to or used by or copied in any way
>>by anyone other than the intended recipient. If this e-mail is received
>>in error, please immediately notify the sender and delete the e-mail and
>>attached documents. Please note that neither the sender nor the sender's
>>company accept any responsibility for viruses and it is your
>>responsibility to scan or otherwise check this e-mail and any
>>attachments.
>> 
>
>_______________________________________________
>Ace mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/ace