Re: [Ace] Charter Update
Likepeng <likepeng@huawei.com> Thu, 23 January 2014 10:59 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 689C71A0441 for <ace@ietfa.amsl.com>; Thu, 23 Jan 2014 02:59:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.435
X-Spam-Level:
X-Spam-Status: No, score=-4.435 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.535, 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 S4FBd_V209M8 for <ace@ietfa.amsl.com>; Thu, 23 Jan 2014 02:59:23 -0800 (PST)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 4096C1A0385 for <ace@ietf.org>; Thu, 23 Jan 2014 02:59:22 -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 BCV64049; Thu, 23 Jan 2014 10:59:04 +0000 (GMT)
Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 23 Jan 2014 10:58:46 +0000
Received: from SZXEMA403-HUB.china.huawei.com (10.82.72.35) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 23 Jan 2014 10:59:01 +0000
Received: from SZXEMA501-MBS.china.huawei.com ([169.254.2.66]) by SZXEMA403-HUB.china.huawei.com ([10.82.72.35]) with mapi id 14.03.0158.001; Thu, 23 Jan 2014 18:58:53 +0800
From: Likepeng <likepeng@huawei.com>
To: Göran Selander <goran.selander@ericsson.com>, Stefanie Gerdes <gerdes@tzi.de>, "ace@ietf.org" <ace@ietf.org>
Thread-Topic: Charter Update
Thread-Index: AQHPEQOJoLZZVMLmu0mdHgyBfloywpqDrUeAgA51YYA=
Date: Thu, 23 Jan 2014 10:58:53 +0000
Message-ID: <34966E97BE8AD64EAE9D3D6E4DEE36F252AE2577@SZXEMA501-MBS.china.huawei.com>
References: <52D4F6AD.3060101@tzi.de> <CEFAE9D7.19DFC%goran.selander@ericsson.com>
In-Reply-To: <CEFAE9D7.19DFC%goran.selander@ericsson.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_34966E97BE8AD64EAE9D3D6E4DEE36F252AE2577SZXEMA501MBSchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Cc: Bert Greevenbosch <Bert.Greevenbosch@huawei.com>, Ludwig Seitz <ludwig@sics.se>
Subject: Re: [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: Thu, 23 Jan 2014 10:59:29 -0000
Hi Goran, Thanks for the feedback. They are very useful. Please see my responses. >I can't see that this property of constrained devices that you single out >(limited user interface) is specifically relevant to the work proposed for ACE. >How about instead mentioning properties like limited processing and power >capabilities or just refer to LWIG terminology? Limited user interface is relevant because the user can’t grant permissions from the user interface. That makes authorization more difficult. About limited processing and power capabilities, they are mentioned in the first paragraph. >I agree that CoRE has decided for DTLS, but as we know DTLS was not >designed for constrained environments and there are improvements to be >made, e.g. the ongoing work in DICE. There are also potential improvements >to the DTLS handshake. Considering this, I would say that authentication >is not yet "well understood". “Well understood” was removed. >"authenticated authorization" has been discussed on this list, but those >who did not follow that thread may interpret this concept in different >ways. “Authenticated authorization” was changed in the paragraphs, but it is still in the task list. To be changed in the next version. >I propose to replace the previous sentence with something spelling out >what the problem is, like: >"The CoRE WG has selected DTLS as the preferred protocol for >authentication and communication security in constrained devices. For >authorization, however, it may be infeasible for a constrained device to >make authorization decisions and manage authorization policies." We changed it as the following: CoAP provides a DTLS binding for authentication but does not address authorization. >To harmonize with previous proposed text replace last sentence with: >"This includes the case where a constrained device enforces an >externally made authorization decision." >This latter part is important, but IMHO is not specifically associated to the >discussion about the need for authentication. How about: >"The authorization solution needs to consider the ability to change >authorization state in an authorized way, including expiry or revocation >of authorization decisions."? Now, it is listed as examples in the second paragraph: Where are the authorization decisions 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 granted to other persons temporarily? How can access be revoked? >Replace "authenticate operations" with "authenticate requests for >operations". Yes, changed. >If I understand this right, this is about the X.509 certificates used in >CoAP/DTLS for the certificate security mode. What about security modes >that do not make use of certificates (e.g. as in draft-seitz-security-modes)? >How about generalizing slightly to >"Optimize existing and design new security modes for CoAP, e.g. profiles >for X.509 certificates used in the CoAP/DTLS certificate security mode" This is one of the open issues that sent out by Stefanie. Keep it open for now. >Proposal: remove "a large number of". The number of keys per constrained >device is not necessarily a problem, but it may benefit from support with >key management, e.g. derivation of session keys. We keep it because we can't really argue that the constrained devices won't need to manage any keys at all. >I think the second sentence can be left out. Use cases and requirements is >commonly understood as an initial activity to set the scope and >constraints for the work. Yes, removed. >How about formulating this as "design criteria for security protocol" or >something similar instead of "applicability of security mechanisms"? >Maybe there is already a good reference to use as a starting point? LWIG? In fact, for the task list, it is the key part. We didn’t change much about this, because we hope to get more discussions and do it later. >In a recent ACE thread, we discussed the option of either client or server >being non-constrained. How about replacing "constrained device to constrained >device communication" with "constrained environments"? Agree with the changes. To be changed. Kind Regards Kepeng 发件人: Ace [mailto:ace-bounces@ietf.org] 代表 G?ran Selander 发送时间: 2014年1月14日 21:16 收件人: Stefanie Gerdes; ace@ietf.org 抄送: Bert Greevenbosch; Ludwig Seitz; Likepeng 主题: Re: [Ace] Charter Update Hi Stefanie Thanks for considering our input, below are some more detailed comments. Sorry for iterating some things that has already been discussed on the list. On 1/14/14 9:34 AM, "Stefanie Gerdes" <gerdes@tzi.de<mailto:gerdes@tzi.de>> wrote: 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. I can't see that this property of constrained devices that you single out (limited user interface) is specifically relevant to the work proposed for ACE. How about instead mentioning properties like limited processing and power capabilities or just refer to LWIG terminology? While authentication is well understood, at least for communication security, I agree that CoRE has decided for DTLS, but as we know DTLS was not designed for constrained environments and there are improvements to be made, e.g. the ongoing work in DICE. There are also potential improvements to the DTLS handshake. Considering this, I would say that authentication is not yet "well understood". there are only unsufficient means for authenticated authorization. "authenticated authorization" has been discussed on this list, but those who did not follow that thread may interpret this concept in different ways. I think it would be good to stick to the word "authorization" in the charter. More below. I propose to replace the previous sentence with something spelling out what the problem is, like: "The CoRE WG has selected DTLS as the preferred protocol for authentication and communication security in constrained devices. For authorization, however, it may be infeasible for a constrained device to make authorization decisions and manage authorization policies." 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. To harmonize with previous proposed text replace last sentence with: "This includes the case where a constrained device enforces an externally made authorization decision." Authentication is considered in this context as it is needed as a prerequisite to performing authorization, I guess this is intended as explanation of "authenticated authorization". I have two comments (this is in part continuing the thread of http://www.ietf.org/mail-archive/web/core/current/msg05132.html): 1. I agree that some sort of verification of access token is needed for authorization, but do we exclude the case of (OAuth) Bearer Tokens? I.e. that there is no information binding the entity making the request to the access token besides being in possession of the token. In the case of Bearer Tokens I'm not sure the term "authentication" is correct as it is just a matter of verifying a digital signature or a MAC (RFC4949 "authenticate"). 2. What I think this all boils down to is that the consumer of the authorization decision is: (a) verifying the integrity of the authorization information, and (b) verifying that the source of the authorization information is allowed by local policy ("trusted") to issue authorization decisions, and (c) verifying that the subject of the authorization decision coincides with the requesting entity. If we accept Bearer Tokens then (c) is optional, else mandatory. Maybe (some parts of) this what you refer to as "authenticated authorization"? I don't think we need go into such details in the charter, just to see if we agree on the lower level. including the authorization to change the authorization state. This latter part is important, but IMHO is not specifically associated to the discussion about the need for authentication. How about: "The authorization solution needs to consider the ability to change authorization state in an authorized way, including expiry or revocation of authorization decisions."? 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 Replace "authenticate operations" with "authenticate requests for operations" 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). Proposal: remove "a large number of". The number of keys per constrained device is not necessarily a problem, but it may benefit from support with key management, e.g. derivation of session 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.) I think the second sentence can be left out. Use cases and requirements is commonly understood as an initial activity to set the scope and constraints for the work. Flesh out profiles for certificates used for authenticated authorization. If I understand this right, this is about the X.509 certificates used in CoAP/DTLS for the certificate security mode. What about security modes that do not make use of certificates (e.g. as in draft-seitz-security-modes)? How about generalizing slightly to "Optimize existing and design new security modes for CoAP, e.g. profiles for X.509 certificates used in the CoAP/DTLS certificate security mode" Document the applicability of the various security mechanisms with respect to resource usage (RAM, message round trips, power consumption etc.). I think this is valuable, I'm just reflecting of the scope of the current text. Say that you can save one round trip by making a some symmetric crypto operation on the constrained resource server. Now we need to decide if we should make that trade off, i.e. introduce crypto to save on communication needs and thus reduce power consumption. This is wider than just "applicability of security mechanisms"? Another naive example: say you have the option to have a security protocol with either a few large messages or several small messages, what is preferred? How about formulating this as "design criteria for security protocol" or something similar instead of "applicability of security mechanisms"? Maybe there is already a good reference to use as a starting point? LWIG? Define a mechanism for authenticated and protected transfer of authorization information suitable for constrained device to constrained device communication. In a recent ACE thread, we discussed the option of either client or server being non-constrained. How about replacing "constrained device to constrained device communication" with "constrained environments"? Best regards, Göran 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
- [Ace] Charter Update Stefanie Gerdes
- Re: [Ace] Charter Update Göran Selander
- Re: [Ace] Charter Update Hannes Tschofenig
- Re: [Ace] Charter Update Göran Selander
- Re: [Ace] Charter Update Olaf Bergmann
- Re: [Ace] Charter Update Likepeng
- Re: [Ace] Charter Update Göran Selander
- Re: [Ace] Charter Update Olaf Bergmann
- Re: [Ace] Charter Update Göran Selander
- Re: [Ace] Charter Update Göran Selander
- Re: [Ace] Charter Update Olaf Bergmann
- Re: [Ace] Charter Update Göran Selander
- Re: [Ace] Charter Update Stefanie Gerdes
- Re: [Ace] Charter Update Göran Selander