[Ace] Charter Update

Stefanie Gerdes <gerdes@tzi.de> Tue, 14 January 2014 08:35 UTC

Return-Path: <gerdes@tzi.de>
X-Original-To: ace@ietfa.amsl.com
Delivered-To: ace@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B3CD1ACCE9 for <ace@ietfa.amsl.com>; Tue, 14 Jan 2014 00:35:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.551
X-Spam-Level:
X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, SPF_HELO_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D06eqKoH60A3 for <ace@ietfa.amsl.com>; Tue, 14 Jan 2014 00:35:18 -0800 (PST)
Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id C9FFB1AE222 for <ace@ietf.org>; Tue, 14 Jan 2014 00:35:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de
Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id s0E8Yu6M000901; Tue, 14 Jan 2014 09:34:56 +0100 (CET)
Received: from [192.168.1.146] (p508A76DE.dip0.t-ipconnect.de [80.138.118.222]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id B7525550; Tue, 14 Jan 2014 09:34:56 +0100 (CET)
Message-ID: <52D4F6AD.3060101@tzi.de>
Date: Tue, 14 Jan 2014 09:34:53 +0100
From: Stefanie Gerdes <gerdes@tzi.de>
User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0.1
MIME-Version: 1.0
To: ace@ietf.org
X-Enigmail-Version: 1.6
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
Cc: Bert Greevenbosch <Bert.Greevenbosch@huawei.com>, Göran Selander <goran.selander@ericsson.com>, Ludwig Seitz <ludwig@sics.se>, Likepeng <likepeng@huawei.com>
Subject: [Ace] Charter Update
X-BeenThere: ace@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" <ace.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ace>, <mailto:ace-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ace/>
List-Post: <mailto:ace@ietf.org>
List-Help: <mailto:ace-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ace>, <mailto:ace-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 14 Jan 2014 08:35:20 -0000

Hi everyone,

We updated the draft charter according to helpful input from Ludwig
Seitz and Göran Selander. I hope this improves the readability of the
charter and clarifies the scope of ACE.

We also added an item to the task list for documenting the applicability
of various security mechanisms to address for example symmetric vs
public key approaches.

Please feel free to provide further comment.

Best regards,
Steffi


Draft Charter V0.1- Authentication and Authorization for Constrained
Environment (ACE)

The CoAP (Constrained Application Protocol) is a light-weight
application layer protocol, especially suitable for applications such as
smart energy, smart home, building automation, remote patient monitoring
etc. Due to the nature of these applications, including a critical,
unattended infrastructure and usage in the personal sphere, security and
privacy protection are critical components.

There are certain, necessary security functions that constrained
devices cannot readily perform due to resource constraints. In
particular, constrained devices often have no or very limited user
interfaces. While authentication is well understood, at least for
communication security, there are only unsufficient means for
authenticated authorization. Especially cases where pre-provisioned
ACLs scale badly or where more sophisticated identity and access
management is needed are not covered. This includes the case where it
is infeasible for a constrained server to perform the authorization
decision and thus needs access to externally generated authorization
information to be able to enforce the decision. Authentication is
considered in this context as it is needed as a prerequisite to
performing authorization, including the authorization to change the
authorization state.

The ACE WG aims 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 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).

The ACE WG has the following tasks:

    Document the use cases and high-level requirements for secured
communication between constrained devices. (This task is pursued as a
means to the other ends, not as an end in itself.)
   Flesh out profiles for certificates used for authenticated authorization.
   Document the applicability of the various security mechanisms 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 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).

Existing work:

Use Cases:

    ​http://tools.ietf.org/id/draft-garcia-core-security
    ​http://tools.ietf.org/id/draft-greevenbosch-core-authreq
    ​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-kang-core-secure-reconfiguration
    ​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-pporamba-dtls-certkey
    ​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/html/draft-sarikaya-ace-secure-bootstrapping