From nobody Sat Sep 3 13:49:04 2016 Return-Path: X-Original-To: ace@ietf.org Delivered-To: ace@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CF3FA12B0EC; Sat, 3 Sep 2016 13:48:59 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.31.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147293573984.2361.7909873056048742911.idtracker@ietfa.amsl.com> Date: Sat, 03 Sep 2016 13:48:59 -0700 Archived-At: Cc: ace@ietf.org Subject: [Ace] I-D Action: draft-ietf-ace-actors-04.txt X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.17 List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Sep 2016 20:49:00 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Authentication and Authorization for Constrained Environments of the IETF. Title : An architecture for authorization in constrained environments Authors : Stefanie Gerdes Ludwig Seitz Goeran Selander Carsten Bormann Filename : draft-ietf-ace-actors-04.txt Pages : 32 Date : 2016-09-03 Abstract: Constrained-node networks are networks where some nodes have severe constraints on code size, state memory, processing capabilities, user interface, power and communication bandwidth (RFC 7228). This document provides terminology, and identifies the elements that an architecture needs to address, providing a problem statement, for authentication and authorization in these networks. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ace-actors/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-ace-actors-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ace-actors-04 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. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sat Sep 3 13:57: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 2D56312B0AD for ; Sat, 3 Sep 2016 13:57:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.7 X-Spam-Level: X-Spam-Status: No, score=-0.7 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_LOW=-0.7] 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 30O-kCqRTUl4 for ; Sat, 3 Sep 2016 13:57:00 -0700 (PDT) Received: from relay3-d.mail.gandi.net (relay3-d.mail.gandi.net [IPv6:2001:4b98:c:538::195]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 383E712B0F3 for ; Sat, 3 Sep 2016 13:56:58 -0700 (PDT) Received: from mfilter32-d.gandi.net (mfilter32-d.gandi.net [217.70.178.163]) by relay3-d.mail.gandi.net (Postfix) with ESMTP id 18BFAA80C4; Sat, 3 Sep 2016 22:56:56 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at mfilter32-d.gandi.net Received: from relay3-d.mail.gandi.net ([IPv6:::ffff:217.70.183.195]) by mfilter32-d.gandi.net (mfilter32-d.gandi.net [::ffff:10.0.15.180]) (amavisd-new, port 10024) with ESMTP id Ue3pdhZ2SeDc; Sat, 3 Sep 2016 22:56:54 +0200 (CEST) X-Originating-IP: 93.199.227.76 Received: from nar-4.local (p5DC7E34C.dip0.t-ipconnect.de [93.199.227.76]) (Authenticated sender: cabo@cabo.im) by relay3-d.mail.gandi.net (Postfix) with ESMTPSA id 1E389A80C7; Sat, 3 Sep 2016 22:56:53 +0200 (CEST) Message-ID: <57CB3913.80005@tzi.org> Date: Sat, 03 Sep 2016 22:56:51 +0200 From: Carsten Bormann User-Agent: Postbox 4.0.8 (Macintosh/20151105) MIME-Version: 1.0 To: ace@ietf.org References: <147293573984.2361.7909873056048742911.idtracker@ietfa.amsl.com> In-Reply-To: <147293573984.2361.7909873056048742911.idtracker@ietfa.amsl.com> X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Ace] I-D Action: draft-ietf-ace-actors-04.txt 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, 03 Sep 2016 20:57:02 -0000 As you can see, the work on the actors draft has resumed. We were driven to submit an intermediate version (that addresses mostly comments by Michael Richardson) to keep the draft from expiring. A version that addresses all the outstanding comments will follow. Grüße, Carsten > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-ace-actors-04 From nobody Tue Sep 6 01:29:50 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 B116112B15A for ; Tue, 6 Sep 2016 01:29:48 -0700 (PDT) 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, DKIM_SIGNED=0.1, DKIM_VALID=-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.20150623.gappssmtp.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 ct0Ni_5hFZfz for ; Tue, 6 Sep 2016 01:29:46 -0700 (PDT) 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 7EE2412B162 for ; Tue, 6 Sep 2016 01:29:46 -0700 (PDT) Received: by mail-lf0-x22a.google.com with SMTP id l131so47100324lfl.2 for ; Tue, 06 Sep 2016 01:29:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sics-se.20150623.gappssmtp.com; s=20150623; h=to:from:subject:message-id:date:user-agent:mime-version; bh=Zv6se0aqZKzWZSaUSLM40YG19zUkmhC1OGvkrtAE/Jc=; b=rNab8E4Jw1hYRZ0XB3KsFXpnHNLya252rvzmXKWNRkNLWmwbYL8iXu2C5a6myWgBXP RtZk34xrdJ0JtNy5Gg/Arclqga0rReNgIAfp3bNW8s6gDchLqY4fkgWxxetEP/vd4bLP vzrVqyNgexsKrfJbZvJZ/WVUFON0tePJXntO25mcSTO2c8liWVCMKKWypShiIbZu82Hq f/5Cxt3Oy38ecmsaMzSMcg+yI1SQzuXAqaWPvucGp6P4GzOcSN/FsT/VgXvIF1yFyTEV W7NT8hTrHrhjGx3XLinqtegeZKKb9yclcze+XgVmBnJxIO77Ks0MtCD7HceEAGk+f1TI MBJw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:to:from:subject:message-id:date:user-agent :mime-version; bh=Zv6se0aqZKzWZSaUSLM40YG19zUkmhC1OGvkrtAE/Jc=; b=NtC9tHj+RCbI6kbUdXJQlFUU/68ut/mYAfHBWCMJujcIrWqQ1DB3y86GQol244EX30 FYIwKflPFzzMwIbqYYdmJwNZ4sXPVqqi47OC5KZOW4LIM/d3P3pUAJKNYVPJQbhidups 1ZqW214QhhS70mjBFGX8txHKrk9tLoAIFSBd21Ae7Xo9tfdVX3liPX01Aq6GRdbAGbTS tJSNVCShzDG+btLZWggpkgCjsDJdWeS9x22CMB5t6P4rbfBGywS4uBeUFHOeVxawHHjY 7BIXWgRG5Kps/rh9YbEOAVW+iyXdJL7ZqqtvqJ1lXsGDTV0vt0FDtBUZIT8/PmMl6K98 a30w== X-Gm-Message-State: AE9vXwNB+dQBrXiAtE/oVqQySazfsnSO+AGtuYdVhrj1k5Fj6N2zb3PvOPCd+RbWO3QPopg2 X-Received: by 10.25.205.200 with SMTP id d191mr11991002lfg.212.1473150584025; Tue, 06 Sep 2016 01:29:44 -0700 (PDT) Received: from [192.168.0.166] ([85.235.12.155]) by smtp.gmail.com with ESMTPSA id s21sm1148403lfg.13.2016.09.06.01.29.42 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 06 Sep 2016 01:29:42 -0700 (PDT) To: "ace@ietf.org" From: Ludwig Seitz Message-ID: <5a08bd70-697f-55e8-74bd-9d99046d1f7a@sics.se> Date: Tue, 6 Sep 2016 10:29:42 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms040805020008040509050307" Archived-At: Subject: [Ace] Java library for CWTs 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: Tue, 06 Sep 2016 08:29:49 -0000 This is a cryptographically signed message in MIME format. --------------ms040805020008040509050307 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Hello ACE, I have uploaded a small Java library for handling CWTs. I am planning to = make this part of a larger library for draft-ietf-ace-oauth-authz, but I = thought this might be useful on its own. Please feel free to test it and suggest improvements. https://github.com/LudwigSeitz/CWT-Java /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 --------------ms040805020008040509050307 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 MBwGCSqGSIb3DQEJBTEPFw0xNjA5MDYwODI5NDJaMC8GCSqGSIb3DQEJBDEiBCChYMGY5iFA 2htF5n+7A3LcChSv8ZfHS9X/Ln/vq6fPiTBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQB KjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMC AgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkG A1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENl cnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVu dCBDQQIQFOEHMTFC2qLTcvGM5tqREjCBnAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRp ZmljYXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBD QQIQFOEHMTFC2qLTcvGM5tqREjANBgkqhkiG9w0BAQEFAASCAQB6/NylTdpO9s4sRu/oX99+ rYswPKBEJ+7JDVwSni9qfPm4aAi7qJAAX4fHqhvMQnF2Qu5d3WdJ6bSa0HIyVOLnk/B02YVE B923Cekk4LLZNCn7R05yOnQjKfGd9lqmii/smuQmUxlybagQkvtmMpwJdOW0k3rbJ/CYbHAz +JAtVWPg8nSz/la3VOudQIMYkEfJiDR2d1cqYJbLnUAaW5qjqb5W3TqE1pQ+gC+JLPivhdRF Ve4i8YnXB0qgM3fmjwgv+YqJHEzU9hhDJUTmmmRPqbrUj78b075ndqr9iOS9VM/b5qXwC4nU VTYn1Bdyp8YZJ9ebaDFzWuP6mRfIRIa1AAAAAAAA --------------ms040805020008040509050307-- From nobody Fri Sep 9 12:44:26 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 A2D1912B31E for ; Fri, 9 Sep 2016 12:44:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.208 X-Spam-Level: X-Spam-Status: No, score=-4.208 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=-1.508, 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 D2qA4BhxXg9R for ; Fri, 9 Sep 2016 12:44:23 -0700 (PDT) Received: from resqmta-po-10v.sys.comcast.net (resqmta-po-10v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:169]) (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 7729712B1B8 for ; Fri, 9 Sep 2016 12:44:23 -0700 (PDT) Received: from resomta-po-09v.sys.comcast.net ([96.114.154.233]) by resqmta-po-10v.sys.comcast.net with SMTP id iRiobNlcgHqoliRipbI2Bz; Fri, 09 Sep 2016 19:44:23 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1473450263; bh=l99agh8L5d8PAVNDh9blpCoT998V24zjfJLWh9igoyI=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=nYTyaJd6/KX0bP2qRHF4cxnFvekuxkjXMC2GdRcPkgwmcwqtIwguUdxsWv4gRHQ2d v6d8GnxpFw1eG6uW7IwbKwXZWSr8pKDIAHt9n5iWb4ohY6n9NSgKNhkeiu8Qy35nGn CBq2VJEOP8B1fiaD4f3ukkNYgXoq1MQhNFf9ZdNcpo8l5653jIb6YbyCD6RuzqvBqy bOOfXuM9xt68hsP5FZzEKkzc+txVTh0qdw+/focogUn58io1uRAkDVfzzP9By0FUxM QOKWfuIFX0zTfCxwfFrKct78zYrHmkQ6ZNUBZvLodZB9UL8sU6lK+weZd2D4Hzu4uY nwSm3g39ObO4g== Received: from [IPv6:2601:148:c000:1951:706d:c8d9:732d:7bd7] ([IPv6:2601:148:c000:1951:706d:c8d9:732d:7bd7]) by resomta-po-09v.sys.comcast.net with SMTP id iRinbx7NtsFLXiRiobY1K2; Fri, 09 Sep 2016 19:44:22 +0000 References: <57909032.10809@gmx.net> <6d259c5b-28e3-c748-4590-0c9f942fe343@comcast.net> <378a0359-6b31-a30c-af28-8ea567b06b00@cisco.com> <57963480.2000809@gmx.net> <0d4c6d56-ebb5-2f43-d555-29c336396033@ericsson.com> <15169.1469642303@obiwan.sandelman.ca> <3271.1469656595@obiwan.sandelman.ca> <32aa7104-70df-80c7-8d6e-537b66716de9@comcast.net> <13663.1469714549@obiwan.sandelman.ca> <9a4153f1-6a96-0ae6-020b-0f0f966aecdf@cisco.com> To: "ace@ietf.org" From: Michael StJohns Message-ID: <95997f84-2715-3287-39d3-45d6ff5f3ea0@comcast.net> Date: Fri, 9 Sep 2016 15:44:21 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <9a4153f1-6a96-0ae6-020b-0f0f966aecdf@cisco.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-CMAE-Envelope: MS4wfBw0JUnugRjmQDYxZhz/q4QhDHOo3PJQnrImOgY/I6y6UkUUkeP7dp9HROGsge9JlK0HZ9BVYjExQZEsOSUl5aCCxt+bBGg/QdJMhHdjqRvpOOrBAjiB WRYwpBmatoICRzaGvGRkyl7EOKdZ+xAo/ly0qXxCAdi3WnlP4PspG2jQXLlCD4V4JNkGZl1rcMxb6g== Archived-At: Subject: Re: [Ace] Group Communication Security Disagreements 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 Sep 2016 19:44:24 -0000 Hi - It's been over a month since there's been any further discussion on this topic. Given the record I would suggest a lack of consensus to proceed on basis of two items: 1) A roughly even split on the vocal yays and nays on the subject of symmetric key multicast for control functions and 2) a failure to address the specific concern of "How do you enforceably keep a cheap, unsafe-in-the-broader-internet security mechanism off the broader internet?" Your mileage may vary. Mike From nobody Fri Sep 9 17:49: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 1C72A12B201 for ; Fri, 9 Sep 2016 11:36:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=plcm365.onmicrosoft.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 7iy_Q0vAMUab for ; Fri, 9 Sep 2016 11:36:12 -0700 (PDT) Received: from mail1.bemta12.messagelabs.com (mail1.bemta12.messagelabs.com [216.82.251.17]) (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 3730A12B1E1 for ; Fri, 9 Sep 2016 11:36:12 -0700 (PDT) Received: from [216.82.251.38] by server-17.bemta-12.messagelabs.com id 31/80-32635-B1103D75; Fri, 09 Sep 2016 18:36:11 +0000 X-Brightmail-Tracker: H4sIAAAAAAAAA1WTfUwTZxzH+/ReeiI1R4Hxs8GojRlGbbUkaon /+MdUNNGYaIZx03nFsz29luauOnRZrDa6FGGK4gvgggYr24CYocZXqtaoARSV+kJ0VnmZUQgS G8VYZV2vT1X23+eez/ee+32fPMcQOo9Gz/DFbl5ycqKBTiFLI3P/MI5FoYIZkUCu5d1QKWH5r WKJxX8uTFlCNdJcMr984DWZX/HhLyq/tukSnX/s2Hv1UnIlJTitRcVrKLt/3wna9Xx98Zt9Lg 8a5EsQwwC7EM7e0JegFEbHXkdw1fuIUh5I9hcCHrfXECVoVNz8qgbfxXk4dRVBt9+vUQTNzgL v4Eda2SmDnQgPuzklQ7CNCHaUtyQy6awV7rd41ApnsDb4uPuxBrMJhu9upxUm2UkQ7voHKaxl v4dXXX0JRuxX8K61IfEuwWbBo96aBAObAV1322jMmfCy518K51fBlVhPMjMB7h+s1mBeDJHBQ KIZsGUEVB+qpLCYD8EGL8JHsQEiD3LwsgjBvfVqnI8Xrnx2msQiGzpjb0ksOmgYenNTg4+oEK p9JyncWA9P7vkQ5mx48XczhRuUIogdWI5bpkFLZS+5B+VUjShXNSJWNSKG11fCifJeDWYjnA9 cJjCPhzMDh5M8DXY+bUvyVDh+tD/Jc+BQ9AqNeSJU7OpK7jMT+q+9RkfQ6D/RZJmXNvGS0Zxn skqCze52cIJoNJtzTQ5eljkbL3JW2VRY5GhC8du4VaVCZ1HFtkVBNJZRGzK1Tc0dBbox1qK1m +2cbP9B2ijychBlM4wBtJmqUIEuTeJtfPE6QYxf6U8amFRDhlataK3s4hyyYMOqFRmZof3hRr WOdBY5eX2WllFCrBKyb3R+3uLTj9GBxunTtUilUulSXbzkENz/930oi0GGdO1wLD5lquB0f/5 SX3wIdXwIXettZQg390XpPUjX3x49XBfo/85bmFcaCv1Il0THrRVybyzvtnb+vCylnqj37Em7 wOSdXvx7Q/sO0e9bsSwwufblGO/OSV9PvzO9ip4dc81euuXb6ILO6LzV6Lxpg0mwu3aFnw6nm GvrJkTMM98eEE/1lOVa2wpebQ/n3Br4yWdp7iTXBWcsEMu+uW0gZTtnnkJIMvcfiEuAexMEAA A= X-Env-Sender: Mahalingam.Mani@Polycom.com X-Msg-Ref: server-9.tower-163.messagelabs.com!1473446162!82088377!19 X-Originating-IP: [140.242.64.169] X-StarScan-Received: X-StarScan-Version: 8.84; banners=-,-,- X-VirusChecked: Checked Received: (qmail 141114 invoked from network); 9 Sep 2016 18:36:09 -0000 Received: from mailrelay.polycom.com (HELO SACWPEXEDGE02V.polycom.com) (140.242.64.169) by server-9.tower-163.messagelabs.com with DHE-RSA-AES256-GCM-SHA384 encrypted SMTP; 9 Sep 2016 18:36:09 -0000 X-CrossPremisesHeadersFilteredBySendConnector: SACWPEXEDGE02V.polycom.com Received: from NAM02-BL2-obe.outbound.protection.outlook.com (207.46.163.82) by mailrelay.polycom.com (10.244.6.169) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Fri, 9 Sep 2016 11:36:07 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=plcm365.onmicrosoft.com; s=selector1-polycom-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=IwI7RYAqnIV2XDfz378DFNZ0e/zTsT+Hdx0dDS0G7gE=; b=ulItMY6HO9txA1GtKIuCkfWhtARwIbSEjHVdJmXQ5w6axCgp7AMgY3Qqj5ARGtP+yEHKpLJZrrwJWFKHW41nJDv6zEQJ1A674uYWugrQapxYJXFHL55pf62f33Vvxjf/sjZNY9Gw1paTAHcMbZZ/hXo/oX9cdYAcaJI5ViJzOFY= Received: from BY2PR10MB0725.namprd10.prod.outlook.com (10.163.110.23) by BY2PR10MB0725.namprd10.prod.outlook.com (10.163.110.23) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.599.9; Fri, 9 Sep 2016 18:36:04 +0000 Received: from BY2PR10MB0725.namprd10.prod.outlook.com ([10.163.110.23]) by BY2PR10MB0725.namprd10.prod.outlook.com ([10.163.110.23]) with mapi id 15.01.0599.016; Fri, 9 Sep 2016 18:36:04 +0000 From: "Mani, Mahalingam" To: "ace@ietf.org" Thread-Topic: CfP: Proposals invited for IoT Track: Real-Time Conference 2016, IIT, Chicago, Oct 18.20 Thread-Index: AdIKyI/sqaAZ/fioRwyGi9k7FG6G5g== Date: Fri, 9 Sep 2016 18:36:03 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [140.242.18.3] x-ms-office365-filtering-correlation-id: 4474d445-68df-467c-1a28-08d3d8e027ba x-microsoft-exchange-diagnostics: 1; BY2PR10MB0725; 20:SZ8nOfWBsQXaPR/J/I3h0qTciiKW95hmZWa3A4alxX34p8Uf08rrnZsXVugtAX+N9rRQv1A1ZqNzOxd+xzGiFn5gzzDXJawrXbCffPHJUtEdMKnvrL2oq/skwVzU0dMO4kkhUCA/xPfY3Yv32J7Z+cRYDagtAmmEprnmBAZ+gzQrYkJ5A6pJwMIzBt9z5CfnDyZGPqYxuviKVVtfYk5Ll9PvCMaBKvAp9AJVAU9Y3ebErdSU68cBiFN5+upw2X8fjTyAgRyCdrlZZaw3DvBt17RwsFNFkZXLvOg9bjc31JaNBC5SzbRia4SQ5pSl4g7EouFnrAen98obXzozlp7gpQ== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR10MB0725; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(278428928389397)(209352067349851)(95692535739014)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(102415321)(6040176)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046); SRVR:BY2PR10MB0725; BCL:0; PCL:0; RULEID:; SRVR:BY2PR10MB0725; x-forefront-prvs: 00603B7EEF x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(199003)(30513003)(189002)(19625215002)(5002640100001)(189998001)(586003)(10400500002)(2351001)(7846002)(50986999)(86362001)(102836003)(3846002)(122556002)(87936001)(5630700001)(54356999)(74316002)(7066003)(19300405004)(2906002)(19580405001)(5640700001)(7906003)(99936001)(229853001)(19580395003)(2900100001)(5660300001)(19617315012)(11100500001)(92566002)(97736004)(15975445007)(101416001)(76576001)(105586002)(16236675004)(561944003)(99286002)(66066001)(33656002)(68736007)(7736002)(4326007)(2501003)(790700001)(81166006)(77096005)(3280700002)(8676002)(106356001)(110136002)(9326002)(81156014)(6116002)(8936002)(9686002)(3660700001)(1730700003)(7696004); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR10MB0725; H:BY2PR10MB0725.namprd10.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: Polycom.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0033_01D20A8E.579CE6E0" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Sep 2016 18:36:03.7731 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: d0880d3f-e6d1-4a41-9e81-b8fbcddf7b6c X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR10MB0725 X-OriginatorOrg: polycom.com X-OrganizationHeadersPreserved: SACWPEXEDGE02V.polycom.com Archived-At: X-Mailman-Approved-At: Fri, 09 Sep 2016 17:49:20 -0700 Cc: "hannes.tschofenig@gmx.net" , "kepeng.lkp@alibaba-inc.com" , "Gonzalo Salgueiro \(gsalguei\)" Subject: [Ace] CfP: Proposals invited for IoT Track: Real-Time Conference 2016, IIT, Chicago, Oct 18.20 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 Sep 2016 18:36:14 -0000 ------=_NextPart_000_0033_01D20A8E.579CE6E0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0034_01D20A8E.579CE6E0" ------=_NextPart_001_0034_01D20A8E.579CE6E0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hello, This is a call for Topic proposals to speak at the IoT Track (http://www.rtc-conference.com/2016/schedule/) for the annual Real-Time Conference (http://www.rtc-conference.com/) at IIT , Chicago. The conference is Oct 18-20 (next month): the IoT tracks are on Oct 19 & 20. (Apologies for a relatively short notice) This call for proposal is for speaking on a relevant Topic: this IoT Track invites topics relevant to use-cases describing work done or being done in interacting with or embedding and enhancing experiences in Real-time Applications and Services. Each speaker slot will be 30-45 minutes duration. We encourage submitting topic proposals online : http://www.rtc-conference.com/2016/submit-presentation-for-conference/ Should you have any questions feel free to email the chairs for IoT Track: Gonzalo Salgueiro (gsalguei@cisco.com ) or Mahalingam Mani (mmani@polycom.com ) Thanks, -IoT Track chairs for IIT RTC (Gonzalo Salgueiro, Mahalingam Mani) ------=_NextPart_001_0034_01D20A8E.579CE6E0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello,

 

This is a = call for Topic proposals to speak at the IoT Track (http://www.rtc-conf= erence.com/2016/schedule/) for the annual Real-Time Conference (http://www.rtc-conference.com/) at IIT, Chicago.

The conference is Oct 18-20 (next month): the IoT = tracks are on Oct 19 & 20. (Apologies for a relatively short = notice)

 

This call for proposal is for speaking on a relevant = Topic: this IoT Track invites topics relevant to use-cases describing = work done or being done in interacting with or embedding and enhancing = experiences in Real-time Applications and Services.

 

Each speaker = slot will be 30-45 minutes duration.

 

We encourage = submitting topic proposals online: http://www.rtc-conference.com/2016/submit-presentation-for-confere= nce/

 

Should you have any questions feel free to email the = chairs for IoT Track: Gonzalo Salgueiro (gsalguei@cisco.com) or Mahalingam = Mani (mmani@polycom.com)

 

Thanks,

-IoT Track = chairs for IIT RTC (Gonzalo Salgueiro, Mahalingam Mani)

 

------=_NextPart_001_0034_01D20A8E.579CE6E0-- ------=_NextPart_000_0033_01D20A8E.579CE6E0 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIITkTCCBQ0w ggL1oAMCAQICEBrVY02YeFKcQ+zVfznU/o4wDQYJKoZIhvcNAQEFBQAwGTEXMBUGA1UEAxMOUG9s eWNvbS1Sb290Q0EwHhcNMTMxMTA0MTg1NzA2WhcNMjMxMTA0MTkwNjU4WjAZMRcwFQYDVQQDEw5Q b2x5Y29tLVJvb3RDQTCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBAMzj+6krY3OF7mtq +O2/yC5heUML7DFZn2cp0Mkp/vos7TDrysGdPDdEIK+zYvZQZs6TrGzPh0XXnEpMcHE7V4nD5zN3 VX0+Zg46w0wCHdkgq/GV3EKlyg0AsX8LgooGlUMeuUNpe+sT0WBl3mXB97TUw7mnRLY1m/IAlyFv 4XO8LfQ1L03vfLBRAVft7xc9Okm6DbHrPxFx9VKpgIkSIUvIx/BK0zXBa/0arWW3tfimfY9t5KdJ Wqb68E8Nb0bD8S0Ve0O76TCR4dVE/HmVj6YrauGcUGfvB4yT+bOOCGlsOw3NoHW2G9PZJF9B9PvV cWzv9Jw3AlzGU2sQMbVD1ZiiRgkG47bvqvi/tg38vWEDMj1lzSpMp/FhC8YrSaGb4YwjM52w9MXM DNypbOFZ/0WjrykwuGB1P9Ga38nRlaMkMJ3lE7P1pQMgxElO5uE+1TI5kTJ9mIGgQtQb57w4vkkJ kHNKjmqzOo3IFkhEIUS3ARPkYG4HWzP7xtmcYBoEx4QwpbxYQKKcxN9h/zuv9LYc79WvnF+i+aj0 1YJKoldsPnIXhG3HullYVQb+v19q8cqm0OGUEq7e2wY72H6JiT6YFc5kZitpZ65L5d1OGVLyFO6b iC79ARA9eBE5L3g9zF/du+U1k9L6LWW3VaHr3ZDCECU8ZX5QeBrqv2aTb0VNAgMBAAGjUTBPMAsG A1UdDwQEAwIBhjAPBgNVHRMBAf8EBTADAQH/MB0GA1UdDgQWBBSMD03mpjCj/UgRICWESaXA53z3 0TAQBgkrBgEEAYI3FQEEAwIBADANBgkqhkiG9w0BAQUFAAOCAgEAs02vFW5Je6895ZBWadxy5vxR z2imWk97qU2sMFSMnmf9QeqPwdawGO33zWr1sSQr8d67AHQc+3ihZuoAaeQAAC6Lww9r17Q3vVqg 7Qge86101Xw1fjXqTFUnWTxBK0S7re7pMqWlqaFgFQOHBMLnrM9z+NQIyDh7st9JjA+bRfFwErQ9 5CziXu+o/4q7eDBP1WaI0yKkEcOQ2LyPuCCE4hcshcJABiSYPax8nW71foHb+bv92IYvYXu2Wpa6 VgnxYqdi2k0Yk8CDiYalVsc+7QH0euQ1YIcovPbpZ02AirLqiiy6XB9i8OKfuapKSftsdfjLKqwI L7lKqz/4uAheETQsORVEh4IT0P8RRaIgHBOBVz/DOW+/IiiYagOJIYqbwGIFImQ7uOLNCoP5qY4y PLUZhmHFnnr7xtz4gv455KP9cwtPYcAarc/IB7WkTmEhFYa19k4jXlZ19AZIO/SPhvV7qz50zqB+ pCReRB5fXnf3qhRSw2WpRD4xr/q8OrWTfQRdXaooTJ14tRziqjEWLz4nPQKbE45aAjgwO0Rp6k5J tWGPhCxmuru/iqVES98VbjuAoo2qYZk7eNrqcnMuSxgqU0bgyie/R/FfMcbsw6rAh7T+qfBSxVIQ tpiqPwtZR5kdi6af3vf4w9q1PvEGrNipAjKEN2HW73558qGfPMowggZ5MIIEYaADAgECAhNuAAAA AgUmZh85ZflDAAAAAAACMA0GCSqGSIb3DQEBBQUAMBkxFzAVBgNVBAMTDlBvbHljb20tUm9vdENB MB4XDTEzMTEwNDE5MTM1MFoXDTIzMTEwNDE5MDY1OFowSDETMBEGCgmSJomT8ixkARkWA2NvbTEX MBUGCgmSJomT8ixkARkWB3BvbHljb20xGDAWBgNVBAMTD1BvbHljb20tU1VCQ0EwMTCCAiIwDQYJ KoZIhvcNAQEBBQADggIPADCCAgoCggIBAOZhKwn7h/qKsHx8zQQPT356Og5GOOJ26SKfzS6dIZaD NjFIhS/5QRd3HZ9I1qFD8faDfpIHL+NzC0xqYJUZsEKntD+cCj99nx33t9D6GCmsEEngeLV0FO/u DlDcCXVJNJWS65E05vKyWFPlIRegDs+E73mNh3dHZ53mgrsCFd8PnX5Zm6zm+dAinDTUreXzSuzT si5yuZ10jHdEoin3bQyYQfAe4nR7BiqcQzYnD+JgU+NrZZ555xMdwVtRhjIFuFHwCN1BgWL8+cmI PTmW3bS/irYkbUn/IYFXGJIdgeZTzsp22+OPChBkCBiy86d9RaM6qvOV/ZLmq0bj4souN1cNBg0g ZnYIgTypQY/5Ew99FJJDor4TH1R5YNtqgwxBiSZSc0WSKy8WBrcUpBM+FP1gETY2sqZh2ApFkhU1 7BBLXcEwu6dnSO9Y5u0zJfOTKPesVaeGTfvzTEcm6A8xKO6V+ai/zhu3egbv4SmlPGiMENMPsWRy cG0c73xz/w9RwpWpImjIcE3+XA9rPhIdNj2KN4sbMJvvN5/ZLJHRScE5F3pltq2sFLyPSqhukYVY NRVXmdJ14FCArDqlrREeWLA2tP4ir0WeFeX6KgU+QrmWvdw1hJZ9/lPkiqDvuBWvDVyON0u/Dvi3 p6RJmWJlC5F8ajRegnM+BAYfokRZkvOHAgMBAAGjggGJMIIBhTAQBgkrBgEEAYI3FQEEAwIBADAd BgNVHQ4EFgQUcIfA57S89xZAbs9iT83FhcVNeekwGQYJKwYBBAGCNxQCBAweCgBTAHUAYgBDAEEw CwYDVR0PBAQDAgGGMA8GA1UdEwEB/wQFMAMBAf8wHwYDVR0jBBgwFoAUjA9N5qYwo/1IESAlhEml wOd899EwbwYDVR0fBGgwZjBkoGKgYIYuaHR0cDovL2NkcDEucG9seWNvbS5jb20vcGtpL1BvbHlj b20tUm9vdENBLmNybIYuaHR0cDovL2NkcDIucG9seWNvbS5jb20vcGtpL1BvbHljb20tUm9vdENB LmNybDCBhgYIKwYBBQUHAQEEejB4MDoGCCsGAQUFBzAChi5odHRwOi8vY2RwMS5wb2x5Y29tLmNv bS9wa2kvUG9seWNvbS1Sb290Q0EuY3J0MDoGCCsGAQUFBzAChi5odHRwOi8vY2RwMi5wb2x5Y29t LmNvbS9wa2kvUG9seWNvbS1Sb290Q0EuY3J0MA0GCSqGSIb3DQEBBQUAA4ICAQDAITSF89YEDKMA zqteWVdg8IqzdMHSHIJGybNrbe1UJj6trSldu42wcgjYLgJrTIDEUEX2Qp1xywpv+zpVAE1bVoek 6ot846XEIiOTofJYnwACZNnCLJ3ijG2iuBCSJjPc6FzwCF/2DMR0erdh8PNhEnl3xDRNyqVOy+DC mlLssSjPgej1UxM4yaDZZUCBrkv1dB3a4qkTbMPFBj5CkC5gPnyKTRW7iUFMKr0pXvByGPHCtRbu ShXAcoSdVH2f8cLUfJ8raVMWu1ynjOMcvlagDaZAcbzLSc8hzhxJNC6Wel9U1uFyEaYGodJTMxzv e5zRU5wZod5kPaEThCKq12Fr9Sz/dYYp4Rup/SymTS4A46qMIrOi6i3icxa3SYAhsCeALdcrgCH4 +cCtKiEE1UpqIfJq8P/+FE6cnfHyGaXD+wn4BTA5BrUBg900HNVNf1Y6BDMqaXDeAPKbiSb5FDot PjAW0v7GLoshHMr+951EdhaFNSUyOV8CoSx9b9BjlYpjJV+QtiaqJLn9UlNOa987Fg9dIY4vrfqH q9kCVr+sVpQsZ6DC17bE7etrHPevRny/EcLmuJY1RD56gPAyePHFs1GEhmKVW9ZlLWtNs79G6wSf ZRnr3vRAtr7v0zWyjfvn52HWM4kbXedjCa/q9boJMVqK+8DJawhrrn38Liw7oDCCB/8wggXnoAMC AQICE2sAAM7QzSy0jLD9CsEAAAAAztAwDQYJKoZIhvcNAQELBQAwSDETMBEGCgmSJomT8ixkARkW A2NvbTEXMBUGCgmSJomT8ixkARkWB3BvbHljb20xGDAWBgNVBAMTD1BvbHljb20tU1VCQ0EwMTAe Fw0xNjAyMTAxOTEwNTdaFw0xNzAyMDkxOTEwNTdaMIGpMRMwEQYKCZImiZPyLGQBGRYDY29tMRcw FQYKCZImiZPyLGQBGRYHcG9seWNvbTEPMA0GA1UECxMGUGVvcGxlMRIwEAYDVQQLEwlFbXBsb3ll ZXMxDTALBgNVBAsTBE5BTEExGTAXBgNVBAMTEE1hbmksIE1haGFsaW5nYW0xKjAoBgkqhkiG9w0B CQEWG01haGFsaW5nYW0uTWFuaUBQb2x5Y29tLmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkC gYEAxZ+NHQbMfrR/IDNjg9lVHsQ+tgNdY++lKvEwSFNaCHpgaa06HFuJ2hWQQv6RWgcVw1dDE0rt izxSlI8H27b6QqtCpX1Pq0NVyLrH8K/kkrQEh8WtvcQNebeD/1G9KWNqOBYgp7Yv/bVmGlYvsDoP +ZIwjWRrlTQnoXi6oeQE2AsCAwEAAaOCBAIwggP+MD0GCSsGAQQBgjcVBwQwMC4GJisGAQQBgjcV CIak5VOG2OVyg7WBGISdphqD6bs6KYXD1FiD2eAdAgFkAgEFMCkGA1UdJQQiMCAGCCsGAQUFBwMC BggrBgEFBQcDBAYKKwYBBAGCNwoDBDALBgNVHQ8EBAMCBaAwNQYJKwYBBAGCNxUKBCgwJjAKBggr BgEFBQcDAjAKBggrBgEFBQcDBDAMBgorBgEEAYI3CgMEMEQGCSqGSIb3DQEJDwQ3MDUwDgYIKoZI hvcNAwICAgCAMA4GCCqGSIb3DQMEAgIAgDAHBgUrDgMCBzAKBggqhkiG9w0DBzAdBgNVHQ4EFgQU G6PU+pvn2wLB1IRZy5BQGCVeJzUwHwYDVR0jBBgwFoAUcIfA57S89xZAbs9iT83FhcVNeekwggE6 BgNVHR8EggExMIIBLTCCASmgggEloIIBIYaBvGxkYXA6Ly8vQ049UG9seWNvbS1TVUJDQTAxLENO PXZ3Y29sb3N1YmNhMDEsQ049Q0RQLENOPVB1YmxpYyUyMEtleSUyMFNlcnZpY2VzLENOPVNlcnZp Y2VzLENOPUNvbmZpZ3VyYXRpb24sREM9cG9seWNvbSxEQz1jb20/Y2VydGlmaWNhdGVSZXZvY2F0 aW9uTGlzdD9iYXNlP29iamVjdENsYXNzPWNSTERpc3RyaWJ1dGlvblBvaW50hi9odHRwOi8vY2Rw MS5wb2x5Y29tLmNvbS9wa2kvUG9seWNvbS1TVUJDQTAxLmNybIYvaHR0cDovL2NkcDIucG9seWNv bS5jb20vcGtpL1BvbHljb20tU1VCQ0EwMS5jcmwwggE9BggrBgEFBQcBAQSCAS8wggErMIGuBggr BgEFBQcwAoaBoWxkYXA6Ly8vQ049UG9seWNvbS1TVUJDQTAxLENOPUFJQSxDTj1QdWJsaWMlMjBL ZXklMjBTZXJ2aWNlcyxDTj1TZXJ2aWNlcyxDTj1Db25maWd1cmF0aW9uLERDPXBvbHljb20sREM9 Y29tP2NBQ2VydGlmaWNhdGU/YmFzZT9vYmplY3RDbGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5 MDsGCCsGAQUFBzAChi9odHRwOi8vY2RwMS5wb2x5Y29tLmNvbS9wa2kvUG9seWNvbS1TVUJDQTAx LmNydDA7BggrBgEFBQcwAoYvaHR0cDovL2NkcDIucG9seWNvbS5jb20vcGtpL1BvbHljb20tU1VC Q0EwMS5jcnQwSQYDVR0RBEIwQKAhBgorBgEEAYI3FAIDoBMMEW1tYW5pQHBvbHljb20uY29tgRtN YWhhbGluZ2FtLk1hbmlAUG9seWNvbS5jb20wDQYJKoZIhvcNAQELBQADggIBAAP1URnuP8nr3vyY oz2UmPpnRZ6FIjX8RUQT8x4DvvAbc6y6Bu/7YcWB9nCHvjrcBMUPtr5c2uAFeRP4SGIZUH+sHsgc fQAVeENVnCN6FA/lrTFfIQ80na3wXyGzgx04/T++4Lyne1o4wRTimtLNZpS1qNac9DlIugVUzOji CJ2G6YRVTXb41wCfeyVAKw9QtTywQy8JAi6yGvkQPxldiEhaF49tQeCJFyb1r1JxXqkmNBO6v3HR /OlVTRyUzsBvSe5vCBm2lSkmhBHKicN/YyJAMvzHp0/EsVc7fum7L/sEEzkz4rO4XfRYvra5HTgE iy/hjUZmj9tUrcSGx8C/+8y9Jar0TKEqKlLRbcZ706RxaTJn5vx53kmZxz6jfjvd5dRFYZLcClOy f0IJSM9XgU0R6Dkk4onDy5AOCmDcJU9kvJM6Qkkm6fK+PaRdfcNS2Bm6wE4BAy/u7EhCn5Zy3prk 2ekBi21LdbIm0GiuTOvvKD2bQHgxWPR1t+D4ZXmZjrqmp4c4I3lXlFpzHN3pDHAGb3xKZz5HipuS r+0ouesRuL7XLENZ9/vwLuIw80sPpkTN1qTPJBWxbfZoMaU8S7qPJX7c8cixT0oIhIcpMLBFJ9gX YCrGLLjIm3utH2f4UIwNi4NpQEzo0SbwWN9jl9TA2g3GSOFzFQtLB1rgCEF+MYIC3jCCAtoCAQEw XzBIMRMwEQYKCZImiZPyLGQBGRYDY29tMRcwFQYKCZImiZPyLGQBGRYHcG9seWNvbTEYMBYGA1UE AxMPUG9seWNvbS1TVUJDQTAxAhNrAADO0M0stIyw/QrBAAAAAM7QMAkGBSsOAwIaBQCgggHVMBgG CSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE2MDkwOTE4MzYwMVowIwYJ KoZIhvcNAQkEMRYEFALrLtJ7G/OZ4Q/XEZurDGPu69+KMG4GCSsGAQQBgjcQBDFhMF8wSDETMBEG CgmSJomT8ixkARkWA2NvbTEXMBUGCgmSJomT8ixkARkWB3BvbHljb20xGDAWBgNVBAMTD1BvbHlj b20tU1VCQ0EwMQITawAAztDNLLSMsP0KwQAAAADO0DBwBgsqhkiG9w0BCRACCzFhoF8wSDETMBEG CgmSJomT8ixkARkWA2NvbTEXMBUGCgmSJomT8ixkARkWB3BvbHljb20xGDAWBgNVBAMTD1BvbHlj b20tU1VCQ0EwMQITawAAztDNLLSMsP0KwQAAAADO0DCBkwYJKoZIhvcNAQkPMYGFMIGCMAsGCWCG SAFlAwQBKjALBglghkgBZQMEARYwCgYIKoZIhvcNAwcwCwYJYIZIAWUDBAECMA4GCCqGSIb3DQMC AgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCGjALBglghkgBZQMEAgMwCwYJYIZIAWUDBAICMAsG CWCGSAFlAwQCATANBgkqhkiG9w0BAQEFAASBgCjrNLDcLQj4lvtAh/wXffevf81oQ3xOsV4Lvcru jqm+eXc0SRo8pbTHLtXtxSloZf9CEUAUfHs/PdaEOj1T9COpxln5N0f5/lgrpF9WJNPznf/VyU9X +xZH4kCXG7tJk3y5TgWN7VQJrs94sIVD590RXKhK+a/JfW0P67LbnELDAAAAAAAA ------=_NextPart_000_0033_01D20A8E.579CE6E0-- From nobody Mon Sep 12 00:32: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 9BFCC12B04A for ; Mon, 12 Sep 2016 00:32:34 -0700 (PDT) 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 MjxKkdK3GXaz for ; Mon, 12 Sep 2016 00:32:32 -0700 (PDT) Received: from mail-lf0-x233.google.com (mail-lf0-x233.google.com [IPv6:2a00:1450:4010:c07::233]) (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 C66BD12B03D for ; Mon, 12 Sep 2016 00:32:31 -0700 (PDT) Received: by mail-lf0-x233.google.com with SMTP id l131so80729862lfl.2 for ; Mon, 12 Sep 2016 00:32:31 -0700 (PDT) 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=DKjsxpGSirwjEZaAaY8uSxSFBx3SL5apf2C+nQ4EyAA=; b=MaHdFCfUDVv0eCup6roewIyJqLwUaIAOnLLcba3pA95fefvsCnf5RLuM/ZVhjZi+9/ a/bOa5qW6J+S/x+2vyHTVTAR0i1MKo0j9zx5Z3e/cgx9LNFsr7MV1A39Sn2Eksko141c NFqj28lHBWMaaUjKibXXO5taHK/pElrou1e+tuJrupwtIdmrusLOkP58YDlMVzY7JfiW TXIF6V6CMLNj81+w/VM00NTyEZI8vtqNB8AHWMv/lSILfK6FT6vPiiby6Hn/oUlJl+mg YysGo109BeGCWP5YRiXhju3MOhpfnzp5SGqIs8MTOOd5MO6wNWLgNUF3pxw+n/HBE+1u IHlQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to; bh=DKjsxpGSirwjEZaAaY8uSxSFBx3SL5apf2C+nQ4EyAA=; b=WvLIlMBHDmEOyPuYV1DoBRTHP8M0wWY/x2mWTRdMQGT5LBOiQtaTlYi8+S/RAj/k1l Abs39SJEmqGS9WCnr6OgqKI2f+XDuwkZ+X9o2lzF69SAZ8bpuoGrGIkPbSm5+Pfla52w X/Elxff/G4UtE90VhL/FK5/O6MUdmUeadFbJM/NiuLViaOSXvzN4+Unujmbuw9EHX8sC oV+cKbVB8lAUZNMq0EA2lLd7HzGPYyvZtnDOuqg47kIU8MDxc/zPlk+4bNvLi9f5aHb0 AHe1KRQsweiRwORK/jQUiayEYG6QW/qZRZO9g+HAIBB5E7owg0YukPdBSOQePIK85AqE oxhw== X-Gm-Message-State: AE9vXwPdH0ehk7h7WgFGH5OdY9JrZSfxH+m6HJ0KNNmDM1ycKqyCTmeJbee+XQ0iZcLQ5R3F X-Received: by 10.25.31.9 with SMTP id f9mr4401300lff.34.1473665549440; Mon, 12 Sep 2016 00:32:29 -0700 (PDT) Received: from [192.168.0.166] ([85.235.12.155]) by smtp.gmail.com with ESMTPSA id g70sm2942391ljg.22.2016.09.12.00.32.28 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 12 Sep 2016 00:32:28 -0700 (PDT) To: ace@ietf.org References: <57909032.10809@gmx.net> <6d259c5b-28e3-c748-4590-0c9f942fe343@comcast.net> <378a0359-6b31-a30c-af28-8ea567b06b00@cisco.com> <57963480.2000809@gmx.net> <0d4c6d56-ebb5-2f43-d555-29c336396033@ericsson.com> <15169.1469642303@obiwan.sandelman.ca> <3271.1469656595@obiwan.sandelman.ca> <32aa7104-70df-80c7-8d6e-537b66716de9@comcast.net> <13663.1469714549@obiwan.sandelman.ca> <9a4153f1-6a96-0ae6-020b-0f0f966aecdf@cisco.com> <95997f84-2715-3287-39d3-45d6ff5f3ea0@comcast.net> From: Ludwig Seitz Message-ID: <463a5cce-9dd1-5d68-bd97-0f08d0719960@sics.se> Date: Mon, 12 Sep 2016 09:32:15 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <95997f84-2715-3287-39d3-45d6ff5f3ea0@comcast.net> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms020900020700070406060506" Archived-At: Subject: Re: [Ace] Group Communication Security Disagreements 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: Mon, 12 Sep 2016 07:32:35 -0000 This is a cryptographically signed message in MIME format. --------------ms020900020700070406060506 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable On 2016-09-09 21:44, Michael StJohns wrote: > Hi - > > It's been over a month since there's been any further discussion on thi= s > topic. Given the record I would suggest a lack of consensus to procee= d > on basis of two items: 1) A roughly even split on the vocal yays and > nays on the subject of symmetric key multicast for control functions an= d > 2) a failure to address the specific concern of "How do you enforceably= > keep a cheap, unsafe-in-the-broader-internet security mechanism off the= > broader internet?" > > Your mileage may vary. > > Mike > Can we at least agree to work on group communication with source=20 authentication? /Ludwig --=20 Ludwig Seitz, PhD SICS Swedish ICT AB Ideon Science Park, Building Beta 2 Scheelev=E4gen 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 --------------ms020900020700070406060506 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 MBwGCSqGSIb3DQEJBTEPFw0xNjA5MTIwNzMyMTVaMC8GCSqGSIb3DQEJBDEiBCAtsNzrbKBE wU9Xyxz2HAxPrA8Tk4UEc1SqTdq+bMVy8DBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQB KjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMC AgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkG A1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENl cnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVu dCBDQQIQFOEHMTFC2qLTcvGM5tqREjCBnAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRp ZmljYXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBD QQIQFOEHMTFC2qLTcvGM5tqREjANBgkqhkiG9w0BAQEFAASCAQC1nAVKWPQZ/VoyqSNI4WBn 8EhxSPeFs6PpMO+nXN9JZ6sIF1zgdmBvEIYQyDyFaL9PEwA1gL3Xpob/eBeMPdKLjHtzTMw3 ClCygzdf1FvdSFjk8lOFnbOsTRcQCYXIbLoGCtamSrqa6JA/7sfuQkfhobBEyZYwsLwm13ws tWB4sULajAWu//ZkZSiweUtHdgbGl54hoTluatKx1oS7TCwIN7DRMJIrHZ0FpxUUYDtVLWAm rQVVfdK7rzzSucYskXPP+UhQVfWrwzOXhoBxE5d61GGvDGJbJvg+rW7OvsMGIN8zXMve5256 h7B8/0NCZzRxI8isKNc5smfI8XKaDhRTAAAAAAAA --------------ms020900020700070406060506-- From nobody Tue Sep 13 02:34: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 5E2A812B282 for ; Tue, 13 Sep 2016 02:34:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.029 X-Spam-Level: X-Spam-Status: No, score=-16.029 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_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.508, 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 JsBriFL-MQ-g for ; Tue, 13 Sep 2016 02:34:26 -0700 (PDT) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 369E812B277 for ; Tue, 13 Sep 2016 02:34:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6968; q=dns/txt; s=iport; t=1473759266; x=1474968866; h=subject:to:references:from:message-id:date:mime-version: in-reply-to; bh=wk/O7LYPivBQxOUF3InbmMQo9g3C0gP/k0Ln0I+vc2w=; b=iOWFqq8w7VtK/4qTFBbPZByTEnA0VeCR6cAUesfASJObCApzb0oqCMsN /f9fiZap53tLSMvyIP8Hd5rJZ7Py0wFhu67Glv0N5SWybhO5LU8DCJSpJ fijEXi/BTXiixzbY1JVvs28UcSSU+NHjbaF3evoeFQMeaNdOBrOPxko6f 8=; X-Files: signature.asc : 481 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BoAgCjx9dX/xbLJq1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgzoBAQEBAXUqUo0zphGFDYIDGQEKhXoCggUUAQIBAQEBAQEBXie?= =?us-ascii?q?EYgEBBAEBASAkJxsLBBQqAgInMAYBDAYCAQGIRg6xVYR9hzwBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEOCQWIKYJWh0KCWgWUE4VQg0CBdYoXiWGGAYxYg3seNoReOjS?= =?us-ascii?q?HLwEBAQ?= X-IronPort-AV: E=Sophos;i="5.30,328,1470700800"; d="asc'?scan'208,217";a="688181919" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 13 Sep 2016 09:34:23 +0000 Received: from [10.61.252.38] ([10.61.252.38]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id u8D9YNwW002284; Tue, 13 Sep 2016 09:34:23 GMT To: Ludwig Seitz , ace@ietf.org References: <57909032.10809@gmx.net> <6d259c5b-28e3-c748-4590-0c9f942fe343@comcast.net> <378a0359-6b31-a30c-af28-8ea567b06b00@cisco.com> <57963480.2000809@gmx.net> <0d4c6d56-ebb5-2f43-d555-29c336396033@ericsson.com> <15169.1469642303@obiwan.sandelman.ca> <3271.1469656595@obiwan.sandelman.ca> <32aa7104-70df-80c7-8d6e-537b66716de9@comcast.net> <13663.1469714549@obiwan.sandelman.ca> <9a4153f1-6a96-0ae6-020b-0f0f966aecdf@cisco.com> <95997f84-2715-3287-39d3-45d6ff5f3ea0@comcast.net> <463a5cce-9dd1-5d68-bd97-0f08d0719960@sics.se> From: Eliot Lear Message-ID: <1aa47ac3-46e7-40b4-d7d9-9e4bb051f286@cisco.com> Date: Tue, 13 Sep 2016 11:34:22 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.3.0 MIME-Version: 1.0 In-Reply-To: <463a5cce-9dd1-5d68-bd97-0f08d0719960@sics.se> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="sh9OGWc1C9cdjnXgaCXBe5cUIJ1jNLa5B" Archived-At: Subject: Re: [Ace] Group Communication Security Disagreements 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: Tue, 13 Sep 2016 09:34:30 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --sh9OGWc1C9cdjnXgaCXBe5cUIJ1jNLa5B Content-Type: multipart/mixed; boundary="Q8pp5gvVCO5LntCaMJgnDEdhrJDNFQNt3"; protected-headers="v1" From: Eliot Lear To: Ludwig Seitz , ace@ietf.org Message-ID: <1aa47ac3-46e7-40b4-d7d9-9e4bb051f286@cisco.com> Subject: Re: [Ace] Group Communication Security Disagreements References: <57909032.10809@gmx.net> <6d259c5b-28e3-c748-4590-0c9f942fe343@comcast.net> <378a0359-6b31-a30c-af28-8ea567b06b00@cisco.com> <57963480.2000809@gmx.net> <0d4c6d56-ebb5-2f43-d555-29c336396033@ericsson.com> <15169.1469642303@obiwan.sandelman.ca> <3271.1469656595@obiwan.sandelman.ca> <32aa7104-70df-80c7-8d6e-537b66716de9@comcast.net> <13663.1469714549@obiwan.sandelman.ca> <9a4153f1-6a96-0ae6-020b-0f0f966aecdf@cisco.com> <95997f84-2715-3287-39d3-45d6ff5f3ea0@comcast.net> <463a5cce-9dd1-5d68-bd97-0f08d0719960@sics.se> In-Reply-To: <463a5cce-9dd1-5d68-bd97-0f08d0719960@sics.se> --Q8pp5gvVCO5LntCaMJgnDEdhrJDNFQNt3 Content-Type: multipart/alternative; boundary="------------093A2DA07E2CAB133457EFA1" This is a multi-part message in MIME format. --------------093A2DA07E2CAB133457EFA1 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Ludwig and Mike, In thinking about this problem, I wonder if the challenge here really is a matter of layering. First of all, if we were to do source authentication, what would that mean? Would it mean that all messages were signed? If so, what sort of format would we be talking about?=20 IPSEC-AH? Higher? I state this because typically, although by no means always, we have at least some separation between protocol and content.=20 I just wonder where that line would be here. I agree that source authentication is important, both in terms of group joins and in terms of message content for all the reasons previously stated. I just wonder if we need to specify all of that in this WG, or if we can state what we think the right answer is above or below.** Eliot On 9/12/16 9:32 AM, Ludwig Seitz wrote: > On 2016-09-09 21:44, Michael StJohns wrote: >> Hi - >> >> It's been over a month since there's been any further discussion on th= is >> topic. Given the record I would suggest a lack of consensus to proce= ed >> on basis of two items: 1) A roughly even split on the vocal yays and >> nays on the subject of symmetric key multicast for control functions a= nd >> 2) a failure to address the specific concern of "How do you enforceabl= y >> keep a cheap, unsafe-in-the-broader-internet security mechanism off th= e >> broader internet?" >> >> Your mileage may vary. >> >> Mike >> > > Can we at least agree to work on group communication with source > authentication? > > /Ludwig > > > > > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace --------------093A2DA07E2CAB133457EFA1 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

Hi Ludwig and Mike,

In thinking about this problem, I wonder if the challenge here really is a matter of layering.=C2=A0 First of all, if we were to d= o source authentication, what would that mean?=C2=A0 Would it mean th= at all messages were signed?=C2=A0 If so, what sort of format would we= be talking about?=C2=A0 IPSEC-AH?=C2=A0 Higher?=C2=A0 I state this bec= ause typically, although by no means always, we have at least some separation between protocol and content.=C2=A0 I just wonder where = that line would be here.

I agree that source authentication is important, both in terms of group joins and in terms of message content for all the reasons previously stated.=C2=A0 I just wonder if we need to specify all of= that in this WG, or if we can state what we think the right answer is above or below.

Eliot


On 9/12/16 9:32 AM, Ludwig Seitz wrote= :
On 2016-09-09 21:44, Michael StJohns wrote:
Hi -

It's been over a month since there's been any further discussion on this
topic.=C2=A0=C2=A0 Given the record I would suggest a lack of con= sensus to proceed
on basis of two items:=C2=A0 1) A roughly even split on the vocal= yays and
nays on the subject of symmetric key multicast for control functions and
2) a failure to address the specific concern of "How do you enforceably
keep a cheap, unsafe-in-the-broader-internet security mechanism off the
broader internet?"

Your mileage may vary.

Mike


Can we at least agree to work on group communication with source authentication?

/Ludwig 




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

--------------093A2DA07E2CAB133457EFA1-- --Q8pp5gvVCO5LntCaMJgnDEdhrJDNFQNt3-- --sh9OGWc1C9cdjnXgaCXBe5cUIJ1jNLa5B 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 iQEcBAEBCAAGBQJX18gfAAoJEIe2a0bZ0nozYw4H/1Ov6g5hfuNbNqi6JJGqQ4bR r3bYF1keo3G4GqaaqEivqNgVCLwXWFtPOO5wTzGDSTcUaZ0MF1Rowz/bf399GSr+ Ql8UcL4Blr6pZrB29LvPn/OQfV82E15b63CsRzmvdkO/ifKtrxIaeFox8wDmRjOh H+jO+mhGvNDY2esVTURHDlTABGZ2gwEXWMzpcBoK37QKMJDf+MxxEotYstxNzIKs yTYPKoe2r87/t4aux4XULHNI/5mK09Z9Pn5hqDSV9N8oW0gDSl+LRTJ8/nzyqJZn AExzjUNjdjpB6nPC4qar3XXiOvJ6UuE5oJCkfQvmN7BYdXMhBnQUJXd5rQb0j00= =Z6s5 -----END PGP SIGNATURE----- --sh9OGWc1C9cdjnXgaCXBe5cUIJ1jNLa5B-- From nobody Wed Sep 14 02:33:44 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 12C0512B22A for ; Wed, 14 Sep 2016 02:33:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=zgrp.onmicrosoft.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 goLc8b2jtqgN for ; Wed, 14 Sep 2016 02:33:40 -0700 (PDT) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-db5eur01on0112.outbound.protection.outlook.com [104.47.2.112]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BAC6412B227 for ; Wed, 14 Sep 2016 02:33:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zgrp.onmicrosoft.com; s=selector1-tridonic-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=fj0CptejobjAsNzrZJtCGairor2jT8JjaYbKbIjdcfI=; b=Z/BSoTaNwMc200kf2k4Oc78Z/MMY4W0BMXr5NyinGSchK5V3AVFS57fqzDo0aydDY6ZpNz9dYc8SRl101ZL1ArQhC1PHh9qzMtYnHO5vM15TOo8vocMENkHKJ9dw3XVF/RmkKa1/4G4qLlB3wyLZWZ5FmXnB7HtWEsReqN4/JiE= Received: from HE1PR0601MB2203.eurprd06.prod.outlook.com (10.168.35.138) by HE1PR0601MB2204.eurprd06.prod.outlook.com (10.168.35.139) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.619.10; Wed, 14 Sep 2016 09:33:29 +0000 Received: from HE1PR0601MB2203.eurprd06.prod.outlook.com ([10.168.35.138]) by HE1PR0601MB2203.eurprd06.prod.outlook.com ([10.168.35.138]) with mapi id 15.01.0619.011; Wed, 14 Sep 2016 09:33:29 +0000 From: Somaraju Abhinav To: "ace@ietf.org" Thread-Topic: [Ace] Group Communication Security Disagreements Thread-Index: AQHR4y7ydQxGwF1N+0u9pqgDf9qZy6Ai5q6AgAZg8QCAAAmhAIAADbeAgAM7mYCAABGdgIAAMPGAgAAXsgCAAPYsgIAJBSKAgDruooCAA+pzgIADRX6g Date: Wed, 14 Sep 2016 09:33:28 +0000 Message-ID: References: <57909032.10809@gmx.net> <6d259c5b-28e3-c748-4590-0c9f942fe343@comcast.net> <378a0359-6b31-a30c-af28-8ea567b06b00@cisco.com> <57963480.2000809@gmx.net> <0d4c6d56-ebb5-2f43-d555-29c336396033@ericsson.com> <15169.1469642303@obiwan.sandelman.ca> <3271.1469656595@obiwan.sandelman.ca> <32aa7104-70df-80c7-8d6e-537b66716de9@comcast.net> <13663.1469714549@obiwan.sandelman.ca> <9a4153f1-6a96-0ae6-020b-0f0f966aecdf@cisco.com> <95997f84-2715-3287-39d3-45d6ff5f3ea0@comcast.net> <463a5cce-9dd1-5d68-bd97-0f08d0719960@sics.se> In-Reply-To: <463a5cce-9dd1-5d68-bd97-0f08d0719960@sics.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=abhinav.somaraju@tridonic.com; x-originating-ip: [146.108.200.98] x-ms-office365-filtering-correlation-id: dc414503-9060-49c3-9968-08d3dc822f95 x-microsoft-exchange-diagnostics: 1; HE1PR0601MB2204; 6:qvx/NvXNELpC19qBv2yykAXjSe8OFA9fT8DwCw9kozHBDW7apmf4QnfvNas8ZNP0WyBlRbm0lqxcKGNEj3qK6oarCbVfrHiN3o1LyeMIwHSSOCFrB1bcVDwQGJa/gt8fVf46F3/zKR5AR6DFFi5cZNRKN6MN/RlmqXst8hybXxerk/Ub6OgPLKLsuTRX1Pd46YrdJumqiCXJP0ezZbz5jKCc1xb015E35rYTh+sIy28UN5c5uztr4bsOw8+/4BCsP+svdvV4ktddLF7W2038IRiX1mXNyFFgCx05H/Y4kAAvZgH9vLlu15oKczN2Y4GFqUXdl/NwQ5edb31rlT4mmQ==; 5:fPChklomgiAzeeEU6kGGo1rpX5Rqop2Qi2MF+h1EnVV+85cdSGhfRbaSpfb5PZZLJDiYJH5DvSGxyulD+Zm+IjeQ4Twp2sE40Zhv3erQpKR47sH3I2RVHpxMxC/NzbA6m/J/qGOAUmZsGzuXM37R3w==; 24:8bTIaDy/cxI/NGPMP1KWui/p8/hOLjaaGm80zwFWLJjduwloQMynl3uPhOqk6OlJrWFGu8SHj/NiktjnlFQ8JX9MDTqMroneDcipFD2GxDE=; 7:CqFjxJTHWnFZ7HKnA7Ned4jDQHMyobQgBw7gT+Ud3HJIrZPar/2NRU40iomX2h2bK+Ft+6ch6rafj9jV/nu8hx10QDMolTv7hOmG4QfTSPEg0nqubWlBezkTxg+OtUMm0If9279ImtdeLpglXgUyY1V6ON/rFGV3CKJ7jhKGxQCXP/QCDAL1bRgwoZ/9qE6JXpSYUHxTHNjJRgCXuWjXYud8I2VOt4/CVPTq2eLPavfuljHwNX9uXhV5dc1EY316 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:HE1PR0601MB2204; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(192374486261705); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026); SRVR:HE1PR0601MB2204; BCL:0; PCL:0; RULEID:; SRVR:HE1PR0601MB2204; x-forefront-prvs: 006546F32A x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(53754006)(199003)(189002)(97736004)(76576001)(5002640100001)(87936001)(5660300001)(86362001)(7696004)(54356999)(7736002)(66066001)(8936002)(77096005)(189998001)(5890100001)(2501003)(11100500001)(74316002)(2906002)(107886002)(110136003)(305945005)(7846002)(50986999)(92566002)(3846002)(76176999)(101416001)(8676002)(81166006)(586003)(33656002)(2351001)(106356001)(450100001)(81156014)(9686002)(5640700001)(1730700003)(6116002)(15650500001)(93886004)(2950100001)(68736007)(102836003)(106116001)(3280700002)(105586002)(2900100001)(3660700001)(10400500002)(122556002); DIR:OUT; SFP:1102; SCL:1; SRVR:HE1PR0601MB2204; H:HE1PR0601MB2203.eurprd06.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: tridonic.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: tridonic.com X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Sep 2016 09:33:28.8832 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 8b206608-a593-4ace-a4b6-ef1fc83c9169 X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0601MB2204 Archived-At: Subject: Re: [Ace] Group Communication Security Disagreements 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, 14 Sep 2016 09:33:43 -0000 Hi all, Thank you all for the feedback on the group communication security discussi= on. We noticed that two concerns have been raised with the current specificatio= n. 1) Symmetric keys do not provide source authentication. Here, most people= on the mailing list agreed that symmetric keys provides basic security and= is sufficient for lighting applications. It is not intended to be used in = the wider internet for more sensitive group communication security use-case= s. 2) How to ensure that the symmetric key group communication security solu= tion is not used in situations it is not designed for? We propose to address the received feedback by making the following modific= ations to the document: 1) We will add an additional section where we specify how asymmetric cryp= tography can be used for secure group communication. This will help for all= those cases where source authentication is desired. 2) Add a security considerations section where we explain that the asymme= tric key solution is the recommended approach but that there are situations= where low latency group communication makes it difficult to use asymmetric= cryptography and where source authentication is less important. You could = call it an applicability statement. If this proposed modifications makes sense then we can try to submit a new = draft with these changes. Abhinav ________________________________________________________ The contents of th= is e-mail and any attachments are confidential to the intended recipient. T= hey may not be disclosed to or used by or copied in any way by anyone other= than the intended recipient. If this e-mail is received in error, please i= mmediately notify the sender and delete the e-mail and attached documents. = Please note that neither the sender nor the sender's company accept any res= ponsibility for viruses and it is your responsibility to scan or otherwise = check this e-mail and any attachments. From nobody Wed Sep 14 03:10:10 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 02BB912B274 for ; Wed, 14 Sep 2016 03:10:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.03 X-Spam-Level: X-Spam-Status: No, score=-16.03 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_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.508, 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 9rXUtSn-I7Ul for ; Wed, 14 Sep 2016 03:10:05 -0700 (PDT) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 85D1312B059 for ; Wed, 14 Sep 2016 03:10:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4953; q=dns/txt; s=iport; t=1473847804; x=1475057404; h=subject:to:references:from:message-id:date:mime-version: in-reply-to; bh=xUd1Fd+ATFp/xKihLYxQ2BFJBXvDXCrtiYFMCIy5leE=; b=Ki29Tku7A0P2z9crW852pZY8rE01PEkgpW8VoL9H3LsrX4SWTN6qDsnu OUr+fzGM/erg/UD2Lek6bSsR27kcYYJVSP6cf4CyIvQjMV+ERuJL1CBSm 6rxCuTMgp/7JwAqR1zlfnVf3vLjb1VBu9Ppb9vJnmUd5nqvmvOzHKy6Gj U=; X-Files: signature.asc : 481 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D1AQCCINlX/xbLJq1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgzoBAQEBAXUqUo0zqyWCAxkLhXoCggMUAQIBAQEBAQEBXieEYgE?= =?us-ascii?q?BBAEBASBLGwsYKgICJzAGAQwGAgEBF4gvDq9YjDsBAQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QERCQWIKoJWhBILBgECgxyCWgEEmWiDQIF1gy6GcYFuhGCDE4YBkFYeNoRrOjS?= =?us-ascii?q?EJw4XgggBAQE?= X-IronPort-AV: E=Sophos;i="5.30,333,1470700800"; d="asc'?scan'208";a="688223528" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 14 Sep 2016 10:10:02 +0000 Received: from [10.61.64.112] (ams3-vpn-dhcp112.cisco.com [10.61.64.112]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id u8EAA2BN021970; Wed, 14 Sep 2016 10:10:02 GMT To: Somaraju Abhinav , "ace@ietf.org" References: <57909032.10809@gmx.net> <6d259c5b-28e3-c748-4590-0c9f942fe343@comcast.net> <378a0359-6b31-a30c-af28-8ea567b06b00@cisco.com> <57963480.2000809@gmx.net> <0d4c6d56-ebb5-2f43-d555-29c336396033@ericsson.com> <15169.1469642303@obiwan.sandelman.ca> <3271.1469656595@obiwan.sandelman.ca> <32aa7104-70df-80c7-8d6e-537b66716de9@comcast.net> <13663.1469714549@obiwan.sandelman.ca> <9a4153f1-6a96-0ae6-020b-0f0f966aecdf@cisco.com> <95997f84-2715-3287-39d3-45d6ff5f3ea0@comcast.net> <463a5cce-9dd1-5d68-bd97-0f08d0719960@sics.se> From: Eliot Lear Message-ID: Date: Wed, 14 Sep 2016 12:10:00 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="AX1sUXGxEc68lxUxqbSJNQS96IEsTw7Uj" Archived-At: Subject: Re: [Ace] Group Communication Security Disagreements 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, 14 Sep 2016 10:10:08 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --AX1sUXGxEc68lxUxqbSJNQS96IEsTw7Uj Content-Type: multipart/mixed; boundary="BLCwln8QLmBiGwbJIjS6skBBgxJETIep0"; protected-headers="v1" From: Eliot Lear To: Somaraju Abhinav , "ace@ietf.org" Message-ID: Subject: Re: [Ace] Group Communication Security Disagreements References: <57909032.10809@gmx.net> <6d259c5b-28e3-c748-4590-0c9f942fe343@comcast.net> <378a0359-6b31-a30c-af28-8ea567b06b00@cisco.com> <57963480.2000809@gmx.net> <0d4c6d56-ebb5-2f43-d555-29c336396033@ericsson.com> <15169.1469642303@obiwan.sandelman.ca> <3271.1469656595@obiwan.sandelman.ca> <32aa7104-70df-80c7-8d6e-537b66716de9@comcast.net> <13663.1469714549@obiwan.sandelman.ca> <9a4153f1-6a96-0ae6-020b-0f0f966aecdf@cisco.com> <95997f84-2715-3287-39d3-45d6ff5f3ea0@comcast.net> <463a5cce-9dd1-5d68-bd97-0f08d0719960@sics.se> In-Reply-To: --BLCwln8QLmBiGwbJIjS6skBBgxJETIep0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Abhinav, Thanks for this email. I think this is pretty close to what I think is necessary. To be sure, vendors and developers have very little power to limit where their products will be placed. Thus it is important to state strongly that source authentication is necessary at other layers when it is not used at this layer. To me that would cover all circumstances. With that approach, I would strongly support the adoption of your document as a WG document and would of course review it and provide comments (as I have ;-). Regards, Eliot On 9/14/16 11:33 AM, Somaraju Abhinav wrote: > Hi all, > > Thank you all for the feedback on the group communication security disc= ussion. > > We noticed that two concerns have been raised with the current specific= ation. > 1) Symmetric keys do not provide source authentication. Here, most pe= ople on the mailing list agreed that symmetric keys provides basic securi= ty and is sufficient for lighting applications. It is not intended to be = used in the wider internet for more sensitive group communication securit= y use-cases. > 2) How to ensure that the symmetric key group communication security = solution is not used in situations it is not designed for? > > We propose to address the received feedback by making the following mod= ifications to the document: > > 1) We will add an additional section where we specify how asymmetric = cryptography can be used for secure group communication. This will help f= or all those cases where source authentication is desired. > 2) Add a security considerations section where we explain that the as= ymmetric key solution is the recommended approach but that there are situ= ations where low latency group communication makes it difficult to use as= ymmetric cryptography and where source authentication is less important. = You could call it an applicability statement. > > If this proposed modifications makes sense then we can try to submit a = new draft with these changes. > > Abhinav > ________________________________________________________ The contents o= f this e-mail and any attachments are confidential to the intended recipi= ent. They may not be disclosed to or used by or copied in any way by anyo= ne other than the intended recipient. If this e-mail is received in error= , please immediately notify the sender and delete the e-mail and attached= documents. Please note that neither the sender nor the sender's company = accept any responsibility for viruses and it is your responsibility to sc= an or otherwise check this e-mail and any attachments. > > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace > --BLCwln8QLmBiGwbJIjS6skBBgxJETIep0-- --AX1sUXGxEc68lxUxqbSJNQS96IEsTw7Uj 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 iQEcBAEBCAAGBQJX2SH5AAoJEIe2a0bZ0nozzX0IANJZHxAICCrgPUifYuwA3FL3 stY2ZdVa/l+/r9eC3NloOPyEdGHFUsk+v966UU3RM0DDWSuMjYh5lRASTBff91JE p2DPVJiVkgXPkM9V4pE/Df8pqZOonvUOkSZ6LJEkOV0ZmT5hPTufAROXsO+YN6sL AgjZAC2IOsrxkAZzAAzd9aW2mpWkCfl3kIuKlenBVkynLFQ6TjiJrMat17+nzoro VILhw6mppHvobOrcxPCGC67SQsKx9XUEdrxcwVA0rb38IBL4vdkflXn1ZFpL0Ism neQBS7yZ+wO/RcC47zZKJqK3bcMU/77Tj8JpVbyyUbZq7EVlDLVnMpaL4iaPnTo= =JXVc -----END PGP SIGNATURE----- --AX1sUXGxEc68lxUxqbSJNQS96IEsTw7Uj-- From nobody Thu Sep 15 09:27:18 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 AB64112B682 for ; Thu, 15 Sep 2016 09:27:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.207 X-Spam-Level: X-Spam-Status: No, score=-4.207 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=-1.508, 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 ZqoPZjWLSMta for ; Thu, 15 Sep 2016 09:27:14 -0700 (PDT) Received: from resqmta-ch2-05v.sys.comcast.net (resqmta-ch2-05v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:37]) (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 911E712B885 for ; Thu, 15 Sep 2016 08:36:20 -0700 (PDT) Received: from resomta-ch2-13v.sys.comcast.net ([69.252.207.109]) by resqmta-ch2-05v.sys.comcast.net with SMTP id kYg3bOyI12FGMkYi3bvqtD; Thu, 15 Sep 2016 15:36:19 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1473953779; bh=oin6a1WL2Ul4dztkvxRQ+O3Ya89YW6aAt4lixNmJZHM=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=O3b6JtgWXMNCs8AMqwtqQLgfLG5lv+INh5nNxdGMWirPb2V672RAgXAx/eWeg6OZ1 yOzTkm4JrtWkd8rVL0jGGzIrXksGxMCXXbUZPbZLMNgphs4cBgHIdkcbeoXoHa5QqJ DZGjz1kwreDRgA2n1i0w96bsscB2I37rMUAVseZgYRzDwaIcTyIaQb6HPFUXmB5CXX uZLcUV9ic9vLERp3vAygkPiGxhY7jTOc5uZbNZp+3DbGfSj0HAcFNWUXBn4MLTh3z4 U1FeCZ9FRIwEqRaanSf/2Def4Q0nTYGvaj72mbGFNF6+6Y4QJDwat4SOMkQd9H40TS Tc/VsOpUICBSg== Received: from [IPv6:2601:148:c000:1951:c183:6e85:ca72:fed] ([IPv6:2601:148:c000:1951:c183:6e85:ca72:fed]) by resomta-ch2-13v.sys.comcast.net with SMTP id kYi2bgjWPF329kYi3bcYb6; Thu, 15 Sep 2016 15:36:19 +0000 To: ace@ietf.org References: <57909032.10809@gmx.net> <6d259c5b-28e3-c748-4590-0c9f942fe343@comcast.net> <378a0359-6b31-a30c-af28-8ea567b06b00@cisco.com> <57963480.2000809@gmx.net> <0d4c6d56-ebb5-2f43-d555-29c336396033@ericsson.com> <15169.1469642303@obiwan.sandelman.ca> <3271.1469656595@obiwan.sandelman.ca> <32aa7104-70df-80c7-8d6e-537b66716de9@comcast.net> <13663.1469714549@obiwan.sandelman.ca> <9a4153f1-6a96-0ae6-020b-0f0f966aecdf@cisco.com> <95997f84-2715-3287-39d3-45d6ff5f3ea0@comcast.net> <463a5cce-9dd1-5d68-bd97-0f08d0719960@sics.se> From: Michael StJohns Message-ID: <97bfa890-da35-8db6-9a11-207f40883e42@comcast.net> Date: Thu, 15 Sep 2016 11:36:18 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------59025F66E319332B14AA8E01" X-CMAE-Envelope: MS4wfBIY+26JxpWgpF/GsYAw0/tPWRH64rW9dIh7GkS76Y7lIA1VrqXznxem/w1fmqNwRdMfCwARx9qDQnhYXqx9ad/1aCLlNnWvmFttmIJWgxMJUL+r1+2d HDN+ZPbfpXpMtsJqsbRHzsrmu6RTuF+J9b4uPGldafV8qoNlt1IjnYC6bjPzhQUut/AqYYR2j9fD/Q== Archived-At: Subject: Re: [Ace] Group Communication Security Disagreements 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, 15 Sep 2016 16:27:17 -0000 This is a multi-part message in MIME format. --------------59025F66E319332B14AA8E01 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Hi Elliot et al - Sorry, I think you're still missing the point: * Source Authentication (A) cannot be accomplished securely by Symmetric Key Multicast (^B): (A -> ^B) * Cyber Physical control functions (C) require source authentication (A): (C -> A) * Turning on and off lights (D) is a Cyber Physical Control Function (C): (D -> C) * Therefore Turning on and off lights (D) requires source authentication (B): (D -> C -> A) (D -> A) * Therefore Turning on and off lights (D) cannot be accomplished securely by Symmetric Key Multicast (^B): (D -> C) ( C -> A) (D -> C -> A) ( D->A) (A -> ^B) (D -> ^B). Apologies if I got the formal logic wrong - its been a while. The above seems to be pretty clear. You might argue the second line, but if you do, you pretty much argue that some forms of cyber physical control require no security at all. In which case, defining a security protocol which implements symmetric key multicast for control function authentication still makes no sense and is probably still not a useful candidate for adoption. What I'd suggest at this point is that *_the lighting folk go away and huddle together to produce a document that they submit independently as an "Informational" _*"this is how *we* do it" document rather than trying to turn this into an Internet Standard. Given that there seems (seems ~= I haven't heard any other group step up claiming they'd find this approach both useful (and mandatory - cf latency and cost issues) for their specific problem) to be no other use case besides lighting, that may be the best approach overall. This is either a general purpose protocol, in which case it needs to be at least conditionally secure for all cases, or it is a protocol that applies to a very very limited set of functionality in which case it is probably not an IETF problem to be solving. Later, Mike ps - so far this discussion hasn't varied much from the discussion in DICE. On 9/14/2016 6:10 AM, Eliot Lear wrote: > Hi Abhinav, > > Thanks for this email. I think this is pretty close to what I think is > necessary. To be sure, vendors and developers have very little power to > limit where their products will be placed. Thus it is important to > state strongly that source authentication is necessary at other layers > when it is not used at this layer. To me that would cover all > circumstances. With that approach, I would strongly support the > adoption of your document as a WG document and would of course review it > and provide comments (as I have ;-). > > Regards, > > Eliot > > > > On 9/14/16 11:33 AM, Somaraju Abhinav wrote: >> Hi all, >> >> Thank you all for the feedback on the group communication security discussion. >> >> We noticed that two concerns have been raised with the current specification. >> 1) Symmetric keys do not provide source authentication. Here, most people on the mailing list agreed that symmetric keys provides basic security and is sufficient for lighting applications. It is not intended to be used in the wider internet for more sensitive group communication security use-cases. >> 2) How to ensure that the symmetric key group communication security solution is not used in situations it is not designed for? >> >> We propose to address the received feedback by making the following modifications to the document: >> >> 1) We will add an additional section where we specify how asymmetric cryptography can be used for secure group communication. This will help for all those cases where source authentication is desired. >> 2) Add a security considerations section where we explain that the asymmetric key solution is the recommended approach but that there are situations where low latency group communication makes it difficult to use asymmetric cryptography and where source authentication is less important. You could call it an applicability statement. >> >> If this proposed modifications makes sense then we can try to submit a new draft with these changes. >> >> Abhinav >> ________________________________________________________ The contents of this e-mail and any attachments are confidential to the intended recipient. They may not be disclosed to or used by or copied in any way by anyone other than the intended recipient. If this e-mail is received in error, please immediately notify the sender and delete the e-mail and attached documents. Please note that neither the sender nor the sender's company accept any responsibility for viruses and it is your responsibility to scan or otherwise check this e-mail and any attachments. >> >> _______________________________________________ >> Ace mailing list >> Ace@ietf.org >> https://www.ietf.org/mailman/listinfo/ace >> > > > > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace --------------59025F66E319332B14AA8E01 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
Hi Elliot et al -

Sorry, I think you're still missing the point:

  • Source Authentication (A) cannot be accomplished securely by Symmetric Key Multicast  (^B):   (A -> ^B)
  • Cyber Physical control functions (C)  require source authentication  (A):  (C -> A)
  • Turning on and off lights (D) is a Cyber Physical Control Function (C):  (D -> C)
  • Therefore Turning on and off lights (D) requires source authentication (B):  (D -> C -> A) (D -> A)
  • Therefore Turning on and off lights (D) cannot be accomplished securely by Symmetric Key Multicast (^B):  (D -> C) ( C -> A) (D -> C -> A) ( D->A) (A -> ^B) (D -> ^B).
Apologies if I got the formal logic wrong - its been a while.

The above seems to be pretty clear.  You might argue the second line, but if you do, you pretty much argue that some forms of cyber physical control require no security at all.  In which case, defining a security protocol which implements symmetric key multicast for control function authentication still makes no sense and is probably still not a useful candidate for adoption.

What I'd suggest at this point is that the lighting folk go away and huddle together to produce a document that they submit independently as an "Informational" "this is how *we* do it" document rather than trying to turn this into an Internet Standard.  Given that there seems (seems ~= I haven't heard any other group step up claiming they'd find this approach both useful (and mandatory - cf latency and cost issues) for their specific problem) to be no other use case besides lighting, that may be the best approach overall.

This is either a general purpose protocol, in which case it needs to be at least conditionally secure for all cases, or it is a protocol that applies to a very very limited set of functionality in which case it is probably not an IETF problem to be solving.

Later, Mike

ps - so far this discussion hasn't varied much from the discussion in DICE. 


On 9/14/2016 6:10 AM, Eliot Lear wrote:
Hi Abhinav,

Thanks for this email.  I think this is pretty close to what I think is
necessary.  To be sure, vendors and developers have very little power to
limit where their products will be placed.  Thus it is important to
state strongly that source authentication is necessary at other layers
when it is not used at this layer.  To me that would cover all
circumstances.  With that approach, I would strongly support the
adoption of your document as a WG document and would of course review it
and provide comments (as I have ;-).

Regards,

Eliot



On 9/14/16 11:33 AM, Somaraju Abhinav wrote:

Hi all,

Thank you all for the feedback on the group communication security discussion.

We noticed that two concerns have been raised with the current specification.
1)   Symmetric keys do not provide source authentication. Here, most people on the mailing list agreed that symmetric keys provides basic security and is sufficient for lighting applications. It is not intended to be used in the wider internet for more sensitive group communication security use-cases.
2)   How to ensure that the symmetric key group communication security solution is not used in situations it is not designed for?

We propose to address the received feedback by making the following modifications to the document:

1)   We will add an additional section where we specify how asymmetric cryptography can be used for secure group communication. This will help for all those cases where source authentication is desired.
2)   Add a security considerations section where we explain that the asymmetric key solution is the recommended approach but that there are situations where low latency group communication makes it difficult to use asymmetric cryptography and where source authentication is less important. You could call it an applicability statement.

If this proposed modifications makes sense then we can try to submit a new draft with these changes.

Abhinav
________________________________________________________ The contents of this e-mail and any attachments are confidential to the intended recipient. They may not be disclosed to or used by or copied in any way by anyone other than the intended recipient. If this e-mail is received in error, please immediately notify the sender and delete the e-mail and attached documents. Please note that neither the sender nor the sender's company accept any responsibility for viruses and it is your responsibility to scan or otherwise check this e-mail and any attachments.

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






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


--------------59025F66E319332B14AA8E01-- From nobody Fri Sep 16 03:03:42 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 176F512B017 for ; Fri, 16 Sep 2016 03:03:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.029 X-Spam-Level: X-Spam-Status: No, score=-16.029 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_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.508, 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 zMVdujv041gh for ; Fri, 16 Sep 2016 03:03:38 -0700 (PDT) Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 52A9C12B094 for ; Fri, 16 Sep 2016 03:03:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6325; q=dns/txt; s=iport; t=1474020217; x=1475229817; h=subject:to:references:from:message-id:date:mime-version: in-reply-to; bh=ZDcrtnKNce9C5fCoH28I88MYKOC0gB7kcrJiL7+Jx/I=; b=eyLRv8s2B3wXBMS3UhT/ysugum8wwJVJM51t+aifkRSnKfBNEroe2fZ/ pI5Pp9fBcSoNZlIgu0aaLwMNX2+QN5t/K03XhURmvPEvg74EEVRfHlWRz kftdZflVWr4lBCyHkX2pZEKlbxQ/hC3dsW38KgxIIBTC39qaOXeqbZDd5 Q=; X-Files: signature.asc : 481 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BLAgB3wttX/xbLJq1UCRkBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYM6AQEBAQGBH44Fph2FD4IDhh4Cgg8UAQIBAQEBAQEBXieEYgE?= =?us-ascii?q?BBCMEYgsEFCoCAlcGAQwIAQGIRrNdjEIBAQEBAQEBAQIBAQEBAQEBAQEBAQ4Oi?= =?us-ascii?q?CoIgk6EGYMpgloBBJltg0CBdYoliWOGA5BaHjaEbDyHPQEBAQ?= X-IronPort-AV: E=Sophos;i="5.30,344,1470700800"; d="asc'?scan'208,217";a="646744774" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 16 Sep 2016 10:03:35 +0000 Received: from [10.61.81.127] (ams3-vpn-dhcp4480.cisco.com [10.61.81.127]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id u8GA3Y5S013839; Fri, 16 Sep 2016 10:03:35 GMT To: Michael StJohns , ace@ietf.org References: <57909032.10809@gmx.net> <6d259c5b-28e3-c748-4590-0c9f942fe343@comcast.net> <378a0359-6b31-a30c-af28-8ea567b06b00@cisco.com> <57963480.2000809@gmx.net> <0d4c6d56-ebb5-2f43-d555-29c336396033@ericsson.com> <15169.1469642303@obiwan.sandelman.ca> <3271.1469656595@obiwan.sandelman.ca> <32aa7104-70df-80c7-8d6e-537b66716de9@comcast.net> <13663.1469714549@obiwan.sandelman.ca> <9a4153f1-6a96-0ae6-020b-0f0f966aecdf@cisco.com> <95997f84-2715-3287-39d3-45d6ff5f3ea0@comcast.net> <463a5cce-9dd1-5d68-bd97-0f08d0719960@sics.se> <97bfa890-da35-8db6-9a11-207f40883e42@comcast.net> From: Eliot Lear Message-ID: <47ad4e37-4747-0150-07da-6994b4dfb0a8@cisco.com> Date: Fri, 16 Sep 2016 12:03:34 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.3.0 MIME-Version: 1.0 In-Reply-To: <97bfa890-da35-8db6-9a11-207f40883e42@comcast.net> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="N3KJD8ub4Wox1sEM6S8tGx5i1QD69oMeN" Archived-At: Subject: Re: [Ace] Group Communication Security Disagreements 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 Sep 2016 10:03:40 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --N3KJD8ub4Wox1sEM6S8tGx5i1QD69oMeN Content-Type: multipart/mixed; boundary="hNl5uN8O3Kur6CmCNjrOL66uvoOUupu9J"; protected-headers="v1" From: Eliot Lear To: Michael StJohns , ace@ietf.org Message-ID: <47ad4e37-4747-0150-07da-6994b4dfb0a8@cisco.com> Subject: Re: [Ace] Group Communication Security Disagreements References: <57909032.10809@gmx.net> <6d259c5b-28e3-c748-4590-0c9f942fe343@comcast.net> <378a0359-6b31-a30c-af28-8ea567b06b00@cisco.com> <57963480.2000809@gmx.net> <0d4c6d56-ebb5-2f43-d555-29c336396033@ericsson.com> <15169.1469642303@obiwan.sandelman.ca> <3271.1469656595@obiwan.sandelman.ca> <32aa7104-70df-80c7-8d6e-537b66716de9@comcast.net> <13663.1469714549@obiwan.sandelman.ca> <9a4153f1-6a96-0ae6-020b-0f0f966aecdf@cisco.com> <95997f84-2715-3287-39d3-45d6ff5f3ea0@comcast.net> <463a5cce-9dd1-5d68-bd97-0f08d0719960@sics.se> <97bfa890-da35-8db6-9a11-207f40883e42@comcast.net> In-Reply-To: <97bfa890-da35-8db6-9a11-207f40883e42@comcast.net> --hNl5uN8O3Kur6CmCNjrOL66uvoOUupu9J Content-Type: multipart/alternative; boundary="------------6A592EFF54459B9DA949448A" This is a multi-part message in MIME format. --------------6A592EFF54459B9DA949448A Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Mike, On 9/15/16 5:36 PM, Michael StJohns wrote: > Hi Elliot et al - > > Sorry, I think you're still missing the point: > > * Source Authentication (A) cannot be accomplished securely by > Symmetric Key Multicast (^B): (A -> ^B) > * Cyber Physical control functions (C) require source > authentication (A): (C -> A) > * Turning on and off lights (D) is a Cyber Physical Control Function > (C): (D -> C) > * Therefore Turning on and off lights (D) requires source > authentication (B): (D -> C -> A) (D -> A) > * Therefore Turning on and off lights (D) cannot be accomplished > securely by Symmetric Key Multicast (^B): (D -> C) ( C -> A) (D > -> C -> A) ( D->A) (A -> ^B) (D -> ^B). > > Apologies if I got the formal logic wrong - its been a while. > All of this seems about right to me, but with two big caveats: 1. We are, I think, talking about group-based communications and not necessarily group-based authorization for device control. There is a difference, albeit subtle. One could reasonably envision borrowing from lower layers to satisfy device authorization requirements. 2. The question here is whether this is the right level to address the problem. And I'll ask my clarifying question again: is there a more logical place to anchor identity, like above or below this layer? Eliot --------------6A592EFF54459B9DA949448A Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

Hi Mike,


On 9/15/16 5:36 PM, Michael StJohns wrote:
Hi Elliot et al -

Sorry, I think you're still missing the point:

  • Source Authentication (A) cannot be accomplished securely by Symmetric Key Multicast=C2=A0 (^B):=C2=A0=C2=A0 (A -> ^= B)
  • Cyber Physical control functions (C)=C2=A0 require source authentication=C2=A0 (A):=C2=A0 (C -> A)
  • Turning on and off lights (D) is a Cyber Physical Control Function (C):=C2=A0 (D -> C)
  • Therefore Turning on and off lights (D) requires source authentication (B):=C2=A0 (D -> C -> A) (D -> A)
  • Therefore Turning on and off lights (D) cannot be accomplished securely by Symmetric Key Multicast (^B):=C2=A0 = (D -> C) ( C -> A) (D -> C -> A) ( D->A) (A -> ^B) (D -> ^B).
Apologies if I got the formal logic wrong - its been a while.
=
All of this seems about right to me, but with two big caveats:
  1. We are, I think, talking about group-based communications and not necessarily group-based authorization for device control.=C2=A0= There is a difference, albeit subtle.=C2=A0 One could reasonably envision borrowing from lower layers to satisfy device authorization requirements.

  2. The question here is whether this is the right level to address the problem.=C2=A0 And I'll ask my clarifying question ag= ain: is there a more logical place to anchor identity, like above or below this layer?
Eliot
--------------6A592EFF54459B9DA949448A-- --hNl5uN8O3Kur6CmCNjrOL66uvoOUupu9J-- --N3KJD8ub4Wox1sEM6S8tGx5i1QD69oMeN 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 iQEcBAEBCAAGBQJX28N3AAoJEIe2a0bZ0nozym0H/1kalZTKRRCHpHtAcGWsiJzY rEx1z9QD+LXfcpv5Jc5Tbd587ngQOUuMHEfySHmm6A2PHid2ofymq3CRjBKthnGj z2F/ctGRoYJZatpSSEQrWnSb84VwY3Dl0IBqRWvJ4Ffkdpyy9N+k040eaWUvNiJu UoCeEtdd7iuO562skxRC3O8geDd0WWifqzyL2A7Nl6Vl1CBA3lVbWTiU4j5bVA7u vUhDi2wcoWXdz50Olgg56Y/yWlGivhNYo3GaKfuSLGTmz/yEJa0opMr3i5eFVpIX aqA8rk0XKFNkpsOBa9hTLHZKfB4tktfCVphDGs/rsALu6+zsFyiXt1wgvAsvZiU= =gJQA -----END PGP SIGNATURE----- --N3KJD8ub4Wox1sEM6S8tGx5i1QD69oMeN-- From nobody Fri Sep 16 09:39:42 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 D9C3A12B172 for ; Fri, 16 Sep 2016 09:39:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.207 X-Spam-Level: X-Spam-Status: No, score=-4.207 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=-1.508, 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 x2bDp5dueh67 for ; Fri, 16 Sep 2016 09:39:37 -0700 (PDT) Received: from resqmta-ch2-08v.sys.comcast.net (resqmta-ch2-08v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:40]) (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 37FBA12B0C6 for ; Fri, 16 Sep 2016 09:39:37 -0700 (PDT) Received: from resomta-ch2-09v.sys.comcast.net ([69.252.207.105]) by resqmta-ch2-08v.sys.comcast.net with SMTP id kwAobAYLM84vjkwAqbtTok; Fri, 16 Sep 2016 16:39:36 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1474043976; bh=N4nym77spwLUeIVNfTG6p+1Yj1l1OjglANH1hedIQvA=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=dRyKnIbO6oGMPUi/wCFTkX3rXYD4jyVmy89O5zm7f3jZQCxItUrBXwSamc9JYs4t6 p5f8H20rkirX23IVV7XIFOsr0aod1qxbBamB+xZ4Q3/p4jdpuvyMV7T/fvxywO12sf Q9kgKVc7vgsAgNHD/dRXIh2FevOVOtORxYW52Ixu4EW+Zl4m5Xesuhc5BCwFWFQ9Ux B7gB/tCWiT91Req+Eq++exp2bpBwmh2it/WF9CBHgxQQ+xFc0wW+lIujNCgpJqabm5 TVIdUro48VyiS8L6Vp5RMB19N1sgwc3DB4ZcuptPwC4xsiI7zoFEPuyE/UwL8U7cjf Ew0MZjyvZfYKQ== Received: from [IPv6:2601:148:c000:1951:c183:6e85:ca72:fed] ([IPv6:2601:148:c000:1951:c183:6e85:ca72:fed]) by resomta-ch2-09v.sys.comcast.net with SMTP id kwApbVlABN3QMkwAqb3wlG; Fri, 16 Sep 2016 16:39:36 +0000 To: Eliot Lear , ace@ietf.org References: <57909032.10809@gmx.net> <6d259c5b-28e3-c748-4590-0c9f942fe343@comcast.net> <378a0359-6b31-a30c-af28-8ea567b06b00@cisco.com> <57963480.2000809@gmx.net> <0d4c6d56-ebb5-2f43-d555-29c336396033@ericsson.com> <15169.1469642303@obiwan.sandelman.ca> <3271.1469656595@obiwan.sandelman.ca> <32aa7104-70df-80c7-8d6e-537b66716de9@comcast.net> <13663.1469714549@obiwan.sandelman.ca> <9a4153f1-6a96-0ae6-020b-0f0f966aecdf@cisco.com> <95997f84-2715-3287-39d3-45d6ff5f3ea0@comcast.net> <463a5cce-9dd1-5d68-bd97-0f08d0719960@sics.se> <97bfa890-da35-8db6-9a11-207f40883e42@comcast.net> <47ad4e37-4747-0150-07da-6994b4dfb0a8@cisco.com> From: Michael StJohns Message-ID: <2ae9f313-274c-0c9e-097b-8369d02b091b@comcast.net> Date: Fri, 16 Sep 2016 12:39:35 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <47ad4e37-4747-0150-07da-6994b4dfb0a8@cisco.com> Content-Type: multipart/alternative; boundary="------------2B88EACC0A2AA69BAE86B85B" X-CMAE-Envelope: MS4wfK9sx2kgrdg7qWu0komkxyybATBlXWjNMmZWpudADb7Z58qOE5q6pnnTZLEiQvqbxcrIdoowcgGkgtT8w4XQRth4jfQSyChbSjaNbSaTily7TBMhgE0i k64UIsUo0Hgo5D0C2MwjUdlxmXKq4WJPAmqp+wQplxyGsv0ypdo6IAF8ll6MnNyGb25feO6obOB7dfxxENcO0bhzZoA1n7xGNEU= Archived-At: Subject: Re: [Ace] Group Communication Security Disagreements 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 Sep 2016 16:39:41 -0000 This is a multi-part message in MIME format. --------------2B88EACC0A2AA69BAE86B85B Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit On 9/16/2016 6:03 AM, Eliot Lear wrote: > > Hi Mike, > > > On 9/15/16 5:36 PM, Michael StJohns wrote: >> Hi Elliot et al - >> >> Sorry, I think you're still missing the point: >> >> * Source Authentication (A) cannot be accomplished securely by >> Symmetric Key Multicast (^B): (A -> ^B) >> * Cyber Physical control functions (C) require source >> authentication (A): (C -> A) >> * Turning on and off lights (D) is a Cyber Physical Control >> Function (C): (D -> C) >> * Therefore Turning on and off lights (D) requires source >> authentication (B): (D -> C -> A) (D -> A) >> * Therefore Turning on and off lights (D) cannot be accomplished >> securely by Symmetric Key Multicast (^B): (D -> C) ( C -> A) (D >> -> C -> A) ( D->A) (A -> ^B) (D -> ^B). >> >> Apologies if I got the formal logic wrong - its been a while. >> > All of this seems about right to me, but with two big caveats: > > 1. We are, I think, talking about group-based communications and not > necessarily group-based authorization for device control. There > is a difference, albeit subtle. One could reasonably envision > borrowing from lower layers to satisfy device authorization > requirements. > Sorry - we've really been talking about using symmetric key multicast for control functions. (cf all the discussions on lighting control and the ever reducing maximum latency requirement). Authorization is really about whether or not a given entity accepts and acts on a given authenticated message. Trying to parse this as group comms (which I took you to mean "secure group comms") vs group authorization is really a red herring here as you can't have meaningful authorization without meaningful authentication and so far, we haven't gotten that far. > 1. The question here is whether this is the right level to address > the problem. And I'll ask my clarifying question again: is there > a more logical place to anchor identity, like above or below this > layer? > This is mostly an irrelevant question at this point. Once we agree that symmetric key multiparty (N>2 or 3 in the case of a kerberos system) authentication is off the table, then talking about which level to put this reduces down to either per application or per device and the associated protocols for each of those. It's entirely possible a message might be authenticated by credentials at multiple protocol layers depending on who owns what in the mesh. Later, Mike > Eliot --------------2B88EACC0A2AA69BAE86B85B Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
On 9/16/2016 6:03 AM, Eliot Lear wrote:

Hi Mike,


On 9/15/16 5:36 PM, Michael StJohns wrote:
Hi Elliot et al -

Sorry, I think you're still missing the point:

  • Source Authentication (A) cannot be accomplished securely by Symmetric Key Multicast  (^B):   (A -> ^B)
  • Cyber Physical control functions (C)  require source authentication  (A):  (C -> A)
  • Turning on and off lights (D) is a Cyber Physical Control Function (C):  (D -> C)
  • Therefore Turning on and off lights (D) requires source authentication (B):  (D -> C -> A) (D -> A)
  • Therefore Turning on and off lights (D) cannot be accomplished securely by Symmetric Key Multicast (^B):  (D -> C) ( C -> A) (D -> C -> A) ( D->A) (A -> ^B) (D -> ^B).
Apologies if I got the formal logic wrong - its been a while.

All of this seems about right to me, but with two big caveats:
  1. We are, I think, talking about group-based communications and not necessarily group-based authorization for device control.  There is a difference, albeit subtle.  One could reasonably envision borrowing from lower layers to satisfy device authorization requirements.
Sorry - we've really been talking about using symmetric key multicast for control functions.  (cf all the discussions on lighting control and the ever reducing maximum latency requirement).   Authorization is really about whether or not a given entity accepts and acts on a given authenticated message.  Trying to parse this as group comms (which I took you to mean "secure group comms") vs group authorization is really a red herring here as you can't have meaningful authorization without meaningful authentication and so far, we haven't gotten that far.



  1. The question here is whether this is the right level to address the problem.  And I'll ask my clarifying question again: is there a more logical place to anchor identity, like above or below this layer?

This is mostly an irrelevant question at this point.  Once we agree that symmetric key multiparty (N>2 or 3 in the case of a kerberos system) authentication is off the table, then talking about which level to put this reduces down to either per application  or per device and the associated protocols for each of those.  It's entirely possible a message might be authenticated by credentials at multiple protocol layers depending on who owns what in the mesh.

Later, Mike

Eliot


--------------2B88EACC0A2AA69BAE86B85B-- From nobody Mon Sep 26 01:24:11 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 8186E12B00A for ; Mon, 26 Sep 2016 01:24:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.417 X-Spam-Level: X-Spam-Status: No, score=-4.417 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-2.316, 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 n12p_GCQ7Upv for ; Mon, 26 Sep 2016 01:24:08 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 18A8312B0A0 for ; Mon, 26 Sep 2016 01:24:07 -0700 (PDT) Received: from [192.168.91.133] ([80.92.122.18]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0MDW9x-1bjE0S2vYj-00GmyX; Mon, 26 Sep 2016 10:24:01 +0200 To: "Calvo Alonso, Daniel" , "ace@ietf.org" References: <8A926B4ADC92E345A40FA5363D47FA3003358C69@DEERLM99EX1MSX.ww931.my-it-solutions.net> From: Hannes Tschofenig Message-ID: <15048fce-3378-94e3-40d6-c75fc511a2cb@gmx.net> Date: Mon, 26 Sep 2016 10:24:00 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <8A926B4ADC92E345A40FA5363D47FA3003358C69@DEERLM99EX1MSX.ww931.my-it-solutions.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Provags-ID: V03:K0:+qcXgqQWw8R9FqYf74zoTzg6JmLBkBAiWH8PT/86asfc02ZA5eW QYUGl0iUW6VK1ZjABhnInrwoWgRwT0HwSpnCv3AtpnD5iq76wbEU8ajnqQtWn9F6QMmSybu KI7vrg+JBC8FJpoRJxpgcXQjf9JITLX/1a0kPf+LdKDS/CSApTodNMtjTWfS5M+aDR0c6dq pJ3Hy8KVvQX1cD/ubqiQg== X-UI-Out-Filterresults: notjunk:1;V01:K0:J/Amwfq0ybc=:2cOv+pm96Fvv+6OL00b/ph YFv+Q4bDbKLZy3uAbicU6HLPyFdeGf1ImbljImaKzOAzyKLpQBstEwYZ8kl5BUdQtZ4+E8Va1 raWm98xWkkEdm2kyL4gafizY6OR9bjSsjC1FpTr5X3Q3c+LLYkzEKJTFKmfYzZkRrzy78Z4iD Yyrob4dZN7+3w5I9+wQF0Z0fTDZcRquv4X1/Riglr4mlHWGQtaBvWJ2VOE1ZRB65FzX20AlhL HaHLyG6Ebg4AYgmqckblNkmxoULBZZc+dIlO25DPKIZDrfEI0pkR6DQkL13eXB286F/1WI944 hBi/0giUUQxcd7SdpnKH0ogYlr3XnMH6CrzLAXxwIFB4NytyXvStKkWvRwPaFMOQXtqgU0T6Z iMY+Xg/8aOuXeCOTiUbQnLi0Q8JXJsL1xk5zpeWY7xmS9q+nYBCVu91pfJb7EsYZvaezZqloN McLbkGoYyeX63lewEuPlWILpCfoENxI3LH/Etp6qgcZD6ispqvuey13f7v3PboZAYS9hSGtWq NC0SWNMQ6EtH/bqG7tcE3vkndoGDed7k99OuArkyvHMuj1RrzFtwN3GHxwreMVnw+dNX6EIbd fkSY8LeyMLVz5rjtaPS38gsDJcr1v/JV900DTyv57oAA/0No45Jw0oVaVstP9bhykDlA/pN/0 +ex5bNqQFV0orEZcM4tCCx5Aty/736yvO9nHwI2sUfAFggC3enR7zapRYBE4Fu9mJisc8/bbP 8ckx77O1IlKHHWVUlsfZLqs1aEIVGTeTl6rTHHgpq/ewQlkMsnQo4xV4TCjFN+6egg6E/n+xG xOZq5X7 Archived-At: Cc: "Kasinathan, Prabhakaran" , "Cuellar, Jorge" , "Gato, Jose" Subject: Re: [Ace] Correct url for draft-cuellar-ace-pat-priv-enhanced-authz-tokens source code 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: Mon, 26 Sep 2016 08:24:10 -0000 Hi Daniel, could you provide a bit of info what you have implemented? (I know that I can look at the code myself but you probably know all the details from the top of your head.) Ciao Hannes On 08/31/2016 10:11 AM, Calvo Alonso, Daniel wrote: > Dear all, > > As I promised during my presentation in the ACE WG meeting in Berlin, > this is the correct link to > draft-cuellar-ace-pat-priv-enhanced-authz-tokens prototype source code: > > _https://gitlab.atosresearch.eu/ari/ACE-PAT-pub_ > > Please, don’t hesitate in contact me in case you have any doubt or problem. > > With my best regards, > > *Daniel Calvo* > Energy and Transport Market > Atos Research and Innovation > Tel: +34 946 66 20 82 > _daniel.calvo@atos.net_ > C/Real Consulado s/n, > Polígono Industrial Candina > 39011 Santander > _www.atosresearch.eu_ > > > *Feel free to download our booklet at* > _http://atos.net/en-us/home/we-are/insights-innovation/research-and-innovation.html_ > > > This e-mail and the documents attached are confidential and intended > solely for the addressee; it may also be privileged. If you receive this > e-mail in error, please notify the sender immediately and destroy it. > As its integrity cannot be secured on the Internet, the Atos group > liability cannot be triggered for the message content. Although the > sender endeavors to maintain a computer virus-free network, the sender > does not warrant that this transmission is virus-free and will not be > liable for any damages resulting from any virus transmitted. > > Este mensaje y los ficheros adjuntos pueden contener información > confidencial destinada solamente a la(s) persona(s) mencionadas > anteriormente y pueden estar protegidos por secreto profesional. > Si usted recibe este correo electrónico por error, gracias por informar > inmediatamente al remitente y destruir el mensaje. > Al no estar asegurada la integridad de este mensaje sobre la red, Atos > no se hace responsable por su contenido. Su contenido no constituye > ningún compromiso para el grupo Atos, salvo ratificación escrita por > ambas partes. > Aunque se esfuerza al máximo por mantener su red libre de virus, el > emisor no puede garantizar nada al respecto y no será responsable de > cualesquiera daños que puedan resultar de una transmisión de virus. > This e-mail and the documents attached are confidential and intended > solely for the addressee; it may also be privileged. If you receive this > e-mail in error, please notify the sender immediately and destroy it. > As its integrity cannot be secured on the Internet, the Atos group > liability cannot be triggered for the message content. Although the > sender endeavors to maintain a computer virus-free network, the sender > does not warrant that this transmission is virus-free and will not be > liable for any damages resulting from any virus transmitted. > > Este mensaje y los ficheros adjuntos pueden contener información > confidencial destinada solamente a la(s) persona(s) mencionadas > anteriormente y pueden estar protegidos por secreto profesional. > Si usted recibe este correo electrónico por error, gracias por informar > inmediatamente al remitente y destruir el mensaje. > Al no estar asegurada la integridad de este mensaje sobre la red, Atos > no se hace responsable por su contenido. Su contenido no constituye > ningún compromiso para el grupo Atos, salvo ratificación escrita por > ambas partes. > Aunque se esfuerza al máximo por mantener su red libre de virus, el > emisor no puede garantizar nada al respecto y no será responsable de > cualesquiera daños que puedan resultar de una transmisión de virus. > > > > This e-mail and the documents attached are confidential and intended > solely for the addressee; it may also be privileged. If you receive this > e-mail in error, please notify the sender immediately and destroy it. > As its integrity cannot be secured on the Internet, the Atos group > liability cannot be triggered for the message content. Although the > sender endeavors to maintain a computer virus-free network, the sender > does not warrant that this transmission is virus-free and will not be > liable for any damages resulting from any virus transmitted. > > Este mensaje y los ficheros adjuntos pueden contener información > confidencial destinada solamente a la(s) persona(s) mencionadas > anteriormente y pueden estar protegidos por secreto profesional. > Si usted recibe este correo electrónico por error, gracias por informar > inmediatamente al remitente y destruir el mensaje. > Al no estar asegurada la integridad de este mensaje sobre la red, Atos > no se hace responsable por su contenido. Su contenido no constituye > ningún compromiso para el grupo Atos, salvo ratificación escrita por > ambas partes. > Aunque se esfuerza al máximo por mantener su red libre de virus, el > emisor no puede garantizar nada al respecto y no será responsable de > cualesquiera daños que puedan resultar de una transmisión de virus. > > > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace > From nobody Mon Sep 26 03:11:06 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 9B95E12B0EE for ; Mon, 26 Sep 2016 03:11:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.051 X-Spam-Level: X-Spam-Status: No, score=-0.051 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_FUTURE_06_12=1.947, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=alibaba-inc.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 PzKHHT-3yvEL for ; Mon, 26 Sep 2016 03:11:01 -0700 (PDT) Received: from out0-133.mail.aliyun.com (out0-133.mail.aliyun.com [140.205.0.133]) by ietfa.amsl.com (Postfix) with ESMTP id 368F312B0F9 for ; Mon, 26 Sep 2016 03:11:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alibaba-inc.com; s=default; t=1474884659; h=Date:Subject:From:To:Message-ID:Mime-version:Content-type; bh=d5ojsm++U8GDZ+iXJrqZ0l6peehKzl/PQtUME6I0WIc=; b=Q4++936gLJVo6PfID3fd1HTkvGQac1IE6upfZooPQ0t4EX34Qnp1eMeOiwkj4uM7YCj9YBRozSoy6/he1CjVtcO2Je+ddyTwSjCUrWA1HrlyAnjDWKXIpi65At6yhiyID88QiAT9RT8osJJVpNE7LO6BZpY2MShm5yE82MIHISQ= X-Alimail-AntiSpam: AC=PASS; BC=-1|-1; BR=01201311R171e4; FP=0|-1|-1|-1|0|-1|-1|-1; HT=e02c03289; MF=kepeng.lkp@alibaba-inc.com; NM=1; PH=DS; RN=3; SR=0; TI=SMTPD_---.7.AYqDv_1474884650; Received: from 30.9.221.225(mailfrom:kepeng.lkp@alibaba-inc.com ip:42.120.74.105) by smtp.aliyun-inc.com(127.0.0.1); Mon, 26 Sep 2016 18:10:54 +0800 User-Agent: Microsoft-MacOutlook/14.4.8.150116 Date: Tue, 27 Sep 2016 01:11:01 +0800 From: "Kepeng Li" To: ace Message-ID: Thread-Topic: Summary of ACE Group Communication Security Discussion Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3557758266_8360185" Archived-At: Cc: Kathleen Moriarty , Hannes Tschofenig Subject: [Ace] Summary of ACE Group Communication Security Discussion 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: Mon, 26 Sep 2016 10:11:05 -0000 > ´ËÓʼþʹÓà MIME ¸ñʽ¡£ÓÉÓÚÓʼþÔĶÁ³ÌÐò²»ÄÜʶ±ð ´Ë¸ñʽ£¬Òò´Ë£¬¿ÉÄÜÎÞ·¨Ê¶±ð¸ÃÓʼþµÄ·Ö²¿»ò²¿·ÖÄÚÈÝ¡£ --B_3557758266_8360185 Content-type: text/plain; charset="GB2312" Content-transfer-encoding: 7bit Hi all, We went through all email exchanges again in order to see where we are. Abhinav also proposed a way forward in his email to the list, see https://www.ietf.org/mail-archive/web/ace/current/msg01961.html, where he proposed to standardize a solution based on public key as well as symmetric key cryptography. Here is our impression of the views presented by various people. Mike seems to think the only acceptable solution is to use messages signed using public key crypto and is strongly against working on a symmetric key group communication protocol. Paul Duffy and Michael Richardson are in favor of defining a public key crypto solution but it is not clear whether they are against specifying a symmetric key solution as well. Walter, Abhinav, Sandeep, Hannes are in favor of working on a symmetric key group communication security protocols (as co-authors of the work). Oscar Garcia (Philips) is also in favor of the work. In this mail to the list, see https://www.ietf.org/mail-archive/web/ace/current/msg01931.html, Robert Cragie (ARM) expressed a view that public key crypto is the preferred solution but others based on symmetric crypto are still worthy of consideration. Markus Grunwald (Osram) also appears to be in favor of the proposed approach, see https://www.ietf.org/mail-archive/web/ace/current/msg01932.html Akbar Rahman also seems to be in favor of working on a group communication security protocol, see https://www.ietf.org/mail-archive/web/ace/current/msg01873.html Ned Smith also seems to be in favor of working on a group communication security protocol, as expressed in his mail to the list: https://www.ietf.org/mail-archive/web/ace/current/msg01872.html The opinion of the following persons in the discussion appear unclear to me: - Mohit Sethi - Ludwig Seitz - Carsten Bormann - Stephen Farrell - Jim Schaad (offered clarifications regarding the use of COSE) Pascal Urien and Rene Struik provided performance data but they didn't appear to have expressed a strong view about the question regarding symmetric vs. asymmetric crypto for group communication security. Derek Atkins offered performance data for public key crypto but refers to new techniques (rather than RSA/ECC). Please correct us if we are wrong in our interpretation of your mail postings. Ciao Hannes & Kepeng --B_3557758266_8360185 Content-type: text/html; charset="GB2312" Content-transfer-encoding: quoted-printable

Hi all,=  


<= span style=3D"font-size: 16px;">We went through all email= exchanges again in order to see where we are. Abhinav also proposed a way f= orward in his email to the list, see https://www.ietf.org/mail-archive/we= b/ace/current/msg01961.html, where he proposed to standardize a solution= based on public key as well as symmetric key cryptography. 


Here is our impression of the vi= ews presented by various people.


Mike seems to think th= e only acceptable solution is to use messages signed using public key crypto= and is strongly against working on a symmetric key group communication prot= ocol.


Paul Duffy and Michael Richardson are in favor of= defining a public key crypto solution but it is not clear whether they are = against specifying a symmetric key solution as well.


=

Wa= lter, Abhinav, Sandeep, Hannes are in favor of working on a symmetric key gr= oup communication security protocols (as co-authors of the work). Oscar Garc= ia (Philips) is also in favor of the work.


In this= mail to the list, see https://www.ietf.org/mail-archive/web/ace/current/= msg01931.html, Robert Cragie (ARM) expressed a view that public key cryp= to is the preferred solution but others based on symmetric crypto are still = worthy of consideration.


Markus Grunw= ald (Osram) also appears to be in favor of the proposed approach, see <= /span>

https://www.ietf.org/mail-archive/web/ace/current/msg01932.html

=  

Akbar Rahman also seems to be in fa= vor of working on a group communication security protocol, see

https://www.ietf.org/mail-archive/web/ace/current/msg01873.html

 

Ned Smith also seems to be in = favor of working on a group communication security protocol, as expressed in= his mail to the list:

https://www.ietf.org/mail-arch= ive/web/ace/current/msg01872.html

 <= /o:p>

The opinion of the following persons in the discussion appear unclear = to me:

- Mohit Sethi

- Lud= wig Seitz

- Carsten Bormann

- Stephen Farrell 

<= span style=3D"font-size: 16px;">- Jim Schaad (offered cla= rifications regarding the use of COSE)

 =

Pascal Urien and Rene Struik provided performance data but they didn'= t appear to have expressed a strong view about the question regarding symmet= ric vs. asymmetric crypto for group communication security.

Derek Atkins offered performance data for public key crypto but ref= ers to new techniques (rather than RSA/ECC).

 <= /font>

Please correct us if we are wrong in our interpretation of your= mail postings.

 

Ciao<= /font>

Hannes & Kepeng


--B_3557758266_8360185-- From nobody Mon Sep 26 04:04:54 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 CAAD512B13E for ; Mon, 26 Sep 2016 04:04:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.837 X-Spam-Level: X-Spam-Status: No, score=-16.837 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_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-2.316, 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 dSZiAlBx6diQ for ; Mon, 26 Sep 2016 04:04:47 -0700 (PDT) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 033C712B13B for ; Mon, 26 Sep 2016 04:04:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=19772; q=dns/txt; s=iport; t=1474887887; x=1476097487; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to; bh=IJt6HIqcYEbD7GgxKvdtBtW4jcLmM/4yHW+QkA1ImBs=; b=Bdm8fAGp3Hz/xrOw0wWtz14jPrsTGyUJM3TIrmr5mHTTuoXHpleJt0Hb 2XggiFH0FSkGxF2GiFpXyU7dEb3isQZCQRkAl/hwd5UtMFv4YK1G+msF3 RobXq3AIDDxWQJ92JFWDpquqhvQqtOyEKZz5vTFRd4PAuq3aaj19fpsTW M=; X-Files: signature.asc, signature.asc : 481 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AMAgB8AOlX/xbLJq1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgwc0AQEBAQF1KlKNM6Y+hRCCBBkBCoV6AoIHFAECAQEBAQEBAV4?= =?us-ascii?q?nhGIBAQQBAQEgSwsQCwQBEyoCAicwBgEMBgIBAReIMA6xNIxOAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBDgkFiDOCWIQWCwUCAQGDHoJaBZl2g0GBdoMwhwGBboRkgxS?= =?us-ascii?q?GBZBnHjYahG08NIVOgi0BAQE?= X-IronPort-AV: E=Sophos;i="5.30,399,1470700800"; d="asc'?scan'208,217";a="688515065" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 26 Sep 2016 11:04:44 +0000 Received: from [10.61.229.246] ([10.61.229.246]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id u8QB4iMq030399; Mon, 26 Sep 2016 11:04:44 GMT To: Kepeng Li , ace References: From: Eliot Lear Message-ID: Date: Mon, 26 Sep 2016 13:04:43 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="iRmT3dV6d2kfpcgCEQLNWefGAauVdWKeR" Archived-At: Cc: Kathleen Moriarty , Hannes Tschofenig Subject: Re: [Ace] Summary of ACE Group Communication Security Discussion 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: Mon, 26 Sep 2016 11:04:53 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --iRmT3dV6d2kfpcgCEQLNWefGAauVdWKeR Content-Type: multipart/mixed; boundary="HIAKB3f0mrrvlSb7cHS20oDJA8SgMTTqU"; protected-headers="v1" From: Eliot Lear To: Kepeng Li , ace Cc: Kathleen Moriarty , Hannes Tschofenig Message-ID: Subject: Re: [Ace] Summary of ACE Group Communication Security Discussion References: In-Reply-To: --HIAKB3f0mrrvlSb7cHS20oDJA8SgMTTqU Content-Type: multipart/mixed; boundary="------------9CBA9CB09AECF8A00A97D342" This is a multi-part message in MIME format. --------------9CBA9CB09AECF8A00A97D342 Content-Type: multipart/alternative; boundary="------------B33625C12E78F9E48E9FDF4C" --------------B33625C12E78F9E48E9FDF4C Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi, On 9/26/16 7:11 PM, Kepeng Li wrote: > > Please correct us if we are wrong in our interpretation of your mail > postings. > Perhaps my middle ground didn't seem important, but I had thought it was a good way forward: require asymmetric for group admission (as Abhinav & co do), group keying for communication and require source authentication at other layers. I otherwise supported his proposal. I do take Mike's point that the standard wouldn't be self-contained, and there are risks of it being used without that additional layer beyond its applicatbility. I still think the middle ground approach is best, given some of the use cases. Eliot --------------B33625C12E78F9E48E9FDF4C Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

Hi,

On 9/26/16 7:11 PM, Kepeng Li wrote:

Please correct us if we are wrong in our interpretation of your mail postings.


Perhaps my middle ground didn't seem important, but I had thought it was a good way forward: require asymmetric for group admission (as Abhinav & co do), group keying for communication and require source authentication at other layers.=C2=A0 I otherwise supported hi= s proposal.

I do take Mike's point that the standard wouldn't be self-contained, and there are risks of it being used without that additional layer beyond its applicatbility.=C2=A0 I still think the middle ground appr= oach is best, given some of the use cases.

Eliot
 --------------B33625C12E78F9E48E9FDF4C-- --------------9CBA9CB09AECF8A00A97D342 Content-Type: message/rfc822; name="Attached Message" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="Attached Message" X-Mozilla-Keys: Received: from xch-rcd-002.cisco.com (173.37.102.12) by xch-aln-005.cisco.com (173.36.7.15) with Microsoft SMTP Server (TLS) id 15.0.1210.3 via Mailbox Transport; Wed, 14 Sep 2016 05:10:36 -0500 Received: from xch-rcd-016.cisco.com (173.37.102.26) by XCH-RCD-002.cisco.com (173.37.102.12) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 14 Sep 2016 05:10:36 -0500 Received: from xch-aln-006.cisco.com (173.36.7.16) by XCH-RCD-016.cisco.com (173.37.102.26) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 14 Sep 2016 05:10:35 -0500 Received: from alln-iport-1.cisco.com (173.37.142.88) by mail.cisco.com (173.36.7.16) with Microsoft SMTP Server (TLS) id 15.0.1210.3 via Frontend Transport; Wed, 14 Sep 2016 05:10:35 -0500 X-Files: signature.asc : 481 Received: from alln-core-4.cisco.com ([173.36.13.137]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 14 Sep 2016 10:10:34 +0000 Received: from alln-inbound-j.cisco.com (alln-inbound-j.cisco.com [173.37.147.240]) by alln-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id u8EAAUJ8031252 (version=TLSv1/SSLv3 cipher=DHE-RSA-SEED-SHA bits=128 verify=OK); Wed, 14 Sep 2016 10:10:33 GMT Received-SPF: Pass (alln-inbound-j.cisco.com: domain of ace-bounces@ietf.org designates 4.31.198.44 as permitted sender) identity=mailfrom; client-ip=4.31.198.44; receiver=alln-inbound-j.cisco.com; envelope-from="ace-bounces@ietf.org"; x-sender="ace-bounces@ietf.org"; x-conformance=spf_only; x-record-type="v=spf1" Received-SPF: None (alln-inbound-j.cisco.com: no sender authenticity information available from domain of postmaster@mail.ietf.org) identity=helo; client-ip=4.31.198.44; receiver=alln-inbound-j.cisco.com; envelope-from="ace-bounces@ietf.org"; x-sender="postmaster@mail.ietf.org"; x-conformance=spf_only Authentication-Results: alln-inbound-j.cisco.com; spf=Pass smtp.mailfrom=ace-bounces@ietf.org; spf=None smtp.helo=postmaster@mail.ietf.org; dkim=pass (signature verified) header.i=@ietf.org; dkim=hardfail (body hash did not verify [final]) header.i=@cisco.com; dmarc=fail (p=none dis=none) d=cisco.com X-from-outside-Cisco: 4.31.198.44 X-Files: signature.asc : 481 IronPort-PHdr: =?us-ascii?q?9a23=3AH0ePFRUVAhizegSm6UDjvwodxM7V8LGtZVwlr6E/?= =?us-ascii?q?grcLSJyIuqrYYBeGt8tkgFKBZ4jH8fUM07OQ6PG5HzNaqs7e+DBaKdoXBkdD0Z?= =?us-ascii?q?1X1yUbQ+e9QXXhK/DrayFoVO9jb3RCu0+BDE5OBczlbEfTqHDhpRQbGxH4KBYn?= =?us-ascii?q?br+tQt2asc272qiI9oHJZE0Q3XzmMOo0c0/99VqZ9pFPx9AzcuBpklqBi0ALUt?= =?us-ascii?q?we/XlvK1OXkkS0zeaL17knzR5tvek8/dVLS6TwcvdwZ7VZCDM7LzJ9v5Wz5lHr?= =?us-ascii?q?BDGC7XoEU2gQjgEAQ02ctEm7Dd/MtDDnvL99xDWCJp+xCq8rRnKj4rtlDhjyh2?= =?us-ascii?q?ACPj899WjRzctokKNcpgnmrhdykLPSe5yfYf93f6fBeoETTmcERMtISiFaHqu9?= =?us-ascii?q?YpcBSe0bMrFDsoP/qlAS+Aa4HhSmH+j1yzVF1UPxiJY91u07GAPblCUqH9MIuW?= =?us-ascii?q?qc+Nz/NKYUWP7z167NxC/Kbe5+xS385I/OcxtnqvaJC/Y4O8PaxGEuGh/LyFKK?= =?us-ascii?q?psatazqe28wMvnSVqe16WrT8pXQgrlRcpjmo2o8Ih4DTztYRx1ne3S54240yY9?= =?us-ascii?q?a/TRgoMpafDJJMunTCZMNNScQ4TjQt4X5ixw=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0FtAADmIdlXhyzGHwRcGgEBAQECAQEBA?= =?us-ascii?q?QgBAQEBFQEBAQECAQEBAQgBAQEBgn0SAQEBAQF1fI0zqyWBQjgBIQuFdQOBTzg?= =?us-ascii?q?UAQEBAQEBAQEBAQECEAEBAQoLCQkZL4IyBAEBAxEBBAUiFwYEAQEEAQEBAQEBJ?= =?us-ascii?q?gEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBCQINMRIBARoBAQEDAQE?= =?us-ascii?q?BIB0BAQQKHgwCAwECBgEBChgmBAICAwEjMAYBDAYCAQEBFogvAQICCa5pZ4RIA?= =?us-ascii?q?QEFh2wBAQEBAQEBAQEBAQEBAQEBAQEBAQEOBgMFiCqCVoQSCwYBAoMcgloBmWy?= =?us-ascii?q?DQIF1gy6GcYFuhGCDE4YBkFQggyiBeW6EJw4XMBiBQAEBAQ?= X-IPAS-Result: =?us-ascii?q?A0FtAADmIdlXhyzGHwRcGgEBAQECAQEBAQgBAQEBFQEBAQE?= =?us-ascii?q?CAQEBAQgBAQEBgn0SAQEBAQF1fI0zqyWBQjgBIQuFdQOBTzgUAQEBAQEBAQEBA?= =?us-ascii?q?QECEAEBAQoLCQkZL4IyBAEBAxEBBAUiFwYEAQEEAQEBAQEBJgEBAQEBAQEBAQE?= =?us-ascii?q?BAQEBAQEBAQEBAQEBAQEBAQEBAQEBCQINMRIBARoBAQEDAQEBIB0BAQQKHgwCA?= =?us-ascii?q?wECBgEBChgmBAICAwEjMAYBDAYCAQEBFogvAQICCa5pZ4RIAQEFh2wBAQEBAQE?= =?us-ascii?q?BAQEBAQEBAQEBAQEBAQEOBgMFiCqCVoQSCwYBAoMcgloBmWyDQIF1gy6GcYFuh?= =?us-ascii?q?GCDE4YBkFQggyiBeW6EJw4XMBiBQAEBAQ?= X-IronPort-AV: E=Sophos;i="5.30,333,1470700800"; d="asc'?scan'208";a="236678034" X-IronPort-Outbreak-Status: No, level 0, Unknown - Unknown Received: from mail.ietf.org ([4.31.198.44]) by alln-inbound-j.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 14 Sep 2016 10:10:11 +0000 Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E2FC512B278; Wed, 14 Sep 2016 03:10:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1473847810; bh=d3pis8JLEprwr7WJlbagaPUZXhcvWArdxZHncGjYwFA=; h=To:References:From:Date:In-Reply-To:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe; b=jUU5CvpFO88HYn4ul3U2VF37nyWzYxWAbB4q5NRsEHn1GHnprAFrv0nnKQO/9/oLZ KeTAZj46iRIjv3MD++RLU8FldPECzEEwomrWfNOV20iD/TVxHOaHaYkomGfpjiAkFr z9EZ7VgV4zwxBOwDjOaOK9IRY4jwY5B8ZoYT5NwU= 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 02BB912B274 for ; Wed, 14 Sep 2016 03:10:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.03 X-Spam-Level: X-Spam-Status: No, score=-16.03 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_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.508, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 9rXUtSn-I7Ul for ; Wed, 14 Sep 2016 03:10:05 -0700 (PDT) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 85D1312B059 for ; Wed, 14 Sep 2016 03:10:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4953; q=dns/txt; s=iport; t=1473847804; x=1475057404; h=subject:to:references:from:message-id:date:mime-version: in-reply-to; bh=xUd1Fd+ATFp/xKihLYxQ2BFJBXvDXCrtiYFMCIy5leE=; b=Ki29Tku7A0P2z9crW852pZY8rE01PEkgpW8VoL9H3LsrX4SWTN6qDsnu OUr+fzGM/erg/UD2Lek6bSsR27kcYYJVSP6cf4CyIvQjMV+ERuJL1CBSm 6rxCuTMgp/7JwAqR1zlfnVf3vLjb1VBu9Ppb9vJnmUd5nqvmvOzHKy6Gj U=; X-Files: signature.asc : 481 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D1AQCCINlX/xbLJq1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgzoBAQEBAXUqUo0zqyWCAxkLhXoCggMUAQIBAQEBAQEBXieEYgE?= =?us-ascii?q?BBAEBASBLGwsYKgICJzAGAQwGAgEBF4gvDq9YjDsBAQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QERCQWIKoJWhBILBgECgxyCWgEEmWiDQIF1gy6GcYFuhGCDE4YBkFYeNoRrOjS?= =?us-ascii?q?EJw4XgggBAQE?= X-IronPort-AV: E=Sophos;i="5.30,333,1470700800"; d="asc'?scan'208";a="688223528" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 14 Sep 2016 10:10:02 +0000 Received: from [10.61.64.112] (ams3-vpn-dhcp112.cisco.com [10.61.64.112]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id u8EAA2BN021970; Wed, 14 Sep 2016 10:10:02 GMT To: Somaraju Abhinav , "ace@ietf.org" References: <57909032.10809@gmx.net> <6d259c5b-28e3-c748-4590-0c9f942fe343@comcast.net> <378a0359-6b31-a30c-af28-8ea567b06b00@cisco.com> <57963480.2000809@gmx.net> <0d4c6d56-ebb5-2f43-d555-29c336396033@ericsson.com> <15169.1469642303@obiwan.sandelman.ca> <3271.1469656595@obiwan.sandelman.ca> <32aa7104-70df-80c7-8d6e-537b66716de9@comcast.net> <13663.1469714549@obiwan.sandelman.ca> <9a4153f1-6a96-0ae6-020b-0f0f966aecdf@cisco.com> <95997f84-2715-3287-39d3-45d6ff5f3ea0@comcast.net> <463a5cce-9dd1-5d68-bd97-0f08d0719960@sics.se> From: Eliot Lear Message-ID: Date: Wed, 14 Sep 2016 12:10:00 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.3.0 In-Reply-To: Archived-At: Subject: Re: [Ace] Group Communication Security Disagreements 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: , Content-Type: multipart/mixed; boundary="===============2168740074399737838==" Errors-To: ace-bounces@ietf.org Sender: Ace Return-Path: ace-bounces@ietf.org X-MS-Exchange-Organization-AuthSource: XCH-ALN-006.cisco.com X-MS-Exchange-Organization-AuthAs: Internal X-MS-Exchange-Organization-AuthMechanism: 10 X-MS-Exchange-Organization-Network-Message-Id: 952e278d-4e82-4b1b-206c-08d3dc875e97 X-MS-Exchange-Organization-AVStamp-Enterprise: 1.0 MIME-Version: 1.0 --===============2168740074399737838== Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="AX1sUXGxEc68lxUxqbSJNQS96IEsTw7Uj" --AX1sUXGxEc68lxUxqbSJNQS96IEsTw7Uj Content-Type: multipart/mixed; boundary="BLCwln8QLmBiGwbJIjS6skBBgxJETIep0"; protected-headers=v1 From: Eliot Lear To: Somaraju Abhinav , "ace@ietf.org" Message-ID: Subject: Re: [Ace] Group Communication Security Disagreements References: <57909032.10809@gmx.net> <6d259c5b-28e3-c748-4590-0c9f942fe343@comcast.net> <378a0359-6b31-a30c-af28-8ea567b06b00@cisco.com> <57963480.2000809@gmx.net> <0d4c6d56-ebb5-2f43-d555-29c336396033@ericsson.com> <15169.1469642303@obiwan.sandelman.ca> <3271.1469656595@obiwan.sandelman.ca> <32aa7104-70df-80c7-8d6e-537b66716de9@comcast.net> <13663.1469714549@obiwan.sandelman.ca> <9a4153f1-6a96-0ae6-020b-0f0f966aecdf@cisco.com> <95997f84-2715-3287-39d3-45d6ff5f3ea0@comcast.net> <463a5cce-9dd1-5d68-bd97-0f08d0719960@sics.se> In-Reply-To: --BLCwln8QLmBiGwbJIjS6skBBgxJETIep0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi Abhinav, Thanks for this email. I think this is pretty close to what I think is necessary. To be sure, vendors and developers have very little power to limit where their products will be placed. Thus it is important to state strongly that source authentication is necessary at other layers when it is not used at this layer. To me that would cover all circumstances. With that approach, I would strongly support the adoption of your document as a WG document and would of course review it and provide comments (as I have ;-). Regards, Eliot On 9/14/16 11:33 AM, Somaraju Abhinav wrote: > Hi all, > > Thank you all for the feedback on the group communication security disc= ussion. > > We noticed that two concerns have been raised with the current specific= ation. > 1) Symmetric keys do not provide source authentication. Here, most pe= ople on the mailing list agreed that symmetric keys provides basic securi= ty and is sufficient for lighting applications. It is not intended to be = used in the wider internet for more sensitive group communication securit= y use-cases. > 2) How to ensure that the symmetric key group communication security = solution is not used in situations it is not designed for? > > We propose to address the received feedback by making the following mod= ifications to the document: > > 1) We will add an additional section where we specify how asymmetric = cryptography can be used for secure group communication. This will help f= or all those cases where source authentication is desired. > 2) Add a security considerations section where we explain that the as= ymmetric key solution is the recommended approach but that there are situ= ations where low latency group communication makes it difficult to use as= ymmetric cryptography and where source authentication is less important. = You could call it an applicability statement. > > If this proposed modifications makes sense then we can try to submit a = new draft with these changes. > > Abhinav > ________________________________________________________ The contents o= f this e-mail and any attachments are confidential to the intended recipi= ent. They may not be disclosed to or used by or copied in any way by anyo= ne other than the intended recipient. If this e-mail is received in error= , please immediately notify the sender and delete the e-mail and attached= documents. Please note that neither the sender nor the sender's company = accept any responsibility for viruses and it is your responsibility to sc= an or otherwise check this e-mail and any attachments. > > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace > --BLCwln8QLmBiGwbJIjS6skBBgxJETIep0-- --AX1sUXGxEc68lxUxqbSJNQS96IEsTw7Uj 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 iQEcBAEBCAAGBQJX2SH5AAoJEIe2a0bZ0nozzX0IANJZHxAICCrgPUifYuwA3FL3 stY2ZdVa/l+/r9eC3NloOPyEdGHFUsk+v966UU3RM0DDWSuMjYh5lRASTBff91JE p2DPVJiVkgXPkM9V4pE/Df8pqZOonvUOkSZ6LJEkOV0ZmT5hPTufAROXsO+YN6sL AgjZAC2IOsrxkAZzAAzd9aW2mpWkCfl3kIuKlenBVkynLFQ6TjiJrMat17+nzoro VILhw6mppHvobOrcxPCGC67SQsKx9XUEdrxcwVA0rb38IBL4vdkflXn1ZFpL0Ism neQBS7yZ+wO/RcC47zZKJqK3bcMU/77Tj8JpVbyyUbZq7EVlDLVnMpaL4iaPnTo= =JXVc -----END PGP SIGNATURE----- --AX1sUXGxEc68lxUxqbSJNQS96IEsTw7Uj-- --===============2168740074399737838== Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace --===============2168740074399737838==-- --------------9CBA9CB09AECF8A00A97D342-- --HIAKB3f0mrrvlSb7cHS20oDJA8SgMTTqU-- --iRmT3dV6d2kfpcgCEQLNWefGAauVdWKeR 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 iQEcBAEBCAAGBQJX6QDMAAoJEIe2a0bZ0nozzw8IAJeNOti/4RbcdnQa4b8aA0Pj DLXXgHGo6d9OgCICXLswfTYJUN5uE5mpDSLWEMWcNVO9qbLSlQTaBK0ST+VWuHYz Z6LAR3S0S5TeIPhfxCHMEkvFJaxu2O2PtLDMVJIR8RvkwaFIfOemn5AQyDMUcjw0 70HVKxBz9QknG0FWa/4ndHKwY7iiHX/x7bZlrVYmSAXw+5TcjhVJ/jXOY1lUDiAM NqG8eRjTzDaJboxRRsn5k673GiRnxABcP7di6o8kkU8KhzAPi8yyqKrrdOAfOfE0 ynb6/+CLRFsgFn6mNV9UHn1HgDEFnqIyJNvYuwQp48WwQW4t6JZ30K5UT/lWScY= =5m7Q -----END PGP SIGNATURE----- --iRmT3dV6d2kfpcgCEQLNWefGAauVdWKeR-- From nobody Mon Sep 26 04:11:19 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 E4A2C12B152 for ; Mon, 26 Sep 2016 04:11:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.917 X-Spam-Level: X-Spam-Status: No, score=-4.917 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-2.316, 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 Cr3Yvf0fGPKb for ; Mon, 26 Sep 2016 04:11:16 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6AC0A12B13B for ; Mon, 26 Sep 2016 04:11:12 -0700 (PDT) Received: from [192.168.91.133] ([80.92.122.18]) by mail.gmx.com (mrgmx002) with ESMTPSA (Nemesis) id 0MMBun-1brXHn4Ajl-0082Rx; Mon, 26 Sep 2016 13:11:03 +0200 To: Kepeng Li , ace References: From: Hannes Tschofenig Message-ID: <1cc7f243-e7f7-6ec5-7140-88c74853dc34@gmx.net> Date: Mon, 26 Sep 2016 13:11:00 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:Ya/HgilGtGzgQ7kn3nec2o3aMY9Mizh28Wmuf61D1UZUv/6yFaf wHxGAB4lG5iGeJW9EFxUqax0GuOE8CmR3rBYg5WMW2F5+bVYl/nEFCIQIVuoabfKUq2iv4E Sy/kYcXXNp6njAFAfp3h/IZ5Z9+pDXz1nVLfh7f2c3+bYTg+tlV1/1Ayzs5UwSBIJb20jHw pNNCCZKxSlKLfI3mme5Eg== X-UI-Out-Filterresults: notjunk:1;V01:K0:3AVdt/72PDE=:9YAOnXUPwpdoX2IE6mgNVK lGkXWeGf1iL4QbxPdQojcoOzN1Ro4rJcPI3n8ZZvFWIbB4JDLMt6SCQeygzrY81n6pkeiz2Kt lJtkYggx+WQOzux15MOAbgpupUz96n5nnSnb/RZ5JIcMZCveNe6EjRm91H0/parm0w+uyIxyC wAJpr9ohQOgDvGLpEXI9T3fuSCYGk6MycbDmwxf1lcPzzLSuw1UOrR6P+80ORvfT9QIvK2EGm XwVcTapm2Ai2W2qbD4MkGCc1D/AOE/KuZxOWmUrYD0YD/49Ngxw9ympGbrpJvWOAY2Q4oeTUX pFyCbQ3bPSFQCXXeRYjvshU0PS5rENdapjm+yURAy8hvQ7Z/8sJSiCnJqYwNEU6D7NYFNNeWN Fp9kv5ARFUhBsHYug3MXf5shJP9CZ6a362hNow6H/vczvsttLAVsqfl2BBcLxp2buRuvZOp0D ejKmU28B/Gr/KRon2kLYnawy7tM7ojEbYxYoV9btMhrNp5aMBGSDHr88dL3YHVz0g6dPDX0cd ldQRu8NW9NHCDJuSsTpKFwGeuh4yKFtDPu59VHVAB/tTxWXLrwG4X9uUWysR0Ea0bK/TX0xUu QChx4ATqmO67lPgDKcHmsSCayfIB8GhPY+w7Jkk3xRdtVWTWWvPSf+9Wrci4ETEmNJWUidTvx 0x4R6hIDNd2+Qdyhlj0M5lD4JPO5q+AsvFBA2S7wAjxCHUKRCPrByxAjsQhqB77Qyenl+YEKk TsX1A0waVlhpEHG1VIi857zDabMkPaWxM3uh9YvogJDihXj6WCT5VIZw6XR27LHBNH2xZKNE+ D1F8gEl Archived-At: Cc: Kathleen Moriarty Subject: Re: [Ace] Summary of ACE Group Communication Security Discussion 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: Mon, 26 Sep 2016 11:11:18 -0000 I noticed that Eliot also expressed support for the approach presented by Abhinav, see https://mailarchive.ietf.org/arch/msg/ace/ctCtj9QT0WwBDki7vxgVeYVzFaI Ciao Hannes On 09/26/2016 07:11 PM, Kepeng Li wrote: > Hi all, > > > We went through all email exchanges again in order to see where we are. > Abhinav also proposed a way forward in his email to the list, > see https://www.ietf.org/mail-archive/web/ace/current/msg01961.html, > where he proposed to standardize a solution based on public key as well > as symmetric key cryptography. > > > Here is our impression of the views presented by various people. > > > Mike seems to think the only acceptable solution is to use messages > signed using public key crypto and is strongly against working on a > symmetric key group communication protocol. > > > Paul Duffy and Michael Richardson are in favor of defining a public key > crypto solution but it is not clear whether they are against specifying > a symmetric key solution as well. > > > Walter, Abhinav, Sandeep, Hannes are in favor of working on a symmetric > key group communication security protocols (as co-authors of the work). > Oscar Garcia (Philips) is also in favor of the work. > > > In this mail to the list, > see https://www.ietf.org/mail-archive/web/ace/current/msg01931.html, > Robert Cragie (ARM) expressed a view that public key crypto is the > preferred solution but others based on symmetric crypto are still worthy > of consideration. > > > Markus Grunwald (Osram) also appears to be in favor of the proposed > approach, see > > https://www.ietf.org/mail-archive/web/ace/current/msg01932.html > > > > Akbar Rahman also seems to be in favor of working on a group > communication security protocol, see > > https://www.ietf.org/mail-archive/web/ace/current/msg01873.html > > > > Ned Smith also seems to be in favor of working on a group communication > security protocol, as expressed in his mail to the list: > > https://www.ietf.org/mail-archive/web/ace/current/msg01872.html > > > > The opinion of the following persons in the discussion appear unclear to me: > > - Mohit Sethi > > - Ludwig Seitz > > - Carsten Bormann > > - Stephen Farrell > > - Jim Schaad (offered clarifications regarding the use of COSE) > > > > Pascal Urien and Rene Struik provided performance data but they didn't > appear to have expressed a strong view about the question regarding > symmetric vs. asymmetric crypto for group communication security. > > Derek Atkins offered performance data for public key crypto but refers > to new techniques (rather than RSA/ECC). > > > > Please correct us if we are wrong in our interpretation of your mail > postings. > > > > Ciao > > Hannes & Kepeng > > > > > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace > From nobody Mon Sep 26 05:30:41 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 61ECC12B1B5 for ; Mon, 26 Sep 2016 05:30:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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, 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 sAYIe3I8J3ys for ; Mon, 26 Sep 2016 05:30:38 -0700 (PDT) Received: from mail-qk0-x22e.google.com (mail-qk0-x22e.google.com [IPv6:2607:f8b0:400d:c09::22e]) (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 4501312B1B1 for ; Mon, 26 Sep 2016 05:30:38 -0700 (PDT) Received: by mail-qk0-x22e.google.com with SMTP id n185so161265670qke.1 for ; Mon, 26 Sep 2016 05:30:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=PLmkegpdOklqU5Iw4+44hivtQl3OmDJtIY3VjTiWn7w=; b=zCztKilB7GzSC+B6TKDWDKexZNo1d86bD+X4U0spNf75hcJSHXIkxaW9KvA5gWffO6 mMZxoUnBzuxgULFErVH1RLhAoaLePIRqKFI8FK4SZPeTUql9dgTA7E/plZVn1uj/VBL9 XLlxr6xR+4hD97wH5PpZEvluA9nCYuGwZMaoMU39Yq2AlRPxdQJuGwjbgfFTclJWenGR fNdrT7TG+FUM5flE1p/kpTxpOZ/qZtGqvgRdXtWksiAbu77q4WRu7I+B/CaAZlsks6LM AdOAq1txDO7JvV6igcVn1AIuXUlZQz5Zij5cklK5WeYihVLwcEDEH64PHXPaQLM7cooa G6Ww== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=PLmkegpdOklqU5Iw4+44hivtQl3OmDJtIY3VjTiWn7w=; b=g79se1Fw7jQ4SZFn4cKonySnOdnsYZP8EkOHjfraWs0Rw/a+9AqYhUMW0QMTBc1OqA b7vBcijUVhAXiORUpVB0sPlf7ijIFjwpk2T9/txz83Iy22fjYld9B6dY6TYw1doFELzJ BMEF6We+QDUAPE8yQ7a/Yvkv2NAGe1cICL4gOZwlac3h7B+zYuJZML5Xii8eLNE5fyyv yo7bIUsa4sbOyjnHmEcUA9asEQHhCcjdxPlt+ke3lrF5AvnAE5HrRvwJnDzccXMWRHan XW4puU06wI7co7UjBo9fu07pyhAM7MXU7WhZWUxA/I4XILs8VTc8c7juGN/N2d9Us5Du fJ+Q== X-Gm-Message-State: AA6/9RnUWv/I56TcoqwkyRJnkUNNBE8JfFDRIJipUGbwgLpdGc6mxmBD3awqFx63nfJ4Lw== X-Received: by 10.55.145.129 with SMTP id t123mr20589789qkd.130.1474893037305; Mon, 26 Sep 2016 05:30:37 -0700 (PDT) Received: from [192.168.1.8] (209-6-124-204.c3-0.arl-ubr1.sbo-arl.ma.cable.rcn.com. [209.6.124.204]) by smtp.gmail.com with ESMTPSA id x24sm11440659qtc.31.2016.09.26.05.30.36 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 26 Sep 2016 05:30:36 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: kathleen.moriarty.ietf@gmail.com X-Mailer: iPhone Mail (13G36) In-Reply-To: <1cc7f243-e7f7-6ec5-7140-88c74853dc34@gmx.net> Date: Mon, 26 Sep 2016 08:30:35 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <04FDEBEF-68CF-4DC6-B760-4DFB1B87D22C@gmail.com> References: <1cc7f243-e7f7-6ec5-7140-88c74853dc34@gmx.net> To: Hannes Tschofenig Archived-At: Cc: Kepeng Li , ace Subject: Re: [Ace] Summary of ACE Group Communication Security Discussion 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: Mon, 26 Sep 2016 12:30:40 -0000 Without a hat on, you can add my support to Abhinav's proposal. Perfect is i= deal, but you often can not make any progress if you accept nothing less. T= he security considerations section will have to be thorough. Kathleen=20 Please excuse typos, sent from handheld device=20 > On Sep 26, 2016, at 7:11 AM, Hannes Tschofenig = wrote: >=20 > I noticed that Eliot also expressed support for the approach presented by A= bhinav, see https://mailarchive.ietf.org/arch/msg/ace/ctCtj9QT0WwBDki7vxgVeY= VzFaI >=20 > Ciao > Hannes >=20 >> On 09/26/2016 07:11 PM, Kepeng Li wrote: >> Hi all, >>=20 >>=20 >> We went through all email exchanges again in order to see where we are. >> Abhinav also proposed a way forward in his email to the list, >> see https://www.ietf.org/mail-archive/web/ace/current/msg01961.html, >> where he proposed to standardize a solution based on public key as well >> as symmetric key cryptography. >>=20 >>=20 >> Here is our impression of the views presented by various people. >>=20 >>=20 >> Mike seems to think the only acceptable solution is to use messages >> signed using public key crypto and is strongly against working on a >> symmetric key group communication protocol. >>=20 >>=20 >> Paul Duffy and Michael Richardson are in favor of defining a public key >> crypto solution but it is not clear whether they are against specifying >> a symmetric key solution as well. >>=20 >>=20 >> Walter, Abhinav, Sandeep, Hannes are in favor of working on a symmetric >> key group communication security protocols (as co-authors of the work). >> Oscar Garcia (Philips) is also in favor of the work. >>=20 >>=20 >> In this mail to the list, >> see https://www.ietf.org/mail-archive/web/ace/current/msg01931.html, >> Robert Cragie (ARM) expressed a view that public key crypto is the >> preferred solution but others based on symmetric crypto are still worthy >> of consideration. >>=20 >>=20 >> Markus Grunwald (Osram) also appears to be in favor of the proposed >> approach, see >>=20 >> https://www.ietf.org/mail-archive/web/ace/current/msg01932.html >>=20 >>=20 >>=20 >> Akbar Rahman also seems to be in favor of working on a group >> communication security protocol, see >>=20 >> https://www.ietf.org/mail-archive/web/ace/current/msg01873.html >>=20 >>=20 >>=20 >> Ned Smith also seems to be in favor of working on a group communication >> security protocol, as expressed in his mail to the list: >>=20 >> https://www.ietf.org/mail-archive/web/ace/current/msg01872.html >>=20 >>=20 >>=20 >> The opinion of the following persons in the discussion appear unclear to m= e: >>=20 >> - Mohit Sethi >>=20 >> - Ludwig Seitz >>=20 >> - Carsten Bormann >>=20 >> - Stephen Farrell >>=20 >> - Jim Schaad (offered clarifications regarding the use of COSE) >>=20 >>=20 >>=20 >> Pascal Urien and Rene Struik provided performance data but they didn't >> appear to have expressed a strong view about the question regarding >> symmetric vs. asymmetric crypto for group communication security. >>=20 >> Derek Atkins offered performance data for public key crypto but refers >> to new techniques (rather than RSA/ECC). >>=20 >>=20 >>=20 >> Please correct us if we are wrong in our interpretation of your mail >> postings. >>=20 >>=20 >>=20 >> Ciao >>=20 >> Hannes & Kepeng >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> Ace mailing list >> Ace@ietf.org >> https://www.ietf.org/mailman/listinfo/ace >>=20 From nobody Mon Sep 26 08:41: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 1A60F12B2D3 for ; Mon, 26 Sep 2016 08:41:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.016 X-Spam-Level: X-Spam-Status: No, score=-5.016 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=-2.316, 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 ennA3GMptcu5 for ; Mon, 26 Sep 2016 08:41:52 -0700 (PDT) Received: from resqmta-ch2-08v.sys.comcast.net (resqmta-ch2-08v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:40]) (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 C6BFB12B1DF for ; Mon, 26 Sep 2016 08:41:52 -0700 (PDT) Received: from resomta-ch2-10v.sys.comcast.net ([69.252.207.106]) by resqmta-ch2-08v.sys.comcast.net with SMTP id oXzMbOza584vjoY2SbKLdJ; Mon, 26 Sep 2016 15:41:52 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1474904512; bh=QUczLg4b7/g7GVqbJxgJUReJfgwmFylOjgG8vYtv4xU=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=cKZ8WEGm2yOW67F9vO03vDaundAdqwColptJSbus4Wbf91JZzqYX14nx9cnww/ggJ /SGJy8zX9AQVuJ++E1BfgWBlKzr8hcLHh3VVbIf50g991g9dyixGgoTnzxgkZjcAGb oJMHFwNLlfxIEQLfidkRa5hVlbho5RUksoEdIIqynAi/gYLS+yuJ1ND/rSy7Vn3hFE C9rnCUn65IBTWSmkIWB7rON2e1XZDx2d+MoyNp1rUu+cvxkfQ2oUC111SmDAAIz736 lFy3hDsmE55Km2kVGJKDFRVQda549ZAYf0tosWfnTYPdxAgC5q50c0P6NrvleMw9jR y7cSuLfVYeOSA== Received: from [IPv6:2601:148:c000:10a4:cdb3:c1d0:3c22:ab2d] ([IPv6:2601:148:c000:10a4:cdb3:c1d0:3c22:ab2d]) by resomta-ch2-10v.sys.comcast.net with SMTP id oY2RbEFft8W1PoY2RbSfX9; Mon, 26 Sep 2016 15:41:52 +0000 To: ace@ietf.org References: <1cc7f243-e7f7-6ec5-7140-88c74853dc34@gmx.net> <04FDEBEF-68CF-4DC6-B760-4DFB1B87D22C@gmail.com> From: Michael StJohns Message-ID: Date: Mon, 26 Sep 2016 11:41:52 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0 MIME-Version: 1.0 In-Reply-To: <04FDEBEF-68CF-4DC6-B760-4DFB1B87D22C@gmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-CMAE-Envelope: MS4wfGOX28oK+XYNZMWQZ/LORT8w6uZN0fRJPq+atZISxlMWkny1RUDVejZTTkdM7WgIaBoacPnuzoAC1MuXV/3MeRZ3CYjGrjrxou2+rOHlV6WZc+dUIIRP f6lqtFLCIAXa2faeFIf8QLDd5gj5gKaOSWYjw4loMMwiA5v6EAY5b9R1GbKH1VweRH7o6Irtm0fj2A== Archived-At: Subject: Re: [Ace] Summary of ACE Group Communication Security Discussion 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: Mon, 26 Sep 2016 15:41:55 -0000 On 9/26/2016 8:30 AM, kathleen.moriarty.ietf@gmail.com wrote: > Without a hat on, you can add my support to Abhinav's proposal. Perfect is ideal, but you often can not make any progress if you accept nothing less. The security considerations section will have to be thorough. Hi Kathleen et al - To attain "rough consensus", RFC 7282 requires that "all issues be addressed" even if not all issues are accommodated. So far the basic issues of "this is unsafe as a mechanism for 'securing' a control protocol" or even "how the heck do we keep this off the broader internet" have not been addressed. I once again suggest that the lighting folk go off and write something that they implement as a group, and bring it back to the IETF as an informational "here's how we did it" document, rather than adopting this as a WG item. The ONLY thing that even argues for considering symmetric key multicast (vice asymmetric key multicast) is the latency claims for lighting. I haven't yet heard of another use case with the particular combination of cheapness and latency of lighting which would suggest this particular combination is useful elsewhere. With respect to Abhinav's proposal, we've already got several group key manager systems - we don't actually use any of them for control systems, and you might want to inquire as to the reason. [RFC2093,2094] [RFC4046] [RFC4535] With respect to Eliot's comment, it doesn't really matter if the key management protocol is asymmetric if the multicast session keys are symmetric and used for control. The analysis of this can pretty much ignore the key management piece and start with 100 controllers and 1000 actuators with pre-shared keys to consider the threat and mitigation models. Which analysis - AFAICT - no one has actually done. Basically, if you can't secure this 100/1000 system and keep it secure with respect to control functions, I would argue that the rest of it (e.g. key management) is meaningless window dressing. Later, Mike ps - do you *really* want to reinvent SCADA and all its security issues? > > Kathleen > > Please excuse typos, sent from handheld device > >> On Sep 26, 2016, at 7:11 AM, Hannes Tschofenig wrote: >> >> I noticed that Eliot also expressed support for the approach presented by Abhinav, see https://mailarchive.ietf.org/arch/msg/ace/ctCtj9QT0WwBDki7vxgVeYVzFaI >> >> Ciao >> Hannes >> >>> On 09/26/2016 07:11 PM, Kepeng Li wrote: >>> Hi all, >>> >>> >>> We went through all email exchanges again in order to see where we are. >>> Abhinav also proposed a way forward in his email to the list, >>> see https://www.ietf.org/mail-archive/web/ace/current/msg01961.html, >>> where he proposed to standardize a solution based on public key as well >>> as symmetric key cryptography. >>> >>> >>> Here is our impression of the views presented by various people. >>> >>> >>> Mike seems to think the only acceptable solution is to use messages >>> signed using public key crypto and is strongly against working on a >>> symmetric key group communication protocol. >>> >>> >>> Paul Duffy and Michael Richardson are in favor of defining a public key >>> crypto solution but it is not clear whether they are against specifying >>> a symmetric key solution as well. >>> >>> >>> Walter, Abhinav, Sandeep, Hannes are in favor of working on a symmetric >>> key group communication security protocols (as co-authors of the work). >>> Oscar Garcia (Philips) is also in favor of the work. >>> >>> >>> In this mail to the list, >>> see https://www.ietf.org/mail-archive/web/ace/current/msg01931.html, >>> Robert Cragie (ARM) expressed a view that public key crypto is the >>> preferred solution but others based on symmetric crypto are still worthy >>> of consideration. >>> >>> >>> Markus Grunwald (Osram) also appears to be in favor of the proposed >>> approach, see >>> >>> https://www.ietf.org/mail-archive/web/ace/current/msg01932.html >>> >>> >>> >>> Akbar Rahman also seems to be in favor of working on a group >>> communication security protocol, see >>> >>> https://www.ietf.org/mail-archive/web/ace/current/msg01873.html >>> >>> >>> >>> Ned Smith also seems to be in favor of working on a group communication >>> security protocol, as expressed in his mail to the list: >>> >>> https://www.ietf.org/mail-archive/web/ace/current/msg01872.html >>> >>> >>> >>> The opinion of the following persons in the discussion appear unclear to me: >>> >>> - Mohit Sethi >>> >>> - Ludwig Seitz >>> >>> - Carsten Bormann >>> >>> - Stephen Farrell >>> >>> - Jim Schaad (offered clarifications regarding the use of COSE) >>> >>> >>> >>> Pascal Urien and Rene Struik provided performance data but they didn't >>> appear to have expressed a strong view about the question regarding >>> symmetric vs. asymmetric crypto for group communication security. >>> >>> Derek Atkins offered performance data for public key crypto but refers >>> to new techniques (rather than RSA/ECC). >>> >>> >>> >>> Please correct us if we are wrong in our interpretation of your mail >>> postings. >>> >>> >>> >>> Ciao >>> >>> Hannes & Kepeng >>> >>> >>> >>> >>> _______________________________________________ >>> Ace mailing list >>> Ace@ietf.org >>> https://www.ietf.org/mailman/listinfo/ace >>> > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace From nobody Mon Sep 26 09:10:52 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 B26C512B310 for ; Mon, 26 Sep 2016 09:10:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.838 X-Spam-Level: X-Spam-Status: No, score=-16.838 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_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-2.316, 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 uRljx8gt5cxD for ; Mon, 26 Sep 2016 09:10:49 -0700 (PDT) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 273A512B24C for ; Mon, 26 Sep 2016 09:10:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2914; q=dns/txt; s=iport; t=1474906249; x=1476115849; h=subject:to:references:from:message-id:date:mime-version: in-reply-to; bh=byfzZr8b5qWTGNhCdTAUzysEP+YpUcJZ053mwhCKnOM=; b=X1hAcNZnnwkaLttm6VUWZyydQiuAt7rWgpTVawIj4vRN3bY4OWAwcR5j G4ONWIkZBKPhHRuX6kIGmxHCxYntgoKt/SSxzC/nslehzkHv/xv2N7uqq jq9TMsm8MLEMfUPqR4lFHnVPSfRhER9hyctIg+w7G5fhn+9zwsxx8Njv9 0=; X-Files: signature.asc : 481 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0B8BABDSOlX/xbLJq1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgz0BAQEBAYEfuVSCBIYeAoIYEgECAQEBAQEBAV4nhGEBAQEDASN?= =?us-ascii?q?bCwsYKgICVwYBDAgBAYg/CLIIjGABAQEBAQEBAwEBAQEBAQESDogzgliHSIJaA?= =?us-ascii?q?QSZdoNBgXaKMYlmhgWQZyQBL4UHPIgaAQEB?= X-IronPort-AV: E=Sophos;i="5.30,400,1470700800"; d="asc'?scan'208";a="688521372" Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 26 Sep 2016 16:10:22 +0000 Received: from [10.61.210.79] ([10.61.210.79]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id u8QGAMar005698; Mon, 26 Sep 2016 16:10:22 GMT To: Michael StJohns , ace@ietf.org References: <1cc7f243-e7f7-6ec5-7140-88c74853dc34@gmx.net> <04FDEBEF-68CF-4DC6-B760-4DFB1B87D22C@gmail.com> From: Eliot Lear Message-ID: <3dbd8a79-ca4b-3f71-d838-e30beda754be@cisco.com> Date: Mon, 26 Sep 2016 18:10:21 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="i0OUE7tlNLh8SF3UEEWDf2g5wkfJdLwBO" Archived-At: Subject: Re: [Ace] Summary of ACE Group Communication Security Discussion 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: Mon, 26 Sep 2016 16:10:51 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --i0OUE7tlNLh8SF3UEEWDf2g5wkfJdLwBO Content-Type: multipart/mixed; boundary="pDIcAHaA1loG7WliRaaNOuaHD7EI4QrSr"; protected-headers="v1" From: Eliot Lear To: Michael StJohns , ace@ietf.org Message-ID: <3dbd8a79-ca4b-3f71-d838-e30beda754be@cisco.com> Subject: Re: [Ace] Summary of ACE Group Communication Security Discussion References: <1cc7f243-e7f7-6ec5-7140-88c74853dc34@gmx.net> <04FDEBEF-68CF-4DC6-B760-4DFB1B87D22C@gmail.com> In-Reply-To: --pDIcAHaA1loG7WliRaaNOuaHD7EI4QrSr Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Mike, Just one clarification: On 9/26/16 5:41 PM, Michael StJohns wrote: > > With respect to Eliot's comment, it doesn't really matter if the key > management protocol is asymmetric if the multicast session keys are > symmetric and used for control. =20 This doesn't really capture my position which leads me to believe I've muddled it. The key question is whether every transaction needs to be authenticated to a unique device *within this protocol* or is it sufficient that such authentication exists at other layers, e.g., either in content or at lower layers? I recognize that there are some big risks to adding such a dependency, because there is no certainty that implementations will follow that guidance. > The analysis of this can pretty much ignore the key management piece > and start with 100 controllers and 1000 actuators with pre-shared keys > to consider the threat and mitigation models. Which analysis - AFAICT > - no one has actually done. Basically, if you can't secure this > 100/1000 system and keep it secure with respect to control functions, > I would argue that the rest of it (e.g. key management) is meaningless > window dressing. The question in this context again, is whether it all has to happen at this layer? Eliot --pDIcAHaA1loG7WliRaaNOuaHD7EI4QrSr-- --i0OUE7tlNLh8SF3UEEWDf2g5wkfJdLwBO 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 iQEcBAEBCAAGBQJX6UhtAAoJEIe2a0bZ0nozwQAIAM0yT+6Te5UAPn1snwdm01rO Q++5ErB7hXV62Qqa2/yCxCnZrecztDhswNFOCQ9t96uNJf2WrHglpFDlJW44ngEf auunpIfKoslBBPqX4AFLUa4GPnLLnYr0IxuOkg4zyMSy27JLSYBYZlcvCEg6hfBY 71He7vkgiQhCu9w4iGKKMIMIEvWAkYLttqEljU9obM0HyUtEVnlltdoLEx7sXrM3 qXAYGV4+yHtPdK5xrWu9gzbVrWbRGOKVxSCX4ESY6YYmMCGvoOyQgMj0hnhjpogC WBHSFaE47zVyJdCz2vc6ELJpQDNEqVTnFUz8momEruWxVvNA+R+yUD/Ol0C3N40= =E8yU -----END PGP SIGNATURE----- --i0OUE7tlNLh8SF3UEEWDf2g5wkfJdLwBO-- From nobody Mon Sep 26 09:31:30 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 555B412B320 for ; Mon, 26 Sep 2016 09:31:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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, 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 TeKknMiejwtD for ; Mon, 26 Sep 2016 09:31:26 -0700 (PDT) Received: from mail-qk0-x236.google.com (mail-qk0-x236.google.com [IPv6:2607:f8b0:400d:c09::236]) (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 1F88A12B226 for ; Mon, 26 Sep 2016 09:31:26 -0700 (PDT) Received: by mail-qk0-x236.google.com with SMTP id z190so169037484qkc.3 for ; Mon, 26 Sep 2016 09:31:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=5TP085PX0dxViZn/hMegUPVdiqiVlWBl/I9L8SY/I14=; b=0uxoQFHo+HB1yxEfShRobX0RwzTkcNTcXRXn3QbDfWe4PJCr4uvZ6B5GvtKS06xVcU XpzHmoswLL7x5EXGtsKsE/nppoogdoPidYDvL9Oe4KQf9IaMmKkLtK78CSl/6zjj3YqL t6r1rtqdSyJiCl18ez2zyJqYtvH108IYUkRIZSs3o+8zBnUQpn4xgmYodR2pjZWErIZU kKJe8OLJHgVclPlJ/afK1Sd5QZkAvKdQLsRewYc+j6AmNHVaURVIjaHmn91kVMaLk0HR kORFwodOaiXyOt2nGV4Y2OEOj0v5u9cTvnVgVnf7esOi+oz8Opd7YC214ZQQb6Oq1v/+ HNRQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=5TP085PX0dxViZn/hMegUPVdiqiVlWBl/I9L8SY/I14=; b=DwqjOe26z4N6Tcv69Grk83wv6x3iPCyplrwH0N1IE1LbzvYMK7lSSLSynSQvvMgZtc wTolphOaxyHyh7pQrrj3URT8bAdbL93ZIDuike0zFkR4qkei+TIrihJEl4Dq9UtsaU+5 Paar0utvA2pNR5UOzaQf1GtZDsmzjRJQOqfKafTfMXhAcAamclAe63gX81KebxwrYaKj IwPlr1+YKRj428bEyjoo6eAB9j/DMbyqbIFowJLgyl+mEPc4miYGUFiD+bkCaLCelUps dc/AtmaKu2UztIZsPcrml0bWG5vLWxtQD1WWM7NNVS6g6FNFQaHbJ6kQ8BFJD4Lt1iau 8J1A== X-Gm-Message-State: AA6/9RmUEsSfGv5RTH38KnEDndh0i5Rb0u5ewQ7Re5Nf8gclPsQEA+I0xR9GBlCm0uzXJA== X-Received: by 10.55.72.72 with SMTP id v69mr16733733qka.278.1474907485225; Mon, 26 Sep 2016 09:31:25 -0700 (PDT) Received: from [192.168.1.8] (209-6-124-204.c3-0.arl-ubr1.sbo-arl.ma.cable.rcn.com. [209.6.124.204]) by smtp.gmail.com with ESMTPSA id 5sm11986380qts.45.2016.09.26.09.31.24 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 26 Sep 2016 09:31:24 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: kathleen.moriarty.ietf@gmail.com X-Mailer: iPhone Mail (13G36) In-Reply-To: Date: Mon, 26 Sep 2016 12:31:24 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1cc7f243-e7f7-6ec5-7140-88c74853dc34@gmx.net> <04FDEBEF-68CF-4DC6-B760-4DFB1B87D22C@gmail.com> To: Michael StJohns Archived-At: Cc: ace@ietf.org Subject: Re: [Ace] Summary of ACE Group Communication Security Discussion 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: Mon, 26 Sep 2016 16:31:28 -0000 This time as AD. Please excuse typos, sent from handheld device=20 > On Sep 26, 2016, at 11:41 AM, Michael StJohns wrote= : >=20 >> On 9/26/2016 8:30 AM, kathleen.moriarty.ietf@gmail.com wrote: >> Without a hat on, you can add my support to Abhinav's proposal. Perfect i= s ideal, but you often can not make any progress if you accept nothing less.= The security considerations section will have to be thorough. >=20 > Hi Kathleen et al - >=20 > To attain "rough consensus", RFC 7282 requires that "all issues be address= ed" even if not all issues are accommodated. So far the basic issues of "th= is is unsafe as a mechanism for 'securing' a control protocol" or even "how t= he heck do we keep this off the broader internet" have not been addressed. This can be addressed in a draft security considerations. The scope can be m= ade applicable to what's needed to constrain its use. The chairs haven't put out a decision and your concerns have been heard. Th= ey are working to assess consensus. Best regards, Kathleen=20 >=20 > I once again suggest that the lighting folk go off and write something tha= t they implement as a group, and bring it back to the IETF as an information= al "here's how we did it" document, rather than adopting this as a WG item. = The ONLY thing that even argues for considering symmetric key multicast (vi= ce asymmetric key multicast) is the latency claims for lighting. I haven't y= et heard of another use case with the particular combination of cheapness an= d latency of lighting which would suggest this particular combination is use= ful elsewhere. >=20 > With respect to Abhinav's proposal, we've already got several group key ma= nager systems - we don't actually use any of them for control systems, and y= ou might want to inquire as to the reason. [RFC2093,2094] [RFC4046] [RFC4535= ] >=20 > With respect to Eliot's comment, it doesn't really matter if the key manag= ement protocol is asymmetric if the multicast session keys are symmetric and= used for control. The analysis of this can pretty much ignore the key mana= gement piece and start with 100 controllers and 1000 actuators with pre-shar= ed keys to consider the threat and mitigation models. Which analysis - AFAIC= T - no one has actually done. Basically, if you can't secure this 100/1000 s= ystem and keep it secure with respect to control functions, I would argue t= hat the rest of it (e.g. key management) is meaningless window dressing. >=20 > Later, Mike >=20 > ps - do you *really* want to reinvent SCADA and all its security issues? >=20 >>=20 >> Kathleen >>=20 >> Please excuse typos, sent from handheld device >>=20 >>> On Sep 26, 2016, at 7:11 AM, Hannes Tschofenig wrote: >>>=20 >>> I noticed that Eliot also expressed support for the approach presented b= y Abhinav, see https://mailarchive.ietf.org/arch/msg/ace/ctCtj9QT0WwBDki7vxg= VeYVzFaI >>>=20 >>> Ciao >>> Hannes >>>=20 >>>> On 09/26/2016 07:11 PM, Kepeng Li wrote: >>>> Hi all, >>>>=20 >>>>=20 >>>> We went through all email exchanges again in order to see where we are.= >>>> Abhinav also proposed a way forward in his email to the list, >>>> see https://www.ietf.org/mail-archive/web/ace/current/msg01961.html, >>>> where he proposed to standardize a solution based on public key as well= >>>> as symmetric key cryptography. >>>>=20 >>>>=20 >>>> Here is our impression of the views presented by various people. >>>>=20 >>>>=20 >>>> Mike seems to think the only acceptable solution is to use messages >>>> signed using public key crypto and is strongly against working on a >>>> symmetric key group communication protocol. >>>>=20 >>>>=20 >>>> Paul Duffy and Michael Richardson are in favor of defining a public key= >>>> crypto solution but it is not clear whether they are against specifying= >>>> a symmetric key solution as well. >>>>=20 >>>>=20 >>>> Walter, Abhinav, Sandeep, Hannes are in favor of working on a symmetric= >>>> key group communication security protocols (as co-authors of the work).= >>>> Oscar Garcia (Philips) is also in favor of the work. >>>>=20 >>>>=20 >>>> In this mail to the list, >>>> see https://www.ietf.org/mail-archive/web/ace/current/msg01931.html, >>>> Robert Cragie (ARM) expressed a view that public key crypto is the >>>> preferred solution but others based on symmetric crypto are still worth= y >>>> of consideration. >>>>=20 >>>>=20 >>>> Markus Grunwald (Osram) also appears to be in favor of the proposed >>>> approach, see >>>>=20 >>>> https://www.ietf.org/mail-archive/web/ace/current/msg01932.html >>>>=20 >>>>=20 >>>>=20 >>>> Akbar Rahman also seems to be in favor of working on a group >>>> communication security protocol, see >>>>=20 >>>> https://www.ietf.org/mail-archive/web/ace/current/msg01873.html >>>>=20 >>>>=20 >>>>=20 >>>> Ned Smith also seems to be in favor of working on a group communication= >>>> security protocol, as expressed in his mail to the list: >>>>=20 >>>> https://www.ietf.org/mail-archive/web/ace/current/msg01872.html >>>>=20 >>>>=20 >>>>=20 >>>> The opinion of the following persons in the discussion appear unclear t= o me: >>>>=20 >>>> - Mohit Sethi >>>>=20 >>>> - Ludwig Seitz >>>>=20 >>>> - Carsten Bormann >>>>=20 >>>> - Stephen Farrell >>>>=20 >>>> - Jim Schaad (offered clarifications regarding the use of COSE) >>>>=20 >>>>=20 >>>>=20 >>>> Pascal Urien and Rene Struik provided performance data but they didn't >>>> appear to have expressed a strong view about the question regarding >>>> symmetric vs. asymmetric crypto for group communication security. >>>>=20 >>>> Derek Atkins offered performance data for public key crypto but refers >>>> to new techniques (rather than RSA/ECC). >>>>=20 >>>>=20 >>>>=20 >>>> Please correct us if we are wrong in our interpretation of your mail >>>> postings. >>>>=20 >>>>=20 >>>>=20 >>>> Ciao >>>>=20 >>>> Hannes & Kepeng >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> Ace mailing list >>>> Ace@ietf.org >>>> https://www.ietf.org/mailman/listinfo/ace >> _______________________________________________ >> Ace mailing list >> Ace@ietf.org >> https://www.ietf.org/mailman/listinfo/ace >=20 >=20 > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace From nobody Mon Sep 26 10:00:11 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 40B0F12B2FE for ; Mon, 26 Sep 2016 10:00:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.016 X-Spam-Level: X-Spam-Status: No, score=-5.016 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=-2.316, 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 SkduftNZX5J2 for ; Mon, 26 Sep 2016 10:00:06 -0700 (PDT) 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 89F2A12B24B for ; Mon, 26 Sep 2016 10:00:05 -0700 (PDT) Received: from resomta-ch2-04v.sys.comcast.net ([69.252.207.100]) by resqmta-ch2-01v.sys.comcast.net with SMTP id oZFvbFCXrTaLwoZG8bagIG; Mon, 26 Sep 2016 17:00:04 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1474909204; bh=/BYxUl6iNCGy6+6D1GaGj6huOGlZNccHAbhwxQF3IQs=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=NXdfmiehgtkPBvbgcUgIkHWyTeRtWof2qQY6wL976mVHV9TJH+8iTg1tyy2Z9G0bz rsc3wP/aqHOJaOvfFTsTp79vUKvrQpRgIjM7iqutZQuSY+LesHj5DCYVZUzb7c7yxD Pgc1w+ErGnKxYRKmy7TStB87e0Hl8L775u4zSIubaZv5cvT51z+Hyv6dwedDjj/q7z rnQopI60K6DW2lHflocrPbhP2H7jJ3esbTBpPYl6/Odl0tCQAufpQbRGezgbAVJ51P c68mMTu9bpgxaKdrCddBK1Z2ufiESfKM2PtmlXiByiVOYtUACCcV8sKxT3cCrOGcSd fdld4JyKqR+4Q== Received: from [192.168.1.117] ([69.255.115.150]) by resomta-ch2-04v.sys.comcast.net with SMTP id oZG7bvJm8VK25oZG8bg9aO; Mon, 26 Sep 2016 17:00:04 +0000 To: Eliot Lear , ace@ietf.org References: <1cc7f243-e7f7-6ec5-7140-88c74853dc34@gmx.net> <04FDEBEF-68CF-4DC6-B760-4DFB1B87D22C@gmail.com> <3dbd8a79-ca4b-3f71-d838-e30beda754be@cisco.com> From: Michael StJohns Message-ID: Date: Mon, 26 Sep 2016 12:59:23 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0 MIME-Version: 1.0 In-Reply-To: <3dbd8a79-ca4b-3f71-d838-e30beda754be@cisco.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-CMAE-Envelope: MS4wfEjAZQrYWn3dwdgXai3rGoleE1nO9XXCG7xNpz5ucboARKVvtNNCujHtuoG3xaB+0J4Mbb2iOCDcYCpLJoM6SESQ09aCV4+7jd1ZsIfijFfVGT2At/OQ 1kMkH2BeFX8P5w92bUCIdX/QPwsfNDxpSVRszY7CwnORZns6RTuv8bYxXsw+NCTTGpWzHC+SSJbbxQ== Archived-At: Subject: Re: [Ace] Summary of ACE Group Communication Security Discussion 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: Mon, 26 Sep 2016 17:00:10 -0000 On 9/26/2016 12:10 PM, Eliot Lear wrote: > Hi Mike, > > Just one clarification: > > > On 9/26/16 5:41 PM, Michael StJohns wrote: >> With respect to Eliot's comment, it doesn't really matter if the key >> management protocol is asymmetric if the multicast session keys are >> symmetric and used for control. > This doesn't really capture my position which leads me to believe I've > muddled it. The key question is whether every transaction needs to be > authenticated to a unique device *within this protocol* or is it > sufficient that such authentication exists at other layers, e.g., either > in content or at lower layers? I recognize that there are some big > risks to adding such a dependency, because there is no certainty that > implementations will follow that guidance. Hi Eliot - Ah - sorry, I didn't understand what you meant. Let me discuss a few more things and hopefully that will clarify things. Multicast traffic falls into three broad groups: Content (e.g. broadcast audio/video etc), sensor and control. Of these three, only the first has a real (non-mitigated) symmetric key story: if you can break into an end node to steal its copy of the multicast key, you can break into an end node to steal the content, so the compromise of the multicast key and the compromise of the node have similar impacts. In other words, the risk of using symmetric key multicast is no worse than the risk of using symmetric key unicast. For the other two, it comes down to source authentication: being able to forge either a control command or a sensor datum can have *bad* consequences (e.g. having the sensor tell you that the coolant level in the cooling pond for nuclear rods is too high so you pump out what you think is the excess; having a key extracted from an actuator node telling the pump to go on). In the latter two cases, breaking into the node can allow you to do more than the node is legitimately authorized to do, and can allow you to masquerade as any node that uses that key for authentication. In this case, using symmetric key multicast is *MUCH* worse than using symmetric key unicast with respect to the security guarantees. So far so good? In the instant case - lighting - there's really no secret content to speak of, and hence the content confidentiality model of multicast with symmetric keys is really inapplicable. So, if confidentiality isn't a really a requirement, and you can't achieve source authentication (required for sensor or control) with symmetric key multicast, why do it? > >> The analysis of this can pretty much ignore the key management piece >> and start with 100 controllers and 1000 actuators with pre-shared keys >> to consider the threat and mitigation models. Which analysis - AFAICT >> - no one has actually done. Basically, if you can't secure this >> 100/1000 system and keep it secure with respect to control functions, >> I would argue that the rest of it (e.g. key management) is meaningless >> window dressing. > The question in this context again, is whether it all has to happen at > this layer? Can you figure out any way to prevent implementers and designers from using the symmetric multicast key for authentication? If so, then the answer is yes, If not, then no. This is what I've been talking about when I say "crippling" the protocol to prevent the abuses. You might as well do an all in one secure protocol at this level rather than leaving this an exercise for the student. That's not to say that application layer protocols might not also have their own authentication. Later, Mike > > Eliot > > From nobody Mon Sep 26 10:18:16 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 40CBA12B305 for ; Mon, 26 Sep 2016 10:18:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.016 X-Spam-Level: X-Spam-Status: No, score=-5.016 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=-2.316, 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 hAcoAm97G442 for ; Mon, 26 Sep 2016 10:18:05 -0700 (PDT) Received: from resqmta-ch2-08v.sys.comcast.net (resqmta-ch2-08v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:40]) (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 64DCF12B2F7 for ; Mon, 26 Sep 2016 10:17:43 -0700 (PDT) Received: from resomta-ch2-20v.sys.comcast.net ([69.252.207.116]) by resqmta-ch2-08v.sys.comcast.net with SMTP id oZX7bP8x684vjoZXCbKiEm; Mon, 26 Sep 2016 17:17:42 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1474910262; bh=QW1q27llRnoOveXxL5fKCXduOKe0sY+vfKjmonYcjoQ=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=TaJkaO9muHVvYHP/NIZMf8wGlHXyPo8wZTOtv8uFyBUFaKUonQkFfQZbXvyeZr1FA e4lo41jh7NfUvtfI9MgTZBA3+HdwhlswTPZ8rXKmqIgO5hMjLZkTgv4JGZBDnQ/ui5 P5Z/MWld+SzIUAU54hQTeo0zgFg5k9+/8LEoXrndXv35+wVH0zxsYYLwb/957tSrL2 fW61UYGhggnoafycED39HDQTUX4/i2Q0PMouF2xJM8VlC5q+BVcf3C2t1NPSM94lt3 CoL4S8+lapHp83fB26+g/WaYSEZyEgVgYp4lLY9odfK2mznoV+QbF+aL8amh5BEvdr HoSmAexE5rmxg== Received: from [192.168.1.117] ([69.255.115.150]) by resomta-ch2-20v.sys.comcast.net with SMTP id oZXBbz8BfMDTioZXCb8xx1; Mon, 26 Sep 2016 17:17:42 +0000 To: kathleen.moriarty.ietf@gmail.com References: <1cc7f243-e7f7-6ec5-7140-88c74853dc34@gmx.net> <04FDEBEF-68CF-4DC6-B760-4DFB1B87D22C@gmail.com> From: Michael StJohns Message-ID: <27af5f67-29d4-9f53-312f-31855603d451@comcast.net> Date: Mon, 26 Sep 2016 13:17:43 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-CMAE-Envelope: MS4wfDVwJ/fdGe307Spca1mv3745EsuJTX+JnkzjrnXMMeN39zfxqTy23LIm8CKpa0Zomf7cNw2JTdxuPmG9coVJp73agO9ZfVyu7a4DZXXzUFh/7RusB5SL +taAftTXihr13LgjQP1nHVYCYczjyZCXDw/eial8RYLCb9h1hupXg89XmHbjaxuFzYjYrYeqzuS04egYFVuDIxY6qILnwXq1eW8= Archived-At: Cc: ace@ietf.org Subject: Re: [Ace] Summary of ACE Group Communication Security Discussion 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: Mon, 26 Sep 2016 17:18:15 -0000 On 9/26/2016 12:31 PM, kathleen.moriarty.ietf@gmail.com wrote: > This time as AD. > > Please excuse typos, sent from handheld device > >> On Sep 26, 2016, at 11:41 AM, Michael StJohns wrote: >> >>> On 9/26/2016 8:30 AM, kathleen.moriarty.ietf@gmail.com wrote: >>> Without a hat on, you can add my support to Abhinav's proposal. Perfect is ideal, but you often can not make any progress if you accept nothing less. The security considerations section will have to be thorough. >> Hi Kathleen et al - >> >> To attain "rough consensus", RFC 7282 requires that "all issues be addressed" even if not all issues are accommodated. So far the basic issues of "this is unsafe as a mechanism for 'securing' a control protocol" or even "how the heck do we keep this off the broader internet" have not been addressed. > This can be addressed in a draft security considerations. The scope can be made applicable to what's needed to constrain its use. With respect - no. The issue is with respect to the discussion of whether or not to adopt this as a WG item. To "address" the issue, there has to be an offer of proof that someone actually knows how to address it - BEFORE the item is adopted. I may have missed that offer of proof, but I don't think so. You're suggesting that the way of addressing this is to ignore the issues, adopt it the work item, and at some far distant future point make sure there is a security considerations section that says something that might or might not be meaningful. "I will gladly pay you Tuesday for a hamburger today" - J Wellington Wimpy. An interesting approach, but probably not in keeping with correct process. > > The chairs haven't put out a decision and your concerns have been heard. They are working to assess consensus. The counter point to my concerns being heard is them being "addressed" as part of assessing consensus. It says so right there in RFC 7282. Later, Mike > > Best regards, > Kathleen > >> I once again suggest that the lighting folk go off and write something that they implement as a group, and bring it back to the IETF as an informational "here's how we did it" document, rather than adopting this as a WG item. The ONLY thing that even argues for considering symmetric key multicast (vice asymmetric key multicast) is the latency claims for lighting. I haven't yet heard of another use case with the particular combination of cheapness and latency of lighting which would suggest this particular combination is useful elsewhere. >> >> With respect to Abhinav's proposal, we've already got several group key manager systems - we don't actually use any of them for control systems, and you might want to inquire as to the reason. [RFC2093,2094] [RFC4046] [RFC4535] >> >> With respect to Eliot's comment, it doesn't really matter if the key management protocol is asymmetric if the multicast session keys are symmetric and used for control. The analysis of this can pretty much ignore the key management piece and start with 100 controllers and 1000 actuators with pre-shared keys to consider the threat and mitigation models. Which analysis - AFAICT - no one has actually done. Basically, if you can't secure this 100/1000 system and keep it secure with respect to control functions, I would argue that the rest of it (e.g. key management) is meaningless window dressing. >> >> Later, Mike >> >> ps - do you *really* want to reinvent SCADA and all its security issues? >> >>> Kathleen >>> >>> Please excuse typos, sent from handheld device >>> >>>> On Sep 26, 2016, at 7:11 AM, Hannes Tschofenig wrote: >>>> >>>> I noticed that Eliot also expressed support for the approach presented by Abhinav, see https://mailarchive.ietf.org/arch/msg/ace/ctCtj9QT0WwBDki7vxgVeYVzFaI >>>> >>>> Ciao >>>> Hannes >>>> >>>>> On 09/26/2016 07:11 PM, Kepeng Li wrote: >>>>> Hi all, >>>>> >>>>> >>>>> We went through all email exchanges again in order to see where we are. >>>>> Abhinav also proposed a way forward in his email to the list, >>>>> see https://www.ietf.org/mail-archive/web/ace/current/msg01961.html, >>>>> where he proposed to standardize a solution based on public key as well >>>>> as symmetric key cryptography. >>>>> >>>>> >>>>> Here is our impression of the views presented by various people. >>>>> >>>>> >>>>> Mike seems to think the only acceptable solution is to use messages >>>>> signed using public key crypto and is strongly against working on a >>>>> symmetric key group communication protocol. >>>>> >>>>> >>>>> Paul Duffy and Michael Richardson are in favor of defining a public key >>>>> crypto solution but it is not clear whether they are against specifying >>>>> a symmetric key solution as well. >>>>> >>>>> >>>>> Walter, Abhinav, Sandeep, Hannes are in favor of working on a symmetric >>>>> key group communication security protocols (as co-authors of the work). >>>>> Oscar Garcia (Philips) is also in favor of the work. >>>>> >>>>> >>>>> In this mail to the list, >>>>> see https://www.ietf.org/mail-archive/web/ace/current/msg01931.html, >>>>> Robert Cragie (ARM) expressed a view that public key crypto is the >>>>> preferred solution but others based on symmetric crypto are still worthy >>>>> of consideration. >>>>> >>>>> >>>>> Markus Grunwald (Osram) also appears to be in favor of the proposed >>>>> approach, see >>>>> >>>>> https://www.ietf.org/mail-archive/web/ace/current/msg01932.html >>>>> >>>>> >>>>> >>>>> Akbar Rahman also seems to be in favor of working on a group >>>>> communication security protocol, see >>>>> >>>>> https://www.ietf.org/mail-archive/web/ace/current/msg01873.html >>>>> >>>>> >>>>> >>>>> Ned Smith also seems to be in favor of working on a group communication >>>>> security protocol, as expressed in his mail to the list: >>>>> >>>>> https://www.ietf.org/mail-archive/web/ace/current/msg01872.html >>>>> >>>>> >>>>> >>>>> The opinion of the following persons in the discussion appear unclear to me: >>>>> >>>>> - Mohit Sethi >>>>> >>>>> - Ludwig Seitz >>>>> >>>>> - Carsten Bormann >>>>> >>>>> - Stephen Farrell >>>>> >>>>> - Jim Schaad (offered clarifications regarding the use of COSE) >>>>> >>>>> >>>>> >>>>> Pascal Urien and Rene Struik provided performance data but they didn't >>>>> appear to have expressed a strong view about the question regarding >>>>> symmetric vs. asymmetric crypto for group communication security. >>>>> >>>>> Derek Atkins offered performance data for public key crypto but refers >>>>> to new techniques (rather than RSA/ECC). >>>>> >>>>> >>>>> >>>>> Please correct us if we are wrong in our interpretation of your mail >>>>> postings. >>>>> >>>>> >>>>> >>>>> Ciao >>>>> >>>>> Hannes & Kepeng >>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Ace mailing list >>>>> Ace@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/ace >>> _______________________________________________ >>> Ace mailing list >>> Ace@ietf.org >>> https://www.ietf.org/mailman/listinfo/ace >> >> _______________________________________________ >> Ace mailing list >> Ace@ietf.org >> https://www.ietf.org/mailman/listinfo/ace From nobody Mon Sep 26 11:49:06 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 57CAE12B202 for ; Mon, 26 Sep 2016 11:49:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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, 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 0-JUVTPeqrRx for ; Mon, 26 Sep 2016 11:49:02 -0700 (PDT) Received: from mail-qk0-x234.google.com (mail-qk0-x234.google.com [IPv6:2607:f8b0:400d:c09::234]) (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 BB37012B004 for ; Mon, 26 Sep 2016 11:49:01 -0700 (PDT) Received: by mail-qk0-x234.google.com with SMTP id t7so175772757qkh.2 for ; Mon, 26 Sep 2016 11:49:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=M3YFjrgJUcDHNJoHNDfs5aFUWD5UGq7OLQ2RDdYMXFA=; b=Jm75YNhb/82StGOJ7fzH0tH4ZsTEJLmTp96iKACKHaFVu2kOsh3iE9JNVnqfKe5M62 S+zSm2hmOB5iDnm0bPjGpivut4OMoHH5/uGRNGHKb9nzDAA2tpCjz31JakcTamfn7aUG phr7ZoI0xuNm+BIzgjsPnI470FriBDsbHJkBHQMRA2NWlSrGfROTgaU2RvZBgYI2X8jM MZ6sHb1Wx6DKxXc6e9sl1kGGFRYVuRz8gPbqPjd9UqHT9lVmbt883ffstO2kQTaI2igv zvN0dQO3GJHhQO4XFjN76ewFyBOkyxGEcKQz59aKBNVYJ1IH0XgM/WLiTmd0585Y4zai tgeg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=M3YFjrgJUcDHNJoHNDfs5aFUWD5UGq7OLQ2RDdYMXFA=; b=Acg5XAZDDlVhLa5G2LmT7uT713A8Y1BCUu1jrmJ49xx7Fup0l0NEDw+ZFp2sSZq+wX ek3aLEq3O8dZwmpleTdX8hdcQutUTJ/23Of2EHLxOEylr577bqykSi2RzkKajPiumNHG 5TAtvJhtXlhzcO99NmtnjhUAjBraeKnHm8Gej0RjyM8SxK4hZUQ1n1pIc1nu+mA/VAnJ TXQY3skrkrmyWmYsP/O0azqZzxGVZT/vfXdoatZqzxZ1M2ZvXIfJnv6W/Yn9cAdKJ3Vs D5QSrTrZAhdq5xgiR3+uowIb4j+8Qb7jiXW3vkY/wFsYpc4Ad6WlBOk7x5DSHaDt/xV7 Nufw== X-Gm-Message-State: AA6/9RnmlzCL3jkweVSB3yscKCU+oal0k3UBxRh8QJ+ZnvzeVOsY3kAeaC8RNckXnItz2A== X-Received: by 10.55.143.134 with SMTP id r128mr24027346qkd.161.1474915740787; Mon, 26 Sep 2016 11:49:00 -0700 (PDT) Received: from [192.168.1.8] (209-6-124-204.c3-0.arl-ubr1.sbo-arl.ma.cable.rcn.com. [209.6.124.204]) by smtp.gmail.com with ESMTPSA id p124sm12259992qkd.40.2016.09.26.11.48.59 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 26 Sep 2016 11:48:59 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: kathleen.moriarty.ietf@gmail.com X-Mailer: iPhone Mail (13G36) In-Reply-To: <27af5f67-29d4-9f53-312f-31855603d451@comcast.net> Date: Mon, 26 Sep 2016 14:48:58 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <8282E3CE-A603-4CFF-A62F-41350FB826B2@gmail.com> References: <1cc7f243-e7f7-6ec5-7140-88c74853dc34@gmx.net> <04FDEBEF-68CF-4DC6-B760-4DFB1B87D22C@gmail.com> <27af5f67-29d4-9f53-312f-31855603d451@comcast.net> To: Michael StJohns Archived-At: Cc: ace@ietf.org Subject: Re: [Ace] Summary of ACE Group Communication Security Discussion 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: Mon, 26 Sep 2016 18:49:04 -0000 Please excuse typos, sent from handheld device=20 > On Sep 26, 2016, at 1:17 PM, Michael StJohns wrote:= >=20 >> On 9/26/2016 12:31 PM, kathleen.moriarty.ietf@gmail.com wrote: >> This time as AD. >>=20 >> Please excuse typos, sent from handheld device >>=20 >>>> On Sep 26, 2016, at 11:41 AM, Michael StJohns wr= ote: >>>>=20 >>>> On 9/26/2016 8:30 AM, kathleen.moriarty.ietf@gmail.com wrote: >>>> Without a hat on, you can add my support to Abhinav's proposal. Perfec= t is ideal, but you often can not make any progress if you accept nothing le= ss. The security considerations section will have to be thorough. >>> Hi Kathleen et al - >>>=20 >>> To attain "rough consensus", RFC 7282 requires that "all issues be addre= ssed" even if not all issues are accommodated. So far the basic issues of "= this is unsafe as a mechanism for 'securing' a control protocol" or even "ho= w the heck do we keep this off the broader internet" have not been addressed= . >> This can be addressed in a draft security considerations. The scope can b= e made applicable to what's needed to constrain its use. >=20 > With respect - no. The issue is with respect to the discussion of whether= or not to adopt this as a WG item. To "address" the issue, there has to be= an offer of proof that someone actually knows how to address it - BEFORE t= he item is adopted. I may have missed that offer of proof, but I don't thi= nk so. >=20 > You're suggesting that the way of addressing this is to ignore the issues,= adopt it the work item, and at some far distant future point make sure ther= e is a security considerations section that says something that might or mig= ht not be meaningful. "I will gladly pay you Tuesday for a hamburger today= " - J Wellington Wimpy. >=20 > An interesting approach, but probably not in keeping with correct process.= No Mike, that's not what I said. Please let the chairs do their job and let= 's see what they come back with. Your points may be addressed in their resp= onse. If adopted, it is fully recognized that there are security issues and that w= ill need to be addressed. The chairs are working on this adoption call and y= our points are in consideration. There is a real problem to be solved and i= f it's not perfect, and has some security holes, that will be stated clearly= . It is okay to have an imperfect solution. Kathleen=20 >=20 >>=20 >> The chairs haven't put out a decision and your concerns have been heard. = They are working to assess consensus. >=20 > The counter point to my concerns being heard is them being "addressed" as p= art of assessing consensus. It says so right there in RFC 7282. >=20 > Later, Mike >=20 >>=20 >> Best regards, >> Kathleen >>=20 >>> I once again suggest that the lighting folk go off and write something t= hat they implement as a group, and bring it back to the IETF as an informati= onal "here's how we did it" document, rather than adopting this as a WG item= . The ONLY thing that even argues for considering symmetric key multicast (= vice asymmetric key multicast) is the latency claims for lighting. I haven'= t yet heard of another use case with the particular combination of cheapness= and latency of lighting which would suggest this particular combination is u= seful elsewhere. >>>=20 >>> With respect to Abhinav's proposal, we've already got several group key m= anager systems - we don't actually use any of them for control systems, and y= ou might want to inquire as to the reason. [RFC2093,2094] [RFC4046] [RFC4535= ] >>>=20 >>> With respect to Eliot's comment, it doesn't really matter if the key man= agement protocol is asymmetric if the multicast session keys are symmetric a= nd used for control. The analysis of this can pretty much ignore the key ma= nagement piece and start with 100 controllers and 1000 actuators with pre-sh= ared keys to consider the threat and mitigation models. Which analysis - AFA= ICT - no one has actually done. Basically, if you can't secure this 100/100= 0 system and keep it secure with respect to control functions, I would argu= e that the rest of it (e.g. key management) is meaningless window dressing. >>>=20 >>> Later, Mike >>>=20 >>> ps - do you *really* want to reinvent SCADA and all its security issues?= >>>=20 >>>> Kathleen >>>>=20 >>>> Please excuse typos, sent from handheld device >>>>=20 >>>>> On Sep 26, 2016, at 7:11 AM, Hannes Tschofenig wrote: >>>>>=20 >>>>> I noticed that Eliot also expressed support for the approach presented= by Abhinav, see https://mailarchive.ietf.org/arch/msg/ace/ctCtj9QT0WwBDki7v= xgVeYVzFaI >>>>>=20 >>>>> Ciao >>>>> Hannes >>>>>=20 >>>>>> On 09/26/2016 07:11 PM, Kepeng Li wrote: >>>>>> Hi all, >>>>>>=20 >>>>>>=20 >>>>>> We went through all email exchanges again in order to see where we ar= e. >>>>>> Abhinav also proposed a way forward in his email to the list, >>>>>> see https://www.ietf.org/mail-archive/web/ace/current/msg01961.html, >>>>>> where he proposed to standardize a solution based on public key as we= ll >>>>>> as symmetric key cryptography. >>>>>>=20 >>>>>>=20 >>>>>> Here is our impression of the views presented by various people. >>>>>>=20 >>>>>>=20 >>>>>> Mike seems to think the only acceptable solution is to use messages >>>>>> signed using public key crypto and is strongly against working on a >>>>>> symmetric key group communication protocol. >>>>>>=20 >>>>>>=20 >>>>>> Paul Duffy and Michael Richardson are in favor of defining a public k= ey >>>>>> crypto solution but it is not clear whether they are against specifyi= ng >>>>>> a symmetric key solution as well. >>>>>>=20 >>>>>>=20 >>>>>> Walter, Abhinav, Sandeep, Hannes are in favor of working on a symmetr= ic >>>>>> key group communication security protocols (as co-authors of the work= ). >>>>>> Oscar Garcia (Philips) is also in favor of the work. >>>>>>=20 >>>>>>=20 >>>>>> In this mail to the list, >>>>>> see https://www.ietf.org/mail-archive/web/ace/current/msg01931.html, >>>>>> Robert Cragie (ARM) expressed a view that public key crypto is the >>>>>> preferred solution but others based on symmetric crypto are still wor= thy >>>>>> of consideration. >>>>>>=20 >>>>>>=20 >>>>>> Markus Grunwald (Osram) also appears to be in favor of the proposed >>>>>> approach, see >>>>>>=20 >>>>>> https://www.ietf.org/mail-archive/web/ace/current/msg01932.html >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> Akbar Rahman also seems to be in favor of working on a group >>>>>> communication security protocol, see >>>>>>=20 >>>>>> https://www.ietf.org/mail-archive/web/ace/current/msg01873.html >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> Ned Smith also seems to be in favor of working on a group communicati= on >>>>>> security protocol, as expressed in his mail to the list: >>>>>>=20 >>>>>> https://www.ietf.org/mail-archive/web/ace/current/msg01872.html >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> The opinion of the following persons in the discussion appear unclear= to me: >>>>>>=20 >>>>>> - Mohit Sethi >>>>>>=20 >>>>>> - Ludwig Seitz >>>>>>=20 >>>>>> - Carsten Bormann >>>>>>=20 >>>>>> - Stephen Farrell >>>>>>=20 >>>>>> - Jim Schaad (offered clarifications regarding the use of COSE) >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> Pascal Urien and Rene Struik provided performance data but they didn'= t >>>>>> appear to have expressed a strong view about the question regarding >>>>>> symmetric vs. asymmetric crypto for group communication security. >>>>>>=20 >>>>>> Derek Atkins offered performance data for public key crypto but refer= s >>>>>> to new techniques (rather than RSA/ECC). >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> Please correct us if we are wrong in our interpretation of your mail >>>>>> postings. >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> Ciao >>>>>>=20 >>>>>> Hannes & Kepeng >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> _______________________________________________ >>>>>> Ace mailing list >>>>>> Ace@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/ace >>>> _______________________________________________ >>>> Ace mailing list >>>> Ace@ietf.org >>>> https://www.ietf.org/mailman/listinfo/ace >>>=20 >>> _______________________________________________ >>> Ace mailing list >>> Ace@ietf.org >>> https://www.ietf.org/mailman/listinfo/ace >=20 >=20 From nobody Wed Sep 28 03:42: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 DEDBC12B609 for ; Wed, 28 Sep 2016 03:42:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.536 X-Spam-Level: X-Spam-Status: No, score=-6.536 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-2.316, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 q61rEK5ws6o6 for ; Wed, 28 Sep 2016 03:42:44 -0700 (PDT) Received: from smtppost.atos.net (smtppost.atos.net [193.56.114.165]) (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 B725012B60C for ; Wed, 28 Sep 2016 03:42:42 -0700 (PDT) Received: from mail1-ext.my-it-solutions.net (mail1-ext.my-it-solutions.net) by smarthost6.atos.net with smtp (TLS: TLSv1/SSLv3,256bits,ECDHE-RSA-AES256-GCM-SHA384) id 5587_1a0e_471cf51d_3365_4a0d_b362_e9f3b177f756; Wed, 28 Sep 2016 12:42:36 +0200 Received: from mail2-int.my-it-solutions.net ([10.92.32.13]) by mail1-ext.my-it-solutions.net (8.15.2/8.15.2) with ESMTPS id u8SAgXvN021706 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 28 Sep 2016 12:42:33 +0200 Received: from DEERLM99ETTMSX.ww931.my-it-solutions.net ([10.86.142.105]) by mail2-int.my-it-solutions.net (8.15.2/8.15.2) with ESMTPS id u8SAgXbR025028 (version=TLSv1 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 28 Sep 2016 12:42:33 +0200 Received: from DEERLM99EX1MSX.ww931.my-it-solutions.net ([169.254.1.113]) by DEERLM99ETTMSX.ww931.my-it-solutions.net ([10.86.142.105]) with mapi id 14.03.0294.000; Wed, 28 Sep 2016 12:42:33 +0200 From: "Calvo Alonso, Daniel" To: Hannes Tschofenig , "ace@ietf.org" Thread-Topic: [Ace] Correct url for draft-cuellar-ace-pat-priv-enhanced-authz-tokens source code Thread-Index: AdIDXo/JIWofyYeVRFyCDhU6AnzNSQUYAG8AAGyJrgA= Date: Wed, 28 Sep 2016 10:42:32 +0000 Message-ID: <8A926B4ADC92E345A40FA5363D47FA300336A807@DEERLM99EX1MSX.ww931.my-it-solutions.net> References: <8A926B4ADC92E345A40FA5363D47FA3003358C69@DEERLM99EX1MSX.ww931.my-it-solutions.net> <15048fce-3378-94e3-40d6-c75fc511a2cb@gmx.net> In-Reply-To: <15048fce-3378-94e3-40d6-c75fc511a2cb@gmx.net> Accept-Language: es-ES, en-US Content-Language: es-ES X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.142.12] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "Kasinathan, Prabhakaran" , "Cuellar, Jorge" , "Gato, Jose" Subject: Re: [Ace] Correct url for draft-cuellar-ace-pat-priv-enhanced-authz-tokens source code 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, 28 Sep 2016 10:42:48 -0000 Hi Hannes, Sorry for the delayed answer but I have been travelling for a couple of day= s. This code is a first JAVA prototype that implements the actors, messages an= d flows that are defined in draft-cuellar-ace-pat-priv-enhanced-authz-toke= ns-03. I will try to give you an overview: - You can find several examples that demonstrate the features of the draft/= prototype in src/test/java/com/atos/ari/rerum/ace. For instance in Complete= TestSuccess.java: - We have a ResourceServer (lines 74-86) that hosts a resource whic= h will be used for the tests (this functionality would be implemented in a = constrained device) - We have an AuthorizationServer (lines 89-106) that will perform t= he authorization process on behalf of the ResourceServer and which uses a s= et of policies defined a JSON file. This is out of the scope of the draft, = but we have followed this approach to achieve a complete test. - A client wants to get access to the resource but as it does not h= ave an valid access token, the resource server will return an Unauthorized = response with the information about the AuthorizationServer that must be co= ntacted (lines 127-135). - The client uses this information to ask the AuthorizationServer a= n AccessToken that covers its request over the ResourceServer. In this case= , a GET operation. (lines 138- 141) - The client uses part of the ClientToken to perform an authorized = resource request to the resource server (lines 143 - 152) - The client uses part of the ClientToken to unencrypt the answer r= eceived from the ResourceServer (lines 155 -167 ) - In the rest of the code, a similar process if followed to perform= a POST operation. - The implementation of the actors can be found under src/main/java/com/ato= s/ari/rerum/ace folder: AuthorizationServer, Client, ResourceAce and Resour= ceServer. All these classes are used in the examples like the one I mention= ed before. - In src/main/java/com/atos/ari/rerum/ace/messages, you can find the classe= s that implement the different messages that are exchanged as part of the p= rotocol flow, e.g., the sam information message (SamInformationMessage), th= e access token request message (AccessRequestMessage), the client token (Ti= cketTransferMessage, TicketTransferMessageFace) and the access token (Acces= sToken). The access token is embedded in the payload as described in the dr= aft. We use AcePayload class for this part. As you can see, the contents of= the payload are encrypted to protect data confidentiality. In src/main/java/com/atos/ari/rerum/ace/crypto, you can find the classes th= at implement the different algorithms that are initially proposed in the dr= aft. For instance: - AEAD_CHACHA20_POLY130 for authenticat4ed encryption of payloads. - Poly1305 to generate the verifier (part of the ClientToken that = is sent from the AuthorizationServer to the Client and used to encrypt payl= oad) The next step would be to implement the Client actor and its functionality = in a real constrained device. As I explained you in Berlin, this is in our = roadmap but we are going also to follow your comments and try to align firs= t this draft with draft-ietf-ace-oauth-authz-02. @Jorge, @Prabha, please correct me if anything is not totally correct and f= eel free to add what you consider of interest. I hope that this explanation is useful to understand better the code but if= you have more doubts, please don't hesitate in ask me again! BR, Daniel Daniel Calvo Energy and Transport Market Atos Research and Innovation Tel: +34 946 66 20 82 daniel.calvo@atos.net C/Real Consulado s/n, Pol=EDgono Industrial Candina 39011 Santander www.atosresearch.eu Feel free to download our booklet at https://atos.net/en/insights-and-innovation/innovation-labs This e-mail and the documents attached are confidential and intended solely= for the addressee; it may also be privileged. If you receive this e-mail i= n error, please notify the sender immediately and destroy it. As its integrity cannot be secured on the Internet, the Atos group liabilit= y cannot be triggered for the message content. Although the sender endeavor= s to maintain a computer virus-free network, the sender does not warrant th= at this transmission is virus-free and will not be liable for any damages r= esulting from any virus transmitted. Este mensaje y los ficheros adjuntos pueden contener informaci=F3n confiden= cial destinada solamente a la(s) persona(s) mencionadas anteriormente y pue= den estar protegidos por secreto profesional. Si usted recibe este correo electr=F3nico por error, gracias por informar i= nmediatamente al remitente y destruir el mensaje. Al no estar asegurada la integridad de este mensaje sobre la red, Atos no s= e hace responsable por su contenido. Su contenido no constituye ning=FAn co= mpromiso para el grupo Atos, salvo ratificaci=F3n escrita por ambas partes. Aunque se esfuerza al m=E1ximo por mantener su red libre de virus, el emiso= r no puede garantizar nada al respecto y no ser=E1 responsable de cualesqui= era da=F1os que puedan resultar de una transmisi=F3n de virus. This e-mail and the documents attached are confidential and intended solely= for the addressee; it may also be privileged. If you receive this e-mail i= n error, please notify the sender immediately and destroy it. As its integrity cannot be secured on the Internet, the Atos group liabilit= y cannot be triggered for the message content. Although the sender endeavor= s to maintain a computer virus-free network, the sender does not warrant th= at this transmission is virus-free and will not be liable for any damages r= esulting from any virus transmitted. Este mensaje y los ficheros adjuntos pueden contener informaci=F3n confiden= cial destinada solamente a la(s) persona(s) mencionadas anteriormente y pue= den estar protegidos por secreto profesional. Si usted recibe este correo electr=F3nico por error, gracias por informar i= nmediatamente al remitente y destruir el mensaje. Al no estar asegurada la integridad de este mensaje sobre la red, Atos no s= e hace responsable por su contenido. Su contenido no constituye ning=FAn co= mpromiso para el grupo Atos, salvo ratificaci=F3n escrita por ambas partes. Aunque se esfuerza al m=E1ximo por mantener su red libre de virus, el emiso= r no puede garantizar nada al respecto y no ser=E1 responsable de cualesqui= era da=F1os que puedan resultar de una transmisi=F3n de virus. -----Original Message----- From: Hannes Tschofenig [mailto:hannes.tschofenig@gmx.net] Sent: Monday, September 26, 2016 10:24 AM To: Calvo Alonso, Daniel; ace@ietf.org Cc: Kasinathan, Prabhakaran; Cuellar, Jorge; Gato, Jose Subject: Re: [Ace] Correct url for draft-cuellar-ace-pat-priv-enhanced-auth= z-tokens source code Hi Daniel, could you provide a bit of info what you have implemented? (I know that I can look at the code myself but you probably know all the de= tails from the top of your head.) Ciao Hannes On 08/31/2016 10:11 AM, Calvo Alonso, Daniel wrote: > Dear all, > > As I promised during my presentation in the ACE WG meeting in Berlin, > this is the correct link to > draft-cuellar-ace-pat-priv-enhanced-authz-tokens prototype source code: > > _https://gitlab.atosresearch.eu/ari/ACE-PAT-pub_ > > Please, don't hesitate in contact me in case you have any doubt or proble= m. > > With my best regards, > > *Daniel Calvo* > Energy and Transport Market > Atos Research and Innovation > Tel: +34 946 66 20 82 > _daniel.calvo@atos.net_ C/Real > Consulado s/n, Pol=EDgono Industrial Candina > 39011 Santander > _www.atosresearch.eu_ > > > *Feel free to download our booklet at* > _http://atos.net/en-us/home/we-are/insights-innovation/research-and-in > novation.html_ > > > This e-mail and the documents attached are confidential and intended > solely for the addressee; it may also be privileged. If you receive > this e-mail in error, please notify the sender immediately and destroy it= . > As its integrity cannot be secured on the Internet, the Atos group > liability cannot be triggered for the message content. Although the > sender endeavors to maintain a computer virus-free network, the sender > does not warrant that this transmission is virus-free and will not be > liable for any damages resulting from any virus transmitted. > > Este mensaje y los ficheros adjuntos pueden contener informaci=F3n > confidencial destinada solamente a la(s) persona(s) mencionadas > anteriormente y pueden estar protegidos por secreto profesional. > Si usted recibe este correo electr=F3nico por error, gracias por > informar inmediatamente al remitente y destruir el mensaje. > Al no estar asegurada la integridad de este mensaje sobre la red, Atos > no se hace responsable por su contenido. Su contenido no constituye > ning=FAn compromiso para el grupo Atos, salvo ratificaci=F3n escrita por > ambas partes. > Aunque se esfuerza al m=E1ximo por mantener su red libre de virus, el > emisor no puede garantizar nada al respecto y no ser=E1 responsable de > cualesquiera da=F1os que puedan resultar de una transmisi=F3n de virus. > This e-mail and the documents attached are confidential and intended > solely for the addressee; it may also be privileged. If you receive > this e-mail in error, please notify the sender immediately and destroy it= . > As its integrity cannot be secured on the Internet, the Atos group > liability cannot be triggered for the message content. Although the > sender endeavors to maintain a computer virus-free network, the sender > does not warrant that this transmission is virus-free and will not be > liable for any damages resulting from any virus transmitted. > > Este mensaje y los ficheros adjuntos pueden contener informaci=F3n > confidencial destinada solamente a la(s) persona(s) mencionadas > anteriormente y pueden estar protegidos por secreto profesional. > Si usted recibe este correo electr=F3nico por error, gracias por > informar inmediatamente al remitente y destruir el mensaje. > Al no estar asegurada la integridad de este mensaje sobre la red, Atos > no se hace responsable por su contenido. Su contenido no constituye > ning=FAn compromiso para el grupo Atos, salvo ratificaci=F3n escrita por > ambas partes. > Aunque se esfuerza al m=E1ximo por mantener su red libre de virus, el > emisor no puede garantizar nada al respecto y no ser=E1 responsable de > cualesquiera da=F1os que puedan resultar de una transmisi=F3n de virus. > > > > This e-mail and the documents attached are confidential and intended > solely for the addressee; it may also be privileged. If you receive > this e-mail in error, please notify the sender immediately and destroy it= . > As its integrity cannot be secured on the Internet, the Atos group > liability cannot be triggered for the message content. Although the > sender endeavors to maintain a computer virus-free network, the sender > does not warrant that this transmission is virus-free and will not be > liable for any damages resulting from any virus transmitted. > > Este mensaje y los ficheros adjuntos pueden contener informaci=F3n > confidencial destinada solamente a la(s) persona(s) mencionadas > anteriormente y pueden estar protegidos por secreto profesional. > Si usted recibe este correo electr=F3nico por error, gracias por > informar inmediatamente al remitente y destruir el mensaje. > Al no estar asegurada la integridad de este mensaje sobre la red, Atos > no se hace responsable por su contenido. Su contenido no constituye > ning=FAn compromiso para el grupo Atos, salvo ratificaci=F3n escrita por > ambas partes. > Aunque se esfuerza al m=E1ximo por mantener su red libre de virus, el > emisor no puede garantizar nada al respecto y no ser=E1 responsable de > cualesquiera da=F1os que puedan resultar de una transmisi=F3n de virus. > > > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace > This e-mail and the documents attached are confidential and intended solely= for the addressee; it may also be privileged. If you receive this e-mail i= n error, please notify the sender immediately and destroy it. As its integrity cannot be secured on the Internet, the Atos group liabilit= y cannot be triggered for the message content. Although the sender endeavor= s to maintain a computer virus-free network, the sender does not warrant th= at this transmission is virus-free and will not be liable for any damages r= esulting from any virus transmitted. Este mensaje y los ficheros adjuntos pueden contener informaci=F3n confiden= cial destinada solamente a la(s) persona(s) mencionadas anteriormente y pue= den estar protegidos por secreto profesional. Si usted recibe este correo electr=F3nico por error, gracias por informar i= nmediatamente al remitente y destruir el mensaje. Al no estar asegurada la integridad de este mensaje sobre la red, Atos no s= e hace responsable por su contenido. Su contenido no constituye ning=FAn co= mpromiso para el grupo Atos, salvo ratificaci=F3n escrita por ambas partes. Aunque se esfuerza al m=E1ximo por mantener su red libre de virus, el emiso= r no puede garantizar nada al respecto y no ser=E1 responsable de cualesqui= era da=F1os que puedan resultar de una transmisi=F3n de virus. From nobody Thu Sep 29 08:18:35 2016 Return-Path: X-Original-To: ace@ietf.org Delivered-To: ace@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A9A6612B0F4; Thu, 29 Sep 2016 08:18:33 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Meeting Session Request Tool\"" To: X-Test-IDTracker: no X-IETF-IDTracker: 6.34.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147516231365.18489.7103940531476724386.idtracker@ietfa.amsl.com> Date: Thu, 29 Sep 2016 08:18:33 -0700 Archived-At: Cc: Kathleen.Moriarty.ietf@gmail.com, ace-chairs@ietf.org, ace@ietf.org, kepeng.lkp@alibaba-inc.com Subject: [Ace] ace - New Meeting Session Request for IETF 97 X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.17 List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Sep 2016 15:18:34 -0000 A new meeting session request has just been submitted by Kepeng Li, a Chair of the ace working group. --------------------------------------------------------- Working Group Name: Authentication and Authorization for Constrained Environments Area Name: Security Area Session Requester: Kepeng Li Number of Sessions: 1 Length of Session(s): 2.5 Hours Number of Attendees: 100 Conflicts to Avoid: First Priority: core cose oauth saag lwig tokbind tls Special Requests: Avoid entire SEC areas. Please avoid a session on Friday! ---------------------------------------------------------