Re: [Ace] Charter Update
Göran Selander <goran.selander@ericsson.com> Thu, 23 January 2014 11:03 UTC
Return-Path: <goran.selander@ericsson.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 675B11A0453 for <ace@ietfa.amsl.com>; Thu, 23 Jan 2014 03:03:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.939
X-Spam-Level:
X-Spam-Status: No, score=-0.939 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, HOST_MISMATCH_NET=0.311, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, SPF_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 WKb4A3IHBMtz for <ace@ietfa.amsl.com>; Thu, 23 Jan 2014 03:03:48 -0800 (PST)
Received: from sessmg20.mgmt.ericsson.se (sessmg20.ericsson.net [193.180.251.50]) by ietfa.amsl.com (Postfix) with ESMTP id C08901A0451 for <ace@ietf.org>; Thu, 23 Jan 2014 03:03:46 -0800 (PST)
X-AuditID: c1b4fb32-b7f4c8e0000012f5-e2-52e0f7109d9e
Received: from ESESSHC016.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg20.mgmt.ericsson.se (Symantec Mail Security) with SMTP id 74.9D.04853.017F0E25; Thu, 23 Jan 2014 12:03:45 +0100 (CET)
Received: from ESESSMB303.ericsson.se ([169.254.3.107]) by ESESSHC016.ericsson.se ([153.88.183.66]) with mapi id 14.02.0387.000; Thu, 23 Jan 2014 12:03:43 +0100
From: Göran Selander <goran.selander@ericsson.com>
To: Likepeng <likepeng@huawei.com>, Stefanie Gerdes <gerdes@tzi.de>, "ace@ietf.org" <ace@ietf.org>
Thread-Topic: Charter Update
Thread-Index: AQHPEQODYpam4LbFJUioLZLuB/tCYZqEM2aAgA3uBICAABIbgA==
Date: Thu, 23 Jan 2014 11:03:43 +0000
Message-ID: <CF06B53C.694E%goran.selander@ericsson.com>
References: <52D4F6AD.3060101@tzi.de> <CEFAE9D7.19DFC%goran.selander@ericsson.com> <34966E97BE8AD64EAE9D3D6E4DEE36F252AE2577@SZXEMA501-MBS.china.huawei.com>
In-Reply-To: <34966E97BE8AD64EAE9D3D6E4DEE36F252AE2577@SZXEMA501-MBS.china.huawei.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.3.9.131030
x-originating-ip: [153.88.183.150]
Content-Type: multipart/alternative; boundary="_000_CF06B53C694Egoranselanderericssoncom_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrJIsWRmVeSWpSXmKPExsUyM+Jvja7g9wdBBj03WS2+f+thtvj9ZAWr xcaLdxkt9hxuYrZ41XqH2YHVo+XIW1aPJUt+Mnn0HvvN5rHt7VfmAJYoLpuU1JzMstQifbsE rozflycyFfQtYqt42H+PqYFxbS9bFyMnh4SAicT3h3uZIWwxiQv31gPFuTiEBE4wSqyespgd wlnCKHFjQwMLSBWbgIvEg4ZHTCC2iECKREfbRkYQm1kgVOJj60ywuLCAtETPqo1ANgdQjYzE sn4riHIniSU3e9lBbBYBVYmXTyaA2bwC5hIzL59nhti1gFFi5YwvYLs4BcIkXr5dD3YpI9B1 30+tYYLYJS5x68l8JoirBSSW7DkP9YGoxMvH/1hBbFEBPYl7j+ayQMSVJFZsvwR1Z4zEiZZz UIsFJU7OfMIygVFsFpKxs5CUzUJSNgvoHWYBTYn1u/QhShQlpnQ/ZIewNSRa58yFsq0ljk7f xoKsZgEjxypGyeLU4uLcdCMDvdz03BK91KLM5OLi/Dy94tRNjMDoPrjlt9EOxpN77A8xSnOw KInzXmetCRISSE8sSc1OTS1ILYovKs1JLT7EyMTBKdXAqDs/cLVL03EljUmf2uSry18+kVb6 +89I87+eBdfmELOl/9tkTc9670k2eHLu7ZeNnZGVd8tkBP6cl+eJlV23qdHznVzQ0YbH5lky +zezTtwcsNMsMG39xe+/Ch8F/dBulp9zbNf9NxdfrTmnlrpXleeJw6PLiqUZnXPPvjiq4pHb bmMY1baeX4mlOCPRUIu5qDgRAEFlKAi8AgAA
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 11:03:52 -0000
Hi Kepeng, Thanks for looking back at the comments made. Meanwhile I’ve been putting the still relevant comments in the context the current draft charter so we have done some double work here. I’ll post that soon. Göran From: Likepeng <likepeng@huawei.com<mailto:likepeng@huawei.com>> Date: Thursday 23 January 2014 11:58 To: Göran Selander <goran.selander@ericsson.com<mailto:goran.selander@ericsson.com>>, Stefanie Gerdes <gerdes@tzi.de<mailto:gerdes@tzi.de>>, "ace@ietf.org<mailto:ace@ietf.org>" <ace@ietf.org<mailto:ace@ietf.org>> Cc: Bert Greevenbosch <Bert.Greevenbosch@huawei.com<mailto:Bert.Greevenbosch@huawei.com>>, Ludwig Seitz <ludwig@sics.se<mailto:ludwig@sics.se>> Subject: Re: Charter Update 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<mailto: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