From nobody Wed Dec 7 00:43:35 2016 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83A50129642 for ; Wed, 7 Dec 2016 00:43:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.621 X-Spam-Level: X-Spam-Status: No, score=-2.621 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 Q-UxBnMlJ2uu for ; Wed, 7 Dec 2016 00:43:32 -0800 (PST) Received: from lb3-smtp-cloud3.xs4all.net (lb3-smtp-cloud3.xs4all.net [194.109.24.30]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC3791293D9 for ; Wed, 7 Dec 2016 00:43:31 -0800 (PST) Received: from webmail.xs4all.nl ([IPv6:2001:888:0:22:194:109:20:214]) by smtp-cloud3.xs4all.net with ESMTP id GwjV1u00E0F6qFb01wjVZx; Wed, 07 Dec 2016 09:43:29 +0100 Received: from 2001:983:a264:1:c941:e6f8:b9be:ff57 by webmail.xs4all.nl with HTTP (HTTP/1.1 POST); Wed, 07 Dec 2016 09:43:29 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Wed, 07 Dec 2016 09:43:29 +0100 From: peter van der Stok To: ace@ietf.org Organization: vanderstok consultancy Mail-Reply-To: consultancy@vanderstok.org In-Reply-To: <148109993874.13650.16153158219588186911.idtracker@ietfa.amsl.com> References: <148109993874.13650.16153158219588186911.idtracker@ietfa.amsl.com> Message-ID: <98ee2bb96353964756779ee7e1510013@xs4all.nl> X-Sender: stokcons@xs4all.nl (fxFOgpaYBWMPDPtSYFY/p9ghUF9Yrduj) User-Agent: XS4ALL Webmail Archived-At: Subject: [Ace] Fwd: New Version Notification for draft-vanderstok-ace-coap-est-00.txt X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: consultancy@vanderstok.org List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Dec 2016 08:43:34 -0000 Dear all, This is the draft that was originally submitted to CoRE and was presented at the end of the ACE meeting in Seoul. Discussions are on-going on how to proceed with this draft, given the bootstrap work in anima and 6tisch. Looking forward to your reactions, Peter A new version of I-D, draft-vanderstok-ace-coap-est-00.txt has been successfully submitted by Peter van der Stok and posted to the IETF repository. Name: draft-vanderstok-ace-coap-est Revision: 00 Title: EST based on DTLS secured CoAP (EST-coaps) Document date: 2016-12-07 Group: Individual Submission Pages: 15 URL: https://www.ietf.org/internet-drafts/draft-vanderstok-ace-coap-est-00.txt Status: https://datatracker.ietf.org/doc/draft-vanderstok-ace-coap-est/ Htmlized: https://tools.ietf.org/html/draft-vanderstok-ace-coap-est-00 Abstract: Low-resource devices in a Low-power and Lossy Network (LLN) can operate in a mesh network using the IPv6 over Low-power Personal Area Networks (6LoWPAN) and IEEE 802.15.4 link-layer standards. Provisioning these devices in a secure manner with keys (often called security bootstrapping) used to encrypt and authenticate messages is the subject of Bootstrapping of Remote Secure Key Infrastructures (BRSKI) [I-D.ietf-anima-bootstrapping-keyinfra]. Enrollment over Secure Transport (EST) [RFC7030], based on TLS and HTTP, is used for BRSKI. This document defines how low-resource devices are expected to use EST over DTLS and CoAP. 6LoWPAN fragmentation management and minor extensions to CoAP are needed to enable EST over DTLS-secured CoAP (EST-coaps). Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat From nobody Wed Dec 7 11:38:05 2016 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6A03129AA2; Wed, 7 Dec 2016 11:37:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.797 X-Spam-Level: X-Spam-Status: No, score=-4.797 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-2.896, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 PqmbnRRalV-h; Wed, 7 Dec 2016 11:37:46 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CCCBB129584; Wed, 7 Dec 2016 11:37:35 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 08B19203AE; Wed, 7 Dec 2016 14:55:02 -0500 (EST) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 71E6A63768; Wed, 7 Dec 2016 14:37:34 -0500 (EST) From: Michael Richardson To: "ace\@ietf.org" , 6tisch@ietf.org, 6tisch-security@ietf.org, anima-bootstrap@ietf.org In-Reply-To: <6525c5f0b6e040b683ccd9c43b1c5e2f@VI1PR9003MB0237.MGDPHG.emi.philips.com> References: <6525c5f0b6e040b683ccd9c43b1c5e2f@VI1PR9003MB0237.MGDPHG.emi.philips.com> X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Ace] EST over CoAP in ACE wg X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: ace@ietf.org List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Dec 2016 19:37:49 -0000 --=-=-= Content-Type: text/plain I have read: draft-pritikin-coap-bootstrap and draft-vanderstock-core-coap-est and over in the 6tisch security design team we have been trying to adapt the ANIMA WG draft-ietf-anima-bootstrapping-keyinfra for use in the 6tisch environment as a zero-touch enrollment process. (Yes, I am an author involved in both WGs) Peter (one of the authors of draft-vanderstock-core-coap-est) and Max (author of draft-pritikin-coap-bootstrap) are involved. Both documents have good content, and we could combine them easily and wind up with a relatively straight forward description of how to run EST over COAPS. But I don't think that this really solves the problems that we have. However, the movement in draft-vucinic-6tisch-minimal-security (as phase 2, and one-touch) and draft-richardson-6tisch-dtsecurity-secure-join (as phase 1, zero-touch) [both of which are being considered for adoption] is to move away from DTLS and towards OSCOAP and EDHOC. As such, what we would really like is an EST-like mechanism which runs over OSCOAP with EDHOC keying. Ideally, it would also permit the process to be managed/initiated from the new device (the pledge), or from the JCE (Registrar, which might also be the AS in ACE terminology). We want to initiate from the JCE so that we can: a) simplify the constrained device. b) manage the order and priority of join activities to avoid network congestion in constrained (mesh) networks. On the other hand, some want a really simple system that can be used with PSKs as authentication, with the new nodes initiating. I wrote this email last week to explain some of what I have in mind. https://www.ietf.org/mail-archive/web/6tisch/current/msg05020.html I don't know if the EST work fits into ACE's charter, but given that ACE is where OSCOAP and EDHOC seem to be, I'm happy to work on a document here. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlhIZP4ACgkQgItw+93Q 3WXOWQf+KBR6EmPppxIOwna8SV1Urd6mO40e5GVek2gMe/waBEc9koF1smIztedO +V149y098pwPFKmUPMKpWDu4uffFYxJX/aA8X5xWQnJRh3V5fDJJqPXYOPkKDs6o XlKZNiMKloERRwDqVo6dvdi3q1RoLvkO95/SRDu6bzBNnIN9McoqgxxKUs7ofuL+ azR6bsragScPy7PjZcZZwALQYsfw/xZdmO/ztbM/fJ48yxxmzNHPZupLoXxJLVbZ 39BuOkICn+DZ57rMDr2gP8Oh/iwmCUYtrsHnNPaQ5EZqJ1cC6RZZGbh9LZaB5i/S CUvQyN/LCy+OwlHH+y9i9YukNUuJrw== =pTHt -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Dec 7 11:50:33 2016 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B590D129AD6 for ; Wed, 7 Dec 2016 11:50:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.797 X-Spam-Level: X-Spam-Status: No, score=-4.797 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-2.896, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 l4m_PPg22ruZ for ; Wed, 7 Dec 2016 11:50:29 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 44581129ACA for ; Wed, 7 Dec 2016 11:50:26 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 22416203AE; Wed, 7 Dec 2016 15:07:53 -0500 (EST) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 3C1A163768; Wed, 7 Dec 2016 14:50:25 -0500 (EST) From: Michael Richardson To: "ace\@ietf.org" In-Reply-To: References: X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Cc: Martin Furuhed Nexus Subject: Re: [Ace] EST over CoAP in ACE wg X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Dec 2016 19:50:32 -0000 --=-=-= Content-Type: text/plain see inline Martin Furuhed Nexus wrote: > My first post after joining the list. welcome! > As mentioned by Shahid and Samuel, Nexus Group and SICS began a joint > project over a year ago for enabling constrained devices enroll for > certificates using EST over CoAP. > A standard EST server add-on will soon be part of the Nexus > Certificate Manager CA software. Additional EST CoAP server work is > now done in parallel with the work on the SICS EST CoAP client. Our > current implementation shares many similarities to the draft, and the > objective is to update and align our implementation to the draft going > forward. We would be happy to contribute experience together with SICS > based on our ongoing work. It would be great if you could review the two drafts and say if there were significant changes from what you implemented, and ideally to say if they were arbitrary decisions, or were motivated by a need to solve a problem we have not yet realized needed to be solved. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlhIaAAACgkQgItw+93Q 3WUUYgf/fhETO4jjZsmLUolxn6rRHfbbOAJ8fMevjpXjLmvE8Nj2uP9HHaJf9FlM yD715ScmJbS5FHB0yo9pc44/18JB08MB9MR5LYI04VEcy4fekkxGuf+Zwxe9A4Rt A4+7Hnr3HyijoPkuqNkBIy9aK0GqjJK+a4F9zIqAExQp4izRkDjrsSp0lUSAtyfg B2O5bSS9WqV5XdbkgXLmOOE/+wVP0Ctydh0KhMSB6F/vczK0ikH3lxMn30pZs+q+ 9g7TdLCP+C9gNNuyi85qOVu4xB8JjaDbtfcgNJ1xTOF2nxryyXikZMiHhhhhOuFU NoWeXGEg0l5hZ2E2cGTo28u3bUEytQ== =BHb1 -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Dec 8 00:12:32 2016 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0E8A129B58 for ; Thu, 8 Dec 2016 00:12:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=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 Vl1MQE0FNnfd for ; Thu, 8 Dec 2016 00:12:24 -0800 (PST) Received: from lb1-smtp-cloud6.xs4all.net (lb1-smtp-cloud6.xs4all.net [194.109.24.24]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8C54C129CB7 for ; Thu, 8 Dec 2016 00:12:16 -0800 (PST) Received: from webmail.xs4all.nl ([194.109.20.195]) by smtp-cloud6.xs4all.net with ESMTP id HLCE1u0034CYHle01LCEJ8; Thu, 08 Dec 2016 09:12:14 +0100 Received: from 2001:983:a264:1:e4b5:c90e:f42d:52ed by webmail.xs4all.nl with HTTP (HTTP/1.1 POST); Thu, 08 Dec 2016 09:12:14 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Thu, 08 Dec 2016 09:12:14 +0100 From: peter van der Stok To: ace@ietf.org Organization: vanderstok consultancy Mail-Reply-To: consultancy@vanderstok.org In-Reply-To: <14831.1481139454@obiwan.sandelman.ca> References: <6525c5f0b6e040b683ccd9c43b1c5e2f@VI1PR9003MB0237.MGDPHG.emi.philips.com> <14831.1481139454@obiwan.sandelman.ca> Message-ID: <5ac94ac231bc766afdb72776f6ea5e0f@xs4all.nl> X-Sender: stokcons@xs4all.nl (hXPlVLSW7/ja0OkiFMaSjBRy1n/Lryw4) User-Agent: XS4ALL Webmail Archived-At: Cc: 6tisch@ietf.org, anima-bootstrap@ietf.org, 6tisch-security@ietf.org Subject: Re: [Ace] EST over CoAP in ACE wg X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: consultancy@vanderstok.org List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Dec 2016 08:12:25 -0000 Hi Michael, > > As such, what we would really like is an EST-like mechanism which runs > over OSCOAP with EDHOC keying. Ideally, it would also permit the > process > to be managed/initiated from the new device (the pledge), or from the > JCE > (Registrar, which might also be the AS in ACE terminology). > About yesterday I started to understand the approach you suggest. Just some more information, to be absolutely sure about what you propose. Do you propose to keep the content formats used by EST unchanged? and keep all the different modes specified in EST RFC? Greetings, Peter From nobody Thu Dec 8 22:04:27 2016 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 204631293EE; Thu, 8 Dec 2016 22:04:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.418 X-Spam-Level: X-Spam-Status: No, score=-17.418 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-2.896, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 eYOuGX8pPXes; Thu, 8 Dec 2016 22:04:24 -0800 (PST) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A6932128B38; Thu, 8 Dec 2016 22:04:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4048; q=dns/txt; s=iport; t=1481263463; x=1482473063; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=Tk/ObWcHBerR5Y0U6HMtC5vA9NyrCvWbZRnEXovn0dU=; b=ZY7ganrAcPhPWjoyFHMNAEUZAaFXyXLgB0cJHPR9TCxVvroRtnMfgcvc RefdqFsFZB0/ZKklZPXgSTOUHWMcZSn1HRN1vTi71AXP604PlZViBUKv8 hOIMELa8CZFMxFxe+J7AVqxJxmpicSC47gjwTK6MLtypxHUWQAG+HqzAj c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BuAQCDSEpY/4UNJK1eGgEBAQECAQEBA?= =?us-ascii?q?QgBAQEBgywLAQEBAQEfWoEGB41ClxOVAoIJKYJCgmxKAoF8PxQBAgEBAQEBAQF?= =?us-ascii?q?iKIRoAQEBBDpLBAIBCBEEAQEfCQcyFAkIAQEEARIIiGMOqVmLLAEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBARgFhj6EW4QaEAIBTYUvBZprAYlehziBfIhGhguOC4QNAR8?= =?us-ascii?q?3YTyDXRyBXXIBiAuBDQEBAQ?= X-IronPort-AV: E=Sophos;i="5.33,323,1477958400"; d="scan'208";a="184901328" Received: from alln-core-11.cisco.com ([173.36.13.133]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 09 Dec 2016 06:04:22 +0000 Received: from XCH-RCD-006.cisco.com (xch-rcd-006.cisco.com [173.37.102.16]) by alln-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id uB964MGk012495 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 9 Dec 2016 06:04:22 GMT Received: from xch-aln-010.cisco.com (173.36.7.20) by XCH-RCD-006.cisco.com (173.37.102.16) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Fri, 9 Dec 2016 00:04:21 -0600 Received: from xch-aln-010.cisco.com ([173.36.7.20]) by XCH-ALN-010.cisco.com ([173.36.7.20]) with mapi id 15.00.1210.000; Fri, 9 Dec 2016 00:04:22 -0600 From: "Panos Kampanakis (pkampana)" To: "ace@ietf.org" , "6tisch@ietf.org" <6tisch@ietf.org>, "6tisch-security@ietf.org" <6tisch-security@ietf.org>, "anima-bootstrap@ietf.org" Thread-Topic: [Anima-bootstrap] [Ace] EST over CoAP in ACE wg Thread-Index: AdJD/4dN3nkys8JpRuSDXvz8bQBVcAM9B64AADuYMdA= Date: Fri, 9 Dec 2016 06:04:21 +0000 Message-ID: References: <6525c5f0b6e040b683ccd9c43b1c5e2f@VI1PR9003MB0237.MGDPHG.emi.philips.com> <14831.1481139454@obiwan.sandelman.ca> In-Reply-To: <14831.1481139454@obiwan.sandelman.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.82.216.75] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Ace] [Anima-bootstrap] EST over CoAP in ACE wg X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Dec 2016 06:04:26 -0000 Hi Michael, This are interesting good points. IMO, draft-pritikin-coap-bootstrap/draft-vanderstock-core-coap-est do not n= ecessarily need to define one transport mechanism. COAPS (over DTLS) is one= obvious option but running over OSCOAP with EDHOC is another. One of the g= oals of these drafts (would need to be merged) is the binding between COAP = messages and BRSKI / EST APIs for all the bootstrapping and cert enrollment= transactions defined in the anima-bootstrapping-keyinfra doc and RFC7030. = draft-pritikin-coap-bootstrap/draft-vanderstock-core-coap-est address DTLS = as transport mechanism right now, but could be expanded to define more than= one transports. If the WG finds that as a better idea, normative language = would need to be carefully of course and maybe an MTI option would need to = be chosen. I am curious about your workflow in https://www.ietf.org/mail-archive/web/6= tisch/current/msg05020.html You are envisioning for the JCE to initiate the= bootstrapping to the pledge, but wouldn't that better be defined in the an= ima-bootstrapping-keyinfra doc? About 'simple system that can be used with PSKs as authentication', I was c= urious. Did you have TLS-PSK, or TLS-SRP or OSCOAP message auth with PSK/RP= K/Cert? Anything more detail about these usecases? A nit in " <--- CoAP POST /cert----- [PKCS7 Certificate] ". That messag= e would require the private key to be included with the cert since the pled= ge did not generate it by himself. EST defines CMS for this message. PKCS12= could suffice here as well with the challenge if the passphrase provisioni= ng being the problem. Rgs, Panos -----Original Message----- From: Anima-bootstrap [mailto:anima-bootstrap-bounces@ietf.org] On Behalf O= f Michael Richardson Sent: Wednesday, December 07, 2016 2:38 PM To: ace@ietf.org; 6tisch@ietf.org; 6tisch-security@ietf.org; anima-bootstra= p@ietf.org Subject: Re: [Anima-bootstrap] [Ace] EST over CoAP in ACE wg I have read: draft-pritikin-coap-bootstrap and draft-vanderstock-core-coap-est and over in the 6tisch security design team we have been trying to adapt th= e ANIMA WG draft-ietf-anima-bootstrapping-keyinfra for use in the 6tisch en= vironment as a zero-touch enrollment process. (Yes, I am an author involved in both WGs) Peter (one of the authors of draft-vanderstock-core-coap-est) and Max (auth= or of draft-pritikin-coap-bootstrap) are involved. Both documents have good content, and we could combine them easily and wind= up with a relatively straight forward description of how to run EST over C= OAPS. But I don't think that this really solves the problems that we have. However, the movement in draft-vucinic-6tisch-minimal-security (as phase 2, and one-touch) and draft-richardson-6tisch-dtsecurity-secure-join (as phase 1, zero-touc= h) [both of which are being considered for adoption] is to move away from DTLS and towards OSCOAP and EDHOC. As such, what we would really like is an EST-like mechanism which runs over= OSCOAP with EDHOC keying. Ideally, it would also permit the process to be= managed/initiated from the new device (the pledge), or from the JCE (Regis= trar, which might also be the AS in ACE terminology). We want to initiate from the JCE so that we can: a) simplify the constrained device. b) manage the order and priority of join activities to avoid network congestion in constrained (mesh) networks. On the other hand, some want a really simple system that can be used with P= SKs as authentication, with the new nodes initiating. I wrote this email last week to explain some of what I have in mind. https://www.ietf.org/mail-archive/web/6tisch/current/msg05020.html I don't know if the EST work fits into ACE's charter, but given that ACE is= where OSCOAP and EDHOC seem to be, I'm happy to work on a document here. -- Michael Richardson , Sandelman Software Works -=3D = IPv6 IoT consulting =3D- From nobody Fri Dec 9 00:13:21 2016 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2F4812A19D; Fri, 9 Dec 2016 00:13:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sandeep.de 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 kNhzJcuRi0G2; Fri, 9 Dec 2016 00:12:59 -0800 (PST) Received: from mo6-p00-ob.smtp.rzone.de (mo6-p00-ob.smtp.rzone.de [IPv6:2a01:238:20a:202:5300::11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 19FDA12A192; Fri, 9 Dec 2016 00:12:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1481271175; l=11443; s=domk; d=sandeep.de; h=Content-Type:Cc:To:Subject:Date:From:References:In-Reply-To: MIME-Version; bh=jZDElEKRS7vQYNdGdqvR7hCMzGJAC8RutihCTnJS2EE=; b=V8+A0P22Q9NLu1+4NyfRFWMDHb2gKl7ngweypAzI5rmyHRELq2BqiHHxQQQ43ACmMY lZuVmKpJpuIoGjncZCvTOpJolySySNWs9yMm7hdYdRIVzwdo19rk6OszotvFqOmneYNh KYpScTMYWKORhbmFLjctrTtU24Jz9Wj+qzmVA= X-RZG-AUTH: :JWkQc2C7evFfytIRBe7p82UYMzBqkr+YiXEkNEKLhUifTGQRFYQZmh2f X-RZG-CLASS-ID: mo00 Received: from mail-qk0-f173.google.com ([209.85.220.173]) by smtp.strato.de (RZmta 39.10 AUTH) with ESMTPSA id t03c5asB98CsJck (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (curve secp384r1 with 384 ECDH bits, eq. 7680 bits RSA)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verification FAILED - unable to get local issuer certificate)) (Client hostname not verified); Fri, 9 Dec 2016 09:12:54 +0100 (CET) Received: by mail-qk0-f173.google.com with SMTP id q130so10398010qke.1; Fri, 09 Dec 2016 00:12:54 -0800 (PST) X-Gm-Message-State: AKaTC01EtXvCHh9f8C0ipQipDiR64G6BR6iKoAwCl4yAXxoQ5tudctDbYHJDvSd+biflWJ7F1G2erXhtj2r0tA== X-Received: by 10.55.43.29 with SMTP id r29mr66929057qkh.211.1481271173885; Fri, 09 Dec 2016 00:12:53 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.97.33 with HTTP; Fri, 9 Dec 2016 00:12:53 -0800 (PST) In-Reply-To: References: <6525c5f0b6e040b683ccd9c43b1c5e2f@VI1PR9003MB0237.MGDPHG.emi.philips.com> <14831.1481139454@obiwan.sandelman.ca> From: Sandeep Kumar Date: Fri, 9 Dec 2016 09:12:53 +0100 X-Gmail-Original-Message-ID: Message-ID: To: "Panos Kampanakis (pkampana)" Content-Type: multipart/alternative; boundary=001a1147e8e422baba05433552f8 Archived-At: Cc: "6tisch@ietf.org" <6tisch@ietf.org>, "anima-bootstrap@ietf.org" , Sandeep Kumar , "6tisch-security@ietf.org" <6tisch-security@ietf.org>, "ace@ietf.org" Subject: Re: [Ace] [Anima-bootstrap] EST over CoAP in ACE wg X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Dec 2016 08:13:06 -0000 --001a1147e8e422baba05433552f8 Content-Type: text/plain; charset=UTF-8 HI Michael Just to add, 6tisch has decided to use OSCOAP as the transport but other external standards like Fairhair and Thread have already decided to use DTLS as the transport for EST since it is already there and does not break the workflow the way it might in 6tisch. So these draft on DTLS transport do solve the problem for some, not for everyone. Kind regards Sandeep On Fri, Dec 9, 2016 at 7:04 AM, Panos Kampanakis (pkampana) < pkampana@cisco.com> wrote: > Hi Michael, > > This are interesting good points. > > IMO, draft-pritikin-coap-bootstrap/draft-vanderstock-core-coap-est do not > necessarily need to define one transport mechanism. COAPS (over DTLS) is > one obvious option but running over OSCOAP with EDHOC is another. One of > the goals of these drafts (would need to be merged) is the binding between > COAP messages and BRSKI / EST APIs for all the bootstrapping and cert > enrollment transactions defined in the anima-bootstrapping-keyinfra doc and > RFC7030. draft-pritikin-coap-bootstrap/draft-vanderstock-core-coap-est > address DTLS as transport mechanism right now, but could be expanded to > define more than one transports. If the WG finds that as a better idea, > normative language would need to be carefully of course and maybe an MTI > option would need to be chosen. > > I am curious about your workflow in https://www.ietf.org/mail- > archive/web/6tisch/current/msg05020.html You are envisioning for the JCE > to initiate the bootstrapping to the pledge, but wouldn't that better be > defined in the anima-bootstrapping-keyinfra doc? > > About 'simple system that can be used with PSKs as authentication', I was > curious. Did you have TLS-PSK, or TLS-SRP or OSCOAP message auth with > PSK/RPK/Cert? Anything more detail about these usecases? > > A nit in " <--- CoAP POST /cert----- [PKCS7 Certificate] ". That > message would require the private key to be included with the cert since > the pledge did not generate it by himself. EST defines CMS for this > message. PKCS12 could suffice here as well with the challenge if the > passphrase provisioning being the problem. > > Rgs, > Panos > > -----Original Message----- > From: Anima-bootstrap [mailto:anima-bootstrap-bounces@ietf.org] On Behalf > Of Michael Richardson > Sent: Wednesday, December 07, 2016 2:38 PM > To: ace@ietf.org; 6tisch@ietf.org; 6tisch-security@ietf.org; > anima-bootstrap@ietf.org > Subject: Re: [Anima-bootstrap] [Ace] EST over CoAP in ACE wg > > > I have read: > draft-pritikin-coap-bootstrap > and draft-vanderstock-core-coap-est > > and over in the 6tisch security design team we have been trying to adapt > the ANIMA WG draft-ietf-anima-bootstrapping-keyinfra for use in the > 6tisch environment as a zero-touch enrollment process. > (Yes, I am an author involved in both WGs) > > Peter (one of the authors of draft-vanderstock-core-coap-est) and Max > (author of draft-pritikin-coap-bootstrap) are involved. > > Both documents have good content, and we could combine them easily and > wind up with a relatively straight forward description of how to run EST > over COAPS. > But I don't think that this really solves the problems that we have. > > However, the movement in > draft-vucinic-6tisch-minimal-security (as phase 2, and one-touch) > and draft-richardson-6tisch-dtsecurity-secure-join (as phase 1, > zero-touch) > [both of which are being considered for adoption] > > is to move away from DTLS and towards OSCOAP and EDHOC. > > As such, what we would really like is an EST-like mechanism which runs > over OSCOAP with EDHOC keying. Ideally, it would also permit the process > to be managed/initiated from the new device (the pledge), or from the JCE > (Registrar, which might also be the AS in ACE terminology). > > We want to initiate from the JCE so that we can: > a) simplify the constrained device. > b) manage the order and priority of join activities to avoid > network congestion in constrained (mesh) networks. > > On the other hand, some want a really simple system that can be used with > PSKs as authentication, with the new nodes initiating. > > I wrote this email last week to explain some of what I have in mind. > https://www.ietf.org/mail-archive/web/6tisch/current/msg05020.html > > I don't know if the EST work fits into ACE's charter, but given that ACE > is where OSCOAP and EDHOC seem to be, I'm happy to work on a document here. > > -- > Michael Richardson , Sandelman Software Works -= > IPv6 IoT consulting =- > > > > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace > --001a1147e8e422baba05433552f8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

HI Michael

=C2=A0Just to add, 6tisch has decided to us= e OSCOAP as the transport but other external standards like Fairhair and Thread have already decided = to use DTLS as the transport for EST since it is already there and does not br= eak the workflow the way it might in 6tisch. So these draft on DTLS transport do so= lve the problem for some, not for everyone.

=C2=A0Kind regards

Sandeep

=C2=A0


On Fri, Dec= 9, 2016 at 7:04 AM, Panos Kampanakis (pkampana) <pkampana@cisco.com&= gt; wrote:
Hi Michael,

This are interesting good points.

IMO, draft-pritikin-coap-bootstrap/draft-vanderstock-core-coap-es= t do not necessarily need to define one transport mechanism. COAPS (over DT= LS) is one obvious option but running over OSCOAP with EDHOC is another. On= e of the goals of these drafts (would need to be merged) is the binding bet= ween COAP messages and BRSKI / EST APIs for all the bootstrapping and cert = enrollment transactions defined in the anima-bootstrapping-keyinfra doc and= RFC7030. draft-pritikin-coap-bootstrap/draft-vanderstock-core-coap-est address DTLS as transport mechanism right now, but could be expanded= to define more than one transports. If the WG finds that as a better idea,= normative language would need to be carefully of course and maybe an MTI o= ption would need to be chosen.

I am curious about your workflow in https://www.ietf.org/mail-archive/web/6tisch/current/msg05020.h= tml You are envisioning for the JCE to initiate the bootstrapping to th= e pledge, but wouldn't that better be defined in the anima-bootstrappin= g-keyinfra doc?

About 'simple system that can be used with PSKs as authentication',= I was curious. Did you have TLS-PSK, or TLS-SRP or OSCOAP message auth wit= h PSK/RPK/Cert? Anything more detail about these usecases?

A nit in " <--- CoAP POST /cert-----=C2=A0 =C2=A0 =C2=A0[PKCS7 Cert= ificate] ". That message would require the private key to be included = with the cert since the pledge did not generate it by himself. EST defines = CMS for this message. PKCS12 could suffice here as well with the challenge = if the passphrase provisioning being the problem.

Rgs,
Panos

-----Original Message-----
From: Anima-bootstrap [mailto:anima-bootstrap-bounces@ietf.org] On Behalf Of Michael Rich= ardson
Sent: Wednesday, December 07, 2016 2:38 PM
To: ace@ietf.org; 6tisch@ietf.org; 6tisch-security@ietf.org; anima-bootstrap@ietf.org
Subject: Re: [Anima-bootstrap] [Ace] EST over CoAP in ACE wg


I have read:
=C2=A0 =C2=A0 draft-pritikin-coap-bootstrap
and draft-vanderstock-core-coap-est

and over in the 6tisch security design team we have been trying to adapt th= e ANIMA WG draft-ietf-anima-bootstrapping-keyinfra for use in the 6tis= ch environment as a zero-touch enrollment process.
(Yes, I am an author involved in both WGs)

Peter (one of the authors of draft-vanderstock-core-coap-est) and Max = (author of draft-pritikin-coap-bootstrap) are involved.

Both documents have good content, and we could combine them easily and wind= up with a relatively straight forward description of how to run EST over C= OAPS.
But I don't think that this really solves the problems that we have.
However, the movement in
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-vucinic-6tisch-minimal-securit= y (as phase 2, and one-touch)
and=C2=A0 =C2=A0draft-richardson-6tisch-dtsecurity-secure-join (as pha= se 1, zero-touch)
[both of which are being considered for adoption]

is to move away from DTLS and towards OSCOAP and EDHOC.

As such, what we would really like is an EST-like mechanism which runs over= OSCOAP with EDHOC keying.=C2=A0 Ideally, it would also permit the process = to be managed/initiated from the new device (the pledge), or from the JCE (= Registrar, which might also be the AS in ACE terminology).

We want to initiate from the JCE so that we can:
=C2=A0 a) simplify the constrained device.
=C2=A0 b) manage the order and priority of join activities to avoid
=C2=A0 =C2=A0 =C2=A0network congestion in constrained (mesh) networks.

On the other hand, some want a really simple system that can be used with P= SKs as authentication, with the new nodes initiating.

I wrote this email last week to explain some of what I have in mind.
=C2=A0 https://www.ietf.org/mail-<= wbr>archive/web/6tisch/current/msg05020.html

I don't know if the EST work fits into ACE's charter, but given tha= t ACE is where OSCOAP and EDHOC seem to be, I'm happy to work on a docu= ment here.

--
Michael Richardson <mcr+IETF@= sandelman.ca>, Sandelman Software Works=C2=A0 -=3D IPv6 IoT consulti= ng =3D-



_______________________= ________________________
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

--001a1147e8e422baba05433552f8-- From nobody Thu Dec 15 22:28:51 2016 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 895CC129549 for ; Thu, 15 Dec 2016 22:28:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001] autolearn=ham autolearn_force=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 MujBJSzUlgFw for ; Thu, 15 Dec 2016 22:28:47 -0800 (PST) Received: from atl4mhob18.myregisteredsite.com (atl4mhob18.myregisteredsite.com [209.17.115.111]) by ietfa.amsl.com (Postfix) with ESMTP id BD9401294ED for ; Thu, 15 Dec 2016 22:28:47 -0800 (PST) Received: from mailpod.hostingplatform.com ([10.30.71.208]) by atl4mhob18.myregisteredsite.com (8.14.4/8.14.4) with ESMTP id uBG6SjaA043857 for ; Fri, 16 Dec 2016 01:28:45 -0500 Received: (qmail 20649 invoked by uid 0); 16 Dec 2016 06:28:45 -0000 X-TCPREMOTEIP: 73.207.234.73 X-Authenticated-UID: rturner@amalfisystems.com Received: from unknown (HELO ?10.0.1.28?) (rturner@amalfisystems.com@73.207.234.73) by 0 with ESMTPA; 16 Dec 2016 06:28:45 -0000 From: Randy Turner Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\)) Message-Id: Date: Fri, 16 Dec 2016 01:28:44 -0500 To: ace@ietf.org X-Mailer: Apple Mail (2.3251) Archived-At: Subject: [Ace] attribute based access control X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Dec 2016 06:28:49 -0000 HI, I was looking at draft-ietf-ace-oauth-authz-04, specifically the = client-to-AS section =E2=80=94 I am trying to determine if it is = possible to use this OAUTH-based model to implement attribute-based = authorization (ABAC). The client-to-AS section of this draft refers the reader to section 4 of = RFC 6749, which provides a =E2=80=9Cclient-id=E2=80=9D (good) and a = =E2=80=9Cscope=E2=80=9D to include in an authorization request. In addition, it looks like the ACE draft adds to this the =E2=80=9Caud=E2=80= =9D and =E2=80=9Ccnf=E2=80=9D parameters. I=E2=80=99m trying to map this client-to-AS request to a traditional = ABAC authorization request which asks the question =E2=80=9CIdentity = wants to perform action on resource =E2=80=9D =E2=80=A6 is this = allowed ? (allow/deny response) In one of the ACE draft examples, it uses the =E2=80=9Caud=E2=80=9D = field to include the name of a sensor =E2=80=9CtempSensor4711=E2=80=9D = - this could be the =E2=80=9Cresource=E2=80=9D of the ABAC request, and = the =E2=80=9Cclient ID=E2=80=9D (RFC 6749) could be the =E2=80=9Cidentity=E2= =80=9D I=E2=80=99m missing the type of operation or =E2=80=9Caction=E2=80=9D = that the client is trying to perform on a resource (=E2=80=9Cread=E2=80=9D= , =E2=80=9Cwrite=E2=80=9D, =E2=80=9Csomething else, hopefully = extensible=E2=80=9D) =E2=80=94 would this be the =E2=80=9Cscope=E2=80=9D = parameter ? I did see section 8.2 of the draft where it discusses a registry of = parameters which might allow additional parameters to a client-to-AS = request, but I was looking for a way to do ABAC without having to = register anything. I=E2=80=99m specifically asking about obtaining an access token to be = used later by a client accessing the actual resource. Has anyone tried combining draft-ietf-ace-oauth-authz-04 with ABAC = systems ? Thanks! Randy From nobody Fri Dec 16 00:47:40 2016 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52F811295BC for ; Fri, 16 Dec 2016 00:47:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=sics.se 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 7dGE7TBM-cEn for ; Fri, 16 Dec 2016 00:47:34 -0800 (PST) Received: from mail-wm0-x22b.google.com (mail-wm0-x22b.google.com [IPv6:2a00:1450:400c:c09::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 78C7412945D for ; Fri, 16 Dec 2016 00:47:34 -0800 (PST) Received: by mail-wm0-x22b.google.com with SMTP id a197so22794834wmd.0 for ; Fri, 16 Dec 2016 00:47:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sics.se; s=google; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to; bh=yVM49m6QjRajE3NheIeQXbUuqlX/EBBTxTieYTsVdyw=; b=EunDNNNuZm4zCPiqHVxGe/Fyb/JJ0zREg9OBwtz2mbShlgsaOuXBSTfJGCAosns7IO Cv8ZHKBwO1AU0/smy4VAFxlCkV9CDITuBwUCwskH6n1jWyavYPUI8t4Cpv4xqTTOMefW UtFItWe7WmXkpwDBDxybSUSz5kD8SElobCfGd5nqey4zT3F6GgKOAPzi6o7aBrycx7nR Fl+/Gu1PSzzmvtZ76b6Rs+4YCSvk6PAJrUkhEseeyB5RiW2G2GRr4zEzFqGG0KWAsf2m wqk+mCXFpcyt0IWBZT4AS3IYBYarB9KlcZfODw6/K7lY/QFwnI3IvItRwpZeG3qA7yAT Vkwg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to; bh=yVM49m6QjRajE3NheIeQXbUuqlX/EBBTxTieYTsVdyw=; b=tKDpy7DUMKfeggewG/YlYLv/raN5WEKJCz+N8EUaqn3gSsMKXOqP1mIDQkpAuch2wb Ml+PwT2FVjlWv1uYghiRajfdekbCn+imdeT3SFF2LQwMvSLrqfG8Bxzlk3Yze8TOYUCP CjMhvroFDuQJfXjfxr0dM+ATKnV8RJTR5EGY0mW0JlpP/aFY11krm7y11sx8gVQ6PGas DK1KRqgVmOBC0Dh1wZWYYtQSqXwSHo8kA4bX2kwwWwvpsH+/eUx3scXMEukRqoj4GHiA fKCQAgbVYmsT6DFFsyz48mNb/ESb5+rSGL73brOjfrlLwaWC56F98jD7SFDcKXAfqbYr sw/w== X-Gm-Message-State: AKaTC03qTTWpTTiho13JEvDxqJJk35d9yjyafNwsIAlvM2jdEl1azkbNCweueVlbfITsQCOp X-Received: by 10.25.212.82 with SMTP id l79mr483927lfg.155.1481878052789; Fri, 16 Dec 2016 00:47:32 -0800 (PST) Received: from [192.168.0.166] ([85.235.12.155]) by smtp.gmail.com with ESMTPSA id u204sm1163892lja.5.2016.12.16.00.47.31 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 16 Dec 2016 00:47:31 -0800 (PST) To: ace@ietf.org, rturner@amalfisystems.com References: From: Ludwig Seitz Message-ID: Date: Fri, 16 Dec 2016 09:47:17 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms010501080500090701060102" Archived-At: Subject: Re: [Ace] attribute based access control X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Dec 2016 08:47:38 -0000 This is a cryptographically signed message in MIME format. --------------ms010501080500090701060102 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable On 2016-12-16 07:28, Randy Turner wrote: > HI, > > I was looking at draft-ietf-ace-oauth-authz-04, specifically the > client-to-AS section =E2=80=94 I am trying to determine if it is possib= le to > use this OAUTH-based model to implement attribute-based authorization > (ABAC). The client-to-AS section of this draft refers the reader to > section 4 of RFC 6749, which provides a =E2=80=9Cclient-id=E2=80=9D (go= od) and a > =E2=80=9Cscope=E2=80=9D to include in an authorization request. > In addition, it looks like the ACE draft adds to this the =E2=80=9Caud=E2= =80=9D and > =E2=80=9Ccnf=E2=80=9D parameters. > > I=E2=80=99m trying to map this client-to-AS request to a traditional AB= AC > authorization request which asks the question =E2=80=9CIdentity wan= ts to > perform action on resource =E2=80=9D =E2=80=A6 is this allowed ?= (allow/deny > response) > > In one of the ACE draft examples, it uses the =E2=80=9Caud=E2=80=9D fie= ld to include > the name of a sensor =E2=80=9CtempSensor4711=E2=80=9D - this could be = the =E2=80=9Cresource=E2=80=9D > of the ABAC request, and the =E2=80=9Cclient ID=E2=80=9D (RFC 6749) cou= ld be the > =E2=80=9Cidentity=E2=80=9D > > I=E2=80=99m missing the type of operation or =E2=80=9Caction=E2=80=9D t= hat the client is > trying to perform on a resource (=E2=80=9Cread=E2=80=9D, =E2=80=9Cwrite= =E2=80=9D, =E2=80=9Csomething else, > hopefully extensible=E2=80=9D) =E2=80=94 would this be the =E2=80=9Csco= pe=E2=80=9D parameter ? > > I did see section 8.2 of the draft where it discusses a registry of > parameters which might allow additional parameters to a client-to-AS > request, but I was looking for a way to do ABAC without having to > register anything. > > I=E2=80=99m specifically asking about obtaining an access token to be u= sed > later by a client accessing the actual resource. > > Has anyone tried combining draft-ietf-ace-oauth-authz-04 with ABAC > systems ? Yes I have. My approach is the following: I use the OAuth client credentials grant flow to request an access=20 token, and then I use an XACML engine internally on the AS to decide on=20 access token requests base on the client's credentials and the "scope"=20 and "aud" parameters of the access token request. When it comes to extracting an action and a resource from an access=20 token request, my understanding is that the scope parameter actually=20 gives you both in an application specific way. If you look at the examples of how scope is used in=20 https://www.brandur.org/oauth-scope you can see that e.g. LinkedIn uses=20 some kind of capability-like format for their scope parameters=20 (r_basicprofile r_emailaddress rw_groups w_messages). Thus you could=20 extract the action and the resource from scope with an application=20 specific processing module. You could also have a look at https://tools.ietf.org/html/draft-bormann-core-ace-aif-03 which defines a CoAP specific capability format. I was considering to=20 use that as values for the scope in CoAP-specific scenarios. I would be happy to hear your take on this and discuss the issue in more = detail. Regards, Ludwig --=20 Ludwig Seitz, PhD SICS Swedish ICT AB Ideon Science Park, Building Beta 2 Scheelev=C3=A4gen 17, SE-223 70 Lund Phone +46(0)70-349 92 51 The RISE institutes SP, Swedish ICT and Innventia are merging in order to create a unified institute sector and become a stronger innovation partner for businesses and society. At the end of the year we will change our name to RISE. Read more at www.ri.se/en/about-rise --------------ms010501080500090701060102 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CtQwggTqMIID0qADAgECAhAU4QcxMULaotNy8Yzm2pESMA0GCSqGSIb3DQEBCwUAMHUxCzAJ BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGll bnQgQ0EwHhcNMTYwMzE0MDkzNDMyWhcNMTcwMzE0MDkzNDMyWjA4MRcwFQYDVQQDDA5sdWR3 aWdAc2ljcy5zZTEdMBsGCSqGSIb3DQEJARYObHVkd2lnQHNpY3Muc2UwggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQC9kgmm82Op78D9DXYNJrQW5bUdSxElnOC/CzAK/enHn+uF B/RLo8alI6Ukd35qsAtcje0I3e/RtbkRnkEuhKneH+aDRofy7YaWQO61CjIlcdndTx8FEmXK /swcafYX5PbyzQFGgApwtWFkVXcq3R87CDB3VbkHzTHIBmfwZ4hhDeEyuJoSuWEVWQppfTji /GpVLiDx6s+Zqm3qI5EkjvhQ+jX3tJxXqUf4w1BY6/sBLfvr7TOPGPoAmi6B2UOgyDSfX3c0 +jzlYFLNb6Eqc7uGvaQi7VN39kAJXz9f+qL/wokaNjboK3/JyTG/ikxsWymzO9E0/U9apn2Y z5SVUGSDAgMBAAGjggGxMIIBrTAOBgNVHQ8BAf8EBAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUH AwIGCCsGAQUFBwMEMAkGA1UdEwQCMAAwHQYDVR0OBBYEFN37NX1Db3Xp23cbQI1MpYPUMw84 MB8GA1UdIwQYMBaAFCSBbDlhvkkPj7cbRivJKLUnSG1oMG8GCCsGAQUFBwEBBGMwYTAkBggr BgEFBQcwAYYYaHR0cDovL29jc3Auc3RhcnRzc2wuY29tMDkGCCsGAQUFBzAChi1odHRwOi8v YWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9zY2EuY2xpZW50MS5jcnQwOAYDVR0fBDEwLzAtoCug KYYnaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2NhLWNsaWVudDEuY3JsMBkGA1UdEQQSMBCB Dmx1ZHdpZ0BzaWNzLnNlMCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzBG BgNVHSAEPzA9MDsGCysGAQQBgbU3AQIEMCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3Rh cnRzc2wuY29tL3BvbGljeTANBgkqhkiG9w0BAQsFAAOCAQEAUy78MN+soYHwIz+6m9mMkzPF KfgIq7sLupWnis7K5U66U9zfKOVDReyfUvPmar7P7Tb9uNNrUlkk3lSISplqU30TMnVbtK5D I0mxdpa1hZxIAa8uWQnAh/oYJJYaMziKxpZgsUjel6/ZnD0z/QsuHo763I1boi2ghe4Knj0f qFO79ErRr9aJJBfQlFVwQ4gRoYtMz18/usC3eqGxFz8a/LCeRMWeZJagGJ/St1WW1HUBmMFd vRFweeUdCvDbzK+WjqbxhXyi7b0sH65lWIjINCBVQ0AvqOwm/aXEWcIQlAIJjr2kEC6c0VY6 V1aP16BAKooEgGGOTrmcDGeteXZRyjCCBeIwggPKoAMCAQICEGunin0K14jWUQr5WeTntOEw DQYJKoZIhvcNAQELBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4x KzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMT IFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTE1MTIxNjAxMDAwNVoXDTMw MTIxNjAxMDAwNVowdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAn BgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFy dENvbSBDbGFzcyAxIENsaWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB AL192vfDon2D9luC/dtbX64eG3XAtRmvmCSsu1d52DXsCR58zJQbCtB2/A5uFqNxWacpXGGt TCRk9dEDBlmixEd8QiLkUfvHpJX/xKnmVkS6Iye8wUbYzMsDzgnpazlPg19dnSqfhM+Cevdf a89VLnUztRr2cgmCfyO9Otrh7LJDPG+4D8ZnAqDtVB8MKYJL6QgKyVhhaBc4y3bGWxKyXEtx 7QIZZGxPwSkzK3WIN+VKNdkiwTubW5PIdopmykwvIjLPqbJK7yPwFZYekKE015OsW6FV+s4D IM8UlVS8pkIsoGGJtMuWjLL4tq2hYQuuN0jhrxK1ljz50hH23gA9cbMCAwEAAaOCAWQwggFg MA4GA1UdDwEB/wQEAwIBBjAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0T AQH/BAgwBgEB/wIBADAyBgNVHR8EKzApMCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNv bS9zZnNjYS5jcmwwZgYIKwYBBQUHAQEEWjBYMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5z dGFydHNzbC5jb20wMAYIKwYBBQUHMAKGJGh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRz L2NhLmNydDAdBgNVHQ4EFgQUJIFsOWG+SQ+PtxtGK8kotSdIbWgwHwYDVR0jBBgwFoAUTgvv GqRAW6UXaYcwyjRoQ9BBrvIwPwYDVR0gBDgwNjA0BgRVHSAAMCwwKgYIKwYBBQUHAgEWHmh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeTANBgkqhkiG9w0BAQsFAAOCAgEAi+P3h+wB i4StDwECW5zhIycjBL008HACblIf26HY0JdOruKbrWDsXUsiI0j/7Crft9S5oxvPiDtVqspB OB/y5uzSns1lZwh7sG96bYBZpcGzGxpFNjDmQbcM3yl3WFIRS4WhNrsOY14V7y2IrUGsvets D+bjyOngCIVeC/GmsmtbuLOzJ606tEc9uRbhjTu/b0x2Fo+/e7UkQvKzNeo7OMhijixaULyI NBfCBJb+e29bLafgu6JqjOUJ9eXXj20p6q/CW+uVrZiSW57+q5an2P2i7hP85jQJcy5j4HzA 0rSiF3YPhKGAWUxKPMAVGgcYoXzWydOvZ3UDsTDTagXpRDIKQLZo02wrlxY6iMFqvlzsemVf 1odhQJmi7Eh5TbxI40kDGcBOBHhwnaOumZhLP+SWJQnjpLpSlUOj95uf1zo9oz9e0NgIJoz/ tdfrBzez76xtDsK0KfUDHt1/q59BvDI7RX6gVr0fQoCyMczNzCTcRXYHY0tq2J0oT+bsb6sH 2b4WVWAiJKnSYaWDjdA70qHX4mq9MIjO/ZskmSY8wtAk24orAc0vwXgYanqNsBX5Yv4sN4Z9 VyrwMdLcusP7HJgRdAGKpkR2I9U4zEsNJQJewM7S4Jalo1DyPrLpL2nTET8ZrSl5Utp1UeGp /2deoprGevfnxWB+vHNQiu85o6MxggPMMIIDyAIBATCBiTB1MQswCQYDVQQGEwJJTDEWMBQG A1UEChMNU3RhcnRDb20gTHRkLjEpMCcGA1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBB dXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0Q29tIENsYXNzIDEgQ2xpZW50IENBAhAU4QcxMULa otNy8Yzm2pESMA0GCWCGSAFlAwQCAQUAoIICEzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcB MBwGCSqGSIb3DQEJBTEPFw0xNjEyMTYwODQ3MTdaMC8GCSqGSIb3DQEJBDEiBCAwEuIUVl3r PUhZXdrzqFbnTOIga2qkLUL5JRckL7PfvDBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQB KjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMC AgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkG A1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENl cnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVu dCBDQQIQFOEHMTFC2qLTcvGM5tqREjCBnAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRp ZmljYXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBD QQIQFOEHMTFC2qLTcvGM5tqREjANBgkqhkiG9w0BAQEFAASCAQBOwe5Z2VOkXldyuEYu6qUm BDsY8KGbqG+7letWPttcifP++Ln2QEM7wlXnrwhDmQb4k9jEDyACgyx3DXq6pQs/XTCDD4EF NIa+BNHZbj5hRpieBBHr/fITr9OfBwuO9BgViFwW7ajQPCPWSUnraH+njDdWhGfY6b6VWs/8 uy9Gw8VrX2uAT25u0+unfrH8Lt5+Q8Js8AyLhue83fe4zktMix4+JY4+KTvOtLncY9p4ajeL CbEm5It2zxhDSuBSTfXW7rI9UFCJKD+s5g69Qso5jH5c6vlntM90zAB42ZjRizAT7UdUPuMR Fusz1X/hxIfcjKfeBz2lPPahKku7OyZzAAAAAAAA --------------ms010501080500090701060102-- From nobody Thu Dec 22 00:42:57 2016 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34A30129420 for ; Thu, 22 Dec 2016 00:42:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.622 X-Spam-Level: X-Spam-Status: No, score=-17.622 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 PLyBSL88iWV9 for ; Thu, 22 Dec 2016 00:42:54 -0800 (PST) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DE1601294CE for ; Thu, 22 Dec 2016 00:42:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2249; q=dns/txt; s=iport; t=1482396174; x=1483605774; h=to:from:subject:message-id:date:mime-version; bh=W3J5USoDKlBnAoKvY2obj8+BeMpgzsuyCIhHOHMrWik=; b=UNVjPhFby4kqbL8lLMRGUdhAbykM4jGfbPosfnZxrS7Q5OKZGRXJGTcM rL6sr5PtQqEzaq2WaiM78RI1lzY0nFbuUoPmnZqOHtZCDotzq6bhiNBng 8zvbz+08MgIAlpFfEdqyrtXuQX0WtQVJKYa7z8inTFtTW8kaPD3NYuiUx k=; X-Files: signature.asc : 481 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CVAwAAkVtY/xbLJq1eGwEBAQMBAQEJA?= =?us-ascii?q?QEBgzUBAQEBAY9UcqpyggmISRQBAgEBAQEBAQFiHQuFEkkKYAJfDQgBAYhomQK?= =?us-ascii?q?QAIIoiwIBAQgCARYPiDMIihiCXQWad4NjgXyLWooihi+SMx83MVYWDYYQPYkOA?= =?us-ascii?q?QEB?= X-IronPort-AV: E=Sophos;i="5.33,387,1477958400"; d="asc'?scan'208";a="648085807" Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 22 Dec 2016 08:42:49 +0000 Received: from [10.61.231.33] ([10.61.231.33]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id uBM8gnA1004145 for ; Thu, 22 Dec 2016 08:42:49 GMT To: "Ace@ietf.org" From: Eliot Lear Message-ID: Date: Thu, 22 Dec 2016 09:42:48 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="jt5QqWP2cjfdkHhKXvU8NVhhcA1A8M13g" Archived-At: Subject: [Ace] where are we with draft-somarju-ace-multicast? X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Dec 2016 08:42:56 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --jt5QqWP2cjfdkHhKXvU8NVhhcA1A8M13g Content-Type: multipart/mixed; boundary="w6Phx4XRTFU5xS0buIr48g5GWp2aHX17b"; protected-headers="v1" From: Eliot Lear To: "Ace@ietf.org" Message-ID: Subject: where are we with draft-somarju-ace-multicast? --w6Phx4XRTFU5xS0buIr48g5GWp2aHX17b Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi, This working group has been in a state of indecision about this draft for quite some time and I would like to gain some clarity on the matter. On the one hand, we have a draft that there seems to be unanimous agreement would be useful to the lighting people. On the other hand, we have some concern that the draft might be misapplied to environments where PSK/symmetric keys should not be employed.=20 As Hannes wrote, security is not a black and white matter. We need to acknowledge that fact. This, to me, seems to boil down to an applicability statement.=20 On the matter of status, it is not appropriate to release this as an experiment. People want to code, release that code and see their customers use that code. This is precisely what a proposed standard is f= or. I would like to see this draft adopted by the working group, an appropriate applicability statement added, and see it shipped. Eliot --w6Phx4XRTFU5xS0buIr48g5GWp2aHX17b-- --jt5QqWP2cjfdkHhKXvU8NVhhcA1A8M13g Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2 iQEcBAEBCAAGBQJYW5IJAAoJEIe2a0bZ0nozBPsH/24vvwS/d7mp8SaSHKDNEWbr c0fTU/i71udW+S5lvLBGf5KH25fU0s6jjcyaTOU9ruMAHoeLVKVY/Ezm/1FKduFA YmFWlCQCX6uwhIQ92Pv/cSPnjPwCKvcSNXKCvcjXbhwnuqPGoJ0lYdq3Os4wF2pI obVgJqbQKIcAHWDuN6Q61+x0htFUCSmAleuKPjNousUIDj1B7CzWWcQuXJ9m/ve1 Z7xzoRcjlDD9CgTYL3PFD04YyoKcJIxvkyciy61Q/n3/M8Ad87lAr6ZePNA82BRG hwVvjSIkR2gE4wuSPg0wEXVq/Uz19OnhXpjeUzLHoYIm4iwgxr9gUmp0ck2yi/k= =XmC7 -----END PGP SIGNATURE----- --jt5QqWP2cjfdkHhKXvU8NVhhcA1A8M13g-- From nobody Thu Dec 22 01:17:04 2016 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDFB51294EC for ; Thu, 22 Dec 2016 01:17:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=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 brMB06gX6zhV for ; Thu, 22 Dec 2016 01:17:01 -0800 (PST) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DDC1B127076 for ; Thu, 22 Dec 2016 01:17:00 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [134.102.201.11]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id uBM9GrsZ009791; Thu, 22 Dec 2016 10:16:53 +0100 (CET) Received: from [192.168.217.102] (p5DC7E34C.dip0.t-ipconnect.de [93.199.227.76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3tkm9x4HcPz8L1P; Thu, 22 Dec 2016 10:16:53 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Carsten Bormann In-Reply-To: Date: Thu, 22 Dec 2016 10:16:52 +0100 X-Mao-Original-Outgoing-Id: 504091012.21247-b6501a88ee85ab9ea6fa0a8fb3adba1c Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Eliot Lear X-Mailer: Apple Mail (2.3259) Archived-At: Cc: "Ace@ietf.org" Subject: Re: [Ace] where are we with draft-somarju-ace-multicast? X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Dec 2016 09:17:03 -0000 On 22 Dec 2016, at 09:42, Eliot Lear wrote: >=20 > I would like to see this draft adopted by the working group, an > appropriate applicability statement added, and see it shipped. +1 (Everything has been said already that needs to be said about the = issue.) Gr=C3=BC=C3=9Fe, Carsten From nobody Thu Dec 22 14:36:05 2016 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 160511298A0 for ; Thu, 22 Dec 2016 14:36:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.799 X-Spam-Level: X-Spam-Status: No, score=-5.799 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-3.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.net 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 rp1mLwpc2Jjv for ; Thu, 22 Dec 2016 14:36:02 -0800 (PST) Received: from resqmta-ch2-01v.sys.comcast.net (resqmta-ch2-01v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:33]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 563B61295EA for ; Thu, 22 Dec 2016 14:36:02 -0800 (PST) Received: from resomta-ch2-16v.sys.comcast.net ([69.252.207.112]) by resqmta-ch2-01v.sys.comcast.net with SMTP id KBxgc4TvjRNZDKBxxchJvt; Thu, 22 Dec 2016 22:36:01 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20161114; t=1482446161; bh=WqcPPsKZ+iarxedFlW9Sxjzgb8kkcWwCB3YMb2F9MTg=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=GWM4ZvZkLOGx/hQzrFIOXmLVFOzpOOV3HGP7M+eDfjoJj4QQzM9pqXi9xksg+vb/W vXKW9jLMsuQ6IGlYuQwxB2+xlgq3vCtEB1zjYF3LfSRWSAAQxH3G3AEIGmHzj6DkXb eW+JivXR8tU7Ev7ulqlLNyIEMusrFlR4Yrsj5mbGREq1fUnQ//o8xdB0SUUwjDEBhh F63fDCqrNkW0b25L4/FlcQm7YpMd25YqqAEqtd2gz1LEkARtVW7/faF5jgsFd5/0MZ QerJYZMK/AHGHchCY4sUa4vbDXk31RsG29hydgpi2No1yzApcDSOjHYIJ4SROhc817 s0tjq8llqlN7Q== Received: from [IPv6:2601:152:4400:9b5f:c8f0:67e5:88b1:2975] ([IPv6:2601:152:4400:9b5f:c8f0:67e5:88b1:2975]) by resomta-ch2-16v.sys.comcast.net with SMTP id KBxwc8DIrR8oyKBxxc30pv; Thu, 22 Dec 2016 22:36:01 +0000 To: ace@ietf.org References: From: Michael StJohns Message-ID: Date: Thu, 22 Dec 2016 17:36:12 -0500 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------D08FCABBC075252D34209E6C" X-CMAE-Envelope: MS4wfKOjG4NORp4kKB+C3u8MZiiQXoq82MgJRUigH8RbmSuaYcPoxePa/zzhAmVEfqNe5HDEGgFmYEwTCsZyOr2A/hxRNT3YK+CThUbjdqbNarkdgZSuz1KM xrctzxja9SoHXKrsqGuo9hk8jLNHo4dYyIUaDmI4z918u+/eZrj5GuVtW40/0NjJmZYiXSeSlAiB7A== Archived-At: Subject: Re: [Ace] where are we with draft-somarju-ace-multicast? X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Dec 2016 22:36:04 -0000 This is a multi-part message in MIME format. --------------D08FCABBC075252D34209E6C Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit On 12/22/2016 3:42 AM, Eliot Lear wrote: > Hi, > > This working group has been in a state of indecision about this draft > for quite some time and I would like to gain some clarity on the matter. > > On the one hand, we have a draft that there seems to be unanimous > agreement would be useful to the lighting people. Actually, we have a draft that the lighting people unanimously agree that would be useful to the lighting people. Not quite the same thing. And, as I've said before, if this is ONLY applicable to the lighting people then they should go off and write an Informational "Here's how we do it" document and not try for an internet standard. > On the other hand, we > have some concern that the draft might be misapplied to environments > where PSK/symmetric keys should not be employed. > > As Hannes wrote, security is not a black and white matter. We need to > acknowledge that fact. This, to me, seems to boil down to an > applicability statement. I don't know why people think I'm just going to let things pass without trying to inject some rigor. My last question: What is the security requirement for an ACE Group comm protocol? My current minimum bid: Compromise of a single device shall not result in the attacker gaining privileges over the group greater than those nominally granted to the device being attacked. or less nuanced: Compromise of a single device shall not result in the compromise of the entire group. I asked the above question a month ago in response to Hannes' email and received no answer. None. As far as I can glean from the discussion (this one and the 2 year one in DTLS), the current answer from the lighting folk to "What is the security requirement" is "we don't really care as long it is weak enough that we don't have to pay for hardware or endure latency for validation so we can use this fundamentally insecure symmetric key group system". I apologize if that's unfair, but I literally haven't been able to find ANY indication that there's any consideration in selecting the "security" solution than this. And as far as I can tell, that means that their security requirement is the empty set - which is sort of an appropriate name for security theater. Can ANYONE provide me with a parseable and non-empty security requirement for symmetric key group communications? > > On the matter of status, it is not appropriate to release this as an > experiment. People want to code, release that code and see their > customers use that code. This is precisely what a proposed standard is for. For an "ACE Group comm" protocol, it has to be generally applicable to the ACE space, and not just this this tiny hardware and cost constrained corner. An Informational RFC by the lighting folk provided as whole cloth is the appropriate approach - not an internet standard in any way shape or form. > > I would like to see this draft adopted by the working group, an > appropriate applicability statement added, and see it shipped. I would like a security group to actually produce secure protocols. I'm not even sure this approach is applicable to the lighting scenario in any meaningful way. Mike > > Eliot > > > > > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace --------------D08FCABBC075252D34209E6C Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit


On 12/22/2016 3:42 AM, Eliot Lear wrote:
Hi,

This working group has been in a state of indecision about this draft
for quite some time and I would like to gain some clarity on the matter.

On the one hand, we have a draft that there seems to be unanimous
agreement would be useful to the lighting people.
Actually, we have a draft that the lighting people unanimously agree that would be useful to the lighting people.  Not quite the same thing.

And, as I've said before, if this is ONLY applicable to the lighting people then they should go off and write an Informational "Here's how we do it" document and not try for an internet standard.

On the other hand, we
have some concern that the draft might be misapplied to environments
where PSK/symmetric keys should not be employed. 

As Hannes wrote, security is not a black and white matter.  We need to
acknowledge that fact.  This, to me, seems to boil down to an
applicability statement.

I don't know why people think I'm just going to let things pass without trying to inject some rigor.

My last question:  What is the security requirement for an ACE Group comm protocol?

My current minimum bid:  Compromise of a single device shall not result in the attacker gaining privileges over the group greater than those nominally granted to the device being attacked.  or less nuanced:  Compromise of a single device shall not result in the compromise of the entire group. 

I asked the above question a month ago in response to Hannes' email and received no answer.  None.

As far as I can glean from the discussion (this one and the 2 year one in DTLS), the current answer from the lighting folk to "What is the security requirement" is "we don't really care as long it is weak enough that we don't have to pay for hardware or endure latency for validation so we can use this fundamentally insecure symmetric key group system".  I apologize if that's unfair, but I literally haven't been able to find ANY indication that there's any consideration in selecting the "security" solution than this.

And as far as I can tell, that means that their security requirement is the empty set - which is sort of an appropriate name for security theater.

Can ANYONE provide me with a parseable and non-empty security requirement for symmetric key group communications?


On the matter of status, it is not appropriate to release this as an
experiment.  People want to code, release that code and see their
customers use that code.  This is precisely what a proposed standard is for.

For an "ACE Group comm" protocol, it has to be generally applicable to the ACE space, and not just this this tiny hardware and cost constrained corner. An Informational RFC by the lighting folk provided as whole cloth is the appropriate approach - not an internet standard in any way shape or form.


I would like to see this draft adopted by the working group, an
appropriate applicability statement added, and see it shipped.

I would like a security group to actually produce secure protocols.   I'm not even sure this approach is applicable to the lighting scenario in any meaningful way.

Mike


--------------D08FCABBC075252D34209E6C-- From nobody Fri Dec 23 00:24:34 2016 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 728BA1299A3 for ; Fri, 23 Dec 2016 00:24:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.622 X-Spam-Level: X-Spam-Status: No, score=-17.622 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 7ts7BPtNF6l0 for ; Fri, 23 Dec 2016 00:24:31 -0800 (PST) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F3B0B1299A2 for ; Fri, 23 Dec 2016 00:24:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4128; q=dns/txt; s=iport; t=1482481471; x=1483691071; h=subject:to:references:from:message-id:date:mime-version: in-reply-to; bh=fwXxU9rNePyPs/KpEL+zrKTmdnMQnUrWfQXFWvXOMZg=; b=UjbS5tmiUz5wH3xTIZgbFymrp3+Sg8bXCKKldMkp6TNlkGlfUS2i8O4j SxNmxwwraSMH3uujR0mYO1q+AaASlC9nNdKxjmShMQQZdR7yiR2RAN59Q GpNlfJmJ0loutHzbEuynwoP4ns/EzYVIBwHMJf+tsj/QBeOl1G1yoSzL+ Y=; X-Files: signature.asc : 481 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DcBQAK3lxY/xbLJq1eGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgzcBAQEBAYErII4NcpVflReCCYYiAoIxFAECAQEBAQEBAWIohGg?= =?us-ascii?q?BAQEDASNJCggLCxgqAgJXBgEMCAEBiGMIqz6CJ4p+AQEBAQEBAQMBAQEBAQEBE?= =?us-ascii?q?g+ISoJghDCDHoJdBZp5g2OBfYtciiWGL44qhA8fNwGBBxYNhBYcgV49iTwBAQE?= X-IronPort-AV: E=Sophos;i="5.33,392,1477958400"; d="asc'?scan'208";a="650985233" Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 23 Dec 2016 08:24:28 +0000 Received: from [10.61.229.102] ([10.61.229.102]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id uBN8OSGR031319; Fri, 23 Dec 2016 08:24:28 GMT To: Michael StJohns , ace@ietf.org References: From: Eliot Lear Message-ID: <062dd7b2-48a8-ba6c-e80a-0e8f309bf12e@cisco.com> Date: Fri, 23 Dec 2016 09:24:27 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="o8NjThOMLVCIFd6wO5eAp7UCWRsrITa6w" Archived-At: Subject: Re: [Ace] where are we with draft-somarju-ace-multicast? X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Dec 2016 08:24:33 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --o8NjThOMLVCIFd6wO5eAp7UCWRsrITa6w Content-Type: multipart/mixed; boundary="fND6UhopmmoTACAKm3EHV5n0bvoI0Wrvw"; protected-headers="v1" From: Eliot Lear To: Michael StJohns , ace@ietf.org Message-ID: <062dd7b2-48a8-ba6c-e80a-0e8f309bf12e@cisco.com> Subject: Re: [Ace] where are we with draft-somarju-ace-multicast? References: In-Reply-To: --fND6UhopmmoTACAKm3EHV5n0bvoI0Wrvw Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 12/22/16 11:36 PM, Michael StJohns wrote: > > > On 12/22/2016 3:42 AM, Eliot Lear wrote: >> Hi, >> >> This working group has been in a state of indecision about this draft >> for quite some time and I would like to gain some clarity on the matte= r. >> >> On the one hand, we have a draft that there seems to be unanimous >> agreement would be useful to the lighting people. =20 > Actually, we have a draft that the lighting people unanimously agree > that would be useful to the lighting people. Not quite the same thing.= > No, even you have previously conceded that this use case is fine. > And, as I've said before, if this is ONLY applicable to the lighting > people then they should go off and write an Informational "Here's how > we do it" document and not try for an internet standard. It's not. Lighting is not the only highly constrained case where low power budget and low latency requirements will make public key operations expensive. It just happens to be leading the path. > >> On the other hand, we >> have some concern that the draft might be misapplied to environments >> where PSK/symmetric keys should not be employed.=20 >> >> As Hannes wrote, security is not a black and white matter. We need to= >> acknowledge that fact. This, to me, seems to boil down to an >> applicability statement.=20 > > I don't know why people think I'm just going to let things pass > without trying to inject some rigor. > > My last question: What is the security requirement for an ACE Group > comm protocol? The answer should be as it always was: make things better. The current alternative is nothing, which is what happens today, and well beyond lighting. The current draft provides for use of asymmetric keying for group admission. Beyond that, the choices are pretty stark: perform an symmetric operation on every transaction or use a group key. > > My current minimum bid: Compromise of a single device shall not > result in the attacker gaining privileges over the group greater than > those nominally granted to the device being attacked. or less > nuanced: Compromise of a single device shall not result in the > compromise of the entire group.=20 And here's mine: The group must be treated as a single device, for purpose of compromise, barring additional measures being taken at other layers. The advantage of this over status quo is that today admission is open, and the threat surface is therefore unconstrained. With this approach the threat surface is reduced to other infected group members. Eliot --fND6UhopmmoTACAKm3EHV5n0bvoI0Wrvw-- --o8NjThOMLVCIFd6wO5eAp7UCWRsrITa6w Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2 iQEcBAEBCAAGBQJYXN88AAoJEIe2a0bZ0nozBJ8IAMUXdqaeMSjGa7eeFtES+1tO H4FeXsmrSO7h2w2ObL1xheg3fb1dNge7aszExb6t5CEzWUgoAI8aKS+qC3R3lYCm sofUik+eT9mWnK41RFaIQwYPPd1CclBnF4mrT2obJtaXBNx62NWuwHz8k0Z69Ynn KtVETewJjbFM0qh9SR6mSLSMeAzcLOkW6cyVXzhKyfUC0HU9SkKLS4BadIl69kbB +9MszozLScqxh7KLeF3SC+M2vFj9T7KfCz/ZrwpDBtxdADfkc1JhQCg9OmpmnwOe HK/y2CrBwtw/A7Dot0ZZbkFzNfkBMlFoQ7ZVAoVfVgp18/87FG44mvyZSIRuBCw= =76IG -----END PGP SIGNATURE----- --o8NjThOMLVCIFd6wO5eAp7UCWRsrITa6w-- From nobody Fri Dec 23 00:29:02 2016 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF3CA1294AE for ; Fri, 23 Dec 2016 00:29:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=sics.se 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 QhKAyN7yhqa2 for ; Fri, 23 Dec 2016 00:28:58 -0800 (PST) Received: from mail-lf0-x22a.google.com (mail-lf0-x22a.google.com [IPv6:2a00:1450:4010:c07::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E083D12946E for ; Fri, 23 Dec 2016 00:28:57 -0800 (PST) Received: by mail-lf0-x22a.google.com with SMTP id y21so133818485lfa.1 for ; Fri, 23 Dec 2016 00:28:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sics.se; s=google; h=to:from:subject:message-id:date:user-agent:mime-version; bh=cuNxuarORF5oEmT/1Nsj4rQetCnkq+pWH3BhUi8m8/4=; b=N1OQa+Pz5+x5TVYPFA9DYvBQcrdCqBCKUGXCmWtvA8WgnFQeWmYH8Bdezz96Ho7fvQ rzbzKck2eckuiib/q22nizOOzdgBck9Ar5PKcz1mgMcNLO3KCV7LZWmF4jpXaveUFcvD yeskZgwu3HNXuE99bY03QnFgMpUx4PptV8d5oL6cG3gy3Cvn7if9cbnRyPaS1AJGhpWe U6VGIe+JVP7mfGcJiKln4IpLC7H2pRz0iS8JnGCb/dfyTbE0vros/0LgAeoY8AoHRG8T LkW2v/PE7GLuZ2lrcE9/fSLqSjykQS8xIXAxkWwopwtnfsrT6GvoT4ASxus9RreF/GbQ iWaQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:subject:message-id:date:user-agent :mime-version; bh=cuNxuarORF5oEmT/1Nsj4rQetCnkq+pWH3BhUi8m8/4=; b=bRrHaEQV6ty6VCn1WoVVIpyC3+A3T+5dB1FMfuPlPE4bSPWuZGQIZojY2KCuebvXZt h6oWHUKr86A3+sJP+1+rBZXbt5dEGTvDO2R+zcTG9eJH0BHwkadd1xFxyKDPHVCaytGf mWvqDIKjqJvQ3W8lwF3hDrhjeEF7uP2oUwhjmMPykeVEcr/OJHU4sH4S7GaQmoyu9tY+ uCnR6wLC2++GmvFKpSbbB2G42uosVgqjeCQdE6umDUmPtCv5nsDy6ibxm0ZD2BZIRJ8j xLDsbBmWUvtoYSC1kzFDF5T0MCxlf5LANzjhWMz5TeGqblrTvr6AhgNl9Z2UybNtkIFm BVkA== X-Gm-Message-State: AIkVDXJEI4iYasb4jL0AdzDCfcWlVBRsZ0lKvPuiqWgG9bPusdeXwtq3UHMwiWPcHFQWsYFR X-Received: by 10.25.221.65 with SMTP id u62mr3176276lfg.52.1482481735705; Fri, 23 Dec 2016 00:28:55 -0800 (PST) Received: from [192.168.0.166] ([85.235.12.155]) by smtp.gmail.com with ESMTPSA id v9sm7658487lja.0.2016.12.23.00.28.54 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 23 Dec 2016 00:28:54 -0800 (PST) To: "ace@ietf.org" From: Ludwig Seitz Message-ID: <6948f417-1972-4f9b-5b85-9e0daff9e971@sics.se> Date: Fri, 23 Dec 2016 09:28:54 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms010703040104030203040702" Archived-At: Subject: [Ace] Code for draft-ietf-ace-oauth-authz X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Dec 2016 08:29:01 -0000 This is a cryptographically signed message in MIME format. --------------ms010703040104030203040702 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Hello, as a little Christmas present, here is some code implementing parts of=20 draft-ietf-ace-oauth-authz: https://bitbucket.org/lseitz/ace-java It is still in an early stage of development, missing code for the=20 client side and probably has a good dose of errors left in it, but=20 hopefully it is useful anyways. Node that this is Java code, so it's not aimed at constrained devices.=20 We (SICS) will work on code for constrained devices next year. /Ludwig --=20 Ludwig Seitz, PhD SICS Swedish ICT AB Ideon Science Park, Building Beta 2 Scheelev=C3=A4gen 17, SE-223 70 Lund Phone +46(0)70-349 92 51 The RISE institutes SP, Swedish ICT and Innventia are merging in order=20 to create a unified institute sector and become a stronger innovation=20 partner for businesses and society. At the end of the year we will=20 change our name to RISE. Read more at www.ri.se/en/about-rise --------------ms010703040104030203040702 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CtQwggTqMIID0qADAgECAhAU4QcxMULaotNy8Yzm2pESMA0GCSqGSIb3DQEBCwUAMHUxCzAJ BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGll bnQgQ0EwHhcNMTYwMzE0MDkzNDMyWhcNMTcwMzE0MDkzNDMyWjA4MRcwFQYDVQQDDA5sdWR3 aWdAc2ljcy5zZTEdMBsGCSqGSIb3DQEJARYObHVkd2lnQHNpY3Muc2UwggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQC9kgmm82Op78D9DXYNJrQW5bUdSxElnOC/CzAK/enHn+uF B/RLo8alI6Ukd35qsAtcje0I3e/RtbkRnkEuhKneH+aDRofy7YaWQO61CjIlcdndTx8FEmXK /swcafYX5PbyzQFGgApwtWFkVXcq3R87CDB3VbkHzTHIBmfwZ4hhDeEyuJoSuWEVWQppfTji /GpVLiDx6s+Zqm3qI5EkjvhQ+jX3tJxXqUf4w1BY6/sBLfvr7TOPGPoAmi6B2UOgyDSfX3c0 +jzlYFLNb6Eqc7uGvaQi7VN39kAJXz9f+qL/wokaNjboK3/JyTG/ikxsWymzO9E0/U9apn2Y z5SVUGSDAgMBAAGjggGxMIIBrTAOBgNVHQ8BAf8EBAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUH AwIGCCsGAQUFBwMEMAkGA1UdEwQCMAAwHQYDVR0OBBYEFN37NX1Db3Xp23cbQI1MpYPUMw84 MB8GA1UdIwQYMBaAFCSBbDlhvkkPj7cbRivJKLUnSG1oMG8GCCsGAQUFBwEBBGMwYTAkBggr BgEFBQcwAYYYaHR0cDovL29jc3Auc3RhcnRzc2wuY29tMDkGCCsGAQUFBzAChi1odHRwOi8v YWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9zY2EuY2xpZW50MS5jcnQwOAYDVR0fBDEwLzAtoCug KYYnaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2NhLWNsaWVudDEuY3JsMBkGA1UdEQQSMBCB Dmx1ZHdpZ0BzaWNzLnNlMCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzBG BgNVHSAEPzA9MDsGCysGAQQBgbU3AQIEMCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3Rh cnRzc2wuY29tL3BvbGljeTANBgkqhkiG9w0BAQsFAAOCAQEAUy78MN+soYHwIz+6m9mMkzPF KfgIq7sLupWnis7K5U66U9zfKOVDReyfUvPmar7P7Tb9uNNrUlkk3lSISplqU30TMnVbtK5D I0mxdpa1hZxIAa8uWQnAh/oYJJYaMziKxpZgsUjel6/ZnD0z/QsuHo763I1boi2ghe4Knj0f qFO79ErRr9aJJBfQlFVwQ4gRoYtMz18/usC3eqGxFz8a/LCeRMWeZJagGJ/St1WW1HUBmMFd vRFweeUdCvDbzK+WjqbxhXyi7b0sH65lWIjINCBVQ0AvqOwm/aXEWcIQlAIJjr2kEC6c0VY6 V1aP16BAKooEgGGOTrmcDGeteXZRyjCCBeIwggPKoAMCAQICEGunin0K14jWUQr5WeTntOEw DQYJKoZIhvcNAQELBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4x KzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMT IFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTE1MTIxNjAxMDAwNVoXDTMw MTIxNjAxMDAwNVowdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAn BgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFy dENvbSBDbGFzcyAxIENsaWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB AL192vfDon2D9luC/dtbX64eG3XAtRmvmCSsu1d52DXsCR58zJQbCtB2/A5uFqNxWacpXGGt TCRk9dEDBlmixEd8QiLkUfvHpJX/xKnmVkS6Iye8wUbYzMsDzgnpazlPg19dnSqfhM+Cevdf a89VLnUztRr2cgmCfyO9Otrh7LJDPG+4D8ZnAqDtVB8MKYJL6QgKyVhhaBc4y3bGWxKyXEtx 7QIZZGxPwSkzK3WIN+VKNdkiwTubW5PIdopmykwvIjLPqbJK7yPwFZYekKE015OsW6FV+s4D IM8UlVS8pkIsoGGJtMuWjLL4tq2hYQuuN0jhrxK1ljz50hH23gA9cbMCAwEAAaOCAWQwggFg MA4GA1UdDwEB/wQEAwIBBjAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0T AQH/BAgwBgEB/wIBADAyBgNVHR8EKzApMCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNv bS9zZnNjYS5jcmwwZgYIKwYBBQUHAQEEWjBYMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5z dGFydHNzbC5jb20wMAYIKwYBBQUHMAKGJGh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRz L2NhLmNydDAdBgNVHQ4EFgQUJIFsOWG+SQ+PtxtGK8kotSdIbWgwHwYDVR0jBBgwFoAUTgvv GqRAW6UXaYcwyjRoQ9BBrvIwPwYDVR0gBDgwNjA0BgRVHSAAMCwwKgYIKwYBBQUHAgEWHmh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeTANBgkqhkiG9w0BAQsFAAOCAgEAi+P3h+wB i4StDwECW5zhIycjBL008HACblIf26HY0JdOruKbrWDsXUsiI0j/7Crft9S5oxvPiDtVqspB OB/y5uzSns1lZwh7sG96bYBZpcGzGxpFNjDmQbcM3yl3WFIRS4WhNrsOY14V7y2IrUGsvets D+bjyOngCIVeC/GmsmtbuLOzJ606tEc9uRbhjTu/b0x2Fo+/e7UkQvKzNeo7OMhijixaULyI NBfCBJb+e29bLafgu6JqjOUJ9eXXj20p6q/CW+uVrZiSW57+q5an2P2i7hP85jQJcy5j4HzA 0rSiF3YPhKGAWUxKPMAVGgcYoXzWydOvZ3UDsTDTagXpRDIKQLZo02wrlxY6iMFqvlzsemVf 1odhQJmi7Eh5TbxI40kDGcBOBHhwnaOumZhLP+SWJQnjpLpSlUOj95uf1zo9oz9e0NgIJoz/ tdfrBzez76xtDsK0KfUDHt1/q59BvDI7RX6gVr0fQoCyMczNzCTcRXYHY0tq2J0oT+bsb6sH 2b4WVWAiJKnSYaWDjdA70qHX4mq9MIjO/ZskmSY8wtAk24orAc0vwXgYanqNsBX5Yv4sN4Z9 VyrwMdLcusP7HJgRdAGKpkR2I9U4zEsNJQJewM7S4Jalo1DyPrLpL2nTET8ZrSl5Utp1UeGp /2deoprGevfnxWB+vHNQiu85o6MxggPMMIIDyAIBATCBiTB1MQswCQYDVQQGEwJJTDEWMBQG A1UEChMNU3RhcnRDb20gTHRkLjEpMCcGA1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBB dXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0Q29tIENsYXNzIDEgQ2xpZW50IENBAhAU4QcxMULa otNy8Yzm2pESMA0GCWCGSAFlAwQCAQUAoIICEzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcB MBwGCSqGSIb3DQEJBTEPFw0xNjEyMjMwODI4NTRaMC8GCSqGSIb3DQEJBDEiBCCaUBJ4n2Xs RsbqiqCWk6WDnUriQMdjYs7xaGOGWh6xJjBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQB KjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMC AgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkG A1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENl cnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVu dCBDQQIQFOEHMTFC2qLTcvGM5tqREjCBnAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRp ZmljYXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBD QQIQFOEHMTFC2qLTcvGM5tqREjANBgkqhkiG9w0BAQEFAASCAQAPF7Ql5kuWIA8FYb2xAIK8 auQmWEdslxTI4ta99zht1sHAQc4iejW/eYn6R+xqslYrmviuiKFc0+LRnRIvulOK18KFiKa3 rsX9IA7HdQtw1/ULbYY7+aZh40oS3QuXcygkJC3E8FnuNrLWz6aRF5XCAdueo0mKz1wBNKyF 8HaZuobc0rbmowSzdY3zKh3mwQGWVMeC9S5gfpxMjLPkax7Zf/dKG3582nZSoNZGjUreXge7 G8vmJbz5ezGWIOfWD98aCRmuKsKwFpyR6M9h1xsUT2i6gm82KT8TLH9J9agScLWKEa3jz3pb an8ZKhP6JOdzCfU16OTMkqTbkvMgEgHeAAAAAAAA --------------ms010703040104030203040702-- From nobody Fri Dec 23 09:41:49 2016 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3AD53129418 for ; Fri, 23 Dec 2016 09:41:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.8 X-Spam-Level: X-Spam-Status: No, score=-5.8 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-3.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.net 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 xcq6mFxGhFN1 for ; Fri, 23 Dec 2016 09:41:47 -0800 (PST) Received: from resqmta-ch2-09v.sys.comcast.net (resqmta-ch2-09v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:41]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C240129413 for ; Fri, 23 Dec 2016 09:41:46 -0800 (PST) Received: from resomta-ch2-06v.sys.comcast.net ([69.252.207.102]) by resqmta-ch2-09v.sys.comcast.net with SMTP id KTqLcauaNuazMKTqkcJa6c; Fri, 23 Dec 2016 17:41:46 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20161114; t=1482514906; bh=ooO5QEkaxN/oY3gYEOeZV5Y18i48RtIjvmXEJ60M00I=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=GCtXaXBrk/ryKRL6gQbk5a3I26i9+UD9olbSdMv4CBVVU+nx2pQLi7BmZ0azcnp8H X438+eafqLblk8qO1srFrHvzn6skL8miyEaDIBQihWhsYT+uNR3KoIc2pUKxa1XV2Q uK9RQITX9dsM8dwAfeqFcuD8E7z7H87I+4xamOJfbunwzfJfCrjr4VEcjS8N8Y2yKY npn2pr3eE9SiYF12hs0aoLmswiAYhJqB0MQxZyZZnfm7QKnQ2ivXZdOt/tRtrVG/Oh WtETv2NJQj5c96SMBPJDRHSLTCvyc9fjy6+DN25TevGml8DdZlJhpLrWD3z/bDNBZW r+bmvdD+TBiFA== Received: from [IPv6:2601:152:4400:9b5f:c8f0:67e5:88b1:2975] ([IPv6:2601:152:4400:9b5f:c8f0:67e5:88b1:2975]) by resomta-ch2-06v.sys.comcast.net with SMTP id KTqicfInPBjCGKTqjcLf9a; Fri, 23 Dec 2016 17:41:46 +0000 To: Eliot Lear , ace@ietf.org References: <062dd7b2-48a8-ba6c-e80a-0e8f309bf12e@cisco.com> From: Michael StJohns Message-ID: <00653595-3a01-c00b-be9b-1fe41b1e2c3d@comcast.net> Date: Fri, 23 Dec 2016 12:41:57 -0500 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: <062dd7b2-48a8-ba6c-e80a-0e8f309bf12e@cisco.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-CMAE-Envelope: MS4wfHWe8TfhNvqidfvJUHwdTs/8O9F+XhZtdvLMFKFYyHj3qz9Jj4ZibT3C9rpevYMv5hok8TwGmkU3VQjdwCtSsQQfJyp+ZOb12iGhhddp4a/F1i0zt9Dj x0muZV9EaAaN/+W9zLLOIQO/1FL19UThFIHi4JSNBWs2AnE53yfoMQsgJdm25ReJc30kJPvD8SLzhw5FUd/QlJeHmlCZY5NCTag= Archived-At: Subject: Re: [Ace] where are we with draft-somarju-ace-multicast? X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Dec 2016 17:41:48 -0000 On 12/23/2016 3:24 AM, Eliot Lear wrote: > > On 12/22/16 11:36 PM, Michael StJohns wrote: >> >> On 12/22/2016 3:42 AM, Eliot Lear wrote: >>> Hi, >>> >>> This working group has been in a state of indecision about this draft >>> for quite some time and I would like to gain some clarity on the matter. >>> >>> On the one hand, we have a draft that there seems to be unanimous >>> agreement would be useful to the lighting people. >> Actually, we have a draft that the lighting people unanimously agree >> that would be useful to the lighting people. Not quite the same thing. >> > No, even you have previously conceded that this use case is fine. Really? Where and when? What I said was that I didn't believe this draft was even conditionally secure for control systems, and that while I thought it was a bad idea, I was fine with the lighting folk going off and publishing it as informational for their own internal use. > >> And, as I've said before, if this is ONLY applicable to the lighting >> people then they should go off and write an Informational "Here's how >> we do it" document and not try for an internet standard. > It's not. Lighting is not the only highly constrained case where low > power budget and low latency requirements will make public key > operations expensive. It just happens to be leading the path. Can you think of even one other case where low cost (not low power - seriously, it's a light bulb and it's plugged in) and low latency so constrain the problem that nothing but a symmetric solution will work? I can't. And I can't remember even a suggestion that there was another one. Remember that the latency issues here are related to human perception and to nothing else. So use case other than lighting is? > >>> On the other hand, we >>> have some concern that the draft might be misapplied to environments >>> where PSK/symmetric keys should not be employed. >>> >>> As Hannes wrote, security is not a black and white matter. We need to >>> acknowledge that fact. This, to me, seems to boil down to an >>> applicability statement. >> I don't know why people think I'm just going to let things pass >> without trying to inject some rigor. >> >> My last question: What is the security requirement for an ACE Group >> comm protocol? > The answer should be as it always was: make things better. In what world is "make things better" a security requirement? > The current > alternative is nothing, which is what happens today, and well beyond > lighting. The current draft provides for use of asymmetric keying for > group admission. Beyond that, the choices are pretty stark: perform an > symmetric operation on every transaction or use a group key. I'm not sure if you meant "perform an asymmetric operation..." or you were stating a false dilemma by limiting the choices. The asymmetric keying for group admission is nothing new, and probably doesn't materially affect the security of the protocol. If you've got a content distribution system, then the use of group symmetric keys is a valid option - mainly because the compromise of an end device is no worse than the compromise of the group key as you get access to the content by breaking into an end system. But that's not what this is. If you've got a one-to-many control system, then the use of group symmetric keys is not an option, because the compromise of an end or actuator device gives you the access to control other end or actuator devices. There are caveats and mitigations here dealing with key protection and secure elements (which cost money or power), but the general case is as stated. ACE should be working on the general case of the security of a group control system, and it's pretty clear that - for the general case - only an asymmetric approach for "signing" the control messages has the necessary security properties. > >> My current minimum bid: Compromise of a single device shall not >> result in the attacker gaining privileges over the group greater than >> those nominally granted to the device being attacked. or less >> nuanced: Compromise of a single device shall not result in the >> compromise of the entire group. > And here's mine: > > The group must be treated as a single device, for purpose of compromise, > barring additional measures being taken at other layers. Um. No. This requirement is valid if and only if each and every device in the group has exactly the same privileges with respect to the group. If I compromise a light switch, I get its privileges to turn on and off the group. If I compromise a light bulb, why should I get privileges to turn on and off the group? I actually described the above as a possibility for say a collection/flock of drones way back in DICE. But even then I would suggest that hardware protection of the symmetric key would be necessary for meaningful security guarantees for any group larger than about 4 or 8. > The advantage > of this over status quo is that today admission is open, and the threat > surface is therefore unconstrained. With this approach the threat > surface is reduced to other infected group members. I believe that your analysis is flawed. Basically, the cost to attack any of the entities in the lighting case approaches zero, especially if you can physically access one. The probability of success of attacking such entities approaches unity. The security guarantees for this are therefore roughly equivalent to no security at all and may be worse than no security at all because the general public will not inquire as to what "secure" means for any given case. Or put another way, this is no better than security by obscurity. There are any number of products that tout security in their ads or specifications, but when you get under the covers you recoil in horror at finding just how trivial it would be to penetrate. I expect going forward that any device or item can be broken into with some level of effort given physical or network access. What I don't want to have happen - due to our poor choices - is making the Work Factor of the group (to break in) identical to the Work Factor of breaking into a single device and that's what this draft is proposing to institutionalize in the protocol. We can do better and we should. Mike > > Eliot > From nobody Sat Dec 24 08:20:03 2016 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02D42128E19 for ; Sat, 24 Dec 2016 08:20:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 O4oFITpbyWpk for ; Sat, 24 Dec 2016 08:19:59 -0800 (PST) Received: from mail-qk0-x22c.google.com (mail-qk0-x22c.google.com [IPv6:2607:f8b0:400d:c09::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B087B1200A0 for ; Sat, 24 Dec 2016 08:19:58 -0800 (PST) Received: by mail-qk0-x22c.google.com with SMTP id h201so28232688qke.1 for ; Sat, 24 Dec 2016 08:19:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=PsD5w/TmPquR7Kr3yTNcTursYNdXBuvpW9cFTQecWGo=; b=eijVdu90JADQ+bbxvong3ssV/qiWOdWxERhnaxLcQi5zyje+79a3V6jCqW16vefV86 RNxBCx+HhqrKj71jxMPS7U1mZdO5VVZu4rJo+zEIEpWXNfh7/P5Sv7+KKj1Rd87Tcq3b +pnktFtz1mYr3f7pD8Pg2mnjAoZiSdpYUgOrH/F9iKDkyQ0HIzLR0SjQeWNYf4DfEhwV OdTBdhyWZCvPTLBxGgx2BWFmQdjsvZFp5Zy/NKjyupWuBr0KB+C3U3mwt5/G72FTL7aA uR8JT7NEWILnRKMDuGyari191/Z0ppDY2xxZ0hhNWKqdlQWWZGBKZqbtvIJC0KxcubJU X5gg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=PsD5w/TmPquR7Kr3yTNcTursYNdXBuvpW9cFTQecWGo=; b=XosA18+rIAuXU5McRq3G/9IwnKvRuqnstLUgfyFudoZDk6fHtdnqDRktByp5uUk2lE pydnsm3FsIR70a0jPi28fvlrFKlfS67ptxwGWQyKBxh/Wgfa6I9xZS53jXQtItOHsieY mOcSiZ6vh1mfI8zWntLQxEk4rVaSCU6anPWNFJBCIBA3O0NSwwd5Yt8DiiqmIZpJFXTP ADubR+9ql7Om6QKukgDtZcninFnzqyO+IUCTCYCxisqywqXzEAjFdlW3sNgSvth1zgq3 z4vQcEiZjOF4xopCeAXoZM/g101bgf6nalRLDnxqzIeUalBiypEbkJDCAF5j3pg3ePyZ lBBQ== X-Gm-Message-State: AIkVDXJYbn7e/rpHW7uc/DHdGmUwvmWvtShGX3HLm1IU3AxQ/2UaqsJ7y8tizTFs4FRT4uTN4F4qjfrzTfBk8w== X-Received: by 10.55.132.67 with SMTP id g64mr10775qkd.153.1482596397858; Sat, 24 Dec 2016 08:19:57 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.161.101 with HTTP; Sat, 24 Dec 2016 08:19:57 -0800 (PST) In-Reply-To: <00653595-3a01-c00b-be9b-1fe41b1e2c3d@comcast.net> References: <062dd7b2-48a8-ba6c-e80a-0e8f309bf12e@cisco.com> <00653595-3a01-c00b-be9b-1fe41b1e2c3d@comcast.net> From: Kathleen Moriarty Date: Sat, 24 Dec 2016 11:19:57 -0500 Message-ID: To: Michael StJohns Content-Type: multipart/alternative; boundary=94eb2c07481ca3cd04054469dfac Archived-At: Cc: Eliot Lear , "ace@ietf.org" Subject: Re: [Ace] where are we with draft-somarju-ace-multicast? X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Dec 2016 16:20:01 -0000 --94eb2c07481ca3cd04054469dfac Content-Type: text/plain; charset=UTF-8 We continue to go in circles on this despite efforts to mitigate or warn of risks and agreement to put forth an asymmetric key solution at the same time. This continued DoS on this topic is serving no purpose but to delay vendors or send them elsewhere when they are here in ACE looking for assistance to standardize a solution (or solutions). I thought we had some agreement to go forward with both solutions. I see Mike is requesting that this be informational and that's one possible route, but I'm not convinced. I do think we should go forward adopting the solutions, working on them and figuring out the status and constraining language in parallel. inline, On Fri, Dec 23, 2016 at 12:41 PM, Michael StJohns wrote: > On 12/23/2016 3:24 AM, Eliot Lear wrote: > >> >> On 12/22/16 11:36 PM, Michael StJohns wrote: >> >>> >>> On 12/22/2016 3:42 AM, Eliot Lear wrote: >>> >>>> Hi, >>>> >>>> This working group has been in a state of indecision about this draft >>>> for quite some time and I would like to gain some clarity on the matter. >>>> >>> Thank you for your efforts, Eliot! > >>>> On the one hand, we have a draft that there seems to be unanimous >>>> agreement would be useful to the lighting people. >>>> >>> Actually, we have a draft that the lighting people unanimously agree >>> that would be useful to the lighting people. Not quite the same thing. >>> >>> No, even you have previously conceded that this use case is fine. >> > > Really? Where and when? What I said was that I didn't believe this > draft was even conditionally secure for control systems, and that while I > thought it was a bad idea, I was fine with the lighting folk going off and > publishing it as informational for their own internal use. > > > >> And, as I've said before, if this is ONLY applicable to the lighting >>> people then they should go off and write an Informational "Here's how >>> we do it" document and not try for an internet standard. >>> >> It's not. Lighting is not the only highly constrained case where low >> power budget and low latency requirements will make public key >> operations expensive. It just happens to be leading the path. >> > > Can you think of even one other case where low cost (not low power - > seriously, it's a light bulb and it's plugged in) and low latency so > constrain the problem that nothing but a symmetric solution will work? I > can't. And I can't remember even a suggestion that there was another one. > Remember that the latency issues here are related to human perception and > to nothing else. > > So use case other than lighting is? I don't see why it matters. If we have lighting vendors who want to work with us in ACE, why can't we devise a couple of solutions specific to their space? These questions are only relevant to the constraining language that gets added to the draft(s). > > > >> On the other hand, we >>>> have some concern that the draft might be misapplied to environments >>>> where PSK/symmetric keys should not be employed. >>>> >>>> As Hannes wrote, security is not a black and white matter. We need to >>>> acknowledge that fact. This, to me, seems to boil down to an >>>> applicability statement. >>>> >>> I don't know why people think I'm just going to let things pass >>> without trying to inject some rigor. >>> >>> My last question: What is the security requirement for an ACE Group >>> comm protocol? >>> >> The answer should be as it always was: make things better. >> > In what world is "make things better" a security requirement? > > The current >> alternative is nothing, which is what happens today, and well beyond >> lighting. The current draft provides for use of asymmetric keying for >> group admission. Beyond that, the choices are pretty stark: perform an >> symmetric operation on every transaction or use a group key. >> > > I'm not sure if you meant "perform an asymmetric operation..." or you were > stating a false dilemma by limiting the choices. The asymmetric keying for > group admission is nothing new, and probably doesn't materially affect the > security of the protocol. > > If you've got a content distribution system, then the use of group > symmetric keys is a valid option - mainly because the compromise of an end > device is no worse than the compromise of the group key as you get access > to the content by breaking into an end system. But that's not what this is. > > If you've got a one-to-many control system, then the use of group > symmetric keys is not an option, because the compromise of an end or > actuator device gives you the access to control other end or actuator > devices. There are caveats and mitigations here dealing with key > protection and secure elements (which cost money or power), but the general > case is as stated. > > ACE should be working on the general case of the security of a group > control system, and it's pretty clear that - for the general case - only an > asymmetric approach for "signing" the control messages has the necessary > security properties. > > > >> My current minimum bid: Compromise of a single device shall not >>> result in the attacker gaining privileges over the group greater than >>> those nominally granted to the device being attacked. or less >>> nuanced: Compromise of a single device shall not result in the >>> compromise of the entire group. >>> >> And here's mine: >> >> The group must be treated as a single device, for purpose of compromise, >> barring additional measures being taken at other layers. >> > > Um. No. This requirement is valid if and only if each and every device in > the group has exactly the same privileges with respect to the group. If I > compromise a light switch, I get its privileges to turn on and off the > group. If I compromise a light bulb, why should I get privileges to turn > on and off the group? > Fine, let's constrain it as such and move on. There are use cases for lighting that do not require high security. If you overbuild, it will not get used. We just need to provide an alternate more secure solution detailing when it is to be used at the same time a symmetric key solution is published (standards or informational track TBD). > > I actually described the above as a possibility for say a collection/flock > of drones way back in DICE. But even then I would suggest that hardware > protection of the symmetric key would be necessary for meaningful security > guarantees for any group larger than about 4 or 8. > > > > The advantage >> of this over status quo is that today admission is open, and the threat >> surface is therefore unconstrained. With this approach the threat >> surface is reduced to other infected group members. >> > > I believe that your analysis is flawed. Basically, the cost to attack any > of the entities in the lighting case approaches zero, especially if you can > physically access one. The probability of success of attacking such > entities approaches unity. The security guarantees for this are therefore > roughly equivalent to no security at all and may be worse than no security > at all because the general public will not inquire as to what "secure" > means for any given case. Or put another way, this is no better than > security by obscurity. > In some scenarios, lower security is all that is needed. If a zone in an office building turns off when an employee leaves the room, this zone (a single device) is compromised, worse case scenario might be a high bill for the month. Settings like hospitals would not be appropriate for this solution and that should be called out explicitly. The risk decision is always made by the implementor, we just need to give them the information needed to make appropriate decisions. > > There are any number of products that tout security in their ads or > specifications, but when you get under the covers you recoil in horror at > finding just how trivial it would be to penetrate. > Sure, but let's figure out if there is a way to do this and list appropriate protections for the "device" or zone, etc. where a shared key is in use. > > I expect going forward that any device or item can be broken into with > some level of effort given physical or network access. What I don't want > to have happen - due to our poor choices - is making the Work Factor of the > group (to break in) identical to the Work Factor of breaking into a single > device and that's what this draft is proposing to institutionalize in the > protocol. We can do better and we should. I thought we were working on multiple solutions and moving on? Happy holidays! Kathleen > > > Mike > > > > >> Eliot >> >> > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace > -- Best regards, Kathleen --94eb2c07481ca3cd04054469dfac Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
We continue to go in circles on this despite efforts to mi= tigate or warn of risks and agreement to put forth an asymmetric key soluti= on at the same time.=C2=A0 This continued DoS on this topic is serving no p= urpose but to delay vendors or send them elsewhere when they are here in AC= E looking for assistance to standardize a solution (or solutions). =C2=A0
I thought we had some agreement to go forward with both s= olutions.=C2=A0 I see Mike is requesting that this be informational and tha= t's one possible route, but I'm not convinced.=C2=A0 I do think we = should go forward adopting the solutions, working on them and figuring out = the status and constraining language in parallel. inline,

On Fri, Dec 23, 2016 at 12:= 41 PM, Michael StJohns <mstjohns@comcast.net> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">On 12/23/2016 3:24 AM, Eliot= Lear wrote:

On 12/22/16 11:36 PM, Michael StJohns wrote:

On 12/22/2016 3:42 AM, Eliot Lear wrote:
Hi,

This working group has been in a state of indecision about this draft
for quite some time and I would like to gain some clarity on the matter.

=
Thank you for your efforts, Eliot!=C2=A0

On the one hand, we have a draft that there seems to be unanimous
agreement would be useful to the lighting people.
Actually, we have a draft that the lighting people unanimously agree
that would be useful to the lighting people.=C2=A0 Not quite the same thing= .

No, even you have previously conceded that this use case is fine.

 Really?=C2=A0 Where and when?=C2=A0 =C2=A0 What I said was that I didn'= t believe this draft was even conditionally secure for control systems, and= that while I thought it was a bad idea, I was fine with the lighting folk = going off and publishing it as informational for their own internal use.



And, as I've said before, if this is ONLY applicable to the lighting people then they should go off and write an Informational "Here's = how
we do it" document and not try for an internet standard.
It's not.=C2=A0 Lighting is not the only highly constrained case where = low
power budget and low latency requirements will make public key
operations expensive.=C2=A0 It just happens to be leading the path.

Can you think of even one other case where low cost (not low power - seriou= sly, it's a light bulb and it's plugged in) and low latency so cons= train the problem that nothing but a symmetric solution will work?=C2=A0 I = can't.=C2=A0 And I can't remember even a suggestion that there was = another one.=C2=A0 Remember that the latency issues here are related to hum= an perception and to nothing else.

So use case other than lighting is?

I don&#= 39;t see why it matters.=C2=A0 If we have lighting vendors who want to work= with us in ACE, why can't we devise a couple of solutions specific to = their space?=C2=A0 These questions are only relevant to the constraining la= nguage that gets added to the draft(s).=C2=A0





On the other hand, we
have some concern that the draft might be misapplied to environments
where PSK/symmetric keys should not be employed.

As Hannes wrote, security is not a black and white matter.=C2=A0 We need to=
acknowledge that fact.=C2=A0 This, to me, seems to boil down to an
applicability statement.
I don't know why people think I'm just going to let things pass
without trying to inject some rigor.

My last question:=C2=A0 What is the security requirement for an ACE Group comm protocol?
The answer should be as it always was: make things better.
 In what world is "make things better" a security requirement?

=C2=A0 The current
alternative is nothing, which is what happens today, and well beyond
lighting.=C2=A0 The current draft provides for use of asymmetric keying for=
group admission.=C2=A0 Beyond that, the choices are pretty stark: perform a= n
symmetric operation on every transaction or use a group key.

I'm not sure if you meant "perform an asymmetric operation..."= ; or you were stating a false dilemma by limiting the choices.=C2=A0 The as= ymmetric keying for group admission is nothing new, and probably doesn'= t materially affect the security of the protocol.

If you've got a content distribution system, then the use of group symm= etric keys is a valid option - mainly because the compromise of an end devi= ce is no worse than the compromise of the group key as you get access to th= e content by breaking into an end system.=C2=A0 But that's not what thi= s is.

If you've got a one-to-many control system, then the use of group symme= tric keys is not an option, because the compromise of an end or actuator de= vice gives you the access to control other end or actuator devices.=C2=A0 = =C2=A0 There are caveats and mitigations here dealing with key protection a= nd secure elements (which cost money or power), but the general case is as = stated.

ACE should be working on the general case of the security of a group contro= l system, and it's pretty clear that - for the general case - only an a= symmetric approach for "signing" the control messages has the nec= essary security properties.



My current minimum bid:=C2=A0 Compromise of a single device shall not
result in the attacker gaining privileges over the group greater than
those nominally granted to the device being attacked.=C2=A0 or less
nuanced:=C2=A0 Compromise of a single device shall not result in the
compromise of the entire group.
And here's mine:

The group must be treated as a single device, for purpose of compromise, barring additional measures being taken at other layers.

 Um. No.=C2=A0 This requirement is valid if and only if each and every devic= e in the group has exactly the same privileges with respect to the group.= =C2=A0 If I compromise a light switch, I get its privileges to turn on and = off the group.=C2=A0 If I compromise a light bulb, why should I get privile= ges to turn on and off the group?

Fine,= let's constrain it as such and move on.=C2=A0 There are use cases for = lighting that do not require high security.=C2=A0 If you overbuild, it will= not get used.=C2=A0 We just need to provide an alternate more secure solut= ion detailing when it is to be used at the same time a symmetric key soluti= on is published (standards or informational track TBD).
=C2=A0

I actually described the above as a possibility for say a collection/flock = of drones way back in DICE.=C2=A0 But even then I would suggest that hardwa= re protection of the symmetric key would be necessary for meaningful securi= ty guarantees for any group larger than about 4 or 8.



=C2=A0 The advantage
of this over status quo is that today admission is open, and the threat
surface is therefore unconstrained.=C2=A0 With this approach the threat
surface is reduced to other infected group members.

 I believe that your analysis is flawed.=C2=A0 Basically, the cost to attack= any of the entities in the lighting case approaches zero, especially if yo= u can physically access one.=C2=A0 The probability of success of attacking = such entities approaches unity.=C2=A0 The security guarantees for this are = therefore roughly equivalent to=C2=A0 no security at all and may be worse t= han no security at all because the general public will not inquire as to wh= at "secure" means for any given case. Or put another way, this is= no better than security by obscurity.

= In some scenarios, lower security is all that is needed.=C2=A0 If a zone in= an office building turns off when an employee leaves the room, this zone (= a single device) is compromised, worse case scenario might be a high bill f= or the month.=C2=A0 Settings like hospitals would not be appropriate for th= is solution and that should be called out explicitly.=C2=A0 The risk decisi= on is always made by the implementor, we just need to give them the informa= tion needed to make appropriate decisions. =C2=A0

There are any number of products that tout security in their ads or specifi= cations, but when you get under the covers you recoil in horror at finding = just how trivial it would be to penetrate.

<= div>Sure, but let's figure out if there is a way to do this and list ap= propriate protections for the "device" or zone, etc. where a shar= ed key is in use.
=C2=A0

I expect going forward that any device or item can be broken into with some= level of effort given physical or network access.=C2=A0 What I don't w= ant to have happen - due to our poor choices - is making the Work Factor of= the group (to break in) identical to the Work Factor of breaking into a si= ngle device and that's what this draft is proposing to institutionalize= in the protocol.=C2=A0 We can do better and we should.
I thought we were working on multiple solutions and moving on?=

Happy holidays!
Kathleen
=C2= =A0


Mike




Eliot


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



--
=

Best regards,
Kathleen
--94eb2c07481ca3cd04054469dfac-- From nobody Sat Dec 24 09:12:38 2016 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCBBD1295C0 for ; Sat, 24 Dec 2016 09:12:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=att.net 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 f-NKPmjGl47e for ; Sat, 24 Dec 2016 09:12:35 -0800 (PST) Received: from nm22-vm5.access.bullet.mail.bf1.yahoo.com (nm22-vm5.access.bullet.mail.bf1.yahoo.com [216.109.115.148]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A286712959D for ; Sat, 24 Dec 2016 09:12:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=att.net; s=s1024; t=1482599553; bh=0FTm/UJ8JdRsfCrvAKIFaleu44hVC/kdbZhZ6MoZo1Q=; h=Date:Subject:From:To:CC:References:In-Reply-To:From:Subject; b=P4f9c2OEeSrWyG0CBqvijjpkYGSILwAN7I7bRYP0YvDTjsj8Emnmu91Spa0NW3ugZ803qWZjSANZwcxoBtrtCblT0M6tVIET9H4rn/2xU2XxQhFEANb/fj7NxShwOepkU80afpVjQ3QuILh5G6ymBho/JC+pQYexsGOQtW4kDNs= Received: from [66.196.81.163] by nm22.access.bullet.mail.bf1.yahoo.com with NNFMP; 24 Dec 2016 17:12:33 -0000 Received: from [98.138.226.241] by tm9.access.bullet.mail.bf1.yahoo.com with NNFMP; 24 Dec 2016 17:12:33 -0000 Received: from [127.0.0.1] by smtp112.sbc.mail.ne1.yahoo.com with NNFMP; 24 Dec 2016 17:12:33 -0000 X-Yahoo-Newman-Id: 474396.74879.bm@smtp112.sbc.mail.ne1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: LYMupywVM1lgqGXE1IHsUlmrw6ZJdihSWiQnaOJZ7vTa74S li3wFi0gYq3pv1xxFBiIqOtFFLXo8E.zj.lzwSjClqMks1PYYKYwkepoTbHQ Y2zqvD_U7TCqDzAeKm0brB67bSKMzxQ6UV2LNk80OoQBuJ8aPC_bdrjWsWoL RjAI.87q55FkjfmyjyI0WLwA4nWwQdjj7UPWQfGd_jerMnFRWNtxlfjIDWOj RHGYxUKOOqrFPSpKCwT5XmB1VTo5gsoK4KzaW5qs0n4kEX_eIllvGkzeaNVV .d9DeWVi9q_HqAxKK60Ri4Hdzh3f8aPqSFuFjQI_EdB8c7IPJdmPGrDISyif qLWc9ybpUHH8PCLO8ZEionutfWVIEmGJTJv43f3FOqx68r8li0DtNTc4lsb1 8IA4H2_smTSjEsyhwVu3jOvDypOJfJNUYr7teHrLT0r5d7pagdlpTSiKnahg honlIn0RekxoPtBhDf_CyhaAYqfcWhUK4ObIjMJq8vrMYcUhn4Ogow8Egpee E4kEHN6pxEunqsG0I2k8wPl9iGoi85NDVPCVEMYlfJpAMttFdXIuCHBGPsw- - X-Yahoo-SMTP: fvjol_aswBAraSJvMLe2r1XTzhBhbFxY8q8c3jo- User-Agent: Microsoft-MacOutlook/14.7.1.161129 Date: Sat, 24 Dec 2016 09:12:26 -0800 From: Don Sturek To: Kathleen Moriarty , Michael StJohns Message-ID: Thread-Topic: [Ace] where are we with draft-somarju-ace-multicast? References: <062dd7b2-48a8-ba6c-e80a-0e8f309bf12e@cisco.com> <00653595-3a01-c00b-be9b-1fe41b1e2c3d@comcast.net> In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3565415551_456332" Archived-At: Cc: Eliot Lear , "ace@ietf.org" Subject: Re: [Ace] where are we with draft-somarju-ace-multicast? X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Dec 2016 17:12:37 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3565415551_456332 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Hi Kathleen, Having worked on these lighting solutions and knowing the security limitations, I think the Informational RFC is best. Creating a standard (even with ample warnings and proposed limitations) will only end up in disappointment and embarrassment when someone finds a more creative security break with these solutions . Happy holidays to all! Don Sturek From: Ace on behalf of Kathleen Moriarty Date: Saturday, December 24, 2016 at 8:19 AM To: Michael StJohns Cc: Eliot Lear , "ace@ietf.org" Subject: Re: [Ace] where are we with draft-somarju-ace-multicast? We continue to go in circles on this despite efforts to mitigate or warn of risks and agreement to put forth an asymmetric key solution at the same time. This continued DoS on this topic is serving no purpose but to delay vendors or send them elsewhere when they are here in ACE looking for assistance to standardize a solution (or solutions). I thought we had some agreement to go forward with both solutions. I see Mike is requesting that this be informational and that's one possible route, but I'm not convinced. I do think we should go forward adopting the solutions, working on them and figuring out the status and constraining language in parallel. inline, On Fri, Dec 23, 2016 at 12:41 PM, Michael StJohns wrote: > On 12/23/2016 3:24 AM, Eliot Lear wrote: >> >> On 12/22/16 11:36 PM, Michael StJohns wrote: >>> >>> On 12/22/2016 3:42 AM, Eliot Lear wrote: >>>> Hi, >>>> >>>> This working group has been in a state of indecision about this draft >>>> for quite some time and I would like to gain some clarity on the matter. Thank you for your efforts, Eliot! >>>> >>>> On the one hand, we have a draft that there seems to be unanimous >>>> agreement would be useful to the lighting people. >>> Actually, we have a draft that the lighting people unanimously agree >>> that would be useful to the lighting people. Not quite the same thing. >>> >> No, even you have previously conceded that this use case is fine. > > Really? Where and when? What I said was that I didn't believe this draft > was even conditionally secure for control systems, and that while I thought it > was a bad idea, I was fine with the lighting folk going off and publishing it > as informational for their own internal use. > > >> >>> And, as I've said before, if this is ONLY applicable to the lighting >>> people then they should go off and write an Informational "Here's how >>> we do it" document and not try for an internet standard. >> It's not. Lighting is not the only highly constrained case where low >> power budget and low latency requirements will make public key >> operations expensive. It just happens to be leading the path. > > Can you think of even one other case where low cost (not low power - > seriously, it's a light bulb and it's plugged in) and low latency so constrain > the problem that nothing but a symmetric solution will work? I can't. And I > can't remember even a suggestion that there was another one. Remember that > the latency issues here are related to human perception and to nothing else. > > So use case other than lighting is? I don't see why it matters. If we have lighting vendors who want to work with us in ACE, why can't we devise a couple of solutions specific to their space? These questions are only relevant to the constraining language that gets added to the draft(s). > > > >> >>>> On the other hand, we >>>> have some concern that the draft might be misapplied to environments >>>> where PSK/symmetric keys should not be employed. >>>> >>>> As Hannes wrote, security is not a black and white matter. We need to >>>> acknowledge that fact. This, to me, seems to boil down to an >>>> applicability statement. >>> I don't know why people think I'm just going to let things pass >>> without trying to inject some rigor. >>> >>> My last question: What is the security requirement for an ACE Group >>> comm protocol? >> The answer should be as it always was: make things better. > In what world is "make things better" a security requirement? > >> The current >> alternative is nothing, which is what happens today, and well beyond >> lighting. The current draft provides for use of asymmetric keying for >> group admission. Beyond that, the choices are pretty stark: perform an >> symmetric operation on every transaction or use a group key. > > I'm not sure if you meant "perform an asymmetric operation..." or you were > stating a false dilemma by limiting the choices. The asymmetric keying for > group admission is nothing new, and probably doesn't materially affect the > security of the protocol. > > If you've got a content distribution system, then the use of group symmetric > keys is a valid option - mainly because the compromise of an end device is no > worse than the compromise of the group key as you get access to the content by > breaking into an end system. But that's not what this is. > > If you've got a one-to-many control system, then the use of group symmetric > keys is not an option, because the compromise of an end or actuator device > gives you the access to control other end or actuator devices. There are > caveats and mitigations here dealing with key protection and secure elements > (which cost money or power), but the general case is as stated. > > ACE should be working on the general case of the security of a group control > system, and it's pretty clear that - for the general case - only an asymmetric > approach for "signing" the control messages has the necessary security > properties. > > >> >>> My current minimum bid: Compromise of a single device shall not >>> result in the attacker gaining privileges over the group greater than >>> those nominally granted to the device being attacked. or less >>> nuanced: Compromise of a single device shall not result in the >>> compromise of the entire group. >> And here's mine: >> >> The group must be treated as a single device, for purpose of compromise, >> barring additional measures being taken at other layers. > > Um. No. This requirement is valid if and only if each and every device in the > group has exactly the same privileges with respect to the group. If I > compromise a light switch, I get its privileges to turn on and off the group. > If I compromise a light bulb, why should I get privileges to turn on and off > the group? Fine, let's constrain it as such and move on. There are use cases for lighting that do not require high security. If you overbuild, it will not get used. We just need to provide an alternate more secure solution detailing when it is to be used at the same time a symmetric key solution is published (standards or informational track TBD). > > I actually described the above as a possibility for say a collection/flock of > drones way back in DICE. But even then I would suggest that hardware > protection of the symmetric key would be necessary for meaningful security > guarantees for any group larger than about 4 or 8. > > > >> The advantage >> of this over status quo is that today admission is open, and the threat >> surface is therefore unconstrained. With this approach the threat >> surface is reduced to other infected group members. > > I believe that your analysis is flawed. Basically, the cost to attack any of > the entities in the lighting case approaches zero, especially if you can > physically access one. The probability of success of attacking such entities > approaches unity. The security guarantees for this are therefore roughly > equivalent to no security at all and may be worse than no security at all > because the general public will not inquire as to what "secure" means for any > given case. Or put another way, this is no better than security by obscurity. In some scenarios, lower security is all that is needed. If a zone in an office building turns off when an employee leaves the room, this zone (a single device) is compromised, worse case scenario might be a high bill for the month. Settings like hospitals would not be appropriate for this solution and that should be called out explicitly. The risk decision is always made by the implementor, we just need to give them the information needed to make appropriate decisions. > > There are any number of products that tout security in their ads or > specifications, but when you get under the covers you recoil in horror at > finding just how trivial it would be to penetrate. Sure, but let's figure out if there is a way to do this and list appropriate protections for the "device" or zone, etc. where a shared key is in use. > > I expect going forward that any device or item can be broken into with some > level of effort given physical or network access. What I don't want to have > happen - due to our poor choices - is making the Work Factor of the group (to > break in) identical to the Work Factor of breaking into a single device and > that's what this draft is proposing to institutionalize in the protocol. We > can do better and we should. I thought we were working on multiple solutions and moving on? Happy holidays! Kathleen > > > Mike > > > >> >> Eliot >> > > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace -- Best regards, Kathleen _______________________________________________ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace --B_3565415551_456332 Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable
Hi Kathleen,

=
Having worked on these lighting solutions and knowing the securit= y limitations, I think the Informational RFC is best.   Creating a stan= dard (even with ample warnings and proposed limitations) will only end up in= disappointment and embarrassment when someone finds a more creative securit= y break with these solutions .

Happy holidays to al= l!

Don Sturek



From: Ace <ace-bounces@ietf.org> on behalf of Kathleen = Moriarty <kathleen.mori= arty.ietf@gmail.com>
Date: = Saturday, December 24, 2016 at 8:19 AM
To:= Michael StJohns <mstjohns@= comcast.net>
Cc: Eliot Lear= <lear@cisco.com>, "ace@ietf.org" <ace@ietf= .org>
Subject: Re: [Ace] wh= ere are we with draft-somarju-ace-multicast?

We continue to go in circles on this despite efforts to mitigate or = warn of risks and agreement to put forth an asymmetric key solution at the s= ame time.  This continued DoS on this topic is serving no purpose but t= o delay vendors or send them elsewhere when they are here in ACE looking for= assistance to standardize a solution (or solutions).  

<= div>I thought we had some agreement to go forward with both solutions. = I see Mike is requesting that this be informational and that's one possible= route, but I'm not convinced.  I do think we should go forward adoptin= g the solutions, working on them and figuring out the status and constrainin= g language in parallel. inline,

On Fri, Dec 23, 2016 at 12:41 PM, Michael StJohns <mstjohns@comc= ast.net> wrote:
On= 12/23/2016 3:24 AM, Eliot Lear wrote:

On 12/22/16 11:36 PM, Michael StJohns wrote:
<= br> On 12/22/2016 3:42 AM, Eliot Lear wrote:
Hi,

This working group has been in a state of indecision about this draft
for quite some time and I would like to gain some clarity on the matter.

<= div>Thank you for your efforts, Eliot! 
=

On the one hand, we have a draft that there seems to be unanimous
agreement would be useful to the lighting people.
Actually, we have a draft that the lighting people unanimously agree
that would be useful to the lighting people.  Not quite the same thing= .

No, even you have previously conceded that this use case is fine.

 Really?  Where and when?    What I said was that I didn't be= lieve this draft was even conditionally secure for control systems, and that= while I thought it was a bad idea, I was fine with the lighting folk going = off and publishing it as informational for their own internal use.



And, as I've said before, if this is ONLY applicable to the lighting
people then they should go off and write an Informational "Here's how
we do it" document and not try for an internet standard.
It's not.  Lighting is not the only highly constrained case where low<= br> power budget and low latency requirements will make public key
operations expensive.  It just happens to be leading the path.

Can you think of even one other case where low cost (not low power - seriou= sly, it's a light bulb and it's plugged in) and low latency so constrain the= problem that nothing but a symmetric solution will work?  I can't.&nbs= p; And I can't remember even a suggestion that there was another one.  = Remember that the latency issues here are related to human perception and to= nothing else.

So use case other than lighting is?

I don't= see why it matters.  If we have lighting vendors who want to work with= us in ACE, why can't we devise a couple of solutions specific to their spac= e?  These questions are only relevant to the constraining language that= gets added to the draft(s). 





On the other hand, we
have some concern that the draft might be misapplied to environments
where PSK/symmetric keys should not be employed.

As Hannes wrote, security is not a black and white matter.  We need to=
acknowledge that fact.  This, to me, seems to boil down to an
applicability statement.
I don't know why people think I'm just going to let things pass
without trying to inject some rigor.

My last question:  What is the security requirement for an ACE Group comm protocol?
The answer should be as it always was: make things better.
= In what world is "make things better" a security requirement?

  The current
alternative is nothing, which is what happens today, and well beyond
lighting.  The current draft provides for use of asymmetric keying for=
group admission.  Beyond that, the choices are pretty stark: perform a= n
symmetric operation on every transaction or use a group key.

I'm not sure if you meant "perform an asymmetric operation..." or you were = stating a false dilemma by limiting the choices.  The asymmetric keying= for group admission is nothing new, and probably doesn't materially affect = the security of the protocol.

If you've got a content distribution system, then the use of group symmetri= c keys is a valid option - mainly because the compromise of an end device is= no worse than the compromise of the group key as you get access to the cont= ent by breaking into an end system.  But that's not what this is.
If you've got a one-to-many control system, then the use of group symmetric= keys is not an option, because the compromise of an end or actuator device = gives you the access to control other end or actuator devices.    = There are caveats and mitigations here dealing with key protection and secur= e elements (which cost money or power), but the general case is as stated.
ACE should be working on the general case of the security of a group contro= l system, and it's pretty clear that - for the general case - only an asymme= tric approach for "signing" the control messages has the necessary security = properties.



My current minimum bid:  Compromise of a single device shall not
result in the attacker gaining privileges over the group greater than
those nominally granted to the device being attacked.  or less
nuanced:  Compromise of a single device shall not result in the
compromise of the entire group.
And here's mine:

The group must be treated as a single device, for purpose of compromise, barring additional measures being taken at other layers.
 Um. No.  This requirement is valid if and only if each and every devic= e in the group has exactly the same privileges with respect to the group.&nb= sp; If I compromise a light switch, I get its privileges to turn on and off = the group.  If I compromise a light bulb, why should I get privileges t= o turn on and off the group?

Fine, let's= constrain it as such and move on.  There are use cases for lighting th= at do not require high security.  If you overbuild, it will not get use= d.  We just need to provide an alternate more secure solution detailing= when it is to be used at the same time a symmetric key solution is publishe= d (standards or informational track TBD).
 

I actually described the above as a possibility for say a collection/flock = of drones way back in DICE.  But even then I would suggest that hardwar= e protection of the symmetric key would be necessary for meaningful security= guarantees for any group larger than about 4 or 8.


  The advantage
of this over status quo is that today admission is open, and the threat
= surface is therefore unconstrained.  With this approach the threat
= surface is reduced to other infected group members.

I believe that your analysis is flawed.  Basically, the cost to attack= any of the entities in the lighting case approaches zero, especially if you= can physically access one.  The probability of success of attacking su= ch entities approaches unity.  The security guarantees for this are the= refore roughly equivalent to  no security at all and may be worse than = no security at all because the general public will not inquire as to what "s= ecure" means for any given case. Or put another way, this is no better than = security by obscurity.

In some scenarios= , lower security is all that is needed.  If a zone in an office buildin= g turns off when an employee leaves the room, this zone (a single device) is= compromised, worse case scenario might be a high bill for the month.  = Settings like hospitals would not be appropriate for this solution and that = should be called out explicitly.  The risk decision is always made by t= he implementor, we just need to give them the information needed to make app= ropriate decisions.  

There are any number of products that tout security in their ads or specifi= cations, but when you get under the covers you recoil in horror at finding j= ust how trivial it would be to penetrate.

Sure, but let's figure out if there is a way to do this and list appropria= te protections for the "device" or zone, etc. where a shared key is in use.<= /div>
 

I expect going forward that any device or item can be broken into with some= level of effort given physical or network access.  What I don't want t= o have happen - due to our poor choices - is making the Work Factor of the g= roup (to break in) identical to the Work Factor of breaking into a single de= vice and that's what this draft is proposing to institutionalize in the prot= ocol.  We can do better and we should.

= I thought we were working on multiple solutions and moving on?
Happy holidays!
Kathleen
 


Mike




Eliot


_______________________________________________
Ace mailing list
Ace@ietf.= org
https://www.ietf.org/mailman/listinfo/ace



--

=
Best regards,
Kathleen
_______________________________________________ Ace mailing list Ace@ietf.org https://www.ietf.org/ma= ilman/listinfo/ace --B_3565415551_456332-- From nobody Sat Dec 24 10:24:55 2016 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E95412958D for ; Sat, 24 Dec 2016 10:24:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 kmLC_qJkLBuG for ; Sat, 24 Dec 2016 10:24:51 -0800 (PST) Received: from mail-qt0-x232.google.com (mail-qt0-x232.google.com [IPv6:2607:f8b0:400d:c0d::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 433B7129552 for ; Sat, 24 Dec 2016 10:24:51 -0800 (PST) Received: by mail-qt0-x232.google.com with SMTP id p16so281371775qta.0 for ; Sat, 24 Dec 2016 10:24:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=TQFAkt6zX4xZGamUDvZ1kw7PR1iP6VtjcwE8vy+FHWM=; b=JtYwIQTC7nrq92DFZSd+mPpehAbuFcuyYjkhM6yyplfCnp9JdAn0YgSe74sbAhv+aW uM29aGL5LfYc+nyeFxapn22W9UZcG1EqiDhXadgP95ynI2Cfx3Cqxt6xcc+mf3XkzapC Zml6iAJDhJW2wzzyI9Qt4enBI7VWFa/l+sgZB0IiVz9zAApEwLh0LP063/J0b5JEV1Qg tol04WA2iTUFuVGwBYvR6CXz24Utq+7NQU/KZoiS7ma5tWklVncM0vdTVh4KrlnB1WOQ iNbww6roV6B7bwzcd5gEatYIH7rOMjmaLmjX/iEeH76JEI2qLR5nqlSa8jKr+w9fOi0r 545Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=TQFAkt6zX4xZGamUDvZ1kw7PR1iP6VtjcwE8vy+FHWM=; b=OFcS6t3T+YDz7vmR06WUs8N4ldCCY6Q5Eqa0iOzYGIKxjG0vmQD0sxGJ6nyVCAGxSz gj8JCuHgcNxjC0kZsvqL/E2SBKaworSG5dfCtOwOa6nvJSrHZnkY+xy+D1+Ci4p+cUJC AZzK8NPZFt4Qxnhp6K+hF8h/n1eSGAtb+O7cIP+DfugwIirQSCROAb89fgolyLOIHIJL Fl5LytoMn/47P7QbdX4/7mHJ4DCuTTr6KfbkH4WQ0ZWIWYKW0ucFAJ1V/YsQkicuKS/g BMze8U9WIiBacvLVOfiUEhi7tEpmkM3XnHV3vus0jQbu0ih9f9xrrDfydduUbPRmHHWD Qsig== X-Gm-Message-State: AIkVDXJxMezX1/ifdoHYh/SHwLEOBb+xKGz8Y9d6nQtNCEDo/ltbpPXsE7FhEmSYpA3Zhg== X-Received: by 10.200.37.241 with SMTP id f46mr19547508qtf.164.1482603890368; Sat, 24 Dec 2016 10:24:50 -0800 (PST) Received: from [10.0.1.4] (ool-457c4d63.dyn.optonline.net. [69.124.77.99]) by smtp.gmail.com with ESMTPSA id l2sm22766108qkc.36.2016.12.24.10.24.49 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 24 Dec 2016 10:24:49 -0800 (PST) Content-Type: multipart/alternative; boundary=Apple-Mail-1BB21614-4423-4B5D-AD43-2497F147D2E1 Mime-Version: 1.0 (1.0) From: kathleen.moriarty.ietf@gmail.com X-Mailer: iPhone Mail (14C92) In-Reply-To: Date: Sat, 24 Dec 2016 13:24:48 -0500 Content-Transfer-Encoding: 7bit Message-Id: References: <062dd7b2-48a8-ba6c-e80a-0e8f309bf12e@cisco.com> <00653595-3a01-c00b-be9b-1fe41b1e2c3d@comcast.net> To: Don Sturek Archived-At: Cc: Michael StJohns , Eliot Lear , "ace@ietf.org" Subject: Re: [Ace] where are we with draft-somarju-ace-multicast? X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Dec 2016 18:24:54 -0000 --Apple-Mail-1BB21614-4423-4B5D-AD43-2497F147D2E1 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Thanks, Don. Your input is helpful. I'd just like to see this discussion settled and to s= ee progress. The chairs are managing at this point. If justified, either c= an work with agreement. My point was more to get things moving. Thank you, Kathleen=20 Please excuse typos, sent from handheld device=20 > On Dec 24, 2016, at 12:12 PM, Don Sturek wrote: >=20 > Hi Kathleen, >=20 > Having worked on these lighting solutions and knowing the security limitat= ions, I think the Informational RFC is best. Creating a standard (even wit= h ample warnings and proposed limitations) will only end up in disappointmen= t and embarrassment when someone finds a more creative security break with t= hese solutions . >=20 > Happy holidays to all! >=20 > Don Sturek >=20 >=20 >=20 > From: Ace on behalf of Kathleen Moriarty > Date: Saturday, December 24, 2016 at 8:19 AM > To: Michael StJohns > Cc: Eliot Lear , "ace@ietf.org" > Subject: Re: [Ace] where are we with draft-somarju-ace-multicast? >=20 > We continue to go in circles on this despite efforts to mitigate or warn o= f risks and agreement to put forth an asymmetric key solution at the same ti= me. This continued DoS on this topic is serving no purpose but to delay ven= dors or send them elsewhere when they are here in ACE looking for assistance= to standardize a solution (or solutions).=20 >=20 > I thought we had some agreement to go forward with both solutions. I see M= ike is requesting that this be informational and that's one possible route, b= ut I'm not convinced. I do think we should go forward adopting the solution= s, working on them and figuring out the status and constraining language in p= arallel. inline, >=20 >> On Fri, Dec 23, 2016 at 12:41 PM, Michael StJohns w= rote: >>> On 12/23/2016 3:24 AM, Eliot Lear wrote: >>>=20 >>>> On 12/22/16 11:36 PM, Michael StJohns wrote: >>>>=20 >>>>> On 12/22/2016 3:42 AM, Eliot Lear wrote: >>>>> Hi, >>>>>=20 >>>>> This working group has been in a state of indecision about this draft >>>>> for quite some time and I would like to gain some clarity on the matte= r. >=20 > Thank you for your efforts, Eliot!=20 >>>>>=20 >>>>> On the one hand, we have a draft that there seems to be unanimous >>>>> agreement would be useful to the lighting people. >>>> Actually, we have a draft that the lighting people unanimously agree >>>> that would be useful to the lighting people. Not quite the same thing.= >>>>=20 >>> No, even you have previously conceded that this use case is fine. >>=20 >> Really? Where and when? What I said was that I didn't believe this dr= aft was even conditionally secure for control systems, and that while I thou= ght it was a bad idea, I was fine with the lighting folk going off and publi= shing it as informational for their own internal use. >>=20 >>=20 >>>=20 >>>> And, as I've said before, if this is ONLY applicable to the lighting >>>> people then they should go off and write an Informational "Here's how >>>> we do it" document and not try for an internet standard. >>> It's not. Lighting is not the only highly constrained case where low >>> power budget and low latency requirements will make public key >>> operations expensive. It just happens to be leading the path. >>=20 >> Can you think of even one other case where low cost (not low power - seri= ously, it's a light bulb and it's plugged in) and low latency so constrain t= he problem that nothing but a symmetric solution will work? I can't. And I= can't remember even a suggestion that there was another one. Remember that= the latency issues here are related to human perception and to nothing else= . >>=20 >> So use case other than lighting is? >=20 > I don't see why it matters. If we have lighting vendors who want to work w= ith us in ACE, why can't we devise a couple of solutions specific to their s= pace? These questions are only relevant to the constraining language that g= ets added to the draft(s).=20 >=20 >>=20 >>=20 >>=20 >>>=20 >>>>> On the other hand, we >>>>> have some concern that the draft might be misapplied to environments >>>>> where PSK/symmetric keys should not be employed. >>>>>=20 >>>>> As Hannes wrote, security is not a black and white matter. We need to= >>>>> acknowledge that fact. This, to me, seems to boil down to an >>>>> applicability statement. >>>> I don't know why people think I'm just going to let things pass >>>> without trying to inject some rigor. >>>>=20 >>>> My last question: What is the security requirement for an ACE Group >>>> comm protocol? >>> The answer should be as it always was: make things better. >> In what world is "make things better" a security requirement? >>=20 >>> The current >>> alternative is nothing, which is what happens today, and well beyond >>> lighting. The current draft provides for use of asymmetric keying for >>> group admission. Beyond that, the choices are pretty stark: perform an >>> symmetric operation on every transaction or use a group key. >>=20 >> I'm not sure if you meant "perform an asymmetric operation..." or you wer= e stating a false dilemma by limiting the choices. The asymmetric keying fo= r group admission is nothing new, and probably doesn't materially affect the= security of the protocol. >>=20 >> If you've got a content distribution system, then the use of group symmet= ric keys is a valid option - mainly because the compromise of an end device i= s no worse than the compromise of the group key as you get access to the con= tent by breaking into an end system. But that's not what this is. >>=20 >> If you've got a one-to-many control system, then the use of group symmetr= ic keys is not an option, because the compromise of an end or actuator devic= e gives you the access to control other end or actuator devices. There ar= e caveats and mitigations here dealing with key protection and secure elemen= ts (which cost money or power), but the general case is as stated. >>=20 >> ACE should be working on the general case of the security of a group cont= rol system, and it's pretty clear that - for the general case - only an asym= metric approach for "signing" the control messages has the necessary securit= y properties. >>=20 >>=20 >>>=20 >>>> My current minimum bid: Compromise of a single device shall not >>>> result in the attacker gaining privileges over the group greater than >>>> those nominally granted to the device being attacked. or less >>>> nuanced: Compromise of a single device shall not result in the >>>> compromise of the entire group. >>> And here's mine: >>>=20 >>> The group must be treated as a single device, for purpose of compromise,= >>> barring additional measures being taken at other layers. >>=20 >> Um. No. This requirement is valid if and only if each and every device i= n the group has exactly the same privileges with respect to the group. If I= compromise a light switch, I get its privileges to turn on and off the grou= p. If I compromise a light bulb, why should I get privileges to turn on and= off the group? >=20 > Fine, let's constrain it as such and move on. There are use cases for lig= hting that do not require high security. If you overbuild, it will not get u= sed. We just need to provide an alternate more secure solution detailing wh= en it is to be used at the same time a symmetric key solution is published (= standards or informational track TBD). > =20 >>=20 >> I actually described the above as a possibility for say a collection/floc= k of drones way back in DICE. But even then I would suggest that hardware p= rotection of the symmetric key would be necessary for meaningful security gu= arantees for any group larger than about 4 or 8. >>=20 >>=20 >>=20 >>> The advantage >>> of this over status quo is that today admission is open, and the threat >>> surface is therefore unconstrained. With this approach the threat >>> surface is reduced to other infected group members. >>=20 >> I believe that your analysis is flawed. Basically, the cost to attack an= y of the entities in the lighting case approaches zero, especially if you ca= n physically access one. The probability of success of attacking such entit= ies approaches unity. The security guarantees for this are therefore roughl= y equivalent to no security at all and may be worse than no security at all= because the general public will not inquire as to what "secure" means for a= ny given case. Or put another way, this is no better than security by obscur= ity. >=20 > In some scenarios, lower security is all that is needed. If a zone in an o= ffice building turns off when an employee leaves the room, this zone (a sing= le device) is compromised, worse case scenario might be a high bill for the m= onth. Settings like hospitals would not be appropriate for this solution an= d that should be called out explicitly. The risk decision is always made by= the implementor, we just need to give them the information needed to make a= ppropriate decisions. =20 >>=20 >> There are any number of products that tout security in their ads or speci= fications, but when you get under the covers you recoil in horror at finding= just how trivial it would be to penetrate. >=20 > Sure, but let's figure out if there is a way to do this and list appropria= te protections for the "device" or zone, etc. where a shared key is in use. > =20 >>=20 >> I expect going forward that any device or item can be broken into with so= me level of effort given physical or network access. What I don't want to h= ave happen - due to our poor choices - is making the Work Factor of the grou= p (to break in) identical to the Work Factor of breaking into a single devic= e and that's what this draft is proposing to institutionalize in the protoco= l. We can do better and we should. >=20 > I thought we were working on multiple solutions and moving on? >=20 > Happy holidays! > Kathleen > =20 >>=20 >>=20 >> Mike >>=20 >>=20 >>=20 >>>=20 >>> Eliot >>>=20 >>=20 >> _______________________________________________ >> Ace mailing list >> Ace@ietf.org >> https://www.ietf.org/mailman/listinfo/ace >=20 >=20 >=20 > --=20 >=20 > Best regards, > Kathleen > _______________________________________________ Ace mailing list Ace@ietf.= org https://www.ietf.org/mailman/listinfo/ace --Apple-Mail-1BB21614-4423-4B5D-AD43-2497F147D2E1 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Thanks, Don.

Your input is helpful. &= nbsp;I'd just like to see this discussion settled and to see progress.  = ;The chairs are managing at this point.  If justified, either can work w= ith agreement.  My point was more to get things moving.

Thank you,
Kathleen 

Please excuse typos, s= ent from handheld device 

On Dec 24, 2016, at 12:12 PM, D= on Sturek <d.sturek@att.net> w= rote:

Hi Kathleen,

Having worked on these lighting solutions and knowing the s= ecurity limitations, I think the Informational RFC is best.   Creating a= standard (even with ample warnings and proposed limitations) will only end u= p in disappointment and embarrassment when someone finds a more creative sec= urity break with these solutions .

Happy holidays t= o all!

Don Sturek



From: Ace <ace-bounces@ietf.org> on behalf o= f Kathleen Moriarty <= kathleen.moriarty.ietf@gmail.com>
Date: Saturday, December 24, 2016 at 8:19 AM
To: Michael StJohns <mstjohns@comcast.net>
C= c: Eliot Lear <lear@cisco.com>, "ace@ietf.org" <ace@ietf.org>
= Subject: Re: [Ace] where are we with draft-somarju-ace-multicast?

We continue to go in circles on this d= espite efforts to mitigate or warn of risks and agreement to put forth an as= ymmetric key solution at the same time.  This continued DoS on this top= ic is serving no purpose but to delay vendors or send them elsewhere when th= ey are here in ACE looking for assistance to standardize a solution (or solu= tions).  

I thought we had some agreement to go forw= ard with both solutions.  I see Mike is requesting that this be informa= tional and that's one possible route, but I'm not convinced.  I do thin= k we should go forward adopting the solutions, working on them and figuring o= ut the status and constraining language in parallel. inline,

On Fri, Dec 23, 2016 at 12:4= 1 PM, Michael StJohns <mstjohns@comcast.net> wrote:
On 12/23/2016 3:24 AM, Eliot Lear= wrote:

On 12/22/16 11:36 PM, Michael StJohns wrote:
Hi,

This working group has been in a state of indecision about this draft
for quite some time and I would like to gain some clarity on the matter.
=

Thank you for your efforts, Eliot! 

On the one hand, we have a draft that there seems to be unanimous
agreement would be useful to the lighting people.
Actually, we have a draft that the lighting people unanimously agree
that would be useful to the lighting people.  Not quite the same thing.=

No, even you have previously conceded that this use case is fine.

Really?  Where and when?    What I said was that I didn't bel= ieve this draft was even conditionally secure for control systems, and that w= hile I thought it was a bad idea, I was fine with the lighting folk going of= f and publishing it as informational for their own internal use.



And, as I've said before, if this is ONLY applicable to the lighting
people then they should go off and write an Informational "Here's how
we do it" document and not try for an internet standard.
It's not.  Lighting is not the only highly constrained case where low power budget and low latency requirements will make public key
operations expensive.  It just happens to be leading the path.

Can you think of even one other case where low cost (not low power - serious= ly, it's a light bulb and it's plugged in) and low latency so constrain the p= roblem that nothing but a symmetric solution will work?  I can't. = And I can't remember even a suggestion that there was another one.  Re= member that the latency issues here are related to human perception and to n= othing else.

So use case other than lighting is?

I don't s= ee why it matters.  If we have lighting vendors who want to work with u= s in ACE, why can't we devise a couple of solutions specific to their space?=   These questions are only relevant to the constraining language that g= ets added to the draft(s). 





On the other hand, we
have some concern that the draft might be misapplied to environments
where PSK/symmetric keys should not be employed.

As Hannes wrote, security is not a black and white matter.  We need to<= br> acknowledge that fact.  This, to me, seems to boil down to an
applicability statement.
I don't know why people think I'm just going to let things pass
without trying to inject some rigor.

My last question:  What is the security requirement for an ACE Group comm protocol?
The answer should be as it always was: make things better.
<= /span> In what world is "make things better" a security requirement?

  The current
alternative is nothing, which is what happens today, and well beyond
lighting.  The current draft provides for use of asymmetric keying for<= br> group admission.  Beyond that, the choices are pretty stark: perform an=
symmetric operation on every transaction or use a group key.

I'm not sure if you meant "perform an asymmetric operation..." or you were s= tating a false dilemma by limiting the choices.  The asymmetric keying f= or group admission is nothing new, and probably doesn't materially affect th= e security of the protocol.

If you've got a content distribution system, then the use of group symmetric= keys is a valid option - mainly because the compromise of an end device is n= o worse than the compromise of the group key as you get access to the conten= t by breaking into an end system.  But that's not what this is.

= If you've got a one-to-many control system, then the use of group symmetric k= eys is not an option, because the compromise of an end or actuator device gi= ves you the access to control other end or actuator devices.    Th= ere are caveats and mitigations here dealing with key protection and secure e= lements (which cost money or power), but the general case is as stated.
<= br> ACE should be working on the general case of the security of a group control= system, and it's pretty clear that - for the general case - only an asymmet= ric approach for "signing" the control messages has the necessary security p= roperties.



My current minimum bid:  Compromise of a single device shall not
result in the attacker gaining privileges over the group greater than
those nominally granted to the device being attacked.  or less
nuanced:  Compromise of a single device shall not result in the
compromise of the entire group.
And here's mine:

The group must be treated as a single device, for purpose of compromise,
= barring additional measures being taken at other layers.
 Um. No.  This requirement is valid if and only if each and every device= in the group has exactly the same privileges with respect to the group.&nbs= p; If I compromise a light switch, I get its privileges to turn on and off t= he group.  If I compromise a light bulb, why should I get privileges to= turn on and off the group?

Fine, let's c= onstrain it as such and move on.  There are use cases for lighting that= do not require high security.  If you overbuild, it will not get used.=   We just need to provide an alternate more secure solution detailing w= hen it is to be used at the same time a symmetric key solution is published (= standards or informational track TBD).
 

I actually described the above as a possibility for say a collection/flock o= f drones way back in DICE.  But even then I would suggest that hardware= protection of the symmetric key would be necessary for meaningful security g= uarantees for any group larger than about 4 or 8.


  The advantage
of this over status quo is that today admission is open, and the threat
surface is therefore unconstrained.  With this approach the threat
surface is reduced to other infected group members.

I believe that your analysis is flawed.  Basically, the cost to attack a= ny of the entities in the lighting case approaches zero, especially if you c= an physically access one.  The probability of success of attacking such= entities approaches unity.  The security guarantees for this are there= fore roughly equivalent to  no security at all and may be worse than no= security at all because the general public will not inquire as to what "sec= ure" means for any given case. Or put another way, this is no better than se= curity by obscurity.

In some scenarios, l= ower security is all that is needed.  If a zone in an office building t= urns off when an employee leaves the room, this zone (a single device) is co= mpromised, worse case scenario might be a high bill for the month.  Set= tings like hospitals would not be appropriate for this solution and that sho= uld be called out explicitly.  The risk decision is always made by the i= mplementor, we just need to give them the information needed to make appropr= iate decisions.  

There are any number of products that tout security in their ads or specific= ations, but when you get under the covers you recoil in horror at finding ju= st how trivial it would be to penetrate.

Sure, but let's figure out if there is a way to do this and list appropriat= e protections for the "device" or zone, etc. where a shared key is in use.
 

I expect going forward that any device or item can be broken into with some l= evel of effort given physical or network access.  What I don't want to h= ave happen - due to our poor choices - is making the Work Factor of the grou= p (to break in) identical to the Work Factor of breaking into a single devic= e and that's what this draft is proposing to institutionalize in the protoco= l.  We can do better and we should.

I t= hought we were working on multiple solutions and moving on?

Happy holidays!
Kathleen
 


Mike




Eliot


_______________________________________________
Ace mailing list
Ace@ie= tf.org
https://www.ietf.org/mailman/listinfo/ace<= /a>



-= -

Best regards,
Kathleen
_______________________________________________ Ace mailing list Ace@ietf.org https://www.ietf.org/m= ailman/listinfo/ace = --Apple-Mail-1BB21614-4423-4B5D-AD43-2497F147D2E1-- 

Eliot





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