[Ace] Draft ACE Charter V0.1

Likepeng <likepeng@huawei.com> Thu, 12 December 2013 03:49 UTC

Return-Path: <likepeng@huawei.com>
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 706561AE1CF for <ace@ietfa.amsl.com>; Wed, 11 Dec 2013 19:49:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level:
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham
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 V9zF-NzoxBRK for <ace@ietfa.amsl.com>; Wed, 11 Dec 2013 19:49:33 -0800 (PST)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id CCD1B1AE0EF for <ace@ietf.org>; Wed, 11 Dec 2013 19:49:32 -0800 (PST)
Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id AYX06933; Thu, 12 Dec 2013 03:49:26 +0000 (GMT)
Received: from LHREML406-HUB.china.huawei.com (10.201.5.243) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 12 Dec 2013 03:49:14 +0000
Received: from SZXEMA404-HUB.china.huawei.com (10.82.72.36) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 12 Dec 2013 03:49:25 +0000
Received: from SZXEMA501-MBS.china.huawei.com ([169.254.2.66]) by SZXEMA404-HUB.china.huawei.com ([10.82.72.36]) with mapi id 14.03.0158.001; Thu, 12 Dec 2013 11:49:19 +0800
From: Likepeng <likepeng@huawei.com>
To: "ace@ietf.org" <ace@ietf.org>
Thread-Topic: Draft ACE Charter V0.1
Thread-Index: Ac727SJkqYhxD//mT5GYmRIeXquOcw==
Date: Thu, 12 Dec 2013 03:49:19 +0000
Message-ID: <34966E97BE8AD64EAE9D3D6E4DEE36F252AD2DF8@SZXEMA501-MBS.china.huawei.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.66.167.122]
Content-Type: multipart/alternative; boundary="_000_34966E97BE8AD64EAE9D3D6E4DEE36F252AD2DF8SZXEMA501MBSchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Subject: [Ace] Draft ACE Charter V0.1
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: Thu, 12 Dec 2013 03:49:36 -0000

Hello all,

Thanks for your feedback, and they are very helpful.

We made a quick update for the charter (1), and hope it captures some of your comments.

I created a wiki page for the charter, so that people can log in the wiki page to improve it:

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

Feel free to provide your further comments/suggestions.

Thanks
Kind Regards
Kepeng & Stefanie


(1)    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.



Currently, a problem with constrained devices is the realization of such secure operation. Constrained devices are unable to include many sophisticated features, such as user interfaces and configuration files, but nevertheless need to perform authentication and authorization operations. While authentication is well understood, at least for communication security, there are only insufficient means for authorization. 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 focuses on providing constrained devices with the necessary prerequisites to use REST operations in a secure way such as authorization information and the related keying material. 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). ACE will use CoAP and employ security properties of DTLS whenever possible.



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 the certificates that already are part of CoAP's security architecture as well as possibly for any ACE-specific use of certificates.

- Define a mechanism for authenticated and protected transfer of authorization information suitable for constrained device to constrained device communication.

- Define an access token and authorization information format suitable for constrained devices.

- Define bootstrapping for authorization information using the Resource Directory (see http://tools.ietf.org/html/draft-ietf-core-resource-directory).