[Ace] Fw: [core] Invitation to New Non-WG Mailing List: Authentication and Authorization for Constrained Environments (ace)

Likepeng <likepeng@huawei.com> Thu, 12 December 2013 05:43 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 D3D1E1AE00F for <ace@ietfa.amsl.com>; Wed, 11 Dec 2013 21:43:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.413
X-Spam-Level:
X-Spam-Status: No, score=-3.413 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CN_BODY_35=0.339, GB_I_INVITATION=-2, MIME_CHARSET_FARAWAY=2.45, 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 1kbRZCOsp50V for <ace@ietfa.amsl.com>; Wed, 11 Dec 2013 21:43:00 -0800 (PST)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 419241A802D for <ace@ietf.org>; Wed, 11 Dec 2013 21:43:00 -0800 (PST)
Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BBH19038; Thu, 12 Dec 2013 05:42:53 +0000 (GMT)
Received: from LHREML405-HUB.china.huawei.com (10.201.5.242) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 12 Dec 2013 05:42:40 +0000
Received: from SZXEMA401-HUB.china.huawei.com (10.82.72.33) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 12 Dec 2013 05:42:52 +0000
Received: from SZXEMA501-MBS.china.huawei.com ([169.254.2.66]) by SZXEMA401-HUB.china.huawei.com ([10.82.72.33]) with mapi id 14.03.0158.001; Thu, 12 Dec 2013 13:42:47 +0800
From: Likepeng <likepeng@huawei.com>
To: "ace@ietf.org" <ace@ietf.org>
Thread-Topic: [core] Invitation to New Non-WG Mailing List: Authentication and Authorization for Constrained Environments (ace)
Thread-Index: AQHO9n+6aRw4+VlebU6uU8o/686UippQDGeQ
Date: Thu, 12 Dec 2013 05:42:47 +0000
Message-ID: <34966E97BE8AD64EAE9D3D6E4DEE36F252AD2E6E@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: text/plain; charset="gb2312"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Cc: Rene Struik <rstruik.ext@gmail.com>
Subject: [Ace] Fw: [core] Invitation to New Non-WG Mailing List: Authentication and Authorization for Constrained Environments (ace)
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 05:43:04 -0000

I forward this email to ace mailing list.

It will be better to discuss it in ace.

@Rene, please join ace mailing list.

Thanks,
Kind Regards
Kepeng

-----邮件原件-----
发件人: core [mailto:core-bounces@ietf.org] 代表 Rene Struik
发送时间: 2013年12月11日 22:45
收件人: Stefanie Gerdes; core@ietf.org
抄送: saag@ietf.org; dtls-iot@ietf.org; jose@ietf.org; oauth@ietf.org
主题: Re: [core] Invitation to New Non-WG Mailing List: Authentication and Authorization for Constrained Environments (ace)

[apologies for replying to all the IETF lists in the original cc]

Dear colleagues:

I have some initial feedback on the potential draft charter.

I believe it is really premature to write potential point solutions into a draft charter, in casu definition of a less constrained device that can be used to outsource computational, storage, or management functionality to. (Does this imply one envisions to have to buy a separate box/single point of failure to take on this task?) It would make much more sense to look into this problem space in terms of requirements first, with an eye towards scalability towards billion+ devices. This does not preclude this potential solution direction, but questions as to what this entails in terms of usability, scalability, and communications impact need to be clear first. This is an ambitious undertaking and many efforts in the past have been far less successful than initially thought. There is also an undercurrent in the draft charter text that there is a need for different "device types", which is not a priori clear. To realize the full potential of constrained networks, one should refle!
ct upon "
 trust" endowed upon single nodes, of whatever type, and consider limiting the impact of violation of this trust, should this occur, as an explicit design criterium.

In the end, this may be an undertaking that would be suitable as an IAB work item, considering potential scope.

Best regards, Rene

==

To achieve this, ACE will be able to employ an architecture with one or more trusted less-constrained devices which will 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.




On 12/11/2013 8:46 AM, Stefanie Gerdes wrote:
> Hi everybody,
>
> As a result of discussions in the CoRE WG in Berlin and Vancouver the 
> new non-WG mailing list Authentication and Authorization for 
> Constrained Environments (ace) was created.
>
> The purpose of this list is to organize interest in a group to define 
> the charter for work on Authentication and Authorization for 
> Constrained Environments.
>
> Our mailing list can be found at (1), existing work can be found at 
> (2), and the draft charter can be found at (3).
>
> Please feel welcome to join the list and provide your feedback!
>
> Thanks,
>
> Kind Regards
> Kepeng & Stefanie
>
>
> (1)Mailing List
>
> https://www.ietf.org/mailman/listinfo/ace
>
> (2)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
>
> (3)Draft Charter - 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 communication. The devices only have limited resources 
> such as memory, storage and transmission capacity. These constraints 
> severely limit the security functions and communications the device can perform.
> Missing functionality includes authentication, which provides trust 
> and ensures an entity is who it says it is, and authorization, which 
> defines and enforces access rights for different clients.
>
> The ACE WG focuses on providing constrained devices with the necessary 
> prerequisites to use REST operations in a secure way. Constrained 
> devices will thus be enabled to authenticate communications 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 an 
> architecture with one or more trusted less-constrained devices which 
> will 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.
> - Define certificate profiling (what kinds of certificates and which 
> attributes are to be used).
> - Define a mechanism for authenticated and protected transfer of 
> authorization information suitable for constrained device to 
> constrained device communication.
> - Define an access ticket and authorization information format 
> suitable for constrained devices.
> - Define bootstrapping for authorization information using the 
> Resource Directory.


--
email: rstruik.ext@gmail.com | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363


_______________________________________________
core mailing list
core@ietf.org
https://www.ietf.org/mailman/listinfo/core