From nobody Thu Oct 1 00:42:26 2015 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C6E91B2B81 for ; Thu, 1 Oct 2015 00:42:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lgfOFav_GqNY for ; Thu, 1 Oct 2015 00:42:23 -0700 (PDT) Received: from mail-lb0-f176.google.com (mail-lb0-f176.google.com [209.85.217.176]) (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 21BDA1B2B7F for ; Thu, 1 Oct 2015 00:42:22 -0700 (PDT) Received: by lbos8 with SMTP id s8so4204715lbo.0 for ; Thu, 01 Oct 2015 00:42:21 -0700 (PDT) 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:content-type; bh=954hkgAK4Biv3zSk1HlXuNJBzNBuAWiJyHZzEYeaA44=; b=kHyZel9eF1ek2vJvKnQBHikQIhHL2LxdRZrzg0NPjvtWiqoJMeNN2fYT455mR5WNnG LZU4Ye7pdQRiLhpf9mamL0qdh1NKPgI9qRz5JMOc90RZtWGyUhRA3S6TGb+S00r7loTB r3AXqrghjkeMTuDVyldFEMUaRPAhjQeNzcqZevk5yjGK4TxBa4IL4GsBRvGzJp2q/93X J974qsGdQYqCeGgu2FcqNRWMcswQrr4W6FIITVzXgG25kbmVKvIl2M120bvGJlaQe/fS 15WJw0AbtHAKv1T70cAHmRuDERXibpO8yfVeQHqk4+HFELgU/mlammTwsksL7NvB7wCL RDuA== X-Gm-Message-State: ALoCoQnaUp5ffw3t9oT8K7sPm3rwXXsUTT32a/F5abl8JwpcMIP4kRxJ1WJMvX2ongbZ+PxFwCcZ X-Received: by 10.152.45.41 with SMTP id j9mr2321751lam.4.1443685341244; Thu, 01 Oct 2015 00:42:21 -0700 (PDT) Received: from [192.168.0.108] ([85.235.11.178]) by smtp.gmail.com with ESMTPSA id j189sm510964lfg.48.2015.10.01.00.42.20 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 01 Oct 2015 00:42:20 -0700 (PDT) To: Prashant_Jhingran@Dell.com, ace@ietf.org References: <20150923110948.975.82548.idtracker@ietfa.amsl.com> <56028910.7030104@sics.se> From: Ludwig Seitz Message-ID: <560CE3DB.4050900@sics.se> Date: Thu, 1 Oct 2015 09:42:19 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms010006020202000104070900" Archived-At: Subject: Re: [Ace] Fwd: New Version Notification for draft-ietf-ace-usecases-06.txt X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 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, 01 Oct 2015 07:42:25 -0000 This is a cryptographically signed message in MIME format. --------------ms010006020202000104070900 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable On 2015-09-27 19:50, Prashant_Jhingran@Dell.com wrote: > *Dell - Internal Use - Confidential * ^^^^^^^^^^^^^^ You've got a leak ;-) > Hi Ludwig, > > Could not capture the below mentioned point earlier, besides this the > document looks very comprehensive to me. > > */Section 3.1 talks about the DoS attacks. /* > > An attacker can potentially cause a DoS attack by various means, the > easiest attack can be caused by forcing the device to send continuous o= r > abnormally higher number of monitoring, troubleshooting or heartbeat > messages to the GW or somewhere, thus forcing more number of > transactions than expected, this may eventually lead to faster > exhaustion of device resources like battery etc. > > Hence we should also add =93Number of message exchanges required during= > monitoring or troubleshooting=94 besides the existing limitations, > like=93Number of message exchanges required by security measures=94. > Hello Prashant, thank you for your comment. I think this section needs clarification.=20 The list of items was intended to specifically refer to the security=20 mechanisms and protocols that will be designed in ACE. Therefore your=20 suggested item "Number of message exchanges required during monitoring=20 or troubleshooting" would be included in the "Number of message=20 exchanges required by security measures" for that specific case. I will try to rephrase that part to make it clearer. Regards, 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 http://www.sics.se --------------ms010006020202000104070900 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 DFQwggYYMIIFAKADAgECAgMMhpgwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYw FAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZp Y2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJt ZWRpYXRlIENsaWVudCBDQTAeFw0xNTAxMDgwODM5MDZaFw0xNjAxMDkyMjQxMzBaMDgxFzAV BgNVBAMMDmx1ZHdpZ0BzaWNzLnNlMR0wGwYJKoZIhvcNAQkBFg5sdWR3aWdAc2ljcy5zZTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMVB4rAuq4FxbARxwRqPLpc/3C194F+V H4XMKK6fu3Y8zDLijzNSjh6tG41oZhXvJcvAs1nZNjUutNLeyBAUFiYhy7HXNdlKpjbMEFKQ +6KpEdZ0Rk+pXgB2E1mqZEfp3M2djcQ/h+7uGVlSGYNAxYk6rWPIIWBx2GMvAQaHP4xxu/F+ PiSQILOVzmtIFZe1t/Lw71aaNeMYVhARo8z5PVsVoq6gBeujxfiRLtiQ/S8xW6RKvNvUkVyT BQfcKaEDZR9FENNf9rFgiAcT6R7hI8RBf1d2fxdlbDU8uM72K3fvzGDt8N9Bfm1kDWbDBxJE 1taRIYs+60D1kwV6DvBb9MECAwEAAaOCAtQwggLQMAkGA1UdEwQCMAAwCwYDVR0PBAQDAgSw MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAdBgNVHQ4EFgQU6ryrKahJtBOEdbIL AAWCpOsQyagwHwYDVR0jBBgwFoAUU3Ltkpzg2ssBXHx+ljVO8tS4UYIwGQYDVR0RBBIwEIEO bHVkd2lnQHNpY3Muc2UwggFMBgNVHSAEggFDMIIBPzCCATsGCysGAQQBgbU3AQIDMIIBKjAu BggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjCB9wYIKwYB BQUHAgIwgeowJxYgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwAwIBARqBvlRo aXMgY2VydGlmaWNhdGUgd2FzIGlzc3VlZCBhY2NvcmRpbmcgdG8gdGhlIENsYXNzIDEgVmFs aWRhdGlvbiByZXF1aXJlbWVudHMgb2YgdGhlIFN0YXJ0Q29tIENBIHBvbGljeSwgcmVsaWFu Y2Ugb25seSBmb3IgdGhlIGludGVuZGVkIHB1cnBvc2UgaW4gY29tcGxpYW5jZSBvZiB0aGUg cmVseWluZyBwYXJ0eSBvYmxpZ2F0aW9ucy4wNgYDVR0fBC8wLTAroCmgJ4YlaHR0cDovL2Ny bC5zdGFydHNzbC5jb20vY3J0dTEtY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEF BQcwAYYtaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczEvY2xpZW50L2NhMEIG CCsGAQUFBzAChjZodHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MxLmNs aWVudC5jYS5jcnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqG SIb3DQEBBQUAA4IBAQBl8BbG0n7+JjFqiJOuAqMbkeqM6Oyd+4oHGu3fbaSiM1SKesae2bfm vifV99a+M4DERZ2SVkOYcvNlv31Q3hvYtzRjDOqewzVKxo021R3ddQULW1DhvTEpclikG5rd 0NRJQn+EkSwEKLeUj68i0dhU8ULhZDDq3A81cTcZzIGrTjNnwDvCktB/sF/iO4At6RJ24P3j KjYFPirW3NsvZ2gzZizSzeubPE0/cWcqEBJ/UtaFPF54efejjLuPRHHMLPDcvrwBhEiBxuG6 oTEo465g4pS9Vo/Z0GoZgZyA+aGQ+YPbPSsqsYmSBjZ6MGGDqQq0niE2dW+8IOdHQvMkqI52 MIIGNDCCBBygAwIBAgIBHjANBgkqhkiG9w0BAQUFADB9MQswCQYDVQQGEwJJTDEWMBQGA1UE ChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUg U2lnbmluZzEpMCcGA1UEAxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwHhcN MDcxMDI0MjEwMTU1WhcNMTcxMDI0MjEwMTU1WjCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoT DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUg Q2xpZW50IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAxwmDzM4t2BqxKaQu E6uWvooyg4ymiEGWVUet1G8SD+rqvyNH4QrvnEIaFHxOhESip7vMz39ScLpNLbL1QpOlPW/t FIzNHS3qd2XRNYG5Sv9RcGE+T4qbLtsjjJbi6sL7Ls/f/X9ftTyhxvxWkf8KW37iKrueKsxw 2HqolH7GM6FX5UfNAwAu4ZifkpmZzU1slBhyWwaQPEPPZRsWoTb7q8hmgv6Nv3Hg9rmA1/VP BIOQ6SKRkHXG0Hhmq1dOFoAFI411+a/9nWm5rcVjGcIWZ2v/43Yksq60jExipA4l5uv9/+Hm 33mbgmCszdj/Dthf13tgAv2O83hLJ0exTqfrlwIDAQABo4IBrTCCAakwDwYDVR0TAQH/BAUw AwEB/zAOBgNVHQ8BAf8EBAMCAQYwHQYDVR0OBBYEFFNy7ZKc4NrLAVx8fpY1TvLUuFGCMB8G A1UdIwQYMBaAFE4L7xqkQFulF2mHMMo0aEPQQa7yMGYGCCsGAQUFBwEBBFowWDAnBggrBgEF BQcwAYYbaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL2NhMC0GCCsGAQUFBzAChiFodHRwOi8v d3d3LnN0YXJ0c3NsLmNvbS9zZnNjYS5jcnQwWwYDVR0fBFQwUjAnoCWgI4YhaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vc2ZzY2EuY3JsMCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNv bS9zZnNjYS5jcmwwgYAGA1UdIAR5MHcwdQYLKwYBBAGBtTcBAgEwZjAuBggrBgEFBQcCARYi aHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEFBQcCARYoaHR0cDov L3d3dy5zdGFydHNzbC5jb20vaW50ZXJtZWRpYXRlLnBkZjANBgkqhkiG9w0BAQUFAAOCAgEA CoMIfXirLAZcuGOMXq4cuSN3TaFx2H2GvD5VSy/6rV55BYHbWNaPeQn3oBSU8KgQZn/Kck1J xbLpAxVCNtsxeW1R87ifhsYZ0qjdrA9anrW2MAWCtosmAOT4OxK9QPoSjCMxM3HbkZCDJgnl E8jMopH21BbyAYr7b5EfGRQJNtgWcvqSXwKHnTutR08+Kkn0KAkXCzeQNLeA5LlYUzFyM7kP Ap8pIRMQ+seHunmyG642S2+y/qHEdMuGIwpfz3eDF1PdctL04qYK/zu+Qg1Bw0RwgigVZs/0 c5HP2/e9DBHh7eSwtzYlk4AUr6yxLlcwSjOfOmKEQ/Q8tzh0IFiNu9IPuTGAPBn4CPxD0+Ru 8T2wg8/s43R/PT3kd1OEqOJUl7q+h+r6fpvU0Fzxd2tC8Ga6fDEPme+1Nbi+03pVjuZQKbGw KJ66gEn06WqaxVZC+J8hh/jR0k9mST1iAZPNYulcNJ8tKmVtjYsv0L1TSm2+NwON58tO+pIV zu3DWwSEXSf+qkDavQam+QtEOZxLBXI++aMUEapSn+k3Lxm48ZCYfAWLb/Xj7F5JQMbZvCex glAbYR0kIHqW5DnsYSdMD/IplJMojx0NBrxJ3fN9dvX2Y6BIXRsF1du4qESm4/3CKuyUV7p9 DW3mPlHTGLvYxnyKQy7VFBkoLINszBrOUeIxggPtMIID6QIBATCBlDCBjDELMAkGA1UEBhMC SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENl cnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJ bnRlcm1lZGlhdGUgQ2xpZW50IENBAgMMhpgwDQYJYIZIAWUDBAIBBQCgggIpMBgGCSqGSIb3 DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE1MTAwMTA3NDIxOVowLwYJKoZI hvcNAQkEMSIEIMmPrdSNFT6iS4v+IOWzBGlY5LU1RH8rWa6nMeTTyY8KMGwGCSqGSIb3DQEJ DzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0D AgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgaUGCSsGAQQB gjcQBDGBlzCBlDCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzAp BgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0 YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgMMhpgwgacG CyqGSIb3DQEJEAILMYGXoIGUMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20g THRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG A1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EC AwyGmDANBgkqhkiG9w0BAQEFAASCAQA0vbDBPE95uZPxR0UE9xTUZdheiGxBGo55xpEqx3fU 4WHBAd7WhM7MZpTxYzHUlCwWXJnsZ3WdtqaLH1wMECj/JM+Ntct4xzY3drd5xc6sbQVmDM3U ZWAaYmLWJ/l2hKkSkLQNRiaoykbVbo3iEvKKubtjvDEknmzG/4N9BpXnj5xHGNAD/5CXYZMA JmWciLbv+VkGLjChAsX4K/pSxJT8O3nYL4tn+Ebo5yfxplVIOCNcg73UuecL6n8iJbIYMSHt eSIji8yvAA2HxG13llzJVDl4JdUgjHGB7OU9vE9gKq7RukY1/IJcSzVRhPW51wY97vNSEQuX i1BN9QA9P45PAAAAAAAA --------------ms010006020202000104070900-- From nobody Thu Oct 1 01:02:24 2015 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97E1C1B2B8E for ; Thu, 1 Oct 2015 01:02:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3KuWkaHcEgO4 for ; Thu, 1 Oct 2015 01:02:17 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (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 829A81B2B96 for ; Thu, 1 Oct 2015 01:02:17 -0700 (PDT) Received: from [192.168.131.140] ([80.92.119.87]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0MS5QA-1a6CS51ka2-00TGTw for ; Thu, 01 Oct 2015 10:02:15 +0200 To: "Ace@ietf.org" From: Hannes Tschofenig Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9 Message-ID: <560CE84F.1070900@gmx.net> Date: Thu, 1 Oct 2015 10:01:19 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="j6t8o0BwWAXaTOs2HSDFrXf7riVBPhfb3" X-Provags-ID: V03:K0:CHg2f0lrndyg4JMH4s77M3/Uq5n3RJma3FrUkUWEmPMxl9PxQ3L DV4T7oEpcjOk+akAgqz4RdxkHmnC/vUPTdwtkHRHYNV2f4MfoXjEY46J1SazRynyoFiaShk B0ncdUZG5XH9D2EBa8Ga02TRO23PnAFqNCIahZ9VzquJOGrodwGBqjPaHueG6PlRhu5533J pdokyxn8N6hwaZ/HKNGqA== X-UI-Out-Filterresults: notjunk:1;V01:K0:GpcK5FDbN3k=:b+H6MQFH75LaGZNDzFVI44 HzNVGvtfIPWMCR6SzRiAnXU6CTRezlA1NhhfjTDooK6PhMh9htZXoMzF8DUQYCMHJbBxpEp11 9iLMrzQj9ZVdb41fGKNQIYamdehPxJC17jPNQ/LwLxoRVz9nyiOqKHz+5JGHxidOpsiB22IIx hNF+eHLhRKRSjdsPFFLbvcau9+g9r4nzXQP46TErQDyWlaIarRKuO2Jt5BWtpkborBFjw2Afz GUp289scxr0+VwoMt4HQl8aYq1ScIRsoZCE4WVdWGZvjtxJXtGBKVN6HzybBr7N98R0i45lsj 9ocDy1ojJXsRH/3jtxj90sP+9M4Kw32W+NEjHGT9gukgT5fkzqKKjj7vwTdjUJGCF+Fy0m030 dEMNdYA6ck/JtEDuUdN9p2lxLuys4gbPeMgUWbxaIuH8+yjZB3KQTAJp61Tp4QTyxuxKtiOsT EFrgSNLM8SjBOmamyhPk0tZSwhUl0plsZEq4RqK+VnqJn42st7mmSttahmP65RdXeCzL+gvj6 gTXAXNltX5Nsd5koS5qVFayIW9CfnIWfaj+AsChOJmXopy+ylvA+GZFOIaB70ogTuN/8Su1t8 u3YVFB4B8emlk5/k7oU1vmIpZFBDR6lPiBzNe88BVltfYYwY1i9BoKkHXdviifM7AWcJje/K6 U338o7sO/xU/re6kS+mdZ6KJEtiVQLpbpkP5BLqo/NEZkVgwWyCDx5jFXDLpF7mlq7UYZr1wp YSA0Cje7iTBTNN7KQsQCmWvM/RRcJrGfcGIZlycUeu+WXWE3eU2UJctbpWU= Archived-At: Subject: [Ace] Constrained Devices and Off-Loading X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 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, 01 Oct 2015 08:02:23 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --j6t8o0BwWAXaTOs2HSDFrXf7riVBPhfb3 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi all, I wanted to raise a point that has bothered me in the discussions on constrained devices already for some time. As the text from the architecture document shows the way how the story is painted is that constrained devices cannot (due to their limitations) perform certain functions on their own and hence they need some third party. Here is one example of such a text: " The limitations of the constrained nodes ask for security mechanisms which take the special characteristics of constrained environments into account; not all constituents may be able to perform all necessary tasks by themselves. In order to meet the security requirements in constrained scenarios, the necessary tasks need to be assigned to logical functional entities. In order to be able to achieve complex security objectives between actors some of which are hosted on simple ("constrained") devices, some of the actors will make use of help from other, less constrained actors. (This offloading is not specific to networks with constrained nodes, but their constrainedness as the main motivation is.) " I see the story a bit differently. What I see is that in general there is a need for third parties to centrally manage authorization. This is not a unique aspect of constrained devices. You can look at pretty much every sector and you will see that there is a desire to centrally manage devices for a variety of reasons, most of them have nothing to do with device limitations. It is just convenient to do that. If I look at the identity management industry then I see them also introducing capabilities for authorizing IoT devices (and not just users and service access, an effort that has been going on the last 15+ years).= In that spirit I believe it is worthwhile to phrase the story in a bit broader style so that these companies recognize themselves and their work again in this environment, particularly since many of the deployed IoT devices are not as constrained some some would think. What I would do is to describe the story as an evolution. Today we have companies doing device management and with the increasing IoT deployment they are also moving over to the management of smaller devices. I could contribute text if there is actually interest. I hate to contribute text that gets trashed. What do others think about this approach? Ciao Hannes --j6t8o0BwWAXaTOs2HSDFrXf7riVBPhfb3 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJWDOhQAAoJEGhJURNOOiAtlw0H/0txz7toy/089NiQZFxvKK3N gtEUvjl6naac+40yJzlMPrxSRczs9Db68bTtfGcB+OkgyYLx0kh8qm3EU5GzGLSy n7G1Pu/1KvuPoBZtsBItYAgWkOlyHY1gb0oypzgO/hH5pGaStlvsOB+saH3XjK/p fAQoYOiIQH9knbD67RSitJR6UBdriKvtBXd14r2WbHon/xF4DXYmMM5z/UeTbgNF D7YRvzHSh+2Tazvg+TcbZrLRY9/Xm8GnCjLJoBpXNz+TYl3NJvvFjk3zWBOw4WbU qu6vb14nrv7QGVJKsKZXyekrSacg1q8Jv0DfUfGLky/KMmfQcpFN+HdriYLn1Lo= =IvyB -----END PGP SIGNATURE----- --j6t8o0BwWAXaTOs2HSDFrXf7riVBPhfb3-- From nobody Thu Oct 1 01:17:10 2015 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 962621B2BBD for ; Thu, 1 Oct 2015 01:16:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.55 X-Spam-Level: X-Spam-Status: No, score=-1.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qbEO8o7vXV0E for ; Thu, 1 Oct 2015 01:16:55 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1DF1F1B2BB2 for ; Thu, 1 Oct 2015 01:16:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [134.102.201.11]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id t918GpKg018285; Thu, 1 Oct 2015 10:16:51 +0200 (CEST) Received: from alma.local (eduroam-pool8-077.wlan.uni-bremen.de [134.102.6.76]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3nRS3Q72dBz4pxV; Thu, 1 Oct 2015 10:16:50 +0200 (CEST) Message-ID: <560CEBF1.303@tzi.org> Date: Thu, 01 Oct 2015 10:16:49 +0200 From: Carsten Bormann User-Agent: Postbox 4.0.5 (Macintosh/20150923) MIME-Version: 1.0 To: Hannes Tschofenig References: <560CE84F.1070900@gmx.net> In-Reply-To: <560CE84F.1070900@gmx.net> X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: "Ace@ietf.org" Subject: Re: [Ace] Constrained Devices and Off-Loading X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 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, 01 Oct 2015 08:16:56 -0000 Hannes Tschofenig wrote: > What I see is that in general there is a need for third parties to > centrally manage authorization. I'm not so sure about that "centrally", but yes. The difference may be that there are additional reasons to do this here: the constrainedness, the thingness, etc. That may influence the selection of solutions. So that hammer may not fit that specific nail very well. Grüße, Carsten From nobody Thu Oct 1 01:30:49 2015 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DA7D1B2BD3 for ; Thu, 1 Oct 2015 01:30:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5pDkWAhFvegE for ; Thu, 1 Oct 2015 01:30:45 -0700 (PDT) Received: from mail-la0-f42.google.com (mail-la0-f42.google.com [209.85.215.42]) (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 D5A1B1B2BD2 for ; Thu, 1 Oct 2015 01:30:44 -0700 (PDT) Received: by laer8 with SMTP id r8so69929549lae.2 for ; Thu, 01 Oct 2015 01:30:43 -0700 (PDT) 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:content-type; bh=zADuOeJqzXxR+9k3cLAHKqGcumbGRR/G0wZLxqh77WE=; b=FWAHQ76yqEkhyadMohqWkW/1MwC466ShPsdUMGBtzTWW7Wgz23zFtUU4vz2YjSXPJG qykdLPOp+FjLpb4gDQE4Wtod01nr3/42GvCqWlBpvacK71lNOyeLiL1OZ1klihG7ymdB ISPIOKs14twqyUmdShISA93FLXKq6KSzikoIifn/LEPJbJ4RHgsae553OfLfrD1ZyNiw hqqO3qiRaGZK37qR/dbk6fJvy0r4LcmEh4cdjdyym2gKJ0jPjBvG1VCAoWlmHFqFIuB/ PJbD2WqtOTAhmxqz7PdexhEnXr9sHfL6uslbOZYph9dDwt3gZm48mRMSOjRZTYP3Rdj/ fEnw== X-Gm-Message-State: ALoCoQkQ6PiCQCzP8VOwz+fR4KJwgROeyh3d71Y/a47WIy1hDBFQp+lLW/g+J0X7NbAZGHG1V1Dr X-Received: by 10.152.228.171 with SMTP id sj11mr11867lac.88.1443688242930; Thu, 01 Oct 2015 01:30:42 -0700 (PDT) Received: from [192.168.0.108] ([85.235.11.178]) by smtp.gmail.com with ESMTPSA id g7sm520348lbs.10.2015.10.01.01.30.41 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 01 Oct 2015 01:30:42 -0700 (PDT) To: ace@ietf.org References: <088001d0fbf6$e4527480$acf75d80$@augustcellars.com> From: Ludwig Seitz Message-ID: <560CEF31.9030204@sics.se> Date: Thu, 1 Oct 2015 10:30:41 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <088001d0fbf6$e4527480$acf75d80$@augustcellars.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms010808070805020309020307" Archived-At: Subject: Re: [Ace] Security properties of CoAP message fields X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 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, 01 Oct 2015 08:30:47 -0000 This is a cryptographically signed message in MIME format. --------------ms010808070805020309020307 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable On 2015-10-01 05:11, Jim Schaad wrote: > I want to go through the fields of a CoAP message and figure out what t= he > security properties for each of the fields would need to be at a minimu= m. > It would, of course, always be acceptable to provide a higher degree of= > security on any field, but knowing minimums helps. I am not worried ab= out > how to achieve the required security level. This should just be a > discussion of what security levels are required. [...] Code: I think that this is going to depend on what the code is. For=20 C->RS > messages and probably for RS->C success responses it should be integrit= y > protected. For RS->C failures, it would be good to be integrity protec= ted. > For Proxy->C responses it might not be able to be protected. For Mallo= ry->C > responses it would never be protected. Does C do different things if = a > protected message is sent and an unprotected message is returned? (Ass= umes > that C always initiates.) In the case of CoAP observe or publish subscribe, can you always say=20 that C initiates? Sure at some point C sent the initial observe/subscribe message, but the = subsequent updates/publications are actually initiated by the RS. I guess when C initiates it should be possible for C to specify if it=20 expects integrity protected response codes. This way a honest proxy can=20 forward such a request to the RS (if it cannot provide the requested=20 protection). > Options: Protection extended to options is going to be option and poss= ibly > dialog specific. > * None: There are/may be options which are expected to be modified in= > transit. There are options which may be/are expected to be inserted in= > transit. These options cannot have any security protection on them > > * Integrity Only: The option can be visible to intervening entities, = and > indeed might be required to be visible for them to function properly, b= ut > there is a requirement that the option not be changed between the sende= r and > the recipient. > > * Confidential (and integrity protected): The option is not to be visi= ble > to intervening entities. Note that the Proxy-Uri option is under some circumstances decomposed to = the Uri-* options, thus it changes, but can be reconstructed and=20 therefore integrity protected. Perhaps some of the CoAP experts can confirm (or deny) this and add some = explanatory example here? /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 http://www.sics.se --------------ms010808070805020309020307 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 DFQwggYYMIIFAKADAgECAgMMhpgwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYw FAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZp Y2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJt ZWRpYXRlIENsaWVudCBDQTAeFw0xNTAxMDgwODM5MDZaFw0xNjAxMDkyMjQxMzBaMDgxFzAV BgNVBAMMDmx1ZHdpZ0BzaWNzLnNlMR0wGwYJKoZIhvcNAQkBFg5sdWR3aWdAc2ljcy5zZTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMVB4rAuq4FxbARxwRqPLpc/3C194F+V H4XMKK6fu3Y8zDLijzNSjh6tG41oZhXvJcvAs1nZNjUutNLeyBAUFiYhy7HXNdlKpjbMEFKQ +6KpEdZ0Rk+pXgB2E1mqZEfp3M2djcQ/h+7uGVlSGYNAxYk6rWPIIWBx2GMvAQaHP4xxu/F+ PiSQILOVzmtIFZe1t/Lw71aaNeMYVhARo8z5PVsVoq6gBeujxfiRLtiQ/S8xW6RKvNvUkVyT BQfcKaEDZR9FENNf9rFgiAcT6R7hI8RBf1d2fxdlbDU8uM72K3fvzGDt8N9Bfm1kDWbDBxJE 1taRIYs+60D1kwV6DvBb9MECAwEAAaOCAtQwggLQMAkGA1UdEwQCMAAwCwYDVR0PBAQDAgSw MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAdBgNVHQ4EFgQU6ryrKahJtBOEdbIL AAWCpOsQyagwHwYDVR0jBBgwFoAUU3Ltkpzg2ssBXHx+ljVO8tS4UYIwGQYDVR0RBBIwEIEO bHVkd2lnQHNpY3Muc2UwggFMBgNVHSAEggFDMIIBPzCCATsGCysGAQQBgbU3AQIDMIIBKjAu BggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjCB9wYIKwYB BQUHAgIwgeowJxYgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwAwIBARqBvlRo aXMgY2VydGlmaWNhdGUgd2FzIGlzc3VlZCBhY2NvcmRpbmcgdG8gdGhlIENsYXNzIDEgVmFs aWRhdGlvbiByZXF1aXJlbWVudHMgb2YgdGhlIFN0YXJ0Q29tIENBIHBvbGljeSwgcmVsaWFu Y2Ugb25seSBmb3IgdGhlIGludGVuZGVkIHB1cnBvc2UgaW4gY29tcGxpYW5jZSBvZiB0aGUg cmVseWluZyBwYXJ0eSBvYmxpZ2F0aW9ucy4wNgYDVR0fBC8wLTAroCmgJ4YlaHR0cDovL2Ny bC5zdGFydHNzbC5jb20vY3J0dTEtY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEF BQcwAYYtaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczEvY2xpZW50L2NhMEIG CCsGAQUFBzAChjZodHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MxLmNs aWVudC5jYS5jcnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqG SIb3DQEBBQUAA4IBAQBl8BbG0n7+JjFqiJOuAqMbkeqM6Oyd+4oHGu3fbaSiM1SKesae2bfm vifV99a+M4DERZ2SVkOYcvNlv31Q3hvYtzRjDOqewzVKxo021R3ddQULW1DhvTEpclikG5rd 0NRJQn+EkSwEKLeUj68i0dhU8ULhZDDq3A81cTcZzIGrTjNnwDvCktB/sF/iO4At6RJ24P3j KjYFPirW3NsvZ2gzZizSzeubPE0/cWcqEBJ/UtaFPF54efejjLuPRHHMLPDcvrwBhEiBxuG6 oTEo465g4pS9Vo/Z0GoZgZyA+aGQ+YPbPSsqsYmSBjZ6MGGDqQq0niE2dW+8IOdHQvMkqI52 MIIGNDCCBBygAwIBAgIBHjANBgkqhkiG9w0BAQUFADB9MQswCQYDVQQGEwJJTDEWMBQGA1UE ChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUg U2lnbmluZzEpMCcGA1UEAxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwHhcN MDcxMDI0MjEwMTU1WhcNMTcxMDI0MjEwMTU1WjCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoT DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUg Q2xpZW50IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAxwmDzM4t2BqxKaQu E6uWvooyg4ymiEGWVUet1G8SD+rqvyNH4QrvnEIaFHxOhESip7vMz39ScLpNLbL1QpOlPW/t FIzNHS3qd2XRNYG5Sv9RcGE+T4qbLtsjjJbi6sL7Ls/f/X9ftTyhxvxWkf8KW37iKrueKsxw 2HqolH7GM6FX5UfNAwAu4ZifkpmZzU1slBhyWwaQPEPPZRsWoTb7q8hmgv6Nv3Hg9rmA1/VP BIOQ6SKRkHXG0Hhmq1dOFoAFI411+a/9nWm5rcVjGcIWZ2v/43Yksq60jExipA4l5uv9/+Hm 33mbgmCszdj/Dthf13tgAv2O83hLJ0exTqfrlwIDAQABo4IBrTCCAakwDwYDVR0TAQH/BAUw AwEB/zAOBgNVHQ8BAf8EBAMCAQYwHQYDVR0OBBYEFFNy7ZKc4NrLAVx8fpY1TvLUuFGCMB8G A1UdIwQYMBaAFE4L7xqkQFulF2mHMMo0aEPQQa7yMGYGCCsGAQUFBwEBBFowWDAnBggrBgEF BQcwAYYbaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL2NhMC0GCCsGAQUFBzAChiFodHRwOi8v d3d3LnN0YXJ0c3NsLmNvbS9zZnNjYS5jcnQwWwYDVR0fBFQwUjAnoCWgI4YhaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vc2ZzY2EuY3JsMCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNv bS9zZnNjYS5jcmwwgYAGA1UdIAR5MHcwdQYLKwYBBAGBtTcBAgEwZjAuBggrBgEFBQcCARYi aHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEFBQcCARYoaHR0cDov L3d3dy5zdGFydHNzbC5jb20vaW50ZXJtZWRpYXRlLnBkZjANBgkqhkiG9w0BAQUFAAOCAgEA CoMIfXirLAZcuGOMXq4cuSN3TaFx2H2GvD5VSy/6rV55BYHbWNaPeQn3oBSU8KgQZn/Kck1J xbLpAxVCNtsxeW1R87ifhsYZ0qjdrA9anrW2MAWCtosmAOT4OxK9QPoSjCMxM3HbkZCDJgnl E8jMopH21BbyAYr7b5EfGRQJNtgWcvqSXwKHnTutR08+Kkn0KAkXCzeQNLeA5LlYUzFyM7kP Ap8pIRMQ+seHunmyG642S2+y/qHEdMuGIwpfz3eDF1PdctL04qYK/zu+Qg1Bw0RwgigVZs/0 c5HP2/e9DBHh7eSwtzYlk4AUr6yxLlcwSjOfOmKEQ/Q8tzh0IFiNu9IPuTGAPBn4CPxD0+Ru 8T2wg8/s43R/PT3kd1OEqOJUl7q+h+r6fpvU0Fzxd2tC8Ga6fDEPme+1Nbi+03pVjuZQKbGw KJ66gEn06WqaxVZC+J8hh/jR0k9mST1iAZPNYulcNJ8tKmVtjYsv0L1TSm2+NwON58tO+pIV zu3DWwSEXSf+qkDavQam+QtEOZxLBXI++aMUEapSn+k3Lxm48ZCYfAWLb/Xj7F5JQMbZvCex glAbYR0kIHqW5DnsYSdMD/IplJMojx0NBrxJ3fN9dvX2Y6BIXRsF1du4qESm4/3CKuyUV7p9 DW3mPlHTGLvYxnyKQy7VFBkoLINszBrOUeIxggPtMIID6QIBATCBlDCBjDELMAkGA1UEBhMC SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENl cnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJ bnRlcm1lZGlhdGUgQ2xpZW50IENBAgMMhpgwDQYJYIZIAWUDBAIBBQCgggIpMBgGCSqGSIb3 DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE1MTAwMTA4MzA0MVowLwYJKoZI hvcNAQkEMSIEIIt4hGCQ3PazT1uO6FC3RHla6dXyhHtPBFTffHYB73VsMGwGCSqGSIb3DQEJ DzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0D AgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgaUGCSsGAQQB gjcQBDGBlzCBlDCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzAp BgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0 YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgMMhpgwgacG CyqGSIb3DQEJEAILMYGXoIGUMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20g THRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG A1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EC AwyGmDANBgkqhkiG9w0BAQEFAASCAQCiEz8knM7lO5S87YTP90TlYWgNNAfZrQQ3qvGChvFf TdeqjDYp1iJwboj2AguMImlaoMlUshZOmKgyMcY87oE5nCrbopPF9yUJl46JaDaKp+EBGYoV Z+ru00quU1YVWGkNv+USWhS3cSAXgQj2tNQKoWyCNZAGvuKhc5Lc7kNUh2Juzqo04oLhxSia Is+zQ+RS6+PAsf6wJt3L/d0ALA+6oOkSwFiV3fkFOleRmSiDs5tfyVdeMRyuZA7OLaJ2aS+4 pUvuzpyTAPEcZMCW8OsB1hQRIq6DpI5u+CwgE6IT7yz3V29AHArdkp8xfYSDz8wBzrnfWo4t 3SzAtZokhWxLAAAAAAAA --------------ms010808070805020309020307-- From nobody Thu Oct 1 01:39:23 2015 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DAB6D1B2BE8 for ; Thu, 1 Oct 2015 01:39:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.55 X-Spam-Level: X-Spam-Status: No, score=-1.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e32GQ42baryr for ; Thu, 1 Oct 2015 01:39:22 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EF5AB1B2B9D for ; Thu, 1 Oct 2015 01:39:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [134.102.201.11]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id t918dGXj009758; Thu, 1 Oct 2015 10:39:16 +0200 (CEST) Received: from alma.local (eduroam-pool8-077.wlan.uni-bremen.de [134.102.6.76]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3nRSYJ38RCz4nfQ; Thu, 1 Oct 2015 10:39:16 +0200 (CEST) Message-ID: <560CF133.6080702@tzi.org> Date: Thu, 01 Oct 2015 10:39:15 +0200 From: Carsten Bormann User-Agent: Postbox 4.0.5 (Macintosh/20150923) MIME-Version: 1.0 To: Jim Schaad References: <088001d0fbf6$e4527480$acf75d80$@augustcellars.com> In-Reply-To: <088001d0fbf6$e4527480$acf75d80$@augustcellars.com> X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: Ace@ietf.org Subject: Re: [Ace] Security properties of CoAP message fields X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 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, 01 Oct 2015 08:39:23 -0000 Jim Schaad wrote: > I want to go through the fields of a CoAP message and figure out what the > security properties for each of the fields would need to be at a minimum. That is not an easy undertaking... E.g.: > Message ID: Should be integrity protected. There is probably no need to integrity-protect the message-ID. The damage an attacker can do by spoofing the message ID is equivalent to suppressing messages, and if an attacker can do the former they can probably do the latter anyway. (This is more at the level of protecting connectivity.) The beef is probably in the options. See OSCOAP Appendix A for one such effort. One other quick comment: > * Confidential (and integrity protected): The option is not to be visible > to intervening entities. More precisely: visible only to specific entities (intervening or not). Grüße, Carsten From nobody Thu Oct 1 01:59:02 2015 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFAEE1B2C40 for ; Thu, 1 Oct 2015 01:59:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RQ3DdGrHAJVJ for ; Thu, 1 Oct 2015 01:58:59 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (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 046C61B2C3C for ; Thu, 1 Oct 2015 01:58:59 -0700 (PDT) Received: from [192.168.131.140] ([80.92.119.87]) by mail.gmx.com (mrgmx001) with ESMTPSA (Nemesis) id 0LoVvG-1aJNUZ1DQY-00gV8Q; Thu, 01 Oct 2015 10:58:57 +0200 To: Carsten Bormann References: <560CE84F.1070900@gmx.net> <560CEBF1.303@tzi.org> From: Hannes Tschofenig Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9 X-Enigmail-Draft-Status: N1110 Message-ID: <560CF55A.1080704@gmx.net> Date: Thu, 1 Oct 2015 10:56:58 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <560CEBF1.303@tzi.org> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="kcWqUru8EGxvt0xfCGmornrL6LQ3N1rCf" X-Provags-ID: V03:K0:5o2dV8ZreeAaiInHsdh2R9+cxwfTRiOaIl2IlOHNAXvMuIUpXXu LPaE3F6WOdI+kJ//HQUUlOXE77uWuRs08Qs6jX7WvS6Q3Yvu+BqKbInse4C/15vTKFz642W 4olQLYFGH4Axzz4tUrsoIIHxEbQY9jKXFA4Vi+0DsNKkCZSvagGSdyrlrUX8+dMxsb60WZB YQsBX+dFg+TNubvjkpMew== X-UI-Out-Filterresults: notjunk:1;V01:K0:ucW7nTby1C0=:CvW61mdBVOdgfBPqfVsJSr bxB6+U9P2xdulT3T3bwsQL3psHw0WgWaSRgPH/nZQ+YbUU6q7hopEeuBlhkcwhaP0GXaY0CDD g/YJgYhnByOgpM6O609D0eL3yCnQE+XevAmKrkHzYtSSs2RthLX2qJGe8Uc9CJnjXfsBOZEIA ep5bVPMi5no0XrjU5YE2/QoAFdYyOr/rVq+Q4jTP7iqSSlAV54OUIuLnSw6eMD6jO7EFTESRK dLxzri+SEJzGyDRhZBeGnM1CENgc8heLYLx8XbXYuWq/lXAzFj8bWNd9B1lnpxp8oRINeOFM2 XMimk12BUiLi7jo2MeglBNjMxZoqzxRc8WBhceWwFGrTxLz+P+d73884aHAlMslVT3rqnZUtr B+XGuIN3p7aLXdONTPWzJZi/gIXeTEKFuSEe1K8tNjhiJPBV5uISu62kblCqnPybk8h0kSp8T 3zZ1utKL+rhtVdBvgqq+3knAsA9jzQ2GdqqU7sUrcum5IAYdfkES31VjeYaVQnWUm7i4mw2V/ sKytvMJDVVh0BSkc/ZTEfBq5bzdMdxI8+nWQ7Z0xZ0oy2IUoTbam2ivVggd1oYH963ftgrfSd pVtDTOd/cCHVNLtFhx244/ZxRGt4u8FRIy1X2kFQDnNL/CsNbxiCNvb8auT3cIHI87TTURhI3 aijnD7AEFB0K48KaS0Se3a7ZLHtQ85smMbihyWVUEb+7fSwRTGyaQWdUra5bE9oF6NjECTJ5d NyY3b8kzdkg7/zQnmixI6s8/QUKeFRs9xKkEy2ErFuUSZywhNrFtfAvsICc= Archived-At: Cc: "Ace@ietf.org" Subject: Re: [Ace] Constrained Devices and Off-Loading X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 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, 01 Oct 2015 08:59:01 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --kcWqUru8EGxvt0xfCGmornrL6LQ3N1rCf Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Carsten thanks for your quick response. On 10/01/2015 10:16 AM, Carsten Bormann wrote: > Hannes Tschofenig wrote: >> What I see is that in general there is a need for third parties to >> centrally manage authorization. >=20 > I'm not so sure about that "centrally", but yes. Centrally is a loose term. I have looked at two use cases in detail, namely the physical access control and the lighting use case. In the physical access control centrally refers to the enterprise identity management system. In the lighting sector centrally means two different things (as described in the draft we submitted to the group), namely the device the installer uses for entities that are fixed in the building (such as light switches and their luminaries). The installer will then disappear once the job is done but may show up again when there is a need to re-configure the devices in the building. Then, there is the more dynamic case where dynamic access is needed and that has to be done via a dedicated server in the network. Smaller companies may not necessarily care about the dynamic use case and so they do not need a dedicated server. In other scenarios the story may be different but I just haven't looked at them in detail. I actually takes a while to understand these scenarios in detail since you have to talk to domain experts. >=20 > The difference may be that there are additional reasons to do this here= : > the constrainedness, the thingness, etc. That may influence the > selection of solutions. I guess it would have been too far fetched to assume that you like my proposal. >=20 > So that hammer may not fit that specific nail very well. >=20 > Gr=C3=BC=C3=9Fe, Carsten >=20 Ciao Hannes --kcWqUru8EGxvt0xfCGmornrL6LQ3N1rCf Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJWDPVaAAoJEGhJURNOOiAtZhUH/1XOhABiPLEBJ4hx7Ye06orm wYRUu4mP8wpoip5Fn6QFL1p/gDBSK0pzU+C0WMQw+pTmI+vL82OB9IPbA8+hoV1v wzE+0eijb+yhNXZpA30J96TtqFoanWa4zy5w9eSBxjf6eUmUnOKROqTZelih2Ci0 r69iZphLv1rTx17aqk1s3DaVzJ3pMLX87X515K7lMLqfYRqvmd59iFHeG4kzUHpR 4AA5yXdhI8Vs2AzSLB1dsjREOqnTdSBh7FWTQbbJVYBDBsUp4/hT3jGL6QO8O3Xe 0T6fcnm6Bc/92Jy0rObF1vgv0dijk90LdrQ6fn9vpJLjtuMCgsr3J0W7rNlMlds= =gPoK -----END PGP SIGNATURE----- --kcWqUru8EGxvt0xfCGmornrL6LQ3N1rCf-- From nobody Thu Oct 1 03:15:54 2015 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6821B1A1AE1 for ; Thu, 1 Oct 2015 03:15:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.55 X-Spam-Level: X-Spam-Status: No, score=-1.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qeElAXu7BBOg for ; Thu, 1 Oct 2015 03:15:52 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 79C5A1A1AC2 for ; Thu, 1 Oct 2015 03:15:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::b]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id t91AFlaf000306; Thu, 1 Oct 2015 12:15:47 +0200 (CEST) Received: from alma.local (reingewinn.informatik.uni-bremen.de [134.102.218.123]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3nRVhg6Nfcz4pjn; Thu, 1 Oct 2015 12:15:47 +0200 (CEST) Message-ID: <560D07D3.6030103@tzi.org> Date: Thu, 01 Oct 2015 12:15:47 +0200 From: Carsten Bormann User-Agent: Postbox 4.0.5 (Macintosh/20150923) MIME-Version: 1.0 To: Hannes Tschofenig References: <560CE84F.1070900@gmx.net> <560CEBF1.303@tzi.org> <560CF55A.1080704@gmx.net> In-Reply-To: <560CF55A.1080704@gmx.net> X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: "Ace@ietf.org" Subject: Re: [Ace] Constrained Devices and Off-Loading X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 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, 01 Oct 2015 10:15:53 -0000 Hannes Tschofenig wrote: > I guess it would have been too far fetched to assume that you like my > proposal. Hey, I did say "yes". Just added a caveat. Grüße, Carsten From nobody Thu Oct 1 05:02:04 2015 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7D751A21C1 for ; Thu, 1 Oct 2015 05:02:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BOJKPYJ2q912 for ; Thu, 1 Oct 2015 05:02:01 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) (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 D8D1A1A21BF for ; Thu, 1 Oct 2015 05:02:00 -0700 (PDT) Received: by lbwr8 with SMTP id r8so7743024lbw.2 for ; Thu, 01 Oct 2015 05:01:59 -0700 (PDT) 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:content-type; bh=3tHyE+N7XO68knGeYOHT+yGrxUlkl6cQQB/xlHCptAQ=; b=jiH7p1pnp8PpKSG9jlekQG4dydH7XRZ6VQaSg8re+jzZllpjmns/k0ZsTT4YlofJK3 WpEf3FIAx6eyJUy6rcwI7MHlzPx2WccoexdJel2eOSPF8TiToGCaMkgO3vIlaI5aCEFM DNQW06EW1s8MMcJwbWpWnuo6WoaPuhU+U61/Z/gWr/Njwt0oMgCSiNO8VGqXF8xKweRd Z0wvjiJzZCr/Bd3EkYa53vxUrvAPYi3Awaj0rJUwy7Ck2SBarcfRPe34QiCwn5eOaQQ+ Yf3SWXJXgEPM6g6bACgh+yTYwmK2yFuMFwk/TzP8gwKF+F2Qlh9hZnJf8Z42QQC984/Q cocA== X-Gm-Message-State: ALoCoQle5kBCsDgoIv5es0+Fou7se6XNOTxDjSAkCYFBTQT1skerRIyyzOMjOmkCryneRCuLoG2h X-Received: by 10.152.170.135 with SMTP id am7mr2828529lac.78.1443700918907; Thu, 01 Oct 2015 05:01:58 -0700 (PDT) Received: from [192.168.0.108] ([85.235.11.178]) by smtp.gmail.com with ESMTPSA id pm6sm615810lbc.1.2015.10.01.05.01.28 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 01 Oct 2015 05:01:48 -0700 (PDT) To: ace@ietf.org References: <0B20F0CA-B84B-4A4B-82E4-D5E87F27D715@sn3rd.com> From: Ludwig Seitz Message-ID: <560D208D.9050902@sics.se> Date: Thu, 1 Oct 2015 14:01:17 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <0B20F0CA-B84B-4A4B-82E4-D5E87F27D715@sn3rd.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms020102030906020605000501" Archived-At: Subject: Re: [Ace] Second WGLC for draft-ietf-ace-usecases-05/6 X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 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, 01 Oct 2015 12:02:04 -0000 This is a cryptographically signed message in MIME format. --------------ms020102030906020605000501 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable On 2015-09-30 22:04, Sean Turner wrote: > I=E2=80=99m late with these so feel free to address these during IETF L= C. > > Overall, I think this draft is good to go and is much better than an > earlier version I reviewed. First a couple of questions: > > 0) I=E2=80=99ve got two questions that I=E2=80=99d like to ask about th= e home > automation case that I=E2=80=99m not sure would require changes (and si= nce > these are late I=E2=80=99ll leave that up to the chairs): > > 0.0) s2.2: There=E2=80=99s the concept of two owners and it seems to im= ply > that they both have the same authorization level. Do you envision a > scenario where say Alice, who is a lawyer, has a smart lock on her > closet to store her files and laptop after work that Bob can=E2=80=99t > access? Why bring lawyers into an otherwise pleasant scenario? Joke aside: No we haven't considered this kind of scenario. However I expect that=20 would be subsumed by o U2.3 A home owner wants to apply different access rights for different users. where Bob would be "just" a user, who does not have full access to all=20 systems in the house. Now if Bob wants a similar closet for his stamps collection that Alice=20 cannot access, I would expect that it would be hard to integrate that=20 into a home automation system controlled by Alice ... > > 0.1) s2.2: The addition of the public safety use case also made me > wonder, if there=E2=80=99s an idea to allow the fire brigade in when th= e > house is on fire or to let the police in if Bob has activated his > home alarm's panic button? > I guess that was implicitly assumed in section 2.4.2.1. The fire department already has special access rights (namely turning=20 off the fire alarm). Perhaps a slight rewording of U4.4 to include other rights than just=20 administrative tasks could resolve this? > 1) One question about the building lighting use case: > > s2.4.1.3/s2.4.3: Should there be a requirement from maintenance about > the device checking the authz before accepting the new firmware? Is > this addressed by U4.10 (if so might be good to add "(U4.10)" to the > last para of s2.4.1.3)? I wouldn't assume that uploading new firmware is a "extremely=20 time-sensitive operation" so U4.10 is not the best item to cover this. I think the reason why there is no explicit item for this one here is=20 that the problem list was supposed to to be incremental. > > 2) One question about the sports and entertainment use case: > > s2.6: The =E2=80=9Clow=E2=80=9D value judgement caught my attention bec= ause when I > first read this use case I thought that one man=E2=80=99s entertainment= event > where everybody=E2=80=99s kit lights up when their team scores is anoth= er > man=E2=80=99s dissent rally getting droned because their Guy Fawkes mas= ks are > chipped; I also thought that entertainment devices (e.g. gaming > systems) are being used for =E2=80=9Cswatting=E2=80=9D so entertainment= !=3D low. But, > then I read use case and I kind of agree that the as described use > case might not need all that much security because the transmit range > of the devices is likely quite small. So could you just strike the > 1st sentence and =E2=80=9Chowever=E2=80=9D from the second sentence and= call it day? > I'm ok with that, Steffi do you agree? > > The rest of these are all editorial so I suggested changes OLD/NEW > and r/old/new: > I'll look into these /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 http://www.sics.se --------------ms020102030906020605000501 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 DFQwggYYMIIFAKADAgECAgMMhpgwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYw FAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZp Y2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJt ZWRpYXRlIENsaWVudCBDQTAeFw0xNTAxMDgwODM5MDZaFw0xNjAxMDkyMjQxMzBaMDgxFzAV BgNVBAMMDmx1ZHdpZ0BzaWNzLnNlMR0wGwYJKoZIhvcNAQkBFg5sdWR3aWdAc2ljcy5zZTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMVB4rAuq4FxbARxwRqPLpc/3C194F+V H4XMKK6fu3Y8zDLijzNSjh6tG41oZhXvJcvAs1nZNjUutNLeyBAUFiYhy7HXNdlKpjbMEFKQ +6KpEdZ0Rk+pXgB2E1mqZEfp3M2djcQ/h+7uGVlSGYNAxYk6rWPIIWBx2GMvAQaHP4xxu/F+ PiSQILOVzmtIFZe1t/Lw71aaNeMYVhARo8z5PVsVoq6gBeujxfiRLtiQ/S8xW6RKvNvUkVyT BQfcKaEDZR9FENNf9rFgiAcT6R7hI8RBf1d2fxdlbDU8uM72K3fvzGDt8N9Bfm1kDWbDBxJE 1taRIYs+60D1kwV6DvBb9MECAwEAAaOCAtQwggLQMAkGA1UdEwQCMAAwCwYDVR0PBAQDAgSw MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAdBgNVHQ4EFgQU6ryrKahJtBOEdbIL AAWCpOsQyagwHwYDVR0jBBgwFoAUU3Ltkpzg2ssBXHx+ljVO8tS4UYIwGQYDVR0RBBIwEIEO bHVkd2lnQHNpY3Muc2UwggFMBgNVHSAEggFDMIIBPzCCATsGCysGAQQBgbU3AQIDMIIBKjAu BggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjCB9wYIKwYB BQUHAgIwgeowJxYgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwAwIBARqBvlRo aXMgY2VydGlmaWNhdGUgd2FzIGlzc3VlZCBhY2NvcmRpbmcgdG8gdGhlIENsYXNzIDEgVmFs aWRhdGlvbiByZXF1aXJlbWVudHMgb2YgdGhlIFN0YXJ0Q29tIENBIHBvbGljeSwgcmVsaWFu Y2Ugb25seSBmb3IgdGhlIGludGVuZGVkIHB1cnBvc2UgaW4gY29tcGxpYW5jZSBvZiB0aGUg cmVseWluZyBwYXJ0eSBvYmxpZ2F0aW9ucy4wNgYDVR0fBC8wLTAroCmgJ4YlaHR0cDovL2Ny bC5zdGFydHNzbC5jb20vY3J0dTEtY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEF BQcwAYYtaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczEvY2xpZW50L2NhMEIG CCsGAQUFBzAChjZodHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MxLmNs aWVudC5jYS5jcnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqG SIb3DQEBBQUAA4IBAQBl8BbG0n7+JjFqiJOuAqMbkeqM6Oyd+4oHGu3fbaSiM1SKesae2bfm vifV99a+M4DERZ2SVkOYcvNlv31Q3hvYtzRjDOqewzVKxo021R3ddQULW1DhvTEpclikG5rd 0NRJQn+EkSwEKLeUj68i0dhU8ULhZDDq3A81cTcZzIGrTjNnwDvCktB/sF/iO4At6RJ24P3j KjYFPirW3NsvZ2gzZizSzeubPE0/cWcqEBJ/UtaFPF54efejjLuPRHHMLPDcvrwBhEiBxuG6 oTEo465g4pS9Vo/Z0GoZgZyA+aGQ+YPbPSsqsYmSBjZ6MGGDqQq0niE2dW+8IOdHQvMkqI52 MIIGNDCCBBygAwIBAgIBHjANBgkqhkiG9w0BAQUFADB9MQswCQYDVQQGEwJJTDEWMBQGA1UE ChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUg U2lnbmluZzEpMCcGA1UEAxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwHhcN MDcxMDI0MjEwMTU1WhcNMTcxMDI0MjEwMTU1WjCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoT DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUg Q2xpZW50IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAxwmDzM4t2BqxKaQu E6uWvooyg4ymiEGWVUet1G8SD+rqvyNH4QrvnEIaFHxOhESip7vMz39ScLpNLbL1QpOlPW/t FIzNHS3qd2XRNYG5Sv9RcGE+T4qbLtsjjJbi6sL7Ls/f/X9ftTyhxvxWkf8KW37iKrueKsxw 2HqolH7GM6FX5UfNAwAu4ZifkpmZzU1slBhyWwaQPEPPZRsWoTb7q8hmgv6Nv3Hg9rmA1/VP BIOQ6SKRkHXG0Hhmq1dOFoAFI411+a/9nWm5rcVjGcIWZ2v/43Yksq60jExipA4l5uv9/+Hm 33mbgmCszdj/Dthf13tgAv2O83hLJ0exTqfrlwIDAQABo4IBrTCCAakwDwYDVR0TAQH/BAUw AwEB/zAOBgNVHQ8BAf8EBAMCAQYwHQYDVR0OBBYEFFNy7ZKc4NrLAVx8fpY1TvLUuFGCMB8G A1UdIwQYMBaAFE4L7xqkQFulF2mHMMo0aEPQQa7yMGYGCCsGAQUFBwEBBFowWDAnBggrBgEF BQcwAYYbaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL2NhMC0GCCsGAQUFBzAChiFodHRwOi8v d3d3LnN0YXJ0c3NsLmNvbS9zZnNjYS5jcnQwWwYDVR0fBFQwUjAnoCWgI4YhaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vc2ZzY2EuY3JsMCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNv bS9zZnNjYS5jcmwwgYAGA1UdIAR5MHcwdQYLKwYBBAGBtTcBAgEwZjAuBggrBgEFBQcCARYi aHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEFBQcCARYoaHR0cDov L3d3dy5zdGFydHNzbC5jb20vaW50ZXJtZWRpYXRlLnBkZjANBgkqhkiG9w0BAQUFAAOCAgEA CoMIfXirLAZcuGOMXq4cuSN3TaFx2H2GvD5VSy/6rV55BYHbWNaPeQn3oBSU8KgQZn/Kck1J xbLpAxVCNtsxeW1R87ifhsYZ0qjdrA9anrW2MAWCtosmAOT4OxK9QPoSjCMxM3HbkZCDJgnl E8jMopH21BbyAYr7b5EfGRQJNtgWcvqSXwKHnTutR08+Kkn0KAkXCzeQNLeA5LlYUzFyM7kP Ap8pIRMQ+seHunmyG642S2+y/qHEdMuGIwpfz3eDF1PdctL04qYK/zu+Qg1Bw0RwgigVZs/0 c5HP2/e9DBHh7eSwtzYlk4AUr6yxLlcwSjOfOmKEQ/Q8tzh0IFiNu9IPuTGAPBn4CPxD0+Ru 8T2wg8/s43R/PT3kd1OEqOJUl7q+h+r6fpvU0Fzxd2tC8Ga6fDEPme+1Nbi+03pVjuZQKbGw KJ66gEn06WqaxVZC+J8hh/jR0k9mST1iAZPNYulcNJ8tKmVtjYsv0L1TSm2+NwON58tO+pIV zu3DWwSEXSf+qkDavQam+QtEOZxLBXI++aMUEapSn+k3Lxm48ZCYfAWLb/Xj7F5JQMbZvCex glAbYR0kIHqW5DnsYSdMD/IplJMojx0NBrxJ3fN9dvX2Y6BIXRsF1du4qESm4/3CKuyUV7p9 DW3mPlHTGLvYxnyKQy7VFBkoLINszBrOUeIxggPtMIID6QIBATCBlDCBjDELMAkGA1UEBhMC SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENl cnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJ bnRlcm1lZGlhdGUgQ2xpZW50IENBAgMMhpgwDQYJYIZIAWUDBAIBBQCgggIpMBgGCSqGSIb3 DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE1MTAwMTEyMDExN1owLwYJKoZI hvcNAQkEMSIEIHFilo8qIHy1FVX5dqZioqUQABKkBOgENDwYeVCQLGfLMGwGCSqGSIb3DQEJ DzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0D AgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgaUGCSsGAQQB gjcQBDGBlzCBlDCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzAp BgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0 YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgMMhpgwgacG CyqGSIb3DQEJEAILMYGXoIGUMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20g THRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG A1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EC AwyGmDANBgkqhkiG9w0BAQEFAASCAQAO+5m68ioJfwF1RBUDMuwEDSW9YFJKvw1qWqQhf4k8 LDCTAb4Pf9UqnbtJWdk0MHuyeKh/mQHsKDJ5MnRMSowTejXR1uj1xa0QAFIwWL2p9SSQvUFI 5/aEtk+iL9ktfvlRLwI3Zml45XoQrBknd0ZP3Tt5T5IJN2P+TwiB1P+r2W08UsRSjoJCE75U KxgRRtu72TRe/Sg3UlSRXH4ZvjSon0Yp7tbzZbbH32GG+Hsqo2GsrWuxtcBOUSp7kISK5C0q Op53chyqNEyanqSj7UFHYqPXt5g/JbLf77ce0qDaJSkieB/AKw6RPyNiYCmome/nryy4ZEth HkBZ/Ja3Qdj2AAAAAAAA --------------ms020102030906020605000501-- From nobody Thu Oct 1 05:07:51 2015 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC5E91A219E for ; Thu, 1 Oct 2015 05:07:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.301 X-Spam-Level: X-Spam-Status: No, score=-3.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_44=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y52_5EigcdzK for ; Thu, 1 Oct 2015 05:07:47 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 28E761A6F0E for ; Thu, 1 Oct 2015 05:07:46 -0700 (PDT) X-AuditID: c1b4fb3a-f79136d0000071e2-02-560d221092d1 Received: from ESESSHC021.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 76.3A.29154.0122D065; Thu, 1 Oct 2015 14:07:44 +0200 (CEST) Received: from ESESSMB303.ericsson.se ([169.254.3.186]) by ESESSHC021.ericsson.se ([153.88.183.81]) with mapi id 14.03.0248.002; Thu, 1 Oct 2015 14:07:43 +0200 From: =?utf-8?B?R8O2cmFuIFNlbGFuZGVy?= To: Jim Schaad , "Ace@ietf.org" Thread-Topic: [Ace] Security properties of CoAP message fields Thread-Index: AdD7wXuwKORIzqWaSGu1IQAoFf67FgAgEr+A Date: Thu, 1 Oct 2015 12:07:42 +0000 Message-ID: References: <088001d0fbf6$e4527480$acf75d80$@augustcellars.com> In-Reply-To: <088001d0fbf6$e4527480$acf75d80$@augustcellars.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.7.141117 x-originating-ip: [153.88.183.16] Content-Type: text/plain; charset="utf-8" Content-ID: <36950E10A44F264F9B5888AA24124DE2@ericsson.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpikeLIzCtJLcpLzFFi42KZGfG3RldAiTfM4N9caYvv33qYLVZP/87m wOSxcc50No8lS34yBTBFcdmkpOZklqUW6dslcGVMePWTuWCFdcW/NU/ZGxifWHYxcnBICJhI vJ5o2MXICWSKSVy4t56ti5GLQ0jgKKNEx+RzzBDOYkaJzhmTWUCq2ARcJB40PGICsUUE3CTO 979iBBkkLGAr8fsjD0TYTmLPqr+sELaRxOVbR5hBbBYBFYkJGzawgdi8AhYSl+fvZgSxhQTs Jd7/ugMW5xRwkDhzYjNYnBHooO+n1oCtYhYQl7j1ZD4TxKECEkv2nGeGsEUlXj7+B7ZLVEBP YuX1JjaIuKLEzrPtzCCnMQtoSqzfpQ8xxlpi+ba3jBC2osSU7ofsEOcISpyc+YRlAqP4LCTb ZiF0z0LSPQtJ9ywk3QsYWVcxihanFhfnphsZ6aUWZSYXF+fn6eWllmxiBEbawS2/rXYwHnzu eIhRgINRiYd3wWSeMCHWxLLiytxDjNIcLErivM1MD0KFBNITS1KzU1MLUovii0pzUosPMTJx cEo1MAYxSM7cYbIjcrGdx5WALhfV8gd3Pr9YP82p5azb4ZD/cvXF8imWj3yvdXzc8b9hVYXU C7Vv/1rCItpdJLb7lZizcslsz/S4FbCY8ezF7auLjQJ+GQg1rfWsrnjPYrXxMMt0cdOpgakM /+Z3btNKvyDBpLrS8LOU8vrnfy5mbZf5XJXj8EDwihJLcUaioRZzUXEiAOz1SwGVAgAA Archived-At: Subject: Re: [Ace] Security properties of CoAP message fields X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 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, 01 Oct 2015 12:07:50 -0000 SGkgSmltLA0KDQpBcyBDYXJzdGVuIHBvaW50ZWQgb3V0LCBtdWNoIG9mIHRoaXMgaXMgY29uc2lk ZXJlZCBpbiBBcHBlbmRpeCBBIG9mDQpodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9k cmFmdC1zZWxhbmRlci1hY2Utb2JqZWN0LXNlY3VyaXR5DQoNCihJZiBhbnlvbmUgYnkgY2hhbmNl IGdldHMgbW90aXZhdGVkIHRvIGFjdHVhbGx5IHJlYWQgaXQsIEkgd291bGQgcmVjb21tZW5kDQp3 YWl0IGEgbGl0dGxlIGZvciB2ZXJzaW9uIC0wMyBmb3IgaW1wcm92ZWQgcmVhZGFiaWxpdHkuKQ0K DQpOb3RlIHRoYXQgQXBwZW5kaXggQSBhcHBsaWVzIHRvIE1vZGU6Q09BUCB3aGljaCBpcyB0aGUg bW9kZSB3aGVyZSBwYXlsb2FkLA0Kc2VsZWN0ZWQgaGVhZGVycyBhbmQgb3B0aW9ucyBhcmUgcHJv dGVjdGVkLiBUaGVyZSBpcyBhbHNvIGEgTW9kZTpQQVlMDQp3aGljaCBpcyBvbmx5IHByb3RlY3Rp bmcgcGF5bG9hZC4gRGlmZmVyZW50IE1vZGVzIGFwcGx5IHRvIGRpZmZlcmVudCB1c2UNCmNhc2Vz IGFzIGlzIGV4ZW1wbGlmaWVkIGluIHNlY3Rpb24gMiBhbmQgMyBvZiB0aGUgZHJhZnQgKGFuZCBi ZWxvdykuDQoNCkNvbW1lbnRzIGlubGluZToNCg0KT24gMjAxNS0xMC0wMSAwNToxMSwgIkppbSBT Y2hhYWQiIDxpZXRmQGF1Z3VzdGNlbGxhcnMuY29tPiB3cm90ZToNCg0KPkkgd2FudCB0byBnbyB0 aHJvdWdoIHRoZSBmaWVsZHMgb2YgYSBDb0FQIG1lc3NhZ2UgYW5kIGZpZ3VyZSBvdXQgd2hhdCB0 aGUNCj5zZWN1cml0eSBwcm9wZXJ0aWVzIGZvciBlYWNoIG9mIHRoZSBmaWVsZHMgd291bGQgbmVl ZCB0byBiZSBhdCBhIG1pbmltdW0uDQo+SXQgd291bGQsIG9mIGNvdXJzZSwgYWx3YXlzIGJlIGFj Y2VwdGFibGUgdG8gcHJvdmlkZSBhIGhpZ2hlciBkZWdyZWUgb2YNCj5zZWN1cml0eSBvbiBhbnkg ZmllbGQsIGJ1dCBrbm93aW5nIG1pbmltdW1zIGhlbHBzLiAgSSBhbSBub3Qgd29ycmllZCBhYm91 dA0KPmhvdyB0byBhY2hpZXZlIHRoZSByZXF1aXJlZCBzZWN1cml0eSBsZXZlbC4gIFRoaXMgc2hv dWxkIGp1c3QgYmUgYQ0KPmRpc2N1c3Npb24gb2Ygd2hhdCBzZWN1cml0eSBsZXZlbHMgYXJlIHJl cXVpcmVkLg0KPg0KPkkgaGF2ZSBwcm92aWRlZCBmaXJzdCBndWVzc2VzIGF0IHdoYXQgc2VjdXJp dHkgZnVuY3Rpb25zIEkgdGhpbmsgYXJlDQo+bmVlZGVkLA0KPmJ1dCBhbSBwcm9iYWJseSB3cm9u ZyBhYm91dCBzZXZlcmFsIG9mIHRoZW0uDQo+DQo+UGFydCBvZiB0aGUgcXVlc3Rpb25zIHdvdWxk IGJlIC0gaWYgdGhpcyBjaGFuZ2VzIGluIGZsaWdodCwgc2hvdWxkIHRoZQ0KPnJlY2VpdmVyIHRy ZWF0IHRoZSBtZXNzYWdlIGFzIGludmFsaWQ/DQo+DQo+TG9va2luZyBhdCBhIENvQVAgTWVzc2Fn ZSBwaWVjZSBieSBwaWVjZSBJIHNlZSB0aGUgZm9sbG93aW5nOg0KPg0KPlRvIGFuZCBGcm9tIEFk ZHJlc3Npbmc6ICBPayB0aGlzIGlzIG5vdCByZWFsbHkgcGFydCBvZiB0aGUgbWVzc2FnZSwgSSBq dXN0DQo+d2FudCB0byBlbnN1cmUgdGhhdCBub2JvZHkgdGhpbmdzIHRoYXQgdGhpcyBzaG91bGQg YmUgcHJvdGVjdGVkIGluIGFueSB3YXkNCj5hcyBpdCB3aWxsIGJlIG1vZGlmaWVkIGluIHRyYW5z aXQgYnkgYW55IG51bWJlciBvZiBDb0FQIGFuZCBub24gQ29BUA0KPmVudGl0aWVzLg0KDQpXZSBw cm9wb3NlIHRvIGludGVncml0eSBwcm90ZWN0IGUuZy4gZGVzdGluYXRpb24gVVJJICh0aGUgY29u dGVudCBvZiB0aGUNCkNvQVAgT3B0aW9ucyBVcmktSG9zdCwgVXJpLVBvcnQsIFVyaS1QYXRoLCBV cmktUXVlcnkpIGluIHRoZSBDb0FQIHJlcXVlc3QuDQoNCj4NCj5Db0FQIHZlcnNpb24gbnVtYmVy OiAgTWF5YmUgaW50ZWdyaXR5IHByb3RlY3RlZCAtIEkgZG9uJ3Qgc2VlIGFueSBiZW5lZml0DQo+ aW4NCj5oaWRpbmcuDQoNClRoZSBtaW5kIHNldCB3ZSBoYXZlIGlzIHRoYXQgYmV0d2VlbiBhbnkg dHdvIGVuZHBvaW50cyB3aXRoIGEgc2VjdXJpdHkNCmFzc29jaWF0aW9uIHRoZXJlIG1heSBpbiBn ZW5lcmFsIGJlIHNvbWUgaW50ZXJtZWRpYXRlIG5vZGVzLiBUaGlzIG1lYW5zDQp0aGF0IG1hbnkg b2YgdGhlIGhlYWRlciBwYXJhbWV0ZXJzIGRvZXNu4oCZdCBtYWtlIHNlbnNlIHRvIGludGVncml0 eQ0KcHJvdGVjdCwgYmVjYXVzZSB0aGV5IGFyZSBub3QgcHJlc2VydmVkIGVuZC10by1lbmQuDQoN Cg0KRm9yIFZlcnNpb24gd2Ugd2VyZSBhY3R1YWxseSBjb25zaWRlcmluZyB0aGUgYmVuZWZpdHMg b2YgaGF2aW5nIGEgcHJveHkNCnRyYW5zbGF0aW5nIGJldHdlZW4gZGlmZmVyZW50IHZlcnNpb25z LCB0aHVzIHdlIG9taXR0ZWQgaW50ZWdyaXR5DQpwcm90ZWN0aW9uICh3aGljaCB0aGVuIG5lZWRz IHRvIGJlIGNvbnNpZGVyZWQgd2l0aCBuZXdlciB2ZXJzaW9uIG9mIENvQVANCmFwcGVhciBzbyB0 aGlzIGRvZXMgbm90IGludHJvZHVjZSBhIHZ1bG5lcmFiaWxpdHkpDQoNCg0KPg0KPk1lc3NhZ2Ug dHlwZTogIFRoaXMgbWlnaHQgYmUgaW50ZXJlc3RpbmcgdG8gaW50ZWdyaXR5IHByb3RlY3QsIEkg ZG9uJ3QNCj5rbm93DQo+dGhlcmUgaXMgYW55IGJlbmVmaXQgaW4gaGlkaW5nLg0KPg0KPlRva2Vu IExlbmd0aDogIEltcGxpY2l0bHkgcHJvdGVjdGVkIGlmIHRoZSB0b2tlbiBpdHNlbGYgaXMgcHJv dGVjdGVkLg0KPg0KPlRva2VuOiAgU2hvdWxkIGJlIGludGVncml0eSBwcm90ZWN0ZWQuICBQcm90 ZWN0aW9uIHNob3VsZCBiZSBleHRlbmRlZCB0bw0KPm5vdGluZyB0aGF0IGEgdG9rZW4gZG9lcyBu b3QgZXhpc3QuDQoNCk5vbmUgb2YgdGhlc2UgdGhyZWUgbmVjZXNzYXJpbHkgc3Vydml2ZXMgYSBw cm94eS4NCg0KPg0KPkNvZGU6ICBJIHRoaW5rIHRoYXQgdGhpcyBpcyBnb2luZyB0byBkZXBlbmQg b24gd2hhdCB0aGUgY29kZSBpcy4gIEZvcg0KPkMtPlJTDQo+bWVzc2FnZXMgYW5kIHByb2JhYmx5 IGZvciBSUy0+QyBzdWNjZXNzIHJlc3BvbnNlcyBpdCBzaG91bGQgYmUgaW50ZWdyaXR5DQo+cHJv dGVjdGVkLiAgRm9yIFJTLT5DIGZhaWx1cmVzLCBpdCB3b3VsZCBiZSBnb29kIHRvIGJlIGludGVn cml0eQ0KPnByb3RlY3RlZC4NCj5Gb3IgUHJveHktPkMgcmVzcG9uc2VzIGl0IG1pZ2h0IG5vdCBi ZSBhYmxlIHRvIGJlIHByb3RlY3RlZC4gIEZvcg0KPk1hbGxvcnktPkMNCj5yZXNwb25zZXMgaXQg d291bGQgbmV2ZXIgYmUgcHJvdGVjdGVkLiAgIERvZXMgQyBkbyBkaWZmZXJlbnQgdGhpbmdzIGlm IGENCj5wcm90ZWN0ZWQgbWVzc2FnZSBpcyBzZW50IGFuZCBhbiB1bnByb3RlY3RlZCBtZXNzYWdl IGlzIHJldHVybmVkPw0KPihBc3N1bWVzDQo+dGhhdCBDIGFsd2F5cyBpbml0aWF0ZXMuKQ0KDQpU aGUgdHdvIE1vZGVzIG1lbnRpb25lZCBhYm92ZSBhZGRyZXNzIHRoaXMgZGlmZmVyZW50bHkuDQoN CkZvciBNb2RlOkNPQVAgYSBjb21wbGlhbnQgbm9kZSByZWNlaXZpbmcgYSBwcm90ZWN0ZWQgcmVx dWVzdCBtdXN0IHNlbmQgYQ0KcHJvdGVjdGVkIHJlc3BvbnNlLCBhbmQgYSBjb21wbGlhbnQgbm9k ZSByZWNlaXZpbmcgdGhlIHJlc3BvbnNlIHZlcmlmeWluZw0KdGhhdCBpdCBtYXRjaGVzIHRoZSBy ZXF1ZXN0LiBJbiB0aGlzIGNhc2UgQ29kZSBpcyBpbnRlZ3JpdHkgcHJvdGVjdGVkLCBzbw0KdGhp cyBtb2RlIGFwcGxpZXMgdG8gdGhlIHVzZSBjYXNlcyB3aGVyZSBpdCBpcyBpbXBvcnRhbnQgdG8g ZGlzdGluZ3Vpc2gNCmUuZy4gR0VUIGZyb20gREVMRVRFIG9yIHdoZXJlIGl0IGlzIGltcG9ydGFu dCB0aGF0IHJlc3BvbnNlIGNvZGVzIGFyZQ0KaW50ZWdyaXR5IHByb3RlY3RlZCB0byBlbnN1cmUg Y29ycmVjdCBvcGVyYXRpb25zIGhhcyBiZWVuIHBlcmZvcm1lZC4NCg0KRm9yIE1vZGU6UEFZTCBv bmx5IHRoZSBwYXlsb2FkIGlzIHByb3RlY3RlZCwgc28gdGhlIGNoYW5nZSBvZiBDb2RlIHNob3Vs ZA0Kbm90IGhhdmUgYSBzZWN1cml0eSBpbXBsaWNhdGlvbi4gSW4gdGhpcyBjYXNlIHRoZXJlIG1h eSBiZSBwcm90ZWN0ZWQNCm1lc3NhZ2UgaW4gb25seSBvbmUgZGlyZWN0aW9uLCBlLmcuIGEgR0VU IHJlc3BvbnNlIGNhY2hlZCBhbmQgZm9yd2FyZGVkIHRvDQpkaWZmZXJlbnQgcmVxdWVzdGluZyBj bGllbnRzLg0KDQo+DQo+TWVzc2FnZSBJRDogIFNob3VsZCBiZSBpbnRlZ3JpdHkgcHJvdGVjdGVk Lg0KDQpNYXkgYmUgY2hhbmdlZCBieSBpbnRlcm1lZGlhcnkuDQoNCj4gDQo+DQo+T3B0aW9uczog IFByb3RlY3Rpb24gZXh0ZW5kZWQgdG8gb3B0aW9ucyBpcyBnb2luZyB0byBiZSBvcHRpb24gYW5k DQo+cG9zc2libHkNCj5kaWFsb2cgc3BlY2lmaWMuDQo+KiAgTm9uZTogIFRoZXJlIGFyZS9tYXkg YmUgb3B0aW9ucyB3aGljaCBhcmUgZXhwZWN0ZWQgdG8gYmUgbW9kaWZpZWQgaW4NCj50cmFuc2l0 LiAgVGhlcmUgYXJlIG9wdGlvbnMgd2hpY2ggbWF5IGJlL2FyZSBleHBlY3RlZCB0byBiZSBpbnNl cnRlZCBpbg0KPnRyYW5zaXQuICBUaGVzZSBvcHRpb25zIGNhbm5vdCBoYXZlIGFueSBzZWN1cml0 eSBwcm90ZWN0aW9uIG9uIHRoZW0NCg0KV2UgZWxhYm9yYXRlIG9uIHRoaXMgaW4gQXBwZW5kaXgg QS4gT25lIGdlbmVyYWwgaW5kaWNhdGlvbiBhcmUgb3B0aW9ucw0KdGhhdCBhcmUgc2FmZS10by1m b3J3YXJkIG1heSBiZSBpbnRlZ3JpdHkgcHJvdGVjdGVkLiBCdXQgZXZlbiBpZiBhbiBvcHRpb24N CmlzIG5vdCBzYWZlLXRvLWZvcndhcmQsIHRoZSBjb250ZW50IG9mIHRoZSBvcHRpb24gbWF5IGJl IGludGVncml0eQ0KcHJvdGVjdGVkLiBUaGUgY3JpdGljYWwgZGlzdGluY3Rpb24gc2VlbXMgdG8g YmUgaWYgYW4gb3B0aW9uIGlzIGNoYW5nZWQgaW4NCmEgcHJlZGljdGFibGUgd2F5IHNvIGl0IGlz IHBvc3NpYmxlIHRvIGRlZmluZSBhbiDigJxpbnZhcmlhbnTigJ0gd2hpY2ggY2FuIGJlDQppbnRl Z3JpdHkgcHJvdGVjdGVkLg0KDQo+DQo+KiAgSW50ZWdyaXR5IE9ubHk6ICBUaGUgb3B0aW9uIGNh biBiZSB2aXNpYmxlIHRvIGludGVydmVuaW5nIGVudGl0aWVzLCBhbmQNCj5pbmRlZWQgbWlnaHQg YmUgcmVxdWlyZWQgdG8gYmUgdmlzaWJsZSBmb3IgdGhlbSB0byBmdW5jdGlvbiBwcm9wZXJseSwg YnV0DQo+dGhlcmUgaXMgYSByZXF1aXJlbWVudCB0aGF0IHRoZSBvcHRpb24gbm90IGJlIGNoYW5n ZWQgYmV0d2VlbiB0aGUgc2VuZGVyDQo+YW5kDQo+dGhlIHJlY2lwaWVudA0KPg0KPiogQ29uZmlk ZW50aWFsIChhbmQgaW50ZWdyaXR5IHByb3RlY3RlZCk6ICBUaGUgb3B0aW9uIGlzIG5vdCB0byBi ZSB2aXNpYmxlDQo+dG8gaW50ZXJ2ZW5pbmcgZW50aXRpZXMuDQoNClllcywgZm9yIGVhY2ggbW9k ZSB0aGVyZSBhcmUgdHdvIGNhc2VzLg0KDQo+DQo+Qm9keTogIERlcGVuZHMgb24gY29udGVudC4g IFdpbGwgZWl0aGVyIGJlIGludGVncml0eSBwcm90ZWN0ZWQgb3INCj5jb25maWRlbnRpYWwgYW5k IGludGVncml0eSBwcm90ZWN0ZWQuDQoNCkFncmVlDQoNCkfDtnJhbg0KDQo+DQo+SmltDQo+DQo+ DQo+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj5BY2Ug bWFpbGluZyBsaXN0DQo+QWNlQGlldGYub3JnDQo+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9hY2UNCg0K From nobody Thu Oct 1 07:22:07 2015 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CA801A6F7F for ; Thu, 1 Oct 2015 07:22:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jctv3yHlkewt for ; Thu, 1 Oct 2015 07:22:03 -0700 (PDT) Received: from mail-lb0-f177.google.com (mail-lb0-f177.google.com [209.85.217.177]) (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 1610C1A6F7B for ; Thu, 1 Oct 2015 07:22:03 -0700 (PDT) Received: by lbos8 with SMTP id s8so10225009lbo.0 for ; Thu, 01 Oct 2015 07:22:01 -0700 (PDT) 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:content-type; bh=PnP3DgxAyxw+RqysDKZgfdxUDdkToOp+m3EgJ5FfBE4=; b=caROy+BVmpzZR0sABOVg0uAMuHxzp6cOFyO7A7dhsP4VPFr4Z1QggSgwAzIlEpN7Fq 3v6f95ZHTfFhnaHenfWJ+9Ol2KASKDIexGpu0yzCgFzBQ1w9DCYu5Ycg+ThB0GkM4OAQ cFl4BNVVmQGfP5HVvfzVC+rV4FHfne+x0eNtgNJslqy+PV1AXXMak+meOK6abWP1xk6N UyWsUbwFP0nqxs8co2rn62L/5OBpSsCmKkrMbW3/coUm84irmOU+biaG/ptEoztJ2z4u 7BHygleBQxK84TC6KHGP8eac6tH20OWZI8kpze/NIxnbk9bIB23iqF7gyYFSLXIqZt/O p3VA== X-Gm-Message-State: ALoCoQlV89s4R3Q0Jk78r9xzIB7IVROyU0TnKx6HaTLbm+5nkknMRR+Q7THAg6rb0fvBBOd0Poj/ X-Received: by 10.25.21.79 with SMTP id l76mr2019558lfi.79.1443709321233; Thu, 01 Oct 2015 07:22:01 -0700 (PDT) Received: from [192.168.0.108] ([85.235.11.178]) by smtp.gmail.com with ESMTPSA id j5sm672909lbq.43.2015.10.01.07.21.59 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 01 Oct 2015 07:22:00 -0700 (PDT) To: ace@ietf.org, sean@sn3rd.com, Kathleen Moriarty References: <0B20F0CA-B84B-4A4B-82E4-D5E87F27D715@sn3rd.com> From: Ludwig Seitz Message-ID: <560D4187.9020500@sics.se> Date: Thu, 1 Oct 2015 16:21:59 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <0B20F0CA-B84B-4A4B-82E4-D5E87F27D715@sn3rd.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms020304020008040701040606" Archived-At: Subject: Re: [Ace] Second WGLC for draft-ietf-ace-usecases-05/6 X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 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, 01 Oct 2015 14:22:06 -0000 This is a cryptographically signed message in MIME format. --------------ms020304020008040701040606 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable Hello Sean, thank you for your comments and the especially the detailed suggested=20 updates you provided. Some comments inline. @Kathleen: One comment specifically relates to some text you suggested=20 earlier, could you comment on this? (search for your name in the text). Regards, Ludwig On 2015-09-30 22:04, Sean Turner wrote: [...] > 7) s2.1: I=E2=80=99m not sure why it=E2=80=99s necessary to include val= ue judgements: > =E2=80=9Cit=E2=80=99s not easy=E2=80=9D and =E2=80=9Cespecially challen= ging": > > OLD: > > The proper handling of the sensors in this scenario is not easy to > accomplish. They have to be associated to the appropriate pallet of > the respective container. Moreover, the goods and the corresponding > sensors belong to specific customers. > > NEW: > > Sensors in this scenario have to be associated to the appropriate > pallet of the respective container. Sensors as well as the goods to > specific customers. > I agree with the first part, however the second part of your suggestion does not sound like a complete sentence to me. Perhaps if we add a 'belong' somewhere? > The Intelligent Container (http://www.intelligentcontainer.com) is > an example project that continuously monitors perishable goods. > This sounds like the project itself that is montioring the goods. Perhaps rephrase this to "... project that explores solutions to continuously monitor perishable goods."? > 17) (no action required) s2.3.1: I figured =E2=80=9CHeartGuard=E2=80=9D= had to > trademarked because I hear about it all the time - nope it=E2=80=99s be= cause > we give =E2=80=9Cheartgard=E2=80=9D to my dog to prevent roundworms, th= readworms, > etc. ;) > I actually made that name up to refer to the device with something shorter that "the thing that measures John's heart rate". > 18) s2.3.2 U.3: The impact of security on battery lifetimes is > specially called out and maybe that=E2=80=99s appropriate given the doc= ument. > But, isn=E2=80=99t the requirement really that non-health-related impac= ts on > battery life be minimized to cut down on the amount of > charging/replacing the battery? I mean if the device is tweeting out > it=E2=80=99s location and firing off a charge to keep my heart beating = when > the batter gets low I sure hope it stops tweeting and keeps on firing > off signals to the heart. Might I humbly suggest: > > U3.3 Battery changes are very inconvenient and sometimes impractical > so battery life impacts need to be minimized. > The section is supposed to list specific authorization problems and I=20 feel that aspect is lost with your proposal. How about this: U3.3 Battery changes are very inconvenient and sometimes impractical so=20 battery life impact of the authorization mechanisms need to be minimized.= > 21) s2.5.1: r/end customer=E2=80=99s/customer=E2=80=99s > Doesn't that make it easier to misunderstand? The utility companies are after all also customers of the service operato= r. > > 25) s2.6.1: (being pc today): r/girls/women Steffi wrote that section, honestly! > 32) s3.1: Without an example of what part of DTLS you=E2=80=99re talkin= g > about maybe we could generalize this a bit :) > > OLD: > > Denial of service (DoS) attacks threaten the availability of > services a device provides. E.g., an attacker can induce a device to > perform steps of a heavy weight security protocol (e.g. Datagram > Transport Layer Security (DTLS) [RFC6347]) before authentication and > authorization can be verified, thus exhausting the device's system > resources. This leads to a temporary or - e.g. if the batteries are > drained - permanent failure of the service. For some services of > constrained devices, availability is especially important (see > Section 2.3). Because of their limitations, constrained devices are > especially vulnerable to denial of service attacks. Solution > designers must be particularly careful to consider these limitations > in every part of the protocol. This includes: > > NEW: > > Denial of service (DoS) attacks threaten the availability of > services a device provides and constrained devices are especially > vulnerable to these types of attacks because of their limitations. > Attackers can illicit a temporary or if the battery is drained a > permanent failure service simply by repeatedly flooding the device > with connection attempts; for some services (see Section 2.3), > availability is especially important. Solution designers must be > particularly careful to consider the following limitations in every > part of the protocol: > > The focus shifts somewhat with your suggestion, what I tried to point=20 out here was that especially the security protocols can offer a=20 convenient avenue for DoS attacks. Perhaps this change to your suggested change makes that clearer: "Solution designers must be particularly careful to consider the=20 following limitations in every part of the authorization solution." 33) s3.2: Add =E2=80=9CTimers for transaction processing=E2=80=9D I mean = a simple > attack is start transaction, wait[0], ... wait[n], fail. > I assume you mean section 3.1 here not 3.2 right? > 34) s3.2: The last paragraph, aren't we really worried about > unauthorized disclosure and spoofing? You can intercept as many > encrypted sessions as you want and you can eavesdrop on as many > sessions that don=E2=80=99t require confidentiality as you want. I rea= lly > think what you=E2=80=99re trying to say is that the sessions need to be= > appropriately protected: > > OLD: > > Another category of attacks that needs to be considered by solution > developers is session interception and hijacking. > > NEW: > > Solution developers also need to consider whether the session should > be protected from information disclosure and spoofing. > Same here you do mean 3.1 right? Also the part on session interception=20 and hijacking was specifically requested by Kathleen. I'm not sure if=20 your edit captures her intent. > 35) s3.2 & s3.3) r/(see e.g./(see > > 36) s3.3: You=E2=80=99ve convinced me, we need to take care for almost = all > cases involving untrained humans (my mum included): r/home > scenarios/scenarios > --=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 http://www.sics.se --------------ms020304020008040701040606 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 DFQwggYYMIIFAKADAgECAgMMhpgwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYw FAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZp Y2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJt ZWRpYXRlIENsaWVudCBDQTAeFw0xNTAxMDgwODM5MDZaFw0xNjAxMDkyMjQxMzBaMDgxFzAV BgNVBAMMDmx1ZHdpZ0BzaWNzLnNlMR0wGwYJKoZIhvcNAQkBFg5sdWR3aWdAc2ljcy5zZTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMVB4rAuq4FxbARxwRqPLpc/3C194F+V H4XMKK6fu3Y8zDLijzNSjh6tG41oZhXvJcvAs1nZNjUutNLeyBAUFiYhy7HXNdlKpjbMEFKQ +6KpEdZ0Rk+pXgB2E1mqZEfp3M2djcQ/h+7uGVlSGYNAxYk6rWPIIWBx2GMvAQaHP4xxu/F+ PiSQILOVzmtIFZe1t/Lw71aaNeMYVhARo8z5PVsVoq6gBeujxfiRLtiQ/S8xW6RKvNvUkVyT BQfcKaEDZR9FENNf9rFgiAcT6R7hI8RBf1d2fxdlbDU8uM72K3fvzGDt8N9Bfm1kDWbDBxJE 1taRIYs+60D1kwV6DvBb9MECAwEAAaOCAtQwggLQMAkGA1UdEwQCMAAwCwYDVR0PBAQDAgSw MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAdBgNVHQ4EFgQU6ryrKahJtBOEdbIL AAWCpOsQyagwHwYDVR0jBBgwFoAUU3Ltkpzg2ssBXHx+ljVO8tS4UYIwGQYDVR0RBBIwEIEO bHVkd2lnQHNpY3Muc2UwggFMBgNVHSAEggFDMIIBPzCCATsGCysGAQQBgbU3AQIDMIIBKjAu BggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjCB9wYIKwYB BQUHAgIwgeowJxYgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwAwIBARqBvlRo aXMgY2VydGlmaWNhdGUgd2FzIGlzc3VlZCBhY2NvcmRpbmcgdG8gdGhlIENsYXNzIDEgVmFs aWRhdGlvbiByZXF1aXJlbWVudHMgb2YgdGhlIFN0YXJ0Q29tIENBIHBvbGljeSwgcmVsaWFu Y2Ugb25seSBmb3IgdGhlIGludGVuZGVkIHB1cnBvc2UgaW4gY29tcGxpYW5jZSBvZiB0aGUg cmVseWluZyBwYXJ0eSBvYmxpZ2F0aW9ucy4wNgYDVR0fBC8wLTAroCmgJ4YlaHR0cDovL2Ny bC5zdGFydHNzbC5jb20vY3J0dTEtY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEF BQcwAYYtaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczEvY2xpZW50L2NhMEIG CCsGAQUFBzAChjZodHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MxLmNs aWVudC5jYS5jcnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqG SIb3DQEBBQUAA4IBAQBl8BbG0n7+JjFqiJOuAqMbkeqM6Oyd+4oHGu3fbaSiM1SKesae2bfm vifV99a+M4DERZ2SVkOYcvNlv31Q3hvYtzRjDOqewzVKxo021R3ddQULW1DhvTEpclikG5rd 0NRJQn+EkSwEKLeUj68i0dhU8ULhZDDq3A81cTcZzIGrTjNnwDvCktB/sF/iO4At6RJ24P3j KjYFPirW3NsvZ2gzZizSzeubPE0/cWcqEBJ/UtaFPF54efejjLuPRHHMLPDcvrwBhEiBxuG6 oTEo465g4pS9Vo/Z0GoZgZyA+aGQ+YPbPSsqsYmSBjZ6MGGDqQq0niE2dW+8IOdHQvMkqI52 MIIGNDCCBBygAwIBAgIBHjANBgkqhkiG9w0BAQUFADB9MQswCQYDVQQGEwJJTDEWMBQGA1UE ChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUg U2lnbmluZzEpMCcGA1UEAxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwHhcN MDcxMDI0MjEwMTU1WhcNMTcxMDI0MjEwMTU1WjCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoT DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUg Q2xpZW50IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAxwmDzM4t2BqxKaQu E6uWvooyg4ymiEGWVUet1G8SD+rqvyNH4QrvnEIaFHxOhESip7vMz39ScLpNLbL1QpOlPW/t FIzNHS3qd2XRNYG5Sv9RcGE+T4qbLtsjjJbi6sL7Ls/f/X9ftTyhxvxWkf8KW37iKrueKsxw 2HqolH7GM6FX5UfNAwAu4ZifkpmZzU1slBhyWwaQPEPPZRsWoTb7q8hmgv6Nv3Hg9rmA1/VP BIOQ6SKRkHXG0Hhmq1dOFoAFI411+a/9nWm5rcVjGcIWZ2v/43Yksq60jExipA4l5uv9/+Hm 33mbgmCszdj/Dthf13tgAv2O83hLJ0exTqfrlwIDAQABo4IBrTCCAakwDwYDVR0TAQH/BAUw AwEB/zAOBgNVHQ8BAf8EBAMCAQYwHQYDVR0OBBYEFFNy7ZKc4NrLAVx8fpY1TvLUuFGCMB8G A1UdIwQYMBaAFE4L7xqkQFulF2mHMMo0aEPQQa7yMGYGCCsGAQUFBwEBBFowWDAnBggrBgEF BQcwAYYbaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL2NhMC0GCCsGAQUFBzAChiFodHRwOi8v d3d3LnN0YXJ0c3NsLmNvbS9zZnNjYS5jcnQwWwYDVR0fBFQwUjAnoCWgI4YhaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vc2ZzY2EuY3JsMCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNv bS9zZnNjYS5jcmwwgYAGA1UdIAR5MHcwdQYLKwYBBAGBtTcBAgEwZjAuBggrBgEFBQcCARYi aHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEFBQcCARYoaHR0cDov L3d3dy5zdGFydHNzbC5jb20vaW50ZXJtZWRpYXRlLnBkZjANBgkqhkiG9w0BAQUFAAOCAgEA CoMIfXirLAZcuGOMXq4cuSN3TaFx2H2GvD5VSy/6rV55BYHbWNaPeQn3oBSU8KgQZn/Kck1J xbLpAxVCNtsxeW1R87ifhsYZ0qjdrA9anrW2MAWCtosmAOT4OxK9QPoSjCMxM3HbkZCDJgnl E8jMopH21BbyAYr7b5EfGRQJNtgWcvqSXwKHnTutR08+Kkn0KAkXCzeQNLeA5LlYUzFyM7kP Ap8pIRMQ+seHunmyG642S2+y/qHEdMuGIwpfz3eDF1PdctL04qYK/zu+Qg1Bw0RwgigVZs/0 c5HP2/e9DBHh7eSwtzYlk4AUr6yxLlcwSjOfOmKEQ/Q8tzh0IFiNu9IPuTGAPBn4CPxD0+Ru 8T2wg8/s43R/PT3kd1OEqOJUl7q+h+r6fpvU0Fzxd2tC8Ga6fDEPme+1Nbi+03pVjuZQKbGw KJ66gEn06WqaxVZC+J8hh/jR0k9mST1iAZPNYulcNJ8tKmVtjYsv0L1TSm2+NwON58tO+pIV zu3DWwSEXSf+qkDavQam+QtEOZxLBXI++aMUEapSn+k3Lxm48ZCYfAWLb/Xj7F5JQMbZvCex glAbYR0kIHqW5DnsYSdMD/IplJMojx0NBrxJ3fN9dvX2Y6BIXRsF1du4qESm4/3CKuyUV7p9 DW3mPlHTGLvYxnyKQy7VFBkoLINszBrOUeIxggPtMIID6QIBATCBlDCBjDELMAkGA1UEBhMC SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENl cnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJ bnRlcm1lZGlhdGUgQ2xpZW50IENBAgMMhpgwDQYJYIZIAWUDBAIBBQCgggIpMBgGCSqGSIb3 DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE1MTAwMTE0MjE1OVowLwYJKoZI hvcNAQkEMSIEIOrlaMfMSjN787ljTDtkXYq2ebDnvyRkC/d0JzOAyFmiMGwGCSqGSIb3DQEJ DzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0D AgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgaUGCSsGAQQB gjcQBDGBlzCBlDCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzAp BgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0 YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgMMhpgwgacG CyqGSIb3DQEJEAILMYGXoIGUMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20g THRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG A1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EC AwyGmDANBgkqhkiG9w0BAQEFAASCAQAVVeAUpuwhu/Vi06U5vtJUbx35FHr9ncT76z5+NrPV kEXmxG/w0vGQXcyVLgWNMCTJXMm9XP4LMYChOc8anSOp0LuUqsoKz5fftQOrmlqvpMzfKs8o ZoNkj64fyCtfFs7TuYcZoXsy0Hs3Scrq73RPH4cfkN4jUpvsPvrvi8WU4GcjXxrW7cG0j3ZL 0fyjOv32eLV8pkpUgaOmdIry+sK6dPvgw21ZBxZ6o74Pircz4/H5Nw8DysyUSaS31LGKyP0D ptyoBHtC74nt5h3wIoaISriyyRY8YPUh+ERnuqwXy3rLpr8zzELjQIQSvML6jJ47UkyU1SBu TdwOEak4XXnCAAAAAAAA --------------ms020304020008040701040606-- From nobody Thu Oct 1 08:22:56 2015 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27EBB1B2D19 for ; Thu, 1 Oct 2015 08:22:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rOqqrYV3wv_g for ; Thu, 1 Oct 2015 08:22:53 -0700 (PDT) Received: from mail-wi0-x232.google.com (mail-wi0-x232.google.com [IPv6:2a00:1450:400c:c05::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 991CA1B2A0C for ; Thu, 1 Oct 2015 08:22:52 -0700 (PDT) Received: by wiclk2 with SMTP id lk2so38997753wic.0 for ; Thu, 01 Oct 2015 08:22:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=vNQc1ChrFUgq75PyBXF286KYla3J9IM1m6gX9G7VzzQ=; b=NKydsqkc3xE1GPKjP/a3o/U5Rn6vpA6WcVturji7Irq7f7qKB1ZBvWtnXmsHNWW6Lg Jht9Oy0Eyw+AoAFK2yQdQEhWAWtVAGaQr5CMQ+X6si9x1/wFDNgh84xviAubPZtaycYK UL44IEmU0dQVmwU0PEsL+ue9jYgaa6FoS1N4fk7jlx2VmS0N/VjORFqoABN/5d8ygD/G 6QvZ0/rSHzPTvz7m+Bgv8jUd86tV+m4eu00oIsCjNr7lTvAV63UlXv5tU2w/wRUoQjXi ffQyRzTGkbSa3z+N8tycXGfuNof+hkh8hOwCljC93jj8byrMAtyDJU6Zuazqx4d5hlvr dacA== MIME-Version: 1.0 X-Received: by 10.180.75.38 with SMTP id z6mr3735298wiv.36.1443712971139; Thu, 01 Oct 2015 08:22:51 -0700 (PDT) Received: by 10.28.214.213 with HTTP; Thu, 1 Oct 2015 08:22:50 -0700 (PDT) In-Reply-To: <560D4187.9020500@sics.se> References: <0B20F0CA-B84B-4A4B-82E4-D5E87F27D715@sn3rd.com> <560D4187.9020500@sics.se> Date: Thu, 1 Oct 2015 11:22:50 -0400 Message-ID: From: Kathleen Moriarty To: Ludwig Seitz Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: sean@sn3rd.com, "ace@ietf.org" Subject: Re: [Ace] Second WGLC for draft-ietf-ace-usecases-05/6 X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 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, 01 Oct 2015 15:22:55 -0000 Thanks for addressing these additional comments quickly. I've tentatively put this on the 10/22 telechat so we can wrap it up before the next meeting. If a new version is ready today, I could put it on the 10/15 instead. I'll respond to the one comment inline, thanks for noting my previous text request. On Thu, Oct 1, 2015 at 10:21 AM, Ludwig Seitz wrote: > Hello Sean, > > thank you for your comments and the especially the detailed suggested > updates you provided. > > Some comments inline. > > @Kathleen: One comment specifically relates to some text you suggested > earlier, could you comment on this? (search for your name in the text). > > Regards, > > Ludwig > > > On 2015-09-30 22:04, Sean Turner wrote: > [...] > >> 7) s2.1: I=E2=80=99m not sure why it=E2=80=99s necessary to include valu= e judgements: >> =E2=80=9Cit=E2=80=99s not easy=E2=80=9D and =E2=80=9Cespecially challeng= ing": >> >> OLD: >> >> The proper handling of the sensors in this scenario is not easy to >> accomplish. They have to be associated to the appropriate pallet of >> the respective container. Moreover, the goods and the corresponding >> sensors belong to specific customers. >> >> NEW: >> >> Sensors in this scenario have to be associated to the appropriate >> pallet of the respective container. Sensors as well as the goods to >> specific customers. >> > I agree with the first part, however the second part of your suggestion > does not sound like a complete sentence to me. Perhaps if we add a > 'belong' somewhere? > > > >> The Intelligent Container (http://www.intelligentcontainer.com) is >> an example project that continuously monitors perishable goods. >> > > This sounds like the project itself that is montioring the goods. > Perhaps rephrase this to "... project that explores solutions to > continuously monitor perishable goods."? > > >> 17) (no action required) s2.3.1: I figured =E2=80=9CHeartGuard=E2=80=9D = had to >> trademarked because I hear about it all the time - nope it=E2=80=99s bec= ause >> we give =E2=80=9Cheartgard=E2=80=9D to my dog to prevent roundworms, thr= eadworms, >> etc. ;) >> > > I actually made that name up to refer to the device with something > shorter that "the thing that measures John's heart rate". > > >> 18) s2.3.2 U.3: The impact of security on battery lifetimes is >> specially called out and maybe that=E2=80=99s appropriate given the docu= ment. >> But, isn=E2=80=99t the requirement really that non-health-related impact= s on >> battery life be minimized to cut down on the amount of >> charging/replacing the battery? I mean if the device is tweeting out >> it=E2=80=99s location and firing off a charge to keep my heart beating w= hen >> the batter gets low I sure hope it stops tweeting and keeps on firing >> off signals to the heart. Might I humbly suggest: >> > > >> U3.3 Battery changes are very inconvenient and sometimes impractical >> so battery life impacts need to be minimized. >> > > The section is supposed to list specific authorization problems and I fee= l > that aspect is lost with your proposal. > > How about this: > U3.3 Battery changes are very inconvenient and sometimes impractical so > battery life impact of the authorization mechanisms need to be minimized. > > >> 21) s2.5.1: r/end customer=E2=80=99s/customer=E2=80=99s >> > > Doesn't that make it easier to misunderstand? > > The utility companies are after all also customers of the service operato= r. > > >> >> 25) s2.6.1: (being pc today): r/girls/women > > > Steffi wrote that section, honestly! > > > >> 32) s3.1: Without an example of what part of DTLS you=E2=80=99re talking >> about maybe we could generalize this a bit :) >> >> OLD: >> >> Denial of service (DoS) attacks threaten the availability of >> services a device provides. E.g., an attacker can induce a device to >> perform steps of a heavy weight security protocol (e.g. Datagram >> Transport Layer Security (DTLS) [RFC6347]) before authentication and >> authorization can be verified, thus exhausting the device's system >> resources. This leads to a temporary or - e.g. if the batteries are >> drained - permanent failure of the service. For some services of >> constrained devices, availability is especially important (see >> Section 2.3). Because of their limitations, constrained devices are >> especially vulnerable to denial of service attacks. Solution >> designers must be particularly careful to consider these limitations >> in every part of the protocol. This includes: >> >> NEW: >> >> Denial of service (DoS) attacks threaten the availability of >> services a device provides and constrained devices are especially >> vulnerable to these types of attacks because of their limitations. >> Attackers can illicit a temporary or if the battery is drained a >> permanent failure service simply by repeatedly flooding the device >> with connection attempts; for some services (see Section 2.3), >> availability is especially important. Solution designers must be >> particularly careful to consider the following limitations in every >> part of the protocol: >> >> > > The focus shifts somewhat with your suggestion, what I tried to point out > here was that especially the security protocols can offer a convenient > avenue for DoS attacks. > > Perhaps this change to your suggested change makes that clearer: > > "Solution designers must be particularly careful to consider the followin= g > limitations in every part of the authorization solution." > > > 33) s3.2: Add =E2=80=9CTimers for transaction processing=E2=80=9D I mean = a simple >> >> attack is start transaction, wait[0], ... wait[n], fail. >> > > I assume you mean section 3.1 here not 3.2 right? > > >> 34) s3.2: The last paragraph, aren't we really worried about >> unauthorized disclosure and spoofing? You can intercept as many >> encrypted sessions as you want and you can eavesdrop on as many >> sessions that don=E2=80=99t require confidentiality as you want. I real= ly >> think what you=E2=80=99re trying to say is that the sessions need to be >> appropriately protected: >> >> OLD: >> >> Another category of attacks that needs to be considered by solution >> developers is session interception and hijacking. >> >> NEW: >> >> Solution developers also need to consider whether the session should >> be protected from information disclosure and spoofing. >> > > Same here you do mean 3.1 right? Also the part on session interception an= d > hijacking was specifically requested by Kathleen. I'm not sure if your ed= it > captures her intent. Information disclosure is the problem that is possible from both session interception (passive) and hijacking. Sessions could also be altered, so that is not covered by the new text, but the terms are better than what I had as they get to the problem as opposed to attack types. Spoofing is also more of an attack type. How about: Solution developers also need to consider whether the session should be protected from information disclosure and tampering. I think that covers active attacks and Sean's spoofing addition. Sean, if you can think of a better term, please do suggest one or two. Thanks, Kathleen > >> 35) s3.2 & s3.3) r/(see e.g./(see >> >> 36) s3.3: You=E2=80=99ve convinced me, we need to take care for almost a= ll >> cases involving untrained humans (my mum included): r/home >> scenarios/scenarios >> > > -- > 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 > http://www.sics.se > --=20 Best regards, Kathleen From nobody Thu Oct 1 08:29:20 2015 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3AD5F1B2D24 for ; Thu, 1 Oct 2015 08:29:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.799 X-Spam-Level: X-Spam-Status: No, score=0.799 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kfR6EEqQ12aA for ; Thu, 1 Oct 2015 08:29:12 -0700 (PDT) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0722.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::722]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1E6901AC42D for ; Thu, 1 Oct 2015 08:29:10 -0700 (PDT) Received: from DB4PR06CA0012.eurprd06.prod.outlook.com (10.160.40.140) by DB4PR06MB160.eurprd06.prod.outlook.com (10.242.155.155) with Microsoft SMTP Server (TLS) id 15.1.280.20; Thu, 1 Oct 2015 15:28:49 +0000 Received: from DB3FFO11FD018.protection.gbl (2a01:111:f400:7e04::156) by DB4PR06CA0012.outlook.office365.com (2a01:111:e400:9851::12) with Microsoft SMTP Server (TLS) id 15.1.286.20 via Frontend Transport; Thu, 1 Oct 2015 15:28:49 +0000 Authentication-Results: spf=fail (sender IP is 146.108.200.10) smtp.mailfrom=tridonic.com; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=tridonic.com; Received-SPF: Fail (protection.outlook.com: domain of tridonic.com does not designate 146.108.200.10 as permitted sender) receiver=protection.outlook.com; client-ip=146.108.200.10; helo=ATBRAGMSX01.itiso.net; Received: from ATBRAGMSX01.itiso.net (146.108.200.10) by DB3FFO11FD018.mail.protection.outlook.com (10.47.217.49) with Microsoft SMTP Server (TLS) id 15.1.274.4 via Frontend Transport; Thu, 1 Oct 2015 15:28:48 +0000 Received: from ATBRAGMSX02.itiso.net ([169.254.2.75]) by ATBRAGMSX01.itiso.net ([146.108.41.69]) with mapi id 14.03.0248.002; Thu, 1 Oct 2015 17:28:48 +0200 From: Somaraju Abhinav To: "Ace@ietf.org" Thread-Topic: [ACE] review draft-ietf-ace-usecases-06 Thread-Index: AdD8XTFdDVkUObPhQvi/FvrOxuHgzQ== Date: Thu, 1 Oct 2015 15:28:48 +0000 Message-ID: <0E9A48AB39AF3547ACD28A6DE3E2906A0AB169@ATBRAGMSX02.itiso.net> Accept-Language: en-US, de-AT Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [146.108.41.149] Content-Type: multipart/alternative; boundary="_000_0E9A48AB39AF3547ACD28A6DE3E2906A0AB169ATBRAGMSX02itison_" MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Microsoft-Exchange-Diagnostics: 1; DB3FFO11FD018; 1:pCc2O37InOdsoeHPBgkESI5ZA+2wg/V3JBqz4sJp9RJv0ztVMBgl7WyHJAIr+hw6IOBTKM6XMS50cLXI1zH/o1xzxxPx/rovjnhPCGKIqeoIskGqmcsn1hq8BPsmtuK7Sw6XyfMYaJN24uOsORcRDnBzEQ0DCL2jyJN2XKmmBfaYi23+jH78D6fnHhkwuPP3MJp6Oj99hTUYCGSRMLk9vLwHT3ZzRIwkG+/a0eVG3JHjbYeSWUr4+VR8Fd6r2kWlqVAqmHL0XPan1wAufx/D1P9Kum9UjjUACwihEKd5N/PPqcuCnh+ZymGkobKUddlpcSNz7VReS7O3LAyuJrgNPA== X-Forefront-Antispam-Report: CIP:146.108.200.10; CTRY:AT; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(2980300002)(1110001)(1109001)(339900001)(53754006)(199003)(189002)(54356999)(53416004)(6806005)(104016004)(2930100002)(5001960100002)(5004730100002)(450100001)(189998001)(62966003)(86362001)(92566002)(46102003)(5003600100002)(5001860100001)(5890100001)(5007970100001)(77156002)(84326002)(55846006)(69596002)(2501003)(110136002)(85426001)(107886002)(64706001)(229853001)(230783001)(50986999)(19300405004)(19625215002)(5008740100001)(26826002)(19580395003)(33656002)(5001830100001)(81156007)(105606002)(16236675004)(2900100001)(2920100001)(87936001)(66066001)(15975445007)(102836002)(2351001)(512954002)(106466001)(11100500001)(4001540100001); DIR:OUT; SFP:1102; SCL:1; SRVR:DB4PR06MB160; H:ATBRAGMSX01.itiso.net; FPR:; SPF:Fail; PTR:unknown.zgrp.net; A:1; MX:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; DB4PR06MB160; 2:cZvreK3pu5vcOw7cnf/kAC1kPyIou7TfrX00Ez8Wy9Vjcm4A0D5EP6mj+CRws19VEsWOOHHVCqtfY0lhzoxfamdndwHDwVGO2FBSK1XDy9yPMGIqJz4Yo7Af/zxl6tyUwB9MqCZElRw8esbwJcHWikAcN+R+Y6eFPRD+d02FXqA=; 3:QoIhEFosukBMna0UoWwmWVC23MeNHq+1DhW2bPeowpgV5PfHm44jhKBuT6MVXIgoDIUEekq4hXMsd0fjGuAWOm93g6W5ryWtnzihUXJUBUHej+SqBqv9RnBV4iVGMtG7CYlQgt/FZly6yYlYibxJh1b93iWikVX8JvRJSgptsSaT0XfR7XjytOWIVwmxJm0sR51vFcl/gCoA43usapiwfX2E+I7+eTf7lRARUtpnMlLx6pAkwjnJK+cO8+fSF/cz; 25:abIpucofaJUJ9fuqGzViAiXBCeKxi14JBE/epAozc/m/FguqPO/aU+fbMCJA9Bdqha/iVSFSFPrvA/CKvbtKR8uXxr/UTTi0M3nl4ZqFRVzUCEa4GzbKCn9n8bS6UT7xgZam7nFTfVLnUG50wTsoSU+eRPp1ZQX/iqgPsA7Ft91wzvgDEJBWbO2PiuShgj2Tk9Cb2S6Hjev1UtrP4+r0LCk9XBlYChRBLvNil+CIs0mjBdtx4coFRkFXsjU+Tu1gQdfEr1RX/qN40M9Z/x0s0A== X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DB4PR06MB160; X-Microsoft-Exchange-Diagnostics: 1; DB4PR06MB160; 20:G/kG29ko94nAPA3k6yoRxJQxXQCqzdWVajBNQK65JODp8/iKQ0Qh3+9ca9XdJ+G5AV83xTF1HnTKF2nui6shBmHakgqCGmjK9n13tO54MVyPbOB+fEQNdHNyecMl+op1T3oQa/+j7dJyxStQZV8yE7bKrHbFE6sPuqMe9RRGW48kLzbYUiO6rAdKr+ifNTK3fex+eRlIdCDMMA9Chlr9ikcGLmkMYHe8sOXK7C/VldPX5Y31QXeSiY+mcf7sHM4k5PPOfJ3cSVjJ4sHI/F1fAmhG9eUTMfSgQZKfick3EZqDdhT71JuyJVl79iXOuru/qDV+mu7bzFGms762qW6ZZkUUIOMlwMGjMQYSHKDvEMxH+ZXPghmOiq3AdX7TrYR6vU7ASfx0r3qtRBuDkG9/Aqaa0ceCpmJJtFnyy8Og9yNAjZ1fFh5YDP893z0hQIfyp7fz4O9uznNpYqmBeJ3571q7Nxwhu8Ni6cf2nrmo9Mwp2ZNYzK+Zqg8/a0Wa2C8G; 4:UXG4tFfX3LgtmNMgTIDz+Xws0YMdWPlIlyO92EXu+v3VHCWhdeh0a1o7pliug5A60IwUnE+haRNEkwAsApccxdhGQNVhg/BlilrRwhEjhYS2L3g1bZDxRGXuW+njzej/wlbRe8okKUnIIdwHU+FZf73TtkMvAdV+W+GuqURwoPEtPcbP4/AY63H3P2xrCU1cN16IQzN42DVleeXLtXuOT3cyc+Xx8nxU3vuPqFRhVe8uDGSA9NgMAVNoIsz6LqbkgWCW+nPTvOdD7k6jTuzMzfMdSCJ4tpjLrQKe1xEOhRmTFx38YWD92yWw+jqELn67G+diyerE4TonzVvUApK0QClw5/M2wxzFiqVVPRRFSXM= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(108003899814671); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(520078)(3002001); SRVR:DB4PR06MB160; BCL:0; PCL:0; RULEID:; SRVR:DB4PR06MB160; X-Forefront-PRVS: 0716E70AB6 X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; DB4PR06MB160; 23:biQASPRUKQ9HvqnIF2Z3Lr/Vf7t9hMmTewneMe3Cs5?= =?us-ascii?Q?W3H9szVr51CAI5LtgjniVNGfTnstg5mqacUjYtzym+rm9E0WHYznY+QnLFTy?= =?us-ascii?Q?spmA76Afg9k56PlTOgyK57SaKBApRiZfTfJ+LOxVBQDr1qfanyHs5EoyzKuF?= =?us-ascii?Q?EqGiFGKR0rFpxSgV2JmwJlqLjQKCCJDz6/Tt59aSFv9S1AGYKJNZyDLDZPQb?= =?us-ascii?Q?fM8JBI8+Hj37juqY0l00FuPZLQieh79TmuTsn12U20tIZWXKN6ie3v5TUfHC?= =?us-ascii?Q?xPVNoBS97Wf/51nmUasWWhAAipmpktEODvcW86SW6/Ywd/J9yFhDb+CBXFBJ?= =?us-ascii?Q?kXugQO/eC5pKsn+tArKM0xlDfC8XsMuuRKTqid7pAGO8QlR2zUgYH+VePZxo?= =?us-ascii?Q?H6Bgwo3HC0T+xVR547wjKdH4C3lI8vkgFlI5HO2mbskF3dx3VD+Y0lxe84Ou?= =?us-ascii?Q?5gxWV1gl5CYb/q0CWWuRbxP8D5u7TMhSVHx3isnh2WN9Tl1zla9feY56ih4d?= =?us-ascii?Q?1kGCJ+5iykFzU5UMihu/Gs8HoXCKjWtx/gJk01/2JTOgl8FJRQikFSNxzAvn?= =?us-ascii?Q?BJ1F/nAIAt19sv1polsskGlgritWDoXu8dMlEeE1Be9UcFeL1Gt1VNd/O6/r?= =?us-ascii?Q?o/oArn1dAv+PHH1x22Jtq3JLFcabYUov4ZvltAFmLIj1El1e/nlYP4q87CPa?= =?us-ascii?Q?2HEo88eFc/S7vqC5a1PJoBkpGW+8TkqZ5IJ4Ul8qO5HRhqnEwpJ+4iN999nr?= =?us-ascii?Q?Fv0VDXPya7vx0QR6aJESQW9MrICqXIFQtF40EKfM9opvMEQssTHuTbkl1uVF?= =?us-ascii?Q?uxkWlRijByFBXoo5zyfhhzOqKeH5Tj6/OQMzL4ba0cfLxkKxFCjh7GLt0kun?= =?us-ascii?Q?AbZOWLMDZfIis2h53iAeWlp0E6pAkG5XJniQ53s7JEQLAuJClfXNv0MR09Oy?= =?us-ascii?Q?AYSwlP6fQ7YBwVAZtkrR43Pv9U51Melycc8hTev75R9JLvI5021XMQt3EEeC?= =?us-ascii?Q?etXGLti5f1p1xkAZ4XeczruiCfSMlrhv7EnhUXrXy/KGDtPoG4AjdK46y6iL?= =?us-ascii?Q?bl2H+1aPKzhdSNs2JNR0Kaf1n1Ashiu0zhxZBICplDv4QAuZjV1RQWq4tNml?= =?us-ascii?Q?C4bYwFToOS1GTJmU0Seqj5FpRQj2wU5WjT1cAPZAnc6biPjR4IkL7mp9nAz7?= =?us-ascii?Q?e41BdZ76zUjF8u95YAtSenwXr3MFnsbx5Dwwk3blRfSNZwoXO5PB3+Uf1lId?= =?us-ascii?Q?4w42wdjIr9oOnnfbvuK2g52CH5PAbqOkXir5+iOWTDdjxileNVxY2akd5z2u?= =?us-ascii?Q?jmzcIBZwEY2yjBkTNpuYhl2jQTipy50SnTe0I5T2lk0Owj747C9aKO9zLk4N?= =?us-ascii?Q?PxzrzNy4njE3CJ9A0zaocNDVj99jdwn9MwAZ5jl0GWY0prRWrkm2OE2e5OLp?= =?us-ascii?Q?juHkVbM2C4Cm/mNtMGhfR+de3JX2GM2ogjixrcTFlgq7Fj1kHwLU8cgJsfHf?= =?us-ascii?Q?IHi8APA67X1JGF7zq2LeAZwtMpVSguCTiUZvH7BDSmwGAD2yS6zMPv8rkl0R?= =?us-ascii?Q?UsfVnyTmjwK7EVzg=3D=3D?= X-Microsoft-Exchange-Diagnostics: 1; DB4PR06MB160; 5:b42OX7XeS2/jXkmSzwf3gUNnCTQDhxNq/QtKSVrL1bnoUAr47H637yL8IlwkiuwKOKoRNeX9ng1wM3GwODPmrn111denXv1yeoqrLyRS2UBDO2mXixdfUxrqfbP6JfuNyX2PYCwUUPlIGEqi9QrZpA==; 24:LCiRschEjMqqgVXjH8cswWi350leT7wGOVAoq7wlSk6Uq3/S/s2MsVU4mScSXQq3RMTn6r3WaznrA1DQ7OkpY+CORHzhTZprp4r53GIE4pY=; 20:i9zLNKraCajNJ6Nq123FWfnvSNTjMTd8rciD7MXgupfNy+hX02mzSyU88CNLJqSAHuHz0xcIwNnUkbf19edB7w== SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: tridonic.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 01 Oct 2015 15:28:48.9211 (UTC) X-MS-Exchange-CrossTenant-Id: 8b206608-a593-4ace-a4b6-ef1fc83c9169 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=8b206608-a593-4ace-a4b6-ef1fc83c9169; Ip=[146.108.200.10]; Helo=[ATBRAGMSX01.itiso.net] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB4PR06MB160 Archived-At: Subject: [Ace] [ACE] review draft-ietf-ace-usecases-06 X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 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, 01 Oct 2015 15:29:19 -0000 --_000_0E9A48AB39AF3547ACD28A6DE3E2906A0AB169ATBRAGMSX02itison_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi All, Please see below my review of the use-cases draft. Regards, Abhinav Page 3, last paragraph: "We assume that the communication between the devic= es is based on the Representational State Transfer (REST) architectural style, i.e. a device acts as a server that offers resources such as sensor data and actuators". Is this true for all interactions in the constrained world? For several eve= nt driven systems, does it not make sense to also support some "RPC" like f= eatures? In some of the models we are looking at in the indoor professional= lighting domain, it is planned to use CoAP POST to execute an action and n= ot to create a new resource. The remaining comments I have are only regarding the Building Automation us= ecase because of my background working for an Indoor professional lighting = company. Sec. 2.4.1.1. "A vacant area of the building has been recently leased to co= mpany A. Before moving into its new office, Company A wishes to replace the lighting with a more energy efficient and a better light quality luminaries. They hire an installation and commissioning company C to redo the illumination." >From my knowledge of Building automation and professional lighting this sce= nario is highly unlikely. Usually a leasing company hires a space and the l= ights come as package with the space and are built into the leasing company= 's contract. If the leasing company wishes to change the luminaires they ty= pically have to speak to the (representative of) the building owner but thi= s is quite rare. There are some specific regions in the world e.g. central = EU where this is not always the case. Sometimes in central EU, the building= s do not have any built in luminaires and the leasing companies bring in th= eir own freestanding luminaires. It is very rarely the case that a leasing = tenant hires a contractor to change the lighting system. The situations is = more complicated for HVAC systems which often need to satisfy regulatory re= quirements. HVAC systems are often done building wide and are very rarely t= enant specific. A very important aspect of the installation/commissioning workflow has been= overlooked. Typically, installation in the building occur in the following= order (in a new building). 1) Installation of the lighting devices by an u= ntrained electrician, 2) A lighting commissioning engineer who configures l= ights 3) Installation of HVAC systems 4) First presence of trained IT profe= ssionals. So, the initial commissioning/installation process needs to be performed by= people with no IT knowledge and with the IT backbone not being present. Al= so, the commissioning goes in phases with different floors being commission= ed at different times and then later connected together with the IT backbon= e. Not having the IT backbone during commissioning puts big constraints bec= ause it is difficult to use public key certs during this process. Another point is that Authorization rules may also be role based. E.g. A co= mmissioner/facility manager might be able to configure devices but a user m= ay only be able to dim up/down the lights. 2.4.1.3 Maintenance The roles of a facility manager and commissioner (at least in building spea= k) are confused here. Depending on the type of building, there is a facilit= y manager who takes care of issues during the device operation. If changes = are required the facility manager is usually able to make the changes. The = facility manager is sometimes the same individual as the commissioner but n= ot always. We need to put procedures in place so that the commissioner who = commissions at the start can "hand-over" the system to the facility manager= . The most common maintenance issue that occur is that of replacing broken de= vices. Therefore, the "authorizations" need to be transferred to the replac= ement device. A phase that occurs several times and not covered in this use case is recom= missioning. This may occur in several situations: 1) when one tenant moves = out and a new one moves in, 2) Changes in the office space, 3) removing a d= evice from one system and adding it to another ________________________________________________________ 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. --_000_0E9A48AB39AF3547ACD28A6DE3E2906A0AB169ATBRAGMSX02itison_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 
Hi All,
 
Please see below my review of the u=
se-cases draft. 
 
Regards,
Abhinav
 
Page 3, last paragraph: „We assume that the communication between the device=
s is based on the

  = ; Representational State Transfer (REST) architectural style, i.e. a

  = ; device acts as a server that offers resources such as sensor data and

  = ; actuators”.

Is this tru= e for all interactions in the constrained world? For several event driven s= ystems, does it not make sense to also support some “RPC” like features? In some of the models we are looking at i= n the indoor professional lighting domain, it is planned to use CoAP POST t= o execute an action and not to create a new resource.

 =

The remaini= ng comments I have are only regarding the Building Automation usecase becau= se of my background working for an Indoor professional lighting company.

 = 

Sec. 2.=
4.1.1. “A vacant area of the building has been recently leased to com=
pany A.
 &=
nbsp; Before moving into its new office, Company A wishes to replace the
 &=
nbsp; lighting with a more energy efficient and a better light quality=

 &=
nbsp; luminaries.  They hire an installation and commissioning company=
 C to
 &=
nbsp; redo the illumination.”
&n=
bsp;
From my=
 knowledge of Building automation and professional lighting this scenario i=
s highly unlikely. Usually a leasing company hires a space and the lights c=
ome as package with the space and are built into the leasing company’=
s contract. If the leasing company wishes to change the luminaires they typ=
ically have to speak to the (representative of) the building owner but this=
 is quite rare. There are some specific regions in the world e.g. central E=
U where this is not always the case. Sometimes in central EU, the buildings=
 do not have any built in luminaires and the leasing companies bring in the=
ir own freestanding luminaires. It is very rarely the case that a leasing t=
enant hires a contractor to change the lighting system. The situations is m=
ore complicated for HVAC systems which often need to satisfy regulatory req=
uirements. HVAC systems are often done building wide and are very rarely te=
nant specific. 
&n=
bsp;
A very =
important aspect of the installation/commissioning workflow has been overlo=
oked. Typically, installation in the building occur in the following order =
(in a new building). 1) Installation of the lighting devices by an untraine=
d electrician, 2) A lighting commissioning engineer who configures lights 3=
) Installation of HVAC systems 4) First presence of trained IT professional=
s. 
&n=
bsp;
So, the=
 initial commissioning/installation process needs to be performed by people=
 with no IT knowledge and with the IT backbone not being present. Also, the=
 commissioning goes in phases with different floors being commissioned at d=
ifferent times and then later connected together with the IT backbone. Not =
having the IT backbone during commissioning puts big constraints because it=
 is difficult to use public key certs during this process. 
&n=
bsp;
Another=
 point is that Authorization rules may also be role based. E.g. A commissio=
ner/facility manager might be able to configure devices but a user may only=
 be able to dim up/down the lights. 
&n=
bsp;
2.4.1.3=
 Maintenance
The rol=
es of a facility manager and commissioner (at least in building speak) are =
confused here. Depending on the type of building, there is a facility manag=
er who takes care of issues during the device operation. If changes are req=
uired the facility manager is usually able to make the changes. The facilit=
y manager is sometimes the same individual as the commissioner but not alwa=
ys. We need to put procedures in place so that the commissioner who commiss=
ions at the start can “hand-over” the system to the facility ma=
nager.
&n=
bsp;
The mos=
t common maintenance issue that occur is that of replacing broken devices. =
Therefore, the “authorizations” need to be transferred to the r=
eplacement device.
&n=
bsp;
&n=
bsp;
A phase=
 that occurs several times and not covered in this use case is recommiss=
ioning. This may occur in several situations: 1) when one tenant moves =
out and a new one moves in, 2) Changes in the office space, 3) removing a d=
evice from one system and adding it to another
&n=
bsp;
&n=
bsp;
&n=
bsp;
&n=
bsp;
________________________________________________________ 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 immediately notify the sender and= delete the e-mail and attached documents. Please note that neither the sen= der nor the sender's company accept any responsibility for viruses and it i= s your responsibility to scan or otherwise check this e-mail and any attachments. --_000_0E9A48AB39AF3547ACD28A6DE3E2906A0AB169ATBRAGMSX02itison_-- From nobody Thu Oct 1 09:15:07 2015 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A6D91B2DC0 for ; Thu, 1 Oct 2015 09:15:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8nKiNQ7oMQB0 for ; Thu, 1 Oct 2015 09:15:04 -0700 (PDT) Received: from mail-qg0-x233.google.com (mail-qg0-x233.google.com [IPv6:2607:f8b0:400d:c04::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 765311B2DBF for ; Thu, 1 Oct 2015 09:15:04 -0700 (PDT) Received: by qgez77 with SMTP id z77so71499203qge.1 for ; Thu, 01 Oct 2015 09:15:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=1EDocrwHyC0iCTrIrZ6e37X2yEOnNZDX20oQ4v1CBcA=; b=CUpKVEQcMpAneV5Nxa7hm2quLpzZR7y63Db9cd6GdZfEwV2x36dFdcdsuQUlqQeTXO iNlKulYc+zdLY2fd6XqFJMg+wOkDPDvnQOfZJ0yW+G4PRVF/qJuuPZUebuJeCcPW6hpI lVZ3eOOYr2ynNOVMbI8GMNlagFc53hDIbE+kk= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=1EDocrwHyC0iCTrIrZ6e37X2yEOnNZDX20oQ4v1CBcA=; b=IMGkB7lEo2m8ewE4xEFHzGoBMGhU9XwLZhIHU2uQb8RZuj/U9SHaKlJCBU9y7JDpxN Co675BMdBUjb7/K+1oofdYvetJu9pdpxR2dCvpo97YYb+IHgf3vOSryyqbVwMizwIlBu BW4WWpXcDe0hiGQ5GeY1pW7sU1CTfSwbQDwLquhhckudH0p5NbE0cEScyhNsKHGWyAAw TvwW3UZ/Risc6jiCYk905s+lffNLkvoVF81BR5v/HMhDyyKEhuCk1+djokRSsmdkOGJG x1gi11XQX4PIItn5OlKhWBMPu9t+LQb3EcIDXXmf5bS2UHWypAhg6ga6Prcbx9VRLwCM CcHQ== X-Gm-Message-State: ALoCoQlBoTsRgBM8pA8KBCbbRs6Vw6XDxP+2HPicGFLy5n9BZCDqvDnFQaJcXNyjw7EqJMSq1/y4 X-Received: by 10.140.144.23 with SMTP id 23mr14077241qhq.38.1443716103466; Thu, 01 Oct 2015 09:15:03 -0700 (PDT) Received: from [172.16.0.112] (pool-173-73-126-188.washdc.east.verizon.net. [173.73.126.188]) by smtp.gmail.com with ESMTPSA id 145sm2671304qhb.20.2015.10.01.09.15.02 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 01 Oct 2015 09:15:02 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Sean Turner In-Reply-To: <560D208D.9050902@sics.se> Date: Thu, 1 Oct 2015 12:15:09 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <0B20F0CA-B84B-4A4B-82E4-D5E87F27D715@sn3rd.com> <560D208D.9050902@sics.se> To: Ludwig Seitz X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: ace@ietf.org Subject: Re: [Ace] Second WGLC for draft-ietf-ace-usecases-05/6 X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 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, 01 Oct 2015 16:15:06 -0000 On Oct 01, 2015, at 08:01, Ludwig Seitz wrote: > On 2015-09-30 22:04, Sean Turner wrote: >> I=92m late with these so feel free to address these during IETF LC. >>=20 >> Overall, I think this draft is good to go and is much better than an >> earlier version I reviewed. First a couple of questions: >>=20 >> 0) I=92ve got two questions that I=92d like to ask about the home >> automation case that I=92m not sure would require changes (and since >> these are late I=92ll leave that up to the chairs): >>=20 >> 0.0) s2.2: There=92s the concept of two owners and it seems to imply >> that they both have the same authorization level. Do you envision a >> scenario where say Alice, who is a lawyer, has a smart lock on her >> closet to store her files and laptop after work that Bob can=92t >> access? > Why bring lawyers into an otherwise pleasant scenario? My wife=92s a lawyer so I=92m always around one :) > Joke aside: > No we haven't considered this kind of scenario. However I expect that = would be subsumed by >=20 > o U2.3 A home owner wants to apply different access rights for > different users. >=20 > where Bob would be "just" a user, who does not have full access to all = systems in the house. >=20 > Now if Bob wants a similar closet for his stamps collection that Alice = cannot access, I would expect that it would be hard to integrate that = into a home automation system controlled by Alice =85 Okay sounds good. >> 0.1) s2.2: The addition of the public safety use case also made me >> wonder, if there=92s an idea to allow the fire brigade in when the >> house is on fire or to let the police in if Bob has activated his >> home alarm's panic button? >>=20 > I guess that was implicitly assumed in section 2.4.2.1. > The fire department already has special access rights (namely turning = off the fire alarm). >=20 > Perhaps a slight rewording of U4.4 to include other rights than just = administrative tasks could resolve this? That would work for me. >> 1) One question about the building lighting use case: >>=20 >> s2.4.1.3/s2.4.3: Should there be a requirement from maintenance about >> the device checking the authz before accepting the new firmware? Is >> this addressed by U4.10 (if so might be good to add "(U4.10)" to the >> last para of s2.4.1.3)? >=20 > I wouldn't assume that uploading new firmware is a "extremely = time-sensitive operation" so U4.10 is not the best item to cover this. >=20 > I think the reason why there is no explicit item for this one here is = that the problem list was supposed to to be incremental. Okay that works for me. spt >> 2) One question about the sports and entertainment use case: >>=20 >> s2.6: The =93low=94 value judgement caught my attention because when = I >> first read this use case I thought that one man=92s entertainment = event >> where everybody=92s kit lights up when their team scores is another >> man=92s dissent rally getting droned because their Guy Fawkes masks = are >> chipped; I also thought that entertainment devices (e.g. gaming >> systems) are being used for =93swatting=94 so entertainment !=3D low. = But, >> then I read use case and I kind of agree that the as described use >> case might not need all that much security because the transmit range >> of the devices is likely quite small. So could you just strike the >> 1st sentence and =93however=94 from the second sentence and call it = day? >>=20 > I'm ok with that, Steffi do you agree? >=20 >=20 >=20 >>=20 >> The rest of these are all editorial so I suggested changes OLD/NEW >> and r/old/new: >>=20 > I'll look into these >=20 > /Ludwig >=20 > --=20 > Ludwig Seitz, PhD > SICS Swedish ICT AB > Ideon Science Park > Building Beta 2 > Scheelev=E4gen 17 > SE-223 70 Lund >=20 > Phone +46(0)70-349 92 51 > http://www.sics.se >=20 > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace From nobody Thu Oct 1 09:23:37 2015 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5389A1B2DE5 for ; Thu, 1 Oct 2015 09:23:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id npBmQ1N93ROM for ; Thu, 1 Oct 2015 09:23:33 -0700 (PDT) Received: from mail-qk0-x230.google.com (mail-qk0-x230.google.com [IPv6:2607:f8b0:400d:c09::230]) (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 F20141B2DE3 for ; Thu, 1 Oct 2015 09:23:32 -0700 (PDT) Received: by qkas79 with SMTP id s79so31291700qka.0 for ; Thu, 01 Oct 2015 09:23:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=AWpaO4pHhlkbChzRRECw4e1eBA5TrxthT9r0r/CmlHU=; b=GSvbxJPP2BUW8jE54o7weeaIOhRmb7gKn/klJMo6NKafv8amWSku3D5it299AEEmBV f+qOdLanqU0fP4eu8WeX+vo8TWf+/i1eMGQD9txfnJZ97RTGA2fksxdNeW1SanqUu2if bwBxf1e3mHauum3HiPxnst8VHLMdXSZ1EgvOo= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=AWpaO4pHhlkbChzRRECw4e1eBA5TrxthT9r0r/CmlHU=; b=RpPidr/NXDTYw3vVLyb0ESMVYIREvrbBebCkCi26TZ6vWzvAftJP6084zFWv1f83f6 KlKdyhunyPdlAWigL5E8Oz58fsEQwaBAgKjXtZ0z6KS8e5cZ92XeGMZlCM3KhM/JZVy6 N21ZBq7h1JRdSvIo191xPDWSCz4QjfSaDEOvVAcoL3Waeaohb+UVNNU+w8B0xij+GjUJ NrSIX8fExAlsco+4R9FZQ/vOLZboLsnfZ14436Jd1benBajUlT6hS5erhNIyBHaUMFbl urbEWFY6MxR1QyWOScW44oCT+dgwJSvSkolYWULPgNY0l4BbnyjOxL+sqcxdcRjl1tLE ykTw== X-Gm-Message-State: ALoCoQkD73dYXFSJPQDkIjUjPPEAijNvgJV/SUBv0oK2EyblnGbl2VKLa9M3KrLt8XhmfCOfvZsK X-Received: by 10.55.195.134 with SMTP id r6mr13318199qkl.30.1443716611971; Thu, 01 Oct 2015 09:23:31 -0700 (PDT) Received: from [172.16.0.112] (pool-173-73-126-188.washdc.east.verizon.net. [173.73.126.188]) by smtp.gmail.com with ESMTPSA id 78sm2707776qgj.0.2015.10.01.09.23.31 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 01 Oct 2015 09:23:31 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Sean Turner In-Reply-To: Date: Thu, 1 Oct 2015 12:23:37 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <1A66BA12-A94F-4A9E-A05C-2E0483FB76B6@sn3rd.com> References: <0B20F0CA-B84B-4A4B-82E4-D5E87F27D715@sn3rd.com> <560D4187.9020500@sics.se> To: Ludwig Seitz , Kathleen Moriarty X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: "ace@ietf.org" Subject: Re: [Ace] Second WGLC for draft-ietf-ace-usecases-05/6 X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 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, 01 Oct 2015 16:23:35 -0000 Ludwig, Embedding my replies in Kathleen=92s to cut down on the emails. spt On Oct 01, 2015, at 11:22, Kathleen Moriarty = wrote: > Thanks for addressing these additional comments quickly. I've > tentatively put this on the 10/22 telechat so we can wrap it up before > the next meeting. If a new version is ready today, I could put it on > the 10/15 instead. >=20 > I'll respond to the one comment inline, thanks for noting my previous > text request. >=20 > On Thu, Oct 1, 2015 at 10:21 AM, Ludwig Seitz wrote: >> Hello Sean, >>=20 >> thank you for your comments and the especially the detailed suggested >> updates you provided. >>=20 >> Some comments inline. >>=20 >> @Kathleen: One comment specifically relates to some text you = suggested >> earlier, could you comment on this? (search for your name in the = text). >>=20 >> Regards, >>=20 >> Ludwig >>=20 >>=20 >> On 2015-09-30 22:04, Sean Turner wrote: >> [...] >>=20 >>> 7) s2.1: I=92m not sure why it=92s necessary to include value = judgements: >>> =93it=92s not easy=94 and =93especially challenging": >>>=20 >>> OLD: >>>=20 >>> The proper handling of the sensors in this scenario is not easy to >>> accomplish. They have to be associated to the appropriate pallet of >>> the respective container. Moreover, the goods and the corresponding >>> sensors belong to specific customers. >>>=20 >>> NEW: >>>=20 >>> Sensors in this scenario have to be associated to the appropriate >>> pallet of the respective container. Sensors as well as the goods to >>> specific customers. >>>=20 >> I agree with the first part, however the second part of your = suggestion >> does not sound like a complete sentence to me. Perhaps if we add a >> 'belong' somewhere? Yes: Sensors as well as the goods belong to specific customers. >>> The Intelligent Container (http://www.intelligentcontainer.com) is >>> an example project that continuously monitors perishable goods. >>>=20 >>=20 >> This sounds like the project itself that is montioring the goods. >> Perhaps rephrase this to "... project that explores solutions to >> continuously monitor perishable goods.=94? works for me >>> 17) (no action required) s2.3.1: I figured =93HeartGuard=94 had to >>> trademarked because I hear about it all the time - nope it=92s = because >>> we give =93heartgard=94 to my dog to prevent roundworms, = threadworms, >>> etc. ;) >>>=20 >>=20 >> I actually made that name up to refer to the device with something >> shorter that "the thing that measures John's heart rate". >>=20 >>=20 >>> 18) s2.3.2 U.3: The impact of security on battery lifetimes is >>> specially called out and maybe that=92s appropriate given the = document. >>> But, isn=92t the requirement really that non-health-related impacts = on >>> battery life be minimized to cut down on the amount of >>> charging/replacing the battery? I mean if the device is tweeting = out >>> it=92s location and firing off a charge to keep my heart beating = when >>> the batter gets low I sure hope it stops tweeting and keeps on = firing >>> off signals to the heart. Might I humbly suggest: >>>=20 >>=20 >>=20 >>> U3.3 Battery changes are very inconvenient and sometimes impractical >>> so battery life impacts need to be minimized. >>>=20 >>=20 >> The section is supposed to list specific authorization problems and I = feel >> that aspect is lost with your proposal. >>=20 >> How about this: >> U3.3 Battery changes are very inconvenient and sometimes impractical = so >> battery life impact of the authorization mechanisms need to be = minimized. Ah I see your point. wfm >>> 21) s2.5.1: r/end customer=92s/customer=92s >>>=20 >>=20 >> Doesn't that make it easier to misunderstand? >>=20 >> The utility companies are after all also customers of the service = operator. Yeah I guess that makes sense. >>> 25) s2.6.1: (being pc today): r/girls/women >>=20 >>=20 >> Steffi wrote that section, honestly! >>=20 >>=20 >>=20 >>> 32) s3.1: Without an example of what part of DTLS you=92re talking >>> about maybe we could generalize this a bit :) >>>=20 >>> OLD: >>>=20 >>> Denial of service (DoS) attacks threaten the availability of >>> services a device provides. E.g., an attacker can induce a device = to >>> perform steps of a heavy weight security protocol (e.g. Datagram >>> Transport Layer Security (DTLS) [RFC6347]) before authentication and >>> authorization can be verified, thus exhausting the device's system >>> resources. This leads to a temporary or - e.g. if the batteries are >>> drained - permanent failure of the service. For some services of >>> constrained devices, availability is especially important (see >>> Section 2.3). Because of their limitations, constrained devices are >>> especially vulnerable to denial of service attacks. Solution >>> designers must be particularly careful to consider these limitations >>> in every part of the protocol. This includes: >>>=20 >>> NEW: >>>=20 >>> Denial of service (DoS) attacks threaten the availability of >>> services a device provides and constrained devices are especially >>> vulnerable to these types of attacks because of their limitations. >>> Attackers can illicit a temporary or if the battery is drained a >>> permanent failure service simply by repeatedly flooding the device >>> with connection attempts; for some services (see Section 2.3), >>> availability is especially important. Solution designers must be >>> particularly careful to consider the following limitations in every >>> part of the protocol: >>>=20 >>>=20 >>=20 >> The focus shifts somewhat with your suggestion, what I tried to point = out >> here was that especially the security protocols can offer a = convenient >> avenue for DoS attacks. >>=20 >> Perhaps this change to your suggested change makes that clearer: >>=20 >> "Solution designers must be particularly careful to consider the = following >> limitations in every part of the authorization solution.=94 Yes bringing the focus back to the authz part makes it better. >> 33) s3.2: Add =93Timers for transaction processing=94 I mean a simple >>>=20 >>> attack is start transaction, wait[0], ... wait[n], fail. >>>=20 >>=20 >> I assume you mean section 3.1 here not 3.2 right? drat yes I meant 3.1. >>> 34) s3.2: The last paragraph, aren't we really worried about >>> unauthorized disclosure and spoofing? You can intercept as many >>> encrypted sessions as you want and you can eavesdrop on as many >>> sessions that don=92t require confidentiality as you want. I really >>> think what you=92re trying to say is that the sessions need to be >>> appropriately protected: >>>=20 >>> OLD: >>>=20 >>> Another category of attacks that needs to be considered by solution >>> developers is session interception and hijacking. >>>=20 >>> NEW: >>>=20 >>> Solution developers also need to consider whether the session should >>> be protected from information disclosure and spoofing. >>>=20 >>=20 >> Same here you do mean 3.1 right? Also the part on session = interception and >> hijacking was specifically requested by Kathleen. I'm not sure if = your edit >> captures her intent. >=20 > Information disclosure is the problem that is possible from both > session interception (passive) and hijacking. Sessions could also be > altered, so that is not covered by the new text, but the terms are > better than what I had as they get to the problem as opposed to attack > types. Spoofing is also more of an attack type. >=20 > How about: >=20 > Solution developers also need to consider whether the session should > be protected from information disclosure and tampering. >=20 > I think that covers active attacks and Sean's spoofing addition. > Sean, if you can think of a better term, please do suggest one or two. nah I think what you suggested works. > Thanks, > Kathleen >=20 >>=20 >>> 35) s3.2 & s3.3) r/(see e.g./(see >>>=20 >>> 36) s3.3: You=92ve convinced me, we need to take care for almost all >>> cases involving untrained humans (my mum included): r/home >>> scenarios/scenarios >>>=20 >>=20 >> -- >> Ludwig Seitz, PhD >> SICS Swedish ICT AB >> Ideon Science Park >> Building Beta 2 >> Scheelev=E4gen 17 >> SE-223 70 Lund >>=20 >> Phone +46(0)70-349 92 51 >> http://www.sics.se >>=20 >=20 >=20 >=20 > --=20 >=20 > Best regards, > Kathleen From nobody Thu Oct 1 10:18:53 2015 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB4E01B2E15 for ; Thu, 1 Oct 2015 10:18:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sSpYrBTUfrbC for ; Thu, 1 Oct 2015 10:18:49 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (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 8F22B1B2E14 for ; Thu, 1 Oct 2015 10:18:49 -0700 (PDT) Received: from [192.168.131.140] ([80.92.119.87]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0MHXd2-1ZeOeR0gI8-003NeH for ; Thu, 01 Oct 2015 19:18:47 +0200 To: "Ace@ietf.org" From: Hannes Tschofenig Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9 X-Enigmail-Draft-Status: N1110 Message-ID: <560D6A94.1010008@gmx.net> Date: Thu, 1 Oct 2015 19:17:08 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="p3cE9pdNQe0SxuKL1s84PH8LJruVNnUgR" X-Provags-ID: V03:K0:3W148c6l4bl2Rst8JMZYkRvCt1OpHuws4wP1qbguqDBC/goVign RJwBiGX10v/nRF76MooKe1K5BoA2TK0RCWPPnmuiftvhrCXkAEIEvOkF4cBJJq2RW6kuILA HRnE7rL59iYyRa5yUQBu/MkwyomoXrB8ampWAt1/1MS9iBVLIwu7kjKxCv01kgNJ4LnbS4p 2J4Q3QcKs7B8E0b4YC4Ew== X-UI-Out-Filterresults: notjunk:1;V01:K0:Y0d8WqC05bI=:KUvsDXC0prO87kuq3+PoQk CqOvd8JXU+7A0rr2LYnbOMjuBX9oPfiQGHq8OD0RASifMHSAubg85TCWfK7CE1m1GxS13aWt+ AVzZ8Ii77T9O9G/zOHTxZlm0rt7Q4ITgBySjvLaa8a/w1m284WswXREs9pg+gl6EiaR8ldlpD MOfHEJeWFG9v4md8lBjjajkMeOmamTyNqDBk0UXHGeeZue1EyOSIIPj4AL340wSqrnIvy60WI RYKDB2G2pJ+TGnN9vkYE6AmOKkXvAOofwozNcdeVBCXjj766WDsTxODTBQDbiKUSRYzOH0hMz 79X4OUb3PHQ23T7cm3FMGFrmu5j97kph0e1cxYgBD0WIq60w23EFv2CbUgWLeLcfSXSsQkKL7 9xZQsdsfoDHu+u9Rqptg2hICwJKXXWWObBmqqvgG/nPD8z4J7f56luTwydOrKDv/3VPhcm8K4 mOPlsFL55EiyBcsmBTPRw52hPNKXH5wF42Xp0RihfiZSfkmhfFF/TwPrqkiqxh8+mZbX9baPu zleF+uGo1tFl3xGqS2Wnx21l7ihrLe8k0YBtFnmn6czh3cfHxPDhFGB3hhiCufmWhvAGpzf4d 1Ef4wjtlLgx/nueVcRajdTMsL3wgoJd/fJODVSRLhmsOV134wcsZdVd2kCJuRA8xfLJpqHlic bm3zm4XQTUop9HuPacI76wAtbuXlpqWW1P1vkV9VSAn2KLXaf3LmwSqEPbEodxVsnHQD/RFno vtN0Ovrbv75TqhYpI0/uX4NSLnCB9ghnZE1CwSsUjapebUGVXR4tRUkO7Rs= Archived-At: Subject: [Ace] Meeting Minutes (Virtual Interim Meeting -- 30/09/2015) X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 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, 01 Oct 2015 17:18:52 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --p3cE9pdNQe0SxuKL1s84PH8LJruVNnUgR Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Please take a look at the meeting minutes from our virtual interim meetin= g: https://www.ietf.org/proceedings/interim/2015/09/30/ace/minutes/minutes-i= nterim-2015-ace-1 Let us know if you have comments. Ciao Hannes --------- Authorization for Constrained Environments (ACE) WG Virtual Interim Meeti= ng -------------------------------------------------------------------------= -- Date: 30/09/2015 Chairs: Kepeng Li/Hannes Tschofenig Participants: * SeanTurner * Kepeng Li * Klaus Hartke * Kathleen Moriarty * Goeran Selander * Abhinav Somaraju * Erik Wahlstroem * Michael Richardson * Olaf Bergmann * Mohit Sethi * Paul Madsen * Samuel Erdtman * Sandeep Kumar * Friedhelm Rodermund * Hannes Tschofenig * Jim Schaad * Ludwig Seitz * Carsten Bormann * Corinna Schmitt * Daniel Lindau * Malisa Vucinic * Vinod Choyi * Steffi Gerdes * Jorge Cuellar * Prashant Jhingran Kepeng opened the meeting and pointed the participants to the note well, which can be found at: https://www.ietf.org/about/note-well.html He bashed the agenda and nobody requested changes. 1) Rechartering Kepeng showed the updated charter text to the group and asked for comment= s. No new comments on the charter text. The new charter will be sent to the IESG for approval. 2) Use Cases Ludwig reported about the status and the open issues Kathleen raised. Hannes was asked to provide feedback this week about the privacy consideration section. Kathleen asked to submit a new version this week due to the timing with the IESG conference call. Sean mentioned that he has some comments and will post them to the list. 3) Architecture Carsten reported about the status and the email he posted to the mailing list. Here is the mail: http://www.ietf.org/mail-archive/web/ace/current/msg01360.html The term 'non-repudiation' was replaced with 'third party verifiability'.= Discussion about intermediaries was started and two types of intermediaries have been identified: (a) transparent forwarders, and (b) actors that process the messages and participate in the security processing. Goeran mentioned other sub-categories where intermediaries may be able to read messages but are not able to modify them. Yet other intermediaries are able to verify signatures but cannot read the content of the messages. Jim also had comments regarding intermittent connectivity and Carsten asked the group to provide better input. Jim also noted that availability is a security goal. The term 'security domain' seems to be used in various places in the document but with different and un-defined meaning. Currently the review comments are pretty much based only based on a single review from Jim. We need more reviews. Kepeng raised the topic of terminology. Goeran explained why he believes little reason to move away from OAuth terminology. Kathleen explained the process and the agreement reached on terminology in the Dallas IETF meeting, which was followed by the document authors. Ludwig noted that we will have a world where IoT devices are combined with non-IoT devices. Hence, new terminology does not help to communicate the ideas. Steffi disagreed with him and argues that there is confusion. Ludwig asked whether an OAuth authorization server is very different from an authorization manager. Steffi thinks that there are differences. Carsten agrees with Steffi. Goeran believes that some of these terminology discussions are solution dependent. You can also use the 'ACE-' prefix to avoid confusion. Goeran noted that the term 'CAS' was invented by Carsten. Samuel said that he read the use case document and he is familiar with OAuth. He did not need additional terminology; the use cases read nicely without new terminology. Carsten noted that there is at least a solution specific aspect in here. Goeran asked Carsten what use cases cannot be accomplished with OAuth terminology. Carsten said that every solution solves every use case. Goeran asked Carsten to post a mail to the list to explain what cannot be described with OAuth terminology. Paul mentioned that there is an Authorization Manager (AM) in UMA. It manages entities from other security domains. Kepeng asked Carsten to make a proposal to the list. Kepeng suggested to talk about tasks next. Carsten suggested to have WG participants to look at Steffi's task document and whether this is something useful to address Jim's comments. Goeran looked at the document and posted comments to the list. We don't need to reference the draft for various reasons. Many parts are overlapping and other parts are not needed. ACE has already stretched the limit on informational documents. Carsten we should definitely not ask for working group time since it is a bit too complicated. It still provides information to those reading the actors document and need further background. Kepeng: we definitely don't have enough resources in the group to work on that document. Ludwig posted a mail to the list with the summary. Nobody seems to remember the document and it got lost. Ludwig will post the info again to the list. Goeran believes that it should not be too difficult to resolve the comments from Jim. It should not need 20 pages. Ludwig took the headlines and it was pretty obvious without the text. Carsten: We should take the issues to the list. Kepeng: New text needs to be provided to resolve the comment raised by Ji= m. Kepeng: Next topic -- Categories of intermediaries Hannes explained the types of intermediaries (discussed a previously) and Goeran believes that those are the different types. Goeran will send a mail to the list listing the different proposals. Kepeng: Structure of Section 2. Carsten believes it is not worth trying to fix this. Jim: It is OK not to address my comments. I found the flow unhelpful but other people may not have that problem. Kepeng: Diagrams -- confusion about information flow Jim has not had a chance to review the new document yet. Olaf was asked about his comment regarding Figure 7 about "Information flows that need to be protected". It appears to be confusing. Ludwig thinks it is confusing because there are two aspects shows in the figure, namely the information flows and the fact that an endpoint can act as a client and as a resource server. Carsten will look into the term security domain and figure out what is meant in each occurrence. Reviewers: Sean Turner, Sandeep Kumar, and Samuel agreed to do reviews. --p3cE9pdNQe0SxuKL1s84PH8LJruVNnUgR Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJWDWqUAAoJEGhJURNOOiAt7d0H/04aDchjcSmYHP6Cu0ghgpUu NtBGUNBcFBSPCFiX6j3a9hnhDmk8kSc2wORP18MyxcNkoGsdayTvp85CK14voJl0 5apJuGLIz+E8FXNCmkZoRDlwpbaY33pN3xR/NbjnoQumViNA/TUOja0TB9jvf+JB AYkZj06nZ0jFx/Sk0qnS9w/NzATGdj8iE1PiSnz6ako/JKyP2dD5dVxzXtMIC9Ug ky3N7yBx2LRqklIrvgn4jR7T9VyFd3bO2t8+ciuCnKROAFwaspHyDiRO8GcmUz6m GMFisDdDW7UX9L0ig3xjco+KlK31Js0L7QTS4Ty+VqMM1ecL+cynu5uTvJJfmsU= =tiyh -----END PGP SIGNATURE----- --p3cE9pdNQe0SxuKL1s84PH8LJruVNnUgR-- From nobody Thu Oct 1 21:20:23 2015 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AC1C1A92AF for ; Thu, 1 Oct 2015 21:20:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1 X-Spam-Level: X-Spam-Status: No, score=-1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_44=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L7u5K1SdV1jm for ; Thu, 1 Oct 2015 21:20:17 -0700 (PDT) Received: from smtp4.pacifier.net (smtp4.pacifier.net [64.255.237.176]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 613081A90F1 for ; Thu, 1 Oct 2015 21:20:17 -0700 (PDT) Received: from hebrews (c-24-21-96-37.hsd1.or.comcast.net [24.21.96.37]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp4.pacifier.net (Postfix) with ESMTPSA id 9C02F38F02; Thu, 1 Oct 2015 21:20:16 -0700 (PDT) From: "Jim Schaad" To: =?UTF-8?Q?'G=C3=B6ran_Selander'?= , References: <088001d0fbf6$e4527480$acf75d80$@augustcellars.com> In-Reply-To: Date: Thu, 1 Oct 2015 21:17:45 -0700 Message-ID: <000401d0fcc9$4aaa5f90$dfff1eb0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 15.0 Content-Language: en-us Thread-Index: AQIA+rdZxwtn1JgbSnMW0+oRVOSQ3QHyk6HxneeBOfA= Archived-At: Subject: Re: [Ace] Security properties of CoAP message fields X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 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, 02 Oct 2015 04:20:21 -0000 > -----Original Message----- > From: G=C3=B6ran Selander [mailto:goran.selander@ericsson.com] > Sent: Thursday, October 01, 2015 5:08 AM > To: Jim Schaad ; Ace@ietf.org > Subject: Re: [Ace] Security properties of CoAP message fields >=20 > Hi Jim, >=20 > As Carsten pointed out, much of this is considered in Appendix A of > https://datatracker.ietf.org/doc/draft-selander-ace-object-security >=20 > (If anyone by chance gets motivated to actually read it, I would = recommend wait > a little for version -03 for improved readability.) >=20 > Note that Appendix A applies to Mode:COAP which is the mode where = payload, > selected headers and options are protected. There is also a Mode:PAYL = which is > only protecting payload. Different Modes apply to different use cases = as is > exemplified in section 2 and 3 of the draft (and below). >=20 > Comments inline: >=20 > On 2015-10-01 05:11, "Jim Schaad" wrote: >=20 > >To and From Addressing: Ok this is not really part of the message, I > >just want to ensure that nobody things that this should be protected = in > >any way as it will be modified in transit by any number of CoAP and = non > >CoAP entities. >=20 > We propose to integrity protect e.g. destination URI (the content of = the CoAP > Options Uri-Host, Uri-Port, Uri-Path, Uri-Query) in the CoAP request. But these are options, they are not what I would consider to be the to = and from addressing. This is what I would think of as the UDP addresses = prepended to the front. Sorry if I did not make that clearer. >=20 > > > >CoAP version number: Maybe integrity protected - I don't see any > >benefit in hiding. >=20 > The mind set we have is that between any two endpoints with a security > association there may in general be some intermediate nodes. This = means that > many of the header parameters doesn=E2=80=99t make sense to integrity = protect, > because they are not preserved end-to-end. >=20 >=20 > For Version we were actually considering the benefits of having a = proxy > translating between different versions, thus we omitted integrity = protection > (which then needs to be considered with newer version of CoAP appear = so this > does not introduce a vulnerability) What would be the benefits of allow for a proxy to do version number = changing. That potentially says that the entire structure would be = altered and the new things might need to be (or were) integrity = protected. This would start causing failures. >=20 >=20 > > > >Message type: This might be interesting to integrity protect, I = don't > >know there is any benefit in hiding. > > > >Token Length: Implicitly protected if the token itself is protected. > > > >Token: Should be integrity protected. Protection should be extended > >to noting that a token does not exist. >=20 > None of these three necessarily survives a proxy. What are the benefits of allowing a proxy to change the message type? =20 Why would you have a situation where the proxy would change the token? = Why should this happen? The entire value of the token is tied to the = transaction that the client and the server are participating in. = Caching it would make no sense in many cases if the client uses a new = token, because the proxy would not know that it would be in the same = conversation. >=20 > > > >Code: I think that this is going to depend on what the code is. For > >C->RS > >messages and probably for RS->C success responses it should be > >integrity protected. For RS->C failures, it would be good to be > >integrity protected. > >For Proxy->C responses it might not be able to be protected. For > >Mallory->C > >responses it would never be protected. Does C do different things = if a > >protected message is sent and an unprotected message is returned? > >(Assumes > >that C always initiates.) >=20 > The two Modes mentioned above address this differently. >=20 > For Mode:COAP a compliant node receiving a protected request must send = a > protected response, and a compliant node receiving the response = verifying that > it matches the request. In this case Code is integrity protected, so = this mode > applies to the use cases where it is important to distinguish e.g. GET = from > DELETE or where it is important that response codes are integrity = protected to > ensure correct operations has been performed. So what would happen if a proxy returns an error code because it finds a = problem of some type. This would not be integrity protected. Does the = original message creator ignore that error because it is not integrity = protected and resend the original request? Would you end up with a case = where the error is returned and is integrity protected, but not to the = same context? Does that make you accept or reject the message? >=20 > For Mode:PAYL only the payload is protected, so the change of Code = should not > have a security implication. In this case there may be protected = message in only > one direction, e.g. a GET response cached and forwarded to different = requesting > clients. This basically falls into the world of - just protect the content. That = might also be a mixed message world where you combine the two different = features with multiple security contexts. (i.e. an encrypted message = from a server (PAYL) and signed by the intermediate data server (COAP). >=20 > > > >Message ID: Should be integrity protected. >=20 > May be changed by intermediary. I can see this field as being changeable. So no protection makes sense >=20 > > > > > >Options: Protection extended to options is going to be option and > >possibly dialog specific. > >* None: There are/may be options which are expected to be modified = in > >transit. There are options which may be/are expected to be inserted = in > >transit. These options cannot have any security protection on them >=20 > We elaborate on this in Appendix A. One general indication are options = that are > safe-to-forward may be integrity protected. But even if an option is = not safe-to- > forward, the content of the option may be integrity protected. The = critical > distinction seems to be if an option is changed in a predictable way = so it is > possible to define an =E2=80=9Cinvariant=E2=80=9D which can be = integrity protected. This method seems to be fraught with potential errors as new options are = defined. A non-critical option which is modified in a way not known to = the recipient is going to cause failures without the ability to diagnose = what is wrong. Between not knowing which options might or might not be = forwarded and which are modified vs which are protected seems to be a = problem. Jim >=20 > > > >* Integrity Only: The option can be visible to intervening = entities, > >and indeed might be required to be visible for them to function > >properly, but there is a requirement that the option not be changed > >between the sender and the recipient > > > >* Confidential (and integrity protected): The option is not to be > >visible to intervening entities. >=20 > Yes, for each mode there are two cases. >=20 From nobody Thu Oct 1 21:24:58 2015 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E9121ACD38 for ; Thu, 1 Oct 2015 21:24:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yulZRLV84ihd for ; Thu, 1 Oct 2015 21:24:54 -0700 (PDT) Received: from smtp2.pacifier.net (smtp2.pacifier.net [64.255.237.172]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6F3401ACD36 for ; Thu, 1 Oct 2015 21:24:54 -0700 (PDT) Received: from hebrews (c-24-21-96-37.hsd1.or.comcast.net [24.21.96.37]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp2.pacifier.net (Postfix) with ESMTPSA id 002E72C9E7; Thu, 1 Oct 2015 21:24:53 -0700 (PDT) From: "Jim Schaad" To: "'Ludwig Seitz'" , References: <088001d0fbf6$e4527480$acf75d80$@augustcellars.com> <560CEF31.9030204@sics.se> In-Reply-To: <560CEF31.9030204@sics.se> Date: Thu, 1 Oct 2015 21:22:22 -0700 Message-ID: <000501d0fcc9$effd5f10$cff81d30$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 15.0 Content-Language: en-us Thread-Index: AQIA+rdZxwtn1JgbSnMW0+oRVOSQ3QKjTYxmneKC1dA= Archived-At: Subject: Re: [Ace] Security properties of CoAP message fields X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 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, 02 Oct 2015 04:24:56 -0000 > -----Original Message----- > From: Ace [mailto:ace-bounces@ietf.org] On Behalf Of Ludwig Seitz > Sent: Thursday, October 01, 2015 1:31 AM > To: ace@ietf.org > Subject: Re: [Ace] Security properties of CoAP message fields >=20 > On 2015-10-01 05:11, Jim Schaad wrote: > Code: I think that this is going to depend on what the code is. = For > C->RS > > messages and probably for RS->C success responses it should be > > integrity protected. For RS->C failures, it would be good to be integrity > protected. > > For Proxy->C responses it might not be able to be protected. For Mallory->C > > responses it would never be protected. Does C do different things = if a > > protected message is sent and an unprotected message is returned? > > (Assumes that C always initiates.) >=20 > In the case of CoAP observe or publish subscribe, can you always say = that C > initiates? > Sure at some point C sent the initial observe/subscribe message, but = the > subsequent updates/publications are actually initiated by the RS. >=20 > I guess when C initiates it should be possible for C to specify if it expects > integrity protected response codes. This way a honest proxy can = forward such a > request to the RS (if it cannot provide the requested protection). A couple of responses: 1) I was trying to simplify the world and made the assumption that the = same circumstances would come into effect when one reversed the roles. Thus = one could swap C and RS without any changes in the analysis. 2) This is one of the places where Figure 7 in the actors draft becomes slightly confusing. Who is client and who is RS in different types of dialogs becomes weird. Jim >=20 > /Ludwig > -- > Ludwig Seitz, PhD > SICS Swedish ICT AB > Ideon Science Park > Building Beta 2 > Scheelev=E4gen 17 > SE-223 70 Lund >=20 > Phone +46(0)70-349 92 51 > http://www.sics.se From nobody Fri Oct 2 01:58:21 2015 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 515451ACEEA for ; Fri, 2 Oct 2015 01:58:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tSdFBAG7fZUu for ; Fri, 2 Oct 2015 01:58:17 -0700 (PDT) Received: from mail-lb0-f175.google.com (mail-lb0-f175.google.com [209.85.217.175]) (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 CDE101ACEE9 for ; Fri, 2 Oct 2015 01:58:16 -0700 (PDT) Received: by lbcao8 with SMTP id ao8so22959889lbc.3 for ; Fri, 02 Oct 2015 01:58:15 -0700 (PDT) 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:content-type; bh=k5GKxB5d33XRZaJRIzQVUFu4Yszjud8n3fNRYuUHeHA=; b=bGhIRWvkz9WloFnK0jnjdoHpfasQT3z8hNQSIVcnFZh9YU+Umo8kuIFxw1WYmllkZO mpsvbw3d+MT+T65K8J2ggTMFc+L7tpQJaYDaJaiu+rRRLJ7RbBf/m1Ny1kn3wG4URaP4 ferZZsXDGNAtlEHBRQ/OElQn3wDuvJ61AjBLAQYEM+Mb+eq+jyr2llrXZBAhAb9epu+L Pq0iCJk2xBI7mEup1d/0IUcCWdBqb2dtYWz/MWzFz14y73VoxeZwfC1Zg8v+AZNzG/6H 4LhmUQIZKtMpB1jb0uFTO3bxyanAuR74GP3w+6FpYQRccPWrHuwB49LtfxXQjdtkUrJG jnqg== X-Gm-Message-State: ALoCoQnUZ3XLfk3z7LZkylKA4kGp0wt9KJinIOkZkja7yuytaXOQ+MJOJaIlhSdYLJuePo16FrgS X-Received: by 10.112.53.68 with SMTP id z4mr4895808lbo.4.1443776294875; Fri, 02 Oct 2015 01:58:14 -0700 (PDT) Received: from [192.168.0.108] ([85.235.11.178]) by smtp.gmail.com with ESMTPSA id h7sm1309986lbk.8.2015.10.02.01.58.13 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 02 Oct 2015 01:58:13 -0700 (PDT) To: ace@ietf.org, "Kumar, Sandeep" , abhinav.somaraju@tridonic.com References: <0E9A48AB39AF3547ACD28A6DE3E2906A0AB169@ATBRAGMSX02.itiso.net> From: Ludwig Seitz Message-ID: <560E4724.4010309@sics.se> Date: Fri, 2 Oct 2015 10:58:12 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <0E9A48AB39AF3547ACD28A6DE3E2906A0AB169@ATBRAGMSX02.itiso.net> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms060109000809080707010309" Archived-At: Subject: Re: [Ace] [ACE] review draft-ietf-ace-usecases-06 X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 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, 02 Oct 2015 08:58:19 -0000 This is a cryptographically signed message in MIME format. --------------ms060109000809080707010309 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable On 2015-10-01 17:28, Somaraju Abhinav wrote: > Hi All, > > Please see below my review of the use-cases draft. > > Regards, > > Abhinav Hello Abhinav, thank you for reviewing our document. Comments inline. /Ludwig > > Page 3, last paragraph: =84We assume that the communication between the= devices is based on the > > Representational State Transfer (REST) architectural style, i.e. a > > device acts as a server that offers resources such as sensor data a= nd > > actuators=94. > > Is this true for all interactions in the constrained world? For several= > event driven systems, does it not make sense to also support some =93RP= C=94 > like features? In some of the models we are looking at in the indoor > professional lighting domain, it is planned to use CoAP POST to execute= > an action and not to create a new resource. Actually when looking at the use cases it's true there is nothing that=20 would specifically exclude RPC-like communication. I'll try to rephrase=20 this to make it more neutral. > > The remaining comments I have are only regarding the Building Automatio= n > usecase because of my background working for an Indoor professional > lighting company. This makes your comments a very valuable contribution. I'm hoping that=20 Sandeep who was the main author of this section will have some time to=20 address you comments. If not I will give it a try. Regards, Ludwig Seitz --=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 http://www.sics.se --------------ms060109000809080707010309 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 DFQwggYYMIIFAKADAgECAgMMhpgwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYw FAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZp Y2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJt ZWRpYXRlIENsaWVudCBDQTAeFw0xNTAxMDgwODM5MDZaFw0xNjAxMDkyMjQxMzBaMDgxFzAV BgNVBAMMDmx1ZHdpZ0BzaWNzLnNlMR0wGwYJKoZIhvcNAQkBFg5sdWR3aWdAc2ljcy5zZTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMVB4rAuq4FxbARxwRqPLpc/3C194F+V H4XMKK6fu3Y8zDLijzNSjh6tG41oZhXvJcvAs1nZNjUutNLeyBAUFiYhy7HXNdlKpjbMEFKQ +6KpEdZ0Rk+pXgB2E1mqZEfp3M2djcQ/h+7uGVlSGYNAxYk6rWPIIWBx2GMvAQaHP4xxu/F+ PiSQILOVzmtIFZe1t/Lw71aaNeMYVhARo8z5PVsVoq6gBeujxfiRLtiQ/S8xW6RKvNvUkVyT BQfcKaEDZR9FENNf9rFgiAcT6R7hI8RBf1d2fxdlbDU8uM72K3fvzGDt8N9Bfm1kDWbDBxJE 1taRIYs+60D1kwV6DvBb9MECAwEAAaOCAtQwggLQMAkGA1UdEwQCMAAwCwYDVR0PBAQDAgSw MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAdBgNVHQ4EFgQU6ryrKahJtBOEdbIL AAWCpOsQyagwHwYDVR0jBBgwFoAUU3Ltkpzg2ssBXHx+ljVO8tS4UYIwGQYDVR0RBBIwEIEO bHVkd2lnQHNpY3Muc2UwggFMBgNVHSAEggFDMIIBPzCCATsGCysGAQQBgbU3AQIDMIIBKjAu BggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjCB9wYIKwYB BQUHAgIwgeowJxYgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwAwIBARqBvlRo aXMgY2VydGlmaWNhdGUgd2FzIGlzc3VlZCBhY2NvcmRpbmcgdG8gdGhlIENsYXNzIDEgVmFs aWRhdGlvbiByZXF1aXJlbWVudHMgb2YgdGhlIFN0YXJ0Q29tIENBIHBvbGljeSwgcmVsaWFu Y2Ugb25seSBmb3IgdGhlIGludGVuZGVkIHB1cnBvc2UgaW4gY29tcGxpYW5jZSBvZiB0aGUg cmVseWluZyBwYXJ0eSBvYmxpZ2F0aW9ucy4wNgYDVR0fBC8wLTAroCmgJ4YlaHR0cDovL2Ny bC5zdGFydHNzbC5jb20vY3J0dTEtY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEF BQcwAYYtaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczEvY2xpZW50L2NhMEIG CCsGAQUFBzAChjZodHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MxLmNs aWVudC5jYS5jcnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqG SIb3DQEBBQUAA4IBAQBl8BbG0n7+JjFqiJOuAqMbkeqM6Oyd+4oHGu3fbaSiM1SKesae2bfm vifV99a+M4DERZ2SVkOYcvNlv31Q3hvYtzRjDOqewzVKxo021R3ddQULW1DhvTEpclikG5rd 0NRJQn+EkSwEKLeUj68i0dhU8ULhZDDq3A81cTcZzIGrTjNnwDvCktB/sF/iO4At6RJ24P3j KjYFPirW3NsvZ2gzZizSzeubPE0/cWcqEBJ/UtaFPF54efejjLuPRHHMLPDcvrwBhEiBxuG6 oTEo465g4pS9Vo/Z0GoZgZyA+aGQ+YPbPSsqsYmSBjZ6MGGDqQq0niE2dW+8IOdHQvMkqI52 MIIGNDCCBBygAwIBAgIBHjANBgkqhkiG9w0BAQUFADB9MQswCQYDVQQGEwJJTDEWMBQGA1UE ChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUg U2lnbmluZzEpMCcGA1UEAxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwHhcN MDcxMDI0MjEwMTU1WhcNMTcxMDI0MjEwMTU1WjCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoT DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUg Q2xpZW50IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAxwmDzM4t2BqxKaQu E6uWvooyg4ymiEGWVUet1G8SD+rqvyNH4QrvnEIaFHxOhESip7vMz39ScLpNLbL1QpOlPW/t FIzNHS3qd2XRNYG5Sv9RcGE+T4qbLtsjjJbi6sL7Ls/f/X9ftTyhxvxWkf8KW37iKrueKsxw 2HqolH7GM6FX5UfNAwAu4ZifkpmZzU1slBhyWwaQPEPPZRsWoTb7q8hmgv6Nv3Hg9rmA1/VP BIOQ6SKRkHXG0Hhmq1dOFoAFI411+a/9nWm5rcVjGcIWZ2v/43Yksq60jExipA4l5uv9/+Hm 33mbgmCszdj/Dthf13tgAv2O83hLJ0exTqfrlwIDAQABo4IBrTCCAakwDwYDVR0TAQH/BAUw AwEB/zAOBgNVHQ8BAf8EBAMCAQYwHQYDVR0OBBYEFFNy7ZKc4NrLAVx8fpY1TvLUuFGCMB8G A1UdIwQYMBaAFE4L7xqkQFulF2mHMMo0aEPQQa7yMGYGCCsGAQUFBwEBBFowWDAnBggrBgEF BQcwAYYbaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL2NhMC0GCCsGAQUFBzAChiFodHRwOi8v d3d3LnN0YXJ0c3NsLmNvbS9zZnNjYS5jcnQwWwYDVR0fBFQwUjAnoCWgI4YhaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vc2ZzY2EuY3JsMCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNv bS9zZnNjYS5jcmwwgYAGA1UdIAR5MHcwdQYLKwYBBAGBtTcBAgEwZjAuBggrBgEFBQcCARYi aHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEFBQcCARYoaHR0cDov L3d3dy5zdGFydHNzbC5jb20vaW50ZXJtZWRpYXRlLnBkZjANBgkqhkiG9w0BAQUFAAOCAgEA CoMIfXirLAZcuGOMXq4cuSN3TaFx2H2GvD5VSy/6rV55BYHbWNaPeQn3oBSU8KgQZn/Kck1J xbLpAxVCNtsxeW1R87ifhsYZ0qjdrA9anrW2MAWCtosmAOT4OxK9QPoSjCMxM3HbkZCDJgnl E8jMopH21BbyAYr7b5EfGRQJNtgWcvqSXwKHnTutR08+Kkn0KAkXCzeQNLeA5LlYUzFyM7kP Ap8pIRMQ+seHunmyG642S2+y/qHEdMuGIwpfz3eDF1PdctL04qYK/zu+Qg1Bw0RwgigVZs/0 c5HP2/e9DBHh7eSwtzYlk4AUr6yxLlcwSjOfOmKEQ/Q8tzh0IFiNu9IPuTGAPBn4CPxD0+Ru 8T2wg8/s43R/PT3kd1OEqOJUl7q+h+r6fpvU0Fzxd2tC8Ga6fDEPme+1Nbi+03pVjuZQKbGw KJ66gEn06WqaxVZC+J8hh/jR0k9mST1iAZPNYulcNJ8tKmVtjYsv0L1TSm2+NwON58tO+pIV zu3DWwSEXSf+qkDavQam+QtEOZxLBXI++aMUEapSn+k3Lxm48ZCYfAWLb/Xj7F5JQMbZvCex glAbYR0kIHqW5DnsYSdMD/IplJMojx0NBrxJ3fN9dvX2Y6BIXRsF1du4qESm4/3CKuyUV7p9 DW3mPlHTGLvYxnyKQy7VFBkoLINszBrOUeIxggPtMIID6QIBATCBlDCBjDELMAkGA1UEBhMC SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENl cnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJ bnRlcm1lZGlhdGUgQ2xpZW50IENBAgMMhpgwDQYJYIZIAWUDBAIBBQCgggIpMBgGCSqGSIb3 DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE1MTAwMjA4NTgxMlowLwYJKoZI hvcNAQkEMSIEII9X+/6Ob/otqQpdzHR5/JWy/W0CZ6Yw+1bp5xG5nOiJMGwGCSqGSIb3DQEJ DzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0D AgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgaUGCSsGAQQB gjcQBDGBlzCBlDCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzAp BgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0 YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgMMhpgwgacG CyqGSIb3DQEJEAILMYGXoIGUMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20g THRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG A1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EC AwyGmDANBgkqhkiG9w0BAQEFAASCAQClvznDdekezuXH1OH9p12NkBRzs7eblnzyq+gTB+PY Cq1e8vhDAPQw2qd+r4+VwXhAT65wm4lbU2CmlbwNeoZGDveLGMAKohvYZCne793unBdpZqAv 8hrL9xoxf8MXlG5w6aRSnYd4fykx6aQKkFhG59nIZuzcpsTXxuPxJa8FVrNvrgpnFbaOjZr6 y1fwCqBcWqFsapP/VmDOSICgVGsEw9OB2aGvqOCV73Ql4wpAhuXMa3Oi65xAWPRmkX0e0IsO wwu3hLk9q0Hrm67WpjA0pKq31rCSf5fc25X4Si+jax7qr+14uurzXlrj4+FPd1X6HRYzi24a wNw6flmGj828AAAAAAAA --------------ms060109000809080707010309-- From nobody Fri Oct 2 03:45:42 2015 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25CB71B29BA for ; Fri, 2 Oct 2015 03:45:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.55 X-Spam-Level: X-Spam-Status: No, score=-1.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id isaPtCeiX9Db for ; Fri, 2 Oct 2015 03:45:39 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C83E1B29C3 for ; Fri, 2 Oct 2015 03:45:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::b]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id t92AjWjq026970; Fri, 2 Oct 2015 12:45:32 +0200 (CEST) Received: from aung.tzi.org (eduroam-pool3-280.wlan.uni-bremen.de [134.102.233.24]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3nS7JX1y9Pz4ngW; Fri, 2 Oct 2015 12:45:32 +0200 (CEST) From: Olaf Bergmann To: "Jim Schaad" References: <088001d0fbf6$e4527480$acf75d80$@augustcellars.com> <000401d0fcc9$4aaa5f90$dfff1eb0$@augustcellars.com> Date: Fri, 02 Oct 2015 12:45:32 +0200 In-Reply-To: <000401d0fcc9$4aaa5f90$dfff1eb0$@augustcellars.com> (Jim Schaad's message of "Thu, 1 Oct 2015 21:17:45 -0700") Message-ID: <87lhbleegj.fsf@aung.informatik.uni-bremen.de> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: =?utf-8?Q?'G=C3=B6ran_Selander'?= , Ace@ietf.org Subject: Re: [Ace] Security properties of CoAP message fields X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 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, 02 Oct 2015 10:45:41 -0000 "Jim Schaad" writes: > What are the benefits of allowing a proxy to change the message type?=20= =20 For proxying between different transports such as UDP-to-TCP, this is a valid use case. > Why would you have a situation where the proxy would change the token? > Why should this happen? The entire value of the token is tied to the > transaction that the client and the server are participating in. > Caching it would make no sense in many cases if the client uses a new > token, because the proxy would not know that it would be in the same > conversation. I guess this is also something related to the alternate transports use case where the token might be used as a pointer to some internal state within the proxy. (Not sure if that makes any sense, though.) Gr=C3=BC=C3=9Fe Olaf From nobody Fri Oct 2 04:15:05 2015 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E55951B2A3D for ; Fri, 2 Oct 2015 04:15:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.55 X-Spam-Level: X-Spam-Status: No, score=-1.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e6jitUaH1DQt for ; Fri, 2 Oct 2015 04:15:02 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 080521B2A3A for ; Fri, 2 Oct 2015 04:15:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::b]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id t92BEu9d005179; Fri, 2 Oct 2015 13:14:56 +0200 (CEST) Received: from aung.tzi.org (eduroam-pool3-280.wlan.uni-bremen.de [134.102.233.24]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3nS7yS6Qdgz4nk0; Fri, 2 Oct 2015 13:14:56 +0200 (CEST) From: Olaf Bergmann To: "Jim Schaad" References: <088001d0fbf6$e4527480$acf75d80$@augustcellars.com> Date: Fri, 02 Oct 2015 13:14:56 +0200 In-Reply-To: <088001d0fbf6$e4527480$acf75d80$@augustcellars.com> (Jim Schaad's message of "Wed, 30 Sep 2015 20:11:39 -0700") Message-ID: <87h9m9ed3j.fsf@aung.informatik.uni-bremen.de> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: Ace@ietf.org Subject: Re: [Ace] Security properties of CoAP message fields X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 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, 02 Oct 2015 11:15:03 -0000 "Jim Schaad" writes: > Options: Protection extended to options is going to be option and possib= ly > dialog specific. > * None: There are/may be options which are expected to be modified in > transit. There are options which may be/are expected to be inserted in > transit. These options cannot have any security protection on them One interesting side note is that when a proxy inserts (or drops?) options for some reason, the delta-encoded option number will change. Gr=C3=BC=C3=9Fe Olaf From nobody Fri Oct 2 04:31:03 2015 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 652BC1B2A7D for ; Fri, 2 Oct 2015 04:31:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.901 X-Spam-Level: X-Spam-Status: No, score=-3.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tq8gNY-HEO_9 for ; Fri, 2 Oct 2015 04:30:59 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A43501B2A79 for ; Fri, 2 Oct 2015 04:30:58 -0700 (PDT) X-AuditID: c1b4fb30-f79626d000006adf-32-560e6af04be4 Received: from ESESSHC005.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 15.02.27359.0FA6E065; Fri, 2 Oct 2015 13:30:56 +0200 (CEST) Received: from ESESSMB303.ericsson.se ([169.254.3.186]) by ESESSHC005.ericsson.se ([153.88.183.33]) with mapi id 14.03.0248.002; Fri, 2 Oct 2015 13:30:56 +0200 From: =?utf-8?B?R8O2cmFuIFNlbGFuZGVy?= To: Olaf Bergmann , Jim Schaad Thread-Topic: [Ace] Security properties of CoAP message fields Thread-Index: AQHQ/P91KORIzqWaSGu1IQAoFf67Fp5YEZkA Date: Fri, 2 Oct 2015 11:30:55 +0000 Message-ID: References: <088001d0fbf6$e4527480$acf75d80$@augustcellars.com> <000401d0fcc9$4aaa5f90$dfff1eb0$@augustcellars.com> <87lhbleegj.fsf@aung.informatik.uni-bremen.de> In-Reply-To: <87lhbleegj.fsf@aung.informatik.uni-bremen.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.7.141117 x-originating-ip: [153.88.183.20] Content-Type: text/plain; charset="utf-8" Content-ID: <6F67BAAB59F26C418A89BB3F71242EAE@ericsson.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprBIsWRmVeSWpSXmKPExsUyM+Jvje6HLL4wg70vLS2+f+thtmha3Mhk sXr6dzYHZo+Nc6azeSxZ8pPJY9qizADmKC6blNSczLLUIn27BK6MP9tfsxec4qno2BfcwLiA p4uRk0NCwERia/8tVghbTOLCvfVsXYxcHEICRxklHt38yQjhLGaUWDXxI1gVm4CLxIOGR0wg toiAp8SvW8eZQWxmAUWJ3bPOsncxcnAIC9hK/P7IA1FiJ7Fn1V9WCNtIYt2uC2wgNouAikTb +s0sIDavgIXEzxN/2CF2XWWUaL54gB0kwSlgLdH15hhYAyPQdd9PrWGC2CUucevJfCaIqwUk luw5zwxhi0q8fPwPbJmogJ7EyutNbBBxRYmr05czgdzGLKApsX6XPsQYa4k9pz+xwJw/pfsh O8Q9ghInZz5hmcAoMQvJtlkI3bOQdM9C0j0LSfcCRtZVjKLFqcVJuelGRnqpRZnJxcX5eXp5 qSWbGIFReXDLb4MdjC+fOx5iFOBgVOLhVXjKGybEmlhWXJl7iFGag0VJnLeZ6UGokEB6Yklq dmpqQWpRfFFpTmrxIUYmDk6pBsbGgK1/T77oilt+Z3XDnHIWpZW/VN9VHzpxrevMpNBj719t WnUmv89df25V40OeXzNkYsymzk249PrA1rhIg8u1Mm7LZZ8+bzsVy7M2djtzVILu5aW7+Yvd rwTppkRPCC9nfvJgv1ybU7bd+uQnzQtEHE3jRa5VsX1WfevHZ7LnJ6eHl4u1+HwlluKMREMt 5qLiRAD7tLPYqwIAAA== Archived-At: Cc: "Ace@ietf.org" Subject: Re: [Ace] Security properties of CoAP message fields X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 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, 02 Oct 2015 11:31:01 -0000 DQoNCk9uIDIwMTUtMTAtMDIgMTI6NDUsICJPbGFmIEJlcmdtYW5uIiA8YmVyZ21hbm5AdHppLm9y Zz4gd3JvdGU6DQoNCj4iSmltIFNjaGFhZCIgPGlldGZAYXVndXN0Y2VsbGFycy5jb20+IHdyaXRl czoNCj4NCj4+IFdoYXQgYXJlIHRoZSBiZW5lZml0cyBvZiBhbGxvd2luZyBhIHByb3h5IHRvIGNo YW5nZSB0aGUgbWVzc2FnZSB0eXBlPw0KPg0KPkZvciBwcm94eWluZyBiZXR3ZWVuIGRpZmZlcmVu dCB0cmFuc3BvcnRzIHN1Y2ggYXMgVURQLXRvLVRDUCwgdGhpcyBpcyBhDQo+dmFsaWQgdXNlIGNh c2UuDQo+DQo+PiBXaHkgd291bGQgeW91IGhhdmUgYSBzaXR1YXRpb24gd2hlcmUgdGhlIHByb3h5 IHdvdWxkIGNoYW5nZSB0aGUgdG9rZW4/DQo+PiBXaHkgc2hvdWxkIHRoaXMgaGFwcGVuPyAgVGhl IGVudGlyZSB2YWx1ZSBvZiB0aGUgdG9rZW4gaXMgdGllZCB0byB0aGUNCj4+IHRyYW5zYWN0aW9u IHRoYXQgdGhlIGNsaWVudCBhbmQgdGhlIHNlcnZlciBhcmUgcGFydGljaXBhdGluZyBpbi4NCj4+ IENhY2hpbmcgaXQgd291bGQgbWFrZSBubyBzZW5zZSBpbiBtYW55IGNhc2VzIGlmIHRoZSBjbGll bnQgdXNlcyBhIG5ldw0KPj4gdG9rZW4sIGJlY2F1c2UgdGhlIHByb3h5IHdvdWxkIG5vdCBrbm93 IHRoYXQgaXQgd291bGQgYmUgaW4gdGhlIHNhbWUNCj4+IGNvbnZlcnNhdGlvbi4NCj4NCj5JIGd1 ZXNzIHRoaXMgaXMgYWxzbyBzb21ldGhpbmcgcmVsYXRlZCB0byB0aGUgYWx0ZXJuYXRlIHRyYW5z cG9ydHMgdXNlDQo+Y2FzZSB3aGVyZSB0aGUgdG9rZW4gbWlnaHQgYmUgdXNlZCBhcyBhIHBvaW50 ZXIgdG8gc29tZSBpbnRlcm5hbCBzdGF0ZQ0KPndpdGhpbiB0aGUgcHJveHkuIChOb3Qgc3VyZSBp ZiB0aGF0IG1ha2VzIGFueSBzZW5zZSwgdGhvdWdoLikNCg0KQXMgZmFyIGFzIEkgdW5kZXJzdGFu ZCwgdGhlcmUgYXJlIGJhc2ljYWxseSBubyBndWFyYW50ZWVzIHRoYXQgYSBwcm94eSBpcw0Kbm90 IGNoYW5naW5nIFR5cGUgb3IgVG9rZW4sIGFuZCB0aGVyZWZvcmUgdGhleSBjYW5ub3QgYmUgaW50 ZWdyaXR5DQpwcm90ZWN0ZWQgYmV0d2VlbiBjbGllbnQgYW5kIHNlcnZlci4gIEkgd291bGQgYWxz byBoYXZlIGxpa2VkIGFuDQplbmQtdG8tZW5kIHRyYW5zYWN0aW9uIGlkZW50aWZpZXIgYnVpbHQg aW50byB0aGUgQ29BUCBtZXNzYWdlLg0KDQpHw7ZyYW4NCg0K From nobody Fri Oct 2 04:44:15 2015 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBA3C1B2A9D for ; Fri, 2 Oct 2015 04:44:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.901 X-Spam-Level: X-Spam-Status: No, score=-3.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lRjtKFbcLMWn for ; Fri, 2 Oct 2015 04:44:12 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6A6A21B2AAE for ; Fri, 2 Oct 2015 04:44:11 -0700 (PDT) X-AuditID: c1b4fb25-f79a26d00000149a-52-560e6e0912a0 Received: from ESESSHC013.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 15.C8.05274.90E6E065; Fri, 2 Oct 2015 13:44:09 +0200 (CEST) Received: from ESESSMB303.ericsson.se ([169.254.3.186]) by ESESSHC013.ericsson.se ([153.88.183.57]) with mapi id 14.03.0248.002; Fri, 2 Oct 2015 13:44:09 +0200 From: =?utf-8?B?R8O2cmFuIFNlbGFuZGVy?= To: Olaf Bergmann , Jim Schaad Thread-Topic: [Ace] Security properties of CoAP message fields Thread-Index: AdD7wXuwKORIzqWaSGu1IQAoFf67FgBQh0wfAAEDDYA= Date: Fri, 2 Oct 2015 11:44:08 +0000 Message-ID: References: <088001d0fbf6$e4527480$acf75d80$@augustcellars.com> <87h9m9ed3j.fsf@aung.informatik.uni-bremen.de> In-Reply-To: <87h9m9ed3j.fsf@aung.informatik.uni-bremen.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.7.141117 x-originating-ip: [153.88.183.17] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprOIsWRmVeSWpSXmKPExsUyM+JvjS5nHl+Ywct3Ohbfv/UwWzQtbmSy WD39O5sDs8fGOdPZPJYs+cnkMW1RZgBzFJdNSmpOZllqkb5dAlfGhueH2AuucFbs6NjJ0sC4 hbOLkZNDQsBE4vStBmYIW0ziwr31bF2MXBxCAkcZJX7++gHlLGaU2HUbJMPJwSbgIvGg4RET iC0i4Cnx69ZxsG5mAUWJ3bPOsncxcnAIC9hK/P7IA1FiJ7Fn1V9WCNtKYu709YwgNouAikT3 oqVgrbwCFhKX3zWC1QgJFEi8/XIUbBWngLXEjAmP2EFsRqDjvp9awwSxSlzi1pP5TBBHC0gs 2XMe6gFRiZeP/4HNERXQk1h5vYkN5BwJoNOW98uBmMwCmhLrd+lDTLGWeHXsNyvM8VO6H7JD XCMocXLmE5YJjBKzkCybhdA9C0n3LCTds5B0L2BkXcUoWpxanJSbbmSsl1qUmVxcnJ+nl5da sokRGJMHt/xW3cF4+Y3jIUYBDkYlHl6Fp7xhQqyJZcWVuYcYpTlYlMR5m5kehAoJpCeWpGan phakFsUXleakFh9iZOLglGpgnHB17497it6qloX/fgQ/3J0Xa8cVd7p+RorpxfPbd0m0JGzR PqZj6nP4d6FWfNvymjtKsq+C3srus8h6Ne0ZA1/e7duyKat7Jwm94Z55k+PMYZFZvNrzEvds 1pz7bcmOB6rpM1bFfu48lfTh39ddxgcKni65VBZubZ8519B0nrej6Ltne00WXFdiKc5INNRi LipOBAArgTw5qgIAAA== Archived-At: Cc: "Ace@ietf.org" Subject: Re: [Ace] Security properties of CoAP message fields X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 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, 02 Oct 2015 11:44:14 -0000 DQoNCk9uIDIwMTUtMTAtMDIgMTM6MTQsICJPbGFmIEJlcmdtYW5uIiA8YmVyZ21hbm5AdHppLm9y Zz4gd3JvdGU6DQoNCj4iSmltIFNjaGFhZCIgPGlldGZAYXVndXN0Y2VsbGFycy5jb20+IHdyaXRl czoNCj4NCj4+IE9wdGlvbnM6ICBQcm90ZWN0aW9uIGV4dGVuZGVkIHRvIG9wdGlvbnMgaXMgZ29p bmcgdG8gYmUgb3B0aW9uIGFuZA0KPj5wb3NzaWJseQ0KPj4gZGlhbG9nIHNwZWNpZmljLg0KPj4g KiAgTm9uZTogIFRoZXJlIGFyZS9tYXkgYmUgb3B0aW9ucyB3aGljaCBhcmUgZXhwZWN0ZWQgdG8g YmUgbW9kaWZpZWQgaW4NCj4+IHRyYW5zaXQuICBUaGVyZSBhcmUgb3B0aW9ucyB3aGljaCBtYXkg YmUvYXJlIGV4cGVjdGVkIHRvIGJlIGluc2VydGVkIGluDQo+PiB0cmFuc2l0LiAgVGhlc2Ugb3B0 aW9ucyBjYW5ub3QgaGF2ZSBhbnkgc2VjdXJpdHkgcHJvdGVjdGlvbiBvbiB0aGVtDQo+DQo+T25l IGludGVyZXN0aW5nIHNpZGUgbm90ZSBpcyB0aGF0IHdoZW4gYSBwcm94eSBpbnNlcnRzIChvciBk cm9wcz8pDQo+b3B0aW9ucyBmb3Igc29tZSByZWFzb24sIHRoZSBkZWx0YS1lbmNvZGVkIG9wdGlv biBudW1iZXIgd2lsbCBjaGFuZ2UuDQoNCldlIHByb3Bvc2UgdG8gaW50ZWdyaXR5IHByb3RlY3Qg dGhlIGRlbHRhLWVuY29kaW5nIG9mIGludGVncml0eSBwcm90ZWN0ZWQNCm9wdGlvbnMgcHJlc2Vu dCBpbiB0aGUgbWVzc2FnZS4gU28gdW5sZXNzIG9uZSBvZiB0aG9zZSBhcmUgZHJvcHBlZCBvcg0K aW5zZXJ0ZWQgdGhpcyB3aWxsIG5vdCBjaGFuZ2UuIChBbmQgaWYgb25lIG9mIHRob3NlIGNhbiBi ZSBkcm9wcGVkIG9yDQppbnNlcnRlZCB3ZSBjYW7igJl0IGhhdmUgdGhhdCBhcyBpbnRlZ3JpdHkg cHJvdGVjdGVkLCBzbyBwbGVhc2UgbGV0IHVzIGtub3chKQ0KDQpHw7ZyYW4NCg0K From nobody Fri Oct 2 06:37:56 2015 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BAED1ACDFB for ; Fri, 2 Oct 2015 06:37:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.301 X-Spam-Level: X-Spam-Status: No, score=-3.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_44=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Le269C1m-m2q for ; Fri, 2 Oct 2015 06:37:52 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0313A1B2B33 for ; Fri, 2 Oct 2015 06:37:51 -0700 (PDT) X-AuditID: c1b4fb2d-f79626d000004282-bc-560e88ad60c4 Received: from ESESSHC007.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 9E.2D.17026.DA88E065; Fri, 2 Oct 2015 15:37:49 +0200 (CEST) Received: from ESESSMB303.ericsson.se ([169.254.3.186]) by ESESSHC007.ericsson.se ([153.88.183.39]) with mapi id 14.03.0248.002; Fri, 2 Oct 2015 15:37:49 +0200 From: =?utf-8?B?R8O2cmFuIFNlbGFuZGVy?= To: Jim Schaad , "Ace@ietf.org" Thread-Topic: [Ace] Security properties of CoAP message fields Thread-Index: AdD7wXuwKORIzqWaSGu1IQAoFf67FgAgEr+AAB2v44AAF7/5gA== Date: Fri, 2 Oct 2015 13:37:48 +0000 Message-ID: References: <088001d0fbf6$e4527480$acf75d80$@augustcellars.com> <000401d0fcc9$4aaa5f90$dfff1eb0$@augustcellars.com> In-Reply-To: <000401d0fcc9$4aaa5f90$dfff1eb0$@augustcellars.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.7.141117 x-originating-ip: [153.88.183.18] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpikeLIzCtJLcpLzFFi42KZGfG3RndtB1+YwexmW4vv33qYLVZP/87m wOSxcc50No8lS34yBTBFcdmkpOZklqUW6dslcGVsfB5UcC+s4s/bM+wNjAdCuhg5OCQETCRm bNTvYuQEMsUkLtxbz9bFyMUhJHCUUeLX6eusEM5iRolPF7cyg1SxCbhIPGh4xARiiwi4SZzv f8UIMkhYwFbi90ceiLCdxJ5Vf1khbCeJSVsfgdksAioSLX9mg7XyClhINMy7yAQxfwnQsq+X 2UASnAIOEs8W7AJrYAS66PupNWANzALiEreezGeCuFRAYsme88wQtqjEy8f/wOpFBfQkVl5v YoOIK0p8fLUP7DZmAU2J9bv0IcZYSyxc+x5qpKLElO6H7BD3CEqcnPmEZQKj+Cwk22YhdM9C 0j0LSfcsJN0LGFlXMYoWpxYX56YbGeulFmUmFxfn5+nlpZZsYgRG2sEtv3V3MK5+7XiIUYCD UYmHV+Epb5gQa2JZcWXuIUZpDhYlcd4WpgehQgLpiSWp2ampBalF8UWlOanFhxiZODilGhi9 3j5e73LMYN2BgNuL2A7ffP70RUTPRUOeR8s6NwjGrpl+2ePupOsNs/t/lTZu3Vy0VM5tX2An o1/5mZdLo97+N441P7FVT+ju6luvxb4s2ccfwLX18pvsvIntfw9lO6/8ccC5ppPvvjcj617J 6TeXPjbQvLjzUKKNV2gEo8HbF8oflf+XdGfeUGIpzkg01GIuKk4EAJEsbB6VAgAA Archived-At: Subject: Re: [Ace] Security properties of CoAP message fields X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 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, 02 Oct 2015 13:37:55 -0000 DQpJbmxpbmUgb24gdGhlIHJlbWFpbmluZyBjb21tZW50cy4NCg0KT24gMjAxNS0xMC0wMiAwNjox NywgIkppbSBTY2hhYWQiIDxpZXRmQGF1Z3VzdGNlbGxhcnMuY29tPiB3cm90ZToNCg0KPg0KPg0K Pj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+IEZyb206IEfDtnJhbiBTZWxhbmRlciBb bWFpbHRvOmdvcmFuLnNlbGFuZGVyQGVyaWNzc29uLmNvbV0NCj4+IFNlbnQ6IFRodXJzZGF5LCBP Y3RvYmVyIDAxLCAyMDE1IDU6MDggQU0NCj4+IFRvOiBKaW0gU2NoYWFkIDxpZXRmQGF1Z3VzdGNl bGxhcnMuY29tPjsgQWNlQGlldGYub3JnDQo+PiBTdWJqZWN0OiBSZTogW0FjZV0gU2VjdXJpdHkg cHJvcGVydGllcyBvZiBDb0FQIG1lc3NhZ2UgZmllbGRzDQo+PiANCj4+IEhpIEppbSwNCj4+IA0K Pj4gQXMgQ2Fyc3RlbiBwb2ludGVkIG91dCwgbXVjaCBvZiB0aGlzIGlzIGNvbnNpZGVyZWQgaW4g QXBwZW5kaXggQSBvZg0KPj4gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQt c2VsYW5kZXItYWNlLW9iamVjdC1zZWN1cml0eQ0KPj4gDQo+PiAoSWYgYW55b25lIGJ5IGNoYW5j ZSBnZXRzIG1vdGl2YXRlZCB0byBhY3R1YWxseSByZWFkIGl0LCBJIHdvdWxkDQo+PnJlY29tbWVu ZCB3YWl0DQo+PiBhIGxpdHRsZSBmb3IgdmVyc2lvbiAtMDMgZm9yIGltcHJvdmVkIHJlYWRhYmls aXR5LikNCj4+IA0KPj4gTm90ZSB0aGF0IEFwcGVuZGl4IEEgYXBwbGllcyB0byBNb2RlOkNPQVAg d2hpY2ggaXMgdGhlIG1vZGUgd2hlcmUNCj4+cGF5bG9hZCwNCj4+IHNlbGVjdGVkIGhlYWRlcnMg YW5kIG9wdGlvbnMgYXJlIHByb3RlY3RlZC4gVGhlcmUgaXMgYWxzbyBhIE1vZGU6UEFZTA0KPj53 aGljaCBpcw0KPj4gb25seSBwcm90ZWN0aW5nIHBheWxvYWQuIERpZmZlcmVudCBNb2RlcyBhcHBs eSB0byBkaWZmZXJlbnQgdXNlIGNhc2VzDQo+PmFzIGlzDQo+PiBleGVtcGxpZmllZCBpbiBzZWN0 aW9uIDIgYW5kIDMgb2YgdGhlIGRyYWZ0IChhbmQgYmVsb3cpLg0KPj4gDQo+PiBDb21tZW50cyBp bmxpbmU6DQo+PiANCj4+IE9uIDIwMTUtMTAtMDEgMDU6MTEsICJKaW0gU2NoYWFkIiA8aWV0ZkBh dWd1c3RjZWxsYXJzLmNvbT4gd3JvdGU6DQo+PiANCj4+ID5UbyBhbmQgRnJvbSBBZGRyZXNzaW5n OiAgT2sgdGhpcyBpcyBub3QgcmVhbGx5IHBhcnQgb2YgdGhlIG1lc3NhZ2UsIEkNCj4+ID5qdXN0 IHdhbnQgdG8gZW5zdXJlIHRoYXQgbm9ib2R5IHRoaW5ncyB0aGF0IHRoaXMgc2hvdWxkIGJlIHBy b3RlY3RlZCBpbg0KPj4gPmFueSB3YXkgYXMgaXQgd2lsbCBiZSBtb2RpZmllZCBpbiB0cmFuc2l0 IGJ5IGFueSBudW1iZXIgb2YgQ29BUCBhbmQgbm9uDQo+PiA+Q29BUCBlbnRpdGllcy4NCj4+IA0K Pj4gV2UgcHJvcG9zZSB0byBpbnRlZ3JpdHkgcHJvdGVjdCBlLmcuIGRlc3RpbmF0aW9uIFVSSSAo dGhlIGNvbnRlbnQgb2YNCj4+dGhlIENvQVANCj4+IE9wdGlvbnMgVXJpLUhvc3QsIFVyaS1Qb3J0 LCBVcmktUGF0aCwgVXJpLVF1ZXJ5KSBpbiB0aGUgQ29BUCByZXF1ZXN0Lg0KPg0KPkJ1dCB0aGVz ZSBhcmUgb3B0aW9ucywgdGhleSBhcmUgbm90IHdoYXQgSSB3b3VsZCBjb25zaWRlciB0byBiZSB0 aGUgdG8NCj5hbmQgZnJvbSBhZGRyZXNzaW5nLiAgVGhpcyBpcyB3aGF0IEkgd291bGQgdGhpbmsg b2YgYXMgdGhlIFVEUCBhZGRyZXNzZXMNCj5wcmVwZW5kZWQgdG8gdGhlIGZyb250LiAgU29ycnkg aWYgSSBkaWQgbm90IG1ha2UgdGhhdCBjbGVhcmVyLg0KDQpTb3JyeSwgSSBkaWRu4oCZdCB1bmRl cnN0YW5kIHRoaXMgcmVwbHk6IERvIHlvdSBzZWUgYSBwcm9ibGVtIHdpdGggaW50ZWdyaXR5DQpw cm90ZWN0aW5nIHRoZXNlIGRlc3RpbmF0aW9uIHBhcmFtZXRlcnMNCg0KLSBVcmktSG9zdCA9IGRl c3RpbmF0aW9uIElQIGFkZHJlc3MNCg0KLSBVcmktUG9ydCA9IGRlc3RpbmF0aW9uIFVEUCBwb3J0 DQoNCg0KPg0KPj4gDQo+PiA+DQo+PiA+Q29BUCB2ZXJzaW9uIG51bWJlcjogIE1heWJlIGludGVn cml0eSBwcm90ZWN0ZWQgLSBJIGRvbid0IHNlZSBhbnkNCj4+ID5iZW5lZml0IGluIGhpZGluZy4N Cj4+IA0KPj4gVGhlIG1pbmQgc2V0IHdlIGhhdmUgaXMgdGhhdCBiZXR3ZWVuIGFueSB0d28gZW5k cG9pbnRzIHdpdGggYSBzZWN1cml0eQ0KPj4gYXNzb2NpYXRpb24gdGhlcmUgbWF5IGluIGdlbmVy YWwgYmUgc29tZSBpbnRlcm1lZGlhdGUgbm9kZXMuIFRoaXMgbWVhbnMNCj4+dGhhdA0KPj4gbWFu eSBvZiB0aGUgaGVhZGVyIHBhcmFtZXRlcnMgZG9lc27igJl0IG1ha2Ugc2Vuc2UgdG8gaW50ZWdy aXR5IHByb3RlY3QsDQo+PiBiZWNhdXNlIHRoZXkgYXJlIG5vdCBwcmVzZXJ2ZWQgZW5kLXRvLWVu ZC4NCj4+IA0KPj4gDQo+PiBGb3IgVmVyc2lvbiB3ZSB3ZXJlIGFjdHVhbGx5IGNvbnNpZGVyaW5n IHRoZSBiZW5lZml0cyBvZiBoYXZpbmcgYSBwcm94eQ0KPj4gdHJhbnNsYXRpbmcgYmV0d2VlbiBk aWZmZXJlbnQgdmVyc2lvbnMsIHRodXMgd2Ugb21pdHRlZCBpbnRlZ3JpdHkNCj4+cHJvdGVjdGlv bg0KPj4gKHdoaWNoIHRoZW4gbmVlZHMgdG8gYmUgY29uc2lkZXJlZCB3aXRoIG5ld2VyIHZlcnNp b24gb2YgQ29BUCBhcHBlYXIgc28NCj4+dGhpcw0KPj4gZG9lcyBub3QgaW50cm9kdWNlIGEgdnVs bmVyYWJpbGl0eSkNCj4NCj5XaGF0IHdvdWxkIGJlIHRoZSBiZW5lZml0cyBvZiBhbGxvdyBmb3Ig YSBwcm94eSB0byBkbyB2ZXJzaW9uIG51bWJlcg0KPmNoYW5naW5nLiAgVGhhdCBwb3RlbnRpYWxs eSBzYXlzIHRoYXQgdGhlIGVudGlyZSBzdHJ1Y3R1cmUgd291bGQgYmUNCj5hbHRlcmVkIGFuZCB0 aGUgbmV3IHRoaW5ncyBtaWdodCBuZWVkIHRvIGJlIChvciB3ZXJlKSBpbnRlZ3JpdHkNCj5wcm90 ZWN0ZWQuICBUaGlzIHdvdWxkIHN0YXJ0IGNhdXNpbmcgZmFpbHVyZXMuDQoNCldlIGhhdmUgcmVj b25zaWRlcmVkIHRoaXMgYW5kIGFncmVlIHRoYXQgdmVyc2lvbiBudW1iZXIgaGFkIGJldHRlciBi ZQ0KaW50ZWdyaXR5IHByb3RlY3RlZC4gV2lsbCBiZSBjaGFuZ2VkIGluIC0wMy4NCg0KDQo+DQo+ PiANCj4+ID4NCj4+ID5Db2RlOiAgSSB0aGluayB0aGF0IHRoaXMgaXMgZ29pbmcgdG8gZGVwZW5k IG9uIHdoYXQgdGhlIGNvZGUgaXMuICBGb3INCj4+ID5DLT5SUw0KPj4gPm1lc3NhZ2VzIGFuZCBw cm9iYWJseSBmb3IgUlMtPkMgc3VjY2VzcyByZXNwb25zZXMgaXQgc2hvdWxkIGJlDQo+PiA+aW50 ZWdyaXR5IHByb3RlY3RlZC4gIEZvciBSUy0+QyBmYWlsdXJlcywgaXQgd291bGQgYmUgZ29vZCB0 byBiZQ0KPj4gPmludGVncml0eSBwcm90ZWN0ZWQuDQo+PiA+Rm9yIFByb3h5LT5DIHJlc3BvbnNl cyBpdCBtaWdodCBub3QgYmUgYWJsZSB0byBiZSBwcm90ZWN0ZWQuICBGb3INCj4+ID5NYWxsb3J5 LT5DDQo+PiA+cmVzcG9uc2VzIGl0IHdvdWxkIG5ldmVyIGJlIHByb3RlY3RlZC4gICBEb2VzIEMg ZG8gZGlmZmVyZW50IHRoaW5ncyBpZg0KPj5hDQo+PiA+cHJvdGVjdGVkIG1lc3NhZ2UgaXMgc2Vu dCBhbmQgYW4gdW5wcm90ZWN0ZWQgbWVzc2FnZSBpcyByZXR1cm5lZD8NCj4+ID4oQXNzdW1lcw0K Pj4gPnRoYXQgQyBhbHdheXMgaW5pdGlhdGVzLikNCj4+IA0KPj4gVGhlIHR3byBNb2RlcyBtZW50 aW9uZWQgYWJvdmUgYWRkcmVzcyB0aGlzIGRpZmZlcmVudGx5Lg0KPj4gDQo+PiBGb3IgTW9kZTpD T0FQIGEgY29tcGxpYW50IG5vZGUgcmVjZWl2aW5nIGEgcHJvdGVjdGVkIHJlcXVlc3QgbXVzdCBz ZW5kIGENCj4+IHByb3RlY3RlZCByZXNwb25zZSwgYW5kIGEgY29tcGxpYW50IG5vZGUgcmVjZWl2 aW5nIHRoZSByZXNwb25zZQ0KPj52ZXJpZnlpbmcgdGhhdA0KPj4gaXQgbWF0Y2hlcyB0aGUgcmVx dWVzdC4gSW4gdGhpcyBjYXNlIENvZGUgaXMgaW50ZWdyaXR5IHByb3RlY3RlZCwgc28NCj4+dGhp cyBtb2RlDQo+PiBhcHBsaWVzIHRvIHRoZSB1c2UgY2FzZXMgd2hlcmUgaXQgaXMgaW1wb3J0YW50 IHRvIGRpc3Rpbmd1aXNoIGUuZy4gR0VUDQo+PmZyb20NCj4+IERFTEVURSBvciB3aGVyZSBpdCBp cyBpbXBvcnRhbnQgdGhhdCByZXNwb25zZSBjb2RlcyBhcmUgaW50ZWdyaXR5DQo+PnByb3RlY3Rl ZCB0bw0KPj4gZW5zdXJlIGNvcnJlY3Qgb3BlcmF0aW9ucyBoYXMgYmVlbiBwZXJmb3JtZWQuDQo+ DQo+U28gd2hhdCB3b3VsZCBoYXBwZW4gaWYgYSBwcm94eSByZXR1cm5zIGFuIGVycm9yIGNvZGUg YmVjYXVzZSBpdCBmaW5kcyBhDQo+cHJvYmxlbSBvZiBzb21lIHR5cGUuICBUaGlzIHdvdWxkIG5v dCBiZSBpbnRlZ3JpdHkgcHJvdGVjdGVkLiAgRG9lcyB0aGUNCj5vcmlnaW5hbCBtZXNzYWdlIGNy ZWF0b3IgaWdub3JlIHRoYXQgZXJyb3IgYmVjYXVzZSBpdCBpcyBub3QgaW50ZWdyaXR5DQo+cHJv dGVjdGVkIGFuZCByZXNlbmQgdGhlIG9yaWdpbmFsIHJlcXVlc3Q/ICBXb3VsZCB5b3UgZW5kIHVw IHdpdGggYSBjYXNlDQo+d2hlcmUgdGhlIGVycm9yIGlzIHJldHVybmVkIGFuZCBpcyBpbnRlZ3Jp dHkgcHJvdGVjdGVkLCBidXQgbm90IHRvIHRoZQ0KPnNhbWUgY29udGV4dD8gIERvZXMgdGhhdCBt YWtlIHlvdSBhY2NlcHQgb3IgcmVqZWN0IHRoZSBtZXNzYWdlPw0KDQpHb29kIHF1ZXN0aW9uLiBU aGlzIGJvaWxzIGRvd24gdG8gd2hhdCB5b3UgZXhwZWN0IGEgcHJveHkgc2hvdWxkIGJlIGFibGUN CnRvIGRvIGFuZCBob3cgbXVjaCB5b3UgdHJ1c3QgaXQuDQoNCklmIHRoZXJlIGlzIG5vIHNlY3Vy aXR5IGFzc29jaWF0aW9uIHdpdGggdGhlIHByb3h5IGl0IGlzIG5vdCBwb3NzaWJsZSB0bw0KdmVy aWZ5IHRoZXNlIGVycm9yIG1lc3NhZ2VzLiBPbmUgb3B0aW9uIGlzIHRvIGlnbm9yZSB0aGVtIGFu ZCByZXRyYW5zbWl0DQpyZXF1ZXN0IHVudGlsIHRpbWVvdXQuIFRoaXMgbWF5IGJlIHRoZSByaWdo dCBiZWhhdmlvdXIgZS5nLiB0byBtZWV0IGFuDQphdHRlbXB0IHRvIERvUyB0aGUgY2xpZW50IHNl bmRpbmcgZmFrZSBlcnJvciBjb2Rlcy4gQWx0ZXJuYXRpdmVseSBvciBpbg0KYWRkaXRpb24gdGhl IGFwcGxpY2F0aW9uIG1heSBhbmFseXNlIGVycm9yIGNvZGUgYmVmb3JlIG9yIGFmdGVyIHRpbWVv dXQNCmFuZCBhdHRlbXB0IHdvcmthcm91bmQgKHRha2luZyBpbnRvIGFjY291bnQgdGhhdCB0aGUg aW5mb3JtYXRpb24gbWF5IGJlDQp3cm9uZykuIFRoaXMgd291bGQgcmVxdWlyZSB0aGF0IHRoZSBj bGllbnQgY2FjaGVzIGEgbWVzc2FnZSBldmVuIGlmIGl0IGlzDQpub3QgYSB2ZXJpZmllZCByZXNw b25zZSB0byB0aGUgcmVxdWVzdC4NCg0KSWYgdGhlcmUgaXMgYSBzZWN1cml0eSBhc3NvY2lhdGlv biB3aXRoIHRoZSBwcm94eSwgdGhlbiB0aGVyZSBhcmUgdmFyaW91cw0KZGlmZmVyZW50IHNjZW5h cmlvcyBmb3IgaG93IHRvIGdhaW4gdHJ1c3R3b3J0aHkgaW5mb3JtYXRpb24gYWJvdXQgdGhlDQpj YXBhYmlsaXRpZXMvc3RhdHVzIGV0Yy4gb2YgdGhlIHByb3h5LCBvciBvdGhlciByZWFzb24gZm9y IHRoZSBwcm94eSBub3QNCnBlcmZvcm1pbmcgdGhlIHJlcXVlc3RlZCBmdW5jdGlvbi4gSSBkb27i gJl0IGtub3cgaWYgdGhlIHByb3h5IHByb3RlY3RpbmcNCnRoZSBlcnJvciBtZXNzYWdlIGlzIGEg Z29vZCB3YXksIHNpbmNlIHRoYXQgd291bGQgcmVxdWlyZSB0aGUgY2xpZW50IHRvDQphY2NlcHQg bW9yZSB0aGFuIG9uZSByZXNwb25zZSBjb250ZXh0IGZvciBhIGdpdmVuIHJlcXVlc3QuDQoNClNv IEnigJltIG5vdCBzdXJlIHdoYXQgaXMgdGhlIGJlc3QgcHJvY2Vzc2luZyByZWNvbW1lbmRhdGlv bnMgaGVyZSwgb3IgaWYgaXQNCnNob3VsZCBiZSBsZWZ0IHRvIGltcGxlbWVudGF0aW9uICh3aXRo IGEgc2VjdXJpdHkgY29uc2lkZXJhdGlvbiBleHBsYWluaW5nDQp0aGUgaXNzdWUpLiBHZW5lcmFs bHkgc3BlYWtpbmcsIEkgdGhpbmsgaGF2aW5nIGNsaWVudC1zZXJ2ZXIgaW50ZWdyaXR5IG9mDQp0 aGUgY29kZSBpcyBhbiBpbXBvcnRhbnQgZmVhdHVyZSBhbmQgSSB3b3VsZCB0cmFkZSB0aGF0IGFn YWluc3QgdGltZWx5DQpwcm94eSBvcGVyYXRpb25zLg0KDQoNCj4NCj4+IA0KPj4gRm9yIE1vZGU6 UEFZTCBvbmx5IHRoZSBwYXlsb2FkIGlzIHByb3RlY3RlZCwgc28gdGhlIGNoYW5nZSBvZiBDb2Rl DQo+PnNob3VsZCBub3QNCj4+IGhhdmUgYSBzZWN1cml0eSBpbXBsaWNhdGlvbi4gSW4gdGhpcyBj YXNlIHRoZXJlIG1heSBiZSBwcm90ZWN0ZWQNCj4+bWVzc2FnZSBpbiBvbmx5DQo+PiBvbmUgZGly ZWN0aW9uLCBlLmcuIGEgR0VUIHJlc3BvbnNlIGNhY2hlZCBhbmQgZm9yd2FyZGVkIHRvIGRpZmZl cmVudA0KPj5yZXF1ZXN0aW5nDQo+PiBjbGllbnRzLg0KPg0KPlRoaXMgYmFzaWNhbGx5IGZhbGxz IGludG8gdGhlIHdvcmxkIG9mIC0ganVzdCBwcm90ZWN0IHRoZSBjb250ZW50Lg0KDQpZZXMuDQoN Cj4gVGhhdCBtaWdodCBhbHNvIGJlIGEgbWl4ZWQgbWVzc2FnZSB3b3JsZCB3aGVyZSB5b3UgY29t YmluZSB0aGUgdHdvDQo+ZGlmZmVyZW50IGZlYXR1cmVzIHdpdGggbXVsdGlwbGUgc2VjdXJpdHkg Y29udGV4dHMuICAoaS5lLiBhbiBlbmNyeXB0ZWQNCj5tZXNzYWdlIGZyb20gYSBzZXJ2ZXIgKFBB WUwpIGFuZCBzaWduZWQgYnkgdGhlIGludGVybWVkaWF0ZSBkYXRhIHNlcnZlcg0KPihDT0FQKS4N Cg0KWWVzLCB0aGUgbW9kZXMgY2FuIGJlIGNvbWJpbmVkIGxpa2UgdGhhdC4gSW4gdGhpcyBjYXNl LCB0aGVyZSB3b3VsZCBiZQ0KYm90aCBhbiBvYmplY3Qgc2VjdXJpdHkgT3B0aW9uIGFuZCB0aGUg Q29udGVudC1Gb3JtYXQNCmluZGljYXRpbmcgdGhhdCB0aGUgcGF5bG9hZCBpcyBhIHByb3RlY3Rl ZCBvYmplY3QuDQoNCg0KDQo+DQo+PiANCj4+ID4NCj4+ID4NCj4+ID5PcHRpb25zOiAgUHJvdGVj dGlvbiBleHRlbmRlZCB0byBvcHRpb25zIGlzIGdvaW5nIHRvIGJlIG9wdGlvbiBhbmQNCj4+ID5w b3NzaWJseSBkaWFsb2cgc3BlY2lmaWMuDQo+PiA+KiAgTm9uZTogIFRoZXJlIGFyZS9tYXkgYmUg b3B0aW9ucyB3aGljaCBhcmUgZXhwZWN0ZWQgdG8gYmUgbW9kaWZpZWQgaW4NCj4+ID50cmFuc2l0 LiAgVGhlcmUgYXJlIG9wdGlvbnMgd2hpY2ggbWF5IGJlL2FyZSBleHBlY3RlZCB0byBiZSBpbnNl cnRlZCBpbg0KPj4gPnRyYW5zaXQuICBUaGVzZSBvcHRpb25zIGNhbm5vdCBoYXZlIGFueSBzZWN1 cml0eSBwcm90ZWN0aW9uIG9uIHRoZW0NCj4+IA0KPj4gV2UgZWxhYm9yYXRlIG9uIHRoaXMgaW4g QXBwZW5kaXggQS4gT25lIGdlbmVyYWwgaW5kaWNhdGlvbiBhcmUgb3B0aW9ucw0KPj50aGF0IGFy ZQ0KPj4gc2FmZS10by1mb3J3YXJkIG1heSBiZSBpbnRlZ3JpdHkgcHJvdGVjdGVkLiBCdXQgZXZl biBpZiBhbiBvcHRpb24gaXMNCj4+bm90IHNhZmUtdG8tDQo+PiBmb3J3YXJkLCB0aGUgY29udGVu dCBvZiB0aGUgb3B0aW9uIG1heSBiZSBpbnRlZ3JpdHkgcHJvdGVjdGVkLiBUaGUNCj4+Y3JpdGlj YWwNCj4+IGRpc3RpbmN0aW9uIHNlZW1zIHRvIGJlIGlmIGFuIG9wdGlvbiBpcyBjaGFuZ2VkIGlu IGEgcHJlZGljdGFibGUgd2F5IHNvDQo+Pml0IGlzDQo+PiBwb3NzaWJsZSB0byBkZWZpbmUgYW4g 4oCcaW52YXJpYW504oCdIHdoaWNoIGNhbiBiZSBpbnRlZ3JpdHkgcHJvdGVjdGVkLg0KPg0KPlRo aXMgbWV0aG9kIHNlZW1zIHRvIGJlIGZyYXVnaHQgd2l0aCBwb3RlbnRpYWwgZXJyb3JzIGFzIG5l dyBvcHRpb25zIGFyZQ0KPmRlZmluZWQuICBBIG5vbi1jcml0aWNhbCBvcHRpb24gd2hpY2ggaXMg bW9kaWZpZWQgaW4gYSB3YXkgbm90IGtub3duIHRvDQo+dGhlIHJlY2lwaWVudCBpcyBnb2luZyB0 byBjYXVzZSBmYWlsdXJlcyB3aXRob3V0IHRoZSBhYmlsaXR5IHRvIGRpYWdub3NlDQo+d2hhdCBp cyB3cm9uZy4gIEJldHdlZW4gbm90IGtub3dpbmcgd2hpY2ggb3B0aW9ucyBtaWdodCBvciBtaWdo dCBub3QgYmUNCj5mb3J3YXJkZWQgYW5kIHdoaWNoIGFyZSBtb2RpZmllZCB2cyB3aGljaCBhcmUg cHJvdGVjdGVkIHNlZW1zIHRvIGJlIGENCj5wcm9ibGVtLg0KDQpJIHdvdWxkIGxpa2UgdG8gdW5k ZXJzdGFuZCB5b3VyIGNvbmNlcm4gYmV0dGVyLCBjb3VsZCB5b3UgcGxlYXNlIG1ha2UgYW4NCmV4 YW1wbGUgYW5kIGluZGljYXRlIGlmIHRoZSBvcHRpb24gaXMgU2FmZS10by1Gb3J3YXJkIG9yIG5v dCwgYW5kIHdoaWNoDQpwYXJ0aWVzIHN1cHBvcnRzIHRoZSBvcHRpb24gYW5kIHdoaWNoIG5vdC4N Cg0KDQpHw7ZyYW4NCg0KDQo= From nobody Fri Oct 2 06:55:00 2015 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D0781B2BA7; Fri, 2 Oct 2015 06:54:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iPTDJEjt30qJ; Fri, 2 Oct 2015 06:54:56 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B779F1B2B9E; Fri, 2 Oct 2015 06:54:56 -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.4.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151002135456.8512.37319.idtracker@ietfa.amsl.com> Date: Fri, 02 Oct 2015 06:54:56 -0700 Archived-At: Cc: ace@ietf.org Subject: [Ace] I-D Action: draft-ietf-ace-usecases-07.txt X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Oct 2015 13:54:58 -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 Working Group of the IETF. Title : ACE use cases Authors : Ludwig Seitz Stefanie Gerdes Goeran Selander Mehdi Mani Sandeep S. Kumar Filename : draft-ietf-ace-usecases-07.txt Pages : 27 Date : 2015-10-02 Abstract: Constrained devices are nodes with limited processing power, storage space and transmission capacities. These devices in many cases do not provide user interfaces and are often intended to interact without human intervention. This document includes a collection of representative use cases for authentication and authorization in constrained environments. These use cases aim at identifying authorization problems that arise during the lifecycle of a constrained device and are intended to provide a guideline for developing a comprehensive authentication and authorization solution for this class of scenarios. Where specific details are relevant, it is assumed that the devices use the Constrained Application Protocol (CoAP) as communication protocol, however most conclusions apply generally. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ace-usecases/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-ace-usecases-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ace-usecases-07 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 Fri Oct 2 06:59:44 2015 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E91A1A00CA for ; Fri, 2 Oct 2015 06:59:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x5n5ZlwhNh83 for ; Fri, 2 Oct 2015 06:59:40 -0700 (PDT) Received: from mail-la0-f50.google.com (mail-la0-f50.google.com [209.85.215.50]) (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 087431A00B1 for ; Fri, 2 Oct 2015 06:59:40 -0700 (PDT) Received: by lafb9 with SMTP id b9so4879258laf.0 for ; Fri, 02 Oct 2015 06:59:38 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:references:to:from:message-id:date :user-agent:mime-version:in-reply-to:content-type; bh=Tj7qlSjpuIMvX9mGQrL9ylRjpDkd+gY5u3qYYOb5Yz0=; b=jR2B4ob83q3mbQ2ntSlSYUuLx0Hmd1LJBQnckQpItPhQL3VNMD0P7BEjuCR6Bi4Qpf VxJynGlwEKCONJuktyClX9d4DD13022noMPt0b7/dd/fXVtI8IryOQ08mtiVgCPB8UKH CPYa/IaicPMf2k/okni+PcCER8DDx6f89S69Inm12chqU0gicrWQ4X2QLR7I8gE+yNlG U/Y/hV3U93OFYN25MLh4HBk9oiSBXg1YJoJIhnUePJolrbgXXXlJvDslqFYdaBSZbXge LEJxStHuD9DTu2/YpdVbvbC5dL7Ydpqt/9pFZyah+DHOi+WjPCL6GgEPbkjRScE44Ndz FK2w== X-Gm-Message-State: ALoCoQk/S+sBPq8vBJ0qQd0eLelq01JEaidJr0yOMGzsqRQCADiSHQlbcKe4YMMUbYoYct4m35Mc X-Received: by 10.112.147.232 with SMTP id tn8mr3748274lbb.84.1443794378306; Fri, 02 Oct 2015 06:59:38 -0700 (PDT) Received: from [192.168.0.108] ([85.235.11.178]) by smtp.gmail.com with ESMTPSA id f8sm1554979lff.28.2015.10.02.06.59.37 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 02 Oct 2015 06:59:37 -0700 (PDT) References: <20151002135456.8512.90775.idtracker@ietfa.amsl.com> To: "ace@ietf.org" From: Ludwig Seitz X-Forwarded-Message-Id: <20151002135456.8512.90775.idtracker@ietfa.amsl.com> Message-ID: <560E8DC8.3020306@sics.se> Date: Fri, 2 Oct 2015 15:59:36 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <20151002135456.8512.90775.idtracker@ietfa.amsl.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms090800030808080102040808" Archived-At: Subject: [Ace] Fwd: New Version Notification for draft-ietf-ace-usecases-07.txt X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 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, 02 Oct 2015 13:59:42 -0000 This is a cryptographically signed message in MIME format. --------------ms090800030808080102040808 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Hello, I've submitted a new version of the usecases draft to respond to most of = the review comments. What's missing: -Review of the Privacy Considerations (by Hannes) -Changes to address the comments by Abhinav Somaraju @Kathleen: We (Steffi and me) have tried to address your point about the = "Authorization Problems" sections, but I'm not sure I nailed it. I'd be=20 grateful if you could check these again. Regards, Ludwig -------- Forwarded Message -------- Subject: New Version Notification for draft-ietf-ace-usecases-07.txt Date: Fri, 02 Oct 2015 06:54:56 -0700 A new version of I-D, draft-ietf-ace-usecases-07.txt has been successfully submitted by Ludwig Seitz and posted to the IETF repository. Name: draft-ietf-ace-usecases Revision: 07 Title: ACE use cases Document date: 2015-10-02 Group: ace Pages: 27 URL:=20 https://www.ietf.org/internet-drafts/draft-ietf-ace-usecases-07.txt Status: https://datatracker.ietf.org/doc/draft-ietf-ace-usecases/= Htmlized: https://tools.ietf.org/html/draft-ietf-ace-usecases-07 Diff: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ace-usecas= es-07 Abstract: Constrained devices are nodes with limited processing power, storage space and transmission capacities. These devices in many cases do not provide user interfaces and are often intended to interact without human intervention. This document includes a collection of representative use cases for authentication and authorization in constrained environments. These use cases aim at identifying authorization problems that arise during= the lifecycle of a constrained device and are intended to provide a guideline for developing a comprehensive authentication and authorization solution for this class of scenarios. Where specific details are relevant, it is assumed that the devices use the Constrained Application Protocol (CoAP) as communication protocol, however most conclusions apply generally. =20 Please note that it may take a couple of minutes from the time of submiss= ion until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat --------------ms090800030808080102040808 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 DFQwggYYMIIFAKADAgECAgMMhpgwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYw FAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZp Y2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJt ZWRpYXRlIENsaWVudCBDQTAeFw0xNTAxMDgwODM5MDZaFw0xNjAxMDkyMjQxMzBaMDgxFzAV BgNVBAMMDmx1ZHdpZ0BzaWNzLnNlMR0wGwYJKoZIhvcNAQkBFg5sdWR3aWdAc2ljcy5zZTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMVB4rAuq4FxbARxwRqPLpc/3C194F+V H4XMKK6fu3Y8zDLijzNSjh6tG41oZhXvJcvAs1nZNjUutNLeyBAUFiYhy7HXNdlKpjbMEFKQ +6KpEdZ0Rk+pXgB2E1mqZEfp3M2djcQ/h+7uGVlSGYNAxYk6rWPIIWBx2GMvAQaHP4xxu/F+ PiSQILOVzmtIFZe1t/Lw71aaNeMYVhARo8z5PVsVoq6gBeujxfiRLtiQ/S8xW6RKvNvUkVyT BQfcKaEDZR9FENNf9rFgiAcT6R7hI8RBf1d2fxdlbDU8uM72K3fvzGDt8N9Bfm1kDWbDBxJE 1taRIYs+60D1kwV6DvBb9MECAwEAAaOCAtQwggLQMAkGA1UdEwQCMAAwCwYDVR0PBAQDAgSw MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAdBgNVHQ4EFgQU6ryrKahJtBOEdbIL AAWCpOsQyagwHwYDVR0jBBgwFoAUU3Ltkpzg2ssBXHx+ljVO8tS4UYIwGQYDVR0RBBIwEIEO bHVkd2lnQHNpY3Muc2UwggFMBgNVHSAEggFDMIIBPzCCATsGCysGAQQBgbU3AQIDMIIBKjAu BggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjCB9wYIKwYB BQUHAgIwgeowJxYgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwAwIBARqBvlRo aXMgY2VydGlmaWNhdGUgd2FzIGlzc3VlZCBhY2NvcmRpbmcgdG8gdGhlIENsYXNzIDEgVmFs aWRhdGlvbiByZXF1aXJlbWVudHMgb2YgdGhlIFN0YXJ0Q29tIENBIHBvbGljeSwgcmVsaWFu Y2Ugb25seSBmb3IgdGhlIGludGVuZGVkIHB1cnBvc2UgaW4gY29tcGxpYW5jZSBvZiB0aGUg cmVseWluZyBwYXJ0eSBvYmxpZ2F0aW9ucy4wNgYDVR0fBC8wLTAroCmgJ4YlaHR0cDovL2Ny bC5zdGFydHNzbC5jb20vY3J0dTEtY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEF BQcwAYYtaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczEvY2xpZW50L2NhMEIG CCsGAQUFBzAChjZodHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MxLmNs aWVudC5jYS5jcnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqG SIb3DQEBBQUAA4IBAQBl8BbG0n7+JjFqiJOuAqMbkeqM6Oyd+4oHGu3fbaSiM1SKesae2bfm vifV99a+M4DERZ2SVkOYcvNlv31Q3hvYtzRjDOqewzVKxo021R3ddQULW1DhvTEpclikG5rd 0NRJQn+EkSwEKLeUj68i0dhU8ULhZDDq3A81cTcZzIGrTjNnwDvCktB/sF/iO4At6RJ24P3j KjYFPirW3NsvZ2gzZizSzeubPE0/cWcqEBJ/UtaFPF54efejjLuPRHHMLPDcvrwBhEiBxuG6 oTEo465g4pS9Vo/Z0GoZgZyA+aGQ+YPbPSsqsYmSBjZ6MGGDqQq0niE2dW+8IOdHQvMkqI52 MIIGNDCCBBygAwIBAgIBHjANBgkqhkiG9w0BAQUFADB9MQswCQYDVQQGEwJJTDEWMBQGA1UE ChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUg U2lnbmluZzEpMCcGA1UEAxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwHhcN MDcxMDI0MjEwMTU1WhcNMTcxMDI0MjEwMTU1WjCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoT DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUg Q2xpZW50IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAxwmDzM4t2BqxKaQu E6uWvooyg4ymiEGWVUet1G8SD+rqvyNH4QrvnEIaFHxOhESip7vMz39ScLpNLbL1QpOlPW/t FIzNHS3qd2XRNYG5Sv9RcGE+T4qbLtsjjJbi6sL7Ls/f/X9ftTyhxvxWkf8KW37iKrueKsxw 2HqolH7GM6FX5UfNAwAu4ZifkpmZzU1slBhyWwaQPEPPZRsWoTb7q8hmgv6Nv3Hg9rmA1/VP BIOQ6SKRkHXG0Hhmq1dOFoAFI411+a/9nWm5rcVjGcIWZ2v/43Yksq60jExipA4l5uv9/+Hm 33mbgmCszdj/Dthf13tgAv2O83hLJ0exTqfrlwIDAQABo4IBrTCCAakwDwYDVR0TAQH/BAUw AwEB/zAOBgNVHQ8BAf8EBAMCAQYwHQYDVR0OBBYEFFNy7ZKc4NrLAVx8fpY1TvLUuFGCMB8G A1UdIwQYMBaAFE4L7xqkQFulF2mHMMo0aEPQQa7yMGYGCCsGAQUFBwEBBFowWDAnBggrBgEF BQcwAYYbaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL2NhMC0GCCsGAQUFBzAChiFodHRwOi8v d3d3LnN0YXJ0c3NsLmNvbS9zZnNjYS5jcnQwWwYDVR0fBFQwUjAnoCWgI4YhaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vc2ZzY2EuY3JsMCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNv bS9zZnNjYS5jcmwwgYAGA1UdIAR5MHcwdQYLKwYBBAGBtTcBAgEwZjAuBggrBgEFBQcCARYi aHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEFBQcCARYoaHR0cDov L3d3dy5zdGFydHNzbC5jb20vaW50ZXJtZWRpYXRlLnBkZjANBgkqhkiG9w0BAQUFAAOCAgEA CoMIfXirLAZcuGOMXq4cuSN3TaFx2H2GvD5VSy/6rV55BYHbWNaPeQn3oBSU8KgQZn/Kck1J xbLpAxVCNtsxeW1R87ifhsYZ0qjdrA9anrW2MAWCtosmAOT4OxK9QPoSjCMxM3HbkZCDJgnl E8jMopH21BbyAYr7b5EfGRQJNtgWcvqSXwKHnTutR08+Kkn0KAkXCzeQNLeA5LlYUzFyM7kP Ap8pIRMQ+seHunmyG642S2+y/qHEdMuGIwpfz3eDF1PdctL04qYK/zu+Qg1Bw0RwgigVZs/0 c5HP2/e9DBHh7eSwtzYlk4AUr6yxLlcwSjOfOmKEQ/Q8tzh0IFiNu9IPuTGAPBn4CPxD0+Ru 8T2wg8/s43R/PT3kd1OEqOJUl7q+h+r6fpvU0Fzxd2tC8Ga6fDEPme+1Nbi+03pVjuZQKbGw KJ66gEn06WqaxVZC+J8hh/jR0k9mST1iAZPNYulcNJ8tKmVtjYsv0L1TSm2+NwON58tO+pIV zu3DWwSEXSf+qkDavQam+QtEOZxLBXI++aMUEapSn+k3Lxm48ZCYfAWLb/Xj7F5JQMbZvCex glAbYR0kIHqW5DnsYSdMD/IplJMojx0NBrxJ3fN9dvX2Y6BIXRsF1du4qESm4/3CKuyUV7p9 DW3mPlHTGLvYxnyKQy7VFBkoLINszBrOUeIxggPtMIID6QIBATCBlDCBjDELMAkGA1UEBhMC SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENl cnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJ bnRlcm1lZGlhdGUgQ2xpZW50IENBAgMMhpgwDQYJYIZIAWUDBAIBBQCgggIpMBgGCSqGSIb3 DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE1MTAwMjEzNTkzNlowLwYJKoZI hvcNAQkEMSIEINnw9BPlxnJ+byqYJzIKPXP4BRHH5q3lSW9KoT2KIJHLMGwGCSqGSIb3DQEJ DzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0D AgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgaUGCSsGAQQB gjcQBDGBlzCBlDCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzAp BgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0 YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgMMhpgwgacG CyqGSIb3DQEJEAILMYGXoIGUMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20g THRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG A1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EC AwyGmDANBgkqhkiG9w0BAQEFAASCAQBTX9dOiwNhzzc1DnxYOBxgpAgNVb/Nh+ImTgPYh4Di LinrI6DvnfpNoS8rXF7Ffv/jsfxlyc5MUMxfR1Dsz+tO8/sLelxYeOa9d68rsHOiQcA5Ze5K Md6U34bY9oGiE/RhURKuFR8brDKcRYNmtHyyHco1UCM5vJNs0AufPq9rdmm1nXpRRSTHOsma aZUYreLNVFUT/tVgzB/5uCCQ9BRUs1j6Vz3xf7/+plK4AyoPjnECnifxrHHgNPSeaUf5QM5f aUwuF2tY6msYAb7kvtynBJCS+qECY4G7rDhoSIzSIVQMwRD3dIoSxe2XVqNOBoCxugidyW5+ c3kUlO0PHQTDAAAAAAAA --------------ms090800030808080102040808-- From nobody Fri Oct 2 07:26:45 2015 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3DD61A1BA5 for ; Fri, 2 Oct 2015 07:26:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j7mR4q0PwZUO for ; Fri, 2 Oct 2015 07:26:42 -0700 (PDT) Received: from mail-wi0-x236.google.com (mail-wi0-x236.google.com [IPv6:2a00:1450:400c:c05::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 DAEBF1A1BE3 for ; Fri, 2 Oct 2015 07:26:41 -0700 (PDT) Received: by wicfx3 with SMTP id fx3so36175855wic.1 for ; Fri, 02 Oct 2015 07:26:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=6aqTKXURKmw3M4Ptd8NeJScU5CP94/bzju0jYQz/nA0=; b=HzyFRjMsjNPETqbX1vbYZhqChppYOQ+k0iO+cwZr+kXM676BY1TULo6qNWW+Fqgwk/ QCOQGean3fjCXWU1FTCIWhiWeXncB4HBI66+X3FCBKW/ByTQV9zq8Q3q06fatTdAAL3x S8j9URUNbmNJRbrRNOl/OKzONmzOYhWc3Cy+p81LoGA0Z/Yt+g+oTKaqn9zZPZ/m3y8b hs+8u3383sFFCtm7n2wQ6pbhvKOG/rAUbNwsxGWzlFIPmltES+b6kcftOcZHdsxFYQ4g /no7kqZEQUvGb8pPp8qtQMD8HyqAcmJwBacWeGmf1wlrF7oonh7SptzzCW/Uq3/lJpHK 8olA== MIME-Version: 1.0 X-Received: by 10.180.9.74 with SMTP id x10mr4396747wia.61.1443796000332; Fri, 02 Oct 2015 07:26:40 -0700 (PDT) Received: by 10.28.214.213 with HTTP; Fri, 2 Oct 2015 07:26:40 -0700 (PDT) In-Reply-To: <560E8DC8.3020306@sics.se> References: <20151002135456.8512.90775.idtracker@ietfa.amsl.com> <560E8DC8.3020306@sics.se> Date: Fri, 2 Oct 2015 10:26:40 -0400 Message-ID: From: Kathleen Moriarty To: Ludwig Seitz Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "ace@ietf.org" Subject: Re: [Ace] Fwd: New Version Notification for draft-ietf-ace-usecases-07.txt X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 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, 02 Oct 2015 14:26:43 -0000 Ludwig & Steffi, Thanks for your work turing this around. Can we get the other suggested changes in within the next few days? I think the use case changes from Abhinav Somaraju would be important before last call. The privacy ones really must be in before IESG review or it will get snagged there. I'd like to start IETF Last Call by Tuesday to have this draft through IESG review and approved before the next meeting. I'll read through the revision again later today. Thank you, Kathleen On Fri, Oct 2, 2015 at 9:59 AM, Ludwig Seitz wrote: > Hello, > > I've submitted a new version of the usecases draft to respond to most of the > review comments. > > What's missing: > -Review of the Privacy Considerations (by Hannes) > -Changes to address the comments by Abhinav Somaraju > > @Kathleen: We (Steffi and me) have tried to address your point about the > "Authorization Problems" sections, but I'm not sure I nailed it. I'd be > grateful if you could check these again. > > Regards, > > Ludwig > > > -------- Forwarded Message -------- > Subject: New Version Notification for draft-ietf-ace-usecases-07.txt > Date: Fri, 02 Oct 2015 06:54:56 -0700 > > A new version of I-D, draft-ietf-ace-usecases-07.txt > has been successfully submitted by Ludwig Seitz and posted to the > IETF repository. > > Name: draft-ietf-ace-usecases > Revision: 07 > Title: ACE use cases > Document date: 2015-10-02 > Group: ace > Pages: 27 > URL: https://www.ietf.org/internet-drafts/draft-ietf-ace-usecases-07.txt > Status: https://datatracker.ietf.org/doc/draft-ietf-ace-usecases/ > Htmlized: https://tools.ietf.org/html/draft-ietf-ace-usecases-07 > Diff: https://www.ietf.org/rfcdiff?url2=draft-ietf-ace-usecases-07 > > Abstract: > Constrained devices are nodes with limited processing power, storage > space and transmission capacities. These devices in many cases do > not provide user interfaces and are often intended to interact > without human intervention. > > This document includes a collection of representative use cases for > authentication and authorization in constrained environments. These > use cases aim at identifying authorization problems that arise during > the lifecycle of a constrained device and are intended to provide a > guideline for developing a comprehensive authentication and > authorization solution for this class of scenarios. > > Where specific details are relevant, it is assumed that the devices > use the Constrained Application Protocol (CoAP) as communication > protocol, however most conclusions apply generally. > > > > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > The IETF Secretariat > > > > > > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace > -- Best regards, Kathleen From nobody Fri Oct 2 08:18:22 2015 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E5791A7007 for ; Fri, 2 Oct 2015 08:18:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UWXQ8fp3AaWs for ; Fri, 2 Oct 2015 08:18:13 -0700 (PDT) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0785.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::785]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D4D161A6FE7 for ; Fri, 2 Oct 2015 08:18:12 -0700 (PDT) Received: from DBXPR04CA0020.eurprd04.prod.outlook.com (10.141.8.148) by AMSPR04MB212.eurprd04.prod.outlook.com (10.242.84.24) with Microsoft SMTP Server (TLS) id 15.1.280.20; Fri, 2 Oct 2015 15:17:53 +0000 Received: from DB3FFO11FD011.protection.gbl (2a01:111:f400:7e04::178) by DBXPR04CA0020.outlook.office365.com (2a01:111:e400:9414::20) with Microsoft SMTP Server (TLS) id 15.1.286.20 via Frontend Transport; Fri, 2 Oct 2015 15:17:53 +0000 Authentication-Results: spf=none (sender IP is 23.103.247.180) smtp.mailfrom=philips.com; tridonic.com; dkim=none (message not signed) header.d=none;tridonic.com; dmarc=none action=none header.from=philips.com; Received-SPF: None (protection.outlook.com: philips.com does not designate permitted sender hosts) Received: from 011-smtp-out.Philips.com (23.103.247.180) by DB3FFO11FD011.mail.protection.outlook.com (10.47.216.167) with Microsoft SMTP Server (TLS) id 15.1.286.14 via Frontend Transport; Fri, 2 Oct 2015 15:17:53 +0000 Received: from DB5PR9001MB0167.MGDPHG.emi.philips.com (141.251.190.211) by DB5PR9001MB0165.MGDPHG.emi.philips.com (141.251.190.209) with Microsoft SMTP Server (TLS) id 15.1.256.15; Fri, 2 Oct 2015 15:17:51 +0000 Received: from DB5PR9001MB0167.MGDPHG.emi.philips.com ([141.251.190.211]) by DB5PR9001MB0167.MGDPHG.emi.philips.com ([141.251.190.211]) with mapi id 15.01.0243.024; Fri, 2 Oct 2015 15:17:50 +0000 From: "Kumar, Sandeep" To: Somaraju Abhinav , "Ace@ietf.org" Thread-Topic: [ACE] review draft-ietf-ace-usecases-06 Thread-Index: AdD8XTFdDVkUObPhQvi/FvrOxuHgzQAwVt6w Date: Fri, 2 Oct 2015 15:17:50 +0000 Message-ID: References: <0E9A48AB39AF3547ACD28A6DE3E2906A0AB169@ATBRAGMSX02.itiso.net> In-Reply-To: <0E9A48AB39AF3547ACD28A6DE3E2906A0AB169@ATBRAGMSX02.itiso.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [194.171.252.100] Content-Type: multipart/alternative; boundary="_000_c65a5f304e9d402f975bcc900eacaf85DB5PR9001MB0167MGDPHGem_" MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Microsoft-Exchange-Diagnostics: 1; DB3FFO11FD011; 1:zXdWvQacPpcfV+/XWq8QN9R7XROlyc78pcqRy8SckBmYi+OfepN00U1K9to/X9sIu8+M4wytTswlL5/yyp5oYLL+hY9KRDDqTYY6jSlYbqcaugxIjjZsYyzlSNmilBNfcHL+95vVOCBVmtnzujN8jcdGnaooYZROdxL5vA11HtwFbZ6ZF7pyEvF2bHelo+gdEKqWkS+cZvwTzqYvgZjTGBAGI1HEMxUQSAREyNQ6jeEyQgZnTaCZpDJ3WFIIlqVQUSakMnuvljrUVdbDTYr3dTy2z2GT1ZB5EJhnLV3iBaNMRXEOi5gRI1qQZpcyyKfgHauTdSZUPYBTO4TQI/Hzmw== X-Forefront-Antispam-Report: CIP:23.103.247.180; CTRY:; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(2980300002)(428002)(374574003)(189002)(55904004)(45074003)(53754006)(199003)(85714005)(377454003)(11100500001)(87936001)(5001770100001)(97736004)(5001860100001)(4001540100001)(77156002)(10400500002)(5001830100001)(24736003)(92566002)(69596002)(81156007)(5004730100002)(16796002)(15975445007)(5007970100001)(66066001)(2950100001)(64706001)(19580395003)(102836002)(46102003)(5890100001)(2501003)(68736005)(2900100001)(6806005)(108616004)(54356999)(19580405001)(84326002)(101416001)(5008740100001)(62966003)(230783001)(76176999)(50986999)(86362001)(512954002)(105586002)(19300405004)(5003600100002)(106466001)(107886002)(5001960100002)(16236675004)(19625215002)(189998001)(33646002)(567094001); DIR:OUT; SFP:1102; SCL:1; SRVR:AMSPR04MB212; H:011-smtp-out.Philips.com; FPR:; SPF:None; PTR:InfoDomainNonexistent; MX:1; A:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; AMSPR04MB212; 2:pN5aCtLkAkOK0xUE/D0NMbRixQ7HnaIwCQZ+S5iLBhf+ZZEZ6EED+Ww2iZucwuAukaxNkutBXXLGs5yPkl+W8oHCueoBbVOyHgdnDnZSoGt/hdBzl2bGx1iAaBq1rws6+FLkdj8IwUUBtcSm/Os9PQbOZ6Pm9gsluLy674mRC0k=; 3:OXiSjFCPbTyxDngDnFK9rLF9RYlppe0IANpMJ9NjpXP/1ngJVPek+yRYQh+7EMm4CWNNgqdTEQ2Pd7nYu0KKwjdpYhPZlAOjQ9cS57qrnPIAlF0cbZ1k3o1fwx28v4Qwpuj6nyBUmPN9joooSGOtwfk+DCvgsA/5ZqdXwIycD+kDIHBRvk+pexXQ8VjI/nuxXZPSD98x1kUu8VkqHhqqfavgdb9MU2h+kuPrRvb/wUw=; 25:f1WhBXGiPKyyxFz4gbfOwAXdRWxqVj3Ra8rsyR3MLPFjU8YfxZGjrXu8EbG59mmtERxSW8umx3j7f5lmS+nEHEOIZxP2xlazXI/71DEYtggNGlCfupZzlCAUandCV8h8hkjS/aT0sx2eqETY4g3pf+UF6Xvf9Bi+bighmPX8a8a6xxbI83ev8uWjy7rNsM43PT6Udx1tLH19nkaERdALZ2f06/UgbzfOrV7pEmGDJoFFd4HLhnbM7OGKjgy1OesfMnauM/SrltKby+YyaHiQgQ== X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:AMSPR04MB212; X-Microsoft-Exchange-Diagnostics: 1; AMSPR04MB212; 20:Sqzj0LCG5U9TmTOY3+197qdjUjE2s9ngYzu2h7feCYmftrgYVzITd0BPESN4xdhj4fqXxVEo5T0/8baL3lrC6Rx0SelZk2HiKvgzZ17aLHJEvJRoZ0j/B1SZYjhxH1znKmws45+TgGAMCYfmEwkKngQFUhaz2V0xyH7AjukH4pZNrt9rSux4IaiODsgafJfcUpsyOyH0D4jCW/kTox243tvE2v88LUQZBMcLedKnhhTYHWc4U2I61xkwu9msS1J2QRjJg5/llq2ohYokSpLnX/XcF1tjRaGRUhyM4r8Y2Z7/xjNv/QoAQDPoOm0xVANHxhcIgglMz1/LL3F8agVl4o1K5hhgMPDp708Jftjy608+e40J2h3TbRBTnDE2sB+tOgrRhfZLDmUMvwuaJ6KQhX0sFVvh9iJlIiFDHODfj+zhNY/xAhdrtDQwidgFj4WdzYi9/N7XyVsmQ+e2Rk5KODsYJHcTN9gOK7VDtSIwupuNN8W/XIL6GRyt/eHkys7f; 4:43nb9Li5TQH0T2sY7OJCrKW1G7TWlyNO+ZUfPEA/o6Q8D9xWqYlu+BUhZoyXBxh3BaEwouyV7ESG0YCI0OB4/VJkgARd940NvE+RgleXGLjQpNTPdKIs0eJkljFRdMMjV/+3dq8JWplal49tATuSBeiFbPpYrQRs/C4FWz7FLy2RNpzVaaqm7F6fIASTH1dah188DRL2G0RpcXew8f9kQdg2rG/JLzEwBMjOQzAPldkTAfWotPQ4liQJ0ROB5s6fBxyb/b0TTFTXqthPHm5xX0MAcYbK3ZOee63i3vRjzyUp/gGo1nzpyjwiw8MKW98R1Ah4wiMyHyRQQYC8w0dfsZP2KdXcjqrz9w1IIQxCZXc= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(108003899814671); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(520078)(8121501046)(3002001); SRVR:AMSPR04MB212; BCL:0; PCL:0; RULEID:; SRVR:AMSPR04MB212; X-Forefront-PRVS: 0717E25089 X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; AMSPR04MB212; 23:E5FeJ4RsuB4OIYeZY6PZfA8VEgBTxYcMyZsmhZMptd?= =?us-ascii?Q?E+R5BkCkVjxesebnUhTegcXjhREAjV2YHnWmw8vwOOrSU1/1EKdjNf7DM73V?= =?us-ascii?Q?V8ztxoDzdonKSzD9DhiSeE7rsUgdMWtHFKkuz0TttC9hNs/vProUIZ+43D7V?= =?us-ascii?Q?R4vX80RGGK0AO9UCFCC/JgVSbA7It3gZ3e8vyelqWYv0BqwguQZLVbcwEupk?= =?us-ascii?Q?B9aDJV2wyxwijiP7q6f09JCIMDauntBd4wabDjM1RrVSk3RYFEVhHFw37/Mw?= =?us-ascii?Q?jAOEEl+JrgJpVNyDrMLSpsBuVPs2oJqTOniLgaXilNZTTfsrivRDw1UhPRaQ?= =?us-ascii?Q?JOTeXqDKFVW9F5YGVJWOQYF8Ej338x+jEsSpIJokZM+o5gDLtNjjJCg84Mkh?= =?us-ascii?Q?+xrTUnmeSUqxVg7d2GuRuE2AdQr6U+Bj8NC3c2+0WZrfzesfU5YSOY1giKqp?= =?us-ascii?Q?mLO9rEXc4MZaUF55UqK9GdkjLSTXetMdJZmfYbQR6J/kItTCwrHdOlAHcsno?= =?us-ascii?Q?pIaa45ZV5UwIiiKgCy/Ss1bdT50uuQCfGcGe47w8iRE8AbCvWX5+VbG5YQw+?= =?us-ascii?Q?V9RJbqGGlHJDyOoA6WPU0ad8yr6nZ1CRpohuMYl1x1HvKh7b/dsIXxNC+tX/?= =?us-ascii?Q?+ihaWZuYY+Vx7e29tLkLP1nL9YWoLUCyuORae9bUSuDi/WgV/nOnoxe7Lgs5?= =?us-ascii?Q?FRBRdqKtcvqq794mU1LCEdCFu8H1AUy1vp8S9zUE/bSbYKKMqpunNO9Hki1R?= =?us-ascii?Q?iP6nCAd8x0UEq+SaIZ9duILEjnLorUL14aaCu9G92Dsi4XX/CJo54woW2TxZ?= =?us-ascii?Q?lmSj2yFhLN32aw2um4EmqqOd4c9rJU3WhlO0UVhAwqGWb4f45Sn9N9TD4PS5?= =?us-ascii?Q?HKxrSMpQ0WdnkrX7N3GGzgiOELnUwuEsa3iWh+PJj+yaXCU5+IHY7Vp+g2pr?= =?us-ascii?Q?DoCCYOTSyvaIezMZTcFf18e7rvBcBxn5x4p/PJ/1ylnQhUEEnZMRXoOxYGoK?= =?us-ascii?Q?cCLZ813ustHutYoWaJ62oy5pMK3/E/hngNRwjcLhKLar7IqdRA8mYqZcT0Cp?= =?us-ascii?Q?ht7gldnWhwsByvmSUZSRZTmhZwV7gRlqj+kLfN68lp7mmtpHln5sS4PvrgoQ?= =?us-ascii?Q?Mlenfv20DwS5SbLdcfFw+P4PF7VZ77dLBHgTPyZtlB1hLF4eAAwnWdonA3VJ?= =?us-ascii?Q?NfSZ+bvs/AkwCTvT7K7OFz7DBiP5on6AhBY7U+yXTfxZG8FCO+F8Bk/hXH78?= =?us-ascii?Q?3IqfjpNeXk6DW6LlX4mSh+hv4znDW2PmyPXrd/6v9fZJPashu9fZZtZAI36l?= =?us-ascii?Q?Y+moWhyQQTqg6wj75ctyzFVUR35Zttl8FV/tSm+Scta+ogu1FWjRK7SZxKSo?= =?us-ascii?Q?HTXxTU0G7AR6AryJ6JdzVLx2WpyowTFhJPcoTuSHp1zGWOCaA4guo7TDwiW+?= =?us-ascii?Q?fwrWTRo4XQRLjbWDD6ANtYfCltwwkhucpeEyVhzcb8NCIh0s+OEQ+euDWpSn?= =?us-ascii?Q?IhgZBbNi57Lb4nLKnQeq3SPV7UpChr/A0068WNNXiu/EwcSpQmYUsm64ctYO?= =?us-ascii?Q?NDrAw1Mh45aYiw3XoP0lx0c7a8dDFsuoKbGkIvL7pHRSvcKxAakmN7ZJxALI?= =?us-ascii?Q?zDvJxsfENdLjgEu4LyCruouccynP6nxJ3oujrZkVKKHiqtVCa8e7QrfoiKeD?= =?us-ascii?Q?v4?= X-Microsoft-Exchange-Diagnostics: 1; AMSPR04MB212; 5:XJuXF7Tz5300M0L6WapoNlil3y2xDNIx/BmVAk32QWr2fQilREaFrXZbpldaNtEtU+6zfMS4d+Igl8v04it3lWh24PJGA65f+7U3nkUrT9cusACSY5RDWA83SUzH5N4wHef6FNJuNPqMYCOVrk72zQ==; 24:qkcbWKFYe4YxKTwMedXReLVWaAwcomP5oeYSpGiR6Z+UcmcSi7yhb1YHFWosNFgQsdTmMte5r/IVlWh/LwoZCtd+vkiT3Oy1daBDLA2/BSw=; 20:O+TLg1p2jyVNoy00Q1v0jz/6ullEZg7tvUvI0HVKnL02ngip/dINTaZcYP1+XqUSOedVq7imwbd+RC5RDKuzXg== SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: philips.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 02 Oct 2015 15:17:53.1026 (UTC) X-MS-Exchange-CrossTenant-Id: 1a407a2d-7675-4d17-8692-b3ac285306e4 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=1a407a2d-7675-4d17-8692-b3ac285306e4; Ip=[23.103.247.180]; Helo=[011-smtp-out.Philips.com] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: AMSPR04MB212 Archived-At: Subject: Re: [Ace] [ACE] review draft-ietf-ace-usecases-06 X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 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, 02 Oct 2015 15:18:21 -0000 --_000_c65a5f304e9d402f975bcc900eacaf85DB5PR9001MB0167MGDPHGem_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Abhinav See comments inline From: Ace [mailto:ace-bounces@ietf.org] On Behalf Of Somaraju Abhinav Sent: Thursday, October 01, 2015 5:29 PM To: Ace@ietf.org Subject: [Ace] [ACE] review draft-ietf-ace-usecases-06 Hi All, Please see below my review of the use-cases draft. Regards, Abhinav Page 3, last paragraph: "We assume that the communication between the devic= es is based on the Representational State Transfer (REST) architectural style, i.e. a device acts as a server that offers resources such as sensor data and actuators". Is this true for all interactions in the constrained world? For several eve= nt driven systems, does it not make sense to also support some "RPC" like f= eatures? In some of the models we are looking at in the indoor professional= lighting domain, it is planned to use CoAP POST to execute an action and n= ot to create a new resource. The remaining comments I have are only regarding the Building Automation us= ecase because of my background working for an Indoor professional lighting = company. Sec. 2.4.1.1. "A vacant area of the building has been recently leased to co= mpany A. Before moving into its new office, Company A wishes to replace the lighting with a more energy efficient and a better light quality luminaries. They hire an installation and commissioning company C to redo the illumination." >From my knowledge of Building automation and professional lighting this sce= nario is highly unlikely. Usually a leasing company hires a space and the l= ights come as package with the space and are built into the leasing company= 's contract. If the leasing company wishes to change the luminaires they ty= pically have to speak to the (representative of) the building owner but thi= s is quite rare. There are some specific regions in the world e.g. central = EU where this is not always the case. Sometimes in central EU, the building= s do not have any built in luminaires and the leasing companies bring in th= eir own freestanding luminaires. It is very rarely the case that a leasing = tenant hires a contractor to change the lighting system. The situations is = more complicated for HVAC systems which often need to satisfy regulatory re= quirements. HVAC systems are often done building wide and are very rarely t= enant specific. [> ] You are right about the current status in certain central European cou= ntries regarding how office space leasing is done. I have taken a more gene= ral approach to include issues from other domains like retail where indoor = lighting is tied closely to the branding independent of where they lease th= eir space. Instead of creating multiple use cases or geographic specific ca= ses, I took a practical approach to extend the office scenario that can exp= lain what type of issues may be relevant in professional lighting in differ= ent related domains. This way technology developed in ACE is the not the bl= ocking factor for end-users to demand a different choice than they have tod= ay. Does the extension bother you regarding how it would guide the solution= direction making it inapplicable in your more restricted setting? A very important aspect of the installation/commissioning workflow has been= overlooked. Typically, installation in the building occur in the following= order (in a new building). 1) Installation of the lighting devices by an u= ntrained electrician, 2) A lighting commissioning engineer who configures l= ights 3) Installation of HVAC systems 4) First presence of trained IT profe= ssionals. So, the initial commissioning/installation process needs to be performed by= people with no IT knowledge and with the IT backbone not being present. Al= so, the commissioning goes in phases with different floors being commission= ed at different times and then later connected together with the IT backbon= e. Not having the IT backbone during commissioning puts big constraints bec= ause it is difficult to use public key certs during this process. [> ] Indeed true regarding no IT connectivity to devices and forming indivi= dual islands before joining them for a new installation. I think I had it i= n the previous version but it changed after it combined with the HVAC use c= ase. The current description is more shifted towards an already up and run= ning system which changes ownership. I can include in those things. Do you = see other authorization problems that needs to be added based on the change= ? I do not know if it directly means "no public key certs" since the commissi= oning tool can potentially be connected to a backend. Another point is that Authorization rules may also be role based. E.g. A co= mmissioner/facility manager might be able to configure devices but a user m= ay only be able to dim up/down the lights. [> ] That sounds more like the choice of solution rather than an authorizat= ion problem. 2.4.1.3 Maintenance The roles of a facility manager and commissioner (at least in building spea= k) are confused here. Depending on the type of building, there is a facilit= y manager who takes care of issues during the device operation. If changes = are required the facility manager is usually able to make the changes. The = facility manager is sometimes the same individual as the commissioner but n= ot always. We need to put procedures in place so that the commissioner who = commissions at the start can "hand-over" the system to the facility manager= . [> ] The current text does imply a handover to the facility manager (the se= rvice company) since the commissioner needs new authorization to make chang= es during the maintenance stage. Do you have any specific authorization pro= blems in mind by the "hand over" which is not already covered in U4.2 (if y= ou could change the name of the actors). The most common maintenance issue that occur is that of replacing broken de= vices. Therefore, the "authorizations" need to be transferred to the replac= ement device. [> ] This is a good one but needs to be detailed in terms of how much inter= action is needed from the one doing the transfer. It should be less than no= rmal commissioning U4.1 but cannot be zero-configuration either. Any text i= s welcome. A phase that occurs several times and not covered in this use case is recom= missioning. This may occur in several situations: 1) when one tenant moves = out and a new one moves in, 2) Changes in the office space, 3) removing a d= evice from one system and adding it to another [> ] I tried to leave this phase out since I did not see any new authorizat= ion problems (the whole use case is kind of depicted as a recommissioning).= The point of the document is not to explain lighting but to guide the solu= tion development. If you think any new authorization problems need to be ad= ded, we can include this phase. Please let me know. Regards Sandeep ________________________________________________________ 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. ________________________________ The information contained in this message may be confidential and legally p= rotected under applicable law. The message is intended solely for the addre= ssee(s). If you are not the intended recipient, you are hereby notified tha= t any use, forwarding, dissemination, or reproduction of this message is st= rictly prohibited and may be unlawful. If you are not the intended recipien= t, please contact the sender by return e-mail and destroy all copies of the= original message. --_000_c65a5f304e9d402f975bcc900eacaf85DB5PR9001MB0167MGDPHGem_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Abhinav =

 

See comments inline

 

From: Ace [mailto:ace-bounces@ietf.org] On= Behalf Of Somaraju Abhinav
Sent: Thursday, October 01, 2015 5:29 PM
To: Ace@ietf.org
Subject: [Ace] [ACE] review draft-ietf-ace-usecases-06

 

Hi All,
 
Please see below my review of the u=
se-cases draft. 
 
Regards,
Abhinav
 
Page 3, last paragraph: „We assume that the communication between the device=
s is based on the

  = ; Representational State Transfer (REST) architectural style, i.e. a

  = ; device acts as a server that offers resources such as sensor data and

  = ; actuators”.

Is this tru= e for all interactions in the constrained world? For several event driven s= ystems, does it not make sense to also support some “RPC” like features? In some of the models we are looking at i= n the indoor professional lighting domain, it is planned to use CoAP POST t= o execute an action and not to create a new resource.

 =

The remaini= ng comments I have are only regarding the Building Automation usecase becau= se of my background working for an Indoor professional lighting company.

 = 

Sec. 2.=
4.1.1. “A vacant area of the building has been recently leased to com=
pany A.
 &=
nbsp; Before moving into its new office, Company A wishes to replace the
 &=
nbsp; lighting with a more energy efficient and a better light quality=

 &=
nbsp; luminaries.  They hire an installation and commissioning company=
 C to
 &=
nbsp; redo the illumination.”
&n=
bsp;
From my=
 knowledge of Building automation and professional lighting this scenario i=
s highly unlikely. Usually a leasing company hires a space and the lights c=
ome as package with the space and are built into the leasing company’=
s contract. If the leasing company wishes to change the luminaires they typ=
ically have to speak to the (representative of) the building owner but this=
 is quite rare. There are some specific regions in the world e.g. central E=
U where this is not always the case. Sometimes in central EU, the buildings=
 do not have any built in luminaires and the leasing companies bring in the=
ir own freestanding luminaires. It is very rarely the case that a leasing t=
enant hires a contractor to change the lighting system. The situations is m=
ore complicated for HVAC systems which often need to satisfy regulatory req=
uirements. HVAC systems are often done building wide and are very rarely te=
nant specific. 
=
 
[> ] You ar=
e right about the current status in certain central European countries rega=
rding how office space leasing is done. I have taken a more general approac=
h to include issues from other domains like retail where indoor lighting is=
 tied closely to the branding independent of where they lease their space. =
Instead of creating multiple use cases or geographic specific cases, I took=
 a practical approach to extend the office scenario that can explain what t=
ype of issues may be relevant in professional lighting in different related=
 domains. This way technology developed in ACE is the not the blocking fact=
or for end-users to demand a different choice than they have today. Does th=
e extension bother you regarding how it would guide the solution direction =
making it inapplicable in your more restricted setting? <=
/i>
 
A very =
important aspect of the installation/commissioning workflow has been overlo=
oked. Typically, installation in the building occur in the following order =
(in a new building). 1) Installation of the lighting devices by an untraine=
d electrician, 2) A lighting commissioning engineer who configures lights 3=
) Installation of HVAC systems 4) First presence of trained IT professional=
s. 
=
 
So, the=
 initial commissioning/installation process needs to be performed by people=
 with no IT knowledge and with the IT backbone not being present. Also, the=
 commissioning goes in phases with different floors being commissioned at d=
ifferent times and then later connected together with the IT backbone. Not =
having the IT backbone during commissioning puts big constraints because it=
 is difficult to use public key certs during this process. 
=
 
[> ] Indeed=
 true regarding no IT connectivity to devices and forming individual island=
s before joining them for a new installation. I think I had it in the previ=
ous version but it changed after it combined with the HVAC use case.  =
The current description is more shifted towards an already up and running s=
ystem which changes ownership. I can include in those things. Do you see ot=
her authorization problems that needs to be added based on the change?=

I do not know =
if it directly means “no public key certs” since the commission=
ing tool can potentially be connected to a backend. <=
/b>
 
Another=
 point is that Authorization rules may also be role based. E.g. A commissio=
ner/facility manager might be able to configure devices but a user may only=
 be able to dim up/down the lights. 
=
 
[> ] That s=
ounds more like the choice of solution rather than an authorization problem=
.
 
2.4.1.3=
 Maintenance
The rol=
es of a facility manager and commissioner (at least in building speak) are =
confused here. Depending on the type of building, there is a facility manag=
er who takes care of issues during the device operation. If changes are req=
uired the facility manager is usually able to make the changes. The facilit=
y manager is sometimes the same individual as the commissioner but not alwa=
ys. We need to put procedures in place so that the commissioner who commiss=
ions at the start can “hand-over” the system to the facility ma=
nager.
=
 
[> ] The cu=
rrent text does imply a handover to the facility manager (the service compa=
ny) since the commissioner needs new authorization to make changes during t=
he maintenance stage. Do you have any specific authorization problems in mi=
nd by the “hand over” which is not already covered in U4.2 (if =
you could change the name of the actors).
 
The mos=
t common maintenance issue that occur is that of replacing broken devices. =
Therefore, the “authorizations” need to be transferred to the r=
eplacement device.
=
 
[> ] This i=
s a good one but needs to be detailed in terms of how much interaction is n=
eeded from the one doing the transfer. It should be less than normal commis=
sioning U4.1 but cannot be zero-configuration either. Any text is welcome.<=
/span>
&n=
bsp;
A phase=
 that occurs several times and not covered in this use case is recommiss=
ioning. This may occur in several situations: 1) when one tenant moves =
out and a new one moves in, 2) Changes in the office space, 3) removing a d=
evice from one system and adding it to another
=
 
[> ] I trie=
d to leave this phase out since I did not see any new authorization problem=
s (the whole use case is kind of depicted as a recommissioning). The point =
of the document is not to explain lighting but to guide the solution develo=
pment. If you think any new authorization problems need to be added, we can=
 include this phase. Please let me know. 
 
Regards
Sandeep=

&n=
bsp;

________________________________________________= ________ The contents of this e-mail and any attachments are confidential t= o the intended recipient. They may not be disclosed to or used by or copied in any way by anyone other than the intended recip= ient. If this e-mail is received in error, please immediately notify the se= nder 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 sca= n or otherwise check this e-mail and any attachments.


The information contained in= this message may be confidential and legally protected under applicable la= w. The message is intended solely for the addressee(s). If you are not the = intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message i= s strictly prohibited and may be unlawful. If you are not the intended reci= pient, please contact the sender by return e-mail and destroy all copies of= the original message.
 --_000_c65a5f304e9d402f975bcc900eacaf85DB5PR9001MB0167MGDPHGem_-- From nobody Fri Oct 2 08:42:55 2015 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66BC31B2BFC for ; Fri, 2 Oct 2015 08:42:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5kK_IeoVbo3B for ; Fri, 2 Oct 2015 08:42:54 -0700 (PDT) Received: from smtp1.pacifier.net (smtp1.pacifier.net [64.255.237.171]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB8721B2C64 for ; Fri, 2 Oct 2015 08:41:55 -0700 (PDT) Received: from hebrews (winery.augustcellars.com [206.212.239.129]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp1.pacifier.net (Postfix) with ESMTPSA id DF1D32CA25; Fri, 2 Oct 2015 08:41:54 -0700 (PDT) From: "Jim Schaad" To: "'Olaf Bergmann'" References: <088001d0fbf6$e4527480$acf75d80$@augustcellars.com> <000401d0fcc9$4aaa5f90$dfff1eb0$@augustcellars.com> <87lhbleegj.fsf@aung.informatik.uni-bremen.de> In-Reply-To: <87lhbleegj.fsf@aung.informatik.uni-bremen.de> Date: Fri, 2 Oct 2015 08:39:24 -0700 Message-ID: <008801d0fd28$8454bf10$8cfe3d30$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 15.0 Content-Language: en-us Thread-Index: AQIA+rdZxwtn1JgbSnMW0+oRVOSQ3QHyk6HxAjvLSxgBZ92YFJ3LqY+A Archived-At: Cc: =?UTF-8?Q?'G=C3=B6ran_Selander'?= , Ace@ietf.org Subject: Re: [Ace] Security properties of CoAP message fields X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 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, 02 Oct 2015 15:42:55 -0000 > -----Original Message----- > From: Olaf Bergmann [mailto:bergmann@tzi.org] > Sent: Friday, October 02, 2015 3:46 AM > To: Jim Schaad > Cc: 'G=C3=B6ran Selander' ; Ace@ietf.org > Subject: Re: [Ace] Security properties of CoAP message fields >=20 > "Jim Schaad" writes: >=20 > > What are the benefits of allowing a proxy to change the message = type? >=20 > For proxying between different transports such as UDP-to-TCP, this is = a valid use > case. Are there examples in a document that describe this? Jim >=20 > Gr=C3=BC=C3=9Fe > Olaf From nobody Fri Oct 2 08:44:03 2015 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB4171B2C4F for ; Fri, 2 Oct 2015 08:44:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AOxP2M1G5X9c for ; Fri, 2 Oct 2015 08:44:00 -0700 (PDT) Received: from smtp2.pacifier.net (smtp2.pacifier.net [64.255.237.172]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 40E0D1B2C2B for ; Fri, 2 Oct 2015 08:44:00 -0700 (PDT) Received: from hebrews (winery.augustcellars.com [206.212.239.129]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp2.pacifier.net (Postfix) with ESMTPSA id CADC82C9FD; Fri, 2 Oct 2015 08:43:59 -0700 (PDT) From: "Jim Schaad" To: "'Olaf Bergmann'" References: <088001d0fbf6$e4527480$acf75d80$@augustcellars.com> <87h9m9ed3j.fsf@aung.informatik.uni-bremen.de> In-Reply-To: <87h9m9ed3j.fsf@aung.informatik.uni-bremen.de> Date: Fri, 2 Oct 2015 08:41:29 -0700 Message-ID: <008901d0fd28$cebff470$6c3fdd50$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 15.0 Content-Language: en-us Thread-Index: AQIA+rdZxwtn1JgbSnMW0+oRVOSQ3QGt2dNonertImA= Archived-At: Cc: Ace@ietf.org Subject: Re: [Ace] Security properties of CoAP message fields X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 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, 02 Oct 2015 15:44:01 -0000 > -----Original Message----- > From: Olaf Bergmann [mailto:bergmann@tzi.org] > Sent: Friday, October 02, 2015 4:15 AM > To: Jim Schaad > Cc: Ace@ietf.org > Subject: Re: [Ace] Security properties of CoAP message fields >=20 > "Jim Schaad" writes: >=20 > > Options: Protection extended to options is going to be option and > > possibly dialog specific. > > * None: There are/may be options which are expected to be modified > > in transit. There are options which may be/are expected to be > > inserted in transit. These options cannot have any security > > protection on them >=20 > One interesting side note is that when a proxy inserts (or drops?) = options for > some reason, the delta-encoded option number will change. I don't think this is a big deal as we can use the absolute option = number in constructing the authentication string. Jim >=20 > Gr=C3=BC=C3=9Fe > Olaf From nobody Fri Oct 2 08:51:45 2015 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 593861A7012 for ; Fri, 2 Oct 2015 08:51:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.7 X-Spam-Level: X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_44=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jRbktO8xYZh1 for ; Fri, 2 Oct 2015 08:51:43 -0700 (PDT) Received: from smtp1.pacifier.net (smtp1.pacifier.net [64.255.237.171]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EC6031B2C48 for ; Fri, 2 Oct 2015 08:51:42 -0700 (PDT) Received: from hebrews (winery.augustcellars.com [206.212.239.129]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp1.pacifier.net (Postfix) with ESMTPSA id 7AD572CA25; Fri, 2 Oct 2015 08:51:42 -0700 (PDT) From: "Jim Schaad" To: =?UTF-8?Q?'G=C3=B6ran_Selander'?= , References: <088001d0fbf6$e4527480$acf75d80$@augustcellars.com> <000401d0fcc9$4aaa5f90$dfff1eb0$@augustcellars.com> In-Reply-To: Date: Fri, 2 Oct 2015 08:49:12 -0700 Message-ID: <008a01d0fd29$e2841da0$a78c58e0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 15.0 Content-Language: en-us Thread-Index: AQIA+rdZxwtn1JgbSnMW0+oRVOSQ3QHyk6HxAjvLSxgCCuYlJJ3GkjkA Archived-At: Subject: Re: [Ace] Security properties of CoAP message fields X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 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, 02 Oct 2015 15:51:44 -0000 > -----Original Message----- > From: G=C3=B6ran Selander [mailto:goran.selander@ericsson.com] > Sent: Friday, October 02, 2015 6:38 AM > To: Jim Schaad ; Ace@ietf.org > Subject: Re: [Ace] Security properties of CoAP message fields >=20 >=20 > Inline on the remaining comments. >=20 > On 2015-10-02 06:17, "Jim Schaad" wrote: >=20 > > > > > >> -----Original Message----- > >> From: G=C3=B6ran Selander [mailto:goran.selander@ericsson.com] > >> On 2015-10-01 05:11, "Jim Schaad" wrote: > >> > >> >To and From Addressing: Ok this is not really part of the = message, > >> >I just want to ensure that nobody things that this should be > >> >protected in any way as it will be modified in transit by any = number > >> >of CoAP and non CoAP entities. > >> > >> We propose to integrity protect e.g. destination URI (the content = of > >>the CoAP Options Uri-Host, Uri-Port, Uri-Path, Uri-Query) in the = CoAP > >>request. > > > >But these are options, they are not what I would consider to be the = to > >and from addressing. This is what I would think of as the UDP > >addresses prepended to the front. Sorry if I did not make that = clearer. >=20 > Sorry, I didn=E2=80=99t understand this reply: Do you see a problem = with integrity > protecting these destination parameters >=20 > - Uri-Host =3D destination IP address >=20 > - Uri-Port =3D destination UDP port >=20 I was looking at the address headers in a UDP message or TCP message. = What you are describing are options. Options are protected as if they = are options not as if they are an IP address placed on the front of a = packet which gets changed as it progresses through various routers. = These are not properly part of a CoAP message. If you are familiar with email - think of the difference between a To = header in an SMTP header, and the RCPT SMTP command. The first can be = authenticated, but does not necessarily have anything to do with the = RCPT address (think BCC). >=20 > > > >> > >> > > >> >Code: I think that this is going to depend on what the code is. > >> >For > >> >C->RS > >> >messages and probably for RS->C success responses it should be > >> >integrity protected. For RS->C failures, it would be good to be > >> >integrity protected. > >> >For Proxy->C responses it might not be able to be protected. For > >> >Mallory->C > >> >responses it would never be protected. Does C do different = things if > >>a > >> >protected message is sent and an unprotected message is returned? > >> >(Assumes > >> >that C always initiates.) > >> > >> The two Modes mentioned above address this differently. > >> > >> For Mode:COAP a compliant node receiving a protected request must > >>send a protected response, and a compliant node receiving the > >>response verifying that it matches the request. In this case Code = is > >>integrity protected, so this mode applies to the use cases where it > >>is important to distinguish e.g. GET from DELETE or where it is > >>important that response codes are integrity protected to ensure > >>correct operations has been performed. > > > >So what would happen if a proxy returns an error code because it = finds > >a problem of some type. This would not be integrity protected. Does > >the original message creator ignore that error because it is not > >integrity protected and resend the original request? Would you end = up > >with a case where the error is returned and is integrity protected, = but > >not to the same context? Does that make you accept or reject the = message? >=20 > Good question. This boils down to what you expect a proxy should be = able to do > and how much you trust it. >=20 > If there is no security association with the proxy it is not possible = to verify these > error messages. One option is to ignore them and retransmit request = until > timeout. This may be the right behaviour e.g. to meet an attempt to = DoS the > client sending fake error codes. Alternatively or in addition the = application may > analyse error code before or after timeout and attempt workaround = (taking into > account that the information may be wrong). This would require that = the client > caches a message even if it is not a verified response to the request. >=20 > If there is a security association with the proxy, then there are = various different > scenarios for how to gain trustworthy information about the = capabilities/status > etc. of the proxy, or other reason for the proxy not performing the = requested > function. I don=E2=80=99t know if the proxy protecting the error = message is a good way, > since that would require the client to accept more than one response = context > for a given request. >=20 > So I=E2=80=99m not sure what is the best processing recommendations = here, or if it > should be left to implementation (with a security consideration = explaining the > issue). Generally speaking, I think having client-server integrity of = the code is an > important feature and I would trade that against timely proxy = operations. >=20 >=20 Agreed. This is hard. It needs to be considered, discussed and written = down. > > > >> > >> > > >> > > >> >Options: Protection extended to options is going to be option and > >> >possibly dialog specific. > >> >* None: There are/may be options which are expected to be = modified > >> >in transit. There are options which may be/are expected to be > >> >inserted in transit. These options cannot have any security > >> >protection on them > >> > >> We elaborate on this in Appendix A. One general indication are > >>options that are safe-to-forward may be integrity protected. But = even > >>if an option is not safe-to- forward, the content of the option may > >>be integrity protected. The critical distinction seems to be if an > >>option is changed in a predictable way so it is possible to define = an > >>=E2=80=9Cinvariant=E2=80=9D which can be integrity protected. > > > >This method seems to be fraught with potential errors as new options > >are defined. A non-critical option which is modified in a way not > >known to the recipient is going to cause failures without the ability > >to diagnose what is wrong. Between not knowing which options might = or > >might not be forwarded and which are modified vs which are protected > >seems to be a problem. >=20 > I would like to understand your concern better, could you please make = an > example and indicate if the option is Safe-to-Forward or not, and = which parties > supports the option and which not. This may take a while as I am going to need to understand the CoAP = options much better to give a concrete example. I am currently thinking = in the world of possibilities not the real world. Jim >=20 >=20 > G=C3=B6ran >=20 From nobody Fri Oct 2 08:52:30 2015 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9833B1A7012 for ; Fri, 2 Oct 2015 08:52:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.55 X-Spam-Level: X-Spam-Status: No, score=-1.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qoXIGzxsburW for ; Fri, 2 Oct 2015 08:52:27 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C28411ACCF0 for ; Fri, 2 Oct 2015 08:52:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [134.102.201.11]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id t92FqJRA014966; Fri, 2 Oct 2015 17:52:19 +0200 (CEST) Received: from aung.tzi.org (eduroam-pool3-280.wlan.uni-bremen.de [134.102.233.24]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3nSG6W3QXbz4pSG; Fri, 2 Oct 2015 17:52:19 +0200 (CEST) From: Olaf Bergmann To: "Jim Schaad" References: <088001d0fbf6$e4527480$acf75d80$@augustcellars.com> <000401d0fcc9$4aaa5f90$dfff1eb0$@augustcellars.com> <87lhbleegj.fsf@aung.informatik.uni-bremen.de> <008801d0fd28$8454bf10$8cfe3d30$@augustcellars.com> Date: Fri, 02 Oct 2015 17:52:18 +0200 In-Reply-To: <008801d0fd28$8454bf10$8cfe3d30$@augustcellars.com> (Jim Schaad's message of "Fri, 2 Oct 2015 08:39:24 -0700") Message-ID: <878u7lclot.fsf@aung.informatik.uni-bremen.de> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: =?utf-8?Q?'G=C3=B6ran_Selander'?= , Ace@ietf.org Subject: Re: [Ace] Security properties of CoAP message fields X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 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, 02 Oct 2015 15:52:28 -0000 "Jim Schaad" writes: >> -----Original Message----- >> From: Olaf Bergmann [mailto:bergmann@tzi.org] >> Sent: Friday, October 02, 2015 3:46 AM >> To: Jim Schaad >> Cc: 'G=C3=B6ran Selander' ; Ace@ietf.org >> Subject: Re: [Ace] Security properties of CoAP message fields >>=20 >> "Jim Schaad" writes: >>=20 >> > What are the benefits of allowing a proxy to change the message type? >>=20 >> For proxying between different transports such as UDP-to-TCP, this >> is a valid use >> case. > > Are there examples in a document that describe this? Not really examples. There is an ongoing discussion about [0] where Section 4 proposes two alternative formats for the CoAP base header that must use NON as the message type (hence removing retransmissions and ACKs that are not necessary for reliable transport). The third alternative presented there even removes the message type from the (CoAP/TCP) base header entirely. (There has been a lengthy discussion about eliding CON+ACK from CoAP+TCP but I am not sure if that has lead to a final conclusion by now.) [0] https://tools.ietf.org/html/draft-tschofenig-core-coap-tcp-tls Gr=C3=BC=C3=9Fe Olaf From nobody Fri Oct 2 08:53:57 2015 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B60371B2C51 for ; Fri, 2 Oct 2015 08:53:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.55 X-Spam-Level: X-Spam-Status: No, score=-1.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hEJT-5rDBi6W for ; Fri, 2 Oct 2015 08:53:55 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D65171A86EB for ; Fri, 2 Oct 2015 08:53:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [134.102.201.11]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id t92FrnWG019462; Fri, 2 Oct 2015 17:53:49 +0200 (CEST) Received: from aung.tzi.org (eduroam-pool3-280.wlan.uni-bremen.de [134.102.233.24]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3nSG8F4F0Cz4pSJ; Fri, 2 Oct 2015 17:53:49 +0200 (CEST) From: Olaf Bergmann To: "Jim Schaad" References: <088001d0fbf6$e4527480$acf75d80$@augustcellars.com> <87h9m9ed3j.fsf@aung.informatik.uni-bremen.de> <008901d0fd28$cebff470$6c3fdd50$@augustcellars.com> Date: Fri, 02 Oct 2015 17:53:49 +0200 In-Reply-To: <008901d0fd28$cebff470$6c3fdd50$@augustcellars.com> (Jim Schaad's message of "Fri, 2 Oct 2015 08:41:29 -0700") Message-ID: <874mi9clma.fsf@aung.informatik.uni-bremen.de> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: Ace@ietf.org Subject: Re: [Ace] Security properties of CoAP message fields X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 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, 02 Oct 2015 15:53:55 -0000 "Jim Schaad" writes: >> One interesting side note is that when a proxy inserts (or drops?) >> options for >> some reason, the delta-encoded option number will change. > > I don't think this is a big deal as we can use the absolute option > number in constructing the authentication string. Yes, meaning that it must be constructed before message serialization. Hm.... Gr=C3=BC=C3=9Fe Olaf From nobody Fri Oct 2 11:51:31 2015 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 026B31B3155 for ; Fri, 2 Oct 2015 11:51:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KmCwSnHBkLA8 for ; Fri, 2 Oct 2015 11:51:25 -0700 (PDT) Received: from smtp3.pacifier.net (smtp3.pacifier.net [64.255.237.177]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB5831B3150 for ; Fri, 2 Oct 2015 11:51:24 -0700 (PDT) Received: from hebrews (winery.augustcellars.com [206.212.239.129]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp3.pacifier.net (Postfix) with ESMTPSA id 2CA1C38F0F; Fri, 2 Oct 2015 11:51:24 -0700 (PDT) From: "Jim Schaad" To: "'Olaf Bergmann'" References: <088001d0fbf6$e4527480$acf75d80$@augustcellars.com> <000401d0fcc9$4aaa5f90$dfff1eb0$@augustcellars.com> <87lhbleegj.fsf@aung.informatik.uni-bremen.de> <008801d0fd28$8454bf10$8cfe3d30$@augustcellars.com> <878u7lclot.fsf@aung.informatik.uni-bremen.de> In-Reply-To: <878u7lclot.fsf@aung.informatik.uni-bremen.de> Date: Fri, 2 Oct 2015 11:48:54 -0700 Message-ID: <00db01d0fd42$fcfa5f00$f6ef1d00$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 15.0 Content-Language: en-us Thread-Index: AQIA+rdZxwtn1JgbSnMW0+oRVOSQ3QHyk6HxAjvLSxgBZ92YFADQ05wJAcqB72+dtwOYgA== Archived-At: Cc: =?UTF-8?Q?'G=C3=B6ran_Selander'?= , Ace@ietf.org Subject: Re: [Ace] Security properties of CoAP message fields X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 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, 02 Oct 2015 18:51:29 -0000 > -----Original Message----- > From: Olaf Bergmann [mailto:bergmann@tzi.org] > Sent: Friday, October 02, 2015 8:52 AM > To: Jim Schaad > Cc: 'G=C3=B6ran Selander' ; Ace@ietf.org > Subject: Re: [Ace] Security properties of CoAP message fields >=20 > "Jim Schaad" writes: >=20 > >> -----Original Message----- > >> From: Olaf Bergmann [mailto:bergmann@tzi.org] > >> Sent: Friday, October 02, 2015 3:46 AM > >> To: Jim Schaad > >> Cc: 'G=C3=B6ran Selander' ; = Ace@ietf.org > >> Subject: Re: [Ace] Security properties of CoAP message fields > >> > >> "Jim Schaad" writes: > >> > >> > What are the benefits of allowing a proxy to change the message = type? > >> > >> For proxying between different transports such as UDP-to-TCP, this = is > >> a valid use case. > > > > Are there examples in a document that describe this? >=20 > Not really examples. There is an ongoing discussion about [0] where = Section 4 > proposes two alternative formats for the CoAP base header that must = use NON > as the message type (hence removing retransmissions and ACKs that are = not > necessary for reliable transport). The third alternative presented = there even > removes the message type from the > (CoAP/TCP) base header entirely. (There has been a lengthy discussion = about > eliding CON+ACK from CoAP+TCP but I am not sure if that has lead to a = final > conclusion by now.) I can understand why this would not have the same requirements for the = non-secure case. It may be that this needs to be altered for the secure = case depending on what the properties that are trying to be obtained. = The CoAP->TCP proxy can do the confirm messages back in the insecure = case. This may not be true in the secure case. Jim >=20 > [0] https://tools.ietf.org/html/draft-tschofenig-core-coap-tcp-tls >=20 >=20 > Gr=C3=BC=C3=9Fe > Olaf From nobody Sat Oct 3 02:57:52 2015 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 638E21ACE9C for ; Sat, 3 Oct 2015 02:57:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.55 X-Spam-Level: X-Spam-Status: No, score=-1.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sGD8IlxEUK-z for ; Sat, 3 Oct 2015 02:57:49 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D57581ACE9B for ; Sat, 3 Oct 2015 02:57:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [134.102.201.11]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id t939vftD002346; Sat, 3 Oct 2015 11:57:42 +0200 (CEST) Received: from android-b7349089d9b700bb (p57A63B54.dip0.t-ipconnect.de [87.166.59.84]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3nSkBs3K35z4q9P; Sat, 3 Oct 2015 11:57:41 +0200 (CEST) User-Agent: K-9 Mail for Android In-Reply-To: <00db01d0fd42$fcfa5f00$f6ef1d00$@augustcellars.com> References: <088001d0fbf6$e4527480$acf75d80$@augustcellars.com> <000401d0fcc9$4aaa5f90$dfff1eb0$@augustcellars.com> <87lhbleegj.fsf@aung.informatik.uni-bremen.de> <008801d0fd28$8454bf10$8cfe3d30$@augustcellars.com> <878u7lclot.fsf@aung.informatik.uni-bremen.de> <00db01d0fd42$fcfa5f00$f6ef1d00$@augustcellars.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 From: Olaf Bergmann Date: Sat, 03 Oct 2015 11:57:38 +0200 To: Jim Schaad Message-ID: <2A186CAD-E015-4223-8C8E-FF8830E8AE63@tzi.org> Archived-At: Cc: =?ISO-8859-1?Q?=27G=F6ran_Selander=27?= , Ace@ietf.org Subject: Re: [Ace] Security properties of CoAP message fields X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 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 Oct 2015 09:57:50 -0000 On October 2, 2015 8:48:54 PM GMT+02:00, Jim Schaad wrote: > >> eliding CON+ACK from CoAP+TCP [...] > >I can understand why this would not have the same requirements for the >non-secure case. It may be that this needs to be altered for the >secure case depending on what the properties that are trying to be >obtained. The CoAP->TCP proxy can do the confirm messages back in the >insecure case. This may not be true in the secure case. Okay, so as a take-away message I get that we (= the core wg) should take into consideration that altering this will also have negative effect on the security level that can be achieved when CoAP+TCP proxies are in the communication path. Grüße Olaf From nobody Sat Oct 3 04:52:17 2015 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B55011B3641 for ; Sat, 3 Oct 2015 04:52:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.549 X-Spam-Level: X-Spam-Status: No, score=-1.549 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zc-S2rWyNz2y for ; Sat, 3 Oct 2015 04:52:14 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7E9BF1B363F for ; Sat, 3 Oct 2015 04:52:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [134.102.201.11]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id t93Bq7W3004480; Sat, 3 Oct 2015 13:52:07 +0200 (CEST) Received: from nar.local (p5DC7F6AE.dip0.t-ipconnect.de [93.199.246.174]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3nSmkt4JGcz4pMR; Sat, 3 Oct 2015 13:52:06 +0200 (CEST) Date: Sat, 3 Oct 2015 13:52:05 +0200 From: Carsten Bormann To: Jim Schaad , Olaf Bergmann Message-ID: In-Reply-To: <2A186CAD-E015-4223-8C8E-FF8830E8AE63@tzi.org> References: <088001d0fbf6$e4527480$acf75d80$@augustcellars.com> <000401d0fcc9$4aaa5f90$dfff1eb0$@augustcellars.com> <87lhbleegj.fsf@aung.informatik.uni-bremen.de> <008801d0fd28$8454bf10$8cfe3d30$@augustcellars.com> <878u7lclot.fsf@aung.informatik.uni-bremen.de> <00db01d0fd42$fcfa5f00$f6ef1d00$@augustcellars.com> <2A186CAD-E015-4223-8C8E-FF8830E8AE63@tzi.org> X-Mailer: Airmail (329) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="560fc165_76b158c5_2215" Archived-At: Cc: =?utf-8?Q?'G=C3=B6ran_Selander'?= , ace@ietf.org Subject: Re: [Ace] Security properties of CoAP message fields X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 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 Oct 2015 11:52:16 -0000 --560fc165_76b158c5_2215 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline The message type only has a hop-by-hop meaning, so I=E2=80=99m not sure w= hat we are protecting here. A CoAP+TCP proxy cannot be worse in any way from any other kind of proxy.= (To give another example for how message types are not end-to-end, what m= ay be a separate response on one side of a proxy may be piggybacked on an= ACK on the other side.) Gr=C3=BC=C3=9Fe, Carsten On 3 October 2015 at 11:58:01, Olaf Bergmann (bergmann=40tzi.org) wrote: On October 2, 2015 8:48:54 PM GMT+02:00, Jim Schaad wrote: =20 > =20 >> eliding CON+ACK from CoAP+TCP =20 =5B...=5D =20 > =20 >I can understand why this would not have the same requirements for the =20 >non-secure case. It may be that this needs to be altered for the =20 >secure case depending on what the properties that are trying to be =20 >obtained. The CoAP->TCP proxy can do the confirm messages back in the =20 >insecure case. This may not be true in the secure case. =20 Okay, so as a take-away message I get that we (=3D the core wg) should ta= ke into consideration that altering this will also have negative effect o= n the security level that can be achieved when CoAP+TCP proxies are in th= e communication path. =20 Gr=C3=BC=C3=9Fe =20 Olaf =20 =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F =20 Ace mailing list =20 Ace=40ietf.org =20 https://www.ietf.org/mailman/listinfo/ace =20 --560fc165_76b158c5_2215 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline

Hi Sandeep,=

Thanks for the reply. = Maybe there is a confusion of terminology here. The situation that you desc= ribed in the installation/commissioning section is what I would usually cal= l recommissioning. Please see remaining comments inline.

 

 = 

Sec. 2.=
4.1.1. “A vacant area of the building has been recently leased to com=
pany A.
 &=
nbsp; Before moving into its new office, Company A wishes to replace the
 &=
nbsp; lighting with a more energy efficient and a better light quality=

 &=
nbsp; luminaries.  They hire an installation and commissioning company=
 C to
 &=
nbsp; redo the illumination.”
&n=
bsp;
From my=
 knowledge of Building automation and professional lighting this scenario i=
s highly unlikely. Usually a leasing company hires a space and the lights c=
ome as package with the space and are built into the leasing company’=
s contract. If the leasing company wishes to change the luminaires they typ=
ically have to speak to the (representative of) the building owner but this=
 is quite rare. There are some specific regions in the world e.g. central E=
U where this is not always the case. Sometimes in central EU, the buildings=
 do not have any built in luminaires and the leasing companies bring in the=
ir own freestanding luminaires. It is very rarely the case that a leasing t=
enant hires a contractor to change the lighting system. The situations is m=
ore complicated for HVAC systems which often need to satisfy regulatory req=
uirements. HVAC systems are often done building wide and are very rarely te=
nant specific. 
=
 
[&=
gt; ] You are right about the current status in certain central European co=
untries regarding how office space leasing is done. I have taken a more gen=
eral approach to include issues from other domains like retail where indoor=
 lighting is tied closely to the branding independent of where they lease t=
heir space. Instead of creating multiple use cases or geographic specific c=
ases, I took a practical approach to extend the office scenario that can ex=
plain what type of issues may be relevant in professional lighting in diffe=
rent related domains. This way technology developed in ACE is the not the b=
locking factor for end-users to demand a different choice than they have to=
day. Does the extension bother you regarding how it would guide the solutio=
n direction making it inapplicable in your more restricted setting? 
[AS] My =
main issue is that commissioning a part of the building by the leasing comp=
any using independent contractors is very much a corner case when it comes =
to Building automation (and almost never applicable to anything other than =
(retail) lighting because of regulatory requirements). Maybe my previous em=
ail was not clear about this point - Central EU is sometimes an exception t=
o this rule and is one of the corner cases where the leasing company brings=
 their “own lighting using free-standing luminaires”. My concer=
n with the text is that the main issues with regards to initial installatio=
n/commissioning in buildings have not been mentioned (which is the followin=
g point). 
&nb=
sp;
A very =
important aspect of the installation/commissioning workflow has been overlo=
oked. Typically, installation in the building occur in the following order =
(in a new building). 1) Installation of the lighting devices by an untraine=
d electrician, 2) A lighting commissioning engineer who configures lights 3=
) Installation of HVAC systems 4) First presence of trained IT professional=
s. 
=
 
So, the=
 initial commissioning/installation process needs to be performed by people=
 with no IT knowledge and with the IT backbone not being present. Also, the=
 commissioning goes in phases with different floors being commissioned at d=
ifferent times and then later connected together with the IT backbone. Not =
having the IT backbone during commissioning puts big constraints because it=
 is difficult to use public key certs during this process. 
=
 
[&=
gt; ] Indeed true regarding no IT connectivity to devices and forming indiv=
idual islands before joining them for a new installation. I think I had it =
in the previous version but it changed after it combined with the HVAC use =
case.  The current description is more shifted towards an already up a=
nd running system which changes ownership. I can include in those things. D=
o you see other authorization problems that needs to be added based on the =
change?
I =
do not know if it directly means “no public key certs” since th=
e commissioning tool can potentially be connected to a backend. =

[AS] I c=
an only judge new authorization problems after looking at the text. Some of=
 the key issues during the initial commissioning phase are: 1) Phased commi=
ssioning/installation: different parts of the building are installed by (so=
metimes) different installers/commissioners usually by people with no IT ba=
ckground. But at a later stage when the parts are connected, they have to w=
ork as a single system. 2) Lack of IT backbone as already mentioned (though=
 the commissioner can use public key certs the devices probably can’t=
 authenticate commissioner – maybe not important?), 3) Requiring some=
 out of the box functionality before the commissioner is on site to allow s=
ome installation testing, 4) The devices being physically inaccessible when=
 the commissioner is on site but only being accessible during installation =
(e.g. HVAC valves or ceiling mounted luminaires – this rules out opti=
ons such as NFC sometimes) 5) Usually there is a long B-2-B chain before th=
e devices reach the customer (unlike maybe home automation) 6) The initial =
installers/commissioners will need to install devices from multiple differe=
nt suppliers (rules out a single company selling “gateway+device&=
#8221; combinations with specific commissioning methods). 
&nb=
sp;
I think =
it is important that the use-case document captures these initial installat=
ion/commissioning issues rather than focus on the corner case of one tenant=
 independently re-commissioning a part of the building. <=
/pre>

&nb=
sp;


My use c=
ase of installation/commissioning will go along the following lines: 1) Bui=
lding owner hires contractor, 2) Contractor hires: architect (to design), e=
lectrician (to install) and commissioner (there are several permutations of=
 the above possible with additional actors), 3) Electrician (usually not hi=
ghly qualified) installs the devices and needs to prove wiring was done pro=
perly (so needs some out of the box probably unsecured communication), 4) C=
ommissioner comes on site and connects devices to talk to each other (This =
phase could happen in parallel on multiple floors and sometimes even in par=
allel with installation). Sometimes there are 10-100 thousand devices in th=
e building. Also, several devices are not physically accessible to the comm=
issioner. This makes it for instance very difficult to map the physical loc=
al of sensors (e.g. motion sensors), 5) IT engineer comes on site and conne=
cts up the IT backbone and the devices are exposed to the wider internet fo=
r the first time. 6) The devices continue to work with not requiring the co=
mmissioner to come back on site.


&nb=
sp;


Another=
 point is that Authorization rules may also be role based. E.g. A commissio=
ner/facility manager might be able to configure devices but a user may only=
 be able to dim up/down the lights. 


=
 


[&=
gt; ] That sounds more like the choice of solution rather than an authoriza=
tion problem.


[AS] I w=
ould not say this is a choice of solution. In general the users of the indo=
or BA can be grouped into categories – maintenance personnel, (night-=
time) cleaners, commissioners, BMS, LMS systems, end users (that may occupy=
 certain floors). The authorization problem is that these categories of use=
rs need different access rights. The solution could be a role based authori=
zation policy or based on individual authorization policies using unique id=
entification of the user. However, the fact that such categories of users e=
xist is really the underlying authorization problem. 


2.4.1.3=
 Maintenance


The rol=
es of a facility manager and commissioner (at least in building speak) are =
confused here. Depending on the type of building, there is a facility manag=
er who takes care of issues during the device operation. If changes are req=
uired the facility manager is usually able to make the changes. The facilit=
y manager is sometimes the same individual as the commissioner but not alwa=
ys. We need to put procedures in place so that the commissioner who commiss=
ions at the start can “hand-over” the system to the facility ma=
nager.


=
 


[&=
gt; ] The current text does imply a handover to the facility manager (the s=
ervice company) since the commissioner needs new authorization to make chan=
ges during the maintenance stage. Do you have any specific authorization pr=
oblems in mind by the “hand over” which is not already covered =
in U4.2 (if you could change the name of the actors).=



[AS] No.=



&nb=
sp;


The mos=
t common maintenance issue that occur is that of replacing broken devices. =
Therefore, the “authorizations” need to be transferred to the r=
eplacement device.


=
 


[&=
gt; ] This is a good one but needs to be detailed in terms of how much inte=
raction is needed from the one doing the transfer. It should be less than n=
ormal commissioning U4.1 but cannot be zero-configuration either. Any text =
is welcome.


&nb=
sp;


[AS] The=
re are two parts to this – first part is configuring the new device a=
nd of course it cannot be zero configuration. The second part is that prope=
r disposal of the broken device – hopefully when you through the devi=
ce in the bin and somebody else gets access to it, you do not create any ne=
w problems. 


&n=
bsp;


A phase=
 that occurs several times and not covered in this use case is recommiss=
ioning. This may occur in several situations: 1) when one tenant moves =
out and a new one moves in, 2) Changes in the office space, 3) removing a d=
evice from one system and adding it to another


=
 


[&=
gt; ] I tried to leave this phase out since I did not see any new authoriza=
tion problems (the whole use case is kind of depicted as a recommissioning)=
. The point of the document is not to explain lighting but to guide the sol=
ution development. If you think any new authorization problems need to be a=
dded, we can include this phase. Please let me know. =



[AS] You=
 cover this use-case to a large extent in the installation/commissioning se=
ction. However, maybe I missed the point about if a device is removed from =
one system and recommissioned to a new one then you should not be able to b=
reak the old system with the device that has been recommissioned. Differenc=
e from decommissioning use-case is that the device stills needs to work pro=
perly in the new system. 


&nb=
sp;


Re=
gards


Sa=
ndeep


&n=
bsp;


____________________________________=
____________________ The contents of this e-mail and any attachments are co=
nfidential to the intended recipient. They may not be disclosed
 to or used by or copied in any way by anyone other than the intended recip=
ient. If this e-mail is received in error, please immediately notify the se=
nder 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 sca=
n or otherwise check this e-mail and any attachments.

 

The information contained in th= is message may be confidential and legally protected under applicable law. = The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, = forwarding, dissemination, or reproduction of this message is strictly proh= ibited and may be unlawful. If you are not the intended recipient, please c= ontact the sender by return e-mail and destroy all copies of the original message.

________________________________________________________ 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 immediately notify the sender and= delete the e-mail and attached documents. Please note that neither the sen= der nor the sender's company accept any responsibility for viruses and it i= s your responsibility to scan or otherwise check this e-mail and any attachments. --_000_0E9A48AB39AF3547ACD28A6DE3E2906A0AC250ATBRAGMSX02itison_-- From nobody Mon Oct 5 01:37:46 2015 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 290391A0271 for ; Mon, 5 Oct 2015 01:37:45 -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, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B-jvMjWBQH87 for ; Mon, 5 Oct 2015 01:37:42 -0700 (PDT) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0795.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::795]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A1F9C1A0270 for ; Mon, 5 Oct 2015 01:37:41 -0700 (PDT) Received: from DB4PR06CA0077.eurprd06.prod.outlook.com (10.162.49.45) by DB4PR06MB160.eurprd06.prod.outlook.com (10.242.155.155) with Microsoft SMTP Server (TLS) id 15.1.280.20; Mon, 5 Oct 2015 08:37:18 +0000 Received: from DB3FFO11FD023.protection.gbl (2a01:111:f400:7e04::116) by DB4PR06CA0077.outlook.office365.com (2a01:111:e400:9866::45) with Microsoft SMTP Server (TLS) id 15.1.286.20 via Frontend Transport; Mon, 5 Oct 2015 08:37:17 +0000 Authentication-Results: spf=fail (sender IP is 146.108.200.10) smtp.mailfrom=tridonic.com; tzi.org; dkim=none (message not signed) header.d=none;tzi.org; dmarc=none action=none header.from=tridonic.com; Received-SPF: Fail (protection.outlook.com: domain of tridonic.com does not designate 146.108.200.10 as permitted sender) receiver=protection.outlook.com; client-ip=146.108.200.10; helo=ATBRAGMSX01.itiso.net; Received: from ATBRAGMSX01.itiso.net (146.108.200.10) by DB3FFO11FD023.mail.protection.outlook.com (10.47.217.54) with Microsoft SMTP Server (TLS) id 15.1.286.14 via Frontend Transport; Mon, 5 Oct 2015 08:37:17 +0000 Received: from ATBRAGMSX02.itiso.net ([169.254.2.75]) by ATBRAGMSX01.itiso.net ([146.108.41.69]) with mapi id 14.03.0248.002; Mon, 5 Oct 2015 10:37:16 +0200 From: Somaraju Abhinav To: Olaf Bergmann Thread-Topic: [Ace] [ACE] review draft-ietf-ace-usecases-06 Thread-Index: AdD8XTFdDVkUObPhQvi/FvrOxuHgzQC5cAMDAAFR2QA= Date: Mon, 5 Oct 2015 08:37:16 +0000 Message-ID: <0E9A48AB39AF3547ACD28A6DE3E2906A0AC2D5@ATBRAGMSX02.itiso.net> References: <0E9A48AB39AF3547ACD28A6DE3E2906A0AB169@ATBRAGMSX02.itiso.net> <87fv1p92fe.fsf@aung.informatik.uni-bremen.de> In-Reply-To: <87fv1p92fe.fsf@aung.informatik.uni-bremen.de> Accept-Language: en-US, de-AT Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [146.108.41.149] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Microsoft-Exchange-Diagnostics: 1; DB3FFO11FD023; 1:xDw2JVXfuhhpunbPkTJ3Zdlt3PG9TphzkkHmgufAqT93XQEaGr/KlbsKKXcUI+V1U7SFT1UoPV/G0j2iN+2SdDVOFTNMuabWu9np6qvJZZzM3XKITYDBJj6O6Szvz53AQHal98W4/NkhbHZCsO4YVrugO4HsKn5LjiD+hpDHetuPp0VESIxGmLkapeWTB3tH4NXgra4O5HvXG0LcpBEjORv0mGiW9sa0S5nLYh74PwOEabVd9E3siOBDgbDCCSUyzQtnqsirjIhuHhltseEqxEWcEMsgoPK6G5uSiVWEY+IMBXy+pxg3V7WvqH/sFIWL6j6KkdZ8V38x/XMhI+7dgQ== X-Forefront-Antispam-Report: CIP:146.108.200.10; CTRY:AT; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(2980300002)(1110001)(1109001)(339900001)(51914003)(13464003)(189002)(199003)(104016004)(5001860100001)(19580405001)(81156007)(76176999)(33656002)(5001830100001)(26826002)(50986999)(2920100001)(102836002)(106466001)(15975445007)(4001540100001)(23676002)(19580395003)(47776003)(2900100001)(87936001)(50466002)(105606002)(2950100001)(66066001)(11100500001)(53416004)(92566002)(62966003)(5007970100001)(6806005)(5003600100002)(189998001)(54356999)(5004730100002)(5001960100002)(77156002)(5001920100001)(5008740100001)(64706001)(86362001)(46102003)(230783001)(5890100001)(69596002)(110136002)(85426001)(55846006); DIR:OUT; SFP:1102; SCL:1; SRVR:DB4PR06MB160; H:ATBRAGMSX01.itiso.net; FPR:; SPF:Fail; PTR:unknown.zgrp.net; MX:1; A:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; DB4PR06MB160; 2:zWKplqytWu1zfAv1SJJ32Lwx0v9/ch4W8CFefs+BpoxOvw7yWaJ88GMfK6ciuYcULVFw2klhrfGUgVIkHk4Kpbc10g007Vt51hjlvC8HgV2cJY4Xz60ZZY2HjRM+8SCtVQeTbJDyoPyxStpb8/FA+1X+TT2bh0bDJT7fQHKOxLk=; 3:HkaibSRhqouiYrhEIHCQOOdOTR+HKFiX3cqsOn+IBwhCfhgAUSlfo2C3zeWIMwyUV4hc9Tv/8d8dA6dd4yVzTTszfC+1iQwjZGKJSbBcoUuIZ/phyz1WufCoaIlli9VGgQxSBmORvw2XxZRwZ5P7oLCJexfznGKaI7OazBifDaKGgKvcRhiT4td8qyy0o9ZBovk34XM6h2TWGCtk6B8MGswDL28982wBnsPokqvcSD0y7Qnjox3dVSc+Ivj9E4vU; 25:3wCu2hjM6uWenqCsMbwXTVm5qedlr7xA/RLccST9AvrXXa62YhN69sHXHlp6CMAw+6aS/xM6LAVVzQ7GMZJGRe2pyn0FCIXTs+c0gSHh0BNpY6fwYNkSh8S17mNH/N5k80QOWFG+R37eE7VvIEAByACr7pTF9fp/BDn/jWRce7RZ9SBj75N+PB74CMLSQbT/V0Ndm0s1bwvemDhdL3N5pZ9Uzbg3pFBoAJvU175UTKRtW8c7/yMnW+V52SQ9zcE9bFJbFbtbU1XambZxWeBlpw== X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DB4PR06MB160; X-Microsoft-Exchange-Diagnostics: 1; DB4PR06MB160; 20:0C8K86SKgSXfs3RdfSvIIeuBpUPt8dxyKdO9Z2zHGPdziOnyjJRcmmRRTjseQftLjxhwRM5IkWXp998pgKZUCys8oJZSGw7rIeIpk0zuU2P3snCKBvLb5psoe2a6IXhaN7ApX4gzCFmXYMd2+JC0tsifrjTa965yV4nK7vb9u4nWpA9/MZUtMUaYlhfz4GC0NBHtFXwnPjQyc+X+KCoL9zEx942bO1nzmyX6g0ydr4Cdmel4VjfnfXxCy3CIaHVmCN+YVVTKlqUMWYyZD5dy0l8r4+1tViizlWzCwmFxcYdyiXpw+PoLjT2EmdPPIWJTNGbaNL7/IUvEYQI359DuJnIocGGZheMjI4spNC7NSa2kN7nP6RG0FAnLlrgf05VYNg5QnwHKnVtIPG/KwMTYrBQtaED8vOs6fiUILVSERHnclmg/ojle6K64Dklo6M+393vFL0nAk+2yxq2Uz/7xWT2KszguuwFtuE3xf7kfyy3HDl4ENfXJfgphyBke247F; 4:HvAaKWEmq+TBpjgY01ec9CGbpFAUZ7RWQKyCEQRX6T/E4ai2qBhVvFaJ9v5FuYcFJlWWOaTzCQUAN8SIkgoK8F5ha3jzvnMrWutmBEn5Ww8umoY2HMtTs3MzC9AAz6qZaYqIJkFO38A5ZKhhHnFKYXUBxfzAqdu7aKchPhFJLeEkalZqp4pJyMp0uoDBVatbtmcSQgPa5fUR4eHYWpnVAY4tigCjf4WSA/EcqgA6ne7PigombsckDHxDYnKu8AGl5u/81aQEQFt6407zSRCT7zFLMFL/3h1sHZKjfqtCbkPKyKC2J4xCnmC3HFkhTpEG7vlrKgGuTwCcrdeKFZbQtMfiH/2nESGPPdbeFKQCyao= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(520078)(5005006)(8121501046)(3002001); SRVR:DB4PR06MB160; BCL:0; PCL:0; RULEID:; SRVR:DB4PR06MB160; X-Forefront-PRVS: 07200C0526 X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtEQjRQUjA2TUIxNjA7MjM6U21SZWYvZTZkMkx3R0t4VnY5c3FvdkpCVkwv?= =?utf-8?B?V29RZkIzMytTK0xZek9SVkk4RHNsbkltVzF1bWVGQThuMG5MYUl5dk1PRC9w?= =?utf-8?B?VmNYdkpxMmptQzh6dzIwUjdtdUFPd1BEVFB4YVhSNlNsZ0NreDZSTXhmM0JZ?= =?utf-8?B?RWV4aStXRlRsVDkwM3RHcElhV056QTFNMnplT093VTRWRmhGS1l3U2J5c0pS?= =?utf-8?B?aGZnUk5SRmpxVzJHdUh1eXJaNDdCRFNycU93VkRiMFc3NlRLby90YUVrb1l1?= =?utf-8?B?Sjd1ZW1ZMTJMVHI3M3lqVytvVDVhQko4Z00wTW9XZUNwVTVkVkdOYkRuNkdu?= =?utf-8?B?endNZ1hjb2R3WWMxTmN0Wkh1OVBKbkpZMTlPYWV4cXhXWTBSaVFmUXhnblZq?= =?utf-8?B?cUQzaHAxaHJwdW9QM1M5ZjlRN09oN0FpREV1ME92VnVSSEovbktiRDd0WWN4?= =?utf-8?B?SnFLWUg1SjEva1hBSEswUk9mQXYwbVNQOHFVenV6OUVwaDNOY2syRmVJampC?= =?utf-8?B?SVFqbi9jRGQ4VTFsYk0wc3pseGtvSytvSG0zSndka05wK0xXOHRyK0FzdUZH?= =?utf-8?B?NkFrQUlRaHVNRkVwYW8zM243WXpVb09LOVRpM3ZOd1ZBcmFKQ2xjRXU2cUNK?= =?utf-8?B?Nm5sOE5DTG13NEtMSnBVaXdPa2FKeSs3RW1Wa1ZSZlVFUzdzNGN2bkhFWDJI?= =?utf-8?B?aVNhY3FYUkI5aXRjMWJyTi9OaVZvWVFWdElNc3FMdU8yb3Z1TGpJZ2Faclkv?= =?utf-8?B?NXlGbDhTcjhyRFc0QWVpWGs4bE12dGFkVkNDVEE2b1daTFYvR1cvemdVMXhH?= =?utf-8?B?TldQUC8reUJkcERnU1JKQXNTajlNSkpJa2t1a05ScUFFWktwdHJKa1F6dW9u?= =?utf-8?B?SlRPbG42aXVETkxLdTBxcWtDaE5reVVyMHRzZ2xhVWZpMnlUckVucWlZUER6?= =?utf-8?B?RDR4RnZMTjdSeCswbmlHZXdZZGU0SStIUVNFWHZmdEtLUDFoeUQ3aVRyWGpS?= =?utf-8?B?cU4zeU9EWFBUZWNFaVpHUURndGE2VUZpMU5KQktmb1FkTy84VUJ4MGFzeXZE?= =?utf-8?B?bUVHMjRxc1RISGxlcXNvYThCS3g1YUVHZjhiUEFQMW11NmpmbWozenUxWElm?= =?utf-8?B?TDFNVHl0WTI4UDhvL3dOODRqNDkwZ2h4NnZMZnBmNkF5YW5rUkJscEN1ZFNm?= =?utf-8?B?UG5CWmRVTXpiK1owa2c3QzVTdGw5UFprczZnYWt5TVI3L0dhSmNUcmNmWjc4?= =?utf-8?B?WFJQeHhrQVZuMzA3OW96R2cyWVp1cjBZbGRERUJpclp1RUZIWGlXWWRVQkZ5?= =?utf-8?B?QzVpT3pncS9qZDM3SVNvc2lueDNWOE1kRkQraVJCWG82Z05hV2lYOXQwOEFE?= =?utf-8?B?T2Y5UFBGT3ljeDVmOVN5ZVIvVmxXajFkU0lGWmdPZlFxbXE1RzdKWlgvK1VQ?= =?utf-8?B?bmJ6QjFmZTVxZHA0NDkyMjBHSDJBZGJTc0JpYnZCeTA5ci9YMVF2UmFiN0pM?= =?utf-8?B?bTRXZE8ya29mS0hJdjhSU1V1L3ZzVEhWY1BQeHRUTlVLS0dDQ0txWGsyamlx?= =?utf-8?B?VHVSREFzdFFTV1VCa3ZHSE9rdVRPVUZ6NmxPT0dFN2Nma2xLS3Vtc3JWeEp4?= =?utf-8?B?WFhDNlNIZG9KM2FuUEd5aWxMdG1KR1BGdnc5U2x1QkRUTFUzNEpqUVVEZ3VO?= =?utf-8?B?MGVuLy9tZVUvN0YvUUhmbTI2NVdGamtXL3VMTmlMemtCU0hDK09lZTJrTER5?= =?utf-8?B?SUhpR0JYYTAwcTBlSS9zWUJOUER1VzBEcFBQNXU5L3BjcW1xUlM2eUkrVW9O?= =?utf-8?B?Z2pEYzJkTS90UGJJTW9ZQTQzTm1ONVp4Rk4yUnBtbmliMWZscStLbmxIYk8r?= =?utf-8?B?aEpTakM1N2pSczdqVEpPL0NTdzlpUldVNjYzVW5lcjRqc0RSRjdxbzQrbUFI?= =?utf-8?B?L0swK0ZpTk94blR1UVpGNmlKMVNtSUQvaWo1QXNJcnRZZG53azFvY1MzS2V6?= =?utf-8?Q?5TJO+?= X-Microsoft-Exchange-Diagnostics: 1; DB4PR06MB160; 5:JonIcbhKpQIG7m3CnswudX3rVkAT/bWG1hWyl5/GFYFHbmZ/ZtEyoy7Tqo0LW+RfjDvqELdNsQvHkMmY+PwjkZNWfSsJ3v5Ee2UdvmcGGv1h1fNQ6oXJKR/MiCxSncv6UayaQGmDEqHzi575jo06vQ==; 24:3GPNRJ//dv6eaUe1STmAdnd7ICzwc+PLJwH+v7NbexJGpv4p2nQaIvxsVeWofLY1Y9B3g8+SX8A9cdE2QTG4LmaikZyChey+1TaYs0BbWOM=; 20:phmrq68A5oyYhW1UoQ2QOBzBP35uYpgJJYrBVvXfoc+ibmBqMM6blUuTX4nEUAAiOJG7apdSRg12dnDIsqAQ9Q== SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: tridonic.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 05 Oct 2015 08:37:17.3154 (UTC) X-MS-Exchange-CrossTenant-Id: 8b206608-a593-4ace-a4b6-ef1fc83c9169 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=8b206608-a593-4ace-a4b6-ef1fc83c9169; Ip=[146.108.200.10]; Helo=[ATBRAGMSX01.itiso.net] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB4PR06MB160 Archived-At: Cc: "Ace@ietf.org" Subject: Re: [Ace] [ACE] review draft-ietf-ace-usecases-06 X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 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, 05 Oct 2015 08:37:45 -0000 SGkgT2xhZiwNClRoYW5rcyBmb3IgdGhlIGNsYXJpZmljYXRpb24uIEkgdXN1YWxseSBkbyBub3Qg dW5kZXJzdGFuZCBleGFjdGx5IHdoZW4gYW4gQVBJIGlzIFJFU1RmdWwuIElmIHlvdSB0aGluayBh bGwgdGhlIHVzZSBjYXNlcyBjYW4gYmUgY292ZXJlZCB3aXRoIFJlc3RmdWwgQVBJcywgdGhlbiBw bGVhc2UgaWdub3JlIG15IGNvbW1lbnQgLSB0aGUgZGlzdGluY3Rpb24gYmV0d2VlbiBSZXN0ZnVs IHZzIFJQQyBpcyBub3QgdmVyeSBpbXBvcnRhbnQgZm9yIG1lLg0KQWJoaW5hdg0KDQotLS0tLU9y aWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogQWNlIFttYWlsdG86YWNlLWJvdW5jZXNAaWV0Zi5v cmddIE9uIEJlaGFsZiBPZiBPbGFmIEJlcmdtYW5uDQpTZW50OiBNb250YWcsIDA1LiBPa3RvYmVy IDIwMTUgMDk6NTMNClRvOiBTb21hcmFqdSBBYmhpbmF2DQpDYzogQWNlQGlldGYub3JnDQpTdWJq ZWN0OiBSZTogW0FjZV0gW0FDRV0gcmV2aWV3IGRyYWZ0LWlldGYtYWNlLXVzZWNhc2VzLTA2DQoN ClNvbWFyYWp1IEFiaGluYXYgPGFiaGluYXYuc29tYXJhanVAdHJpZG9uaWMuY29tPiB3cml0ZXM6 DQoNCj4gSXMgdGhpcyB0cnVlIGZvciBhbGwgaW50ZXJhY3Rpb25zIGluIHRoZSBjb25zdHJhaW5l ZCB3b3JsZD8gRm9yDQo+IHNldmVyYWwgZXZlbnQgZHJpdmVuIHN5c3RlbXMsIGRvZXMgaXQgbm90 IG1ha2Ugc2Vuc2UgdG8gYWxzbyBzdXBwb3J0DQo+IHNvbWUg4oCcUlBD4oCdIGxpa2UgZmVhdHVy ZXM/IEluIHNvbWUgb2YgdGhlIG1vZGVscyB3ZSBhcmUgbG9va2luZyBhdCBpbg0KPiB0aGUgaW5k b29yIHByb2Zlc3Npb25hbCBsaWdodGluZyBkb21haW4sIGl0IGlzIHBsYW5uZWQgdG8gdXNlIENv QVANCj4gUE9TVCB0byBleGVjdXRlIGFuIGFjdGlvbiBhbmQgbm90IHRvIGNyZWF0ZSBhIG5ldyBy ZXNvdXJjZS4NCg0KQXMgZmFyIGFzIEkgdW5kZXJzdGFuZCwgeW91IGRvIG5vdCBoYXZlIHRvIGFj dHVhbGx5IGNyZWF0ZSBhIG5ldyByZXNvdXJjZSB0byBjYWxsIGEgUE9TVCAiUkVTVC1mdWwiLiBJ ZiB5b3VyIGRlc2lnbiBpcyBjbGVhbiwgaXQgY2FuIHN0aWxsIGJlIFJFU1QuDQoNCkdyw7zDn2UN Ck9sYWYNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N CkFjZSBtYWlsaW5nIGxpc3QNCkFjZUBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9hY2UNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fIFRoZSBjb250ZW50cyBvZiB0aGlzIGUtbWFpbCBhbmQgYW55IGF0 dGFjaG1lbnRzIGFyZSBjb25maWRlbnRpYWwgdG8gdGhlIGludGVuZGVkIHJlY2lwaWVudC4gVGhl eSBtYXkgbm90IGJlIGRpc2Nsb3NlZCB0byBvciB1c2VkIGJ5IG9yIGNvcGllZCBpbiBhbnkgd2F5 IGJ5IGFueW9uZSBvdGhlciB0aGFuIHRoZSBpbnRlbmRlZCByZWNpcGllbnQuIElmIHRoaXMgZS1t YWlsIGlzIHJlY2VpdmVkIGluIGVycm9yLCBwbGVhc2UgaW1tZWRpYXRlbHkgbm90aWZ5IHRoZSBz ZW5kZXIgYW5kIGRlbGV0ZSB0aGUgZS1tYWlsIGFuZCBhdHRhY2hlZCBkb2N1bWVudHMuIFBsZWFz ZSBub3RlIHRoYXQgbmVpdGhlciB0aGUgc2VuZGVyIG5vciB0aGUgc2VuZGVyJ3MgY29tcGFueSBh Y2NlcHQgYW55IHJlc3BvbnNpYmlsaXR5IGZvciB2aXJ1c2VzIGFuZCBpdCBpcyB5b3VyIHJlc3Bv bnNpYmlsaXR5IHRvIHNjYW4gb3Igb3RoZXJ3aXNlIGNoZWNrIHRoaXMgZS1tYWlsIGFuZCBhbnkg YXR0YWNobWVudHMuDQo= From nobody Mon Oct 5 01:38:01 2015 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9065C1A028A for ; Mon, 5 Oct 2015 01:37:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7A93qthUk7pA for ; Mon, 5 Oct 2015 01:37:50 -0700 (PDT) Received: from emea01-db3-obe.outbound.protection.outlook.com (mail-db3on0714.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe04::714]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 46E9A1A01FA for ; Mon, 5 Oct 2015 01:37:49 -0700 (PDT) Received: from DBXPR04MB223.eurprd04.prod.outlook.com (10.242.140.148) by DBXPR04MB270.eurprd04.prod.outlook.com (10.141.10.140) with Microsoft SMTP Server (TLS) id 15.1.286.20; Mon, 5 Oct 2015 08:37:30 +0000 Received: from AM3PR04CA0112.eurprd04.prod.outlook.com (10.163.180.166) by DBXPR04MB223.eurprd04.prod.outlook.com (10.242.140.148) with Microsoft SMTP Server (TLS) id 15.1.286.20; Mon, 5 Oct 2015 08:37:26 +0000 Received: from AM1FFO11FD021.protection.gbl (2a01:111:f400:7e00::101) by AM3PR04CA0112.outlook.office365.com (2a01:111:e400:5366::38) with Microsoft SMTP Server (TLS) id 15.1.286.20 via Frontend Transport; Mon, 5 Oct 2015 08:37:26 +0000 Authentication-Results: spf=none (sender IP is 23.103.247.180) smtp.mailfrom=philips.com; tridonic.com; dkim=none (message not signed) header.d=none;tridonic.com; dmarc=none action=none header.from=philips.com; Received-SPF: None (protection.outlook.com: philips.com does not designate permitted sender hosts) Received: from 011-smtp-out.Philips.com (23.103.247.180) by AM1FFO11FD021.mail.protection.outlook.com (10.174.64.210) with Microsoft SMTP Server (TLS) id 15.1.286.14 via Frontend Transport; Mon, 5 Oct 2015 08:37:24 +0000 Received: from DB5PR9001MB0167.MGDPHG.emi.philips.com (141.251.190.211) by DB5PR9001MB0165.MGDPHG.emi.philips.com (141.251.190.209) with Microsoft SMTP Server (TLS) id 15.1.286.20; Mon, 5 Oct 2015 08:37:10 +0000 Received: from DB5PR9001MB0167.MGDPHG.emi.philips.com ([141.251.190.211]) by DB5PR9001MB0167.MGDPHG.emi.philips.com ([141.251.190.211]) with mapi id 15.01.0286.019; Mon, 5 Oct 2015 08:37:10 +0000 From: "Kumar, Sandeep" To: Somaraju Abhinav , "Ace@ietf.org" Thread-Topic: [ACE] review draft-ietf-ace-usecases-06 Thread-Index: AdD8XTFdDVkUObPhQvi/FvrOxuHgzQAwVt6wAIgXbCAAAkjHQA== Date: Mon, 5 Oct 2015 08:37:10 +0000 Message-ID: <303a8355069d43bda17b076e709fc499@DB5PR9001MB0167.MGDPHG.emi.philips.com> References: <0E9A48AB39AF3547ACD28A6DE3E2906A0AB169@ATBRAGMSX02.itiso.net> <0E9A48AB39AF3547ACD28A6DE3E2906A0AC250@ATBRAGMSX02.itiso.net> In-Reply-To: <0E9A48AB39AF3547ACD28A6DE3E2906A0AC250@ATBRAGMSX02.itiso.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [194.171.252.100] Content-Type: multipart/alternative; boundary="_000_303a8355069d43bda17b076e709fc499DB5PR9001MB0167MGDPHGem_" MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Microsoft-Exchange-Diagnostics: 1; AM1FFO11FD021; 1:PZlQGOdvb4+6mkhtcIvsZRQy+VxEJvX7UxK+Kht0z2v3b8fOkNtEouru7TmDXkeY3g1kSI7EGoTCMC71MKckF+y0aamRMjhvOCxY0ap6mlVeY66LehuU5jtw+DVGaJQkQ0UGvTxM3hSwECaDdwbdjuaXzi0veX3HoRq99mnl8Pgx4o1fiSRKtFDwSAyVfio4pEj9spI00+qkfq/1IGF8/JKF2oLjYfvE/QWiB+zzyezf8x8wrbg+76XteK5tQ0lBudLdNQLfkH0rG5lBi0rxwdx6g5rCztcY9MOtrheN16UEsXetHSZz3gGOKAfWPeaeUVlqjTcqpbvUmbxbzKH1+w== X-Forefront-Antispam-Report: CIP:23.103.247.180; CTRY:; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(2980300002)(428002)(85714005)(199003)(51914003)(45074003)(377454003)(189002)(55904004)(374574003)(6806005)(5003600100002)(2950100001)(5890100001)(24736003)(77156002)(62966003)(2900100001)(5008740100001)(19625215002)(2501003)(108616004)(92566002)(102836002)(15975445007)(68736005)(46102003)(5001830100001)(512954002)(66066001)(64706001)(4001540100001)(97736004)(105586002)(5001770100001)(5001860100001)(106466001)(10400500002)(69596002)(107886002)(19300405004)(5004730100002)(84326002)(5001960100002)(54356999)(101416001)(86362001)(11100500001)(81156007)(87936001)(5007970100001)(19580405001)(19580395003)(230783001)(50986999)(33646002)(16796002)(76176999)(189998001)(16236675004)(567094001); DIR:OUT; SFP:1102; SCL:1; SRVR:DBXPR04MB223; H:011-smtp-out.Philips.com; FPR:; SPF:None; PTR:InfoDomainNonexistent; A:1; MX:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; DBXPR04MB223; 2:kzCZO+r5e3aSO472HKIZq0MxcgfpZiYeUf4g6y70kdyqIaHnVW0LTRFDAod+K7Oq1qJXMa1mOdGu2f7hSx+UHuaCRDvL4mhzc6uH8fXVMA7cBVlyNjGf9u7yfMz42fFAfS6hN28CKgTqqkuvGGtJNQoY8/HKKtL2DfSpuoDEaSk=; 3:9WzxvZeMfVpw5RPr7kopjF4CjO3LvhhraN766Ne9JpEuzCaGSCdsSXbguVgmmzgPoACjOcDiK2ZRoAAyx3/HcY6evbgIEWbiKwzSQ7pDbq5NiCEs/nvBzHK1E0+MyuuwuD6vJE2xkfphcWacyxAJtdv1fYin0bexvLXtxk6A6TJiLL0kKdWkKvzonETxWff/wHfnXoWiL/lGgVHoRl14jJqcwz4IyzsukRajthbpkik=; 25:nFvkcWzFZcEzgBT+b4Vt17PJINkxJs2jK7jjDJPhb2Zr43oPCxHJ2PNRsD9LjKTZQgipdUxeyuQKRYGkwbCevarNorFEtfFkIZQkC1lQnyMZQr5WK2TUXCcsttpkuVvJ3xga2f/2io07BxQGGnAKjdzt9UZ1ODR6cg3Pyto3t65FXjkGE2BKcAStO/AooJdDZq1oPOkeGVZF+4BcbjpWdeNXZClsDuqY5l4ulmGB7uIOex19frR2x7jl0V3YHS/uHt0ZbbJDg6Els5fW54/7jg== X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DBXPR04MB223; X-Microsoft-Exchange-Diagnostics: 1; DBXPR04MB223; 20:Zxepyw6vBIbhlSKc9w9PqQiFK2gvcAW2j0enO9mVYMINvIIFsX5ve5Eamx4cOJ6L7zCS84elyuktlvOE26PAKagZQ8An02JExK34sprphAyqYhL8XFI3kknyOZuLr47+ti8Hr85T+Y0PvFcypIwb1735czCOLW2pESKBurW6VD2Iexbk4ZuN10G1myd4aEC/Kx5GplpFnRrrkoHujLEbFTVZdgniE1EQOH+4gRkSStSmsxQ9Upz73ELldxiOO/ihgdNGJSxo48MLNGFfvCMf/w6TUUhWayJUtcHHjFS9iZdaFVkOlJ1bG/Njv6+wxBxzE33u+BqplJ1/rB5Y2iJ9u50m+H24EgEMK73TeM+wT78t7QBITPwoz2S6fP6GR+MDWFJspDI68DvEBrDEHJCfeR+baleGSj8y1Q8BhbACaYxMoPU1n/L+p+sz386x+GHvJWvyP65Z/k31zuz7fpHovLFAKlJyJjLDAj28Z30bz2ObWG7SxdlWSlaipZa0Ic4s; 4:j6lu+HcxJmTYeMSPih75Nk2jHK9w6rmd7Amr4WWOE4Df4i1G996xsKYXUEuXiZabpLnYALkxvrExWClpw8b+Wkjmjgil9H8Rxe94dsj8ZlxNnuID4rkk9B6bNhYeDH6PZnPZL29f5YVizHF1e1hDwgNAMSjFzE6SwA5mi2+5oE8+tgamj1udBHq2G+rwfGhd4HmIsclbdHcJNfJCcSRmROySzQCcxy+AvS8h1pE1eK/4nz58LAk21uJDkk98uG1FAj5/CaFWsOKEP6wmazmiaXruOG9UriMt2AP2kriEy3pAJQDOXoC92o1/C7J5t6DMdGr1XmgunGBI8SZB6ghAJYZ5tJqF2tuFFGUg21EG//8= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(108003899814671); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(520078)(8121501046)(3002001); SRVR:DBXPR04MB223; BCL:0; PCL:0; RULEID:; SRVR:DBXPR04MB223; X-Forefront-PRVS: 07200C0526 X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; DBXPR04MB223; 23:l0UHF93yCmmbAyO2fpTkBxD6ikbIbr76MLrtwQN5Lu?= =?us-ascii?Q?CY9zgns5s0eztl518IpfQ5aIqLPNJ/tZfhMkC0UPocPnVLjD9FLaHrAO2SVe?= =?us-ascii?Q?/61lAWtcBwxvectHU5uOE6WJgn908ewNG0xKvOXz0ugR3WKDTOhk0Nh+O63u?= =?us-ascii?Q?w4x0KOcS1APWk4qzGKM2aGcZkA0BSUDDhZzP0FFg4YDu21bMyCTo6ws8/fdL?= =?us-ascii?Q?EJJScI4G3198fmoX8Uo3NnZ4FyOMaT+PsLdPT6rEgY3ZhVzRwlrh6z0Xc0nx?= =?us-ascii?Q?jItqnL70ZdV1GRhQwV7u9MZONrGnU4n8DEXcs38WqEgXrUwaiMHkAb/pFyWL?= =?us-ascii?Q?xG1XExh8+iYoWksVVqqL71LzSHJocnsxePt6sV/xhTzguA7uxpb/l5zOfl83?= =?us-ascii?Q?jmxoH2cLvS+UtyrimqFHON22CnC+JRHxRxZ2OAY306DpV5LH8nUeMABr+jC6?= =?us-ascii?Q?RB52tZwLHZmHNV4A3limagU1EW7WG4Zvj1EzUN/xQHOXbhiUZ7C40SJfnHUq?= =?us-ascii?Q?hwDGcPrjnO9aabtBrcgMvItOxnVR4YtjtrtpcUhnBQm6EW3SMTNgdugjophw?= =?us-ascii?Q?mP6AF05aNXZkHscCm7OGtUcAxmGQJVkWAqLSjK77bWPYUb9s3gw1EWsH17Ko?= =?us-ascii?Q?f1lL7UYFSxVdjUJzy29PRqqMz6gRIlIEV1iyObztJfMBftJhQPmAYs7CB+ew?= =?us-ascii?Q?8A4A89tgq4K64Kyu+mePEx68ticF0sGVcBVcabQRtPu53LkJ7SNC4U98fSUT?= =?us-ascii?Q?KMXarODN41NX8sJfWRKOJleA+5GNxUj2zfeaoKQJRkvIfmmP+A9b+wSGGhYV?= =?us-ascii?Q?WuqmQYF8zaWMBJ+XNqUpTtwkx/075QHyQ3/cHZYzDhkdXaUKdfbB2ELXzaZZ?= =?us-ascii?Q?qzPxgtZHNwBCLlTwMTL8YQYr+JrbsTlM6ryGkNyNQu2p12pyQhikOjvKFOlR?= =?us-ascii?Q?wjF+frMWnah0IAHGQPshlIy7Pjb+El1fJQj5B5arIZLUvYGp3+01QLzGPeu6?= =?us-ascii?Q?p0aRsBYmOp2el/oGjI7TCZpzkoSjk4Bfdoi92qHsnAzVS2wRGvOp4EIxUGXl?= =?us-ascii?Q?3TbgYvacqUqe0FDsmx8mOWKc1eNe278aylnBrfKoLWNBzPnlvAiwGBHY7d6k?= =?us-ascii?Q?uvsrjRnJ2ki7TPGF+/2HoL1G+9MBULxIo7HIR40Z2xedY0Uz70vKZJcKBXmg?= =?us-ascii?Q?rrlUaWt52VW0xQ8PKaRBIJiz0zcl3IbgjPu4bm7eD4rUnNcZaUIgZijM7GtD?= =?us-ascii?Q?8A5TLlnBkeyikS75PFgJ6MNb6pyaPEBZtQEODs4qE++JbBp6tF+O7+9qAdiK?= =?us-ascii?Q?E5KKiP0Uz73MJbPw+AVml6+O5Rm+955gz4scuiqUbAUr9iHa+czaA6L0MkKk?= =?us-ascii?Q?cUNGaZ7Hh7YB7sRYeg89HMvCieMdZg94emAzo45cAZJW+zblBRUR3BsBWec7?= =?us-ascii?Q?xsEDmgBxYk6++40GkL3QxbjNchLAxrdOBJfAwsMl68Ht5yQaipwC1NLv1Abg?= =?us-ascii?Q?l/GIRfEBKFn/v0PrSW+EZ6QaHiHfZtVxuyiDW5PNczS/ofk5VmT28HgF2QzS?= =?us-ascii?Q?XV9gGaZ4pbgGAI++KKvRsvRTVGtCwqRY0agum34nBasGYQyKQxa9Cvb7hyjZ?= =?us-ascii?Q?0JfikM9keDKcDsHmpvXmAHElDIVPfifyfiREABsHu4QmNoeIDmKYxsyTuzIN?= =?us-ascii?Q?Iz?= X-Microsoft-Exchange-Diagnostics: 1; DBXPR04MB223; 5:JXprFPuyFv/49jiXM/3kzPHqTwv2NYY4COsVBRANTeptUJ4ckB77W1wxU1PaD+utbKbONOlhcBrLF40op39eAkG9JQopRS9ZVyUF62a+2ELbRULntcFgtDAJULM8gHlb+QeVLqwnjRp++gH4ntBHQA==; 24:qTDwcLTT8DPg+zJjdc0mKBatEgcYn981WJdnPtFmTgdgYWv9fe+W1HVm3o44OM0AOZNksICRWt2sSrXCfxiBzs61QfKFirHiD3rFyIimYnQ=; 20:RbfFo1FEaiJXF0tM9EjlvfFuyeJY3yBCPraCjYZ/IIJzjY0MxUMkSULtiugDLqKKBr22FWqcPsQOvgX/t/dDxA== SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-MS-Exchange-CrossTenant-OriginalArrivalTime: 05 Oct 2015 08:37:24.5364 (UTC) X-MS-Exchange-CrossTenant-Id: 1a407a2d-7675-4d17-8692-b3ac285306e4 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=1a407a2d-7675-4d17-8692-b3ac285306e4; Ip=[23.103.247.180]; Helo=[011-smtp-out.Philips.com] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DBXPR04MB223 X-Microsoft-Exchange-Diagnostics: 1; DBXPR04MB270; 2:pBby19ysPV7I3+4qmhud1LWhPvTLELDRzqmkp5bJEv5aHABBlOlfUYZk/MiIs6L8cPhksc5NUQTG2qKdpDn8m6KRJe57c5xFFNr0/ADIjSfcIjipe9/unjsjG2nQ2lsugptBzZOg1nUKbPweMbf0q/PHVo5x3G9pFRfM2YhWlpU=; 23:5Y5sRcSXSmLQj1MxWqrLIBvlZ8HVH23gX2rXYzbZ3YKppRye6fKL91ociKL2fLpB06Exvur2KAaVTwWEemPMDpwb2DkYlI3hLR4iQIHDnXWiwOZhiNyUyxaW1+7nOa00BJt+fh4KEFRc+2EiC4CGhkomd/imRrSZUVY7QxTC4NzNz1LFO84mzaQ991Yd/VmD X-OriginatorOrg: philips.com Archived-At: Subject: Re: [Ace] [ACE] review draft-ietf-ace-usecases-06 X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 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, 05 Oct 2015 08:37:59 -0000 --_000_303a8355069d43bda17b076e709fc499DB5PR9001MB0167MGDPHGem_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Abhinav True..I tried to combine the commissioning into the re-commissioning phase = to get the main ideas related to commissioning and the maintenance part tog= ether. Indeed the first commissioning can be quite different from a later c= ommissioning since the supporting infrastructure (like IT ) may now be avai= lable (although the supporting infrastructure may itself be in a re-commiss= ioning phase making it unavailable, but let's not get into those details). = Anyways I will make a re-edit to get your main concerns more clearly stated= in the document. Regards Sandeep From: Somaraju Abhinav [mailto:abhinav.somaraju@tridonic.com] Sent: Monday, October 05, 2015 10:12 AM To: Kumar, Sandeep ; Ace@ietf.org Subject: RE: [ACE] review draft-ietf-ace-usecases-06 Hi Sandeep, Thanks for the reply. Maybe there is a confusion of terminology here. The s= ituation that you described in the installation/commissioning section is wh= at I would usually call recommissioning. Please see remaining comments inli= ne. Sec. 2.4.1.1. "A vacant area of the building has been recently leased to co= mpany A. Before moving into its new office, Company A wishes to replace the lighting with a more energy efficient and a better light quality luminaries. They hire an installation and commissioning company C to redo the illumination." >From my knowledge of Building automation and professional lighting this sce= nario is highly unlikely. Usually a leasing company hires a space and the l= ights come as package with the space and are built into the leasing company= 's contract. If the leasing company wishes to change the luminaires they ty= pically have to speak to the (representative of) the building owner but thi= s is quite rare. There are some specific regions in the world e.g. central = EU where this is not always the case. Sometimes in central EU, the building= s do not have any built in luminaires and the leasing companies bring in th= eir own freestanding luminaires. It is very rarely the case that a leasing = tenant hires a contractor to change the lighting system. The situations is = more complicated for HVAC systems which often need to satisfy regulatory re= quirements. HVAC systems are often done building wide and are very rarely t= enant specific. [> ] You are right about the current status in certain central European cou= ntries regarding how office space leasing is done. I have taken a more gene= ral approach to include issues from other domains like retail where indoor = lighting is tied closely to the branding independent of where they lease th= eir space. Instead of creating multiple use cases or geographic specific ca= ses, I took a practical approach to extend the office scenario that can exp= lain what type of issues may be relevant in professional lighting in differ= ent related domains. This way technology developed in ACE is the not the bl= ocking factor for end-users to demand a different choice than they have tod= ay. Does the extension bother you regarding how it would guide the solution= direction making it inapplicable in your more restricted setting? [AS] My main issue is that commissioning a part of the building by the leas= ing company using independent contractors is very much a corner case when i= t comes to Building automation (and almost never applicable to anything oth= er than (retail) lighting because of regulatory requirements). Maybe my pre= vious email was not clear about this point - Central EU is sometimes an exc= eption to this rule and is one of the corner cases where the leasing compan= y brings their "own lighting using free-standing luminaires". My concern wi= th the text is that the main issues with regards to initial installation/co= mmissioning in buildings have not been mentioned (which is the following po= int). A very important aspect of the installation/commissioning workflow has been= overlooked. Typically, installation in the building occur in the following= order (in a new building). 1) Installation of the lighting devices by an u= ntrained electrician, 2) A lighting commissioning engineer who configures l= ights 3) Installation of HVAC systems 4) First presence of trained IT profe= ssionals. So, the initial commissioning/installation process needs to be performed by= people with no IT knowledge and with the IT backbone not being present. Al= so, the commissioning goes in phases with different floors being commission= ed at different times and then later connected together with the IT backbon= e. Not having the IT backbone during commissioning puts big constraints bec= ause it is difficult to use public key certs during this process. [> ] Indeed true regarding no IT connectivity to devices and forming indivi= dual islands before joining them for a new installation. I think I had it i= n the previous version but it changed after it combined with the HVAC use c= ase. The current description is more shifted towards an already up and run= ning system which changes ownership. I can include in those things. Do you = see other authorization problems that needs to be added based on the change= ? I do not know if it directly means "no public key certs" since the commissi= oning tool can potentially be connected to a backend. [AS] I can only judge new authorization problems after looking at the text.= Some of the key issues during the initial commissioning phase are: 1) Phas= ed commissioning/installation: different parts of the building are installe= d by (sometimes) different installers/commissioners usually by people with = no IT background. But at a later stage when the parts are connected, they h= ave to work as a single system. 2) Lack of IT backbone as already mentioned= (though the commissioner can use public key certs the devices probably can= 't authenticate commissioner - maybe not important?), 3) Requiring some out= of the box functionality before the commissioner is on site to allow some = installation testing, 4) The devices being physically inaccessible when the= commissioner is on site but only being accessible during installation (e.g= . HVAC valves or ceiling mounted luminaires - this rules out options such a= s NFC sometimes) 5) Usually there is a long B-2-B chain before the devices = reach the customer (unlike maybe home automation) 6) The initial installers= /commissioners will need to install devices from multiple different supplie= rs (rules out a single company selling "gateway+device" combinations with s= pecific commissioning methods). I think it is important that the use-case document captures these initial i= nstallation/commissioning issues rather than focus on the corner case of on= e tenant independently re-commissioning a part of the building. My use case of installation/commissioning will go along the following lines= : 1) Building owner hires contractor, 2) Contractor hires: architect (to de= sign), electrician (to install) and commissioner (there are several permuta= tions of the above possible with additional actors), 3) Electrician (usuall= y not highly qualified) installs the devices and needs to prove wiring was = done properly (so needs some out of the box probably unsecured communicatio= n), 4) Commissioner comes on site and connects devices to talk to each othe= r (This phase could happen in parallel on multiple floors and sometimes eve= n in parallel with installation). Sometimes there are 10-100 thousand devic= es in the building. Also, several devices are not physically accessible to = the commissioner. This makes it for instance very difficult to map the phys= ical local of sensors (e.g. motion sensors), 5) IT engineer comes on site a= nd connects up the IT backbone and the devices are exposed to the wider int= ernet for the first time. 6) The devices continue to work with not requirin= g the commissioner to come back on site. Another point is that Authorization rules may also be role based. E.g. A co= mmissioner/facility manager might be able to configure devices but a user m= ay only be able to dim up/down the lights. [> ] That sounds more like the choice of solution rather than an authorizat= ion problem. [AS] I would not say this is a choice of solution. In general the users of = the indoor BA can be grouped into categories - maintenance personnel, (nigh= t-time) cleaners, commissioners, BMS, LMS systems, end users (that may occu= py certain floors). The authorization problem is that these categories of u= sers need different access rights. The solution could be a role based autho= rization policy or based on individual authorization policies using unique = identification of the user. However, the fact that such categories of users= exist is really the underlying authorization problem. 2.4.1.3 Maintenance The roles of a facility manager and commissioner (at least in building spea= k) are confused here. Depending on the type of building, there is a facilit= y manager who takes care of issues during the device operation. If changes = are required the facility manager is usually able to make the changes. The = facility manager is sometimes the same individual as the commissioner but n= ot always. We need to put procedures in place so that the commissioner who = commissions at the start can "hand-over" the system to the facility manager= . [> ] The current text does imply a handover to the facility manager (the se= rvice company) since the commissioner needs new authorization to make chang= es during the maintenance stage. Do you have any specific authorization pro= blems in mind by the "hand over" which is not already covered in U4.2 (if y= ou could change the name of the actors). [AS] No. The most common maintenance issue that occur is that of replacing broken de= vices. Therefore, the "authorizations" need to be transferred to the replac= ement device. [> ] This is a good one but needs to be detailed in terms of how much inter= action is needed from the one doing the transfer. It should be less than no= rmal commissioning U4.1 but cannot be zero-configuration either. Any text i= s welcome. [AS] There are two parts to this - first part is configuring the new device= and of course it cannot be zero configuration. The second part is that pro= per disposal of the broken device - hopefully when you through the device i= n the bin and somebody else gets access to it, you do not create any new pr= oblems. A phase that occurs several times and not covered in this use case is recom= missioning. This may occur in several situations: 1) when one tenant moves = out and a new one moves in, 2) Changes in the office space, 3) removing a d= evice from one system and adding it to another [> ] I tried to leave this phase out since I did not see any new authorizat= ion problems (the whole use case is kind of depicted as a recommissioning).= The point of the document is not to explain lighting but to guide the solu= tion development. If you think any new authorization problems need to be ad= ded, we can include this phase. Please let me know. [AS] You cover this use-case to a large extent in the installation/commissi= oning section. However, maybe I missed the point about if a device is remov= ed from one system and recommissioned to a new one then you should not be a= ble to break the old system with the device that has been recommissioned. D= ifference from decommissioning use-case is that the device stills needs to = work properly in the new system. Regards Sandeep ________________________________________________________ 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. ________________________________ The information contained in this message may be confidential and legally p= rotected under applicable law. The message is intended solely for the addre= ssee(s). If you are not the intended recipient, you are hereby notified tha= t any use, forwarding, dissemination, or reproduction of this message is st= rictly prohibited and may be unlawful. If you are not the intended recipien= t, please contact the sender by return e-mail and destroy all copies of the= original message. ________________________________________________________ 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. --_000_303a8355069d43bda17b076e709fc499DB5PR9001MB0167MGDPHGem_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Abhinav<= /span>

 

True..I tried to combi= ne the commissioning into the re-commissioning phase to get the main ideas = related to commissioning and the maintenance part together. Indeed the firs= t commissioning can be quite different from a later commissioning since the supporting infrastructure (like IT ) = may now be available (although the supporting infrastructure may itself be = in a re-commissioning phase making it unavailable, but let’s not get = into those details). Anyways I will make a re-edit to get your main concerns more clearly stated in the document.

 

Regards

Sandeep

 

From: Somaraju Abhinav [mailto:abhinav.somara= ju@tridonic.com]
Sent: Monday, October 05, 2015 10:12 AM
To: Kumar, Sandeep <sandeep.kumar@philips.com>; Ace@ietf.org Subject: RE: [ACE] review draft-ietf-ace-usecases-06

 

Hi Sandeep,=

Thanks for the reply. = Maybe there is a confusion of terminology here. The situation that you desc= ribed in the installation/commissioning section is what I would usually cal= l recommissioning. Please see remaining comments inline.

 

 = 

Sec. 2.=
4.1.1. “A vacant area of the building has been recently leased to com=
pany A.
 &=
nbsp; Before moving into its new office, Company A wishes to replace the
 &=
nbsp; lighting with a more energy efficient and a better light quality=

 &=
nbsp; luminaries.  They hire an installation and commissioning company=
 C to
 &=
nbsp; redo the illumination.”
&n=
bsp;
From my=
 knowledge of Building automation and professional lighting this scenario i=
s highly unlikely. Usually a leasing company hires a space and the lights c=
ome as package with the space and are built into the leasing company’=
s contract. If the leasing company wishes to change the luminaires they typ=
ically have to speak to the (representative of) the building owner but this=
 is quite rare. There are some specific regions in the world e.g. central E=
U where this is not always the case. Sometimes in central EU, the buildings=
 do not have any built in luminaires and the leasing companies bring in the=
ir own freestanding luminaires. It is very rarely the case that a leasing t=
enant hires a contractor to change the lighting system. The situations is m=
ore complicated for HVAC systems which often need to satisfy regulatory req=
uirements. HVAC systems are often done building wide and are very rarely te=
nant specific. 
=
 
[> ] You ar=
e right about the current status in certain central European countries rega=
rding how office space leasing is done. I have taken a more general approac=
h to include issues from other domains like retail where indoor lighting is=
 tied closely to the branding independent of where they lease their space. =
Instead of creating multiple use cases or geographic specific cases, I took=
 a practical approach to extend the office scenario that can explain what t=
ype of issues may be relevant in professional lighting in different related=
 domains. This way technology developed in ACE is the not the blocking fact=
or for end-users to demand a different choice than they have today. Does th=
e extension bother you regarding how it would guide the solution direction =
making it inapplicable in your more restricted setting? <=
/i>
[AS] My main issue i=
s that commissioning a part of the building by the leasing company using in=
dependent contractors is very much a corner case when it comes to Building =
automation (and almost never applicable to anything other than (retail) lig=
hting because of regulatory requirements). Maybe my previous email was not =
clear about this point - Central EU is sometimes an exception to this rule =
and is one of the corner cases where the leasing company brings their ̶=
0;own lighting using free-standing luminaires”. My concern with the t=
ext is that the main issues with regards to initial installation/commission=
ing in buildings have not been mentioned (which is the following point). 
 
A very =
important aspect of the installation/commissioning workflow has been overlo=
oked. Typically, installation in the building occur in the following order =
(in a new building). 1) Installation of the lighting devices by an untraine=
d electrician, 2) A lighting commissioning engineer who configures lights 3=
) Installation of HVAC systems 4) First presence of trained IT professional=
s. 
=
 
So, the=
 initial commissioning/installation process needs to be performed by people=
 with no IT knowledge and with the IT backbone not being present. Also, the=
 commissioning goes in phases with different floors being commissioned at d=
ifferent times and then later connected together with the IT backbone. Not =
having the IT backbone during commissioning puts big constraints because it=
 is difficult to use public key certs during this process. 
=
 
[> ] Indeed=
 true regarding no IT connectivity to devices and forming individual island=
s before joining them for a new installation. I think I had it in the previ=
ous version but it changed after it combined with the HVAC use case.  =
The current description is more shifted towards an already up and running s=
ystem which changes ownership. I can include in those things. Do you see ot=
her authorization problems that needs to be added based on the change?=

I do not know =
if it directly means “no public key certs” since the commission=
ing tool can potentially be connected to a backend. 
[AS] I can only judg=
e new authorization problems after looking at the text. Some of the key iss=
ues during the initial commissioning phase are: 1) Phased commissioning/ins=
tallation: different parts of the building are installed by (sometimes) dif=
ferent installers/commissioners usually by people with no IT background. Bu=
t at a later stage when the parts are connected, they have to work as a sin=
gle system. 2) Lack of IT backbone as already mentioned (though the commiss=
ioner can use public key certs the devices probably can’t authenticat=
e commissioner – maybe not important?), 3) Requiring some out of the =
box functionality before the commissioner is on site to allow some installa=
tion testing, 4) The devices being physically inaccessible when the commiss=
ioner is on site but only being accessible during installation (e.g. HVAC v=
alves or ceiling mounted luminaires – this rules out options such as =
NFC sometimes) 5) Usually there is a long B-2-B chain before the devices re=
ach the customer (unlike maybe home automation) 6) The initial installers/c=
ommissioners will need to install devices from multiple different suppliers=
 (rules out a single company selling “gateway+device” combi=
nations with specific commissioning methods). 
 
I think it is import=
ant that the use-case document captures these initial installation/commissi=
oning issues rather than focus on the corner case of one tenant independent=
ly re-commissioning a part of the building. 
 
My use case of insta=
llation/commissioning will go along the following lines: 1) Building owner =
hires contractor, 2) Contractor hires: architect (to design), electrician (=
to install) and commissioner (there are several permutations of the above p=
ossible with additional actors), 3) Electrician (usually not highly qualifi=
ed) installs the devices and needs to prove wiring was done properly (so ne=
eds some out of the box probably unsecured communication), 4) Commissioner =
comes on site and connects devices to talk to each other (This phase could =
happen in parallel on multiple floors and sometimes even in parallel with i=
nstallation). Sometimes there are 10-100 thousand devices in the building. =
Also, several devices are not physically accessible to the commissioner. Th=
is makes it for instance very difficult to map the physical local of sensor=
s (e.g. motion sensors), 5) IT engineer comes on site and connects up the I=
T backbone and the devices are exposed to the wider internet for the first =
time. 6) The devices continue to work with not requiring the commissioner t=
o come back on site.
 
Another=
 point is that Authorization rules may also be role based. E.g. A commissio=
ner/facility manager might be able to configure devices but a user may only=
 be able to dim up/down the lights. 
=
 
[> ] That s=
ounds more like the choice of solution rather than an authorization problem=
.
[AS] I would not say=
 this is a choice of solution. In general the users of the indoor BA can be=
 grouped into categories – maintenance personnel, (night-time) cleane=
rs, commissioners, BMS, LMS systems, end users (that may occupy certain flo=
ors). The authorization problem is that these categories of users need diff=
erent access rights. The solution could be a role based authorization polic=
y or based on individual authorization policies using unique identification=
 of the user. However, the fact that such categories of users exist is real=
ly the underlying authorization problem. 
2.4.1.3=
 Maintenance
The rol=
es of a facility manager and commissioner (at least in building speak) are =
confused here. Depending on the type of building, there is a facility manag=
er who takes care of issues during the device operation. If changes are req=
uired the facility manager is usually able to make the changes. The facilit=
y manager is sometimes the same individual as the commissioner but not alwa=
ys. We need to put procedures in place so that the commissioner who commiss=
ions at the start can “hand-over” the system to the facility ma=
nager.
=
 
[> ] The cu=
rrent text does imply a handover to the facility manager (the service compa=
ny) since the commissioner needs new authorization to make changes during t=
he maintenance stage. Do you have any specific authorization problems in mi=
nd by the “hand over” which is not already covered in U4.2 (if =
you could change the name of the actors).
[AS] No.<=
/span>
 
The mos=
t common maintenance issue that occur is that of replacing broken devices. =
Therefore, the “authorizations” need to be transferred to the r=
eplacement device.
=
 
[> ] This i=
s a good one but needs to be detailed in terms of how much interaction is n=
eeded from the one doing the transfer. It should be less than normal commis=
sioning U4.1 but cannot be zero-configuration either. Any text is welcome.<=
o:p>
 
[AS] There are two p=
arts to this – first part is configuring the new device and of course=
 it cannot be zero configuration. The second part is that proper disposal o=
f the broken device – hopefully when you through the device in the bi=
n and somebody else gets access to it, you do not create any new problems. =

&n=
bsp;
A phase=
 that occurs several times and not covered in this use case is recommiss=
ioning. This may occur in several situations: 1) when one tenant moves =
out and a new one moves in, 2) Changes in the office space, 3) removing a d=
evice from one system and adding it to another
=
 
[> ] I trie=
d to leave this phase out since I did not see any new authorization problem=
s (the whole use case is kind of depicted as a recommissioning). The point =
of the document is not to explain lighting but to guide the solution develo=
pment. If you think any new authorization problems need to be added, we can=
 include this phase. Please let me know. 
[AS] You cover this =
use-case to a large extent in the installation/commissioning section. Howev=
er, maybe I missed the point about if a device is removed from one system a=
nd recommissioned to a new one then you should not be able to break the old=
 system with the device that has been recommissioned. Difference from decom=
missioning use-case is that the device stills needs to work properly in the=
 new system. 
 
Regards
Sandeep=

&n=
bsp;

________________________________________________= ________ The contents of this e-mail and any attachments are confidential t= o the intended recipient. They may not be disclosed to or used by or copied in any way by anyone other than the intended recip= ient. If this e-mail is received in error, please immediately notify the se= nder 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 sca= n or otherwise check this e-mail and any attachments.

 

The information contained in this message m= ay be confidential and legally protected under applicable law. The message = is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, forw= arding, dissemination, or reproduction of this message is strictly prohibit= ed and may be unlawful. If you are not the intended recipient, please conta= ct the sender by return e-mail and destroy all copies of the original message.

________________________________________________= ________ The contents of this e-mail and any attachments are confidential t= o the intended recipient. They may not be disclosed to or used by or copied in any way by anyone other than the intended recip= ient. If this e-mail is received in error, please immediately notify the se= nder 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 sca= n or otherwise check this e-mail and any attachments.

--_000_303a8355069d43bda17b076e709fc499DB5PR9001MB0167MGDPHGem_-- From nobody Mon Oct 5 02:05:10 2015 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85D001B4E52 for ; Mon, 5 Oct 2015 02:05:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.55 X-Spam-Level: X-Spam-Status: No, score=-1.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LkSI07E2q0LU for ; Mon, 5 Oct 2015 02:05:08 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7BE0D1B4E4C for ; Mon, 5 Oct 2015 02:05:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [134.102.201.11]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id t95955bt026632; Mon, 5 Oct 2015 11:05:05 +0200 (CEST) Received: from aung.tzi.org (eduroam-pool4-373.wlan.uni-bremen.de [134.102.147.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3nTwxF0YZrz4pR0; Mon, 5 Oct 2015 11:05:05 +0200 (CEST) From: Olaf Bergmann To: Somaraju Abhinav References: <0E9A48AB39AF3547ACD28A6DE3E2906A0AB169@ATBRAGMSX02.itiso.net> <87fv1p92fe.fsf@aung.informatik.uni-bremen.de> <0E9A48AB39AF3547ACD28A6DE3E2906A0AC2D5@ATBRAGMSX02.itiso.net> Date: Mon, 05 Oct 2015 11:05:04 +0200 In-Reply-To: <0E9A48AB39AF3547ACD28A6DE3E2906A0AC2D5@ATBRAGMSX02.itiso.net> (Somaraju Abhinav's message of "Mon, 5 Oct 2015 08:37:16 +0000") Message-ID: <877fn18z3z.fsf@aung.informatik.uni-bremen.de> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "Ace@ietf.org" Subject: Re: [Ace] [ACE] review draft-ietf-ace-usecases-06 X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 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, 05 Oct 2015 09:05:09 -0000 Somaraju Abhinav writes: > Thanks for the clarification. I usually do not understand exactly when > an API is RESTful. If you think all the use cases can be covered with > Restful APIs, then please ignore my comment - the distinction between > Restful vs RPC is not very important for me. Fair enough. What I wanted to avoid is to open up the ACE for boiling the ocean. After taking out CoAP we are going to take out REST... Hopefully, we do not end up in taking out authorization :-) Gr=C3=BC=C3=9Fe Olaf From nobody Mon Oct 5 02:14:30 2015 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E6DB1B4EB1 for ; Mon, 5 Oct 2015 02:14:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xxX_yVYyDs7u for ; Mon, 5 Oct 2015 02:14:18 -0700 (PDT) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0795.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::795]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4CD161B4E3E for ; Mon, 5 Oct 2015 02:14:16 -0700 (PDT) Received: from HE1PR06CA0002.eurprd06.prod.outlook.com (10.162.181.140) by DB5PR06MB1480.eurprd06.prod.outlook.com (10.164.40.30) with Microsoft SMTP Server (TLS) id 15.1.286.20; Mon, 5 Oct 2015 09:13:57 +0000 Received: from DB3FFO11FD013.protection.gbl (2a01:111:f400:7e04::160) by HE1PR06CA0002.outlook.office365.com (2a01:111:e400:51fa::12) with Microsoft SMTP Server (TLS) id 15.1.286.20 via Frontend Transport; Mon, 5 Oct 2015 09:13:57 +0000 Authentication-Results: spf=fail (sender IP is 146.108.200.10) smtp.mailfrom=tridonic.com; philips.com; dkim=none (message not signed) header.d=none;philips.com; dmarc=none action=none header.from=tridonic.com; Received-SPF: Fail (protection.outlook.com: domain of tridonic.com does not designate 146.108.200.10 as permitted sender) receiver=protection.outlook.com; client-ip=146.108.200.10; helo=ATDOAGMSX01.itiso.net; Received: from ATDOAGMSX01.itiso.net (146.108.200.10) by DB3FFO11FD013.mail.protection.outlook.com (10.47.216.187) with Microsoft SMTP Server (TLS) id 15.1.286.14 via Frontend Transport; Mon, 5 Oct 2015 09:13:56 +0000 Received: from ATBRAGMSX02.itiso.net ([169.254.2.75]) by ATDOAGMSX01.itiso.net ([169.254.3.28]) with mapi id 14.03.0248.002; Mon, 5 Oct 2015 11:13:55 +0200 From: Somaraju Abhinav To: "Kumar, Sandeep" , "Ace@ietf.org" Thread-Topic: [ACE] review draft-ietf-ace-usecases-06 Thread-Index: AdD8XTFdDVkUObPhQvi/FvrOxuHgzQAwVt6wAIgXbCAAAkjHQAABg3HA Date: Mon, 5 Oct 2015 09:13:54 +0000 Message-ID: <0E9A48AB39AF3547ACD28A6DE3E2906A0AC307@ATBRAGMSX02.itiso.net> References: <0E9A48AB39AF3547ACD28A6DE3E2906A0AB169@ATBRAGMSX02.itiso.net> <0E9A48AB39AF3547ACD28A6DE3E2906A0AC250@ATBRAGMSX02.itiso.net> <303a8355069d43bda17b076e709fc499@DB5PR9001MB0167.MGDPHG.emi.philips.com> In-Reply-To: <303a8355069d43bda17b076e709fc499@DB5PR9001MB0167.MGDPHG.emi.philips.com> Accept-Language: en-US, de-AT Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [146.108.41.149] Content-Type: multipart/alternative; boundary="_000_0E9A48AB39AF3547ACD28A6DE3E2906A0AC307ATBRAGMSX02itison_" MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Microsoft-Exchange-Diagnostics: 1; DB3FFO11FD013; 1:zuBR/Pfk9mZYreZwf7C1yZXi2VQFy3Md8CgAi3UpeXLaiYFfIyk+6JRgRByxLnTKby7B3apTh35HbFfVvXw56EpAjUC8ijBh5tzY2Xn3nB05L98owd16NRFddk+RBjQUQJm9Gxu5lwbPchFdON63QaY49Y9i2za8eGGj7FAyb6fu8QTLRrfuBbISCLVkZYri1BDP1M33tFAaFjrVt6l549kjKKMz2VZfJFU9wcor2Te2TfBARiYdeXsMJ9w2T6d8iAOOXRbFNfD5Ep4zhR1uwjLmC5RmdfbljatDvCBYK//o1hXfk8lVR4gUaovcEyai86JZ7Udx2rd92SvRQOb0iYfQD71yvhdfN/l+N53vViw= X-Forefront-Antispam-Report: CIP:146.108.200.10; CTRY:AT; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(2980300002)(1110001)(1109001)(339900001)(51914003)(45074003)(199003)(377454003)(85714005)(55904004)(189002)(374574003)(76176999)(81156007)(2920100001)(105606002)(19580395003)(2900100001)(92566002)(33656002)(11100500001)(93886004)(106466001)(2950100001)(189998001)(64706001)(87936001)(66066001)(5003600100002)(5001960100002)(53416004)(512954002)(4001540100001)(102836002)(26826002)(15975445007)(107886002)(19580405001)(50986999)(5004730100002)(19625215002)(5007970100001)(55846006)(69596002)(62966003)(230783001)(86362001)(5001830100001)(77156002)(54356999)(84326002)(16236675004)(5008740100001)(85426001)(5001860100001)(5001770100001)(2501003)(46102003)(5890100001)(104016004)(6806005)(19300405004)(567094001)(579004); DIR:OUT; SFP:1102; SCL:1; SRVR:DB5PR06MB1480; H:ATDOAGMSX01.itiso.net; FPR:; SPF:Fail; PTR:unknown.zgrp.net; A:1; MX:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; DB5PR06MB1480; 2:aNwsypmvbei3ZStRBm3/f76khqV87PW/+UJwy/wbOoFop2iv9rvssG/Ckmw1ozAp3UsA3T0thQ3ozcnx3IvSsTz9flM1MNEJjV0KLBY8w67BEm7P4iWpO7KFkWHgWkhb4Iz0t4qrnqfb2DU2a2YjUGvVwDU4NhRdWm1qBD5JLVw=; 3:ebzzpQbU7xs0VlzWGKVJ1jb5QNGrlYX7YyL7HYCKMsWBdQfwgZ2IQvESCYHBvp6khn2XDZm2/zmWgEdUxDdZNX0/gSWJNjQ/mu+xUhf9ojH7rC0cHPWrLl5xUHfsMAH4Fb9kUsJV9Nv54h/eat+uK9uxBoeZLZwI1p+Ic5zfQEDgwB7TeTz475PQPsGJNjVIYB80AQlzW5UQFF08daV/E3FxE5w9h1SXVIFivvfZRakEWkj+PaR3Srx7/BIP/yKE; 25:pm4yiMghIW6ZOe1QOd/bDGI2qOVRRuZqUIuFJCT4BBJYg3skd32w15kueF95c/ffFHYBeTsFC/K7UdKmnmlZZZq6r6KJ13Drg5Sjxr5KHNm21Eq596+or0u+oOvS29wrJg3O8HsMsIwIyom0dzd1/HOhPe/En+4Tcwfb1f3yx08KHOk3k3X5siw4nPinYnPksorB84Mg9XYx7XTAAcGGNoXxZYyxrPT01vdHN8PP6woYMBX5Z2TiQgueJBpyvNpExVKRSMvYYoeySA7ZfCAFig== X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DB5PR06MB1480; X-Microsoft-Exchange-Diagnostics: 1; DB5PR06MB1480; 20:j9IyWlmD4spt60zKTx47KYpqa39D//cQQKQfXbtQp4tOc/WOyqZc2E5QIF3zeE5EW0NP6lZvMpM8Ltp0cKrEtIbr2Eu32rnOiFpGj+E0/d2O+eWW0sGps7uWYdtghhGkNbHsyGimtaptiQY2H/wDX9LspteymZd5OJt2HV9yTh6t7d3YdV8b1Y4PXrU3GXH7HiJbRZzH+TIhG1I7SD7zVoJbm7cECLVlwxx3SquDPU0cbl1wjqiLuBtfuSrSEfAQAIX68c/t+gqFnH4uiVEeWUBthUv1C2cF0zi5kbWCUQ5bsggoZ3vnyCas5HfEUYZaZB9zY7mvlFXxeo00za8hCUqND7nmiRr7XSexv+e5O+n6RTpQ0HeneRm6CSJ6rpIwwq3l9JahI8KMmWBeNIB/Eflp2D4LSGBYkByPjsDuYwrKvapU0uuV0XRUwWin3a7K3L2nSzGbFiM2wpzWO1hSdMZ2Fo7RR/ciAMp3HH72Ap1KohRYkOmTmhqmbg4DfB3Q; 4:EdzH4Tu3v2M6SCPLa5pcVsUrxneRrlHSu24DAAyTSRglIxflhp7HSwc6jY61BCvjZyG7Yqziwo5/e65BTU9ch8QJyHU8M3no1Glt+8FsAVFN1seFtoDljLEhoDX/zmjlSEMp6H3wROBsKy0xEXDdp3smUTw+fqVwm0fV6SSc5PX7+VZJgKNscpTWRlKv6T3YTKooXIMf3CBK8JQgwMqfJobv6fFVoX0fYk/QvRIHYZe8ax9ZCVDy+fkOCTD4iVw6q8VA/Y+R+mfpkLRcE1Alzlp/m03ySRzGHl4DeOqi5qs9H+zURL/92vhuV98SMmtfieQAhtU2V96JIBI5VXt+dfWeLAwIHKwlmTFGFu1l5iU= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(108003899814671); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(520078)(8121501046)(5005006)(3002001); SRVR:DB5PR06MB1480; BCL:0; PCL:0; RULEID:; SRVR:DB5PR06MB1480; X-Forefront-PRVS: 07200C0526 X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; DB5PR06MB1480; 23:PWeOHtWTeQ1iy0A8m81lVth/dFYeFDBdCF69Ae2u8?= =?us-ascii?Q?+bORQKvoyMMFmvkWkCFDyM3xjoQMyi/J8d+2MPuYgAyXMN9W5zuJme/BojJ0?= =?us-ascii?Q?CgyBCFLRqZFrZi6ly2dLDnkAkkYVcLIMOkUJJQ9QTEUX2hJQVHw9PCKMVNUe?= =?us-ascii?Q?Hjo7McVk59q6StEm2GHy5e2A0d28xYXH3Ac6l9q/ftfXjNQM4Ggc5+/8SyGd?= =?us-ascii?Q?SLi/EaQf+kq0SIDgwGVOHZoA4+4UVd+SeEzzaqw04ieKavVogeGALBGJpgei?= =?us-ascii?Q?1Mq4+Ylgt9F1daMsau125EiuNskVydF6uI5b6MZpi75+cYgj3OhdHtpzIdfO?= =?us-ascii?Q?0Bh93pRND1qPc2tOQ7TCtwq+RPVEPdrQwKbE8gtSjehYMKX7mlGhg4Ead3Cw?= =?us-ascii?Q?0+rBKEQNhObLiIzIEB2q6QivtEsb5bBZfP9P9KM1AZ5l8iCwXIbIWbE33cpw?= =?us-ascii?Q?CZjd8iohihb3ZBMuiW2YZ8lyqK37BuGH2WqUU4yod9Uto1ZPWQWR3zaCO+Pu?= =?us-ascii?Q?Xk456RVmPjg6xquec5j11cEueX6uZ8GKjAAfoeIzenj0qnTNMAFoQjvqrDRV?= =?us-ascii?Q?8dJVWSftVHl5s1HYGF/hbSzWvup9wu5fzz/3l8Oev6xbdMeRpWM1z8510C/G?= =?us-ascii?Q?7eW9UyeTQMiH+A83pxAO0qH4g40ZTd2RS/LUDajPHqI2s5JAlT4pCzwDiGu0?= =?us-ascii?Q?sgmSbWLRY91vTdfeMnXTokTgmr0vFEAJmT9JLVYVrEtCLK4xbmhoRqntQBcG?= =?us-ascii?Q?jN19gYOvqYuaFFS4aGGSGFAZj/oyQZ4lBciRWENCzLlEcYKUfwGWB4Ms8fSW?= =?us-ascii?Q?3Pge7ULxRtWsYIGehE4Yw5itwBqQEjXQWI4OI4+13U1YluUO6qA3yj11LNuL?= =?us-ascii?Q?q5MqLGAxgVgpM3fUH15vjgmC00aIy9EMyFfiNQA3IUS5c++CEExsM56vg8yv?= =?us-ascii?Q?Uv52rTOkkKsNbdRb5alkIq2f5Ur3nU22SZiHt3GYQnJA/683eeGoH+J+IfFV?= =?us-ascii?Q?k+u6uRQ67fYC84S819C1NJRyBE9qgflQ9AqqpykJq5kahH8GKFrC5amLrTYe?= =?us-ascii?Q?KVEKPHj4d79huxank5zKZN7gpKsZWVkkvkd0FUDF3Z/OVInOkf5unYSdiLJ1?= =?us-ascii?Q?bzt1DKcL2IlHC7HhaD6/vRgXCOcQw7vMRNDC4sRMKAgKwKiN0q9H0Wtu9Jo4?= =?us-ascii?Q?nTDeKRnBHOlSQ7NbeoIvhfEkkbV0cls59rN6ExM1m+VXx5iqkAYNwRGH82Mz?= =?us-ascii?Q?I/fqvWmh5b3zKkZWdAF7YqKomDIX21Ry2QZr4T46zAC1VGz2mhCRfiFNYUUM?= =?us-ascii?Q?4FfmlGHIRrzVjLrtgl/9otF6uA4g75klR87RdEHRBDIz2BmCc4rnoPgD5VjE?= =?us-ascii?Q?A1m1b5P2KJDIoRNERpi3GwQ28RfLFbcoCJaR/x1c+CkZEgy9JqTceqPad3Nb?= =?us-ascii?Q?dwxuKKQ9cO3zlOlOqiK/zQxapAZxH2EYxFH69jfwD52D3hCgLtXOhx4RbG1y?= =?us-ascii?Q?gI4V6m7Ug3+AXijqF+Ed1f1Eh8qVgLNv9dcB/fmcTTXDyin2YK/P+NwI8yWf?= =?us-ascii?Q?OB+RFK9uiBuXYoRNRnRnXLqPqEuFe3liCVeklKd23sNDnOOxUz7Sb5kd/oRd?= =?us-ascii?Q?2RUebPktQc2Qgwopn80t1oTYBJ/fdqkra4lK6xBu0bry9nft+HZiWRQtTq+u?= =?us-ascii?Q?lRjnBybIaJJ7FO9F3b56y/VS8/HFcywsUvVxd7tRK3PmMI=3D?= X-Microsoft-Exchange-Diagnostics: 1; DB5PR06MB1480; 5:/iV5wxqlWI5VRx0Hg63Z9hwUtNASqXWqrrOUlN4A/2sL31uxJgaghbJdUb9zLhbLWGxCD4p6Cp04LtwsgrzU12d1dxK2c9Q7VHSvzL9KxhF2JYrcytv60bQUH9qgwuXNHXYk5LZxZUZMbWfFNIDV7Q==; 24:ukmA3UsRFKZN/qv/N+oQHEHGz5A2IsdbR9inZQDsJdH9FUNaF4Yq9klmoRFXkiBcF+eWs8qkLRR1a7jgcphMJ02sqXqJE5BIbQ4OlmG4hng=; 20:92vM2crWtKv1BpgcTSV+ZmK7RXVZ3J4ueZCSowSCs0ZwqIPZlatP0/putmFzHxxJ/MrKA978Xt6aObNFhmzfag== SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: tridonic.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 05 Oct 2015 09:13:56.4399 (UTC) X-MS-Exchange-CrossTenant-Id: 8b206608-a593-4ace-a4b6-ef1fc83c9169 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=8b206608-a593-4ace-a4b6-ef1fc83c9169; Ip=[146.108.200.10]; Helo=[ATDOAGMSX01.itiso.net] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB5PR06MB1480 Archived-At: Subject: Re: [Ace] [ACE] review draft-ietf-ace-usecases-06 X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 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, 05 Oct 2015 09:14:29 -0000 --_000_0E9A48AB39AF3547ACD28A6DE3E2906A0AC307ATBRAGMSX02itison_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Grt! Looking forward to your new draft. Abhinav From: Kumar, Sandeep [mailto:sandeep.kumar@philips.com] Sent: Montag, 05. Oktober 2015 10:37 To: Somaraju Abhinav; Ace@ietf.org Subject: RE: [ACE] review draft-ietf-ace-usecases-06 Hi Abhinav True..I tried to combine the commissioning into the re-commissioning phase = to get the main ideas related to commissioning and the maintenance part tog= ether. Indeed the first commissioning can be quite different from a later c= ommissioning since the supporting infrastructure (like IT ) may now be avai= lable (although the supporting infrastructure may itself be in a re-commiss= ioning phase making it unavailable, but let's not get into those details). = Anyways I will make a re-edit to get your main concerns more clearly stated= in the document. Regards Sandeep From: Somaraju Abhinav [mailto:abhinav.somaraju@tridonic.com] Sent: Monday, October 05, 2015 10:12 AM To: Kumar, Sandeep >; Ace@ietf.org Subject: RE: [ACE] review draft-ietf-ace-usecases-06 Hi Sandeep, Thanks for the reply. Maybe there is a confusion of terminology here. The s= ituation that you described in the installation/commissioning section is wh= at I would usually call recommissioning. Please see remaining comments inli= ne. Sec. 2.4.1.1. "A vacant area of the building has been recently leased to co= mpany A. Before moving into its new office, Company A wishes to replace the lighting with a more energy efficient and a better light quality luminaries. They hire an installation and commissioning company C to redo the illumination." >From my knowledge of Building automation and professional lighting this sce= nario is highly unlikely. Usually a leasing company hires a space and the l= ights come as package with the space and are built into the leasing company= 's contract. If the leasing company wishes to change the luminaires they ty= pically have to speak to the (representative of) the building owner but thi= s is quite rare. There are some specific regions in the world e.g. central = EU where this is not always the case. Sometimes in central EU, the building= s do not have any built in luminaires and the leasing companies bring in th= eir own freestanding luminaires. It is very rarely the case that a leasing = tenant hires a contractor to change the lighting system. The situations is = more complicated for HVAC systems which often need to satisfy regulatory re= quirements. HVAC systems are often done building wide and are very rarely t= enant specific. [> ] You are right about the current status in certain central European cou= ntries regarding how office space leasing is done. I have taken a more gene= ral approach to include issues from other domains like retail where indoor = lighting is tied closely to the branding independent of where they lease th= eir space. Instead of creating multiple use cases or geographic specific ca= ses, I took a practical approach to extend the office scenario that can exp= lain what type of issues may be relevant in professional lighting in differ= ent related domains. This way technology developed in ACE is the not the bl= ocking factor for end-users to demand a different choice than they have tod= ay. Does the extension bother you regarding how it would guide the solution= direction making it inapplicable in your more restricted setting? [AS] My main issue is that commissioning a part of the building by the leas= ing company using independent contractors is very much a corner case when i= t comes to Building automation (and almost never applicable to anything oth= er than (retail) lighting because of regulatory requirements). Maybe my pre= vious email was not clear about this point - Central EU is sometimes an exc= eption to this rule and is one of the corner cases where the leasing compan= y brings their "own lighting using free-standing luminaires". My concern wi= th the text is that the main issues with regards to initial installation/co= mmissioning in buildings have not been mentioned (which is the following po= int). A very important aspect of the installation/commissioning workflow has been= overlooked. Typically, installation in the building occur in the following= order (in a new building). 1) Installation of the lighting devices by an u= ntrained electrician, 2) A lighting commissioning engineer who configures l= ights 3) Installation of HVAC systems 4) First presence of trained IT profe= ssionals. So, the initial commissioning/installation process needs to be performed by= people with no IT knowledge and with the IT backbone not being present. Al= so, the commissioning goes in phases with different floors being commission= ed at different times and then later connected together with the IT backbon= e. Not having the IT backbone during commissioning puts big constraints bec= ause it is difficult to use public key certs during this process. [> ] Indeed true regarding no IT connectivity to devices and forming indivi= dual islands before joining them for a new installation. I think I had it i= n the previous version but it changed after it combined with the HVAC use c= ase. The current description is more shifted towards an already up and run= ning system which changes ownership. I can include in those things. Do you = see other authorization problems that needs to be added based on the change= ? I do not know if it directly means "no public key certs" since the commissi= oning tool can potentially be connected to a backend. [AS] I can only judge new authorization problems after looking at the text.= Some of the key issues during the initial commissioning phase are: 1) Phas= ed commissioning/installation: different parts of the building are installe= d by (sometimes) different installers/commissioners usually by people with = no IT background. But at a later stage when the parts are connected, they h= ave to work as a single system. 2) Lack of IT backbone as already mentioned= (though the commissioner can use public key certs the devices probably can= 't authenticate commissioner - maybe not important?), 3) Requiring some out= of the box functionality before the commissioner is on site to allow some = installation testing, 4) The devices being physically inaccessible when the= commissioner is on site but only being accessible during installation (e.g= . HVAC valves or ceiling mounted luminaires - this rules out options such a= s NFC sometimes) 5) Usually there is a long B-2-B chain before the devices = reach the customer (unlike maybe home automation) 6) The initial installers= /commissioners will need to install devices from multiple different supplie= rs (rules out a single company selling "gateway+device" combinations with s= pecific commissioning methods). I think it is important that the use-case document captures these initial i= nstallation/commissioning issues rather than focus on the corner case of on= e tenant independently re-commissioning a part of the building. My use case of installation/commissioning will go along the following lines= : 1) Building owner hires contractor, 2) Contractor hires: architect (to de= sign), electrician (to install) and commissioner (there are several permuta= tions of the above possible with additional actors), 3) Electrician (usuall= y not highly qualified) installs the devices and needs to prove wiring was = done properly (so needs some out of the box probably unsecured communicatio= n), 4) Commissioner comes on site and connects devices to talk to each othe= r (This phase could happen in parallel on multiple floors and sometimes eve= n in parallel with installation). Sometimes there are 10-100 thousand devic= es in the building. Also, several devices are not physically accessible to = the commissioner. This makes it for instance very difficult to map the phys= ical local of sensors (e.g. motion sensors), 5) IT engineer comes on site a= nd connects up the IT backbone and the devices are exposed to the wider int= ernet for the first time. 6) The devices continue to work with not requirin= g the commissioner to come back on site. Another point is that Authorization rules may also be role based. E.g. A co= mmissioner/facility manager might be able to configure devices but a user m= ay only be able to dim up/down the lights. [> ] That sounds more like the choice of solution rather than an authorizat= ion problem. [AS] I would not say this is a choice of solution. In general the users of = the indoor BA can be grouped into categories - maintenance personnel, (nigh= t-time) cleaners, commissioners, BMS, LMS systems, end users (that may occu= py certain floors). The authorization problem is that these categories of u= sers need different access rights. The solution could be a role based autho= rization policy or based on individual authorization policies using unique = identification of the user. However, the fact that such categories of users= exist is really the underlying authorization problem. 2.4.1.3 Maintenance The roles of a facility manager and commissioner (at least in building spea= k) are confused here. Depending on the type of building, there is a facilit= y manager who takes care of issues during the device operation. If changes = are required the facility manager is usually able to make the changes. The = facility manager is sometimes the same individual as the commissioner but n= ot always. We need to put procedures in place so that the commissioner who = commissions at the start can "hand-over" the system to the facility manager= . [> ] The current text does imply a handover to the facility manager (the se= rvice company) since the commissioner needs new authorization to make chang= es during the maintenance stage. Do you have any specific authorization pro= blems in mind by the "hand over" which is not already covered in U4.2 (if y= ou could change the name of the actors). [AS] No. The most common maintenance issue that occur is that of replacing broken de= vices. Therefore, the "authorizations" need to be transferred to the replac= ement device. [> ] This is a good one but needs to be detailed in terms of how much inter= action is needed from the one doing the transfer. It should be less than no= rmal commissioning U4.1 but cannot be zero-configuration either. Any text i= s welcome. [AS] There are two parts to this - first part is configuring the new device= and of course it cannot be zero configuration. The second part is that pro= per disposal of the broken device - hopefully when you through the device i= n the bin and somebody else gets access to it, you do not create any new pr= oblems. A phase that occurs several times and not covered in this use case is recom= missioning. This may occur in several situations: 1) when one tenant moves = out and a new one moves in, 2) Changes in the office space, 3) removing a d= evice from one system and adding it to another [> ] I tried to leave this phase out since I did not see any new authorizat= ion problems (the whole use case is kind of depicted as a recommissioning).= The point of the document is not to explain lighting but to guide the solu= tion development. If you think any new authorization problems need to be ad= ded, we can include this phase. Please let me know. [AS] You cover this use-case to a large extent in the installation/commissi= oning section. However, maybe I missed the point about if a device is remov= ed from one system and recommissioned to a new one then you should not be a= ble to break the old system with the device that has been recommissioned. D= ifference from decommissioning use-case is that the device stills needs to = work properly in the new system. Regards Sandeep ________________________________________________________ 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. ________________________________ The information contained in this message may be confidential and legally p= rotected under applicable law. The message is intended solely for the addre= ssee(s). If you are not the intended recipient, you are hereby notified tha= t any use, forwarding, dissemination, or reproduction of this message is st= rictly prohibited and may be unlawful. If you are not the intended recipien= t, please contact the sender by return e-mail and destroy all copies of the= original message. ________________________________________________________ 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. ________________________________________________________ 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. --_000_0E9A48AB39AF3547ACD28A6DE3E2906A0AC307ATBRAGMSX02itison_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Grt! Looking forward t= o your new draft.

Abhinav

 

From: Kumar, S= andeep [mailto:sandeep.kumar@philips.com]
Sent: Montag, 05. Oktober 2015 10:37
To: Somaraju Abhinav; Ace@ietf.org
Subject: RE: [ACE] review draft-ietf-ace-usecases-06

 

Hi Abhinav<= /span>

 

True..I tried to combi= ne the commissioning into the re-commissioning phase to get the main ideas = related to commissioning and the maintenance part together. Indeed the firs= t commissioning can be quite different from a later commissioning since the supporting infrastructure (like IT ) = may now be available (although the supporting infrastructure may itself be = in a re-commissioning phase making it unavailable, but let’s not get = into those details). Anyways I will make a re-edit to get your main concerns more clearly stated in the document.

 

Regards

Sandeep

 

From: Somaraju Abhinav [mailto:abhinav.somaraju@tridonic.com]
Sent: Monday, October 05, 2015 10:12 AM
To: Kumar, Sandeep <= sandeep.kumar@philips.com>; Ace@ietf.org
Subject: RE: [ACE] review draft-ietf-ace-usecases-06

 

Hi Sandeep,=

Thanks for the reply. = Maybe there is a confusion of terminology here. The situation that you desc= ribed in the installation/commissioning section is what I would usually cal= l recommissioning. Please see remaining comments inline.

 

 = 

Sec. 2.=
4.1.1. “A vacant area of the building has been recently leased to com=
pany A.
 &=
nbsp; Before moving into its new office, Company A wishes to replace the
 &=
nbsp; lighting with a more energy efficient and a better light quality=

 &=
nbsp; luminaries.  They hire an installation and commissioning company=
 C to
 &=
nbsp; redo the illumination.”
&n=
bsp;
From my=
 knowledge of Building automation and professional lighting this scenario i=
s highly unlikely. Usually a leasing company hires a space and the lights c=
ome as package with the space and are built into the leasing company’=
s contract. If the leasing company wishes to change the luminaires they typ=
ically have to speak to the (representative of) the building owner but this=
 is quite rare. There are some specific regions in the world e.g. central E=
U where this is not always the case. Sometimes in central EU, the buildings=
 do not have any built in luminaires and the leasing companies bring in the=
ir own freestanding luminaires. It is very rarely the case that a leasing t=
enant hires a contractor to change the lighting system. The situations is m=
ore complicated for HVAC systems which often need to satisfy regulatory req=
uirements. HVAC systems are often done building wide and are very rarely te=
nant specific. 
=
 
[&=
gt; ] You are right about the current status in certain central European co=
untries regarding how office space leasing is done. I have taken a more gen=
eral approach to include issues from other domains like retail where indoor=
 lighting is tied closely to the branding independent of where they lease t=
heir space. Instead of creating multiple use cases or geographic specific c=
ases, I took a practical approach to extend the office scenario that can ex=
plain what type of issues may be relevant in professional lighting in diffe=
rent related domains. This way technology developed in ACE is the not the b=
locking factor for end-users to demand a different choice than they have to=
day. Does the extension bother you regarding how it would guide the solutio=
n direction making it inapplicable in your more restricted setting? 
[AS] My =
main issue is that commissioning a part of the building by the leasing comp=
any using independent contractors is very much a corner case when it comes =
to Building automation (and almost never applicable to anything other than =
(retail) lighting because of regulatory requirements). Maybe my previous em=
ail was not clear about this point - Central EU is sometimes an exception t=
o this rule and is one of the corner cases where the leasing company brings=
 their “own lighting using free-standing luminaires”. My concer=
n with the text is that the main issues with regards to initial installatio=
n/commissioning in buildings have not been mentioned (which is the followin=
g point). 
&nb=
sp;
A very =
important aspect of the installation/commissioning workflow has been overlo=
oked. Typically, installation in the building occur in the following order =
(in a new building). 1) Installation of the lighting devices by an untraine=
d electrician, 2) A lighting commissioning engineer who configures lights 3=
) Installation of HVAC systems 4) First presence of trained IT professional=
s. 
=
 
So, the=
 initial commissioning/installation process needs to be performed by people=
 with no IT knowledge and with the IT backbone not being present. Also, the=
 commissioning goes in phases with different floors being commissioned at d=
ifferent times and then later connected together with the IT backbone. Not =
having the IT backbone during commissioning puts big constraints because it=
 is difficult to use public key certs during this process. 
=
 
[&=
gt; ] Indeed true regarding no IT connectivity to devices and forming indiv=
idual islands before joining them for a new installation. I think I had it =
in the previous version but it changed after it combined with the HVAC use =
case.  The current description is more shifted towards an already up a=
nd running system which changes ownership. I can include in those things. D=
o you see other authorization problems that needs to be added based on the =
change?
I =
do not know if it directly means “no public key certs” since th=
e commissioning tool can potentially be connected to a backend. =

[AS] I c=
an only judge new authorization problems after looking at the text. Some of=
 the key issues during the initial commissioning phase are: 1) Phased commi=
ssioning/installation: different parts of the building are installed by (so=
metimes) different installers/commissioners usually by people with no IT ba=
ckground. But at a later stage when the parts are connected, they have to w=
ork as a single system. 2) Lack of IT backbone as already mentioned (though=
 the commissioner can use public key certs the devices probably can’t=
 authenticate commissioner – maybe not important?), 3) Requiring some=
 out of the box functionality before the commissioner is on site to allow s=
ome installation testing, 4) The devices being physically inaccessible when=
 the commissioner is on site but only being accessible during installation =
(e.g. HVAC valves or ceiling mounted luminaires – this rules out opti=
ons such as NFC sometimes) 5) Usually there is a long B-2-B chain before th=
e devices reach the customer (unlike maybe home automation) 6) The initial =
installers/commissioners will need to install devices from multiple differe=
nt suppliers (rules out a single company selling “gateway+device&=
#8221; combinations with specific commissioning methods). 
&nb=
sp;
I think =
it is important that the use-case document captures these initial installat=
ion/commissioning issues rather than focus on the corner case of one tenant=
 independently re-commissioning a part of the building. <=
/pre>

&nb=
sp;


My use c=
ase of installation/commissioning will go along the following lines: 1) Bui=
lding owner hires contractor, 2) Contractor hires: architect (to design), e=
lectrician (to install) and commissioner (there are several permutations of=
 the above possible with additional actors), 3) Electrician (usually not hi=
ghly qualified) installs the devices and needs to prove wiring was done pro=
perly (so needs some out of the box probably unsecured communication), 4) C=
ommissioner comes on site and connects devices to talk to each other (This =
phase could happen in parallel on multiple floors and sometimes even in par=
allel with installation). Sometimes there are 10-100 thousand devices in th=
e building. Also, several devices are not physically accessible to the comm=
issioner. This makes it for instance very difficult to map the physical loc=
al of sensors (e.g. motion sensors), 5) IT engineer comes on site and conne=
cts up the IT backbone and the devices are exposed to the wider internet fo=
r the first time. 6) The devices continue to work with not requiring the co=
mmissioner to come back on site.


&nb=
sp;


Another=
 point is that Authorization rules may also be role based. E.g. A commissio=
ner/facility manager might be able to configure devices but a user may only=
 be able to dim up/down the lights. 


=
 


[&=
gt; ] That sounds more like the choice of solution rather than an authoriza=
tion problem.


[AS] I w=
ould not say this is a choice of solution. In general the users of the indo=
or BA can be grouped into categories – maintenance personnel, (night-=
time) cleaners, commissioners, BMS, LMS systems, end users (that may occupy=
 certain floors). The authorization problem is that these categories of use=
rs need different access rights. The solution could be a role based authori=
zation policy or based on individual authorization policies using unique id=
entification of the user. However, the fact that such categories of users e=
xist is really the underlying authorization problem. 

2.4.1.3=
 Maintenance


The rol=
es of a facility manager and commissioner (at least in building speak) are =
confused here. Depending on the type of building, there is a facility manag=
er who takes care of issues during the device operation. If changes are req=
uired the facility manager is usually able to make the changes. The facilit=
y manager is sometimes the same individual as the commissioner but not alwa=
ys. We need to put procedures in place so that the commissioner who commiss=
ions at the start can “hand-over” the system to the facility ma=
nager.


=
 


[&=
gt; ] The current text does imply a handover to the facility manager (the s=
ervice company) since the commissioner needs new authorization to make chan=
ges during the maintenance stage. Do you have any specific authorization pr=
oblems in mind by the “hand over” which is not already covered =
in U4.2 (if you could change the name of the actors).=



[AS] No.=



&nb=
sp;


The mos=
t common maintenance issue that occur is that of replacing broken devices. =
Therefore, the “authorizations” need to be transferred to the r=
eplacement device.


=
 


[&=
gt; ] This is a good one but needs to be detailed in terms of how much inte=
raction is needed from the one doing the transfer. It should be less than n=
ormal commissioning U4.1 but cannot be zero-configuration either. Any text =
is welcome.


&nb=
sp;


[AS] The=
re are two parts to this – first part is configuring the new device a=
nd of course it cannot be zero configuration. The second part is that prope=
r disposal of the broken device – hopefully when you through the devi=
ce in the bin and somebody else gets access to it, you do not create any ne=
w problems. 


&n=
bsp;


A phase=
 that occurs several times and not covered in this use case is recommiss=
ioning. This may occur in several situations: 1) when one tenant moves =
out and a new one moves in, 2) Changes in the office space, 3) removing a d=
evice from one system and adding it to another


=
 


[&=
gt; ] I tried to leave this phase out since I did not see any new authoriza=
tion problems (the whole use case is kind of depicted as a recommissioning)=
. The point of the document is not to explain lighting but to guide the sol=
ution development. If you think any new authorization problems need to be a=
dded, we can include this phase. Please let me know. =



[AS] You=
 cover this use-case to a large extent in the installation/commissioning se=
ction. However, maybe I missed the point about if a device is removed from =
one system and recommissioned to a new one then you should not be able to b=
reak the old system with the device that has been recommissioned. Differenc=
e from decommissioning use-case is that the device stills needs to work pro=
perly in the new system. 


&nb=
sp;


Re=
gards


Sa=
ndeep


&n=
bsp;


____________________________________=
____________________ The contents of this e-mail and any attachments are co=
nfidential to the intended recipient. They may not be disclosed
 to or used by or copied in any way by anyone other than the intended recip=
ient. If this e-mail is received in error, please immediately notify the se=
nder 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 sca=
n or otherwise check this e-mail and any attachments.

 

The information contained in th= is message may be confidential and legally protected under applicable law. = The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, = forwarding, dissemination, or reproduction of this message is strictly proh= ibited and may be unlawful. If you are not the intended recipient, please c= ontact the sender by return e-mail and destroy all copies of the original message.

____________________________________= ____________________ The contents of this e-mail and any attachments are co= nfidential to the intended recipient. They may not be disclosed to or used by or copied in any way by anyone other than the intended recip= ient. If this e-mail is received in error, please immediately notify the se= nder 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 sca= n or otherwise check this e-mail and any attachments.

________________________________________________________ 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 immediately notify the sender and= delete the e-mail and attached documents. Please note that neither the sen= der nor the sender's company accept any responsibility for viruses and it i= s your responsibility to scan or otherwise check this e-mail and any attachments. --_000_0E9A48AB39AF3547ACD28A6DE3E2906A0AC307ATBRAGMSX02itison_-- From nobody Mon Oct 5 02:17:52 2015 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F6951B4EB6 for ; Mon, 5 Oct 2015 02:17:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lm4-AcLzAEkL for ; Mon, 5 Oct 2015 02:17:49 -0700 (PDT) Received: from mail-lb0-f175.google.com (mail-lb0-f175.google.com [209.85.217.175]) (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 3DA611B4EBA for ; Mon, 5 Oct 2015 02:17:49 -0700 (PDT) Received: by lbos8 with SMTP id s8so54236491lbo.0 for ; Mon, 05 Oct 2015 02:17:47 -0700 (PDT) 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:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-type; bh=BJ7Eqhcm7QJLtGwN372tOgMBqK+wQcIZ3VS8d9Q9RHs=; b=UxL8ywRcAqUQRWQ1SpYsxQo5j9psFsvWavh9eCfbZbKYdv4FPH/CXnHAeK2eg4RT8b iPR7DAy9ZrssCgf2hH3MyJ32GfG1dD8+/mEWv6hqQQs98gDCIsZqKpbdb3BJS1e9tNt9 ZTI67eosG6TwbNJJAySnst3b3SM5qyCbY8RmFXUh5mg1jf8BcerYeZ+FUhZFjBJXTcQt 9TH930t5z8l6mH65E7OWm30p30uWvOxix1LCVoZNwhh1P96qDivDPqp4i/iW9zRMUIVD ckFGD9NDTrdt0ugWvrGlNSWpFhktivq+mPUvJa60Y1u0r6iAUjSY6ZzX0hCzkXlAQEor 9Haw== X-Gm-Message-State: ALoCoQm2KuHr1w12hB3pVQcRDmZ3rg/jg+6c8MmSdwjiDAka1jETxeN6AD7N3U5ZXHJr2s06kUPB X-Received: by 10.112.147.39 with SMTP id th7mr10695276lbb.82.1444036667300; Mon, 05 Oct 2015 02:17:47 -0700 (PDT) Received: from [192.168.0.108] ([85.235.11.178]) by smtp.gmail.com with ESMTPSA id oz1sm3999488lbb.26.2015.10.05.02.17.46 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 05 Oct 2015 02:17:46 -0700 (PDT) To: Olaf Bergmann References: <088001d0fbf6$e4527480$acf75d80$@augustcellars.com> <87h9m9ed3j.fsf@aung.informatik.uni-bremen.de> <008901d0fd28$cebff470$6c3fdd50$@augustcellars.com> <874mi9clma.fsf@aung.informatik.uni-bremen.de> <561222E7.5050904@sics.se> <87lhbhbw9h.fsf@aung.informatik.uni-bremen.de> From: Ludwig Seitz Message-ID: <56124039.5000802@sics.se> Date: Mon, 5 Oct 2015 11:17:45 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <87lhbhbw9h.fsf@aung.informatik.uni-bremen.de> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms070901070503030507080807" Archived-At: Cc: ace@ietf.org Subject: Re: [Ace] Security properties of CoAP message fields X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 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, 05 Oct 2015 09:17:51 -0000 This is a cryptographically signed message in MIME format. --------------ms070901070503030507080807 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable On 2015-10-05 09:38, Olaf Bergmann wrote: > Ludwig Seitz writes: > >> On 2015-10-02 17:53, Olaf Bergmann wrote: >>> "Jim Schaad" writes: >>> >>>>> One interesting side note is that when a proxy inserts (or drops?) >>>>> options for >>>>> some reason, the delta-encoded option number will change. >>>> >>>> I don't think this is a big deal as we can use the absolute option >>>> number in constructing the authentication string. >>> >>> Yes, meaning that it must be constructed before message >>> serialization. Hm.... >>> >>> Gr=C3=BC=C3=9Fe >>> Olaf >>> >> >> In draft-selander-ace-object-security we suggested that you create a >> separate list of integrity protected options (using the >> delta-encoding) as input for signing/MACing. >> >> We considered and rejected the idea of using the actual option numbers= >> instead, because you then need an additional piece of parsing code in >> your library, whereas with the delta encoding you can reuse the CoAP >> code. > > I do not see why you need an additional piece of parsing code? Well some code has to create the data object (including the option=20 numbers) that you are going to sign/MAC. Without the delta-encoding this has to be some new code (at least=20 partially). /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 http://www.sics.se --------------ms070901070503030507080807 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 DFQwggYYMIIFAKADAgECAgMMhpgwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYw FAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZp Y2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJt ZWRpYXRlIENsaWVudCBDQTAeFw0xNTAxMDgwODM5MDZaFw0xNjAxMDkyMjQxMzBaMDgxFzAV BgNVBAMMDmx1ZHdpZ0BzaWNzLnNlMR0wGwYJKoZIhvcNAQkBFg5sdWR3aWdAc2ljcy5zZTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMVB4rAuq4FxbARxwRqPLpc/3C194F+V H4XMKK6fu3Y8zDLijzNSjh6tG41oZhXvJcvAs1nZNjUutNLeyBAUFiYhy7HXNdlKpjbMEFKQ +6KpEdZ0Rk+pXgB2E1mqZEfp3M2djcQ/h+7uGVlSGYNAxYk6rWPIIWBx2GMvAQaHP4xxu/F+ PiSQILOVzmtIFZe1t/Lw71aaNeMYVhARo8z5PVsVoq6gBeujxfiRLtiQ/S8xW6RKvNvUkVyT BQfcKaEDZR9FENNf9rFgiAcT6R7hI8RBf1d2fxdlbDU8uM72K3fvzGDt8N9Bfm1kDWbDBxJE 1taRIYs+60D1kwV6DvBb9MECAwEAAaOCAtQwggLQMAkGA1UdEwQCMAAwCwYDVR0PBAQDAgSw MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAdBgNVHQ4EFgQU6ryrKahJtBOEdbIL AAWCpOsQyagwHwYDVR0jBBgwFoAUU3Ltkpzg2ssBXHx+ljVO8tS4UYIwGQYDVR0RBBIwEIEO bHVkd2lnQHNpY3Muc2UwggFMBgNVHSAEggFDMIIBPzCCATsGCysGAQQBgbU3AQIDMIIBKjAu BggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjCB9wYIKwYB BQUHAgIwgeowJxYgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwAwIBARqBvlRo aXMgY2VydGlmaWNhdGUgd2FzIGlzc3VlZCBhY2NvcmRpbmcgdG8gdGhlIENsYXNzIDEgVmFs aWRhdGlvbiByZXF1aXJlbWVudHMgb2YgdGhlIFN0YXJ0Q29tIENBIHBvbGljeSwgcmVsaWFu Y2Ugb25seSBmb3IgdGhlIGludGVuZGVkIHB1cnBvc2UgaW4gY29tcGxpYW5jZSBvZiB0aGUg cmVseWluZyBwYXJ0eSBvYmxpZ2F0aW9ucy4wNgYDVR0fBC8wLTAroCmgJ4YlaHR0cDovL2Ny bC5zdGFydHNzbC5jb20vY3J0dTEtY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEF BQcwAYYtaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczEvY2xpZW50L2NhMEIG CCsGAQUFBzAChjZodHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MxLmNs aWVudC5jYS5jcnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqG SIb3DQEBBQUAA4IBAQBl8BbG0n7+JjFqiJOuAqMbkeqM6Oyd+4oHGu3fbaSiM1SKesae2bfm vifV99a+M4DERZ2SVkOYcvNlv31Q3hvYtzRjDOqewzVKxo021R3ddQULW1DhvTEpclikG5rd 0NRJQn+EkSwEKLeUj68i0dhU8ULhZDDq3A81cTcZzIGrTjNnwDvCktB/sF/iO4At6RJ24P3j KjYFPirW3NsvZ2gzZizSzeubPE0/cWcqEBJ/UtaFPF54efejjLuPRHHMLPDcvrwBhEiBxuG6 oTEo465g4pS9Vo/Z0GoZgZyA+aGQ+YPbPSsqsYmSBjZ6MGGDqQq0niE2dW+8IOdHQvMkqI52 MIIGNDCCBBygAwIBAgIBHjANBgkqhkiG9w0BAQUFADB9MQswCQYDVQQGEwJJTDEWMBQGA1UE ChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUg U2lnbmluZzEpMCcGA1UEAxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwHhcN MDcxMDI0MjEwMTU1WhcNMTcxMDI0MjEwMTU1WjCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoT DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUg Q2xpZW50IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAxwmDzM4t2BqxKaQu E6uWvooyg4ymiEGWVUet1G8SD+rqvyNH4QrvnEIaFHxOhESip7vMz39ScLpNLbL1QpOlPW/t FIzNHS3qd2XRNYG5Sv9RcGE+T4qbLtsjjJbi6sL7Ls/f/X9ftTyhxvxWkf8KW37iKrueKsxw 2HqolH7GM6FX5UfNAwAu4ZifkpmZzU1slBhyWwaQPEPPZRsWoTb7q8hmgv6Nv3Hg9rmA1/VP BIOQ6SKRkHXG0Hhmq1dOFoAFI411+a/9nWm5rcVjGcIWZ2v/43Yksq60jExipA4l5uv9/+Hm 33mbgmCszdj/Dthf13tgAv2O83hLJ0exTqfrlwIDAQABo4IBrTCCAakwDwYDVR0TAQH/BAUw AwEB/zAOBgNVHQ8BAf8EBAMCAQYwHQYDVR0OBBYEFFNy7ZKc4NrLAVx8fpY1TvLUuFGCMB8G A1UdIwQYMBaAFE4L7xqkQFulF2mHMMo0aEPQQa7yMGYGCCsGAQUFBwEBBFowWDAnBggrBgEF BQcwAYYbaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL2NhMC0GCCsGAQUFBzAChiFodHRwOi8v d3d3LnN0YXJ0c3NsLmNvbS9zZnNjYS5jcnQwWwYDVR0fBFQwUjAnoCWgI4YhaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vc2ZzY2EuY3JsMCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNv bS9zZnNjYS5jcmwwgYAGA1UdIAR5MHcwdQYLKwYBBAGBtTcBAgEwZjAuBggrBgEFBQcCARYi aHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEFBQcCARYoaHR0cDov L3d3dy5zdGFydHNzbC5jb20vaW50ZXJtZWRpYXRlLnBkZjANBgkqhkiG9w0BAQUFAAOCAgEA CoMIfXirLAZcuGOMXq4cuSN3TaFx2H2GvD5VSy/6rV55BYHbWNaPeQn3oBSU8KgQZn/Kck1J xbLpAxVCNtsxeW1R87ifhsYZ0qjdrA9anrW2MAWCtosmAOT4OxK9QPoSjCMxM3HbkZCDJgnl E8jMopH21BbyAYr7b5EfGRQJNtgWcvqSXwKHnTutR08+Kkn0KAkXCzeQNLeA5LlYUzFyM7kP Ap8pIRMQ+seHunmyG642S2+y/qHEdMuGIwpfz3eDF1PdctL04qYK/zu+Qg1Bw0RwgigVZs/0 c5HP2/e9DBHh7eSwtzYlk4AUr6yxLlcwSjOfOmKEQ/Q8tzh0IFiNu9IPuTGAPBn4CPxD0+Ru 8T2wg8/s43R/PT3kd1OEqOJUl7q+h+r6fpvU0Fzxd2tC8Ga6fDEPme+1Nbi+03pVjuZQKbGw KJ66gEn06WqaxVZC+J8hh/jR0k9mST1iAZPNYulcNJ8tKmVtjYsv0L1TSm2+NwON58tO+pIV zu3DWwSEXSf+qkDavQam+QtEOZxLBXI++aMUEapSn+k3Lxm48ZCYfAWLb/Xj7F5JQMbZvCex glAbYR0kIHqW5DnsYSdMD/IplJMojx0NBrxJ3fN9dvX2Y6BIXRsF1du4qESm4/3CKuyUV7p9 DW3mPlHTGLvYxnyKQy7VFBkoLINszBrOUeIxggPtMIID6QIBATCBlDCBjDELMAkGA1UEBhMC SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENl cnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJ bnRlcm1lZGlhdGUgQ2xpZW50IENBAgMMhpgwDQYJYIZIAWUDBAIBBQCgggIpMBgGCSqGSIb3 DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE1MTAwNTA5MTc0NVowLwYJKoZI hvcNAQkEMSIEIFExH/0+VBWimiNQwjuVUQMIkNEfPR6PnD1RLOzrcpUtMGwGCSqGSIb3DQEJ DzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0D AgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgaUGCSsGAQQB gjcQBDGBlzCBlDCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzAp BgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0 YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgMMhpgwgacG CyqGSIb3DQEJEAILMYGXoIGUMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20g THRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG A1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EC AwyGmDANBgkqhkiG9w0BAQEFAASCAQBXG+W9m4VmabN/o39akZ6DPDSmCd0L8JZQoSfo+cH/ yXyUZhjsMpoIxSKrg+fcux9DVY7bj5xwVpuudpRWe8MnL/2I15xihr1giKQcvVVbrvZ3Z9+Q JppshEdx6sYkQjxcdWl2PrQXlRy6KyDDGlhBRYv1RIUCUsUeLoVW/Jm/nP5eHBe1shBfRxdJ gLv4KWFxPYZqh3SrS38oBiDCYHCUmmkVKdipQq2vXH1hxo9HftbQOcMYp36tHZ8quWRZ8Ctf CNObCyOGIectzS8VhCVMu0QJRFylu/SNo9dobGB57TNjkx4GeUqXSetRWb6bj/FhnjRxQdFY 8u3fQbw2DT5VAAAAAAAA --------------ms070901070503030507080807-- From nobody Mon Oct 5 02:35:39 2015 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75EBA1B4ECF for ; Mon, 5 Oct 2015 02:35:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.55 X-Spam-Level: X-Spam-Status: No, score=-1.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pT9whgcwqRk0 for ; Mon, 5 Oct 2015 02:35:36 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6AA9E1B4ECE for ; Mon, 5 Oct 2015 02:35:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::b]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id t959ZWPM010526; Mon, 5 Oct 2015 11:35:32 +0200 (CEST) Received: from aung.tzi.org (eduroam-pool4-373.wlan.uni-bremen.de [134.102.147.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3nTxcN2N1zz4q5c; Mon, 5 Oct 2015 11:35:32 +0200 (CEST) From: Olaf Bergmann To: Ludwig Seitz References: <088001d0fbf6$e4527480$acf75d80$@augustcellars.com> <87h9m9ed3j.fsf@aung.informatik.uni-bremen.de> <008901d0fd28$cebff470$6c3fdd50$@augustcellars.com> <874mi9clma.fsf@aung.informatik.uni-bremen.de> <561222E7.5050904@sics.se> <87lhbhbw9h.fsf@aung.informatik.uni-bremen.de> <56124039.5000802@sics.se> Date: Mon, 05 Oct 2015 11:35:29 +0200 In-Reply-To: <56124039.5000802@sics.se> (Ludwig Seitz's message of "Mon, 5 Oct 2015 11:17:45 +0200") Message-ID: <87twq57j4u.fsf@aung.informatik.uni-bremen.de> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.4 (gnu/linux) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Archived-At: Cc: ace@ietf.org Subject: Re: [Ace] Security properties of CoAP message fields X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 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, 05 Oct 2015 09:35:37 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Ludwig Seitz writes: > Well some code has to create the data object (including the option > numbers) that you are going to sign/MAC. > > Without the delta-encoding this has to be some new code (at least > partially). Call me dumb, but I do not see a big difference between the two cases. With the delta-encoding you may have to prepare input data for your MAC function, with real option numbers you must prepare input data for your MAC function. (If you use real option numbers the spec will have to say something about the canonicalization which comes for free when you use the already encoded options, though.) Gr=C3=BC=C3=9Fe Olaf --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAlYSRGEACgkQH0ed6TCN5IOvKQCgkvz+YyLlDkPiUTB5BW0U6fvI pyIAn0MPhI8JwXZ+ej9zBb7EE0uTHnLc =Q8va -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Oct 5 03:33:19 2015 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BA581A8A85 for ; Mon, 5 Oct 2015 03:33:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aU_-FGW2UCLE for ; Mon, 5 Oct 2015 03:33:16 -0700 (PDT) Received: from mail-la0-f50.google.com (mail-la0-f50.google.com [209.85.215.50]) (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 C68B11A8825 for ; Mon, 5 Oct 2015 03:33:14 -0700 (PDT) Received: by lafb9 with SMTP id b9so33965104laf.0 for ; Mon, 05 Oct 2015 03:33:13 -0700 (PDT) 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:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-type; bh=/mza4JqCE1jnbjRu6LdI9dAYgzv/JYKMkJz2nuZ5VPc=; b=DndCRHFxlC+aOIbQe+2WxHf7bvQDPqALvKerVRG9qJjzJPMwUmKRoqgKLcmallwm4J G5YvDQ/rjPxgpBadhHhkyhGT4R6XzA1HNNq2JqKyfcQQJWVzCqzOPkTFVe6nLT9vaH49 UZj/w827FSM7vx8UssW84Xb6WCHMiy2+XkZRzU8zd07mzztUvq26hqAc4xjLASlvubRq nFUbIL51Dw7uMTXa0JRpeBRJDvrWzKUtqc1XdhQzuSYbfHINiklkxfJCkAXoMtHZ2g3x xva+KGf8DLTcFNREJDt9vHNhoTSitBAg6qyBry57YTC1iPEpDHImWg9QkZnr4RuyPEDc ScSQ== X-Gm-Message-State: ALoCoQm84u3P5ZHpk9nGpkW4e6kqhcjSLhDHSj/TXt7Vi36xul21GG1KVNQ4OR8Wq05AGPJ1Lg7U X-Received: by 10.112.132.74 with SMTP id os10mr11253432lbb.40.1444041192988; Mon, 05 Oct 2015 03:33:12 -0700 (PDT) Received: from [192.168.0.108] ([85.235.11.178]) by smtp.gmail.com with ESMTPSA id d82sm4146620lfg.22.2015.10.05.03.33.11 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 05 Oct 2015 03:33:12 -0700 (PDT) To: Olaf Bergmann References: <088001d0fbf6$e4527480$acf75d80$@augustcellars.com> <87h9m9ed3j.fsf@aung.informatik.uni-bremen.de> <008901d0fd28$cebff470$6c3fdd50$@augustcellars.com> <874mi9clma.fsf@aung.informatik.uni-bremen.de> <561222E7.5050904@sics.se> <87lhbhbw9h.fsf@aung.informatik.uni-bremen.de> <56124039.5000802@sics.se> <87twq57j4u.fsf@aung.informatik.uni-bremen.de> From: Ludwig Seitz Message-ID: <561251E7.6020704@sics.se> Date: Mon, 5 Oct 2015 12:33:11 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <87twq57j4u.fsf@aung.informatik.uni-bremen.de> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms070704030508060208000708" Archived-At: Cc: ace@ietf.org Subject: Re: [Ace] Security properties of CoAP message fields X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 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, 05 Oct 2015 10:33:19 -0000 This is a cryptographically signed message in MIME format. --------------ms070704030508060208000708 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable On 2015-10-05 11:35, Olaf Bergmann wrote: > Ludwig Seitz writes: > >> Well some code has to create the data object (including the option >> numbers) that you are going to sign/MAC. >> >> Without the delta-encoding this has to be some new code (at least >> partially). > > Call me dumb, but I do not see a big difference between the two > cases. With the delta-encoding you may have to prepare input data for > your MAC function, with real option numbers you must prepare input data= > for your MAC function. (If you use real option numbers the spec will > have to say something about the canonicalization which comes for free > when you use the already encoded options, though.) > > Gr=C3=BC=C3=9Fe > Olaf > You are right, the difference is indeed small, but when you use the=20 delta-encoding you can reuse CoAP code without any modification, whereas = when you want to use the real numbers you have to rewrite some parts of=20 that. Anyways my point was just to express a slight preference for generating=20 the input for the MAC/signature functions as a delta encoded list of=20 options. /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 http://www.sics.se --------------ms070704030508060208000708 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 DFQwggYYMIIFAKADAgECAgMMhpgwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYw FAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZp Y2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJt ZWRpYXRlIENsaWVudCBDQTAeFw0xNTAxMDgwODM5MDZaFw0xNjAxMDkyMjQxMzBaMDgxFzAV BgNVBAMMDmx1ZHdpZ0BzaWNzLnNlMR0wGwYJKoZIhvcNAQkBFg5sdWR3aWdAc2ljcy5zZTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMVB4rAuq4FxbARxwRqPLpc/3C194F+V H4XMKK6fu3Y8zDLijzNSjh6tG41oZhXvJcvAs1nZNjUutNLeyBAUFiYhy7HXNdlKpjbMEFKQ +6KpEdZ0Rk+pXgB2E1mqZEfp3M2djcQ/h+7uGVlSGYNAxYk6rWPIIWBx2GMvAQaHP4xxu/F+ PiSQILOVzmtIFZe1t/Lw71aaNeMYVhARo8z5PVsVoq6gBeujxfiRLtiQ/S8xW6RKvNvUkVyT BQfcKaEDZR9FENNf9rFgiAcT6R7hI8RBf1d2fxdlbDU8uM72K3fvzGDt8N9Bfm1kDWbDBxJE 1taRIYs+60D1kwV6DvBb9MECAwEAAaOCAtQwggLQMAkGA1UdEwQCMAAwCwYDVR0PBAQDAgSw MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAdBgNVHQ4EFgQU6ryrKahJtBOEdbIL AAWCpOsQyagwHwYDVR0jBBgwFoAUU3Ltkpzg2ssBXHx+ljVO8tS4UYIwGQYDVR0RBBIwEIEO bHVkd2lnQHNpY3Muc2UwggFMBgNVHSAEggFDMIIBPzCCATsGCysGAQQBgbU3AQIDMIIBKjAu BggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjCB9wYIKwYB BQUHAgIwgeowJxYgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwAwIBARqBvlRo aXMgY2VydGlmaWNhdGUgd2FzIGlzc3VlZCBhY2NvcmRpbmcgdG8gdGhlIENsYXNzIDEgVmFs aWRhdGlvbiByZXF1aXJlbWVudHMgb2YgdGhlIFN0YXJ0Q29tIENBIHBvbGljeSwgcmVsaWFu Y2Ugb25seSBmb3IgdGhlIGludGVuZGVkIHB1cnBvc2UgaW4gY29tcGxpYW5jZSBvZiB0aGUg cmVseWluZyBwYXJ0eSBvYmxpZ2F0aW9ucy4wNgYDVR0fBC8wLTAroCmgJ4YlaHR0cDovL2Ny bC5zdGFydHNzbC5jb20vY3J0dTEtY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEF BQcwAYYtaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczEvY2xpZW50L2NhMEIG CCsGAQUFBzAChjZodHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MxLmNs aWVudC5jYS5jcnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqG SIb3DQEBBQUAA4IBAQBl8BbG0n7+JjFqiJOuAqMbkeqM6Oyd+4oHGu3fbaSiM1SKesae2bfm vifV99a+M4DERZ2SVkOYcvNlv31Q3hvYtzRjDOqewzVKxo021R3ddQULW1DhvTEpclikG5rd 0NRJQn+EkSwEKLeUj68i0dhU8ULhZDDq3A81cTcZzIGrTjNnwDvCktB/sF/iO4At6RJ24P3j KjYFPirW3NsvZ2gzZizSzeubPE0/cWcqEBJ/UtaFPF54efejjLuPRHHMLPDcvrwBhEiBxuG6 oTEo465g4pS9Vo/Z0GoZgZyA+aGQ+YPbPSsqsYmSBjZ6MGGDqQq0niE2dW+8IOdHQvMkqI52 MIIGNDCCBBygAwIBAgIBHjANBgkqhkiG9w0BAQUFADB9MQswCQYDVQQGEwJJTDEWMBQGA1UE ChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUg U2lnbmluZzEpMCcGA1UEAxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwHhcN MDcxMDI0MjEwMTU1WhcNMTcxMDI0MjEwMTU1WjCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoT DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUg Q2xpZW50IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAxwmDzM4t2BqxKaQu E6uWvooyg4ymiEGWVUet1G8SD+rqvyNH4QrvnEIaFHxOhESip7vMz39ScLpNLbL1QpOlPW/t FIzNHS3qd2XRNYG5Sv9RcGE+T4qbLtsjjJbi6sL7Ls/f/X9ftTyhxvxWkf8KW37iKrueKsxw 2HqolH7GM6FX5UfNAwAu4ZifkpmZzU1slBhyWwaQPEPPZRsWoTb7q8hmgv6Nv3Hg9rmA1/VP BIOQ6SKRkHXG0Hhmq1dOFoAFI411+a/9nWm5rcVjGcIWZ2v/43Yksq60jExipA4l5uv9/+Hm 33mbgmCszdj/Dthf13tgAv2O83hLJ0exTqfrlwIDAQABo4IBrTCCAakwDwYDVR0TAQH/BAUw AwEB/zAOBgNVHQ8BAf8EBAMCAQYwHQYDVR0OBBYEFFNy7ZKc4NrLAVx8fpY1TvLUuFGCMB8G A1UdIwQYMBaAFE4L7xqkQFulF2mHMMo0aEPQQa7yMGYGCCsGAQUFBwEBBFowWDAnBggrBgEF BQcwAYYbaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL2NhMC0GCCsGAQUFBzAChiFodHRwOi8v d3d3LnN0YXJ0c3NsLmNvbS9zZnNjYS5jcnQwWwYDVR0fBFQwUjAnoCWgI4YhaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vc2ZzY2EuY3JsMCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNv bS9zZnNjYS5jcmwwgYAGA1UdIAR5MHcwdQYLKwYBBAGBtTcBAgEwZjAuBggrBgEFBQcCARYi aHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEFBQcCARYoaHR0cDov L3d3dy5zdGFydHNzbC5jb20vaW50ZXJtZWRpYXRlLnBkZjANBgkqhkiG9w0BAQUFAAOCAgEA CoMIfXirLAZcuGOMXq4cuSN3TaFx2H2GvD5VSy/6rV55BYHbWNaPeQn3oBSU8KgQZn/Kck1J xbLpAxVCNtsxeW1R87ifhsYZ0qjdrA9anrW2MAWCtosmAOT4OxK9QPoSjCMxM3HbkZCDJgnl E8jMopH21BbyAYr7b5EfGRQJNtgWcvqSXwKHnTutR08+Kkn0KAkXCzeQNLeA5LlYUzFyM7kP Ap8pIRMQ+seHunmyG642S2+y/qHEdMuGIwpfz3eDF1PdctL04qYK/zu+Qg1Bw0RwgigVZs/0 c5HP2/e9DBHh7eSwtzYlk4AUr6yxLlcwSjOfOmKEQ/Q8tzh0IFiNu9IPuTGAPBn4CPxD0+Ru 8T2wg8/s43R/PT3kd1OEqOJUl7q+h+r6fpvU0Fzxd2tC8Ga6fDEPme+1Nbi+03pVjuZQKbGw KJ66gEn06WqaxVZC+J8hh/jR0k9mST1iAZPNYulcNJ8tKmVtjYsv0L1TSm2+NwON58tO+pIV zu3DWwSEXSf+qkDavQam+QtEOZxLBXI++aMUEapSn+k3Lxm48ZCYfAWLb/Xj7F5JQMbZvCex glAbYR0kIHqW5DnsYSdMD/IplJMojx0NBrxJ3fN9dvX2Y6BIXRsF1du4qESm4/3CKuyUV7p9 DW3mPlHTGLvYxnyKQy7VFBkoLINszBrOUeIxggPtMIID6QIBATCBlDCBjDELMAkGA1UEBhMC SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENl cnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJ bnRlcm1lZGlhdGUgQ2xpZW50IENBAgMMhpgwDQYJYIZIAWUDBAIBBQCgggIpMBgGCSqGSIb3 DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE1MTAwNTEwMzMxMVowLwYJKoZI hvcNAQkEMSIEIBurKgi6X6bopECl4u7zhdRkjzpTU/BJ9t3b8EDNJnOlMGwGCSqGSIb3DQEJ DzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0D AgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgaUGCSsGAQQB gjcQBDGBlzCBlDCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzAp BgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0 YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgMMhpgwgacG CyqGSIb3DQEJEAILMYGXoIGUMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20g THRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG A1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EC AwyGmDANBgkqhkiG9w0BAQEFAASCAQC7njcJsJ5U7g79C6TR6wzDG7mlS+Vc9RX4EQvW1yKU hUhl79u4wFnp7IjHBi4aqLf31mTjg9xDKrXfh/ZMzfIskQIWfbTK6jhXn4/G80nPvzMMLYUb wRfy/3YhVUt4IFG1YeJLXzYSPf+JKcpYziVa9zAXV2nZ/FODhLAcEWB22euyAMjh9WPxcDQ9 vDwj5OyZWZR9BnFpLSSyDWrHwYU+1iPO/YnTDv6A29u/59DCCbXFXQL9nr92MzzRxswxbdRg IM7f0v7jMYemLjw1jyRFA/c14QhsMv9Uuz4eGuaLNh5TgRX+LJTghXJRjiNSzBJXQy6H2c9h g1use0+JXGQDAAAAAAAA --------------ms070704030508060208000708-- From nobody Mon Oct 5 04:00:23 2015 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C72C61A9145 for ; Mon, 5 Oct 2015 04:00:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.55 X-Spam-Level: X-Spam-Status: No, score=-1.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3KV9i5M8FNAe for ; Mon, 5 Oct 2015 04:00:21 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3784A1A9143 for ; Mon, 5 Oct 2015 04:00:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [134.102.201.11]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id t95B0Imb000262; Mon, 5 Oct 2015 13:00:18 +0200 (CEST) Received: from aung.tzi.org (unknown [IPv6:2001:638:708:30da:211:22ff:fedd:aa18]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3nTzVB0WrPz4pY0; Mon, 5 Oct 2015 13:00:18 +0200 (CEST) From: Olaf Bergmann To: Ludwig Seitz References: <088001d0fbf6$e4527480$acf75d80$@augustcellars.com> <87h9m9ed3j.fsf@aung.informatik.uni-bremen.de> <008901d0fd28$cebff470$6c3fdd50$@augustcellars.com> <874mi9clma.fsf@aung.informatik.uni-bremen.de> <561222E7.5050904@sics.se> <87lhbhbw9h.fsf@aung.informatik.uni-bremen.de> <56124039.5000802@sics.se> <87twq57j4u.fsf@aung.informatik.uni-bremen.de> <561251E7.6020704@sics.se> Date: Mon, 05 Oct 2015 13:00:17 +0200 In-Reply-To: <561251E7.6020704@sics.se> (Ludwig Seitz's message of "Mon, 5 Oct 2015 12:33:11 +0200") Message-ID: <874mi57f7i.fsf@aung.informatik.uni-bremen.de> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: ace@ietf.org Subject: Re: [Ace] Security properties of CoAP message fields X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 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, 05 Oct 2015 11:00:22 -0000 Ludwig Seitz writes: > On 2015-10-05 11:35, Olaf Bergmann wrote: > You are right, the difference is indeed small, but when you use the > delta-encoding you can reuse CoAP code without any modification, > whereas when you want to use the real numbers you have to rewrite some > parts of that. > > Anyways my point was just to express a slight preference for > generating the input for the MAC/signature functions as a delta > encoded list of options. Okay, thanks for the clarification. As you may have inferred from my posts, I have no strong opinion on either of them. I can imagine that using delta-encoded can have some benefit in certain scenarios. Gr=C3=BC=C3=9Fe Olaf From nobody Tue Oct 6 14:12:58 2015 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1074A1A6FED for ; Tue, 6 Oct 2015 14:12:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.611 X-Spam-Level: X-Spam-Status: No, score=-2.611 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lDFhI69gQ1Cm for ; Tue, 6 Oct 2015 14:12:57 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D138A1A8738 for ; Tue, 6 Oct 2015 14:12:56 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 262A52009E; Tue, 6 Oct 2015 17:14:50 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id B2AAB637F8; Tue, 6 Oct 2015 17:12:54 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 9603063745; Tue, 6 Oct 2015 17:12:54 -0400 (EDT) From: Michael Richardson To: Hannes Tschofenig In-Reply-To: <560CE84F.1070900@gmx.net> References: <560CE84F.1070900@gmx.net> X-Mailer: MH-E 8.6; nmh 1.3-dev; GNU Emacs 24.4.2 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca Archived-At: Cc: "Ace@ietf.org" Subject: Re: [Ace] Constrained Devices and Off-Loading X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 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 Oct 2015 21:12:58 -0000 --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable We manage constrained devices centrally because the devices are incapable of making the decision locally. We manage non-constrained devices (like desktop PCs) centrally because the end-users are either untrusted, or incapable of making the decision locally. > If I look at the identity management industry then I see them also > introducing capabilities for authorizing IoT devices (and not just users > and service access, an effort that has been going on the last 15+ years). > In that spirit I believe it is worthwhile to phrase the story in a bit > broader style so that these companies recognize themselves and their work > again in this environment, particularly since many of the deployed IoT > devices are not as constrained some some would think. I strongly agree with making the situation a bit broader, so go ahead... =2D-=20 Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEVAwUBVhQ5VoCLcPvd0N1lAQK5YAf+L5osouvRifMwx1UXckk4HL3C7qNAVoWW hLLfEJsZaASS0Zj0wVMWiebs0wBHFwdhwE8q/4xgHeskXM8tMrDJU59XWEJIRdw2 hSgAFvcYZoYAsTEQg51wrp+HcRNrOE+7TCsEszfpErt8a7Nxu9vs43q+77nRlnya iSQl25Fy/AEeVSNSZ3uZo23alSP0gIKlguPI8iUkTjjv4Q6MFKbR+53ZZzJLNppk fEV1fJ0mbCVUKsQQVPpbK7rqXx8y8VqpRr6sERZ6QCbpiFo26pjjGZwn5+5u7EUS y3vAbXqXgzcL22UsUGxZNFKJQTZ9v2uJwU1UaPOwOobiDTQDYNH1jQ== =1e77 -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Oct 7 00:07:50 2015 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 702E61B2B55 for ; Wed, 7 Oct 2015 00:07:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.901 X-Spam-Level: X-Spam-Status: No, score=-3.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YP-CzDWMUwK5 for ; Wed, 7 Oct 2015 00:07:48 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 842351B2B4F for ; Wed, 7 Oct 2015 00:07:47 -0700 (PDT) X-AuditID: c1b4fb25-f79a26d00000149a-4d-5614c4c1c201 Received: from ESESSHC010.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 00.BA.05274.1C4C4165; Wed, 7 Oct 2015 09:07:45 +0200 (CEST) Received: from ESESSMB303.ericsson.se ([169.254.3.99]) by ESESSHC010.ericsson.se ([153.88.183.48]) with mapi id 14.03.0248.002; Wed, 7 Oct 2015 09:07:45 +0200 From: =?utf-8?B?R8O2cmFuIFNlbGFuZGVy?= To: Hannes Tschofenig , "Ace@ietf.org" Thread-Topic: [Ace] Constrained Devices and Off-Loading Thread-Index: AQHQ/B+DMQW3YFSHEEeFeMv9WYsYKp5fpXmA Date: Wed, 7 Oct 2015 07:07:44 +0000 Message-ID: References: <560CE84F.1070900@gmx.net> In-Reply-To: <560CE84F.1070900@gmx.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.7.141117 x-originating-ip: [153.88.183.154] Content-Type: text/plain; charset="utf-8" Content-ID: <4AA282993071D143869DEDC981DB720E@ericsson.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpmkeLIzCtJLcpLzFFi42KZGfG3RvfgEZEwg8971C2+f+thtli68x6r A5PH4k372TyWLPnJFMAUxWWTkpqTWZZapG+XwJXxfv99xoJF6hV3Pr9nb2BcoNbFyMkhIWAi cX1+KwuELSZx4d56ti5GLg4hgaOMEl9m/GWBcBYxSiy8/oUNpIpNwEXiQcMjJhBbRCBI4sDd BYwgtrCAmcTHXwtYIeLmEpvfvIayjSTuT7wPVs8ioCJx9ddFMJtXwELi1MSzYJuFBNQknr1c BRTn4OAUUJe40xwIEmYEOuj7qTVg5cwC4hK3nsxngjhUQGLJnvPMELaoxMvH/8BWiQroSay8 3sQGEVeSWHT7M9hIZgFNifW79CHGWEuc+tkMNVJRYkr3Q3aIawQlTs58wjKBUXwWkm2zELpn IemehaR7FpLuBYysqxhFi1OLk3LTjYz1Uosyk4uL8/P08lJLNjECY+3glt+qOxgvv3E8xCjA wajEw5vgIhImxJpYVlyZe4hRmoNFSZy3melBqJBAemJJanZqakFqUXxRaU5q8SFGJg5OqQZG GfmHqUKdCnG55vYSfm38ImtNYhKDJEv8TDZqeD/wrHC4Oa9f+WtlxvOPL1mNLC6VLGYylOh1 D+WdIX0y8bfI91pP/SO3LvOzzrWMr2jf29ixMTB08bycg70b4hM2nm88nCFfd26r3dzcowcW t2+1/Ty7IKm7XNvg4InO8nqpwzmGKTueNiixFGckGmoxFxUnAgCY5AQ9lgIAAA== Archived-At: Subject: Re: [Ace] Constrained Devices and Off-Loading X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Oct 2015 07:07:49 -0000 SGkgSGFubmVzDQoNCk9uIDIwMTUtMTAtMDEgMTA6MDEsICJIYW5uZXMgVHNjaG9mZW5pZyIgPGhh bm5lcy50c2Nob2ZlbmlnQGdteC5uZXQ+IHdyb3RlOg0KDQo+SGkgYWxsLA0KPg0KPkkgd2FudGVk IHRvIHJhaXNlIGEgcG9pbnQgdGhhdCBoYXMgYm90aGVyZWQgbWUgaW4gdGhlIGRpc2N1c3Npb25z IG9uDQo+Y29uc3RyYWluZWQgZGV2aWNlcyBhbHJlYWR5IGZvciBzb21lIHRpbWUuIEFzIHRoZSB0 ZXh0IGZyb20gdGhlDQo+YXJjaGl0ZWN0dXJlIGRvY3VtZW50IHNob3dzIHRoZSB3YXkgaG93IHRo ZSBzdG9yeSBpcyBwYWludGVkIGlzIHRoYXQNCj5jb25zdHJhaW5lZCBkZXZpY2VzIGNhbm5vdCAo ZHVlIHRvIHRoZWlyIGxpbWl0YXRpb25zKSBwZXJmb3JtIGNlcnRhaW4NCj5mdW5jdGlvbnMgb24g dGhlaXIgb3duIGFuZCBoZW5jZSB0aGV5IG5lZWQgc29tZSB0aGlyZCBwYXJ0eS4NCj4NCj5IZXJl IGlzIG9uZSBleGFtcGxlIG9mIHN1Y2ggYSB0ZXh0Og0KPg0KPiINCj4gICBUaGUgbGltaXRhdGlv bnMgb2YgdGhlIGNvbnN0cmFpbmVkIG5vZGVzIGFzayBmb3Igc2VjdXJpdHkgbWVjaGFuaXNtcw0K PiAgIHdoaWNoIHRha2UgdGhlIHNwZWNpYWwgY2hhcmFjdGVyaXN0aWNzIG9mIGNvbnN0cmFpbmVk IGVudmlyb25tZW50cw0KPiAgIGludG8gYWNjb3VudDsgbm90IGFsbCBjb25zdGl0dWVudHMgbWF5 IGJlIGFibGUgdG8gcGVyZm9ybSBhbGwNCj4gICBuZWNlc3NhcnkgdGFza3MgYnkgdGhlbXNlbHZl cy4gIEluIG9yZGVyIHRvIG1lZXQgdGhlIHNlY3VyaXR5DQo+ICAgcmVxdWlyZW1lbnRzIGluIGNv bnN0cmFpbmVkIHNjZW5hcmlvcywgdGhlIG5lY2Vzc2FyeSB0YXNrcyBuZWVkIHRvIGJlDQo+ICAg YXNzaWduZWQgdG8gbG9naWNhbCBmdW5jdGlvbmFsIGVudGl0aWVzLg0KPg0KPiAgIEluIG9yZGVy IHRvIGJlIGFibGUgdG8gYWNoaWV2ZSBjb21wbGV4IHNlY3VyaXR5IG9iamVjdGl2ZXMgYmV0d2Vl bg0KPiAgIGFjdG9ycyBzb21lIG9mIHdoaWNoIGFyZSBob3N0ZWQgb24gc2ltcGxlICgiY29uc3Ry YWluZWQiKSBkZXZpY2VzLA0KPiAgIHNvbWUgb2YgdGhlIGFjdG9ycyB3aWxsIG1ha2UgdXNlIG9m IGhlbHAgZnJvbSBvdGhlciwgbGVzcyBjb25zdHJhaW5lZA0KPiAgIGFjdG9ycy4gIChUaGlzIG9m ZmxvYWRpbmcgaXMgbm90IHNwZWNpZmljIHRvIG5ldHdvcmtzIHdpdGgNCj4gICBjb25zdHJhaW5l ZCBub2RlcywgYnV0IHRoZWlyIGNvbnN0cmFpbmVkbmVzcyBhcyB0aGUgbWFpbiBtb3RpdmF0aW9u DQo+ICAgaXMuKQ0KPiINCj4NCj5JIHNlZSB0aGUgc3RvcnkgYSBiaXQgZGlmZmVyZW50bHkuDQo+ DQo+V2hhdCBJIHNlZSBpcyB0aGF0IGluIGdlbmVyYWwgdGhlcmUgaXMgYSBuZWVkIGZvciB0aGly ZCBwYXJ0aWVzIHRvDQo+Y2VudHJhbGx5IG1hbmFnZSBhdXRob3JpemF0aW9uLiBUaGlzIGlzIG5v dCBhIHVuaXF1ZSBhc3BlY3Qgb2YNCj5jb25zdHJhaW5lZCBkZXZpY2VzLiBZb3UgY2FuIGxvb2sg YXQgcHJldHR5IG11Y2ggZXZlcnkgc2VjdG9yIGFuZCB5b3UNCj53aWxsIHNlZSB0aGF0IHRoZXJl IGlzIGEgZGVzaXJlIHRvIGNlbnRyYWxseSBtYW5hZ2UgZGV2aWNlcyBmb3IgYQ0KPnZhcmlldHkg b2YgcmVhc29ucywgbW9zdCBvZiB0aGVtIGhhdmUgbm90aGluZyB0byBkbyB3aXRoIGRldmljZQ0K PmxpbWl0YXRpb25zLiBJdCBpcyBqdXN0IGNvbnZlbmllbnQgdG8gZG8gdGhhdC4NCj4NCj5JZiBJ IGxvb2sgYXQgdGhlIGlkZW50aXR5IG1hbmFnZW1lbnQgaW5kdXN0cnkgdGhlbiBJIHNlZSB0aGVt IGFsc28NCj5pbnRyb2R1Y2luZyBjYXBhYmlsaXRpZXMgZm9yIGF1dGhvcml6aW5nIElvVCBkZXZp Y2VzIChhbmQgbm90IGp1c3QgdXNlcnMNCj5hbmQgc2VydmljZSBhY2Nlc3MsIGFuIGVmZm9ydCB0 aGF0IGhhcyBiZWVuIGdvaW5nIG9uIHRoZSBsYXN0IDE1KyB5ZWFycykuDQoNCk5vdGUgdGhhdCB0 aGUgcXVvdGUgYWJvdmUgZG9lcyBub3QgZXhwbGljaXRseSBtZW50aW9uIOKAnGF1dGhvcml6YXRp b27igJ0uDQoNCkl0IGFsc28gYXBwbGllcyB0byBvdGhlciBzZWN1cml0eSBzZXJ2aWNlcywgZm9y IGV4YW1wbGUsIGF1dGhlbnRpY2F0aW9uDQphbmQga2V5IGVzdGFibGlzaG1lbnQsIHdoZXJlIHRy dXN0ZWQgdGhpcmQgcGFydGllcyBwcm92aWRlIHNlY3VyaXR5DQpjb250ZXh0IGluZm9ybWF0aW9u IHN1Y2ggYXMga2V5cyBhbmQgb3RoZXIgcGFyYW1ldGVycyB0aGF0IGRlcGVuZGVudCBub2Rlcw0K dXNlIHRvIGVzdGFibGlzaCBzZWN1cmUgY29ubmVjdGlvbnMuIFN1Y2ggZXhhbXBsZXMgYWxzbyBl eGlzdCBpbiB0aGUNCnVuY29uc3RyYWluZWQgd29ybGQgYW5kIGNhcnJ5IG92ZXIgdG8gdGhlIGNv bnN0cmFpbmVkIHNldHRpbmcsIGFuZCBtYXkgYmUNCm5lY2Vzc2FyeSBmb3IgdGhlIHNlcnZpY2Ug dG8gd29yayBpbiB0aGUgY29uc3RyYWluZWQgc2V0dGluZy4NCg0KQW5kIHRoZXJlIGFyZSB5ZXQg b3RoZXIgZXhhbXBsZXMgb2YgdGhpcmQgcGFydHkgc2VydmljZXMgd2hpY2ggYXJlIG5vdA0Kc3Bl Y2lmaWMgdG8gbmV0d29ya3Mgd2l0aA0KICAgY29uc3RyYWluZWQgbm9kZXMgYnV0IHRoZWlyIGNv bnN0cmFpbmVkbmVzcyBpcyB0aGUgbWFpbiBtb3RpdmF0aW9uLA0Kc3VjaCBhcyB0aGUgbWVzc2Fn ZSBicm9rZXIgaW4gYSBwdWJsaXNoLXN1YnNjcmliZSBzZXR0aW5nLCB3aGljaCBvZmZsb2Fkcw0K YSBjb25zdHJhaW5lZCBwdWJsaXNoZXIgZnJvbSBpbnRlcmFjdGluZyB3aXRoIGVhY2ggc3Vic2Ny aWJlciAoaW4gd2hpY2gNCmNhc2Ugb25lIHNlY3VyaXR5IG9iamVjdGl2ZSBpcyBlbmQtdG8tZW5k IHNlY3VyaXR5IGJldHdlZW4gcHVibGlzaGVyIGFuZA0Kc3Vic2NyaWJlcikuDQoNClN1Y2ggZXhh bXBsZXMgYXJlIGJlaGluZCBpbiB0aGUgdGV4dCB5b3UgcXVvdGVkLCBwbGVhc2UgY29uc2lkZXIg dGhhdCB3aGVuDQp5b3UgcHJvcG9zZSBuZXcgdGV4dCAtIHdoaWNoIEkgYWxzbyBlbmNvdXJhZ2Ug eW91IHRvIGRvIQ0KDQoNCkfDtnJhbg0KDQoNCj4NCj5JbiB0aGF0IHNwaXJpdCBJIGJlbGlldmUg aXQgaXMgd29ydGh3aGlsZSB0byBwaHJhc2UgdGhlIHN0b3J5IGluIGEgYml0DQo+YnJvYWRlciBz dHlsZSBzbyB0aGF0IHRoZXNlIGNvbXBhbmllcyByZWNvZ25pemUgdGhlbXNlbHZlcyBhbmQgdGhl aXINCj53b3JrIGFnYWluIGluIHRoaXMgZW52aXJvbm1lbnQsIHBhcnRpY3VsYXJseSBzaW5jZSBt YW55IG9mIHRoZSBkZXBsb3llZA0KPklvVCBkZXZpY2VzIGFyZSBub3QgYXMgY29uc3RyYWluZWQg c29tZSBzb21lIHdvdWxkIHRoaW5rLg0KPg0KPldoYXQgSSB3b3VsZCBkbyBpcyB0byBkZXNjcmli ZSB0aGUgc3RvcnkgYXMgYW4gZXZvbHV0aW9uLiBUb2RheSB3ZSBoYXZlDQo+Y29tcGFuaWVzIGRv aW5nIGRldmljZSBtYW5hZ2VtZW50IGFuZCB3aXRoIHRoZSBpbmNyZWFzaW5nIElvVCBkZXBsb3lt ZW50DQo+dGhleSBhcmUgYWxzbyBtb3Zpbmcgb3ZlciB0byB0aGUgbWFuYWdlbWVudCBvZiBzbWFs bGVyIGRldmljZXMuDQo+DQo+SSBjb3VsZCBjb250cmlidXRlIHRleHQgaWYgdGhlcmUgaXMgYWN0 dWFsbHkgaW50ZXJlc3QuIEkgaGF0ZSB0bw0KPmNvbnRyaWJ1dGUgdGV4dCB0aGF0IGdldHMgdHJh c2hlZC4NCj4NCj5XaGF0IGRvIG90aGVycyB0aGluayBhYm91dCB0aGlzIGFwcHJvYWNoPw0KPg0K PkNpYW8NCj5IYW5uZXMNCj4NCj4NCg0K From nobody Wed Oct 7 07:48:03 2015 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69DF21A9150; Wed, 7 Oct 2015 07:47:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rQvelrKW_XIk; Wed, 7 Oct 2015 07:47:49 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 45ADF1A914B; Wed, 7 Oct 2015 07:47:49 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.4.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151007144749.30946.25878.idtracker@ietfa.amsl.com> Date: Wed, 07 Oct 2015 07:47:49 -0700 Archived-At: Cc: ace@ietf.org Subject: [Ace] I-D Action: draft-ietf-ace-usecases-08.txt X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Oct 2015 14:47:50 -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 Working Group of the IETF. Title : ACE use cases Authors : Ludwig Seitz Stefanie Gerdes Göran Selander Mehdi Mani Sandeep S. Kumar Filename : draft-ietf-ace-usecases-08.txt Pages : 29 Date : 2015-10-07 Abstract: Constrained devices are nodes with limited processing power, storage space and transmission capacities. These devices in many cases do not provide user interfaces and are often intended to interact without human intervention. This document includes a collection of representative use cases for authentication and authorization in constrained environments. These use cases aim at identifying authorization problems that arise during the lifecycle of a constrained device and are intended to provide a guideline for developing a comprehensive authentication and authorization solution for this class of scenarios. Where specific details are relevant, it is assumed that the devices use the Constrained Application Protocol (CoAP) as communication protocol, however most conclusions apply generally. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ace-usecases/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-ace-usecases-08 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ace-usecases-08 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 Wed Oct 7 07:59:44 2015 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87F831A9252 for ; Wed, 7 Oct 2015 07:59:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.55 X-Spam-Level: X-Spam-Status: No, score=-1.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LvKOJRIj6QGz for ; Wed, 7 Oct 2015 07:59:20 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4EE011A923E for ; Wed, 7 Oct 2015 07:59:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [134.102.201.11]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id t97ExGgi004853 for ; Wed, 7 Oct 2015 16:59:16 +0200 (CEST) Received: from [IPv6:2001:638:708:30da:39bf:95b4:4a13:7707] (unknown [IPv6:2001:638:708:30da:39bf:95b4:4a13:7707]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3nWJj00Jd6z4nlQ for ; Wed, 7 Oct 2015 16:59:16 +0200 (CEST) References: <20151007144749.30946.36680.idtracker@ietfa.amsl.com> To: "Ace@ietf.org" From: Stefanie Gerdes X-Enigmail-Draft-Status: N1110 X-Forwarded-Message-Id: <20151007144749.30946.36680.idtracker@ietfa.amsl.com> Message-ID: <56153343.7020009@tzi.de> Date: Wed, 7 Oct 2015 16:59:15 +0200 User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <20151007144749.30946.36680.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Subject: [Ace] Fwd: New Version Notification for draft-ietf-ace-usecases-08.txt X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Oct 2015 14:59:22 -0000 Hi all, I submitted a new version of the use cases draft that addresses Abhinav's and Olaf's comments. Thank you Sandeep and Abhinav for finding a solution so quickly. Best regards, Steffi -------- Forwarded Message -------- Subject: New Version Notification for draft-ietf-ace-usecases-08.txt Date: Wed, 07 Oct 2015 07:47:49 -0700 From: internet-drafts@ietf.org To: Mehdi Mani , Sandeep Kumar , Sandeep S. Kumar , Ludwig Seitz , Goran Selander , Stefanie Gerdes , Stefanie Gerdes , Mehdi Mani , Ludwig Seitz , "Göran Selander" A new version of I-D, draft-ietf-ace-usecases-08.txt has been successfully submitted by Stefanie Gerdes and posted to the IETF repository. Name: draft-ietf-ace-usecases Revision: 08 Title: ACE use cases Document date: 2015-10-07 Group: ace Pages: 29 URL: https://www.ietf.org/internet-drafts/draft-ietf-ace-usecases-08.txt Status: https://datatracker.ietf.org/doc/draft-ietf-ace-usecases/ Htmlized: https://tools.ietf.org/html/draft-ietf-ace-usecases-08 Diff: https://www.ietf.org/rfcdiff?url2=draft-ietf-ace-usecases-08 Abstract: Constrained devices are nodes with limited processing power, storage space and transmission capacities. These devices in many cases do not provide user interfaces and are often intended to interact without human intervention. This document includes a collection of representative use cases for authentication and authorization in constrained environments. These use cases aim at identifying authorization problems that arise during the lifecycle of a constrained device and are intended to provide a guideline for developing a comprehensive authentication and authorization solution for this class of scenarios. Where specific details are relevant, it is assumed that the devices use the Constrained Application Protocol (CoAP) as communication protocol, however most conclusions apply generally. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat From nobody Wed Oct 7 08:42:13 2015 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B23A21AC425 for ; Wed, 7 Oct 2015 08:41:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Aaia9QMuv9be for ; Wed, 7 Oct 2015 08:41:50 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (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 3F6E91AC427 for ; Wed, 7 Oct 2015 08:41:50 -0700 (PDT) Received: from [192.168.10.196] ([64.134.100.215]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0MfzEP-1ZvipT10UP-00NSDj for ; Wed, 07 Oct 2015 17:41:48 +0200 To: "Ace@ietf.org" From: Hannes Tschofenig Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9 Message-ID: <56153D33.6010100@gmx.net> Date: Wed, 7 Oct 2015 17:41:39 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="TGkF3qM7p2cs73V4ij051e9TRjQD7IwX4" X-Provags-ID: V03:K0:lQKvWJQQcDRr02k9Ph0M+xQtrb8jhs6/BLYS0plxcCCDimJVhPq 8jZogVYvPvTYEki1PpNlNxK0blIIqERqb9JYOCGcqFGV5SgTG9SF1bfQ+1q1zCSO1dliWch tFdzAWNeDMdFf6dp5GalHD863FnbnT0vtnRIoFHa+Kg2KU+WeRdo3Jo2iq2MGXIkcXG33mL i7faybXkEIqhtnbOpxg2Q== X-UI-Out-Filterresults: notjunk:1;V01:K0:6R4eFTIfxDk=:NA7UvHuiJxhWcNM6xEkceH wYFiPdlvxwZKEoi8j9T6MwZwll3A9b+UUvieJVvbubb6Vf/NhaDvZLlAAqTEYQeqHCPBM2gjd ovP8PvlPVBCe0ek8VW0y0kvLQFdwgMO6cMiEAhGQCVANaNhRlSsnynbhKipKux23ZnIF3Cx2R tmZnby/cObhJR+ecxMmjBaJAYYhAaM6ghOjPUO+RRd7IRId1czEMM/xCRo5i+g74fwjFE1b/+ JKRQ0cDQYQN40hcdXnIq90ijggUo8Up7++7FVBpsmStnnGOiw1V+U5Tquwii4GQRPCBB7x6Eo IDAWiF2lfRIb5cDm1gM9N+KaipwngrNlED2jQheaUjxfYZfNbpAPOBWC6xXCi8kQy0xsIisHt rU1uM+Mnz85vqp5rrbuycmfnSC17WU7q0BxONzYH7vUsOPh+GHXvKehLB0CSwUcns2v1jjA9I Z0LQzcXCsJCSHIohcRj6qpP/2Zq81LU5xH4gUwy4yXGKJw8cqNH7SyRBuEm822ugaQW0ahglm EhBnaXtAj3gWBP4QrvEvGnYa857iCvEzfuUvYkdsLSrHveIwYBa3kAPzHNyvOzhlptJ1yBcOQ y52u3GLdrs/XxiWz9aa/MteoAGqgcyqSOV2Vv9PnCI7kaWyM+DqXaECY7ItaJ1+fwIZ8g62xI ph/3M+3R1WPImxIC6yCuASPeJfwAPNcfPHJLSrIAT6+w99Y1W5FOXQMyA5MBMw6PHhmHahlLH gDmxnkvdKqy8FSDnIMvPsQU+ajSYz3miIWhxXBl0Vec8RWDt2IWpUPsLMxA= Archived-At: Subject: [Ace] Dynamically Connecting Smart Sports Equipment X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Oct 2015 15:41:51 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --TGkF3qM7p2cs73V4ij051e9TRjQD7IwX4 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable After Sean provided his review comments I took a look at this scenario again and I get more and more the impression that we should delete this scenario since it is nothing that we do in ACE. My understanding of the scenario is that we are asking for a sort-of multi-user operating system to be introduced for sports watches. While this sounds like a fun scenario I don't see how it relates to what we do in ACE. Ciao Hannes --TGkF3qM7p2cs73V4ij051e9TRjQD7IwX4 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJWFT00AAoJEGhJURNOOiAt9g8H+weOWyP+6TBQI1ravfaPyvAp rQ/MSiOFDwo+hywR+USokLsHp7XAhnwsJt8yA1HP9qckJmh9DRNqmRFN2fN+VQQZ RCG+1fXUYyLhZO6bFYgsSx/rN12mkogAc6afnb7QrAC6/uQramt8Oc/4FjX9umFu X5qik/eIoalnSo3rMg+A2sOpykvelbRQFgIKYvzL9yoBNtRiB07StP7U6GUObuEf QtTR0/5SwwjPKq5+lVs9JcJ3BWHRGEHsXeGsXzpuQzVI/oCZ7rZ6zsPwmT6SupEr 5YvBvPvV0rYfcNt6aJubxL3xr+Lj7jN2SoVl4PPl/qC+zIAHLyo3doaeInPhWes= =xc1x -----END PGP SIGNATURE----- --TGkF3qM7p2cs73V4ij051e9TRjQD7IwX4-- From nobody Wed Oct 7 09:12:32 2015 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBEB01ACD23 for ; Wed, 7 Oct 2015 09:12:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fP9v62f_1bBK for ; Wed, 7 Oct 2015 09:12:06 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (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 15EA21ACD18 for ; Wed, 7 Oct 2015 09:12:06 -0700 (PDT) Received: from [192.168.10.196] ([64.134.100.215]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0LqALY-1aEoPz3CQi-00dlHx for ; Wed, 07 Oct 2015 18:12:04 +0200 To: "Ace@ietf.org" From: Hannes Tschofenig Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9 Message-ID: <5615444F.5050108@gmx.net> Date: Wed, 7 Oct 2015 18:11:59 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="Mktg2q2SA42mtVMW8a5DAg4H7mCqUa8Uv" X-Provags-ID: V03:K0:pgAfcSGLtQCvlnHwIUhsf31boJ82WhiGXUc7Q9Q+cj4wNkP16J0 sCm36yTnLldzTkVfL9ClglG5CWsumNGC0MsnhrIp6dnldfTmcCIW+mR7ir8BDZQy6jbz9/X PdEJYxYeQIIxBe4svc/VI0tyTmgnJKe4WSXJ7LeJOi9L1uCbpDTPWTd39XiM9Gj/syxoaiG byN8I0GP/BQ8QSxZs21Ew== X-UI-Out-Filterresults: notjunk:1;V01:K0:wMWvHuvo6+E=:htd/Hded9PodmawCZHV4Qe kswxAxVqGtiqcaMJur0f3i8Xr01VNhO5NcfFr+bDoJdP1OgnLojpD43Rx81zfKoy30VVnnwDU XcTJjkXF63WeXI8+J1yshZu8+zsEJuY0SD7ElxDrvetzKYuWAcuVoYhq9KLHj83srtbBnuKra EMkWCwBK2mizs+AjDDELKeu0z4RMq8BlQdQ6RBLsqvhnqJAELWMj7h1ffcLLcw1Y+8WPic0+p wVozx4U4qVJ8FJwpp9i3sRW146Ugj2CacLSFxXgN9+aNwhYmbKCWR4HYDGqbt92GcEDs8byWo OjN2oOyeVsHFS/oSJfwaQAnXPzFQ5AkfK+vPyFmwfGH9LzvIg9aNXtI+heRXBaCtHRoCBtptT VLr2vML2ulj0FP4s6Hx6aEQahFunCa1vBHT++i15c3z9UtPaVvK2hQDjiZY/Y03qUmG6CpXLZ UPKRrjZrWaI/ZCVaBhX9MIg1BYJygNJxGQhqf5i2a76OfDU+/cq0MReYmmWAlMMXSYcYyplsH ULuyFczsSC1Fr5HqpI3yWJvDuXT5cl9tebE6R/8T3iEYngEax8AXge3XHD+VPpMn042bJ3qZK SCf9E0VFH/qupNmIFac9BIlg5QQ+T0INASSINzO5C+TzelFyhMwTsaGmpWlO+LPc+kxkvXC/2 7ZQduBp2h9fTiqBYO+WN2mVcI7KoHBnoDdVINenVbxyudHQJH0vxzqkOBWWYKepJ1I3lZpSQS qP2cOjQPAVt4Yb5GNnFDq2XdHEVORqBqCNK1YBr5A6U4bIN0AiqxRGwvmgg= Archived-At: Subject: [Ace] Privacy Considerations -- Use Case Draft X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Oct 2015 16:12:09 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --Mktg2q2SA42mtVMW8a5DAg4H7mCqUa8Uv Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Here is proposed text for the privacy consideration section. 4. Privacy Considerations The constrained devices in focus of this document collect data from the physical world via sensors or affect their surrounding via actuators. The collected and processed data often can be associated with individuals. Since sensor data may be collected and distributed on a regular interval a significant amount of information about an individual can be collected and used as input to learning algorithms as part of big data analysis and used in an automated decision making process. Offering privacy protection for individuals is important to guarantee that only authorized entities are allowed to access collected data and to trigger actions, to obtain consent prior to the sharing of data, and to deal with other privacy-related threats outlined in RFC 6973. RFC 6973 was written as guidance for engineers designing technical solutions. For a short description about the deployment-related aspects of privacy and further references relevant for the Internet of Things sector please read Section 7 of RFC 7452. --Mktg2q2SA42mtVMW8a5DAg4H7mCqUa8Uv Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJWFURQAAoJEGhJURNOOiAtEHsH/A4laL1xYxleGwaWs/RGQGlf 8vOdG0Sbi23kGQSQH/Htqv/DYQBZU+kQIqDbSByuuEd1xCze0nckUzupYVlV/nYH m0yLENP0MAyNu1aZHs0WLnrrpaonUgZ39m+EccNouL+I7gEJPp34fMePY32WuPJZ a89jdszJ6h+jrM7GoWs+CywWq6cp6MN+MdfNj0BNeYCfcSDMHKL1upG24Wxw8mkG G3f5DVAGknyunKYzt+Iq6lKMomMYOBtH1Srd4NbsJ+Ob6ORTwy0SfT7kcMLEZptO ZEkPJViCGczGQhPMKd90enrSNMzl/oJTvPU3a7WMCAJuQyIGhoYA+IsJmG0dj7k= =gfXF -----END PGP SIGNATURE----- --Mktg2q2SA42mtVMW8a5DAg4H7mCqUa8Uv-- From nobody Wed Oct 7 10:41:05 2015 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CE441A90EB for ; Wed, 7 Oct 2015 10:41:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W2Rfkie5ZxNv for ; Wed, 7 Oct 2015 10:41:02 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (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 D57081A8F4C for ; Wed, 7 Oct 2015 10:41:01 -0700 (PDT) Received: from [192.168.10.197] ([64.134.100.215]) by mail.gmx.com (mrgmx002) with ESMTPSA (Nemesis) id 0Lu8Ri-1aj2Oz2AJq-011VSg for ; Wed, 07 Oct 2015 19:41:00 +0200 To: "Ace@ietf.org" From: Hannes Tschofenig Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9 Message-ID: <56155927.30307@gmx.net> Date: Wed, 7 Oct 2015 19:40:55 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="Cbp74n2dExNm3kpGSm1LAOmtf9eKLL8is" X-Provags-ID: V03:K0:wApyHqPWIOuiclygbEMOI/8n3kd8bzG8qjXFQKxPPq+T95WSA2Y BPwoHyAr0iBCqEJf4CGPR8td5dfHFtcFka1u7k0DXvdUUhCBoMUclNKcGk0FFQTxqlTIhHO bYxF6wf4F6c+kfsLiz1ZIjecwAM/7lxwL4V0Z6Ny+Xb+cahEPhViDpmnjS0YnrHMEO0jReH ZMT7jkXqJdY5oHtuNiEbw== X-UI-Out-Filterresults: notjunk:1;V01:K0:IInkYP34vUE=:JQ0izBW+s734mjuxhPMJOm ozi5iurPN/rrNoXeJ9kNVw/TxhMD1+Uit2VsQyJcIgMhivhKQ46uFVYGnsimOZE4IqBSQEQdl ad+e7CPw5H/B9Di2O6mnFyq9Q3woRjVNTotabX0VBXwMaAYKdXJiHaY5+UOhKUzY5JMnYA626 /u3+41EV7Zg6FL463M4ZYYIUn6/UzylWBaX6KGrRRbn9tNME5uYYy38PA7DGirneeR+PI/mwO hBRsdIBkK547qRG9c7a+NurCD+GUJ5WM7VZOLxZs/qWkKMPE1CTfVS1L2GTxczMVpAUjzL4pX iF3n6/zPiAZuVo1G/f8GWQgcPTfSuZxz3+AEs2JElZifVqu3BBv35TfUeKpRQHGI6/7tU1P5S 6KkYbG8Ci0itIf7ty0/Wb+6LwKzPwy+Bj6pKDgTXXEAX4fAQKQQHnGUuuUaOc2lqL1jFNwo9s vLVGdCt7EiIe3dUbk3Dytn0FiAQGeBC0XS9DWu+PFle+BU/1+DXXw9anHWf7wJG9ZzLltG88u JGxVxaSI8rDsEoHdMjW98YG107ETDK4ns0aO91KcpvsGkjAcF7MTkHPbpbJpM9sZcmvmGCA1q GxHgf6nkVxOP1orh/TmSmqWpvdorpEH3c/OcnAAejoEKdn6Pc9H4TSfKa3Tev48h+oX2VQ7kX Zqjgl2wUx8KfV929duRD3Q33gvLQCE1Fcn1APN06oYf35ZR8wDA3waFjcZhsT8eEv9wK919zz Mb0jl5BnjYucnfvKCZ/ZFxP0Q+L98du+VHjR4aOUMcjoVg39yVMWNj1HIeY= Archived-At: Subject: [Ace] ACE Use Case Draft: IPR Confirmation X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Oct 2015 17:41:03 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --Cbp74n2dExNm3kpGSm1LAOmtf9eKLL8is Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Ludwig, Steffi, Mehdi, Goeran, Sandeep, I am working on the shepherd writeup for the use case document: https://tools.ietf.org/html/draft-ietf-ace-usecases-08 One item in the template requires me to indicate whether each document author has confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. Could you please confirm? Ciao Hannes --Cbp74n2dExNm3kpGSm1LAOmtf9eKLL8is Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJWFVkoAAoJEGhJURNOOiAtCr0IAKMPMOycLSArdQK6+7DkHDK8 SVg4tG1BTdmgJ+ZVeojs3LrLveb05iQlwbKxt1ZFcirzybOjv/EQPk592FRxp7vS B6DraRD9C9UdJBwVDK0pHwQKbHtox2evfEFOCMAp+8ueI5nPzdPt+h/5PeuM/VwH 9PiS+VZDb0iein8knN2SBVYXK0PCGktIz68I6i/0c6oNCyl8ur5Bytw1tT9bF8hv nVuiWhUN3KETQ3ir1s4nx5rHeBVp7fY7alf2shcm+ooN69gNsbBDHA/cKgKI3cpk zgUYGS8I88Ru9BzU+H5UHUUD1vUtKIPktgwAO4F4kGy2Bw039UVXuunBBIgtP0M= =TywB -----END PGP SIGNATURE----- --Cbp74n2dExNm3kpGSm1LAOmtf9eKLL8is-- From nobody Wed Oct 7 10:56:44 2015 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8F381ACD7D for ; Wed, 7 Oct 2015 10:56:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bI8pFFLm2B9W for ; Wed, 7 Oct 2015 10:56:40 -0700 (PDT) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0780.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::780]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A00F1ACD71 for ; Wed, 7 Oct 2015 10:56:39 -0700 (PDT) Received: from DB4PR04CA0012.eurprd04.prod.outlook.com (10.160.41.22) by AM3PR04MB258.eurprd04.prod.outlook.com (10.242.17.141) with Microsoft SMTP Server (TLS) id 15.1.293.16; Wed, 7 Oct 2015 17:56:22 +0000 Received: from AM1FFO11FD003.protection.gbl (2a01:111:f400:7e00::122) by DB4PR04CA0012.outlook.office365.com (2a01:111:e400:9852::22) with Microsoft SMTP Server (TLS) id 15.1.286.20 via Frontend Transport; Wed, 7 Oct 2015 17:56:23 +0000 Authentication-Results: spf=none (sender IP is 23.103.247.180) smtp.mailfrom=philips.com; gmx.net; dkim=none (message not signed) header.d=none;gmx.net; dmarc=none action=none header.from=philips.com; Received-SPF: None (protection.outlook.com: philips.com does not designate permitted sender hosts) Received: from 011-smtp-out.Philips.com (23.103.247.180) by AM1FFO11FD003.mail.protection.outlook.com (10.174.64.85) with Microsoft SMTP Server (TLS) id 15.1.293.9 via Frontend Transport; Wed, 7 Oct 2015 17:56:22 +0000 Received: from DB5PR9001MB0167.MGDPHG.emi.philips.com (141.251.190.211) by DB5PR9001MB0165.MGDPHG.emi.philips.com (141.251.190.209) with Microsoft SMTP Server (TLS) id 15.1.286.20; Wed, 7 Oct 2015 17:56:16 +0000 Received: from DB5PR9001MB0167.MGDPHG.emi.philips.com ([141.251.190.211]) by DB5PR9001MB0167.MGDPHG.emi.philips.com ([141.251.190.211]) with mapi id 15.01.0286.019; Wed, 7 Oct 2015 17:56:16 +0000 From: "Kumar, Sandeep" To: Hannes Tschofenig , "Ace@ietf.org" Thread-Topic: [Ace] ACE Use Case Draft: IPR Confirmation Thread-Index: AQHRASdbw4Q+n30zqUCKTcy7lJHhS55gUJ0A Date: Wed, 7 Oct 2015 17:56:16 +0000 Message-ID: References: <56155927.30307@gmx.net> In-Reply-To: <56155927.30307@gmx.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Microsoft-Exchange-Diagnostics: 1; AM1FFO11FD003; 1:udwkEXEZvUgq0NQL/luJfq6wW4uTfkZA2oJ6Mx7xYOxSgsg0h8mS0ScMH7kXKtfCAtjqY2jvXtNOLbYtoBWLjI/qlJlMXr1U0LLp8vGa/SHICbiJkV3GDYYWcuBmsxWk7yGyFzUaw1Nai+tWe7bL6dI4NbpJk2QqND09XQlnrJtOKrE8UmmvuQnDcWSrbd+eHE2IRGGRUsLnfcqa3Ta9tW+Zi2rQzMjZPZC/hqsGs9xnRxp0IMuKs9/lL7x6yge1HxmcIbYY8WC1weWN6e6AjOJ5r16QdVg/161cYSY1EruCkMhswTjXl2fF9Zcddt/mcUD/J4U0t0b4oDMpV1lPLz3lYDDACPsfcdghEwyoGUI= X-Forefront-Antispam-Report: CIP:23.103.247.180; CTRY:; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(2980300002)(428002)(24454002)(374574003)(85714005)(189002)(199003)(55904004)(63666004)(92566002)(106466001)(33646002)(64706001)(50466002)(54356999)(76176999)(50986999)(10400500002)(69596002)(101416001)(97756001)(95246002)(5007970100001)(19580395003)(5001960100002)(16796002)(107886002)(105586002)(5001770100001)(97736004)(81156007)(2950100001)(106116001)(2900100001)(15975445007)(102836002)(19580405001)(46102003)(23726002)(47776003)(5008740100001)(87936001)(11100500001)(2501003)(86362001)(189998001)(6806005)(46406003)(95446003)(567094001); DIR:OUT; SFP:1102; SCL:1; SRVR:AM3PR04MB258; H:011-smtp-out.Philips.com; FPR:; SPF:None; PTR:InfoDomainNonexistent; MX:1; A:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; AM3PR04MB258; 2:6tEGHIUXR/eAA1evCIbNIDQ05XAYS28l4gU7713oqc8GywVa3mHHudPG7HjDsb0+eQv26jMuBJJpl+S5NVRv1PBEbW8Z0nzVvHDG51zNueugQA+rbL2N0qA63dIUllvYcP/RFlF2YCW1BGGQ5xv2JECJp0Y0pqMdolF/SLEDUzg=; 3:m8py21QwR/dYfELXVoe3RkhzRQwnAYRxjRg8Iy0LAX1FbeTCSMccEf8iKyz/UIL4QeqKPS8J0IKei/Vnz5wpPrY8huBrWy/VO1LCjEx4CXOcWZ6Jt7IZQHhXxxNtGwYH5wzZdKdf4SNOzlQDgS+mdPSt5o2THpC8H/A8f4RnsvyZhb2IsprcPk75FYWGiCE+XlgKq59+C4mCtT8/XzOwh1auzSzojFdUVTuQIrSUfpw=; 25:3c9PUSRkWrrMo9bs17oXx2fUtdHhdrJLBqvJcDRVvkCRU6Di3APpDl3jqqhPd4hUb3PO6YnKwSXnuy6xmlxRqz8Z5nGtyvl7qTfnowQiU/Z9xIobcg6TWSXn9GDiXPt3j6EFk/p3jTaiV/tUckIggxLpfsMXeC7ml9OG6UD3x/bXnQ+Nz+x/jWdn3366DTciHQGZ0IpNFfwFTxRKqPPD18OVkQUWvw6PLtpjNuLP64m0G/Y9fVCCorxLHp+ZtWZeqVgWt3Ptv7x+NlIjJkf1xg== X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:AM3PR04MB258; X-Microsoft-Exchange-Diagnostics: 1; AM3PR04MB258; 20:PIPH+YFXWKJ9NMduDyKRb2Pv6DI7AvHRHw/DdK3uAwPYz78tKW9gMjD9+nDmeOlMl5mUsUT5KE+HkyCd8sxKY9k0vpDuowAmtQe2Ir16f+lNukIT4K2xKGtc3w0raVBObqIQUtlbrUQA1tT1+lhpRnqYsHrE0mHs3OLp4OhKjJvMTgDqDbtt9rpGhnGorcm5q+v6tkFq65aDm5CCwDWiNm7m0vtL+TYflQws6Ev0kUrOxiBSFcSYiqHc3ZreZjuh76MJLzaIB4vniqd/Clw1vASoqgnP9hLgisQ6aLiImMDMFHT3ClW9QBGXDb7lS5U1AGl5uN8w1wR9uzulQI7ex1eNKK+J5A+Xpc6lK5iVnDYdgU+Fa6mgF94UiTBfPB9ruuXMt9PqQo+oyij6JBNyGu7kqquRHwxyYqBv4SVPIy7E65vT0inwB8GMEf+d27ccexJVeAFWwjNx3Uo8wmqPfZ5HEISOS702MzJnrW0LLs/LNcvRYsxF9fwauU9KyemQ; 4:XvU0zO4nOxcRe73XthDsrIxNQ7hqIbwzvSD0kCZ7wMzMO6jSFZzH2GfzIEMD2jGEj9/n8rZTlkPyLmKqFDG/eoTo0trT8CVYLHuM1gH9hpJ6tv8x5g0URXoGPVtjIAyoDPUZkmbcZoEFnudkvBXV+3zAI8VAYDV/WJI6u0YEkD6mV7M+TKh4O4y13yULVCqcqPzYo8bBWQuO+EnEHmyLZPTISamUzRICDqvhuOBQi8fPMd7vHYsUQWordflAGrf8Gxm8auV1tAeJ10rkHU9ENyJOkFXZaeikwPRFRxc7IZfIIwgtUoHKzU8jm+lRuXEFmwHMoDCG497SIrMCj3pw9lbhV8E1UuqrlYVBV396M4U= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(520078)(5005006)(8121501046)(3002001); SRVR:AM3PR04MB258; BCL:0; PCL:0; RULEID:; SRVR:AM3PR04MB258; X-Forefront-PRVS: 0722981D2A X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; AM3PR04MB258; 23:ynvTKNYRFNKa5z8qBAxeBp1U3LzZ5lb2y0NoJmOXAo?= =?us-ascii?Q?lMZW05o1NS11sMwE49LcYobpgIPviEmfM2x43OEtl5FvuAiOdsOHEvH8Z4e1?= =?us-ascii?Q?4Xu27pO70wWo4LN0avo8HFzAHL3a9o+WhoWCBP17mUDeR+UwB6yLVlFxQb73?= =?us-ascii?Q?MDlJED9zF6ReDwio5W0e9x9aCMoIauiKPRRnsjvGT7KTWN9Do9S4fpd570R5?= =?us-ascii?Q?Wfwj/kL8P4ejw1LESegcXxL7nLyiyiEa5XoBs7mhuBnlh/zn9AG+d660S7u+?= =?us-ascii?Q?icL8KAdy9jEbIYBWjtWjWDfZzJm5AajPR36haXP7+aO898e9AdporuAya34k?= =?us-ascii?Q?1gVAUh7sVVPXSn+2nwbtl0eLEU2MSo/dLWLQyv3Uaon09xyRk5GA8KbzRgVW?= =?us-ascii?Q?6iL2gxsf7aujXqqES/wPxGvOT5ZSFgNWMDL4rRhWVOhBOyHTsJJ6/jL+xbXI?= =?us-ascii?Q?qV+8ToxxlIyH03p1fBa44dyGhfTA3+hLexkgvwnV311mKbdq8fdOcm6+v2BW?= =?us-ascii?Q?ofrTwGtXD6oWHoGQF3CwX6/YC985y0P4smBxzPg8qNryjlRI23c1Wc+nZv7N?= =?us-ascii?Q?82/8oXFM4WLI2WSw3kGpWLqRabHr9Jw7RY/YVBnnOkxj6v4JDvFNO+Ai20F1?= =?us-ascii?Q?MhX1nY1xFK8OYo0y1AZ+qnvqig96/+h27hqwy+KXoayqh6HZWX+YioS98Yy8?= =?us-ascii?Q?Gz/hhJCZxhzKV4JW5xOTcsj+j8j5QaexwDO5KNQonjp/Z+gLL20T+0i8aOhP?= =?us-ascii?Q?FnTKU8V6oScsdbHVzN0jSSiyWohO84iEWyzgQj9HFqJeDh6IAhkA/paq5nbW?= =?us-ascii?Q?banl4SsAGW0DyiEMeVD7LXFtN8Dkf0agfmcC5pzE5X3c9OxejdsrLd+2p7YO?= =?us-ascii?Q?21y2niIi7ZWUt95Oo/vUZ6lrRuXMx6DJjkCaVhoG5gEPhK3EUOHh1bH6Y0nG?= =?us-ascii?Q?L28BUmr+X9i1Drh2Im8+uKwXAYBsPMfSGWSucYaOY776zFEEHO6O+UPTj7UB?= =?us-ascii?Q?JXz5tImaVLS2AJnbqeT374oxGdh8HZVXWP6TdZe7s49r+VslGFHRx/9x7+Sf?= =?us-ascii?Q?AVXqFTeyJqnZQ9tbDqbceN/JqY9roApfDRDSjP/dWBnL6l4wrhDIrC4LlT72?= =?us-ascii?Q?35QR8VtKrckHXLhljjMcNw0qApItL5W4CfVq+8XZ5bhjz8WEsEx3w2dKtvFV?= =?us-ascii?Q?r3o2MnDSyIDgHD8m9faucPp4UJuiNKUGhaGueeqesvYiqWFAhYq+gw6PDye/?= =?us-ascii?Q?pM04lwj63vEjD0UnbJZ3/GYXgtVuZ8enPUxdyznadFNHFhLKYCfprYKUlOkK?= =?us-ascii?Q?e1YrsC3SdnOW8ZW/Qs7QUHowelxiL3OYY+xgkJYT3w?= X-Microsoft-Exchange-Diagnostics: 1; AM3PR04MB258; 5:rKQl3MI6ENZw4scCmSjkWnV26mx33xtqc50eKOEoBZjn6PZL9VFQNpwbVFtrvURimc1qaNLPB/GtA6BYr6sRA5JGH+hTQsW9iTRx1l9cW8+/rz525UYCGUQv9XJlRLDss7xjhVk4ZFahqxsIWqY93A==; 24:blM2Lbq7agMLOgYgFV4eWMCPf4kTagvOO6waXm9AiU4AbyJ2RqDWr83Rnka71YI1KgYoKFI9dd8Q7NgpuIj9HO5gYSFhQbyKS1LqgBtsRDA=; 20:vGCRODMu+Ir/S72NepLZdC+SbL3MAqNtgzvowIZ5mDsMT0fHH5Nj1kaJqDAIEvtksIolscirYqp2FgEsoI00yQ== SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: philips.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 07 Oct 2015 17:56:22.7149 (UTC) X-MS-Exchange-CrossTenant-Id: 1a407a2d-7675-4d17-8692-b3ac285306e4 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=1a407a2d-7675-4d17-8692-b3ac285306e4; Ip=[23.103.247.180]; Helo=[011-smtp-out.Philips.com] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM3PR04MB258 Archived-At: Subject: Re: [Ace] ACE Use Case Draft: IPR Confirmation X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Oct 2015 17:56:42 -0000 Hi Hannes No IPR to declare from my side. Sandeep Hannes Tschofenig wrote: Hi Ludwig, Steffi, Mehdi, Goeran, Sandeep, I am working on the shepherd writeup for the use case document: https://tools.ietf.org/html/draft-ietf-ace-usecases-08 One item in the template requires me to indicate whether each document author has confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. Could you please confirm? Ciao Hannes ________________________________ The information contained in this message may be confidential and legally p= rotected under applicable law. The message is intended solely for the addre= ssee(s). If you are not the intended recipient, you are hereby notified tha= t any use, forwarding, dissemination, or reproduction of this message is st= rictly prohibited and may be unlawful. If you are not the intended recipien= t, please contact the sender by return e-mail and destroy all copies of the= original message. From nobody Wed Oct 7 12:47:22 2015 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B34E51B2FAE for ; Wed, 7 Oct 2015 12:47:21 -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, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 950n30dEUs1U for ; Wed, 7 Oct 2015 12:47:17 -0700 (PDT) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0757.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::757]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 920131B2FA6 for ; Wed, 7 Oct 2015 12:47:16 -0700 (PDT) Received: from HE1PR06CA0026.eurprd06.prod.outlook.com (10.162.181.164) by AM3PR06MB145.eurprd06.prod.outlook.com (10.242.245.14) with Microsoft SMTP Server (TLS) id 15.1.286.20; Wed, 7 Oct 2015 19:46:55 +0000 Received: from DB3FFO11FD049.protection.gbl (2a01:111:f400:7e04::151) by HE1PR06CA0026.outlook.office365.com (2a01:111:e400:51fa::36) with Microsoft SMTP Server (TLS) id 15.1.293.16 via Frontend Transport; Wed, 7 Oct 2015 19:46:54 +0000 Authentication-Results: spf=fail (sender IP is 146.108.200.10) smtp.mailfrom=tridonic.com; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=tridonic.com; Received-SPF: Fail (protection.outlook.com: domain of tridonic.com does not designate 146.108.200.10 as permitted sender) receiver=protection.outlook.com; client-ip=146.108.200.10; helo=ATBRAGMSX01.itiso.net; Received: from ATBRAGMSX01.itiso.net (146.108.200.10) by DB3FFO11FD049.mail.protection.outlook.com (10.47.217.80) with Microsoft SMTP Server (TLS) id 15.1.286.14 via Frontend Transport; Wed, 7 Oct 2015 19:46:54 +0000 Received: from ATBRAGMSX02.itiso.net ([169.254.2.75]) by ATBRAGMSX01.itiso.net ([146.108.41.69]) with mapi id 14.03.0248.002; Wed, 7 Oct 2015 21:46:53 +0200 From: Somaraju Abhinav To: "ace@ietf.org" Thread-Topic: [Ace] I-D Action: draft-ietf-ace-usecases-08.txt Thread-Index: AQHRAQ8v+Y8j1WWsdk6W9V8MtG+8/p5gbuo6 Date: Wed, 7 Oct 2015 19:46:51 +0000 Message-ID: <0E9A48AB39AF3547ACD28A6DE3E2906A0AD965@ATBRAGMSX02.itiso.net> References: <20151007144749.30946.25878.idtracker@ietfa.amsl.com> In-Reply-To: <20151007144749.30946.25878.idtracker@ietfa.amsl.com> Accept-Language: en-US, de-AT Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [146.108.8.124] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Microsoft-Exchange-Diagnostics: 1; DB3FFO11FD049; 1:P5Al7eiDNiNAEgw83560VXyQcZ8gDtM04KfhdxV9QUqalOov8xq039lNpugVx6ev0UqFUDr2WEu6zp1Gj03x6MbhJ7WLyodTWfe1gQlY2+CtasNVValFRNLJdmgDy7oM5+cOaN4NUnnmFyBMFPGbZG2BEcGumGximQ8bTy3gYNc7RpystVT0+/HbLgtLYrZXqn2cnKpxlsWm3Sk53lmQdrTtQGLhm15eXikj8i2UftW7Rphi0lOWdAJf+PFwNpnR3NL6rD0yUfNdN2nKBpI45fSGog695zPq8gFJtsDHuXl3cVn5pJLqUajp/OT0loR3xwqV3ZJ6jhHJLPxpNmaZvg== X-Forefront-Antispam-Report: CIP:146.108.200.10; CTRY:AT; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(2980300002)(1110001)(1109001)(339900001)(199003)(164054003)(52604005)(377424004)(189002)(377454003)(23756003)(2351001)(5001960100002)(106116001)(53416004)(105606002)(5008740100001)(189998001)(107886002)(104016004)(6806005)(5007970100001)(5004730100002)(81156007)(450100001)(106466001)(102836002)(110136002)(15975445007)(11100500001)(5003600100002)(19580395003)(33656002)(86362001)(46102003)(2900100001)(5890100001)(26826002)(2501003)(87936001)(2950100001)(85426001)(2920100001)(47776003)(69596002)(76176999)(50986999)(19580405001)(54356999)(92566002)(55846006)(64706001)(230783001)(66066001)(50466002); DIR:OUT; SFP:1102; SCL:1; SRVR:AM3PR06MB145; H:ATBRAGMSX01.itiso.net; FPR:; SPF:Fail; PTR:unknown.zgrp.net; A:1; MX:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; AM3PR06MB145; 2:ZYwFDzoGWK9SCqhoXF00NhF4wAWZaQQ9mZb+M9OxSWM7aMbpbWko7aaxKRQOoKzJLsFNWKzUhRpxdVTHmGhCn6tJjP1qSccdGSiONWhN5AYP7i+1ZLU8pYU1rOgn5i7b2Hu81VnI6ULm9LCLgsAazE4AV6CqFGx3ITWo7kQ3h/U=; 3:yNoW2hMwJv/jYT0rfT7GFK+DD9fiYVQfdchgFrNAPYAp+b0zoweScikEvnTq14pgQvaYmgn4P/xTCvqROZ6sO3wS9T04OVEkZKobt0MvUXDdnrkezz8FvtTlhwq38hHixa0xwx4kVvmI8KBvznK8vc/yIwlKzIAceDPAl9YMjMToFYvk+u43SzZ3PKl8eK/8WWtFe1WsaV7UsRxTvX8+jpMC5sP5GssGKXfzDG8zrqUwuW/gCS7Js8tMCAt5jkJ8; 25:ITh0ivR9qHv1n3zylvRLfEl+KvdMnb/NJBvPO/1wUYX3M+apmB9ag854pZQLjTuZtHclBHW1a8y9kKNSnY7gFp1uG6gR6NCcPYe31n0PleaGM8Z+WNUIw9/fqi4WTDP6/cOTpNkmVNjZVNcBSwBWb+kp6gf+Waaj8Ep7Lgc+ecKMHjAt1vXDYjyaUGaYCubBmoIjnLey7nr7ceZeQxWUR75BY6zCf5/JCPg+IBa9v5xfdhZTjhzhAaLo4453BTLqlERAMskaAG+DdUaUDjymUw== X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:AM3PR06MB145; X-Microsoft-Exchange-Diagnostics: 1; AM3PR06MB145; 20:IY7E0Wes55f3OHMSzv/eavJ5hCF5O3DnC8Xxnd8IztvYuPdL4k0wimqgMLZA8VXFK3eM9F2JhXNRAdTi28FKsGyMFhMGgFa5Ghl4WB6HLnrWJfd9dGZxfyKnr6CAYTloQPI8/pekYOmRENaszN9WYxQJRkq2HLl740rfL9lEyxd1ZZ/ElI0kCBYOsSoShL0wb68CPUZh81O12w0+XNnulrp7MN790iTi7MRTvzYmrtib+TVHfV92DYDgJKD25YokZAz265gLtIEFLuo5U0gKDBmqzIZ1ZPZQaqpgExwbd54RGmK2z2dMmN4fF4HemDs/orPvh3PMVqiRcyXp3phtofSUP/61/sMOtmgbBpKKRW2y6+xwcgNJzA53GE1g40AA7BgqIAxt9pO7Ge39cXFc/Vz3sblgcaD6Ca5aHYjEQYeSudLyqPEJLyn5BLLV1GGDuKk0RX7yFdaN3AzAMnjVPsQHN/jZYFWHuHZGL2a1dRCDZNFdREsNwVvrfLkhPWRj; 4:BzOSvipH0IFtEyzinq7AqB7gIY5EUtXIvS8IY0YE+MZYkd1nprrGv/AKJPFWJ8T8mzbdMoZYEjvMm0AtoibFngT8Fwn1EejArYl2Uuv3Y4EJmggXoG6caqgmPkJgqPNUO7CrpEqmKuoF4saKXQK7dqFzCqfVt4AhHjJYBeVbxAN5NAzDvxbbCT9phJdkKst4D8J0GOyVJWtaA+hPhJWQPdAEkThEoGHJUP5xYGUMoYW6i9oR9WwlKs1Ug9S3T5zyB68JZo+Qoie2GAqG0/RvAO5c/Ca87qC8c1HRlvBGanwNLcPt7RJGDQ9UGtP/BFyKnaK+CGf/PSSFEijMkmefl0OvPIM5JdBXpgFRx49je1M= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(520078)(5005006)(8121501046)(3002001); SRVR:AM3PR06MB145; BCL:0; PCL:0; RULEID:; SRVR:AM3PR06MB145; X-Forefront-PRVS: 0722981D2A X-Microsoft-Exchange-Diagnostics: =?iso-8859-1?Q?1; AM3PR06MB145; 23:EQyOqMX5b4VFZ346z7uV+xlOzCru1jNsUUmbmyBv?= =?iso-8859-1?Q?yQng8T/QgRiy9Al+gmEsuj8Vqme+1nq4NhQocUrvXvfH02MiVpP8lBiGNe?= =?iso-8859-1?Q?TLSFzZdUg/ge1B/mXbuGBlZpKOyKyY4pMG6/QfHoYXQj+4G5cJJQXtAxnF?= =?iso-8859-1?Q?eSiN1Dpoz2UIKx7E+gSR+2/G5OAojYTrhUXvxN17tMFIXCJubW+OXrusVL?= =?iso-8859-1?Q?KszubvdVs1oWLClhZGz6A5vimpz6N0P1cm7+3R+Mrifg8palfs+XgNwpjQ?= =?iso-8859-1?Q?+ohzfd0h5lTIM6Q+Ma3TbPSjpmIbv8IJVRt2flsOefmp4PfcmQro2G3oqA?= =?iso-8859-1?Q?YnfODrJZJ+jwxZrXQd53+IkpgK/ix82hfQHb4zwmvBRfspkB3fYSINkPlT?= =?iso-8859-1?Q?MgD79eYaFjB6bq9EK6duSjjMLcByAKKfbk/McV7OAFTGVbCI2Yp1K3QrjM?= =?iso-8859-1?Q?iuwZbAmaN68S44IIBYwUV7089sDDsvhqNBG7d2L+6pSvkCYgq4I/tsPvqU?= =?iso-8859-1?Q?ThX3o5fKsPyXbluSmGacZwTj32wykY2azoaKCsavuxMSoJU/mXo40pkc8s?= =?iso-8859-1?Q?wzjV/G34QG818tYOlNrlRvQI3Ff0VNNEftB0sfpEQf1fkVuTdK31SMpLyF?= =?iso-8859-1?Q?7SpZ055lCFceuXZ9T2AWgGdMOhrJYNK/GxEY0q+cPVmHGZ1U6jQ6n5EpML?= =?iso-8859-1?Q?t2Znmwx/C+LXhvu+MeZVyrnN+tHzWJQXADJxFpbtIWDDHmW3BRt9wwq9Qp?= =?iso-8859-1?Q?oh6Ju3xwY1P511nwgzCcajdLGGrlorotYI7P6HLgyJyXgDI9knpIX113m+?= =?iso-8859-1?Q?gGqlronF7Y869Oa+ErDjvH18mk/NHNgQGXi/aM4KDgt/onopLXS23Ln+Oj?= =?iso-8859-1?Q?GlIGGsaVxuS0j4G8EqYKTnfQkNGu4GyiWiz32i+wgDJlYqKFKTmSTSYAM1?= =?iso-8859-1?Q?dwYCBVZSkOlyOmxqqLLFN8DKaoqouq5B5tvWcD2dQsuMQCbheRQQx2Eawq?= =?iso-8859-1?Q?zbgR3TMYw80tV1y5gPSq8qU3EsfGMllQHS7mllgYi4MgL/OJZC7Iu4+wTb?= =?iso-8859-1?Q?LrxRX0mgFxOK73Rqg6KHw+D7F/dGL1lxQ4ZHRP0mdHq9hmPtIj2r2ewUt+?= =?iso-8859-1?Q?h1Yq8o64d4tUratGz4qDUxEr3TIJ2jP57NtkMW+sPZJ/3baL+igWskYFj6?= =?iso-8859-1?Q?JcaUZPwyc32a2+K0fc4UfT/tDTpBbiKePpfyzhTwbRma3oykl5xNUQyoV2?= =?iso-8859-1?Q?Ss3jxRjRPy0XM15SEsatkQwbUtH/s1FpLJy04AncV0vp/OtvMezGI8Sf2Q?= =?iso-8859-1?Q?jnivdq/ZR2OJtYql5Qowdvua0RU2iKkfqmln7ahPlNFr4MUWPw4t6jxlRt?= =?iso-8859-1?Q?n+HPOZS11LUJpIn1OcFMXi8CGrQhz9nIn+eL6puXKRYz7h40JS2JyGVG0o?= =?iso-8859-1?Q?JBL87AB9521lm7SpcQJvZHpyGFFjZcGSTEizGetMndcNc1kP9XJf1JbznL?= =?iso-8859-1?Q?xJfEgswigzFwVmPvv4SEG8g0NFezr0f1VWpFpr0N?= X-Microsoft-Exchange-Diagnostics: 1; AM3PR06MB145; 5:XdfEGImEjl2UTVTO+TaB6aH9TpOY5OF1hrbU2JPIzwLzhLZc5zOQEcyYKhRRXfCp1d5LluFEuMR/+iK1KTKHufbJi16Lbspfw/XmQVVnZyq6qjq/RZ/2x2YIqBZbcahuS84d+6aoaXOI0hFm4bl4CQ==; 24:m1nm4NfZ4Pw8DKP2j9jeXK8++Mi8g80qRXBBdldjls51gKwgjfjRqcrNz06UPwrIuV3Rns/TBuSvcp6TPU4N5AizjFB9Lyq4K2qNXZTBpjU=; 20:BXD48cRXc41vNNtG/Ac8KswGiaVQZ/OH4LeyN3k4qDsjgPFESSXiN5d3SJEEXfYEGRFe6MScIPOVaAvl5sUisg== SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: tridonic.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 07 Oct 2015 19:46:54.3170 (UTC) X-MS-Exchange-CrossTenant-Id: 8b206608-a593-4ace-a4b6-ef1fc83c9169 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=8b206608-a593-4ace-a4b6-ef1fc83c9169; Ip=[146.108.200.10]; Helo=[ATBRAGMSX01.itiso.net] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM3PR06MB145 Archived-At: Subject: Re: [Ace] I-D Action: draft-ietf-ace-usecases-08.txt X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Oct 2015 19:47:21 -0000 Hi Ludwig, Sandeep, thanks for including the changes in the Building Automation use case. I lik= e the way you have written building automation use case now and don't have = further review comments. Thanks, Abhinav ________________________________________ From: Ace [ace-bounces@ietf.org] on behalf of internet-drafts@ietf.org [int= ernet-drafts@ietf.org] Sent: Wednesday, October 07, 2015 4:47 PM To: i-d-announce@ietf.org Cc: ace@ietf.org Subject: [Ace] I-D Action: draft-ietf-ace-usecases-08.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Authentication and Authorization for Cons= trained Environments Working Group of the IETF. Title : ACE use cases Authors : Ludwig Seitz Stefanie Gerdes G=F6ran Selander Mehdi Mani Sandeep S. Kumar Filename : draft-ietf-ace-usecases-08.txt Pages : 29 Date : 2015-10-07 Abstract: Constrained devices are nodes with limited processing power, storage space and transmission capacities. These devices in many cases do not provide user interfaces and are often intended to interact without human intervention. This document includes a collection of representative use cases for authentication and authorization in constrained environments. These use cases aim at identifying authorization problems that arise during the lifecycle of a constrained device and are intended to provide a guideline for developing a comprehensive authentication and authorization solution for this class of scenarios. Where specific details are relevant, it is assumed that the devices use the Constrained Application Protocol (CoAP) as communication protocol, however most conclusions apply generally. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ace-usecases/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-ace-usecases-08 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ace-usecases-08 Please note that it may take a couple of minutes from the time of submissio= n 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/ _______________________________________________ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace ________________________________________________________ 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 Oct 7 12:52:36 2015 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D05A81B2FD2 for ; Wed, 7 Oct 2015 12:52:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.55 X-Spam-Level: X-Spam-Status: No, score=-1.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nopxvSu2QPjX for ; Wed, 7 Oct 2015 12:52:29 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8289E1B2FCF for ; Wed, 7 Oct 2015 12:52:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [134.102.201.11]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id t97JqPLH018123; Wed, 7 Oct 2015 21:52:25 +0200 (CEST) Received: from aung.tzi.org (eduroam-pool3-078.wlan.uni-bremen.de [134.102.232.78]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3nWRCF3zXlz4qBx; Wed, 7 Oct 2015 21:52:25 +0200 (CEST) From: Olaf Bergmann To: Hannes Tschofenig References: <56153D33.6010100@gmx.net> Date: Wed, 07 Oct 2015 21:52:25 +0200 In-Reply-To: <56153D33.6010100@gmx.net> (Hannes Tschofenig's message of "Wed, 7 Oct 2015 17:41:39 +0200") Message-ID: <87egh6a22u.fsf@aung.informatik.uni-bremen.de> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "Ace@ietf.org" Subject: Re: [Ace] Dynamically Connecting Smart Sports Equipment X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Oct 2015 19:52:33 -0000 Hannes Tschofenig writes: > After Sean provided his review comments I took a look at this scenario > again and I get more and more the impression that we should delete this > scenario since it is nothing that we do in ACE. > > My understanding of the scenario is that we are asking for a sort-of > multi-user operating system to be introduced for sports watches. No, we are trying to cover relevant authorization scenarios. Following your reasonig, we could also argue that ACE neither does ship containers nor install lighting in office buildings and therefore must throw out those scenarios as well. Gr=C3=BC=C3=9Fe Olaf From nobody Wed Oct 7 13:13:20 2015 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A46B31B3016; Wed, 7 Oct 2015 13:13:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oOOnhRw2ehLq; Wed, 7 Oct 2015 13:13:16 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 65DFB1B300F; Wed, 7 Oct 2015 13:13:16 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.4.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151007201316.8911.98554.idtracker@ietfa.amsl.com> Date: Wed, 07 Oct 2015 13:13:16 -0700 Archived-At: Cc: ace@ietf.org Subject: [Ace] I-D Action: draft-ietf-ace-usecases-09.txt X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Oct 2015 20:13:17 -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 Working Group of the IETF. Title : ACE use cases Authors : Ludwig Seitz Stefanie Gerdes Göran Selander Mehdi Mani Sandeep S. Kumar Filename : draft-ietf-ace-usecases-09.txt Pages : 29 Date : 2015-10-07 Abstract: Constrained devices are nodes with limited processing power, storage space and transmission capacities. These devices in many cases do not provide user interfaces and are often intended to interact without human intervention. This document includes a collection of representative use cases for authentication and authorization in constrained environments. These use cases aim at identifying authorization problems that arise during the lifecycle of a constrained device and are intended to provide a guideline for developing a comprehensive authentication and authorization solution for this class of scenarios. Where specific details are relevant, it is assumed that the devices use the Constrained Application Protocol (CoAP) as communication protocol, however most conclusions apply generally. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ace-usecases/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-ace-usecases-09 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ace-usecases-09 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 Wed Oct 7 13:22:46 2015 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E51E01B303D for ; Wed, 7 Oct 2015 13:22:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.55 X-Spam-Level: X-Spam-Status: No, score=-1.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id li2kb4jSW3iq for ; Wed, 7 Oct 2015 13:22:44 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C84391B3035 for ; Wed, 7 Oct 2015 13:22:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [134.102.201.11]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id t97KMdtl027060; Wed, 7 Oct 2015 22:22:39 +0200 (CEST) Received: from [IPv6:2001:638:708:30da:583e:9173:7d0a:2e04] (unknown [IPv6:2001:638:708:30da:583e:9173:7d0a:2e04]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3nWRt75Cmxz4pNc; Wed, 7 Oct 2015 22:22:39 +0200 (CEST) To: Hannes Tschofenig , "Ace@ietf.org" References: <56155927.30307@gmx.net> From: Stefanie Gerdes Message-ID: <56157F0F.7070907@tzi.de> Date: Wed, 7 Oct 2015 22:22:39 +0200 User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <56155927.30307@gmx.net> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Ace] ACE Use Case Draft: IPR Confirmation X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Oct 2015 20:22:45 -0000 Hi Hannes, no IPR known from my side. Thanks, Steffi On 10/07/2015 07:40 PM, Hannes Tschofenig wrote: > Hi Ludwig, Steffi, Mehdi, Goeran, Sandeep, > > I am working on the shepherd writeup for the use case document: > https://tools.ietf.org/html/draft-ietf-ace-usecases-08 > > One item in the template requires me to indicate whether each > document author has confirmed that any and all appropriate IPR > disclosures required for full conformance with the provisions of > BCP 78 and BCP 79 have already been filed. > > Could you please confirm? > > Ciao Hannes > > > > _______________________________________________ Ace mailing list > Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace > -- Stefanie Gerdes Tel: +49 421 218 63906 TZI Universitt Bremen E-Mail: gerdes@tzi.de Bibliothekstr. 1, MZH 5150 28359 Bremen, Germany From nobody Wed Oct 7 13:25:03 2015 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65B1B1B303D for ; Wed, 7 Oct 2015 13:25:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.55 X-Spam-Level: X-Spam-Status: No, score=-1.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ndtC94U90xMI for ; Wed, 7 Oct 2015 13:25:01 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DDC891B303B for ; Wed, 7 Oct 2015 13:25:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::b]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id t97KOu1O003311 for ; Wed, 7 Oct 2015 22:24:56 +0200 (CEST) Received: from [IPv6:2001:638:708:30da:583e:9173:7d0a:2e04] (unknown [IPv6:2001:638:708:30da:583e:9173:7d0a:2e04]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3nWRwm5ZPKz4pV6 for ; Wed, 7 Oct 2015 22:24:56 +0200 (CEST) References: <20151007201316.8911.18159.idtracker@ietfa.amsl.com> To: "Ace@ietf.org" From: Stefanie Gerdes X-Forwarded-Message-Id: <20151007201316.8911.18159.idtracker@ietfa.amsl.com> Message-ID: <56157F98.4020000@tzi.de> Date: Wed, 7 Oct 2015 22:24:56 +0200 User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <20151007201316.8911.18159.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Subject: [Ace] Fwd: New Version Notification for draft-ietf-ace-usecases-09.txt X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Oct 2015 20:25:02 -0000 Hi all, I submitted a new version of the draft with the privacy considerations that Hannes provided. Thank you, Hannes, for writing them up. Best regards, Steffi -------- Forwarded Message -------- Subject: New Version Notification for draft-ietf-ace-usecases-09.txt Date: Wed, 07 Oct 2015 13:13:16 -0700 From: internet-drafts@ietf.org To: Mehdi Mani , Sandeep Kumar , Sandeep S. Kumar , Ludwig Seitz , Goran Selander , Stefanie Gerdes , Stefanie Gerdes , Mehdi Mani , Ludwig Seitz , "Göran Selander" A new version of I-D, draft-ietf-ace-usecases-09.txt has been successfully submitted by Stefanie Gerdes and posted to the IETF repository. Name: draft-ietf-ace-usecases Revision: 09 Title: ACE use cases Document date: 2015-10-07 Group: ace Pages: 29 URL: https://www.ietf.org/internet-drafts/draft-ietf-ace-usecases-09.txt Status: https://datatracker.ietf.org/doc/draft-ietf-ace-usecases/ Htmlized: https://tools.ietf.org/html/draft-ietf-ace-usecases-09 Diff: https://www.ietf.org/rfcdiff?url2=draft-ietf-ace-usecases-09 Abstract: Constrained devices are nodes with limited processing power, storage space and transmission capacities. These devices in many cases do not provide user interfaces and are often intended to interact without human intervention. This document includes a collection of representative use cases for authentication and authorization in constrained environments. These use cases aim at identifying authorization problems that arise during the lifecycle of a constrained device and are intended to provide a guideline for developing a comprehensive authentication and authorization solution for this class of scenarios. Where specific details are relevant, it is assumed that the devices use the Constrained Application Protocol (CoAP) as communication protocol, however most conclusions apply generally. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat From nobody Wed Oct 7 13:27:01 2015 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 308621B3037 for ; Wed, 7 Oct 2015 13:26:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DIxImvpl8V9m for ; Wed, 7 Oct 2015 13:26:56 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (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 5021B1B2FFF for ; Wed, 7 Oct 2015 13:26:56 -0700 (PDT) Received: from [192.168.10.197] ([64.134.100.215]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0LyEUz-1adjYX4BnB-015ZCe; Wed, 07 Oct 2015 22:26:54 +0200 To: Olaf Bergmann References: <56153D33.6010100@gmx.net> <87egh6a22u.fsf@aung.informatik.uni-bremen.de> From: Hannes Tschofenig Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9 Message-ID: <56158006.1080506@gmx.net> Date: Wed, 7 Oct 2015 22:26:46 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <87egh6a22u.fsf@aung.informatik.uni-bremen.de> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="sPX9Spt5FbHwO6ufVM5ELGRcq1uG513QT" X-Provags-ID: V03:K0:cWmqEmDu9sMv4zYaaqD/Sx+DRshqp6GZIy0wpMKSDF2qdTJAQH4 c6OrzhogFB2Bjjo6u3FGzEOPdEhQDMCAVIGzRwxBgFSIgyoN0MySFZWmi/Bn8lsAPzFYyF9 xqt0QkKm9cfA0SSUIzS1hx/WpOUwmzyU/hf2z3mzVnJFsNQOikrAJ8D1/C0Q7zt5CiSR/L0 sTKjk9dBuH8tefVV2GAcw== X-UI-Out-Filterresults: notjunk:1;V01:K0:jvrn/HUHDJo=:n+N0AZq+CwbuWmAnnBtwr3 I6zPIP52URm9Zk5SHcYn1Zw2LRYt5FbWG7Vwd+jjrop6zRMwzBfwfyC19iikg2iI2u3Xle2gF fsMxRf+CP+jN6tHWXLJJImNgVVOB7ID8nHY/TVMmcNmzjex3/U31hB/D50jFE26IlactLS4Lg N4de44c8Jr9ZbAMM1DJoAZ7trCtvJ+eZXkdm6mZNVD5TVPmWczDGiwxfg0npAJ6TOku3LGT1M J238CIPXOVKQaeXQOxX+2Pj2wo3x316evz3nyfochHNXal9JTDlRQvNlmev7QT6QmyoDte5Su T/3717RkY//3lKpda4VHyDOyGWDau722R+7iNTVVaFbHtxRn8MSQhyuz/xsezlK/yhFZMZkge 3i3ZRqnlVh9I7iPOzTjnwbX6YVFcVlwZtnF5NqaBCX5UPuZN89eqIkES4aiLZB5Irr0xiuHje vbAu8aPdBiSlEc2knTVaUzhMbCDUoKHwgdfHCivQ32dKEwDlqhLgS7MJkt1qqC8r+5o3jkH1i nLTlMkJL8SA1fyPIVhNAdfn5OMlgyaZZW7nzE/qcUZxH+hZNkYs7leeUd99cEu5m2Rneebviw qUZUhpMBnAiCRiM8y2GgpDqLTd/AJaXfS/yJcn/ABgIjGQAIDqA+LXD0PPA4aS2N+j1TOfWNn UbUmmoWcNNctb0jU0xs08P4h/iztUzFIJkMFQWduFna+O0SX56yDy4m+wUodMGxgmCmpb4tRN y+sa9dvJbaIpZ6IfzI4Q7r3ANBSDkJ3Djwzla+XMpdS8C8LwOuzyg8vWOdQ= Archived-At: Cc: "Ace@ietf.org" Subject: Re: [Ace] Dynamically Connecting Smart Sports Equipment X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Oct 2015 20:26:58 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --sPX9Spt5FbHwO6ufVM5ELGRcq1uG513QT Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Olaf, I believe you misunderstand the comment. Unless I fail to understand the description of the scenario but it seems that what is being asked for is a wearable (sports watch) that supports multiple users on the same device. Alice gives his watch his friend Bob but does not want Bob to see the training data she previously collected and stored on the device. How does this relate to ACE? Ciao Hannes On 10/07/2015 09:52 PM, Olaf Bergmann wrote: > Hannes Tschofenig writes: >=20 >> After Sean provided his review comments I took a look at this scenario= >> again and I get more and more the impression that we should delete thi= s >> scenario since it is nothing that we do in ACE. >> >> My understanding of the scenario is that we are asking for a sort-of >> multi-user operating system to be introduced for sports watches. >=20 > No, we are trying to cover relevant authorization scenarios. Following > your reasonig, we could also argue that ACE neither does ship container= s > nor install lighting in office buildings and therefore must throw out > those scenarios as well. >=20 > Gr=C3=BC=C3=9Fe > Olaf >=20 > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace >=20 --sPX9Spt5FbHwO6ufVM5ELGRcq1uG513QT Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJWFYAHAAoJEGhJURNOOiAtkX0H/1l7FKodGlY+WQWRaa5Q+LXg 4wkpPH/50EoHaiXD6jyJeHCBIUIWyIh158xofkQo8i17Uz3XTQre9LDCPz0zcDYJ nTRwUEuxPSffNPKTvhJloBrN3C8sROwKbuhS44tA0CJ6ctVnImxXn3HCnaMG/Gs5 EXb/Zm/8BikU2X1A1DkYHW5rijrI6Hm4PhkuVb5CLXsETZtWZxd/xgT+T4WRlRa3 BXe2Xybn7x/4OgtBU1wJxujeB6FPsPdXDLE9NK+6diD/nZbtUyEgiPwXHqOf7Twt 7VIHlVVjTwNldAcq6K4PjOo/fBy0ARtAKFx6ndjGNatpJryr4cQ5NPC6qdWl1qk= =AzA2 -----END PGP SIGNATURE----- --sPX9Spt5FbHwO6ufVM5ELGRcq1uG513QT-- From nobody Wed Oct 7 13:30:36 2015 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD7111B304D for ; Wed, 7 Oct 2015 13:30:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1X9NKEICHCgL for ; Wed, 7 Oct 2015 13:30:34 -0700 (PDT) Received: from mail-wi0-f170.google.com (mail-wi0-f170.google.com [209.85.212.170]) (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 DEDE31B3054 for ; Wed, 7 Oct 2015 13:30:27 -0700 (PDT) Received: by wicge5 with SMTP id ge5so229827127wic.0 for ; Wed, 07 Oct 2015 13:30:26 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:subject:message-id:from:to:mime-version :content-type:content-transfer-encoding; bh=l2AAUS2A8DBkDACFQE6FyUg+WZNfdXDAJzgjvKuU8CM=; b=PjQBz4Kn9iwjpsdd0DP/FF/8nRAIUkxjC+mobwGdUYdNrp0MNC8Lery47bphAF3p46 DrpDsw5gC8IGT/bz4SAu3vbgpyqa1f+XeA1fyTe4o8cTtBVCxE3yVGDzaxYtJMJFvKKv YB2VM5VaPFwiOI4q5BArULrMgNAN+P4HeAYBjSlmvDbJb4ymhfWW1Ta3UqpOmyY7MhBF Z087pFXRq5/jtANn1qFxyi1p5FHXs5Q+y0kCtKz2C8GJ0HvM4wNVaqrGawbiQjw25psv O2nIXY23Xg5fKYfabejYZz7DYTv8X8haVLTiSeUdXqttc2tiFzK7wyoCGMS1SwGhopdu dFhg== X-Gm-Message-State: ALoCoQnPHwBfW75CsTts8nGwBDbqGtRlQciZsZ8ifbMauSzKLf8hBh11AFLv2nAvltThpFBoj5qL X-Received: by 10.194.134.197 with SMTP id pm5mr3412421wjb.118.1444249826146; Wed, 07 Oct 2015 13:30:26 -0700 (PDT) Received: from localhost (dslb-084-060-043-156.084.060.pools.vodafone-ip.de. [84.60.43.156]) by smtp.gmail.com with ESMTPSA id gc8sm4108097wib.2.2015.10.07.13.30.25 (version=TLSv1 cipher=RC4-SHA bits=128/128); Wed, 07 Oct 2015 13:30:25 -0700 (PDT) Date: Wed, 07 Oct 2015 22:30:22 +0200 Message-ID: <8o4og929ahfpdxc5lpohlhy0.1444249822792@email.android.com> From: Ludwig Seitz To: Hannes Tschofenig , "Ace@ietf.org" MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 Archived-At: Subject: Re: [Ace] ACE Use Case Draft: IPR Confirmation X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Oct 2015 20:30:36 -0000 Tm8gSVBSIGRpc2Nsb3N1cmVzIGZyb20gbWUuIC9MdWR3aWcKClNlbnQgZnJvbSBteSBwaG9uZQoK SGFubmVzIFRzY2hvZmVuaWcgPGhhbm5lcy50c2Nob2ZlbmlnQGdteC5uZXQ+IHdyb3RlOgoKPkhp IEx1ZHdpZywgU3RlZmZpLCBNZWhkaSwgR29lcmFuLCBTYW5kZWVwLAo+Cj5JIGFtIHdvcmtpbmcg b24gdGhlIHNoZXBoZXJkIHdyaXRldXAgZm9yIHRoZSB1c2UgY2FzZSBkb2N1bWVudDoKPmh0dHBz Oi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWFjZS11c2VjYXNlcy0wOAo+Cj5PbmUg aXRlbSBpbiB0aGUgdGVtcGxhdGUgcmVxdWlyZXMgbWUgdG8gaW5kaWNhdGUgd2hldGhlciBlYWNo IGRvY3VtZW50Cj5hdXRob3IgaGFzIGNvbmZpcm1lZCB0aGF0IGFueSBhbmQgYWxsIGFwcHJvcHJp YXRlIElQUiBkaXNjbG9zdXJlcwo+cmVxdWlyZWQgZm9yIGZ1bGwgY29uZm9ybWFuY2Ugd2l0aCB0 aGUgcHJvdmlzaW9ucyBvZiBCQ1AgNzgKPmFuZCBCQ1AgNzkgaGF2ZSBhbHJlYWR5IGJlZW4gZmls ZWQuCj4KPkNvdWxkIHlvdSBwbGVhc2UgY29uZmlybT8KPgo+Q2lhbwo+SGFubmVzCj4KPgo+X19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KPkFjZSBtYWlsaW5n IGxpc3QKPkFjZUBpZXRmLm9yZwo+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9hY2UK From nobody Wed Oct 7 13:35:07 2015 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32E321B3054 for ; Wed, 7 Oct 2015 13:35:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.55 X-Spam-Level: X-Spam-Status: No, score=-1.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BE87w8OysRxE for ; Wed, 7 Oct 2015 13:35:04 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 549681B3051 for ; Wed, 7 Oct 2015 13:35:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::b]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id t97KZ0tC026358; Wed, 7 Oct 2015 22:35:00 +0200 (CEST) Received: from nar.local (p5DC7F6AE.dip0.t-ipconnect.de [93.199.246.174]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3nWS8N2Blrz4q2G; Wed, 7 Oct 2015 22:35:00 +0200 (CEST) Message-ID: <561581F2.3060505@tzi.org> Date: Wed, 07 Oct 2015 22:34:58 +0200 From: Carsten Bormann User-Agent: Postbox 4.0.5 (Macintosh/20150923) MIME-Version: 1.0 To: Hannes Tschofenig References: <56153D33.6010100@gmx.net> <87egh6a22u.fsf@aung.informatik.uni-bremen.de> <56158006.1080506@gmx.net> In-Reply-To: <56158006.1080506@gmx.net> X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: Olaf Bergmann , "Ace@ietf.org" Subject: Re: [Ace] Dynamically Connecting Smart Sports Equipment X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Oct 2015 20:35:05 -0000 It is a simple example of ownership and multiple stakeholders. It would be nice to have more of those, but maybe we want to put a lid on what we have. Grüße, Carsten Hannes Tschofenig wrote: > How does this relate to ACE? From nobody Wed Oct 7 14:29:08 2015 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AF9F1B311A for ; Wed, 7 Oct 2015 14:29:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IujGVSuxyAE8 for ; Wed, 7 Oct 2015 14:28:55 -0700 (PDT) Received: from mail-qk0-x232.google.com (mail-qk0-x232.google.com [IPv6:2607:f8b0:400d:c09::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 271821B3113 for ; Wed, 7 Oct 2015 14:28:55 -0700 (PDT) Received: by qkdo1 with SMTP id o1so2460798qkd.1 for ; Wed, 07 Oct 2015 14:28:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:mime-version:subject:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=FKjvABfU33METQ9e/EJq9OLZA7uw/TjrRB1QbmskUWU=; b=0HjGn54SoAZ0iB4MJdsMEij9nJMBzhHVgswhqk1N6EluujK5Ze7MBsFEBz+9oQ3prk qi6uNSay4+6DZEzWYZHEu09yjLsey1XaFx8xZT80TDSu/6uRGqRLuSNw5l2hEhpI3ODv mQOj8CtaQZbkIbVfm0cMZQtJJtHIo4c5h5aDmeYHFBaRTOIUQ23l6pnDKYQv8Sf/CnGw m3Xvk3+0Iw8h+1zYatrpcYDw5zFynFWW5vdcyg7Lqtwrec0fHyM34MxYs/GXX7YsVwAM hIF1F6bSSoCqY7oEWedldxXl/glszXTYsfdbgY0pXPzFzPkA2T7M9RRSOOoosOKynfkk X9jw== X-Received: by 10.55.192.81 with SMTP id o78mr4139978qki.97.1444253334237; Wed, 07 Oct 2015 14:28:54 -0700 (PDT) Received: from [192.168.1.14] (pool-96-233-21-91.bstnma.east.verizon.net. [96.233.21.91]) by smtp.gmail.com with ESMTPSA id f1sm16983218qhe.42.2015.10.07.14.28.51 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 07 Oct 2015 14:28:52 -0700 (PDT) From: Kathleen Moriarty X-Google-Original-From: Kathleen Moriarty Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) X-Mailer: iPhone Mail (12H143) In-Reply-To: <561581F2.3060505@tzi.org> Date: Wed, 7 Oct 2015 17:28:50 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <23191A62-445C-448B-8D0A-5E05282C15B0@gmail.com> References: <56153D33.6010100@gmx.net> <87egh6a22u.fsf@aung.informatik.uni-bremen.de> <56158006.1080506@gmx.net> <561581F2.3060505@tzi.org> To: Carsten Bormann Archived-At: Cc: Hannes Tschofenig , Olaf Bergmann , "Ace@ietf.org" Subject: Re: [Ace] Dynamically Connecting Smart Sports Equipment X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Oct 2015 21:29:00 -0000 The lighting example is similar in that manner - multiple users with separat= e zones that they may be authorized to access. The difference is scale and i= mplementation. Kathleen=20 Sent from my iPhone > On Oct 7, 2015, at 4:34 PM, Carsten Bormann wrote: >=20 > It is a simple example of ownership and multiple stakeholders. >=20 > It would be nice to have more of those, but maybe we want to put a lid > on what we have. >=20 > Gr=C3=BC=C3=9Fe, Carsten >=20 >=20 > Hannes Tschofenig wrote: >> How does this relate to ACE? >=20 > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace From nobody Wed Oct 7 14:39:59 2015 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD1D91B3134 for ; Wed, 7 Oct 2015 14:39:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DO6ate_YrKlW for ; Wed, 7 Oct 2015 14:39:56 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (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 3B32E1B3132 for ; Wed, 7 Oct 2015 14:39:56 -0700 (PDT) Received: from [192.168.10.197] ([70.88.231.185]) by mail.gmx.com (mrgmx002) with ESMTPSA (Nemesis) id 0Lg0sd-1aPu5i3U5b-00pbi3; Wed, 07 Oct 2015 23:39:46 +0200 To: Kathleen Moriarty , Carsten Bormann References: <56153D33.6010100@gmx.net> <87egh6a22u.fsf@aung.informatik.uni-bremen.de> <56158006.1080506@gmx.net> <561581F2.3060505@tzi.org> <23191A62-445C-448B-8D0A-5E05282C15B0@gmail.com> From: Hannes Tschofenig Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9 Message-ID: <5615911F.8000905@gmx.net> Date: Wed, 7 Oct 2015 23:39:43 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <23191A62-445C-448B-8D0A-5E05282C15B0@gmail.com> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="tRokusnBjwPX6gSdoXecQWxlEs5H7WnEV" X-Provags-ID: V03:K0:DErAxrWfiUMLNQ9dcGRxXaepYqGer7XsmiAdZRjn8URAyLYDJMO yTSziJnx+Gtuv5xi9MPtWDC4yrllTNG4rDpsiFTmTLVrGRMl46OTVGMLFUQcrADqJxjnKOa CDcndM+oS7SyZSsa+ND31BlcdrWb5ThO+FwhpewapBcuf1R8LR8CGEOQSebjqM7eOWlhYVC Uj6uspCi0qGEoDco1bm2g== X-UI-Out-Filterresults: notjunk:1;V01:K0:lDrNgn7hwU4=:U3E2rrTWMEIFHwromkHrN2 mGUGtYJmbxEgiwlv+UWNdaJD7ES35MNTLrrfcLrlvApqHRsc3i8Kz1BamjFXbaUVhaLgWtmDr dZaMB4Gnyvvs02Ye2ZoM/YDKI7haHC00OoPNzpOmD/ZCR5pCreyztSb5WZc9TQlRbk6WpKxlk AC+3lSRCMo6pOjic5WDlP6cpiOQcGzhZYxTmZDNEWNr5G+rd8nbGBIgOAHbZtadLqcjUI3RUS 1U92MfVpMXoIvupQ6Xts/Vsz9yWuameNB1USdNRU0s7q2arwlV8zjvrjnAg01Q3fpvdBCW2+4 7T9yLX1/RZZPlkjcaJTR6Sltwt54zPwRRbi9ZdDmieKk65CjlxkTVkgMg/OrwNrayEfAZqoat zaz1yzRODtmIA4K2vO7/xmZD7PCyWXzgwEbuixgHbhsPqobNAZ1ojIlT8rnlS4ooCDaVNxipk IA/ApHjgvS8aEdGPpasBgLuNCeO3ijY5M3/lwAf0BaZ5vNhtt166/W0ULCKD1VpNteipW3krN XcxOW/1HrwxHBjcD5h5zfVvOJzaTa8McHr2A0ERV8ltp0SbO/u5Nd5IDVLrJwXyedheD5JB2y EQd0EdpLavq9+FcYg8bbfjLGswKzxDhRwQ3Zyl6AcQAseca3UlmD+QRLwhj8TLdrqBy4EN76O fWKB2oHY5v3V/emvAMuQh2F7e7pXIFWyvdsuBdB7ny5BDapaveYEB9o4b7W2Fv6V8Bv0VTwSZ +1fHYn8Oe3cn1XqriYGPl+LflMliiaZPs++neyLN69vy+cp084wro2UbKtU= Archived-At: Cc: Olaf Bergmann , "Ace@ietf.org" Subject: Re: [Ace] Dynamically Connecting Smart Sports Equipment X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Oct 2015 21:39:57 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --tRokusnBjwPX6gSdoXecQWxlEs5H7WnEV Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable I am not sure about that. I have looked into lighting at some level of detail and there the problem is that devices like light switches, phones, etc. are trying to change the configuration of other devices, such as luminaries. The sports watch scenario, if I understand it correctly, is about us two using one watch but with the desire to keep our recorded date on the watch separate. I don't want you to see my running data and you don't want me to see your swimming data stored on the same watch. On 10/07/2015 11:28 PM, Kathleen Moriarty wrote: > The lighting example is similar in that manner - multiple users with se= parate zones that they may be authorized to access. The difference is sc= ale and implementation. --tRokusnBjwPX6gSdoXecQWxlEs5H7WnEV Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJWFZEfAAoJEGhJURNOOiAt9nkH/31LvmOvYIduYfyZtZdgRFP3 73c8cINxLCF9Tre/vsOWn5jKHGTyAWIRpr7wUNE5zkotrZn7Swe1vqMkus7uupDq ckbhd1isP50kFP7KyZqTbkD97aGCyHPFnmFwRt72kLbP7sqf7akvOJk+OdTMNtux 0IYpYKMdD8WIf7dfwCVbRBTaAXzOB1QZBTGxtWdIRg6BIYZDm0fEJG4gbdvZL6ns nKuu/7rubX0nbrILPxeMuRipnPO9nFgbE+NEsE7mDF1w6/kJ2xVbzozyij54yMJT Cs5/raAURwimso+VoS767dYAASIcV9+CcE/OQnDLiWXwqn2jMh0H3WE/fW+IpJc= =hOmw -----END PGP SIGNATURE----- --tRokusnBjwPX6gSdoXecQWxlEs5H7WnEV-- From nobody Wed Oct 7 14:46:58 2015 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C84E11A1A6A for ; Wed, 7 Oct 2015 14:46:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.55 X-Spam-Level: X-Spam-Status: No, score=-1.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XNeBYYaxHVls for ; Wed, 7 Oct 2015 14:46:56 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DE6C61A1A11 for ; Wed, 7 Oct 2015 14:46:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [134.102.201.11]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id t97LkoAG008392; Wed, 7 Oct 2015 23:46:50 +0200 (CEST) Received: from nar.local (p5DC7F6AE.dip0.t-ipconnect.de [93.199.246.174]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3nWTlF5n76z4qBG; Wed, 7 Oct 2015 23:46:46 +0200 (CEST) Message-ID: <561592C5.7060306@tzi.org> Date: Wed, 07 Oct 2015 23:46:45 +0200 From: Carsten Bormann User-Agent: Postbox 4.0.5 (Macintosh/20150923) MIME-Version: 1.0 To: Hannes Tschofenig References: <56153D33.6010100@gmx.net> <87egh6a22u.fsf@aung.informatik.uni-bremen.de> <56158006.1080506@gmx.net> <561581F2.3060505@tzi.org> <23191A62-445C-448B-8D0A-5E05282C15B0@gmail.com> <5615911F.8000905@gmx.net> In-Reply-To: <5615911F.8000905@gmx.net> X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: Kathleen Moriarty , Olaf Bergmann , "Ace@ietf.org" Subject: Re: [Ace] Dynamically Connecting Smart Sports Equipment X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Oct 2015 21:46:56 -0000 Hannes Tschofenig wrote: > I don't want you to see my running data and you don't > want me to see your swimming data stored on the same watch. I don't want you to see my birthday surprise lighting scenarios and you don't want me to see your exorbitant accumulated usage. Grüße, Carsten From nobody Wed Oct 7 14:49:17 2015 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6A0A1A1B76 for ; Wed, 7 Oct 2015 14:49:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nr3l4R2auE0A for ; Wed, 7 Oct 2015 14:49:15 -0700 (PDT) Received: from mail-qg0-x229.google.com (mail-qg0-x229.google.com [IPv6:2607:f8b0:400d:c04::229]) (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 E9ACC1A1A77 for ; Wed, 7 Oct 2015 14:49:14 -0700 (PDT) Received: by qgez77 with SMTP id z77so27063223qge.1 for ; Wed, 07 Oct 2015 14:49:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:mime-version:subject:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=ELVa0o/VDl3iuKzs2j2ShqG2WoImkTyZqMmwUgRSQnA=; b=TsLVyon6YUEy8ZZq2GeSDdGfUB/GYRL/r5W8UN4DZY8J61seaQT7kHDXMA22hBzcgQ I+w9XVh9yXP9hEjG/pK9dexlL/LOoy+ZfDf5NtcQfA6h9WmTs3+VhXLde6IWu9meOR8G RXjhYKONd+ZZUxbpcFnZU2Gd5ZqFKZelRVvvGArCtnyD0NrPiRULTWs8AGvZa/iykiJf K1WhF7OI8XkO9D2ruuiyeMcvXBp5xvPzI0jQv2ZYHWWqyfP3xYP48nIU+BZJ0WyhKVe+ fL3c1sd5zv/XDCiMteUT+jyqXxopjNOlSSFrnLAM5uCaZ1uyH1vW+8yujj8DgXue0rl5 lZAg== X-Received: by 10.140.150.78 with SMTP id 75mr4628973qhw.11.1444254554135; Wed, 07 Oct 2015 14:49:14 -0700 (PDT) Received: from [192.168.1.14] (pool-96-233-21-91.bstnma.east.verizon.net. [96.233.21.91]) by smtp.gmail.com with ESMTPSA id o65sm17028944qhb.21.2015.10.07.14.49.08 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 07 Oct 2015 14:49:12 -0700 (PDT) From: Kathleen Moriarty X-Google-Original-From: Kathleen Moriarty Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) X-Mailer: iPhone Mail (12H143) In-Reply-To: <5615911F.8000905@gmx.net> Date: Wed, 7 Oct 2015 17:49:07 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <0FBD373E-15DE-4FA1-AD09-66091685A1F0@gmail.com> References: <56153D33.6010100@gmx.net> <87egh6a22u.fsf@aung.informatik.uni-bremen.de> <56158006.1080506@gmx.net> <561581F2.3060505@tzi.org> <23191A62-445C-448B-8D0A-5E05282C15B0@gmail.com> <5615911F.8000905@gmx.net> To: Hannes Tschofenig Archived-At: Cc: Carsten Bormann , Olaf Bergmann , "Ace@ietf.org" Subject: Re: [Ace] Dynamically Connecting Smart Sports Equipment X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Oct 2015 21:49:16 -0000 Sent from my iPhone > On Oct 7, 2015, at 5:39 PM, Hannes Tschofenig w= rote: >=20 > I am not sure about that. I have looked into lighting at some level of > detail and there the problem is that devices like light switches, > phones, etc. are trying to change the configuration of other devices, > such as luminaries. >=20 > The sports watch scenario, if I understand it correctly, is about us two > using one watch but with the desire to keep our recorded date on the > watch separate. I don't want you to see my running data and you don't > want me to see your swimming data stored on the same watch. >=20 >=20 I was thinking you and I might work for different companies in the same buil= ding and have access just got the lighting in our own space. This is in tha= t use case. So there is the concept of separate authorization zones on that= use case as well - just on a completely different scale. Kathleen=20 >=20 >> On 10/07/2015 11:28 PM, Kathleen Moriarty wrote: >> The lighting example is similar in that manner - multiple users with sepa= rate zones that they may be authorized to access. The difference is scale a= nd implementation. >=20 From nobody Thu Oct 8 00:01:38 2015 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C3A51B322F for ; Thu, 8 Oct 2015 00:01:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.901 X-Spam-Level: X-Spam-Status: No, score=-3.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nagoLLgBtrAJ for ; Thu, 8 Oct 2015 00:01:34 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 254131B322E for ; Thu, 8 Oct 2015 00:01:32 -0700 (PDT) X-AuditID: c1b4fb25-f79a26d00000149a-29-561614cad8c4 Received: from ESESSHC002.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 8B.C5.05274.AC416165; Thu, 8 Oct 2015 09:01:31 +0200 (CEST) Received: from ESESSMB303.ericsson.se ([169.254.3.99]) by ESESSHC002.ericsson.se ([153.88.183.24]) with mapi id 14.03.0248.002; Thu, 8 Oct 2015 09:01:30 +0200 From: =?utf-8?B?R8O2cmFuIFNlbGFuZGVy?= To: Hannes Tschofenig Thread-Topic: [Ace] ACE Use Case Draft: IPR Confirmation Thread-Index: AQHRAT79an1d1ikXyUa1ETs7t24b6J5hK9AA Date: Thu, 8 Oct 2015 07:01:29 +0000 Message-ID: References: <8o4og929ahfpdxc5lpohlhy0.1444249822792@email.android.com> In-Reply-To: <8o4og929ahfpdxc5lpohlhy0.1444249822792@email.android.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.7.141117 x-originating-ip: [153.88.183.149] Content-Type: text/plain; charset="utf-8" Content-ID: <768E5E0AA6001F419E539BB967942603@ericsson.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupjkeLIzCtJLcpLzFFi42KZGfG3Rve0iFiYwdEJnBbfv/UwWyzdeY/V gclj8ab9bB5LlvxkCmCK4rJJSc3JLEst0rdL4MpYuPcOY8E6rorWD8dYGhh7uLoYOTkkBEwk rk98xAJhi0lcuLeerYuRi0NI4CijxO7dZ1kgnEWMEv+7m1lBqtgEXCQeNDxiArFFBAwlrs+c DhZnFlCU2D3rLDuILSxgLrGppY0ZosZC4kvPRDYI20iiv3s9WD2LgIrEuT1HwebwAtXcfH8d yOYAWuYm0f4vCsTkFHCXaPjMD1LBCHTb91NrmCA2iUvcejKfCeJmAYkle84zQ9iiEi8f/wOb LiqgJ7HyehMbRFxJYu3h7SwgI5kFNCXW79KHGGMt8WXiXDaY46d0P2SHOEZQ4uTMJywTGCVm Idk2C6F7FpLuWUi6ZyHpXsDIuopRtDi1OCk33chYL7UoM7m4OD9PLy+1ZBMjMAIPbvmtuoPx 8hvHQ4wCHIxKPLwJLiJhQqyJZcWVuYcYpTlYlMR5m5kehAoJpCeWpGanphakFsUXleakFh9i ZOLglGpgtOUrjJvgvPla2FnBP7ofV+08W/SC3fbWV+9Yhxs8J283SH6P6y4pynLmdjn/RnCZ zOb/Wx8ohq5axzalov7LpoPqs1g6K446XnfadSpbarXB42m2FydZRCVKK2zJV+2d89oxhTfc 3XZSkFr2/p1bSj+ffJY1788ZQx0Zv9l3rx5lZVGVtt03V4mlOCPRUIu5qDgRAPVUQj6hAgAA Archived-At: Cc: "Ace@ietf.org" Subject: Re: [Ace] ACE Use Case Draft: IPR Confirmation X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 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, 08 Oct 2015 07:01:36 -0000 Tm9uZSBmcm9tIG1lIGVpdGhlci4NCg0KR8O2cmFuDQoNCk9uIDIwMTUtMTAtMDcgMjI6MzAsICJM dWR3aWcgU2VpdHoiIDxsdWR3aWdAc2ljcy5zZT4gd3JvdGU6DQoNCj5ObyBJUFIgZGlzY2xvc3Vy ZXMgZnJvbSBtZS4gL0x1ZHdpZw0KPg0KPlNlbnQgZnJvbSBteSBwaG9uZQ0KPg0KPkhhbm5lcyBU c2Nob2ZlbmlnIDxoYW5uZXMudHNjaG9mZW5pZ0BnbXgubmV0PiB3cm90ZToNCj4NCj4+SGkgTHVk d2lnLCBTdGVmZmksIE1laGRpLCBHb2VyYW4sIFNhbmRlZXAsDQo+Pg0KPj5JIGFtIHdvcmtpbmcg b24gdGhlIHNoZXBoZXJkIHdyaXRldXAgZm9yIHRoZSB1c2UgY2FzZSBkb2N1bWVudDoNCj4+aHR0 cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtYWNlLXVzZWNhc2VzLTA4DQo+Pg0K Pj5PbmUgaXRlbSBpbiB0aGUgdGVtcGxhdGUgcmVxdWlyZXMgbWUgdG8gaW5kaWNhdGUgd2hldGhl ciBlYWNoIGRvY3VtZW50DQo+PmF1dGhvciBoYXMgY29uZmlybWVkIHRoYXQgYW55IGFuZCBhbGwg YXBwcm9wcmlhdGUgSVBSIGRpc2Nsb3N1cmVzDQo+PnJlcXVpcmVkIGZvciBmdWxsIGNvbmZvcm1h bmNlIHdpdGggdGhlIHByb3Zpc2lvbnMgb2YgQkNQIDc4DQo+PmFuZCBCQ1AgNzkgaGF2ZSBhbHJl YWR5IGJlZW4gZmlsZWQuDQo+Pg0KPj5Db3VsZCB5b3UgcGxlYXNlIGNvbmZpcm0/DQo+Pg0KPj5D aWFvDQo+Pkhhbm5lcw0KPj4NCj4+DQo+Pl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQo+PkFjZSBtYWlsaW5nIGxpc3QNCj4+QWNlQGlldGYub3JnDQo+Pmh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vYWNlDQo+X19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj5BY2UgbWFpbGluZyBsaXN0DQo+QWNl QGlldGYub3JnDQo+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9hY2UNCg0K From nobody Thu Oct 8 00:41:44 2015 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A73A1B327B for ; Thu, 8 Oct 2015 00:41:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dj5pAiwY84HG for ; Thu, 8 Oct 2015 00:41:41 -0700 (PDT) Received: from emea01-db3-obe.outbound.protection.outlook.com (mail-db3on0793.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe04::793]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0190F1B3279 for ; Thu, 8 Oct 2015 00:41:40 -0700 (PDT) Received: from AM3PR04CA0043.eurprd04.prod.outlook.com (10.242.16.43) by DB3PR04MB217.eurprd04.prod.outlook.com (10.242.130.18) with Microsoft SMTP Server (TLS) id 15.1.286.20; Thu, 8 Oct 2015 07:41:19 +0000 Received: from DB3FFO11FD025.protection.gbl (2a01:111:f400:7e04::175) by AM3PR04CA0043.outlook.office365.com (2a01:111:e400:8814::43) with Microsoft SMTP Server (TLS) id 15.1.293.16 via Frontend Transport; Thu, 8 Oct 2015 07:41:19 +0000 Authentication-Results: spf=none (sender IP is 23.103.247.180) smtp.mailfrom=philips.com; gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=philips.com; Received-SPF: None (protection.outlook.com: philips.com does not designate permitted sender hosts) Received: from 011-smtp-out.Philips.com (23.103.247.180) by DB3FFO11FD025.mail.protection.outlook.com (10.47.217.56) with Microsoft SMTP Server (TLS) id 15.1.293.9 via Frontend Transport; Thu, 8 Oct 2015 07:41:18 +0000 Received: from DB5PR9001MB0167.MGDPHG.emi.philips.com (141.251.190.211) by DB5PR9001MB0166.MGDPHG.emi.philips.com (141.251.190.210) with Microsoft SMTP Server (TLS) id 15.1.286.20; Thu, 8 Oct 2015 07:41:12 +0000 Received: from DB5PR9001MB0167.MGDPHG.emi.philips.com ([141.251.190.211]) by DB5PR9001MB0167.MGDPHG.emi.philips.com ([141.251.190.211]) with mapi id 15.01.0286.019; Thu, 8 Oct 2015 07:41:12 +0000 From: "Kumar, Sandeep" To: Kathleen Moriarty , Carsten Bormann Thread-Topic: [Ace] Dynamically Connecting Smart Sports Equipment Thread-Index: AQHRARbBxdoh1U5AiEOnwFBuun4KVJ5gcUdOgAAJhACAAAJLAIAADwwAgAClYsA= Date: Thu, 8 Oct 2015 07:41:12 +0000 Message-ID: References: <56153D33.6010100@gmx.net> <87egh6a22u.fsf@aung.informatik.uni-bremen.de> <56158006.1080506@gmx.net> <561581F2.3060505@tzi.org> <23191A62-445C-448B-8D0A-5E05282C15B0@gmail.com> In-Reply-To: <23191A62-445C-448B-8D0A-5E05282C15B0@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [194.171.252.100] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Microsoft-Exchange-Diagnostics: 1; DB3FFO11FD025; 1:dPqENRyhN7l1yUS5qDKz+LWllhia4Ag9afCCgYoPOgQpbDAO2I9DqKXSPzHnlAe5ifbgwKv6NpzhWxxTbpC3grZxwB4IPP8reyASVKEom6XjjgTPF7RFitRAn3zczcmwR6NUtLp/guyOMdU6/3e70LCSRwfyJbKUloXxHIWyxEU5zl4XoNGHhITp1QmO+saS3hXqGX0lX0V+3nI4hNSxxPiX2lp0B2VkJWMNRYhIrTUwHSwHfUv8F5d48rKn+fIp4E8b2apHpar2QahJJ2FzQoXbprpa621KubI7IXc5DWeDpo9tyvQwHnCj8qa1Gy8Ndy/b8/4n0Od4Vxh9iwicllD7g+qipj2ZhCYB/pJjIhA= X-Forefront-Antispam-Report: CIP:23.103.247.180; CTRY:; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(2980300002)(428002)(189002)(85714005)(13464003)(199003)(377454003)(374574003)(55904004)(24454002)(5001920100001)(87936001)(2950100001)(5001960100002)(92566002)(5003630100001)(2900100001)(5004730100002)(5007970100001)(6806005)(189998001)(23676002)(106116001)(46102003)(105586002)(106466001)(15975445007)(5003600100002)(50986999)(50466002)(19580395003)(69596002)(66066001)(47776003)(102836002)(54356999)(86362001)(64706001)(10400500002)(16796002)(19580405001)(93886004)(11100500001)(33646002)(5008740100001)(24736003)(108616004)(97736004)(81156007)(5001770100001)(76176999)(101416001)(567094001); DIR:OUT; SFP:1102; SCL:1; SRVR:DB3PR04MB217; H:011-smtp-out.Philips.com; FPR:; SPF:None; PTR:InfoDomainNonexistent; MX:1; A:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; DB3PR04MB217; 2:PB5/h0ozL64H+6pmMDgdktPf6PQLBBdJdGUBhojhkaKRxMi7YoUiZakw/ccZQYdSPaEz+OngLglfYbpLcPS5Hp97TxvjfD0L1PPsGe1rt+Oe0oaQyc5nGP+L4n73qQIUamcExznpAEpvwQANCl4XQTJ+vpG8IBngAr/WfbXGzZ4=; 3:aV3+57ES+DTA1N6T0OydOl39MgB581opny2+//ANx4ENyPtl8FTA1hs9AZhavo5/Qnw1wWsCg1d79M0qoS3yD94N/+IC+cJ2vWs4vibWa9cUN2xYXI7iOG47TCdhPhH878OpemNTxjroMgF6O1eQFqEriIHlDredvrwJ+Fi8MC2p9/Fgr1XSQgNEsCu3OaiQFc70V/HopkRMkElXkpNSR56JXGz8d/jasH86KrKaTsQ=; 25:bHuJo8eQrL9wiXaKnlFAZ9snB/Zw7nOj4mAQfGXHElCjDONutmOqYfUwj+i/LUeX+j1c0AfEJrdzvZccsdQ9yhxKbBKa0nqCgJz3FXrSLPdU3O3GaQsn8ayF+W3kH4Y9zVdsmHd5CqYIE35L+oSmKHbMs4KkmdvVI0FR3AGo2OIMw/CyrYzaqZxf1hJPMc71tsHsVs3CXz5YI3pNjUr/WvA/NiXMZy7h/z9UwA0uV8tOECAzDZJg1mrEKNqP8mJPbBc/LtBOAxf94ws4NVdikw== X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DB3PR04MB217; X-Microsoft-Exchange-Diagnostics: 1; DB3PR04MB217; 20:Frqhr0BlHlYuSLFLGp6HfIF3UF91HKYd6hF1PyL5guEq+6gFX7+Tqgy6D7AZ5aUVWa2PYqwAoroAIXKq0sVQhZLJjaRbg/zJsFoKNZscIy43r1YS9HQWtinR0atF/JLQGanbCJgBN25XBvomUMtSOf/blbd/ArI441dMH58eorIwsOMOaG+zmdAZfPoyFJY0SQJD9gBWXBCtUtv6WA/dYR27LtO1kYbsw+1PfmT3XQG6CenfEAEMAUx3zPUhN8ZdCxU4kZzPmtGD3l0CHF8JTyV2XzjMID39XMpGFKF8AAgAQqaq/TTMCvHt4CV2qwWaMfOFYnVNkaSMwJ6le6AZW6d1IjCNHZMD1y400YbzRVDd2Jw0rE5vxjroFfpcLuRHy1sYYPF+2EMbipKRN9WEfhXGHODq6EcOIlaJ57jHgRSRSaGsOnCHykoWJiHUuA08CPYUp/2jspAoLw/ix6PFKUia8iM3ZkD8D5PxPZ54KLQdzSL+bM71YaUm/40Tzb01; 4:P2wrqiDFkBlmJH4hqeS2Z7JcAp0stvRS3ZzSfDIDFsnk0cGaVbEVPsgwi93LJikKR9KdB8SAqC9RfdQCHJXGa58c3C0p1TNtq6AXW+AV/fxHYHRO/Q0l4pJq3zVWuCcfBNCiztfNZq12p6Xd/g6fWLQucQjW7mmXzOiyK+bfgwj1TqVKrqUdPf+SccdHBbcxyqmAGGe04P6dF2ujgdwslYLzYHv0m/0WmU1AMdUJPrxbilUJeXSGyfPIfxSmC6YnZjh6ZQaiTJH08fI/aPCHd2KNlIKieBb89T7uSKLQ0FjJW5mkq21OBuH1wOvVDUKYXOdFhST7g/WQ5APiE6qs5w9Mj8FxpWWHIEUD4FLGliY= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(520078)(3002001); SRVR:DB3PR04MB217; BCL:0; PCL:0; RULEID:; SRVR:DB3PR04MB217; X-Forefront-PRVS: 0723A02764 X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtEQjNQUjA0TUIyMTc7MjM6cVNmT2wyKy9YcUM2eUdmOGtFdVN6VWNhRnR4?= =?utf-8?B?WFJaZGFpZE5UWDI3L2k1TFJVSDBBWEw4K1VqYlhla09xekFsNUJZVWtnQ1Bp?= =?utf-8?B?NFVUaGQ4elROOEJwcWUrTlE2cUY0d3AzWWFFdFp3SnJCRDdFY0FzQjl0clB0?= =?utf-8?B?bkMvT0lLa2g4aUZiK3U2YUMrTzgwK0xONE40WEExbnZUUGV6OEdJb0laMlRr?= =?utf-8?B?MkJ2VzFSejcyakk4OC9lNWNhWmpkVnk0Z1NEaGM2WmFPKzhkQ2JXcGQybkpj?= =?utf-8?B?Y05TWDh1YzhpdlNybEludHlrRVJKbk1BR1pDVVZaUzMzdi9abndaaWI2UkE5?= =?utf-8?B?N2JkeHJKL1JVWm1rK3RRTzUwRkZXOEtDckVYRCtXOW5PNFlRYkFQMDYxRFdO?= =?utf-8?B?aU5wanNVYmVhbHpod3NmdVVUWFpxUFFPUWJrcjJHS0h1SVRXRmFlRnpBaE9z?= =?utf-8?B?TS8vMEhoNlIrTjNyamxLby93dFRhM2k0QTEwS2J5dy9rUURkQndhSzUzRUpD?= =?utf-8?B?Zk1Ga2Q1U2RGejY2VnRXZTZiQURPN1hOcEpJeHFKRUJRVEpWNTh0T2ZEbEht?= =?utf-8?B?a3EvZGtZUktvZnMvNHRLcHl0RTVydTVVRHlobHE4eWVUYndVeGRJeEZRclZX?= =?utf-8?B?SGUzOW4wRDFmRVVaQjhtZGZDWFNnQ0ZmRndXRHVqeWdpOEMxekRnZ0hOWDlJ?= =?utf-8?B?Q0p4ZDBKY05wWnlMSi9KTGIzR0p4NU9XaHRWZDhzdGNRU0FqaUhlUkVZalBV?= =?utf-8?B?aThvTFo1RnY2cjlRSEhYeTZORHh1VjJXUlFMQXQ5QnRKL1pVUk5MNndObURj?= =?utf-8?B?djZMdFJYV0NING5zWG40VG9mekF6MmZ6enJXMVVUeVg3OU9iaXpDbW1mY1Nx?= =?utf-8?B?a3JhQ2ZUaTMzQS81Slo0a1VHSGI0UFJheXNlTWxweWxFeEpCcmlhS3dEU1VD?= =?utf-8?B?R09KUFdxMlhYUG5vTHVGSHh6MVdDTDJTaVBja0tPY0hUc0s1RlhOdkdyaEMw?= =?utf-8?B?Z0R5OTltZGQvM2p4UXRETnRjQjd6RFNjYjZVdmdNNEFkMlNOOVhLYVkyZVlu?= =?utf-8?B?MWhXenVxbjBNZCtqTDlFVUg4enkyTUYxNEdWZ1Ird091SmtsbjVIUkt2enla?= =?utf-8?B?anUxWG5CUnhZNVU0WVVqblVLR1BJeng1cnhEcTMza3RHM2JEQ2NZVG5hV2xN?= =?utf-8?B?a2REUjdGdFp2YlRNWDdSZ2VmeUpiYWhwQmx5SmVnZ2FNQktiNVg2cG5HVVdl?= =?utf-8?B?eXNNSGpZSk9SYzVkV0xvTkRJL09XS0h0Q1BBanBHRFcyTldmQ0ZUeC9Dak9L?= =?utf-8?B?dTV5UDlBVXltUk5JaWJFZVVjUWdVc1p1T2Y2dkJncUtVQTlWTWF6dGU4bGtF?= =?utf-8?B?VHh1Wmg4RHdueS9FTWhQTGZuUCtzUWczUE1mYi9GUzdTc0ZCUXlLQ1BFVmx0?= =?utf-8?B?VmRLOS9YRUNTUmVTYThxd0M3VTRKa0tTcjBCd0ZPRkNUY2VQTzFlQVdDbGtD?= =?utf-8?B?ZmtRWC9iWUdWNHNjMUlyTWlXQTROSjQzc21RY1RPcUx5aFpYTDB5QVFXeS9p?= =?utf-8?B?R1NJenBUSTdHUDlmODFSbWlhSnhiWDBxYkxmTWppcXlVN2FGM1FZaUYwU3ZH?= =?utf-8?B?amdUTm1aenlBZVdkbllldUdlVU0zUkJHZHhUWlZTN25qM2ptb1BxOW9TRlBB?= =?utf-8?B?RytYbmtqRHJXTDdYREx4bnFZd1BUbUV0akRiWnNXYVNzOE84OU5SekpDVGJS?= =?utf-8?B?cGRmSmZhTzRubEFqa3pwWTdnb25lbXVRYm50RWxWbGxrQ2Q0cWE4YXFRVm1t?= =?utf-8?B?Rnl0bUhBcTMweFFuVjhSUzYyQ25Rb1FMR0VBTDVBbW02NUY3b2h0WkNoMlJS?= =?utf-8?B?RmIvM0llZ3pERDY4U2RPNUF1aUs4MHhnM2FKOXlFYUxwVzNUYk1hbTUrWWlv?= =?utf-8?Q?g/lpT8oV9SlpKCAha7G/Z8X1IZVQA=3D?= X-Microsoft-Exchange-Diagnostics: 1; DB3PR04MB217; 5:48AIEOlKC264JMI7zHqkyNQUUPCC0dhNGCWvZ0rdKX+rRntXl3OJqffN4bSdy8E4EW1kogE9AiGfnqfnL6VXxfmVUjgBAZEDlRTLENJ85LMlVNLDuI4lXKS2gPvitp67X0AqlS0EtHQmgf0jTp2M6A==; 24:b8LAwoljTJc6uJmqboUEMhE13UlBFHrfFgr9fKU5TLTzHbG8m3AhLCUev+/P5FQLzIXuPi18VXDJpRXNJuNE8M0ZmtlJXDe+0o7dwD862/M=; 20:o3Wsr4sAynuCWO8IhIKuqi0I1mV60qFlpxt4OhRBZ5YDPR3WAv7PbpEgyzvnMSy3FOyGzIZ2rwIaj6L8+Mw/Ig== SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: philips.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 08 Oct 2015 07:41:18.9086 (UTC) X-MS-Exchange-CrossTenant-Id: 1a407a2d-7675-4d17-8692-b3ac285306e4 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=1a407a2d-7675-4d17-8692-b3ac285306e4; Ip=[23.103.247.180]; Helo=[011-smtp-out.Philips.com] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB3PR04MB217 Archived-At: Cc: Hannes Tschofenig , Olaf Bergmann , "Ace@ietf.org" Subject: Re: [Ace] Dynamically Connecting Smart Sports Equipment X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 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, 08 Oct 2015 07:41:44 -0000 QWdyZWUuIEZ1cnRoZXIgdGhlcmUgY2FuIGJlIGZsZXggc3BhY2VzIGluIG9mZmljZXMgd2hlcmUg YSBwZXJzb24gc2l0dGluZyBhdCB0aGF0IG1vbWVudCBjYW4gZGVjaWRlIHdoYXQgYnJpZ2h0bmVz cyBhbmQgd2hpdGUtY29sb3IgaGUgcHJlZmVycyBidXQgdGhlIG5leHQgcGVyc29uIGNhbm5vdCBh Y2Nlc3MgYW55IG9mIHRob3NlIHNldHRpbmdzIG9yIHRoZSBsb2dnZWQgZGF0YS4NCg0KU2FuZGVl cA0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IEFjZSBbbWFpbHRvOmFj ZS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgS2F0aGxlZW4gTW9yaWFydHkNCj4NCj4g VGhlIGxpZ2h0aW5nIGV4YW1wbGUgaXMgc2ltaWxhciBpbiB0aGF0IG1hbm5lciAtIG11bHRpcGxl IHVzZXJzIHdpdGggc2VwYXJhdGUNCj4gem9uZXMgdGhhdCB0aGV5IG1heSBiZSBhdXRob3JpemVk IHRvIGFjY2Vzcy4gIFRoZSBkaWZmZXJlbmNlIGlzIHNjYWxlIGFuZA0KPiBpbXBsZW1lbnRhdGlv bi4NCj4NCj4gS2F0aGxlZW4NCj4NCj4gU2VudCBmcm9tIG15IGlQaG9uZQ0KPg0KPiA+IE9uIE9j dCA3LCAyMDE1LCBhdCA0OjM0IFBNLCBDYXJzdGVuIEJvcm1hbm4gPGNhYm9AdHppLm9yZz4gd3Jv dGU6DQo+ID4NCj4gPiBJdCBpcyBhIHNpbXBsZSBleGFtcGxlIG9mIG93bmVyc2hpcCBhbmQgbXVs dGlwbGUgc3Rha2Vob2xkZXJzLg0KPiA+DQo+ID4gSXQgd291bGQgYmUgbmljZSB0byBoYXZlIG1v cmUgb2YgdGhvc2UsIGJ1dCBtYXliZSB3ZSB3YW50IHRvIHB1dCBhIGxpZA0KPiA+IG9uIHdoYXQg d2UgaGF2ZS4NCj4gPg0KPiA+IEdyw7zDn2UsIENhcnN0ZW4NCj4gPg0KPiA+DQo+ID4gSGFubmVz IFRzY2hvZmVuaWcgd3JvdGU6DQo+ID4+IEhvdyBkb2VzIHRoaXMgcmVsYXRlIHRvIEFDRT8NCj4g Pg0KPiA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ ID4gQWNlIG1haWxpbmcgbGlzdA0KPiA+IEFjZUBpZXRmLm9yZw0KPiA+IGh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vYWNlDQo+DQo+IF9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fDQo+IEFjZSBtYWlsaW5nIGxpc3QNCj4gQWNlQGlldGYu b3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vYWNlDQoNCl9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQpUaGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGlu IHRoaXMgbWVzc2FnZSBtYXkgYmUgY29uZmlkZW50aWFsIGFuZCBsZWdhbGx5IHByb3RlY3RlZCB1 bmRlciBhcHBsaWNhYmxlIGxhdy4gVGhlIG1lc3NhZ2UgaXMgaW50ZW5kZWQgc29sZWx5IGZvciB0 aGUgYWRkcmVzc2VlKHMpLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCB5 b3UgYXJlIGhlcmVieSBub3RpZmllZCB0aGF0IGFueSB1c2UsIGZvcndhcmRpbmcsIGRpc3NlbWlu YXRpb24sIG9yIHJlcHJvZHVjdGlvbiBvZiB0aGlzIG1lc3NhZ2UgaXMgc3RyaWN0bHkgcHJvaGli aXRlZCBhbmQgbWF5IGJlIHVubGF3ZnVsLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVj aXBpZW50LCBwbGVhc2UgY29udGFjdCB0aGUgc2VuZGVyIGJ5IHJldHVybiBlLW1haWwgYW5kIGRl c3Ryb3kgYWxsIGNvcGllcyBvZiB0aGUgb3JpZ2luYWwgbWVzc2FnZS4NCg== From nobody Thu Oct 8 01:53:59 2015 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1D7C1A8ADA; Thu, 8 Oct 2015 01:53:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.55 X-Spam-Level: X-Spam-Status: No, score=-1.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_FR=0.35] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YSWOKGehimk1; Thu, 8 Oct 2015 01:53:54 -0700 (PDT) Received: from relay3-d.mail.gandi.net (relay3-d.mail.gandi.net [IPv6:2001:4b98:c:538::195]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A29B81A8AD6; Thu, 8 Oct 2015 01:53:54 -0700 (PDT) Received: from dhcp-salsa-i143.rennes.enst-bretagne.fr (unknown [IPv6:2001:660:7301:3728:fd93:4d4a:4c6a:394a]) (Authenticated sender: alex@ackl.io) by relay3-d.mail.gandi.net (Postfix) with ESMTPSA id C1263A811C; Thu, 8 Oct 2015 10:53:51 +0200 (CEST) To: Rafa Marin Lopez From: Alexander Pelov Message-ID: <56162F1A.5020503@ackl.io> Date: Thu, 8 Oct 2015 10:53:46 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: 6tisch@ietf.org, ace@ietf.org Subject: [Ace] Optimizing EAP-over-CoAP payload X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 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, 08 Oct 2015 08:53:56 -0000 Dear Rafa, I've been reading the latest version of your draft ( draft-marin-ace-wg-coap-eap-01.txt ), and I have a couple of questions regarding some of the payload options, which could be optimized even further: 1) Use shorter name for the /auth resource 2) Mandate the use of zero-length CoAP token The first, and the more simple one, is - would it be possible to change the name of the authentication resource from /auth to a shorter one (like /a)? Maybe it could be an option to change the name of this resource, based on the underlaying architecture, e.g. an RFC could mandate that in a specific network the resource could be named /a, whereas the default value could remain /auth? The second, which is a little bit more subtle. Tokens are used to match responses to requests, but during the authentication/authorization phase a single peer (endpoint) would communicate with a single authenticator. Moreover, the communication happens in a serial fashion, and responses are piggybacked. This falls in the case when zero-length token is also advised by RFC7252. Do you think that it would be appropriate to make the use of zero-length token mandatory for EAP-over-CoAP? Best, Alexander From nobody Thu Oct 8 10:02:01 2015 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B308E1ACE61; Thu, 8 Oct 2015 10:02:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rKME7-rLmozR; Thu, 8 Oct 2015 10:01:59 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A0E11ABD35; Thu, 8 Oct 2015 10:01:59 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.4.1 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <20151008170159.15204.85259.idtracker@ietfa.amsl.com> Date: Thu, 08 Oct 2015 10:01:59 -0700 Archived-At: Cc: ace@ietf.org Subject: [Ace] Last Call: (ACE use cases) to Informational RFC X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Reply-To: ietf@ietf.org List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Oct 2015 17:02:00 -0000 The IESG has received a request from the Authentication and Authorization for Constrained Environments WG (ace) to consider the following document: - 'ACE use cases' as Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2015-10-22. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract Constrained devices are nodes with limited processing power, storage space and transmission capacities. These devices in many cases do not provide user interfaces and are often intended to interact without human intervention. This document includes a collection of representative use cases for authentication and authorization in constrained environments. These use cases aim at identifying authorization problems that arise during the lifecycle of a constrained device and are intended to provide a guideline for developing a comprehensive authentication and authorization solution for this class of scenarios. Where specific details are relevant, it is assumed that the devices use the Constrained Application Protocol (CoAP) as communication protocol, however most conclusions apply generally. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-ace-usecases/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-ace-usecases/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Fri Oct 9 05:00:07 2015 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 474701B3906 for ; Fri, 9 Oct 2015 05:00:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gsxvAo0VbGWT for ; Fri, 9 Oct 2015 05:00:02 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (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 837711B3899 for ; Fri, 9 Oct 2015 05:00:02 -0700 (PDT) Received: from [192.168.10.202] ([131.171.200.169]) by mail.gmx.com (mrgmx001) with ESMTPSA (Nemesis) id 0LsChr-1akHOK3583-013vjq; Fri, 09 Oct 2015 13:59:52 +0200 To: "Kumar, Sandeep" , Kathleen Moriarty , Carsten Bormann , Olaf Bergmann References: <56153D33.6010100@gmx.net> <87egh6a22u.fsf@aung.informatik.uni-bremen.de> <56158006.1080506@gmx.net> <561581F2.3060505@tzi.org> <23191A62-445C-448B-8D0A-5E05282C15B0@gmail.com> From: Hannes Tschofenig Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9 X-Enigmail-Draft-Status: N1110 Message-ID: <5617AC33.1060709@gmx.net> Date: Fri, 9 Oct 2015 13:59:47 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="TLbS0Mj4IOqGwrSLBoDH9k5EmDOCGQTLU" X-Provags-ID: V03:K0:y+UulytO198D01dmMxUcRltLpM2O+cx+jbWsOh+fPu8GFdFFCk2 AhatYLZdXWyjWKZyhYTn2dC8mlgrZbyj+d54Z5eqii9y18SPN7pm6p1YnHA8jmTpZnwrwrQ 4UysHdDRPX4/EoJMmiCpKLuPnuozii1B2GpVqYO+8iwmk2RnNG8qpX2KIQT7r7H9ylFjv/7 hpKhtVu8RGIAB3FvOq3+w== X-UI-Out-Filterresults: notjunk:1;V01:K0:HyuUJxrIzP0=:VPn0NTkQJTfu9wzQxAaQkv xfy+nrEIFx4KqEepGoqiP3LCe3zDAYkMdu8j8yXvYqLW+zFz0b9ExBDUor6r+/WEahwbwc3yw QYs4R4oUUnZmhZcXWKha5+NAsofZeCP3AbUjJLzGyYjRq0CPWw9AEvdihdlLXlL/lOn4YwrLm Bd6ChbcUnoVKW/u3wDyrDSm7z/xa1YmndEjrhLUap1YOegFtZpSljIidblclgtrtC2hwWHo06 KQT70zvg+Q7mnwQY2uMTqHi88TzcbqVx/8FGMIavIgrMyEW0f0noiJCK2stH8jS2IDXva1HIS aqctuxmdoOg94e8MFiyvk9POCXglO2QDHr0rvpBnXF5Pkc2guFMUe6J94SRyMJLIQ1OASpa6W Wqd0URL4szG0kI28opI1bbK9W+rmD0FY0VpANfYerO3bgtFKKUSCKkTYkh0vrUoc3RhymPfNe e5v2mj3KjQv6TCB6rPycDmfXCJ61pddZuXA0oa4ZTlEAty1XFgDlaoGkkbmyC4ohiKjX3iBDU 2jD6JxF5DAOHWW6Nm82mpq//LMD9Hn3etvge1Dk52jydkkjOh4AzqbsfqIPlRlT2A0nQCh2/0 2GHa13toQHRN1XUKjd/C6vuLp+azsbx0D1F6xDo9r7DrR7+/Dbv+o6lPO8IoIv4PUp8z38JhO ehqkOq+mTFD1q2UEXb2znIYcjR3aFqkX+AauWyKj47q2R4fSYlnSrAgMmRU2bHmlEOV6hY5Ea KQ85lUiimDRLQ+799qgB6Ug4vCp4TTkXu3RnBzUEHHzCl5OuNbaHU830djQ= Archived-At: Cc: "Ace@ietf.org" Subject: Re: [Ace] Dynamically Connecting Smart Sports Equipment X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 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 Oct 2015 12:00:05 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --TLbS0Mj4IOqGwrSLBoDH9k5EmDOCGQTLU Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Maybe I don't understand the sports equipment scenario properly but I fail to see how this is relevant to the lighting scenario. Here is the scenario I am referring to: https://tools.ietf.org/html/draft-ietf-ace-usecases-07#section-2.6.1 In this scenario I am having a watch used by two users and one user wants to prevent the other user from accessing data stored LOCALLY on the watch. I don't see how this could possibly mapped to a lighting scenario. I have to admit that I am not a domain expert to say whether such a scenario is realistic or relevant but I don't see how anything developed in ACE can contribute a solution. You will probably argue that I should shut up arguing about these scenario because nobody is going to compare solutions against the scenarios anyway. Ciao Hannes On 10/08/2015 09:41 AM, Kumar, Sandeep wrote: > Agree. Further there can be flex spaces in offices where a person sitti= ng at that moment can decide what brightness and white-color he prefers b= ut the next person cannot access any of those settings or the logged data= =2E >=20 > Sandeep >=20 >> -----Original Message----- >> From: Ace [mailto:ace-bounces@ietf.org] On Behalf Of Kathleen Moriarty= >> >> The lighting example is similar in that manner - multiple users with s= eparate >> zones that they may be authorized to access. The difference is scale = and >> implementation. >> >> Kathleen >> >> Sent from my iPhone >> >>> On Oct 7, 2015, at 4:34 PM, Carsten Bormann wrote: >>> >>> It is a simple example of ownership and multiple stakeholders. >>> >>> It would be nice to have more of those, but maybe we want to put a li= d >>> on what we have. >>> >>> Gr=C3=BC=C3=9Fe, Carsten >>> >>> >>> Hannes Tschofenig wrote: >>>> How does this relate to 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 >=20 > ________________________________ > The information contained in this message may be confidential and legal= ly protected under applicable law. The message is intended solely for the= addressee(s). If you are not the intended recipient, you are hereby noti= fied that any use, forwarding, dissemination, or reproduction of this mes= sage is strictly prohibited and may be unlawful. If you are not the inten= ded recipient, please contact the sender by return e-mail and destroy all= copies of the original message. > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace >=20 --TLbS0Mj4IOqGwrSLBoDH9k5EmDOCGQTLU Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJWF6w0AAoJEGhJURNOOiAtXPIH/RaW61eti9OeTZVCVRdu3Vbs 5YoNWlNjFx7JesFhRJ9e1caodSlMXdfX9zlV97OeRpZQFUsNBebUDf2O0kW5mbdZ D1ZSnLGps4+ZeXouO701e5QsAeLHrq+hL2F3n4hKKFcoVdWR5nafLSIm1jUFL0Iz uXaJDLpYYWFXIJx111TBQB3SCF7hjF1t+6bK2WaLz42/Y4Q953D52xDKSaZbyn+N /vpkRA+VJ1r3UXli0OPEI5Le4o31ggT8uiFx8SK6ylXSu1H3FHAlreIq66JTaX6u buMRCjvJQLjVEKvvocx9pcWt3lbi7wNFSf3n91WQnGLAJ5jNP5HY+G3kWMN8hOc= =CkH3 -----END PGP SIGNATURE----- --TLbS0Mj4IOqGwrSLBoDH9k5EmDOCGQTLU-- From nobody Sat Oct 10 05:05:53 2015 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 926E41B35B3; Sat, 10 Oct 2015 05:05:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.55 X-Spam-Level: X-Spam-Status: No, score=-1.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3Gq1ze7KfmkN; Sat, 10 Oct 2015 05:05:50 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 19AD81B35B0; Sat, 10 Oct 2015 05:05:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::b]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id t9AC5kGi021260; Sat, 10 Oct 2015 14:05:46 +0200 (CEST) Received: from nar.local (p5DC7F6AE.dip0.t-ipconnect.de [93.199.246.174]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3nY4jQ0ytlz4pK3; Sat, 10 Oct 2015 14:05:46 +0200 (CEST) Message-ID: <5618FF18.8050909@tzi.org> Date: Sat, 10 Oct 2015 14:05:44 +0200 From: Carsten Bormann User-Agent: Postbox 4.0.5 (Macintosh/20150923) MIME-Version: 1.0 To: dtls-iot@ietf.org, core@ietf.org, ace@ietf.org, cose@ietf.org, t2trg@irtf.org X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Archived-At: Subject: [Ace] Constrained Node/Network Cluster @ IETF94, "final" version X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 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, 10 Oct 2015 12:05:51 -0000 Below is the "final" version of my usual eclectic condensed agenda. (Sorry for missing out on the draft version, but not much has changed.) Again, I have filled in the T2TRG Sat/Sun meeting, which is waiting for its room assignment; the T2TRG summary meeting this time is on Wed morning (and we have 1 h, which should be enough for a summary). Remember that there is still some potential for changes. All times are JST (UTC+0900) (the browser timezone function is not yet reinstated on https://datatracker.ietf.org/meeting/agenda-utc, for those who want to listen from remote). Grüße, Carsten SATURDAY, October 31, 2015 0900-1830 T2TRG - Room TBD 0900-2100 IETF Hackathon - Room 315 0900-1830 RAIM Workshop - Room 303 SUNDAY, November 1, 2015 0900-1600 T2TRG - Room TBD 0900-1800 IETF Hackathon - Room 315 1600-1700 Newcomers' Meet and Greet (open to Newcomers, WG chairs and Mentors only) - InterContinental Bay View Room 1600-1630 CBOR - Room 301 1700-1900 Welcome Reception - InterContinental Ballroom MONDAY, November 2, 2015 0900-1130 Morning Session I Rm 501 OPS v6ops IPv6 Operations WG Rm 301 RTG detnet Deterministic Networking WG Rm 302 SEC *** ace Authentication and Authorization for Constrained Environments WG 1300-1500 Afternoon Session I Rm 501 ART httpbis Hypertext Transfer Protocol WG Rm 304 OPS anima Autonomic Networking Integrated Model and Approach WG Rm 303 TSV tsvwg Transport Area Working Group WG 1520-1650 Afternoon Session II Rm 302 INT dnssd Extensions for Scalable DNS Service Discovery WG Rm 501 TSV rmcat RTP Media Congestion Avoidance Techniques WG 1710-1910 Afternoon Session III Rm 502 OPS v6ops IPv6 Operations WG Rm 501 RTG rtgarea Routing Area Open Meeting Rm 302 SEC tokbind Token Binding WG TUESDAY, November 3, 2015 0900-1130 Morning Session I Rm 301 ART *** core Constrained RESTful Environments WG Rm 502 INT homenet Home Networking WG 1300-1500 Afternoon Session I 411/412 ART webpush Web-Based Push Notifications WG 1520-1650 Afternoon Session II Rm 303 OPS anima Autonomic Networking Integrated Model and Approach WG Rm 413 SEC *** cose CBOR Object Signing and Encryption WG Rm 304 TSV taps Transport Services WG 1710-1840 Afternoon Session III 411/412 SEC openpgp Open Specification for Pretty Good Privacy WG WEDNESDAY, November 4, 2015 0900-1130 Morning Session I Rm 501 INT 6man IPv6 Maintenance WG Rm 302 IRTF*** t2trg Proposed Thing-to-Thing Research Group - 1030 - 1130 Rm 303 SEC tls Transport Layer Security WG 1300-1500 Afternoon Session I Rm 501 TSV tcpinc TCP Increased Security WG THURSDAY, November 5, 2015 0900-1130 Morning Session I Rm 303 ART ice Interactive Connectivity Establishment WG Rm 501 INT *** 6lo IPv6 over Networks of Resource-constrained Nodes WG 1300-1500 Afternoon Session I Rm 413 ART geojson Geographic JSON WG Rm 502 SEC saag Security Area Open Meeting Rm 302 TSV tsvwg Transport Area Working Group WG 1520-1720 Afternoon Session II Rm 303 INT *** 6tisch IPv6 over the TSCH mode of IEEE 802.15.4e WG Rm 501 OPS opsarea Operations & Management Area Open Meeting - Combined with OPSAWG Rm 301 SEC oauth Web Authorization Protocol WG 1740-1840 Afternoon Session III Rm 304 INT intarea Internet Area Working Group WG Rm 302 RTG *** roll Routing Over Low power and Lossy networks WG Rm 501 SEC tls Transport Layer Security WG FRIDAY, November 6, 2015 0900-1130 Morning Session I Rm 302 ART *** core Constrained RESTful Environments WG 411/412 RTG bier Bit Indexed Explicit Replication WG Rm 304 SEC acme Automated Certificate Management Environment WG Rm 501 TSV rmcat RTP Media Congestion Avoidance Techniques WG All day ETSI 6lo Plugtest SATURDAY, November 7, 2015 All day ETSI 6lo Plugtest SUNDAY, November 8, 2015 All day ETSI 6lo Plugtest From nobody Mon Oct 12 11:06:07 2015 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF7EA1ACD8A for ; Mon, 12 Oct 2015 11:06:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.159 X-Spam-Level: ** X-Spam-Status: No, score=2.159 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DATE_IN_PAST_12_24=1.049, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8v5emz2InbPR for ; Mon, 12 Oct 2015 11:06:04 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [176.58.120.209]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B11961ACD79 for ; Mon, 12 Oct 2015 11:06:04 -0700 (PDT) Received: from sandelman.ca (dooku.dawson.sandelman.ca [IPv6:2607:f0b0:f:b:219:d2ff:fec0:9f1e]) by relay.sandelman.ca (Postfix) with ESMTPS id B03CD2208C for ; Mon, 12 Oct 2015 14:06:03 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id A923A61E2F; Sun, 11 Oct 2015 18:21:51 -0400 (EDT) From: Michael Richardson To: "Ace\@ietf.org" In-reply-to: <0FBD373E-15DE-4FA1-AD09-66091685A1F0@gmail.com> References: <56153D33.6010100@gmx.net> <87egh6a22u.fsf@aung.informatik.uni-bremen.de> <56158006.1080506@gmx.net> <561581F2.3060505@tzi.org> <23191A62-445C-448B-8D0A-5E05282C15B0@gmail.com> <5615911F.8000905@gmx.net> <0FBD373E-15DE-4FA1-AD09-66091685A1F0@gmail.com> Comments: In-reply-to Kathleen Moriarty message dated "Wed, 07 Oct 2015 17:49:07 -0400." X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.4.1 MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Sun, 11 Oct 2015 18:21:51 -0400 Message-ID: <18736.1444602111@dooku.sandelman.ca> Archived-At: Subject: Re: [Ace] Dynamically Connecting Smart Sports Equipment X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 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 Oct 2015 18:06:05 -0000 --=-=-= Content-Type: text/plain Kathleen Moriarty wrote: > I was thinking you and I might work for different companies in the same > building and have access just got the lighting in our own space. This is > in that use case. So there is the concept of separate authorization zones > on that use case as well - just on a completely different scale. Or the two of your companies share a hallway that leads to the bathroom. Who turned the light on last night at 2am might be relevant. (Knowing that might help me decide to short the shares of your company) -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEcBAEBAgAGBQJWGuD9AAoJEKD0KQ7Gj3P2tasH/A/t8hCghbaol4C+wzkLE/gx ecoPMFZF/ZQ3p55UNyti3XPTT3rbF83u4sT6mdEYtocmwpNxDiRw8m2Nxb6kgT1B DyWa5SX7RwsC7ryOJ2PYg5uLeLkA2HjG4Mmh44eRrAq4zG9o5S2ObA8ajmWnXL3y CmRM+7uf0oS1ljV1yl6ppDz9Hs2ezg8/cQeFWD91XigXu8Bkl7k3JUfh7tGATn8y Q9iJQNiSAwhzA4Ygvx+q6z7Kc/dURf4s4CGdookv6W0jRY4vzN+zxeoQ9fux9tj9 sUD0OqHSyClNVnx9oWgLnKPjI/o258/Gtx1juEZqEeZa14jmDjjUOIoRYJ+x2c0= =t+o0 -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Oct 12 11:06:09 2015 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAE141ACD79 for ; Mon, 12 Oct 2015 11:06:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.159 X-Spam-Level: ** X-Spam-Status: No, score=2.159 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DATE_IN_PAST_12_24=1.049, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fbq2QDXxw9oO for ; Mon, 12 Oct 2015 11:06:04 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [IPv6:2a01:7e00::f03c:91ff:feae:de77]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E68B1ACD55 for ; Mon, 12 Oct 2015 11:06:04 -0700 (PDT) Received: from sandelman.ca (unknown [209.87.249.16]) by relay.sandelman.ca (Postfix) with ESMTPS id 62B4C22087 for ; Mon, 12 Oct 2015 14:06:02 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 8F28F61E2D; Sun, 11 Oct 2015 18:19:30 -0400 (EDT) From: Michael Richardson To: "Ace\@ietf.org" In-reply-to: <561581F2.3060505@tzi.org> References: <56153D33.6010100@gmx.net> <87egh6a22u.fsf@aung.informatik.uni-bremen.de> <56158006.1080506@gmx.net> <561581F2.3060505@tzi.org> Comments: In-reply-to Carsten Bormann message dated "Wed, 07 Oct 2015 22:34:58 +0200." X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.4.1 MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Sun, 11 Oct 2015 18:19:30 -0400 Message-ID: <18680.1444601970@dooku.sandelman.ca> Archived-At: Subject: Re: [Ace] Dynamically Connecting Smart Sports Equipment X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 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 Oct 2015 18:06:05 -0000 --=-=-= Content-Type: text/plain It's not the *watch* which might be shared/multi-user (although it might). It's the running threadmille, elliptical, or the chin-up-machine, etc. It could also be that the gym has a number of heart monitors, and that they are leant out. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEcBAEBAgAGBQJWGuBwAAoJEKD0KQ7Gj3P2dzAIAIgC2pEJ1afz305SUUNAzm6A i1s8JWLxCVrTe1BYpt2L5Ouiy1QQQq3gi+WggkS3gybzhWx/KnVsyfW5c9nwyEeU LnP/Wk3+dkfvSEDVgGic1ETTIfDF5FRpdM6kZdPySkbwOb4333AEIs2AZHqwavQa SkgatCGpxvDP9BVY5uTtVbkXpqNnFt3YW80j/Xda7CHx9VEDZPhcqnxNmOqNUCyQ 2kMGMP7jD1A7JPYfDIJSK1xgUKmTJPm5XggPP77JyclT9qTuhX5HkdJC1ynrcoAe HFy5vic/1M0cR6fiKV2iN59XPGLVi/BDdT5DadkGYNYwPuCLaOCIy5A7ko6PgAg= =2oFl -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Oct 12 11:41:57 2015 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AAF7D1B2B97; Mon, 12 Oct 2015 11:41:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m0DdAUgiKttz; Mon, 12 Oct 2015 11:41:52 -0700 (PDT) Received: from xenon23.um.es (xenon23.um.es [155.54.212.163]) by ietfa.amsl.com (Postfix) with ESMTP id E71091B2B94; Mon, 12 Oct 2015 11:41:51 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by xenon23.um.es (Postfix) with ESMTP id 7C74736C0; Mon, 12 Oct 2015 20:41:50 +0200 (CEST) X-Virus-Scanned: by antispam in UMU at xenon23.um.es Received: from xenon23.um.es ([127.0.0.1]) by localhost (xenon23.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id Tiiscu4OC4gI; Mon, 12 Oct 2015 20:41:50 +0200 (CEST) Received: from [192.168.1.44] (11.Red-79-144-178.dynamicIP.rima-tde.net [79.144.178.11]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: rafa) by xenon23.um.es (Postfix) with ESMTPSA id 5A5ED36BC; Mon, 12 Oct 2015 20:41:47 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.0 \(3094\)) From: Rafa Marin Lopez In-Reply-To: <56162F1A.5020503@ackl.io> Date: Mon, 12 Oct 2015 20:41:46 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <56162F1A.5020503@ackl.io> To: Alexander Pelov X-Mailer: Apple Mail (2.3094) Archived-At: Cc: 6tisch@ietf.org, Dan Garcia , Rafa Marin Lopez , ace@ietf.org Subject: Re: [Ace] Optimizing EAP-over-CoAP payload X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 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 Oct 2015 18:41:54 -0000 Dear Alexander: Thanks for your comments=20 > El 8 oct 2015, a las 10:53, Alexander Pelov escribi=C3=B3: >=20 > Dear Rafa, >=20 > I've been reading the latest version of your draft ( = draft-marin-ace-wg-coap-eap-01.txt ), and I have a couple of questions = regarding some of the payload options, which could be optimized even = further: >=20 > 1) Use shorter name for the /auth resource > 2) Mandate the use of zero-length CoAP token >=20 > The first, and the more simple one, is - would it be possible to = change the name of the authentication resource from /auth to a shorter = one (like /a)? Maybe it could be an option to change the name of this = resource, based on the underlaying architecture, e.g. an RFC could = mandate that in a specific network the resource could be named /a, = whereas the default value could remain /auth? [Rafa] I do not see any problem to shorten the resource name. >=20 > The second, which is a little bit more subtle. Tokens are used to = match responses to requests, but during the authentication/authorization = phase a single peer (endpoint) would communicate with a single = authenticator. Moreover, the communication happens in a serial fashion, = and responses are piggybacked. This falls in the case when zero-length = token is also advised by RFC7252. Do you think that it would be = appropriate to make the use of zero-length token mandatory for = EAP-over-CoAP? [Rafa] I guess you are referring to this text: =20 "An empty token value is appropriate e.g., when no other tokens are in use to a destination, "or when requests are made serially per destination and receive piggybacked responses.=E2=80=9D= I would say that using zero-length token is possible. What I am not sure = is whether make it mandatory or not. I mean we could say that if the = client sends a zero-length token the server can consider it OK as per = the text above. If there is a non-zero length token value should be also = fine. What do you think? Best Regards. >=20 > Best, > Alexander >=20 > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace ------------------------------------------------------- Rafael Marin Lopez, PhD Dept. Information and Communications Engineering (DIIC) Faculty of Computer Science-University of Murcia 30100 Murcia - Spain Telf: +34868888501 Fax: +34868884151 e-mail: rafa@um.es ------------------------------------------------------- From nobody Mon Oct 12 12:02:06 2015 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 855141B3400; Mon, 12 Oct 2015 12:02:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.55 X-Spam-Level: X-Spam-Status: No, score=-1.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XgiJG1mPRe5R; Mon, 12 Oct 2015 12:02:04 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 256531B349B; Mon, 12 Oct 2015 12:01:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::b]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id t9CJ1ZwU021324; Mon, 12 Oct 2015 21:01:35 +0200 (CEST) Received: from nar.local (p5DC7F6AE.dip0.t-ipconnect.de [93.199.246.174]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3nZTrG6LSHz4psB; Mon, 12 Oct 2015 21:01:34 +0200 (CEST) Message-ID: <561C038C.7090305@tzi.org> Date: Mon, 12 Oct 2015 21:01:32 +0200 From: Carsten Bormann User-Agent: Postbox 4.0.5 (Macintosh/20150923) MIME-Version: 1.0 To: Rafa Marin Lopez References: <56162F1A.5020503@ackl.io> In-Reply-To: X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: 6tisch@ietf.org, Alexander Pelov , Dan Garcia , ace@ietf.org Subject: Re: [Ace] Optimizing EAP-over-CoAP payload X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 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 Oct 2015 19:02:05 -0000 Rafa Marin Lopez wrote: > I would say that using zero-length token is possible. What I am not sure is whether make it mandatory or not. I mean we could say that if the client sends a zero-length token the server can consider it OK as per the text above. If there is a non-zero length token value should be also fine. There is never a reason to discuss token values -- these are chosen by the requester based on its needs, and there is never a reason for a responder to question that choice. Grüße, Carsten From nobody Tue Oct 13 05:50:16 2015 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1ED41B3025; Tue, 13 Oct 2015 05:50:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CkP06pV7s9QL; Tue, 13 Oct 2015 05:50:10 -0700 (PDT) Received: from inkolg01.tcs.com (inkolg01.tcs.com [121.241.215.10]) by ietfa.amsl.com (Postfix) with ESMTP id 6115E1B3023; Tue, 13 Oct 2015 05:50:05 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A2ABAgC9+xxW/wQXEqxeg3puvhIBDYFaFwEJgnKCCn8CHIFgFAEBAQEBAQGBCoQmAQEBAwEBAQEgSwsFCwsHBgQBAgECKAMCAgIlHwMGCAYLCBuICxWsMQEBAW+TXgEBAQEBAQEBAQEBAQEBAQEBAQEBAReFSmqFP4RCMAoNBAcGgig7FB2BFAWHPYVRdYgThRmJWZZBg28fAQGCUQIdgVxphnEBAQE X-IPAS-Result: A2ABAgC9+xxW/wQXEqxeg3puvhIBDYFaFwEJgnKCCn8CHIFgFAEBAQEBAQGBCoQmAQEBAwEBAQEgSwsFCwsHBgQBAgECKAMCAgIlHwMGCAYLCBuICxWsMQEBAW+TXgEBAQEBAQEBAQEBAQEBAQEBAQEBAReFSmqFP4RCMAoNBAcGgig7FB2BFAWHPYVRdYgThRmJWZZBg28fAQGCUQIdgVxphnEBAQE X-IronPort-AV: E=Sophos;i="5.17,677,1437417000"; d="scan'208";a="12666699" In-Reply-To: References: <56162F1A.5020503@ackl.io> To: Rafa Marin Lopez MIME-Version: 1.0 X-KeepSent: 8676C547:C1DA2D9E-65257EDD:00415177; type=4; name=$KeepSent X-Mailer: IBM Notes Release 9.0 March 08, 2013 Message-ID: From: Abhijan Bhattacharyya Date: Tue, 13 Oct 2015 18:18:26 +0530 X-MIMETrack: Serialize by Router on INKOLM102/TCS(Release 9.0.1FP4|June 07, 2015) at 10/13/2015 18:19:03, Serialize complete at 10/13/2015 18:19:03 Content-Type: multipart/alternative; boundary="=_alternative 00465A7265257EDD_=" Archived-At: Cc: 6tisch@ietf.org, a@ackl.io, dan.garcia@um.es, ace@ietf.org Subject: Re: [Ace] Optimizing EAP-over-CoAP payload X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 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 Oct 2015 12:50:13 -0000 This is a multipart message in MIME format. --=_alternative 00465A7265257EDD_= MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgUmFmYSwNClRoZSBhcHBsaWNhdGlvbiBsYXllciBkcml2ZW4gYXBwcm9hY2ggaXMgcmVhbGx5 IGludGVyZXN0aW5nIGluIHRoZSANCmNvbnN0cmFpbmVkIGVudmlyb25tZW50IGNvbnRleHQuIFdl IGhhZCBhIHNpbWlsYXIgYXBwcm9hY2ggZm9yIHNlY3VyZSANCnNlc3Npb24gZXN0YWJsaXNobWVu dCAoYXNzdW1pbmcgdGhhdCBib290LXN0cmFwcGluZyBpcyBhbHJlYWR5IGRvbmUpIHdoaWNoIA0K cGVyZm9ybXMgdGhlIHNlc3Npb24gZXN0YWJsaXNobWVudCBpbiBDb0FQIGJ1dCB1c2VzIHRoZSBE VExTIGVuY3J5cHRpb24gDQphbmQgaGVhZGVyLXN0cnVjdHVyZSBmb3Igc2VjdXJlIGV4Y2hhbmdl IG9mIHRoZSBhcHBsaWNhdGlvbi1sYXllciBtZXNzYWdlLiANCkNvaW5jaWRlbnRhbGx5IHdlIGhh dmUgYWxzbyBkZWZpbmVkIGFuIG9wdGlvbiBjYWxsZWQgIkF1dGgiIC4NCg0KSGVyZSBpcyB0aGUg bGluayB0byB0aGUgZHJhZnQ6IA0KaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWJo YXR0YWNoYXJ5eWEtZGljZS1sZXNzLW9uLWNvYXAtMDAgKEhhZCANCmFuIG9sZGVyIHdvcmsgaW4g cHJvZ3Jlc3M6IA0KaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWJoYXR0YWNoYXJ5 eWEtY29yZS1jb2FwLWxpdGUtYXV0aC0wMC4gDQpCdXQgdGhpcyBvbmUgZGlkIG5vdCBwcm92aWRl IGNoYW5uZWwgc2VjdXJpdHkpLg0KSSBzdWJtaXR0ZWQgdGhpcyBkcmFmdCB0byBkaWNlLCBob3dl dmVyLCBkaWNlIHdhcyBub3QgcmVhbGx5IHRoZSBwbGFjZSB0byANCmRpc2N1c3MgdGhpcy4gT3Vy IGRyYWZ0IGlzIGR1ZSB0byBleHBpcmUgaW4gYWJvdXQgNCBkYXlzLg0KDQoNCg0KUmVnYXJkcw0K QWJoaWphbiBCaGF0dGFjaGFyeXlhDQpBc3NvY2lhdGUgQ29uc3VsdGFudA0KU2NpZW50aXN0LCBJ bm5vdmF0aW9uIExhYiwgS29sa2F0YSwgSW5kaWENClRhdGEgQ29uc3VsdGFuY3kgU2VydmljZXMN Ck1haWx0bzogYWJoaWphbi5iaGF0dGFjaGFyeXlhQHRjcy5jb20NCldlYnNpdGU6IGh0dHA6Ly93 d3cudGNzLmNvbQ0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N CkV4cGVyaWVuY2UgY2VydGFpbnR5LiAgIElUIFNlcnZpY2VzDQogICAgICAgICAgICAgICAgICAg ICAgICBCdXNpbmVzcyBTb2x1dGlvbnMNCiAgICAgICAgICAgICAgICAgICAgICAgIENvbnN1bHRp bmcNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQoNCg0KIkFj ZSIgPGFjZS1ib3VuY2VzQGlldGYub3JnPiB3cm90ZSBvbiAxMC8xMy8yMDE1IDEyOjExOjQ2IEFN Og0KDQo+IEZyb206IFJhZmEgTWFyaW4gTG9wZXogPHJhZmFAdW0uZXM+DQo+IFRvOiBBbGV4YW5k ZXIgUGVsb3YgPGFAYWNrbC5pbz4NCj4gQ2M6IDZ0aXNjaEBpZXRmLm9yZywgRGFuIEdhcmNpYSA8 ZGFuLmdhcmNpYUB1bS5lcz4sIFJhZmEgTWFyaW4gTG9wZXoNCj4gPHJhZmFAdW0uZXM+LCBhY2VA aWV0Zi5vcmcNCj4gRGF0ZTogMTAvMTMvMjAxNSAxMjoxNiBBTQ0KPiBTdWJqZWN0OiBSZTogW0Fj ZV0gT3B0aW1pemluZyBFQVAtb3Zlci1Db0FQIHBheWxvYWQNCj4gU2VudCBieTogIkFjZSIgPGFj ZS1ib3VuY2VzQGlldGYub3JnPg0KPiANCj4gRGVhciBBbGV4YW5kZXI6DQo+IA0KPiBUaGFua3Mg Zm9yIHlvdXIgY29tbWVudHMgDQo+IA0KPiA+IEVsIDggb2N0IDIwMTUsIGEgbGFzIDEwOjUzLCBB bGV4YW5kZXIgUGVsb3YgPGFAYWNrbC5pbz4gZXNjcmliacOzOg0KPiA+IA0KPiA+IERlYXIgUmFm YSwNCj4gPiANCj4gPiBJJ3ZlIGJlZW4gcmVhZGluZyB0aGUgbGF0ZXN0IHZlcnNpb24gb2YgeW91 ciBkcmFmdCAoIGRyYWZ0LW1hcmluLQ0KPiBhY2Utd2ctY29hcC1lYXAtMDEudHh0ICksIGFuZCBJ IGhhdmUgYSBjb3VwbGUgb2YgcXVlc3Rpb25zIHJlZ2FyZGluZw0KPiBzb21lIG9mIHRoZSBwYXls b2FkIG9wdGlvbnMsIHdoaWNoIGNvdWxkIGJlIG9wdGltaXplZCBldmVuIGZ1cnRoZXI6DQo+ID4g DQo+ID4gMSkgVXNlIHNob3J0ZXIgbmFtZSBmb3IgdGhlIC9hdXRoIHJlc291cmNlDQo+ID4gMikg TWFuZGF0ZSB0aGUgdXNlIG9mIHplcm8tbGVuZ3RoIENvQVAgdG9rZW4NCj4gPiANCj4gPiBUaGUg Zmlyc3QsIGFuZCB0aGUgbW9yZSBzaW1wbGUgb25lLCBpcyAtIHdvdWxkIGl0IGJlIHBvc3NpYmxl IHRvIA0KPiBjaGFuZ2UgdGhlIG5hbWUgb2YgdGhlIGF1dGhlbnRpY2F0aW9uIHJlc291cmNlIGZy b20gL2F1dGggdG8gYSANCj4gc2hvcnRlciBvbmUgKGxpa2UgL2EpPyBNYXliZSBpdCBjb3VsZCBi ZSBhbiBvcHRpb24gdG8gY2hhbmdlIHRoZSANCj4gbmFtZSBvZiB0aGlzIHJlc291cmNlLCBiYXNl ZCBvbiB0aGUgdW5kZXJsYXlpbmcgYXJjaGl0ZWN0dXJlLCBlLmcuIA0KPiBhbiBSRkMgY291bGQg bWFuZGF0ZSB0aGF0IGluIGEgc3BlY2lmaWMgbmV0d29yayB0aGUgcmVzb3VyY2UgY291bGQgDQo+ IGJlIG5hbWVkIC9hLCB3aGVyZWFzIHRoZSBkZWZhdWx0IHZhbHVlIGNvdWxkIHJlbWFpbiAvYXV0 aD8NCj4gDQo+IFtSYWZhXSBJIGRvIG5vdCBzZWUgYW55IHByb2JsZW0gdG8gc2hvcnRlbiB0aGUg cmVzb3VyY2UgbmFtZS4NCj4gDQo+ID4gDQo+ID4gVGhlIHNlY29uZCwgd2hpY2ggaXMgYSBsaXR0 bGUgYml0IG1vcmUgc3VidGxlLiBUb2tlbnMgYXJlIHVzZWQgdG8gDQo+IG1hdGNoIHJlc3BvbnNl cyB0byByZXF1ZXN0cywgYnV0IGR1cmluZyB0aGUgYXV0aGVudGljYXRpb24vDQo+IGF1dGhvcml6 YXRpb24gcGhhc2UgYSBzaW5nbGUgcGVlciAoZW5kcG9pbnQpIHdvdWxkIGNvbW11bmljYXRlIHdp dGggDQo+IGEgc2luZ2xlIGF1dGhlbnRpY2F0b3IuIE1vcmVvdmVyLCB0aGUgY29tbXVuaWNhdGlv biBoYXBwZW5zIGluIGEgDQo+IHNlcmlhbCBmYXNoaW9uLCBhbmQgcmVzcG9uc2VzIGFyZSBwaWdn eWJhY2tlZC4gVGhpcyBmYWxscyBpbiB0aGUgDQo+IGNhc2Ugd2hlbiB6ZXJvLWxlbmd0aCB0b2tl biBpcyBhbHNvIGFkdmlzZWQgYnkgUkZDNzI1Mi4gRG8geW91IHRoaW5rDQo+IHRoYXQgaXQgd291 bGQgYmUgYXBwcm9wcmlhdGUgdG8gbWFrZSB0aGUgdXNlIG9mIHplcm8tbGVuZ3RoIHRva2VuIA0K PiBtYW5kYXRvcnkgZm9yIEVBUC1vdmVyLUNvQVA/DQo+IA0KPiBbUmFmYV0gSSBndWVzcyB5b3Ug YXJlIHJlZmVycmluZyB0byB0aGlzIHRleHQ6IA0KPiANCj4gIkFuIGVtcHR5IHRva2VuIHZhbHVl IGlzIGFwcHJvcHJpYXRlIGUuZy4sIHdoZW4NCj4gICAgbm8gb3RoZXIgdG9rZW5zIGFyZSBpbiB1 c2UgdG8gYSBkZXN0aW5hdGlvbiwgIm9yIHdoZW4gcmVxdWVzdHMgYXJlDQo+ICAgIG1hZGUgc2Vy aWFsbHkgcGVyIGRlc3RpbmF0aW9uIGFuZCByZWNlaXZlIHBpZ2d5YmFja2VkIHJlc3BvbnNlcy7i gJ0NCj4gDQo+IEkgd291bGQgc2F5IHRoYXQgdXNpbmcgemVyby1sZW5ndGggdG9rZW4gaXMgcG9z c2libGUuIFdoYXQgSSBhbSBub3QgDQo+IHN1cmUgaXMgd2hldGhlciBtYWtlIGl0IG1hbmRhdG9y eSBvciBub3QuIEkgbWVhbiB3ZSBjb3VsZCBzYXkgdGhhdCANCj4gaWYgdGhlIGNsaWVudCBzZW5k cyBhIHplcm8tbGVuZ3RoIHRva2VuIHRoZSBzZXJ2ZXIgY2FuIGNvbnNpZGVyIGl0IA0KPiBPSyBh cyBwZXIgdGhlIHRleHQgYWJvdmUuIElmIHRoZXJlIGlzIGEgbm9uLXplcm8gbGVuZ3RoIHRva2Vu IHZhbHVlIA0KPiBzaG91bGQgYmUgYWxzbyBmaW5lLg0KPiANCj4gV2hhdCBkbyB5b3UgdGhpbms/ DQo+IA0KPiBCZXN0IFJlZ2FyZHMuDQo+IA0KPiA+IA0KPiA+IEJlc3QsDQo+ID4gQWxleGFuZGVy DQo+ID4gDQo+ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NCj4gPiBBY2UgbWFpbGluZyBsaXN0DQo+ID4gQWNlQGlldGYub3JnDQo+ID4gaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9hY2UNCj4gDQo+IC0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gUmFmYWVsIE1hcmluIExv cGV6LCBQaEQNCj4gRGVwdC4gSW5mb3JtYXRpb24gYW5kIENvbW11bmljYXRpb25zIEVuZ2luZWVy aW5nIChESUlDKQ0KPiBGYWN1bHR5IG9mIENvbXB1dGVyIFNjaWVuY2UtVW5pdmVyc2l0eSBvZiBN dXJjaWENCj4gMzAxMDAgTXVyY2lhIC0gU3BhaW4NCj4gVGVsZjogKzM0ODY4ODg4NTAxIEZheDog KzM0ODY4ODg0MTUxIGUtbWFpbDogcmFmYUB1bS5lcw0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+IA0KPiANCj4gDQo+IA0KPiBfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBBY2UgbWFpbGlu ZyBsaXN0DQo+IEFjZUBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL2FjZQ0KDQo9PT09PS0tLS0tPT09PT0tLS0tLT09PT09Ck5vdGljZTogVGhlIGluZm9y bWF0aW9uIGNvbnRhaW5lZCBpbiB0aGlzIGUtbWFpbAptZXNzYWdlIGFuZC9vciBhdHRhY2htZW50 cyB0byBpdCBtYXkgY29udGFpbiAKY29uZmlkZW50aWFsIG9yIHByaXZpbGVnZWQgaW5mb3JtYXRp b24uIElmIHlvdSBhcmUgCm5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCBhbnkgZGlzc2VtaW5h dGlvbiwgdXNlLCAKcmV2aWV3LCBkaXN0cmlidXRpb24sIHByaW50aW5nIG9yIGNvcHlpbmcgb2Yg dGhlIAppbmZvcm1hdGlvbiBjb250YWluZWQgaW4gdGhpcyBlLW1haWwgbWVzc2FnZSAKYW5kL29y IGF0dGFjaG1lbnRzIHRvIGl0IGFyZSBzdHJpY3RseSBwcm9oaWJpdGVkLiBJZiAKeW91IGhhdmUg cmVjZWl2ZWQgdGhpcyBjb21tdW5pY2F0aW9uIGluIGVycm9yLCAKcGxlYXNlIG5vdGlmeSB1cyBi eSByZXBseSBlLW1haWwgb3IgdGVsZXBob25lIGFuZCAKaW1tZWRpYXRlbHkgYW5kIHBlcm1hbmVu dGx5IGRlbGV0ZSB0aGUgbWVzc2FnZSAKYW5kIGFueSBhdHRhY2htZW50cy4gVGhhbmsgeW91CgoK --=_alternative 00465A7265257EDD_= MIME-Version: 1.0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhpIFJhZmEsPC9mb250Pg0KPGJyPjxmb250 IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5UaGUgYXBwbGljYXRpb24gbGF5ZXIgZHJpdmVuIGFw cHJvYWNoDQppcyByZWFsbHkgaW50ZXJlc3RpbmcgaW4gdGhlIGNvbnN0cmFpbmVkIGVudmlyb25t ZW50IGNvbnRleHQuIFdlIGhhZCBhDQpzaW1pbGFyIGFwcHJvYWNoIGZvciBzZWN1cmUgc2Vzc2lv biBlc3RhYmxpc2htZW50IChhc3N1bWluZyB0aGF0IGJvb3Qtc3RyYXBwaW5nDQppcyBhbHJlYWR5 IGRvbmUpIHdoaWNoIHBlcmZvcm1zIHRoZSBzZXNzaW9uIGVzdGFibGlzaG1lbnQgaW4gQ29BUCBi dXQgdXNlcw0KdGhlIERUTFMgZW5jcnlwdGlvbiBhbmQgaGVhZGVyLXN0cnVjdHVyZSBmb3Igc2Vj dXJlIGV4Y2hhbmdlIG9mIHRoZSBhcHBsaWNhdGlvbi1sYXllcg0KbWVzc2FnZS4gQ29pbmNpZGVu dGFsbHkgd2UgaGF2ZSBhbHNvIGRlZmluZWQgYW4gb3B0aW9uIGNhbGxlZCAmcXVvdDtBdXRoJnF1 b3Q7DQouPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5I ZXJlIGlzIHRoZSBsaW5rIHRvIHRoZSBkcmFmdDogPC9mb250PjxhIGhyZWY9Imh0dHBzOi8vdG9v bHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1iaGF0dGFjaGFyeXlhLWRpY2UtbGVzcy1vbi1jb2FwLTAw Ij48Zm9udCBzaXplPTIgY29sb3I9Ymx1ZSBmYWNlPSJzYW5zLXNlcmlmIj5odHRwczovL3Rvb2xz LmlldGYub3JnL2h0bWwvZHJhZnQtYmhhdHRhY2hhcnl5YS1kaWNlLWxlc3Mtb24tY29hcC0wMDwv Zm9udD48L2E+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPg0KKEhhZCBhbiBvbGRlciB3 b3JrIGluIHByb2dyZXNzOiA8L2ZvbnQ+PGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9o dG1sL2RyYWZ0LWJoYXR0YWNoYXJ5eWEtY29yZS1jb2FwLWxpdGUtYXV0aC0wMCI+PGZvbnQgc2l6 ZT0yIGNvbG9yPWJsdWUgZmFjZT0ic2Fucy1zZXJpZiI+aHR0cHM6Ly90b29scy5pZXRmLm9yZy9o dG1sL2RyYWZ0LWJoYXR0YWNoYXJ5eWEtY29yZS1jb2FwLWxpdGUtYXV0aC0wMDwvZm9udD48L2E+ PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPi4NCkJ1dCB0aGlzIG9uZSBkaWQgbm90IHBy b3ZpZGUgY2hhbm5lbCBzZWN1cml0eSkuPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJz YW5zLXNlcmlmIj5JIHN1Ym1pdHRlZCB0aGlzIGRyYWZ0IHRvIGRpY2UsIGhvd2V2ZXIsDQpkaWNl IHdhcyBub3QgcmVhbGx5IHRoZSBwbGFjZSB0byBkaXNjdXNzIHRoaXMuIE91ciBkcmFmdCBpcyBk dWUgdG8gZXhwaXJlDQppbiBhYm91dCA0IGRheXMuPC9mb250Pg0KPGJyPg0KPGJyPg0KPGJyPg0K PGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5SZWdhcmRzPGJyPg0KQWJoaWphbiBC aGF0dGFjaGFyeXlhPGJyPg0KQXNzb2NpYXRlIENvbnN1bHRhbnQ8YnI+DQpTY2llbnRpc3QsIElu bm92YXRpb24gTGFiLCBLb2xrYXRhLCBJbmRpYTxicj4NClRhdGEgQ29uc3VsdGFuY3kgU2Vydmlj ZXM8YnI+DQpNYWlsdG86IGFiaGlqYW4uYmhhdHRhY2hhcnl5YUB0Y3MuY29tPGJyPg0KV2Vic2l0 ZTogPC9mb250PjxhIGhyZWY9aHR0cDovL3d3dy50Y3MuY29tLz48Zm9udCBzaXplPTIgZmFjZT0i c2Fucy1zZXJpZiI+aHR0cDovL3d3dy50Y3MuY29tPC9mb250PjwvYT48Zm9udCBzaXplPTIgZmFj ZT0ic2Fucy1zZXJpZiI+PGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX188YnI+DQpFeHBlcmllbmNlIGNlcnRhaW50eS4gJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7SVQgU2VydmljZXM8YnI+DQogJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7QnVzaW5l c3MgU29sdXRpb25zPGJyPg0KICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO0NvbnN1bHRpbmc8 YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCjwv Zm9udD4NCjxicj4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZxdW90O0FjZSZxdW90OyAmbHQ7YWNl LWJvdW5jZXNAaWV0Zi5vcmcmZ3Q7IHdyb3RlDQpvbiAxMC8xMy8yMDE1IDEyOjExOjQ2IEFNOjxi cj4NCjxicj4NCiZndDsgRnJvbTogUmFmYSBNYXJpbiBMb3BleiAmbHQ7cmFmYUB1bS5lcyZndDs8 L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgVG86IEFsZXhhbmRlciBQZWxv diAmbHQ7YUBhY2tsLmlvJmd0OzwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0 OyBDYzogNnRpc2NoQGlldGYub3JnLCBEYW4gR2FyY2lhICZsdDtkYW4uZ2FyY2lhQHVtLmVzJmd0 OywNClJhZmEgTWFyaW4gTG9wZXo8YnI+DQomZ3Q7ICZsdDtyYWZhQHVtLmVzJmd0OywgYWNlQGll dGYub3JnPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IERhdGU6IDEwLzEz LzIwMTUgMTI6MTYgQU08L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgU3Vi amVjdDogUmU6IFtBY2VdIE9wdGltaXppbmcgRUFQLW92ZXItQ29BUCBwYXlsb2FkPC9mb250Pjwv dHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IFNlbnQgYnk6ICZxdW90O0FjZSZxdW90OyAm bHQ7YWNlLWJvdW5jZXNAaWV0Zi5vcmcmZ3Q7PC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNp emU9Mj4mZ3Q7IDxicj4NCiZndDsgRGVhciBBbGV4YW5kZXI6PGJyPg0KJmd0OyA8YnI+DQomZ3Q7 IFRoYW5rcyBmb3IgeW91ciBjb21tZW50cyA8YnI+DQomZ3Q7IDxicj4NCiZndDsgJmd0OyBFbCA4 IG9jdCAyMDE1LCBhIGxhcyAxMDo1MywgQWxleGFuZGVyIFBlbG92ICZsdDthQGFja2wuaW8mZ3Q7 DQplc2NyaWJpw7M6PGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyBEZWFyIFJhZmEsPGJy Pg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyBJJ3ZlIGJlZW4gcmVhZGluZyB0aGUgbGF0ZXN0 IHZlcnNpb24gb2YgeW91ciBkcmFmdCAoIGRyYWZ0LW1hcmluLTxicj4NCiZndDsgYWNlLXdnLWNv YXAtZWFwLTAxLnR4dCApLCBhbmQgSSBoYXZlIGEgY291cGxlIG9mIHF1ZXN0aW9ucyByZWdhcmRp bmc8YnI+DQomZ3Q7IHNvbWUgb2YgdGhlIHBheWxvYWQgb3B0aW9ucywgd2hpY2ggY291bGQgYmUg b3B0aW1pemVkIGV2ZW4gZnVydGhlcjo8YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7IDEp IFVzZSBzaG9ydGVyIG5hbWUgZm9yIHRoZSAvYXV0aCByZXNvdXJjZTxicj4NCiZndDsgJmd0OyAy KSBNYW5kYXRlIHRoZSB1c2Ugb2YgemVyby1sZW5ndGggQ29BUCB0b2tlbjxicj4NCiZndDsgJmd0 OyA8YnI+DQomZ3Q7ICZndDsgVGhlIGZpcnN0LCBhbmQgdGhlIG1vcmUgc2ltcGxlIG9uZSwgaXMg LSB3b3VsZCBpdCBiZSBwb3NzaWJsZQ0KdG8gPGJyPg0KJmd0OyBjaGFuZ2UgdGhlIG5hbWUgb2Yg dGhlIGF1dGhlbnRpY2F0aW9uIHJlc291cmNlIGZyb20gL2F1dGggdG8gYSA8YnI+DQomZ3Q7IHNo b3J0ZXIgb25lIChsaWtlIC9hKT8gTWF5YmUgaXQgY291bGQgYmUgYW4gb3B0aW9uIHRvIGNoYW5n ZSB0aGUgPGJyPg0KJmd0OyBuYW1lIG9mIHRoaXMgcmVzb3VyY2UsIGJhc2VkIG9uIHRoZSB1bmRl cmxheWluZyBhcmNoaXRlY3R1cmUsIGUuZy4NCjxicj4NCiZndDsgYW4gUkZDIGNvdWxkIG1hbmRh dGUgdGhhdCBpbiBhIHNwZWNpZmljIG5ldHdvcmsgdGhlIHJlc291cmNlIGNvdWxkDQo8YnI+DQom Z3Q7IGJlIG5hbWVkIC9hLCB3aGVyZWFzIHRoZSBkZWZhdWx0IHZhbHVlIGNvdWxkIHJlbWFpbiAv YXV0aD88YnI+DQomZ3Q7IDxicj4NCiZndDsgW1JhZmFdIEkgZG8gbm90IHNlZSBhbnkgcHJvYmxl bSB0byBzaG9ydGVuIHRoZSByZXNvdXJjZSBuYW1lLjxicj4NCiZndDsgPGJyPg0KJmd0OyAmZ3Q7 IDxicj4NCiZndDsgJmd0OyBUaGUgc2Vjb25kLCB3aGljaCBpcyBhIGxpdHRsZSBiaXQgbW9yZSBz dWJ0bGUuIFRva2VucyBhcmUgdXNlZA0KdG8gPGJyPg0KJmd0OyBtYXRjaCByZXNwb25zZXMgdG8g cmVxdWVzdHMsIGJ1dCBkdXJpbmcgdGhlIGF1dGhlbnRpY2F0aW9uLzxicj4NCiZndDsgYXV0aG9y aXphdGlvbiBwaGFzZSBhIHNpbmdsZSBwZWVyIChlbmRwb2ludCkgd291bGQgY29tbXVuaWNhdGUg d2l0aA0KPGJyPg0KJmd0OyBhIHNpbmdsZSBhdXRoZW50aWNhdG9yLiBNb3Jlb3ZlciwgdGhlIGNv bW11bmljYXRpb24gaGFwcGVucyBpbiBhIDxicj4NCiZndDsgc2VyaWFsIGZhc2hpb24sIGFuZCBy ZXNwb25zZXMgYXJlIHBpZ2d5YmFja2VkLiBUaGlzIGZhbGxzIGluIHRoZSA8YnI+DQomZ3Q7IGNh c2Ugd2hlbiB6ZXJvLWxlbmd0aCB0b2tlbiBpcyBhbHNvIGFkdmlzZWQgYnkgUkZDNzI1Mi4gRG8g eW91IHRoaW5rPGJyPg0KJmd0OyB0aGF0IGl0IHdvdWxkIGJlIGFwcHJvcHJpYXRlIHRvIG1ha2Ug dGhlIHVzZSBvZiB6ZXJvLWxlbmd0aCB0b2tlbg0KPGJyPg0KJmd0OyBtYW5kYXRvcnkgZm9yIEVB UC1vdmVyLUNvQVA/PGJyPg0KJmd0OyA8YnI+DQomZ3Q7IFtSYWZhXSBJIGd1ZXNzIHlvdSBhcmUg cmVmZXJyaW5nIHRvIHRoaXMgdGV4dDogJm5ic3A7PGJyPg0KJmd0OyA8YnI+DQomZ3Q7ICZxdW90 O0FuIGVtcHR5IHRva2VuIHZhbHVlIGlzIGFwcHJvcHJpYXRlIGUuZy4sIHdoZW48YnI+DQomZ3Q7 ICZuYnNwOyAmbmJzcDtubyBvdGhlciB0b2tlbnMgYXJlIGluIHVzZSB0byBhIGRlc3RpbmF0aW9u LCAmcXVvdDtvcg0Kd2hlbiByZXF1ZXN0cyBhcmU8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDttYWRl IHNlcmlhbGx5IHBlciBkZXN0aW5hdGlvbiBhbmQgcmVjZWl2ZSBwaWdneWJhY2tlZA0KcmVzcG9u c2VzLuKAnTxicj4NCiZndDsgPGJyPg0KJmd0OyBJIHdvdWxkIHNheSB0aGF0IHVzaW5nIHplcm8t bGVuZ3RoIHRva2VuIGlzIHBvc3NpYmxlLiBXaGF0IEkgYW0gbm90DQo8YnI+DQomZ3Q7IHN1cmUg aXMgd2hldGhlciBtYWtlIGl0IG1hbmRhdG9yeSBvciBub3QuIEkgbWVhbiB3ZSBjb3VsZCBzYXkg dGhhdA0KPGJyPg0KJmd0OyBpZiB0aGUgY2xpZW50IHNlbmRzIGEgemVyby1sZW5ndGggdG9rZW4g dGhlIHNlcnZlciBjYW4gY29uc2lkZXIgaXQNCjxicj4NCiZndDsgT0sgYXMgcGVyIHRoZSB0ZXh0 IGFib3ZlLiBJZiB0aGVyZSBpcyBhIG5vbi16ZXJvIGxlbmd0aCB0b2tlbiB2YWx1ZQ0KPGJyPg0K Jmd0OyBzaG91bGQgYmUgYWxzbyBmaW5lLjxicj4NCiZndDsgPGJyPg0KJmd0OyBXaGF0IGRvIHlv dSB0aGluaz88YnI+DQomZ3Q7IDxicj4NCiZndDsgQmVzdCBSZWdhcmRzLjxicj4NCiZndDsgPGJy Pg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyBCZXN0LDxicj4NCiZndDsgJmd0OyBBbGV4YW5k ZXI8YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7IF9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KJmd0OyAmZ3Q7IEFjZSBtYWlsaW5nIGxpc3Q8 YnI+DQomZ3Q7ICZndDsgQWNlQGlldGYub3JnPGJyPg0KJmd0OyAmZ3Q7IDwvZm9udD48L3R0Pjxh IGhyZWY9aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9hY2U+PHR0Pjxmb250 IHNpemU9Mj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2FjZTwvZm9udD48 L3R0PjwvYT48dHQ+PGZvbnQgc2l6ZT0yPjxicj4NCiZndDsgPGJyPg0KJmd0OyAtLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPGJyPg0KJmd0OyBS YWZhZWwgTWFyaW4gTG9wZXosIFBoRDxicj4NCiZndDsgRGVwdC4gSW5mb3JtYXRpb24gYW5kIENv bW11bmljYXRpb25zIEVuZ2luZWVyaW5nIChESUlDKTxicj4NCiZndDsgRmFjdWx0eSBvZiBDb21w dXRlciBTY2llbmNlLVVuaXZlcnNpdHkgb2YgTXVyY2lhPGJyPg0KJmd0OyAzMDEwMCBNdXJjaWEg LSBTcGFpbjxicj4NCiZndDsgVGVsZjogKzM0ODY4ODg4NTAxIEZheDogKzM0ODY4ODg0MTUxIGUt bWFpbDogcmFmYUB1bS5lczxicj4NCiZndDsgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTxicj4NCiZndDsgPGJyPg0KJmd0OyA8YnI+DQomZ3Q7 IDxicj4NCiZndDsgPGJyPg0KJmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXzxicj4NCiZndDsgQWNlIG1haWxpbmcgbGlzdDxicj4NCiZndDsgQWNlQGll dGYub3JnPGJyPg0KJmd0OyA8L2ZvbnQ+PC90dD48YSBocmVmPWh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vYWNlPjx0dD48Zm9udCBzaXplPTI+aHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9hY2U8L2ZvbnQ+PC90dD48L2E+PHR0Pjxmb250IHNpemU9Mj48 YnI+DQo8L2ZvbnQ+PC90dD4NCjxwPj09PT09LS0tLS09PT09PS0tLS0tPT09PT08YnI+Ck5vdGlj ZTogVGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpbiB0aGlzIGUtbWFpbDxicj4KbWVzc2FnZSBh bmQvb3IgYXR0YWNobWVudHMgdG8gaXQgbWF5IGNvbnRhaW4gPGJyPgpjb25maWRlbnRpYWwgb3Ig cHJpdmlsZWdlZCBpbmZvcm1hdGlvbi4gSWYgeW91IGFyZSA8YnI+Cm5vdCB0aGUgaW50ZW5kZWQg cmVjaXBpZW50LCBhbnkgZGlzc2VtaW5hdGlvbiwgdXNlLCA8YnI+CnJldmlldywgZGlzdHJpYnV0 aW9uLCBwcmludGluZyBvciBjb3B5aW5nIG9mIHRoZSA8YnI+CmluZm9ybWF0aW9uIGNvbnRhaW5l ZCBpbiB0aGlzIGUtbWFpbCBtZXNzYWdlIDxicj4KYW5kL29yIGF0dGFjaG1lbnRzIHRvIGl0IGFy ZSBzdHJpY3RseSBwcm9oaWJpdGVkLiBJZiA8YnI+CnlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgY29t bXVuaWNhdGlvbiBpbiBlcnJvciwgPGJyPgpwbGVhc2Ugbm90aWZ5IHVzIGJ5IHJlcGx5IGUtbWFp bCBvciB0ZWxlcGhvbmUgYW5kIDxicj4KaW1tZWRpYXRlbHkgYW5kIHBlcm1hbmVudGx5IGRlbGV0 ZSB0aGUgbWVzc2FnZSA8YnI+CmFuZCBhbnkgYXR0YWNobWVudHMuIFRoYW5rIHlvdTwvcD4KCjxw PjwvcD4= --=_alternative 00465A7265257EDD_=-- From nobody Wed Oct 14 02:21:15 2015 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38CEE1B2D1C; Wed, 14 Oct 2015 02:21:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.549 X-Spam-Level: X-Spam-Status: No, score=-1.549 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QzxTxbplrKFX; Wed, 14 Oct 2015 02:21:01 -0700 (PDT) Received: from relay3-d.mail.gandi.net (relay3-d.mail.gandi.net [IPv6:2001:4b98:c:538::195]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 868B51B2D08; Wed, 14 Oct 2015 02:17:11 -0700 (PDT) Received: from dhcp-salsa-i-130-75.rennes.enst-bretagne.fr (unknown [IPv6:2001:660:7301:3728:c46c:5963:1cca:3408]) (Authenticated sender: alex@ackl.io) by relay3-d.mail.gandi.net (Postfix) with ESMTPSA id 878D0A80F2; Wed, 14 Oct 2015 11:17:08 +0200 (CEST) To: Abhijan Bhattacharyya , Rafa Marin Lopez References: <56162F1A.5020503@ackl.io> From: Alexander Pelov Message-ID: <561E1D9F.3060803@ackl.io> Date: Wed, 14 Oct 2015 11:17:19 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------020201030801020505020808" Archived-At: Cc: 6tisch@ietf.org, dan.garcia@um.es, ace@ietf.org Subject: Re: [Ace] Optimizing EAP-over-CoAP payload X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 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 Oct 2015 09:21:04 -0000 This is a multi-part message in MIME format. --------------020201030801020505020808 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Hi Abhijan, Thanks for pointing your draft - very interesting work. However, it seems to me that it solves only a subset of the problems at which EAP-over-CoAP is aimed. Most notably, it is limited to a specific authentication method (DTLS-PSK), whereas EAP is an extensible framework. Maybe there could be some kind of cooperation between the two, e.g. you could specify an EAP method like EAP-DTLS-PSK-short? Best, Alexander Le 13/10/2015 14:48, Abhijan Bhattacharyya a écrit : > Hi Rafa, > The application layer driven approach is really interesting in the > constrained environment context. We had a similar approach for secure > session establishment (assuming that boot-strapping is already done) > which performs the session establishment in CoAP but uses the DTLS > encryption and header-structure for secure exchange of the > application-layer message. Coincidentally we have also defined an > option called "Auth" . > > Here is the link to the draft: > https://tools.ietf.org/html/draft-bhattacharyya-dice-less-on-coap-00(Had > an older work in progress: > https://tools.ietf.org/html/draft-bhattacharyya-core-coap-lite-auth-00. But > this one did not provide channel security). > I submitted this draft to dice, however, dice was not really the place > to discuss this. Our draft is due to expire in about 4 days. > > > > Regards > Abhijan Bhattacharyya > Associate Consultant > Scientist, Innovation Lab, Kolkata, India > Tata Consultancy Services > Mailto: abhijan.bhattacharyya@tcs.com > Website: http://www.tcs.com > ____________________________________________ > Experience certainty. IT Services > Business Solutions > Consulting > ____________________________________________ > > > "Ace" wrote on 10/13/2015 12:11:46 AM: > > > From: Rafa Marin Lopez > > To: Alexander Pelov > > Cc: 6tisch@ietf.org, Dan Garcia , Rafa Marin Lopez > > , ace@ietf.org > > Date: 10/13/2015 12:16 AM > > Subject: Re: [Ace] Optimizing EAP-over-CoAP payload > > Sent by: "Ace" > > > > Dear Alexander: > > > > Thanks for your comments > > > > > El 8 oct 2015, a las 10:53, Alexander Pelov escribió: > > > > > > Dear Rafa, > > > > > > I've been reading the latest version of your draft ( draft-marin- > > ace-wg-coap-eap-01.txt ), and I have a couple of questions regarding > > some of the payload options, which could be optimized even further: > > > > > > 1) Use shorter name for the /auth resource > > > 2) Mandate the use of zero-length CoAP token > > > > > > The first, and the more simple one, is - would it be possible to > > change the name of the authentication resource from /auth to a > > shorter one (like /a)? Maybe it could be an option to change the > > name of this resource, based on the underlaying architecture, e.g. > > an RFC could mandate that in a specific network the resource could > > be named /a, whereas the default value could remain /auth? > > > > [Rafa] I do not see any problem to shorten the resource name. > > > > > > > > The second, which is a little bit more subtle. Tokens are used to > > match responses to requests, but during the authentication/ > > authorization phase a single peer (endpoint) would communicate with > > a single authenticator. Moreover, the communication happens in a > > serial fashion, and responses are piggybacked. This falls in the > > case when zero-length token is also advised by RFC7252. Do you think > > that it would be appropriate to make the use of zero-length token > > mandatory for EAP-over-CoAP? > > > > [Rafa] I guess you are referring to this text: > > > > "An empty token value is appropriate e.g., when > > no other tokens are in use to a destination, "or when requests are > > made serially per destination and receive piggybacked responses.” > > > > I would say that using zero-length token is possible. What I am not > > sure is whether make it mandatory or not. I mean we could say that > > if the client sends a zero-length token the server can consider it > > OK as per the text above. If there is a non-zero length token value > > should be also fine. > > > > What do you think? > > > > Best Regards. > > > > > > > > Best, > > > Alexander > > > > > > _______________________________________________ > > > Ace mailing list > > > Ace@ietf.org > > > https://www.ietf.org/mailman/listinfo/ace > > > > ------------------------------------------------------- > > Rafael Marin Lopez, PhD > > Dept. Information and Communications Engineering (DIIC) > > Faculty of Computer Science-University of Murcia > > 30100 Murcia - Spain > > Telf: +34868888501 Fax: +34868884151 e-mail: rafa@um.es > > ------------------------------------------------------- > > > > > > > > > > _______________________________________________ > > Ace mailing list > > Ace@ietf.org > > https://www.ietf.org/mailman/listinfo/ace > > =====-----=====-----===== > Notice: The information contained in this e-mail > message and/or attachments to it may contain > confidential or privileged information. If you are > not the intended recipient, any dissemination, use, > review, distribution, printing or copying of the > information contained in this e-mail message > and/or attachments to it are strictly prohibited. If > you have received this communication in error, > please notify us by reply e-mail or telephone and > immediately and permanently delete the message > and any attachments. Thank you > --------------020201030801020505020808 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Hi Abhijan,

Thanks for pointing your draft - very interesting work.

However, it seems to me that it solves only a subset of the problems at which EAP-over-CoAP is aimed. Most notably, it is limited to a specific authentication method (DTLS-PSK), whereas EAP is an extensible framework. Maybe there could be some kind of cooperation between the two, e.g. you could specify an EAP method like EAP-DTLS-PSK-short?

Best,
Alexander


Le 13/10/2015 14:48, Abhijan Bhattacharyya a écrit :
Hi Rafa,
The application layer driven approach is really interesting in the constrained environment context. We had a similar approach for secure session establishment (assuming that boot-strapping is already done) which performs the session establishment in CoAP but uses the DTLS encryption and header-structure for secure exchange of the application-layer message. Coincidentally we have also defined an option called "Auth" .

Here is the link to the draft: https://tools.ietf.org/html/draft-bhattacharyya-dice-less-on-coap-00 (Had an older work in progress: https://tools.ietf.org/html/draft-bhattacharyya-core-coap-lite-auth-00. But this one did not provide channel security).
I submitted this draft to dice, however, dice was not really the place to discuss this. Our draft is due to expire in about 4 days.



Regards
Abhijan Bhattacharyya
Associate Consultant
Scientist, Innovation Lab, Kolkata, India
Tata Consultancy Services
Mailto: abhijan.bhattacharyya@tcs.com
Website: http://www.tcs.com
____________________________________________
Experience certainty.        IT Services
                       Business Solutions
                       Consulting
____________________________________________

"Ace" <ace-bounces@ietf.org> wrote on 10/13/2015 12:11:46 AM:

> From: Rafa Marin Lopez <rafa@um.es>
> To: Alexander Pelov <a@ackl.io>
> Cc: 6tisch@ietf.org, Dan Garcia <dan.garcia@um.es>, Rafa Marin Lopez
> <rafa@um.es>, ace@ietf.org
> Date: 10/13/2015 12:16 AM
> Subject: Re: [Ace] Optimizing EAP-over-CoAP payload
> Sent by: "Ace" <ace-bounces@ietf.org>
>
> Dear Alexander:
>
> Thanks for your comments
>
> > El 8 oct 2015, a las 10:53, Alexander Pelov <a@ackl.io> escribió:
> >
> > Dear Rafa,
> >
> > I've been reading the latest version of your draft ( draft-marin-
> ace-wg-coap-eap-01.txt ), and I have a couple of questions regarding
> some of the payload options, which could be optimized even further:
> >
> > 1) Use shorter name for the /auth resource
> > 2) Mandate the use of zero-length CoAP token
> >
> > The first, and the more simple one, is - would it be possible to
> change the name of the authentication resource from /auth to a
> shorter one (like /a)? Maybe it could be an option to change the
> name of this resource, based on the underlaying architecture, e.g.
> an RFC could mandate that in a specific network the resource could
> be named /a, whereas the default value could remain /auth?
>
> [Rafa] I do not see any problem to shorten the resource name.
>
> >
> > The second, which is a little bit more subtle. Tokens are used to
> match responses to requests, but during the authentication/
> authorization phase a single peer (endpoint) would communicate with
> a single authenticator. Moreover, the communication happens in a
> serial fashion, and responses are piggybacked. This falls in the
> case when zero-length token is also advised by RFC7252. Do you think
> that it would be appropriate to make the use of zero-length token
> mandatory for EAP-over-CoAP?
>
> [Rafa] I guess you are referring to this text:  
>
> "An empty token value is appropriate e.g., when
>    no other tokens are in use to a destination, "or when requests are
>    made serially per destination and receive piggybacked responses.”
>
> I would say that using zero-length token is possible. What I am not
> sure is whether make it mandatory or not. I mean we could say that
> if the client sends a zero-length token the server can consider it
> OK as per the text above. If there is a non-zero length token value
> should be also fine.
>
> What do you think?
>
> Best Regards.
>
> >
> > Best,
> > Alexander
> >
> > _______________________________________________
> > Ace mailing list
> > Ace@ietf.org
> > https://www.ietf.org/mailman/listinfo/ace
>
> -------------------------------------------------------
> Rafael Marin Lopez, PhD
> Dept. Information and Communications Engineering (DIIC)
> Faculty of Computer Science-University of Murcia
> 30100 Murcia - Spain
> Telf: +34868888501 Fax: +34868884151 e-mail: rafa@um.es
> -------------------------------------------------------
>
>
>
>
> _______________________________________________
> Ace mailing list
> Ace@ietf.org
> https://www.ietf.org/mailman/listinfo/ace

=====-----=====-----=====
Notice: The information contained in this e-mail
message and/or attachments to it may contain
confidential or privileged information. If you are
not the intended recipient, any dissemination, use,
review, distribution, printing or copying of the
information contained in this e-mail message
and/or attachments to it are strictly prohibited. If
you have received this communication in error,
please notify us by reply e-mail or telephone and
immediately and permanently delete the message
and any attachments. Thank you


--------------020201030801020505020808-- From nobody Wed Oct 14 02:24:24 2015 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BEEF1B2CC3; Wed, 14 Oct 2015 02:24:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.55 X-Spam-Level: X-Spam-Status: No, score=-1.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_FR=0.35] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tn3Dw4elUdRz; Wed, 14 Oct 2015 02:24:21 -0700 (PDT) Received: from relay3-d.mail.gandi.net (relay3-d.mail.gandi.net [IPv6:2001:4b98:c:538::195]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 057F31B2CD0; Wed, 14 Oct 2015 02:24:21 -0700 (PDT) Received: from dhcp-salsa-i-130-75.rennes.enst-bretagne.fr (unknown [IPv6:2001:660:7301:3728:c46c:5963:1cca:3408]) (Authenticated sender: alex@ackl.io) by relay3-d.mail.gandi.net (Postfix) with ESMTPSA id 318D0A80F2; Wed, 14 Oct 2015 11:24:19 +0200 (CEST) To: Carsten Bormann , Rafa Marin Lopez References: <56162F1A.5020503@ackl.io> <561C038C.7090305@tzi.org> From: Alexander Pelov Message-ID: <561E1F58.4030501@ackl.io> Date: Wed, 14 Oct 2015 11:24:40 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <561C038C.7090305@tzi.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: 6tisch@ietf.org, Dan Garcia , ace@ietf.org Subject: Re: [Ace] Optimizing EAP-over-CoAP payload X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 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 Oct 2015 09:24:22 -0000 Hi Carsten, yes, you are right about this! Thanks for pointing it out. Indeed, the wording should be carefully selected, and I think in some (most?) cases the token can be zero-length. However, as you correctly state, this should not be a MUST. If the requester includes a token, then the responder must conform to the CoAP specification. Best, Alexander Le 12/10/2015 21:01, Carsten Bormann a écrit : > Rafa Marin Lopez wrote: >> I would say that using zero-length token is possible. What I am not sure is whether make it mandatory or not. I mean we could say that if the client sends a zero-length token the server can consider it OK as per the text above. If there is a non-zero length token value should be also fine. > There is never a reason to discuss token values -- these are chosen by > the requester based on its needs, and there is never a reason for a > responder to question that choice. > > Grüße, Carsten > > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace From nobody Wed Oct 14 04:10:28 2015 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25C391A016B; Wed, 14 Oct 2015 04:10:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lf61ErwmoKAc; Wed, 14 Oct 2015 04:10:23 -0700 (PDT) Received: from inkolg01.tcs.com (inkolg01.tcs.com [121.241.215.10]) by ietfa.amsl.com (Postfix) with ESMTP id B12321A0161; Wed, 14 Oct 2015 04:10:19 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A2AyAgBINR5W/wQXEqxeg3puvgIBDYFaFwEJgnKCCn8CHIFVFAEBAQEBAQGBCoQmAQEBAwEBAQEgSwsFCwsHBgEDAQIBAigDAgICJR8DBggGCgEIFAeICxWuKAEBAW+TVgEBAQEBAQEBAQEBAQEBAQEBAQEBAReFS2qEOYEGhDQOMAoMAQQHBoIoOxQdgRQFhz2FUXSIE4UZhUuEDxWEJZIJg28fAQGCUQIdgVxphSaBSQEBAQ X-IPAS-Result: A2AyAgBINR5W/wQXEqxeg3puvgIBDYFaFwEJgnKCCn8CHIFVFAEBAQEBAQGBCoQmAQEBAwEBAQEgSwsFCwsHBgEDAQIBAigDAgICJR8DBggGCgEIFAeICxWuKAEBAW+TVgEBAQEBAQEBAQEBAQEBAQEBAQEBAReFS2qEOYEGhDQOMAoMAQQHBoIoOxQdgRQFhz2FUXSIE4UZhUuEDxWEJZIJg28fAQGCUQIdgVxphSaBSQEBAQ X-IronPort-AV: E=Sophos;i="5.17,681,1437417000"; d="scan'208";a="13034318" X-DISCLAIMER: FALSE In-Reply-To: <561E1D9F.3060803@ackl.io> References: <56162F1A.5020503@ackl.io> <561E1D9F.3060803@ackl.io> To: Alexander Pelov MIME-Version: 1.0 X-KeepSent: A8F0C789:50692FBC-65257EDE:003B852E; type=4; name=$KeepSent X-Mailer: IBM Notes Release 9.0 March 08, 2013 Message-ID: From: Abhijan Bhattacharyya Date: Wed, 14 Oct 2015 16:40:07 +0530 X-MIMETrack: Serialize by Router on INKOLM102/TCS(Release 9.0.1FP4|June 07, 2015) at 10/14/2015 16:40:08, Serialize complete at 10/14/2015 16:40:08 Content-Type: multipart/alternative; boundary="=_alternative 003D5A1B65257EDE_=" Archived-At: Cc: 6tisch@ietf.org, Ace , Rafa Marin Lopez , dan.garcia@um.es, ace@ietf.org Subject: Re: [Ace] Optimizing EAP-over-CoAP payload X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 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 Oct 2015 11:10:27 -0000 This is a multipart message in MIME format. --=_alternative 003D5A1B65257EDE_= Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 SGkgQWxleGFuZGVyLA0KDQo+IFRoYW5rcyBmb3IgcG9pbnRpbmcgeW91ciBkcmFmdCAtIHZlcnkg aW50ZXJlc3Rpbmcgd29yay4NClRoYW5rcyBhIGxvdC4NCg0KPiBIb3dldmVyLCBpdCBzZWVtcyB0 byBtZSB0aGF0IGl0IHNvbHZlcyBvbmx5IGEgc3Vic2V0IG9mIHRoZSBwcm9ibGVtcw0KPiBhdCB3 aGljaCBFQVAtb3Zlci1Db0FQIGlzIGFpbWVkLg0KWW91IGFyZSByaWdodC4NClRvIGJlIHByZWNp c2UsIHRoZSB3b3JrIEkgcG9pbnRlZCBvdXQgYWN0dWFsbHkgc3RhcnRzIGFmdGVyIHRoZSBFQVAu IFdlIA0KdHJpZWQgYSBwcm9wb3NlIGEgdmVyeSBsaWdodHdlaWdodCB2ZXJzaW9uIG9mIHNlc3Np b24ta2V5IGVzdGFibGlzaG1lbnQgDQp1c2luZyBDb0FQIGFzc3VtaW5nIHRoYXQgdGhlIG1hc3Rl ciBrZXlzIGhhdmUgYmVlbiBwcmV2aW91c2x5IGNvbmZpZ3VyZWQgDQoobWF5IGJlIHRocm91Z2gg RUFQISkuIFRoZSBpZGVhIGlzIGFzIGZvbGxvd3M6DQoNClRoZSBEVExTIHByb3RvY29sIGNhbiBi ZSBzZXBhcmF0ZWQgaW50byB0d28gcGFydHMgaW4gdGVybXMgb2YgDQpmdW5jdGlvbmFsaXR5LiBG aXJzdCBpcyBzZWN1cmUgc2Vzc2lvbiBlc3RhYmxpc2htZW50IGFuZCB0aGUgbmV4dCBvbmUgaXMg DQpwcm92aWRpbmcgY2hhbm5lbCBzZWN1cml0eSB3aXRoIGluaGVyZW50IHJlbGlhYmlsaXR5IGFu ZCByZXBsYXkgDQpwcm90ZWN0aW9uLiBIb3dldmVyLCB3ZSB0aGluayB0aGF0IHRoZSByZXF1aXJl ZCBleGNoYW5nZXMgaW4gRFRMUyBzZXNzaW9uIA0KZXN0YWJsaXNobWVudCAoSSBhbSBvbmx5IHRh bGtpbmcgYWJvdXQgc3ltbWV0cmljIHN5c3RlbSkgbWF5IGJlIGJpdCBoZWF2eSANCmZvciByZWFs bHkgY29uc3RyYWluZWQgbmV0d29ya3Mgd2l0aCBpbnRlcm1pdHRlbnQgY29ubmVjdGl2aXR5IGFu ZCANCmJhbmR3aWR0aCBjb25zdHJhaW50LiBTbywgd2UgcHJvcG9zZSB0byBwdXNoIHRoZSBzZXNz aW9uIGVzdGFibGlzaG1lbnQgDQpwYXJ0IHRvIGFwcGxpY2F0aW9uIGxheWVyIChDb0FQKSBhbmQg bGV2ZXJhZ2UgdGhlIGluaGVyZW50ICJsaWdodHdlaWdodCANCnlldCByZWxpYWJsZSIgbmF0dXJl IG9mIENvQVAgKGNvbnNpZGVyaW5nIHRoZSBDT04gbW9kZSkuIFdlIGJlbGlldmUsIGl0IGlzIA0K YmV0dGVyIHRvIHB1dCBtb3JlIGNvbnRyb2wgdG8gdGhlIGFwcGxpY2F0aW9uIGxheWVyIHdoZW4g eW91IGFyZSBkZWFsaW5nIA0Kd2l0aCBjb25zdHJhaW5lZCBlbnZpcm9ubWVudC4gVGhlIGFwcGxp Y2F0aW9uIGxheWVyIHNlc3Npb24gZXN0YWJsaXNobWVudCANCm1lY2hhbmlzbSBvdmVyIENvQVAg ZXN0YWJsaXNoZXMgYSBzZWN1cmUgc2Vzc2lvbiB3aGljaCBmaW5hbGx5IHByb2R1Y2VzIA0KdGhl IHNhbWUgdHVwbGUgYXMgaW4gRFRMUyBzZXNzaW9uIGVzdGFibGlzaG1lbnQgLGkuZSwgPFNlcnZl cl93cml0ZV9rZXksIA0KQ2xpZW50X3dyaXRlX2tleSwgU2VydmVyX0lWLCBDbGllbnRfSVY+Lg0K DQpUaGVuIHRoZSByZXNwb25zaWJpbGl0eSBpcyB0cmFuc2ZlcnJlZCB0byB0aGUgdHJhbnNwb3J0 IGxheWVyIGFuZCB0aGUgDQpjaGFubmVsIHNlY3VyaXR5IGlzIHByb3ZpZGVkIHVzaW5nIGNvbnZl bnRpb25hbCBEVExTLVBTSyByZWNvcmQgDQplbmNyeXB0aW9uLiBUaHVzIGl0IHRha2VzIGFsbCB0 aGUgYWR2YW50YWdlIG9mIERUTFMgcmVjb3JkIGVuY3J5cHRpb24uIFRoZSANCmlkZWEgaXMgdG8g dXNlIHRoZSBiZXN0IG9mIHRoZSB3b3JsZHMuIENvQVAncyBsaWdodHdlaWdodC1uZXNzIGNvdXBs ZWQgDQp3aXRoIHJlY29yZCBwcm90ZWN0aW9uIGZyb20gRFRMUy4gVGhpcyB3YXMganVzdCBhbiBl eHBlcmltZW50YWwgd29yayB0byANCnNvbHZlIHNvbWUgaW1tZWRpYXRlIHByb2JsZW1zIGF0IGhh bmQuIEhvd2V2ZXIsIGlmIHRoaXMga2luZCBvZiANCmNyb3NzLWxheWVyIGFwcHJvYWNoIG1ha2Vz IHNlbnNlIHRoZW4gaXQgbWF5ICBzcGF3biBleHRlbmRlZCBpZGVhcy4NCg0KID4gLi4uLi4gTWF5 YmUgdGhlcmUgY291bGQgYmUgc29tZSBraW5kIG9mIGNvb3BlcmF0aW9uIC4uLi4uDQpJdHMgYSBn b29kIHByb3Bvc2l0aW9uLiBCdXQgd2UgbmVlZCB0byBrbm93IGlmIHRoZXJlIGlzIGVub3VnaCB0 cmFjdGlvbiBpbiANCnRoZSBjb21tdW5pdHkgZm9yIGV4dGVuZGluZyB0aGUgd29yay4gTWF5IGJl IHdlIGNhbiBkaXNjdXNzIGlmIHdlIGhhcHBlbiANCnRvIG1lZXQgaW4gWW9rb2hhbWEuDQoNClJl Z2FyZHMNCkFiaGlqYW4gQmhhdHRhY2hhcnl5YQ0KQXNzb2NpYXRlIENvbnN1bHRhbnQNClNjaWVu dGlzdCwgSW5ub3ZhdGlvbiBMYWIsIEtvbGthdGEsIEluZGlhDQpUYXRhIENvbnN1bHRhbmN5IFNl cnZpY2VzDQpNYWlsdG86IGFiaGlqYW4uYmhhdHRhY2hhcnl5YUB0Y3MuY29tDQpXZWJzaXRlOiBo dHRwOi8vd3d3LnRjcy5jb20NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQpFeHBlcmllbmNlIGNlcnRhaW50eS4gICBJVCBTZXJ2aWNlcw0KICAgICAgICAgICAg ICAgICAgICAgICAgQnVzaW5lc3MgU29sdXRpb25zDQogICAgICAgICAgICAgICAgICAgICAgICBD b25zdWx0aW5nDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K DQoNCiJBY2UiIDxhY2UtYm91bmNlc0BpZXRmLm9yZz4gd3JvdGUgb24gMTAvMTQvMjAxNSAwMjo0 NzoxOSBQTToNCg0KPiBGcm9tOiBBbGV4YW5kZXIgUGVsb3YgPGFAYWNrbC5pbz4NCj4gVG86IEFi aGlqYW4gQmhhdHRhY2hhcnl5YSA8YWJoaWphbi5iaGF0dGFjaGFyeXlhQHRjcy5jb20+LCBSYWZh IA0KPiBNYXJpbiBMb3BleiA8cmFmYUB1bS5lcz4NCj4gQ2M6IDZ0aXNjaEBpZXRmLm9yZywgZGFu LmdhcmNpYUB1bS5lcywgYWNlQGlldGYub3JnDQo+IERhdGU6IDEwLzE0LzIwMTUgMDI6NTEgUE0N Cj4gU3ViamVjdDogUmU6IFtBY2VdIE9wdGltaXppbmcgRUFQLW92ZXItQ29BUCBwYXlsb2FkDQo+ IFNlbnQgYnk6ICJBY2UiIDxhY2UtYm91bmNlc0BpZXRmLm9yZz4NCj4gDQo+IEhpIEFiaGlqYW4s DQo+IA0KPiBUaGFua3MgZm9yIHBvaW50aW5nIHlvdXIgZHJhZnQgLSB2ZXJ5IGludGVyZXN0aW5n IHdvcmsuDQo+IA0KPiBIb3dldmVyLCBpdCBzZWVtcyB0byBtZSB0aGF0IGl0IHNvbHZlcyBvbmx5 IGEgc3Vic2V0IG9mIHRoZSBwcm9ibGVtcw0KPiBhdCB3aGljaCBFQVAtb3Zlci1Db0FQIGlzIGFp bWVkLiBNb3N0IG5vdGFibHksIGl0IGlzIGxpbWl0ZWQgdG8gYSANCj4gc3BlY2lmaWMgYXV0aGVu dGljYXRpb24gbWV0aG9kIChEVExTLVBTSyksIHdoZXJlYXMgRUFQIGlzIGFuIA0KPiBleHRlbnNp YmxlIGZyYW1ld29yay4gTWF5YmUgdGhlcmUgY291bGQgYmUgc29tZSBraW5kIG9mIGNvb3BlcmF0 aW9uIA0KPiBiZXR3ZWVuIHRoZSB0d28sIGUuZy4geW91IGNvdWxkIHNwZWNpZnkgYW4gRUFQIG1l dGhvZCBsaWtlIA0KRUFQLURUTFMtUFNLLXNob3J0Pw0KPiANCj4gQmVzdCwNCj4gQWxleGFuZGVy DQo+IA0KDQo+IExlIDEzLzEwLzIwMTUgMTQ6NDgsIEFiaGlqYW4gQmhhdHRhY2hhcnl5YSBhIMOp Y3JpdCA6DQo+IEhpIFJhZmEsIA0KPiBUaGUgYXBwbGljYXRpb24gbGF5ZXIgZHJpdmVuIGFwcHJv YWNoIGlzIHJlYWxseSBpbnRlcmVzdGluZyBpbiB0aGUgDQo+IGNvbnN0cmFpbmVkIGVudmlyb25t ZW50IGNvbnRleHQuIFdlIGhhZCBhIHNpbWlsYXIgYXBwcm9hY2ggZm9yIA0KPiBzZWN1cmUgc2Vz c2lvbiBlc3RhYmxpc2htZW50IChhc3N1bWluZyB0aGF0IGJvb3Qtc3RyYXBwaW5nIGlzIA0KPiBh bHJlYWR5IGRvbmUpIHdoaWNoIHBlcmZvcm1zIHRoZSBzZXNzaW9uIGVzdGFibGlzaG1lbnQgaW4g Q29BUCBidXQgDQo+IHVzZXMgdGhlIERUTFMgZW5jcnlwdGlvbiBhbmQgaGVhZGVyLXN0cnVjdHVy ZSBmb3Igc2VjdXJlIGV4Y2hhbmdlIG9mDQo+IHRoZSBhcHBsaWNhdGlvbi1sYXllciBtZXNzYWdl LiBDb2luY2lkZW50YWxseSB3ZSBoYXZlIGFsc28gZGVmaW5lZCANCj4gYW4gb3B0aW9uIGNhbGxl ZCAiQXV0aCIgLiANCj4gDQo+IEhlcmUgaXMgdGhlIGxpbmsgdG8gdGhlIGRyYWZ0OiBodHRwczov L3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtDQo+IGJoYXR0YWNoYXJ5eWEtZGljZS1sZXNzLW9u LWNvYXAtMDAgKEhhZCBhbiBvbGRlciB3b3JrIGluIHByb2dyZXNzOiANCj4gaHR0cHM6Ly90b29s cy5pZXRmLm9yZy9odG1sL2RyYWZ0LWJoYXR0YWNoYXJ5eWEtY29yZS1jb2FwLWxpdGUtYXV0aC0w MA0KPiAuIEJ1dCB0aGlzIG9uZSBkaWQgbm90IHByb3ZpZGUgY2hhbm5lbCBzZWN1cml0eSkuIA0K PiBJIHN1Ym1pdHRlZCB0aGlzIGRyYWZ0IHRvIGRpY2UsIGhvd2V2ZXIsIGRpY2Ugd2FzIG5vdCBy ZWFsbHkgdGhlIA0KPiBwbGFjZSB0byBkaXNjdXNzIHRoaXMuIE91ciBkcmFmdCBpcyBkdWUgdG8g ZXhwaXJlIGluIGFib3V0IDQgZGF5cy4gDQo+IA0KPiANCj4gDQo+IFJlZ2FyZHMNCj4gQWJoaWph biBCaGF0dGFjaGFyeXlhDQo+IEFzc29jaWF0ZSBDb25zdWx0YW50DQo+IFNjaWVudGlzdCwgSW5u b3ZhdGlvbiBMYWIsIEtvbGthdGEsIEluZGlhDQo+IFRhdGEgQ29uc3VsdGFuY3kgU2VydmljZXMN Cj4gTWFpbHRvOiBhYmhpamFuLmJoYXR0YWNoYXJ5eWFAdGNzLmNvbQ0KPiBXZWJzaXRlOiBodHRw Oi8vd3d3LnRjcy5jb20NCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCj4gRXhwZXJpZW5jZSBjZXJ0YWludHkuICAgICAgICBJVCBTZXJ2aWNlcw0KPiAgICAg ICAgICAgICAgICAgICAgICAgIEJ1c2luZXNzIFNvbHV0aW9ucw0KPiAgICAgICAgICAgICAgICAg ICAgICAgIENvbnN1bHRpbmcNCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NCj4gDQo+IA0KPiAiQWNlIiA8YWNlLWJvdW5jZXNAaWV0Zi5vcmc+IHdyb3RlIG9u IDEwLzEzLzIwMTUgMTI6MTE6NDYgQU06DQo+IA0KPiA+IEZyb206IFJhZmEgTWFyaW4gTG9wZXog PHJhZmFAdW0uZXM+IA0KPiA+IFRvOiBBbGV4YW5kZXIgUGVsb3YgPGFAYWNrbC5pbz4gDQo+ID4g Q2M6IDZ0aXNjaEBpZXRmLm9yZywgRGFuIEdhcmNpYSA8ZGFuLmdhcmNpYUB1bS5lcz4sIFJhZmEg TWFyaW4gTG9wZXoNCj4gPiA8cmFmYUB1bS5lcz4sIGFjZUBpZXRmLm9yZyANCj4gPiBEYXRlOiAx MC8xMy8yMDE1IDEyOjE2IEFNIA0KPiA+IFN1YmplY3Q6IFJlOiBbQWNlXSBPcHRpbWl6aW5nIEVB UC1vdmVyLUNvQVAgcGF5bG9hZCANCj4gPiBTZW50IGJ5OiAiQWNlIiA8YWNlLWJvdW5jZXNAaWV0 Zi5vcmc+IA0KPiA+IA0KPiA+IERlYXIgQWxleGFuZGVyOg0KPiA+IA0KPiA+IFRoYW5rcyBmb3Ig eW91ciBjb21tZW50cyANCj4gPiANCj4gPiA+IEVsIDggb2N0IDIwMTUsIGEgbGFzIDEwOjUzLCBB bGV4YW5kZXIgUGVsb3YgPGFAYWNrbC5pbz4gZXNjcmliacOzOg0KPiA+ID4gDQo+ID4gPiBEZWFy IFJhZmEsDQo+ID4gPiANCj4gPiA+IEkndmUgYmVlbiByZWFkaW5nIHRoZSBsYXRlc3QgdmVyc2lv biBvZiB5b3VyIGRyYWZ0ICggZHJhZnQtbWFyaW4tDQo+ID4gYWNlLXdnLWNvYXAtZWFwLTAxLnR4 dCApLCBhbmQgSSBoYXZlIGEgY291cGxlIG9mIHF1ZXN0aW9ucyByZWdhcmRpbmcNCj4gPiBzb21l IG9mIHRoZSBwYXlsb2FkIG9wdGlvbnMsIHdoaWNoIGNvdWxkIGJlIG9wdGltaXplZCBldmVuIGZ1 cnRoZXI6DQo+ID4gPiANCj4gPiA+IDEpIFVzZSBzaG9ydGVyIG5hbWUgZm9yIHRoZSAvYXV0aCBy ZXNvdXJjZQ0KPiA+ID4gMikgTWFuZGF0ZSB0aGUgdXNlIG9mIHplcm8tbGVuZ3RoIENvQVAgdG9r ZW4NCj4gPiA+IA0KPiA+ID4gVGhlIGZpcnN0LCBhbmQgdGhlIG1vcmUgc2ltcGxlIG9uZSwgaXMg LSB3b3VsZCBpdCBiZSBwb3NzaWJsZSB0byANCj4gPiBjaGFuZ2UgdGhlIG5hbWUgb2YgdGhlIGF1 dGhlbnRpY2F0aW9uIHJlc291cmNlIGZyb20gL2F1dGggdG8gYSANCj4gPiBzaG9ydGVyIG9uZSAo bGlrZSAvYSk/IE1heWJlIGl0IGNvdWxkIGJlIGFuIG9wdGlvbiB0byBjaGFuZ2UgdGhlIA0KPiA+ IG5hbWUgb2YgdGhpcyByZXNvdXJjZSwgYmFzZWQgb24gdGhlIHVuZGVybGF5aW5nIGFyY2hpdGVj dHVyZSwgZS5nLiANCj4gPiBhbiBSRkMgY291bGQgbWFuZGF0ZSB0aGF0IGluIGEgc3BlY2lmaWMg bmV0d29yayB0aGUgcmVzb3VyY2UgY291bGQgDQo+ID4gYmUgbmFtZWQgL2EsIHdoZXJlYXMgdGhl IGRlZmF1bHQgdmFsdWUgY291bGQgcmVtYWluIC9hdXRoPw0KPiA+IA0KPiA+IFtSYWZhXSBJIGRv IG5vdCBzZWUgYW55IHByb2JsZW0gdG8gc2hvcnRlbiB0aGUgcmVzb3VyY2UgbmFtZS4NCj4gPiAN Cj4gPiA+IA0KPiA+ID4gVGhlIHNlY29uZCwgd2hpY2ggaXMgYSBsaXR0bGUgYml0IG1vcmUgc3Vi dGxlLiBUb2tlbnMgYXJlIHVzZWQgdG8gDQo+ID4gbWF0Y2ggcmVzcG9uc2VzIHRvIHJlcXVlc3Rz LCBidXQgZHVyaW5nIHRoZSBhdXRoZW50aWNhdGlvbi8NCj4gPiBhdXRob3JpemF0aW9uIHBoYXNl IGEgc2luZ2xlIHBlZXIgKGVuZHBvaW50KSB3b3VsZCBjb21tdW5pY2F0ZSB3aXRoIA0KPiA+IGEg c2luZ2xlIGF1dGhlbnRpY2F0b3IuIE1vcmVvdmVyLCB0aGUgY29tbXVuaWNhdGlvbiBoYXBwZW5z IGluIGEgDQo+ID4gc2VyaWFsIGZhc2hpb24sIGFuZCByZXNwb25zZXMgYXJlIHBpZ2d5YmFja2Vk LiBUaGlzIGZhbGxzIGluIHRoZSANCj4gPiBjYXNlIHdoZW4gemVyby1sZW5ndGggdG9rZW4gaXMg YWxzbyBhZHZpc2VkIGJ5IFJGQzcyNTIuIERvIHlvdSB0aGluaw0KPiA+IHRoYXQgaXQgd291bGQg YmUgYXBwcm9wcmlhdGUgdG8gbWFrZSB0aGUgdXNlIG9mIHplcm8tbGVuZ3RoIHRva2VuIA0KPiA+ IG1hbmRhdG9yeSBmb3IgRUFQLW92ZXItQ29BUD8NCj4gPiANCj4gPiBbUmFmYV0gSSBndWVzcyB5 b3UgYXJlIHJlZmVycmluZyB0byB0aGlzIHRleHQ6ICANCj4gPiANCj4gPiAiQW4gZW1wdHkgdG9r ZW4gdmFsdWUgaXMgYXBwcm9wcmlhdGUgZS5nLiwgd2hlbg0KPiA+ICAgIG5vIG90aGVyIHRva2Vu cyBhcmUgaW4gdXNlIHRvIGEgZGVzdGluYXRpb24sICJvciB3aGVuIHJlcXVlc3RzIGFyZQ0KPiA+ ICAgIG1hZGUgc2VyaWFsbHkgcGVyIGRlc3RpbmF0aW9uIGFuZCByZWNlaXZlIHBpZ2d5YmFja2Vk IHJlc3BvbnNlcy7igJ0NCj4gPiANCj4gPiBJIHdvdWxkIHNheSB0aGF0IHVzaW5nIHplcm8tbGVu Z3RoIHRva2VuIGlzIHBvc3NpYmxlLiBXaGF0IEkgYW0gbm90IA0KPiA+IHN1cmUgaXMgd2hldGhl ciBtYWtlIGl0IG1hbmRhdG9yeSBvciBub3QuIEkgbWVhbiB3ZSBjb3VsZCBzYXkgdGhhdCANCj4g PiBpZiB0aGUgY2xpZW50IHNlbmRzIGEgemVyby1sZW5ndGggdG9rZW4gdGhlIHNlcnZlciBjYW4g Y29uc2lkZXIgaXQgDQo+ID4gT0sgYXMgcGVyIHRoZSB0ZXh0IGFib3ZlLiBJZiB0aGVyZSBpcyBh IG5vbi16ZXJvIGxlbmd0aCB0b2tlbiB2YWx1ZSANCj4gPiBzaG91bGQgYmUgYWxzbyBmaW5lLg0K PiA+IA0KPiA+IFdoYXQgZG8geW91IHRoaW5rPw0KPiA+IA0KPiA+IEJlc3QgUmVnYXJkcy4NCj4g PiANCj4gPiA+IA0KPiA+ID4gQmVzdCwNCj4gPiA+IEFsZXhhbmRlcg0KPiA+ID4gDQo+ID4gPiBf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+ID4gQWNl IG1haWxpbmcgbGlzdA0KPiA+ID4gQWNlQGlldGYub3JnDQo+ID4gPiBodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL2FjZQ0KPiA+IA0KPiA+IC0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gPiBSYWZhZWwgTWFyaW4gTG9w ZXosIFBoRA0KPiA+IERlcHQuIEluZm9ybWF0aW9uIGFuZCBDb21tdW5pY2F0aW9ucyBFbmdpbmVl cmluZyAoRElJQykNCj4gPiBGYWN1bHR5IG9mIENvbXB1dGVyIFNjaWVuY2UtVW5pdmVyc2l0eSBv ZiBNdXJjaWENCj4gPiAzMDEwMCBNdXJjaWEgLSBTcGFpbg0KPiA+IFRlbGY6ICszNDg2ODg4ODUw MSBGYXg6ICszNDg2ODg4NDE1MSBlLW1haWw6IHJhZmFAdW0uZXMNCj4gPiAtLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+ID4gDQo+ID4gDQo+ ID4gDQo+ID4gDQo+ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCj4gPiBBY2UgbWFpbGluZyBsaXN0DQo+ID4gQWNlQGlldGYub3JnDQo+ID4gaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9hY2UNCj4gPT09PT0tLS0tLT09PT09LS0t LS09PT09PQ0KPiBOb3RpY2U6IFRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaW4gdGhpcyBlLW1h aWwNCj4gbWVzc2FnZSBhbmQvb3IgYXR0YWNobWVudHMgdG8gaXQgbWF5IGNvbnRhaW4gDQo+IGNv bmZpZGVudGlhbCBvciBwcml2aWxlZ2VkIGluZm9ybWF0aW9uLiBJZiB5b3UgYXJlIA0KPiBub3Qg dGhlIGludGVuZGVkIHJlY2lwaWVudCwgYW55IGRpc3NlbWluYXRpb24sIHVzZSwgDQo+IHJldmll dywgZGlzdHJpYnV0aW9uLCBwcmludGluZyBvciBjb3B5aW5nIG9mIHRoZSANCj4gaW5mb3JtYXRp b24gY29udGFpbmVkIGluIHRoaXMgZS1tYWlsIG1lc3NhZ2UgDQo+IGFuZC9vciBhdHRhY2htZW50 cyB0byBpdCBhcmUgc3RyaWN0bHkgcHJvaGliaXRlZC4gSWYgDQo+IHlvdSBoYXZlIHJlY2VpdmVk IHRoaXMgY29tbXVuaWNhdGlvbiBpbiBlcnJvciwgDQo+IHBsZWFzZSBub3RpZnkgdXMgYnkgcmVw bHkgZS1tYWlsIG9yIHRlbGVwaG9uZSBhbmQgDQo+IGltbWVkaWF0ZWx5IGFuZCBwZXJtYW5lbnRs eSBkZWxldGUgdGhlIG1lc3NhZ2UgDQo+IGFuZCBhbnkgYXR0YWNobWVudHMuIFRoYW5rIHlvdQ0K PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBBY2Ug bWFpbGluZyBsaXN0DQo+IEFjZUBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL2FjZQ0KDQo= --=_alternative 003D5A1B65257EDE_= Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: base64 PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhpIEFsZXhhbmRlciw8L2ZvbnQ+DQo8YnI+ DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IFRoYW5rcyBmb3IgcG9pbnRpbmcgeW91ciBkcmFm dCAtIHZlcnkgaW50ZXJlc3RpbmcNCndvcmsuPC9mb250PjwvdHQ+DQo8YnI+PGZvbnQgc2l6ZT0y IGZhY2U9InNhbnMtc2VyaWYiPlRoYW5rcyBhIGxvdC48L2ZvbnQ+DQo8YnI+DQo8YnI+PHR0Pjxm b250IHNpemU9Mj4mZ3Q7IEhvd2V2ZXIsIGl0IHNlZW1zIHRvIG1lIHRoYXQgaXQgc29sdmVzIG9u bHkgYQ0Kc3Vic2V0IG9mIHRoZSBwcm9ibGVtczxicj4NCiZndDsgYXQgd2hpY2ggRUFQLW92ZXIt Q29BUCBpcyBhaW1lZC48L2ZvbnQ+PC90dD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1z ZXJpZiI+WW91IGFyZSByaWdodC48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMt c2VyaWYiPlRvIGJlIHByZWNpc2UsIHRoZSB3b3JrIEkgcG9pbnRlZCBvdXQNCmFjdHVhbGx5IHN0 YXJ0cyBhZnRlciB0aGUgRUFQLiBXZSB0cmllZCBhIHByb3Bvc2UgYSB2ZXJ5IGxpZ2h0d2VpZ2h0 IHZlcnNpb24NCm9mIHNlc3Npb24ta2V5IGVzdGFibGlzaG1lbnQgdXNpbmcgQ29BUCBhc3N1bWlu ZyB0aGF0IHRoZSBtYXN0ZXIga2V5cyBoYXZlDQpiZWVuIHByZXZpb3VzbHkgY29uZmlndXJlZCAo bWF5IGJlIHRocm91Z2ggRUFQISkuIFRoZSBpZGVhIGlzIGFzIGZvbGxvd3M6PC9mb250Pg0KPGJy Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5UaGUgRFRMUyBwcm90b2NvbCBj YW4gYmUgc2VwYXJhdGVkIGludG8NCnR3byBwYXJ0cyBpbiB0ZXJtcyBvZiBmdW5jdGlvbmFsaXR5 LiBGaXJzdCBpcyBzZWN1cmUgc2Vzc2lvbiBlc3RhYmxpc2htZW50DQphbmQgdGhlIG5leHQgb25l IGlzIHByb3ZpZGluZyBjaGFubmVsIHNlY3VyaXR5IHdpdGggaW5oZXJlbnQgcmVsaWFiaWxpdHkN CmFuZCByZXBsYXkgcHJvdGVjdGlvbi4gSG93ZXZlciwgd2UgdGhpbmsgdGhhdCB0aGUgcmVxdWly ZWQgZXhjaGFuZ2VzIGluDQpEVExTIHNlc3Npb24gZXN0YWJsaXNobWVudCAoSSBhbSBvbmx5IHRh bGtpbmcgYWJvdXQgc3ltbWV0cmljIHN5c3RlbSkgbWF5DQpiZSBiaXQgaGVhdnkgZm9yIHJlYWxs eSBjb25zdHJhaW5lZCBuZXR3b3JrcyB3aXRoIGludGVybWl0dGVudCBjb25uZWN0aXZpdHkNCmFu ZCBiYW5kd2lkdGggY29uc3RyYWludC4gU28sIHdlIHByb3Bvc2UgdG8gcHVzaCB0aGUgc2Vzc2lv biBlc3RhYmxpc2htZW50DQpwYXJ0IHRvIGFwcGxpY2F0aW9uIGxheWVyIChDb0FQKSBhbmQgbGV2 ZXJhZ2UgdGhlIGluaGVyZW50ICZxdW90O2xpZ2h0d2VpZ2h0DQp5ZXQgcmVsaWFibGUmcXVvdDsg bmF0dXJlIG9mIENvQVAgKGNvbnNpZGVyaW5nIHRoZSBDT04gbW9kZSkuIFdlIGJlbGlldmUsDQpp dCBpcyBiZXR0ZXIgdG8gcHV0IG1vcmUgY29udHJvbCB0byB0aGUgYXBwbGljYXRpb24gbGF5ZXIg d2hlbiB5b3UgYXJlDQpkZWFsaW5nIHdpdGggY29uc3RyYWluZWQgZW52aXJvbm1lbnQuIFRoZSBh cHBsaWNhdGlvbiBsYXllciBzZXNzaW9uIGVzdGFibGlzaG1lbnQNCm1lY2hhbmlzbSBvdmVyIENv QVAgZXN0YWJsaXNoZXMgYSBzZWN1cmUgc2Vzc2lvbiB3aGljaCBmaW5hbGx5IHByb2R1Y2VzDQp0 aGUgc2FtZSB0dXBsZSBhcyBpbiBEVExTIHNlc3Npb24gZXN0YWJsaXNobWVudCAsaS5lLCA8aT4m bHQ7U2VydmVyX3dyaXRlX2tleSwNCkNsaWVudF93cml0ZV9rZXksIFNlcnZlcl9JViwgQ2xpZW50 X0lWJmd0OzwvaT4uPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNl cmlmIj5UaGVuIHRoZSByZXNwb25zaWJpbGl0eSBpcyB0cmFuc2ZlcnJlZA0KdG8gdGhlIHRyYW5z cG9ydCBsYXllciBhbmQgdGhlIGNoYW5uZWwgc2VjdXJpdHkgaXMgcHJvdmlkZWQgdXNpbmcgY29u dmVudGlvbmFsDQpEVExTLVBTSyByZWNvcmQgZW5jcnlwdGlvbi4gVGh1cyBpdCB0YWtlcyBhbGwg dGhlIGFkdmFudGFnZSBvZiBEVExTIHJlY29yZA0KZW5jcnlwdGlvbi4gVGhlIGlkZWEgaXMgdG8g dXNlIHRoZSBiZXN0IG9mIHRoZSB3b3JsZHMuIENvQVAncyBsaWdodHdlaWdodC1uZXNzDQpjb3Vw bGVkIHdpdGggcmVjb3JkIHByb3RlY3Rpb24gZnJvbSBEVExTLiBUaGlzIHdhcyBqdXN0IGFuIGV4 cGVyaW1lbnRhbA0Kd29yayB0byBzb2x2ZSBzb21lIGltbWVkaWF0ZSBwcm9ibGVtcyBhdCBoYW5k LiBIb3dldmVyLCBpZiB0aGlzIGtpbmQgb2YNCmNyb3NzLWxheWVyIGFwcHJvYWNoIG1ha2VzIHNl bnNlIHRoZW4gaXQgbWF5ICZuYnNwO3NwYXduIGV4dGVuZGVkIGlkZWFzLjwvZm9udD4NCjxicj4N Cjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7PC9mb250Pjx0dD48Zm9u dCBzaXplPTI+Jmd0OyAuLi4uLg0KTWF5YmUgdGhlcmUgY291bGQgYmUgc29tZSBraW5kIG9mIGNv b3BlcmF0aW9uIC4uLi4uPC9mb250PjwvdHQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMt c2VyaWYiPkl0cyBhIGdvb2QgcHJvcG9zaXRpb24uIEJ1dCB3ZSBuZWVkDQp0byBrbm93IGlmIHRo ZXJlIGlzIGVub3VnaCB0cmFjdGlvbiBpbiB0aGUgY29tbXVuaXR5IGZvciBleHRlbmRpbmcgdGhl DQp3b3JrLiBNYXkgYmUgd2UgY2FuIGRpc2N1c3MgaWYgd2UgaGFwcGVuIHRvIG1lZXQgaW4gWW9r b2hhbWEuPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5S ZWdhcmRzPGJyPg0KQWJoaWphbiBCaGF0dGFjaGFyeXlhPGJyPg0KQXNzb2NpYXRlIENvbnN1bHRh bnQ8YnI+DQpTY2llbnRpc3QsIElubm92YXRpb24gTGFiLCBLb2xrYXRhLCBJbmRpYTxicj4NClRh dGEgQ29uc3VsdGFuY3kgU2VydmljZXM8YnI+DQpNYWlsdG86IGFiaGlqYW4uYmhhdHRhY2hhcnl5 YUB0Y3MuY29tPGJyPg0KV2Vic2l0ZTogPC9mb250PjxhIGhyZWY9aHR0cDovL3d3dy50Y3MuY29t Lz48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+aHR0cDovL3d3dy50Y3MuY29tPC9mb250 PjwvYT48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+PGJyPg0KX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpFeHBlcmllbmNlIGNlcnRhaW50eS4g Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7SVQgU2VydmljZXM8YnI+DQogJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7QnVzaW5lc3MgU29sdXRpb25zPGJyPg0KICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwO0NvbnN1bHRpbmc8YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXzxicj4NCjwvZm9udD4NCjxicj4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZx dW90O0FjZSZxdW90OyAmbHQ7YWNlLWJvdW5jZXNAaWV0Zi5vcmcmZ3Q7IHdyb3RlDQpvbiAxMC8x NC8yMDE1IDAyOjQ3OjE5IFBNOjxicj4NCjxicj4NCiZndDsgRnJvbTogQWxleGFuZGVyIFBlbG92 ICZsdDthQGFja2wuaW8mZ3Q7PC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7 IFRvOiBBYmhpamFuIEJoYXR0YWNoYXJ5eWEgJmx0O2FiaGlqYW4uYmhhdHRhY2hhcnl5YUB0Y3Mu Y29tJmd0OywNClJhZmEgPGJyPg0KJmd0OyBNYXJpbiBMb3BleiAmbHQ7cmFmYUB1bS5lcyZndDs8 L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgQ2M6IDZ0aXNjaEBpZXRmLm9y ZywgZGFuLmdhcmNpYUB1bS5lcywgYWNlQGlldGYub3JnPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxm b250IHNpemU9Mj4mZ3Q7IERhdGU6IDEwLzE0LzIwMTUgMDI6NTEgUE08L2ZvbnQ+PC90dD4NCjxi cj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgU3ViamVjdDogUmU6IFtBY2VdIE9wdGltaXppbmcgRUFQ LW92ZXItQ29BUCBwYXlsb2FkPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7 IFNlbnQgYnk6ICZxdW90O0FjZSZxdW90OyAmbHQ7YWNlLWJvdW5jZXNAaWV0Zi5vcmcmZ3Q7PC9m b250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IDxicj4NCiZndDsgSGkgQWJoaWph biw8YnI+DQomZ3Q7IDxicj4NCiZndDsgVGhhbmtzIGZvciBwb2ludGluZyB5b3VyIGRyYWZ0IC0g dmVyeSBpbnRlcmVzdGluZyB3b3JrLjxicj4NCiZndDsgPGJyPg0KJmd0OyBIb3dldmVyLCBpdCBz ZWVtcyB0byBtZSB0aGF0IGl0IHNvbHZlcyBvbmx5IGEgc3Vic2V0IG9mIHRoZSBwcm9ibGVtczxi cj4NCiZndDsgYXQgd2hpY2ggRUFQLW92ZXItQ29BUCBpcyBhaW1lZC4gTW9zdCBub3RhYmx5LCBp dCBpcyBsaW1pdGVkIHRvIGENCjxicj4NCiZndDsgc3BlY2lmaWMgYXV0aGVudGljYXRpb24gbWV0 aG9kIChEVExTLVBTSyksIHdoZXJlYXMgRUFQIGlzIGFuIDxicj4NCiZndDsgZXh0ZW5zaWJsZSBm cmFtZXdvcmsuIE1heWJlIHRoZXJlIGNvdWxkIGJlIHNvbWUga2luZCBvZiBjb29wZXJhdGlvbg0K PGJyPg0KJmd0OyBiZXR3ZWVuIHRoZSB0d28sIGUuZy4geW91IGNvdWxkIHNwZWNpZnkgYW4gRUFQ IG1ldGhvZCBsaWtlIEVBUC1EVExTLVBTSy1zaG9ydD88YnI+DQomZ3Q7IDxicj4NCiZndDsgQmVz dCw8YnI+DQomZ3Q7IEFsZXhhbmRlcjxicj4NCiZndDsgPGJyPg0KPC9mb250PjwvdHQ+DQo8YnI+ PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IExlIDEzLzEwLzIwMTUgMTQ6NDgsIEFiaGlqYW4gQmhhdHRh Y2hhcnl5YSBhDQrDqWNyaXQmbmJzcDs6PC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9 Mj4mZ3Q7IEhpIFJhZmEsIDxicj4NCiZndDsgVGhlIGFwcGxpY2F0aW9uIGxheWVyIGRyaXZlbiBh cHByb2FjaCBpcyByZWFsbHkgaW50ZXJlc3RpbmcgaW4gdGhlDQo8YnI+DQomZ3Q7IGNvbnN0cmFp bmVkIGVudmlyb25tZW50IGNvbnRleHQuIFdlIGhhZCBhIHNpbWlsYXIgYXBwcm9hY2ggZm9yIDxi cj4NCiZndDsgc2VjdXJlIHNlc3Npb24gZXN0YWJsaXNobWVudCAoYXNzdW1pbmcgdGhhdCBib290 LXN0cmFwcGluZyBpcyA8YnI+DQomZ3Q7IGFscmVhZHkgZG9uZSkgd2hpY2ggcGVyZm9ybXMgdGhl IHNlc3Npb24gZXN0YWJsaXNobWVudCBpbiBDb0FQIGJ1dA0KPGJyPg0KJmd0OyB1c2VzIHRoZSBE VExTIGVuY3J5cHRpb24gYW5kIGhlYWRlci1zdHJ1Y3R1cmUgZm9yIHNlY3VyZSBleGNoYW5nZQ0K b2Y8YnI+DQomZ3Q7IHRoZSBhcHBsaWNhdGlvbi1sYXllciBtZXNzYWdlLiBDb2luY2lkZW50YWxs eSB3ZSBoYXZlIGFsc28gZGVmaW5lZA0KPGJyPg0KJmd0OyBhbiBvcHRpb24gY2FsbGVkICZxdW90 O0F1dGgmcXVvdDsgLiA8YnI+DQomZ3Q7IDxicj4NCiZndDsgSGVyZSBpcyB0aGUgbGluayB0byB0 aGUgZHJhZnQ6IDwvZm9udD48L3R0PjxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRt bC9kcmFmdC0iPjx0dD48Zm9udCBzaXplPTI+aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2Ry YWZ0LTwvZm9udD48L3R0PjwvYT48dHQ+PGZvbnQgc2l6ZT0yPjxicj4NCiZndDsgYmhhdHRhY2hh cnl5YS1kaWNlLWxlc3Mtb24tY29hcC0wMCAoSGFkIGFuIG9sZGVyIHdvcmsgaW4gcHJvZ3Jlc3M6 DQo8YnI+DQomZ3Q7IDwvZm9udD48L3R0PjxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcv aHRtbC9kcmFmdC1iaGF0dGFjaGFyeXlhLWNvcmUtY29hcC1saXRlLWF1dGgtMDAiPjx0dD48Zm9u dCBzaXplPTI+aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWJoYXR0YWNoYXJ5eWEt Y29yZS1jb2FwLWxpdGUtYXV0aC0wMDwvZm9udD48L3R0PjwvYT48dHQ+PGZvbnQgc2l6ZT0yPjxi cj4NCiZndDsgLiBCdXQgdGhpcyBvbmUgZGlkIG5vdCBwcm92aWRlIGNoYW5uZWwgc2VjdXJpdHkp LiA8YnI+DQomZ3Q7IEkgc3VibWl0dGVkIHRoaXMgZHJhZnQgdG8gZGljZSwgaG93ZXZlciwgZGlj ZSB3YXMgbm90IHJlYWxseSB0aGUgPGJyPg0KJmd0OyBwbGFjZSB0byBkaXNjdXNzIHRoaXMuIE91 ciBkcmFmdCBpcyBkdWUgdG8gZXhwaXJlIGluIGFib3V0IDQgZGF5cy4NCjxicj4NCiZndDsgPGJy Pg0KJmd0OyA8YnI+DQomZ3Q7IDxicj4NCiZndDsgUmVnYXJkczxicj4NCiZndDsgQWJoaWphbiBC aGF0dGFjaGFyeXlhPGJyPg0KJmd0OyBBc3NvY2lhdGUgQ29uc3VsdGFudDxicj4NCiZndDsgU2Np ZW50aXN0LCBJbm5vdmF0aW9uIExhYiwgS29sa2F0YSwgSW5kaWE8YnI+DQomZ3Q7IFRhdGEgQ29u c3VsdGFuY3kgU2VydmljZXM8YnI+DQomZ3Q7IE1haWx0bzogYWJoaWphbi5iaGF0dGFjaGFyeXlh QHRjcy5jb208YnI+DQomZ3Q7IFdlYnNpdGU6IDwvZm9udD48L3R0PjxhIGhyZWY9aHR0cDovL3d3 dy50Y3MuY29tLz48dHQ+PGZvbnQgc2l6ZT0yPmh0dHA6Ly93d3cudGNzLmNvbTwvZm9udD48L3R0 PjwvYT48dHQ+PGZvbnQgc2l6ZT0yPjxicj4NCiZndDsgX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX188YnI+DQomZ3Q7IEV4cGVyaWVuY2UgY2VydGFpbnR5LiAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtJVCBTZXJ2aWNlczxicj4NCiZndDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 DQombmJzcDsgJm5ic3A7QnVzaW5lc3MgU29sdXRpb25zPGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsN CiZuYnNwOyAmbmJzcDtDb25zdWx0aW5nPGJyPg0KJmd0OyBfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXzxicj4NCiZndDsgPGJyPg0KJmd0OyA8YnI+DQomZ3Q7ICZx dW90O0FjZSZxdW90OyAmbHQ7YWNlLWJvdW5jZXNAaWV0Zi5vcmcmZ3Q7IHdyb3RlIG9uIDEwLzEz LzIwMTUgMTI6MTE6NDYNCkFNOjxicj4NCiZndDsgPGJyPg0KJmd0OyAmZ3Q7IEZyb206IFJhZmEg TWFyaW4gTG9wZXogJmx0O3JhZmFAdW0uZXMmZ3Q7IDxicj4NCiZndDsgJmd0OyBUbzogQWxleGFu ZGVyIFBlbG92ICZsdDthQGFja2wuaW8mZ3Q7IDxicj4NCiZndDsgJmd0OyBDYzogNnRpc2NoQGll dGYub3JnLCBEYW4gR2FyY2lhICZsdDtkYW4uZ2FyY2lhQHVtLmVzJmd0OywgUmFmYQ0KTWFyaW4g TG9wZXo8YnI+DQomZ3Q7ICZndDsgJmx0O3JhZmFAdW0uZXMmZ3Q7LCBhY2VAaWV0Zi5vcmcgPGJy Pg0KJmd0OyAmZ3Q7IERhdGU6IDEwLzEzLzIwMTUgMTI6MTYgQU0gPGJyPg0KJmd0OyAmZ3Q7IFN1 YmplY3Q6IFJlOiBbQWNlXSBPcHRpbWl6aW5nIEVBUC1vdmVyLUNvQVAgcGF5bG9hZCA8YnI+DQom Z3Q7ICZndDsgU2VudCBieTogJnF1b3Q7QWNlJnF1b3Q7ICZsdDthY2UtYm91bmNlc0BpZXRmLm9y ZyZndDsgPGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyBEZWFyIEFsZXhhbmRlcjo8YnI+ DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7IFRoYW5rcyBmb3IgeW91ciBjb21tZW50cyA8YnI+ DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgRWwgOCBvY3QgMjAxNSwgYSBsYXMgMTA6 NTMsIEFsZXhhbmRlciBQZWxvdiAmbHQ7YUBhY2tsLmlvJmd0Ow0KZXNjcmliacOzOjxicj4NCiZn dDsgJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7IERlYXIgUmFmYSw8YnI+DQomZ3Q7ICZn dDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyBJJ3ZlIGJlZW4gcmVhZGluZyB0aGUgbGF0ZXN0 IHZlcnNpb24gb2YgeW91ciBkcmFmdCAoIGRyYWZ0LW1hcmluLTxicj4NCiZndDsgJmd0OyBhY2Ut d2ctY29hcC1lYXAtMDEudHh0ICksIGFuZCBJIGhhdmUgYSBjb3VwbGUgb2YgcXVlc3Rpb25zIHJl Z2FyZGluZzxicj4NCiZndDsgJmd0OyBzb21lIG9mIHRoZSBwYXlsb2FkIG9wdGlvbnMsIHdoaWNo IGNvdWxkIGJlIG9wdGltaXplZCBldmVuIGZ1cnRoZXI6PGJyPg0KJmd0OyAmZ3Q7ICZndDsgPGJy Pg0KJmd0OyAmZ3Q7ICZndDsgMSkgVXNlIHNob3J0ZXIgbmFtZSBmb3IgdGhlIC9hdXRoIHJlc291 cmNlPGJyPg0KJmd0OyAmZ3Q7ICZndDsgMikgTWFuZGF0ZSB0aGUgdXNlIG9mIHplcm8tbGVuZ3Ro IENvQVAgdG9rZW48YnI+DQomZ3Q7ICZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyBUaGUg Zmlyc3QsIGFuZCB0aGUgbW9yZSBzaW1wbGUgb25lLCBpcyAtIHdvdWxkIGl0IGJlIHBvc3NpYmxl DQp0byA8YnI+DQomZ3Q7ICZndDsgY2hhbmdlIHRoZSBuYW1lIG9mIHRoZSBhdXRoZW50aWNhdGlv biByZXNvdXJjZSBmcm9tIC9hdXRoIHRvDQphIDxicj4NCiZndDsgJmd0OyBzaG9ydGVyIG9uZSAo bGlrZSAvYSk/IE1heWJlIGl0IGNvdWxkIGJlIGFuIG9wdGlvbiB0byBjaGFuZ2UNCnRoZSA8YnI+ DQomZ3Q7ICZndDsgbmFtZSBvZiB0aGlzIHJlc291cmNlLCBiYXNlZCBvbiB0aGUgdW5kZXJsYXlp bmcgYXJjaGl0ZWN0dXJlLA0KZS5nLiA8YnI+DQomZ3Q7ICZndDsgYW4gUkZDIGNvdWxkIG1hbmRh dGUgdGhhdCBpbiBhIHNwZWNpZmljIG5ldHdvcmsgdGhlIHJlc291cmNlDQpjb3VsZCA8YnI+DQom Z3Q7ICZndDsgYmUgbmFtZWQgL2EsIHdoZXJlYXMgdGhlIGRlZmF1bHQgdmFsdWUgY291bGQgcmVt YWluIC9hdXRoPzxicj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgW1JhZmFdIEkgZG8gbm90 IHNlZSBhbnkgcHJvYmxlbSB0byBzaG9ydGVuIHRoZSByZXNvdXJjZSBuYW1lLjxicj4NCiZndDsg Jmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyBUaGUgc2Vjb25k LCB3aGljaCBpcyBhIGxpdHRsZSBiaXQgbW9yZSBzdWJ0bGUuIFRva2VucyBhcmUNCnVzZWQgdG8g PGJyPg0KJmd0OyAmZ3Q7IG1hdGNoIHJlc3BvbnNlcyB0byByZXF1ZXN0cywgYnV0IGR1cmluZyB0 aGUgYXV0aGVudGljYXRpb24vPGJyPg0KJmd0OyAmZ3Q7IGF1dGhvcml6YXRpb24gcGhhc2UgYSBz aW5nbGUgcGVlciAoZW5kcG9pbnQpIHdvdWxkIGNvbW11bmljYXRlDQp3aXRoIDxicj4NCiZndDsg Jmd0OyBhIHNpbmdsZSBhdXRoZW50aWNhdG9yLiBNb3Jlb3ZlciwgdGhlIGNvbW11bmljYXRpb24g aGFwcGVucyBpbg0KYSA8YnI+DQomZ3Q7ICZndDsgc2VyaWFsIGZhc2hpb24sIGFuZCByZXNwb25z ZXMgYXJlIHBpZ2d5YmFja2VkLiBUaGlzIGZhbGxzIGluDQp0aGUgPGJyPg0KJmd0OyAmZ3Q7IGNh c2Ugd2hlbiB6ZXJvLWxlbmd0aCB0b2tlbiBpcyBhbHNvIGFkdmlzZWQgYnkgUkZDNzI1Mi4gRG8g eW91DQp0aGluazxicj4NCiZndDsgJmd0OyB0aGF0IGl0IHdvdWxkIGJlIGFwcHJvcHJpYXRlIHRv IG1ha2UgdGhlIHVzZSBvZiB6ZXJvLWxlbmd0aCB0b2tlbg0KPGJyPg0KJmd0OyAmZ3Q7IG1hbmRh dG9yeSBmb3IgRUFQLW92ZXItQ29BUD88YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7IFtS YWZhXSBJIGd1ZXNzIHlvdSBhcmUgcmVmZXJyaW5nIHRvIHRoaXMgdGV4dDogJm5ic3A7PGJyPg0K Jmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAmcXVvdDtBbiBlbXB0eSB0b2tlbiB2YWx1ZSBpcyBh cHByb3ByaWF0ZSBlLmcuLCB3aGVuPGJyPg0KJmd0OyAmZ3Q7ICZuYnNwOyAmbmJzcDtubyBvdGhl ciB0b2tlbnMgYXJlIGluIHVzZSB0byBhIGRlc3RpbmF0aW9uLCAmcXVvdDtvcg0Kd2hlbiByZXF1 ZXN0cyBhcmU8YnI+DQomZ3Q7ICZndDsgJm5ic3A7ICZuYnNwO21hZGUgc2VyaWFsbHkgcGVyIGRl c3RpbmF0aW9uIGFuZCByZWNlaXZlIHBpZ2d5YmFja2VkDQpyZXNwb25zZXMu4oCdPGJyPg0KJmd0 OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyBJIHdvdWxkIHNheSB0aGF0IHVzaW5nIHplcm8tbGVuZ3Ro IHRva2VuIGlzIHBvc3NpYmxlLiBXaGF0IEkNCmFtIG5vdCA8YnI+DQomZ3Q7ICZndDsgc3VyZSBp cyB3aGV0aGVyIG1ha2UgaXQgbWFuZGF0b3J5IG9yIG5vdC4gSSBtZWFuIHdlIGNvdWxkIHNheQ0K dGhhdCA8YnI+DQomZ3Q7ICZndDsgaWYgdGhlIGNsaWVudCBzZW5kcyBhIHplcm8tbGVuZ3RoIHRv a2VuIHRoZSBzZXJ2ZXIgY2FuIGNvbnNpZGVyDQppdCA8YnI+DQomZ3Q7ICZndDsgT0sgYXMgcGVy IHRoZSB0ZXh0IGFib3ZlLiBJZiB0aGVyZSBpcyBhIG5vbi16ZXJvIGxlbmd0aCB0b2tlbg0KdmFs dWUgPGJyPg0KJmd0OyAmZ3Q7IHNob3VsZCBiZSBhbHNvIGZpbmUuPGJyPg0KJmd0OyAmZ3Q7IDxi cj4NCiZndDsgJmd0OyBXaGF0IGRvIHlvdSB0aGluaz88YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0 OyAmZ3Q7IEJlc3QgUmVnYXJkcy48YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsg PGJyPg0KJmd0OyAmZ3Q7ICZndDsgQmVzdCw8YnI+DQomZ3Q7ICZndDsgJmd0OyBBbGV4YW5kZXI8 YnI+DQomZ3Q7ICZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyBfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCiZndDsgJmd0OyAmZ3Q7IEFjZSBt YWlsaW5nIGxpc3Q8YnI+DQomZ3Q7ICZndDsgJmd0OyBBY2VAaWV0Zi5vcmc8YnI+DQomZ3Q7ICZn dDsgJmd0OyA8L2ZvbnQ+PC90dD48YSBocmVmPWh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vYWNlPjx0dD48Zm9udCBzaXplPTI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9hY2U8L2ZvbnQ+PC90dD48L2E+PHR0Pjxmb250IHNpemU9Mj48YnI+DQomZ3Q7 ICZndDsgPGJyPg0KJmd0OyAmZ3Q7IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS08YnI+DQomZ3Q7ICZndDsgUmFmYWVsIE1hcmluIExvcGV6LCBQ aEQ8YnI+DQomZ3Q7ICZndDsgRGVwdC4gSW5mb3JtYXRpb24gYW5kIENvbW11bmljYXRpb25zIEVu Z2luZWVyaW5nIChESUlDKTxicj4NCiZndDsgJmd0OyBGYWN1bHR5IG9mIENvbXB1dGVyIFNjaWVu Y2UtVW5pdmVyc2l0eSBvZiBNdXJjaWE8YnI+DQomZ3Q7ICZndDsgMzAxMDAgTXVyY2lhIC0gU3Bh aW48YnI+DQomZ3Q7ICZndDsgVGVsZjogKzM0ODY4ODg4NTAxIEZheDogKzM0ODY4ODg0MTUxIGUt bWFpbDogcmFmYUB1bS5lczxicj4NCiZndDsgJmd0OyAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsg Jmd0OyA8YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyBfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCiZndDsgJmd0 OyBBY2UgbWFpbGluZyBsaXN0PGJyPg0KJmd0OyAmZ3Q7IEFjZUBpZXRmLm9yZzxicj4NCiZndDsg Jmd0OyA8L2ZvbnQ+PC90dD48YSBocmVmPWh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vYWNlPjx0dD48Zm9udCBzaXplPTI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9hY2U8L2ZvbnQ+PC90dD48L2E+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7ID09 PT09LS0tLS09PT09PS0tLS0tPT09PT08YnI+DQomZ3Q7IE5vdGljZTogVGhlIGluZm9ybWF0aW9u IGNvbnRhaW5lZCBpbiB0aGlzIGUtbWFpbDxicj4NCiZndDsgbWVzc2FnZSBhbmQvb3IgYXR0YWNo bWVudHMgdG8gaXQgbWF5IGNvbnRhaW4gPGJyPg0KJmd0OyBjb25maWRlbnRpYWwgb3IgcHJpdmls ZWdlZCBpbmZvcm1hdGlvbi4gSWYgeW91IGFyZSA8YnI+DQomZ3Q7IG5vdCB0aGUgaW50ZW5kZWQg cmVjaXBpZW50LCBhbnkgZGlzc2VtaW5hdGlvbiwgdXNlLCA8YnI+DQomZ3Q7IHJldmlldywgZGlz dHJpYnV0aW9uLCBwcmludGluZyBvciBjb3B5aW5nIG9mIHRoZSA8YnI+DQomZ3Q7IGluZm9ybWF0 aW9uIGNvbnRhaW5lZCBpbiB0aGlzIGUtbWFpbCBtZXNzYWdlIDxicj4NCiZndDsgYW5kL29yIGF0 dGFjaG1lbnRzIHRvIGl0IGFyZSBzdHJpY3RseSBwcm9oaWJpdGVkLiBJZiA8YnI+DQomZ3Q7IHlv dSBoYXZlIHJlY2VpdmVkIHRoaXMgY29tbXVuaWNhdGlvbiBpbiBlcnJvciwgPGJyPg0KJmd0OyBw bGVhc2Ugbm90aWZ5IHVzIGJ5IHJlcGx5IGUtbWFpbCBvciB0ZWxlcGhvbmUgYW5kIDxicj4NCiZn dDsgaW1tZWRpYXRlbHkgYW5kIHBlcm1hbmVudGx5IGRlbGV0ZSB0aGUgbWVzc2FnZSA8YnI+DQom Z3Q7IGFuZCBhbnkgYXR0YWNobWVudHMuIFRoYW5rIHlvdTwvZm9udD48L3R0Pg0KPGJyPjx0dD48 Zm9udCBzaXplPTI+Jmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXzxicj4NCiZndDsgQWNlIG1haWxpbmcgbGlzdDxicj4NCiZndDsgQWNlQGlldGYub3Jn PGJyPg0KJmd0OyA8L2ZvbnQ+PC90dD48YSBocmVmPWh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vYWNlPjx0dD48Zm9udCBzaXplPTI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9hY2U8L2ZvbnQ+PC90dD48L2E+PHR0Pjxmb250IHNpemU9Mj48YnI+DQo8 L2ZvbnQ+PC90dD4NCg== --=_alternative 003D5A1B65257EDE_=-- From nobody Wed Oct 14 10:00:34 2015 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45E541ACDF4; Wed, 14 Oct 2015 10:00:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XZVOG0DDdKkj; Wed, 14 Oct 2015 10:00:24 -0700 (PDT) Received: from xenon23.um.es (xenon23.um.es [155.54.212.163]) by ietfa.amsl.com (Postfix) with ESMTP id A828B1ACE25; Wed, 14 Oct 2015 10:00:22 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by xenon23.um.es (Postfix) with ESMTP id 825CD4422; Wed, 14 Oct 2015 19:00:21 +0200 (CEST) X-Virus-Scanned: by antispam in UMU at xenon23.um.es Received: from xenon23.um.es ([127.0.0.1]) by localhost (xenon23.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id tzMrG3ao2yUv; Wed, 14 Oct 2015 19:00:21 +0200 (CEST) Received: from inf-205-175.inf.um.es (inf-205-175.inf.um.es [155.54.205.175]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: rafa) by xenon23.um.es (Postfix) with ESMTPSA id B6ECA43EA; Wed, 14 Oct 2015 19:00:19 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.0 \(3094\)) From: Rafa Marin Lopez In-Reply-To: <561C038C.7090305@tzi.org> Date: Wed, 14 Oct 2015 19:00:18 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <359B7C1D-21B3-461A-8285-D264B40E5F55@um.es> References: <56162F1A.5020503@ackl.io> <561C038C.7090305@tzi.org> To: Carsten Bormann X-Mailer: Apple Mail (2.3094) Archived-At: Cc: 6tisch@ietf.org, ace@ietf.org, Alexander Pelov , Rafa Marin Lopez , Dan Garcia Subject: Re: [Ace] [6tisch] Optimizing EAP-over-CoAP payload X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 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 Oct 2015 17:00:27 -0000 Hi Carsten: Fully agree. Thanks. > El 12 oct 2015, a las 21:01, Carsten Bormann escribi=C3=B3= : >=20 > Rafa Marin Lopez wrote: >> I would say that using zero-length token is possible. What I am not = sure is whether make it mandatory or not. I mean we could say that if = the client sends a zero-length token the server can consider it OK as = per the text above. If there is a non-zero length token value should be = also fine. >=20 > There is never a reason to discuss token values -- these are chosen by > the requester based on its needs, and there is never a reason for a > responder to question that choice. >=20 > Gr=C3=BC=C3=9Fe, Carsten >=20 > _______________________________________________ > 6tisch mailing list > 6tisch@ietf.org > https://www.ietf.org/mailman/listinfo/6tisch ------------------------------------------------------- Rafael Marin Lopez, PhD Dept. Information and Communications Engineering (DIIC) Faculty of Computer Science-University of Murcia 30100 Murcia - Spain Telf: +34868888501 Fax: +34868884151 e-mail: rafa@um.es ------------------------------------------------------- From nobody Wed Oct 14 10:54:00 2015 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 464741AD0B3; Wed, 14 Oct 2015 10:53:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mjven3RLxWkH; Wed, 14 Oct 2015 10:53:55 -0700 (PDT) Received: from xenon23.um.es (xenon23.um.es [155.54.212.163]) by ietfa.amsl.com (Postfix) with ESMTP id 4A79C1AD0AF; Wed, 14 Oct 2015 10:53:50 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by xenon23.um.es (Postfix) with ESMTP id DF5244446; Wed, 14 Oct 2015 19:53:48 +0200 (CEST) X-Virus-Scanned: by antispam in UMU at xenon23.um.es Received: from xenon23.um.es ([127.0.0.1]) by localhost (xenon23.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id FYf7klN4PVm7; Wed, 14 Oct 2015 19:53:48 +0200 (CEST) Received: from inf-205-175.inf.um.es (inf-205-175.inf.um.es [155.54.205.175]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: rafa) by xenon23.um.es (Postfix) with ESMTPSA id D6848440E; Wed, 14 Oct 2015 19:53:46 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.0 \(3094\)) From: Rafa Marin Lopez In-Reply-To: Date: Wed, 14 Oct 2015 19:53:45 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <9862DED4-7265-4D41-86D1-CF55F38BAA97@um.es> References: <56162F1A.5020503@ackl.io> To: Abhijan Bhattacharyya X-Mailer: Apple Mail (2.3094) Archived-At: Cc: 6tisch@ietf.org, ace@ietf.org, a@ackl.io, Rafa Marin Lopez , dan.garcia@um.es Subject: Re: [Ace] Optimizing EAP-over-CoAP payload X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 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 Oct 2015 17:53:58 -0000 Hi Abhijan: > El 13 oct 2015, a las 14:48, Abhijan Bhattacharyya = escribi=C3=B3: >=20 > Hi Rafa,=20 > The application layer driven approach is really interesting in the = constrained environment context. We had a similar approach for secure = session establishment (assuming that boot-strapping is already done) = which performs the session establishment in CoAP but uses the DTLS = encryption and header-structure for secure exchange of the = application-layer message. Coincidentally we have also defined an option = called "Auth" .=20 As you mention the bootstrapping can provide a symmetric key (we call it = COAP_AUTH_PSK) to protect CoAP messages with AUTH option. But I see you = would require an additional exchange. I guess you are thinking the = communication among smart objects after the bootstrapping. Best Regards. >=20 > Here is the link to the draft: = https://tools.ietf.org/html/draft-bhattacharyya-dice-less-on-coap-00 = (Had an older work in progress: = https://tools.ietf.org/html/draft-bhattacharyya-core-coap-lite-auth-00. = But this one did not provide channel security).=20 > I submitted this draft to dice, however, dice was not really the place = to discuss this. Our draft is due to expire in about 4 days.=20 >=20 >=20 >=20 > Regards > Abhijan Bhattacharyya > Associate Consultant > Scientist, Innovation Lab, Kolkata, India > Tata Consultancy Services > Mailto: abhijan.bhattacharyya@tcs.com > Website: http://www.tcs.com > ____________________________________________ > Experience certainty. IT Services > Business Solutions > Consulting > ____________________________________________ >=20 >=20 > "Ace" wrote on 10/13/2015 12:11:46 AM: >=20 > > From: Rafa Marin Lopez =20 > > To: Alexander Pelov =20 > > Cc: 6tisch@ietf.org, Dan Garcia , Rafa Marin Lopez > > , ace@ietf.org=20 > > Date: 10/13/2015 12:16 AM=20 > > Subject: Re: [Ace] Optimizing EAP-over-CoAP payload=20 > > Sent by: "Ace" =20 > >=20 > > Dear Alexander: > >=20 > > Thanks for your comments=20 > >=20 > > > El 8 oct 2015, a las 10:53, Alexander Pelov escribi=C3=B3= : > > >=20 > > > Dear Rafa, > > >=20 > > > I've been reading the latest version of your draft ( draft-marin- > > ace-wg-coap-eap-01.txt ), and I have a couple of questions regarding > > some of the payload options, which could be optimized even further: > > >=20 > > > 1) Use shorter name for the /auth resource > > > 2) Mandate the use of zero-length CoAP token > > >=20 > > > The first, and the more simple one, is - would it be possible to=20= > > change the name of the authentication resource from /auth to a=20 > > shorter one (like /a)? Maybe it could be an option to change the=20 > > name of this resource, based on the underlaying architecture, e.g.=20= > > an RFC could mandate that in a specific network the resource could=20= > > be named /a, whereas the default value could remain /auth? > >=20 > > [Rafa] I do not see any problem to shorten the resource name. > >=20 > > >=20 > > > The second, which is a little bit more subtle. Tokens are used to=20= > > match responses to requests, but during the authentication/ > > authorization phase a single peer (endpoint) would communicate with=20= > > a single authenticator. Moreover, the communication happens in a=20 > > serial fashion, and responses are piggybacked. This falls in the=20 > > case when zero-length token is also advised by RFC7252. Do you think > > that it would be appropriate to make the use of zero-length token=20 > > mandatory for EAP-over-CoAP? > >=20 > > [Rafa] I guess you are referring to this text: =20 > >=20 > > "An empty token value is appropriate e.g., when > > no other tokens are in use to a destination, "or when requests = are > > made serially per destination and receive piggybacked = responses.=E2=80=9D > >=20 > > I would say that using zero-length token is possible. What I am not=20= > > sure is whether make it mandatory or not. I mean we could say that=20= > > if the client sends a zero-length token the server can consider it=20= > > OK as per the text above. If there is a non-zero length token value=20= > > should be also fine. > >=20 > > What do you think? > >=20 > > Best Regards. > >=20 > > >=20 > > > Best, > > > Alexander > > >=20 > > > _______________________________________________ > > > Ace mailing list > > > Ace@ietf.org > > > https://www.ietf.org/mailman/listinfo/ace > >=20 > > ------------------------------------------------------- > > Rafael Marin Lopez, PhD > > Dept. Information and Communications Engineering (DIIC) > > Faculty of Computer Science-University of Murcia > > 30100 Murcia - Spain > > Telf: +34868888501 Fax: +34868884151 e-mail: rafa@um.es > > ------------------------------------------------------- > >=20 > >=20 > >=20 > >=20 > > _______________________________________________ > > Ace mailing list > > Ace@ietf.org > > https://www.ietf.org/mailman/listinfo/ace > =3D=3D=3D=3D=3D-----=3D=3D=3D=3D=3D-----=3D=3D=3D=3D=3D > Notice: The information contained in this e-mail > message and/or attachments to it may contain=20 > confidential or privileged information. If you are=20 > not the intended recipient, any dissemination, use,=20 > review, distribution, printing or copying of the=20 > information contained in this e-mail message=20 > and/or attachments to it are strictly prohibited. If=20 > you have received this communication in error,=20 > please notify us by reply e-mail or telephone and=20 > immediately and permanently delete the message=20 > and any attachments. Thank you >=20 >=20 > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace ------------------------------------------------------- Rafael Marin Lopez, PhD Dept. Information and Communications Engineering (DIIC) Faculty of Computer Science-University of Murcia 30100 Murcia - Spain Telf: +34868888501 Fax: +34868884151 e-mail: rafa@um.es ------------------------------------------------------- From nobody Wed Oct 14 19:56:27 2015 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD4851ACE59; Wed, 14 Oct 2015 19:56:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X9d-LOrsCsga; Wed, 14 Oct 2015 19:56:20 -0700 (PDT) Received: from inkolg01.tcs.com (inkolg01.tcs.com [121.241.215.10]) by ietfa.amsl.com (Postfix) with ESMTP id 096E21AD0CA; Wed, 14 Oct 2015 19:56:16 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A2DLAQBrEx9W/wQXEqxeg3puvSwBDYFZFwEJhXsCHIFdFAEBAQEBAQGBCoQmAQEBAwEBAQEgSwsFCwsHBgQBAgECKAMCAgIlHwMGCAYLCBuICxWuYgEBAW+TMQEBAQEBAQEBAQEBAQEBAQEBAQEZhUtqhT+EQjAKDAEEBwaCY4FFBYc9hVJ0iBSFGYVLhA8VhCWSCoNvHwEBglECHYFdaYQeJIElAQEB X-IPAS-Result: A2DLAQBrEx9W/wQXEqxeg3puvSwBDYFZFwEJhXsCHIFdFAEBAQEBAQGBCoQmAQEBAwEBAQEgSwsFCwsHBgQBAgECKAMCAgIlHwMGCAYLCBuICxWuYgEBAW+TMQEBAQEBAQEBAQEBAQEBAQEBAQEZhUtqhT+EQjAKDAEEBwaCY4FFBYc9hVJ0iBSFGYVLhA8VhCWSCoNvHwEBglECHYFdaYQeJIElAQEB X-IronPort-AV: E=Sophos;i="5.17,683,1437417000"; d="scan'208";a="13261321" X-DISCLAIMER: FALSE In-Reply-To: <9862DED4-7265-4D41-86D1-CF55F38BAA97@um.es> References: <56162F1A.5020503@ackl.io> <9862DED4-7265-4D41-86D1-CF55F38BAA97@um.es> To: Rafa Marin Lopez MIME-Version: 1.0 X-KeepSent: C77A1AEB:A4242525-65257EDF:000FE520; type=4; name=$KeepSent X-Mailer: IBM Notes Release 9.0 March 08, 2013 Message-ID: From: Abhijan Bhattacharyya Date: Thu, 15 Oct 2015 08:26:09 +0530 X-MIMETrack: Serialize by Router on INKOLM102/TCS(Release 9.0.1FP4|June 07, 2015) at 10/15/2015 08:26:12, Serialize complete at 10/15/2015 08:26:12 Content-Type: multipart/alternative; boundary="=_alternative 001020BC65257EDF_=" Archived-At: Cc: 6tisch@ietf.org, Ace , a@ackl.io, dan.garcia@um.es, ace@ietf.org Subject: Re: [Ace] Optimizing EAP-over-CoAP payload X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 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 Oct 2015 02:56:23 -0000 This is a multipart message in MIME format. --=_alternative 001020BC65257EDF_= Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 SGkgUmFmYSwNCg0KPiBCdXQgSSBzZWUgeW91IHdvdWxkIHJlcXVpcmUgYW4gYWRkaXRpb25hbCBl eGNoYW5nZS4gSSBndWVzcyB5b3UgYXJlIA0KPiB0aGlua2luZyB0aGUgY29tbXVuaWNhdGlvbiBh bW9uZyBzbWFydCBvYmplY3RzIGFmdGVyIHRoZSBib290c3RyYXBwaW5nLg0KWWVzLiBHZW5lcmF0 aW5nIGEgdGVtcG9yYXJ5IHNlc3Npb24ga2V5IGZvciBlYWNoIHNlc3Npb24gYmV0d2VlbiB0aGUg DQpvYmplY3RzLg0KDQpSZWdhcmRzDQpBYmhpamFuIEJoYXR0YWNoYXJ5eWENCkFzc29jaWF0ZSBD b25zdWx0YW50DQpTY2llbnRpc3QsIElubm92YXRpb24gTGFiLCBLb2xrYXRhLCBJbmRpYQ0KVGF0 YSBDb25zdWx0YW5jeSBTZXJ2aWNlcw0KTWFpbHRvOiBhYmhpamFuLmJoYXR0YWNoYXJ5eWFAdGNz LmNvbQ0KV2Vic2l0ZTogaHR0cDovL3d3dy50Y3MuY29tDQpfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0KRXhwZXJpZW5jZSBjZXJ0YWludHkuICAgSVQgU2Vydmlj ZXMNCiAgICAgICAgICAgICAgICAgICAgICAgIEJ1c2luZXNzIFNvbHV0aW9ucw0KICAgICAgICAg ICAgICAgICAgICAgICAgQ29uc3VsdGluZw0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18NCg0KDQoiQWNlIiA8YWNlLWJvdW5jZXNAaWV0Zi5vcmc+IHdyb3RlIG9u IDEwLzE0LzIwMTUgMTE6MjM6NDUgUE06DQoNCj4gRnJvbTogUmFmYSBNYXJpbiBMb3BleiA8cmFm YUB1bS5lcz4NCj4gVG86IEFiaGlqYW4gQmhhdHRhY2hhcnl5YSA8YWJoaWphbi5iaGF0dGFjaGFy eXlhQHRjcy5jb20+DQo+IENjOiA2dGlzY2hAaWV0Zi5vcmcsIGFjZUBpZXRmLm9yZywgYUBhY2ts LmlvLCBSYWZhIE1hcmluIExvcGV6IA0KPiA8cmFmYUB1bS5lcz4sIGRhbi5nYXJjaWFAdW0uZXMN Cj4gRGF0ZTogMTAvMTQvMjAxNSAxMToyNCBQTQ0KPiBTdWJqZWN0OiBSZTogW0FjZV0gT3B0aW1p emluZyBFQVAtb3Zlci1Db0FQIHBheWxvYWQNCj4gU2VudCBieTogIkFjZSIgPGFjZS1ib3VuY2Vz QGlldGYub3JnPg0KPiANCj4gSGkgQWJoaWphbjoNCj4gDQo+ID4gRWwgMTMgb2N0IDIwMTUsIGEg bGFzIDE0OjQ4LCBBYmhpamFuIEJoYXR0YWNoYXJ5eWEgDQo+IDxhYmhpamFuLmJoYXR0YWNoYXJ5 eWFAdGNzLmNvbT4gZXNjcmliacOzOg0KPiA+IA0KPiA+IEhpIFJhZmEsIA0KPiA+IFRoZSBhcHBs aWNhdGlvbiBsYXllciBkcml2ZW4gYXBwcm9hY2ggaXMgcmVhbGx5IGludGVyZXN0aW5nIGluIHRo ZQ0KPiBjb25zdHJhaW5lZCBlbnZpcm9ubWVudCBjb250ZXh0LiBXZSBoYWQgYSBzaW1pbGFyIGFw cHJvYWNoIGZvciANCj4gc2VjdXJlIHNlc3Npb24gZXN0YWJsaXNobWVudCAoYXNzdW1pbmcgdGhh dCBib290LXN0cmFwcGluZyBpcyANCj4gYWxyZWFkeSBkb25lKSB3aGljaCBwZXJmb3JtcyB0aGUg c2Vzc2lvbiBlc3RhYmxpc2htZW50IGluIENvQVAgYnV0IA0KPiB1c2VzIHRoZSBEVExTIGVuY3J5 cHRpb24gYW5kIGhlYWRlci1zdHJ1Y3R1cmUgZm9yIHNlY3VyZSBleGNoYW5nZSBvZg0KPiB0aGUg YXBwbGljYXRpb24tbGF5ZXIgbWVzc2FnZS4gQ29pbmNpZGVudGFsbHkgd2UgaGF2ZSBhbHNvIGRl ZmluZWQgDQo+IGFuIG9wdGlvbiBjYWxsZWQgIkF1dGgiIC4gDQo+IA0KPiBBcyB5b3UgbWVudGlv biB0aGUgYm9vdHN0cmFwcGluZyBjYW4gcHJvdmlkZSBhIHN5bW1ldHJpYyBrZXkgKHdlIA0KPiBj YWxsIGl0IENPQVBfQVVUSF9QU0spIHRvIHByb3RlY3QgQ29BUCBtZXNzYWdlcyB3aXRoIEFVVEgg b3B0aW9uLiANCj4gQnV0IEkgc2VlIHlvdSB3b3VsZCByZXF1aXJlIGFuIGFkZGl0aW9uYWwgZXhj aGFuZ2UuIEkgZ3Vlc3MgeW91IGFyZSANCj4gdGhpbmtpbmcgdGhlIGNvbW11bmljYXRpb24gYW1v bmcgc21hcnQgb2JqZWN0cyBhZnRlciB0aGUgYm9vdHN0cmFwcGluZy4NCj4gDQo+IEJlc3QgUmVn YXJkcy4NCj4gDQo+ID4gDQo+ID4gSGVyZSBpcyB0aGUgbGluayB0byB0aGUgZHJhZnQ6IGh0dHBz Oi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC0NCj4gYmhhdHRhY2hhcnl5YS1kaWNlLWxlc3Mt b24tY29hcC0wMCAoSGFkIGFuIG9sZGVyIHdvcmsgaW4gcHJvZ3Jlc3M6IA0KPiBodHRwczovL3Rv b2xzLmlldGYub3JnL2h0bWwvZHJhZnQtYmhhdHRhY2hhcnl5YS1jb3JlLWNvYXAtbGl0ZS1hdXRo LTAwDQo+IC4gQnV0IHRoaXMgb25lIGRpZCBub3QgcHJvdmlkZSBjaGFubmVsIHNlY3VyaXR5KS4g DQo+ID4gSSBzdWJtaXR0ZWQgdGhpcyBkcmFmdCB0byBkaWNlLCBob3dldmVyLCBkaWNlIHdhcyBu b3QgcmVhbGx5IHRoZSANCj4gcGxhY2UgdG8gZGlzY3VzcyB0aGlzLiBPdXIgZHJhZnQgaXMgZHVl IHRvIGV4cGlyZSBpbiBhYm91dCA0IGRheXMuIA0KPiA+IA0KPiA+IA0KPiA+IA0KPiA+IFJlZ2Fy ZHMNCj4gPiBBYmhpamFuIEJoYXR0YWNoYXJ5eWENCj4gPiBBc3NvY2lhdGUgQ29uc3VsdGFudA0K PiA+IFNjaWVudGlzdCwgSW5ub3ZhdGlvbiBMYWIsIEtvbGthdGEsIEluZGlhDQo+ID4gVGF0YSBD b25zdWx0YW5jeSBTZXJ2aWNlcw0KPiA+IE1haWx0bzogYWJoaWphbi5iaGF0dGFjaGFyeXlhQHRj cy5jb20NCj4gPiBXZWJzaXRlOiBodHRwOi8vd3d3LnRjcy5jb20NCj4gPiBfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+IEV4cGVyaWVuY2UgY2VydGFpbnR5 LiAgICAgICAgSVQgU2VydmljZXMNCj4gPiAgICAgICAgICAgICAgICAgICAgICAgIEJ1c2luZXNz IFNvbHV0aW9ucw0KPiA+ICAgICAgICAgICAgICAgICAgICAgICAgQ29uc3VsdGluZw0KPiA+IF9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4gDQo+ID4gDQo+ ID4gIkFjZSIgPGFjZS1ib3VuY2VzQGlldGYub3JnPiB3cm90ZSBvbiAxMC8xMy8yMDE1IDEyOjEx OjQ2IEFNOg0KPiA+IA0KPiA+ID4gRnJvbTogUmFmYSBNYXJpbiBMb3BleiA8cmFmYUB1bS5lcz4g DQo+ID4gPiBUbzogQWxleGFuZGVyIFBlbG92IDxhQGFja2wuaW8+IA0KPiA+ID4gQ2M6IDZ0aXNj aEBpZXRmLm9yZywgRGFuIEdhcmNpYSA8ZGFuLmdhcmNpYUB1bS5lcz4sIFJhZmEgTWFyaW4gTG9w ZXoNCj4gPiA+IDxyYWZhQHVtLmVzPiwgYWNlQGlldGYub3JnIA0KPiA+ID4gRGF0ZTogMTAvMTMv MjAxNSAxMjoxNiBBTSANCj4gPiA+IFN1YmplY3Q6IFJlOiBbQWNlXSBPcHRpbWl6aW5nIEVBUC1v dmVyLUNvQVAgcGF5bG9hZCANCj4gPiA+IFNlbnQgYnk6ICJBY2UiIDxhY2UtYm91bmNlc0BpZXRm Lm9yZz4gDQo+ID4gPiANCj4gPiA+IERlYXIgQWxleGFuZGVyOg0KPiA+ID4gDQo+ID4gPiBUaGFu a3MgZm9yIHlvdXIgY29tbWVudHMgDQo+ID4gPiANCj4gPiA+ID4gRWwgOCBvY3QgMjAxNSwgYSBs YXMgMTA6NTMsIEFsZXhhbmRlciBQZWxvdiA8YUBhY2tsLmlvPiBlc2NyaWJpw7M6DQo+ID4gPiA+ IA0KPiA+ID4gPiBEZWFyIFJhZmEsDQo+ID4gPiA+IA0KPiA+ID4gPiBJJ3ZlIGJlZW4gcmVhZGlu ZyB0aGUgbGF0ZXN0IHZlcnNpb24gb2YgeW91ciBkcmFmdCAoIGRyYWZ0LW1hcmluLQ0KPiA+ID4g YWNlLXdnLWNvYXAtZWFwLTAxLnR4dCApLCBhbmQgSSBoYXZlIGEgY291cGxlIG9mIHF1ZXN0aW9u cyByZWdhcmRpbmcNCj4gPiA+IHNvbWUgb2YgdGhlIHBheWxvYWQgb3B0aW9ucywgd2hpY2ggY291 bGQgYmUgb3B0aW1pemVkIGV2ZW4gZnVydGhlcjoNCj4gPiA+ID4gDQo+ID4gPiA+IDEpIFVzZSBz aG9ydGVyIG5hbWUgZm9yIHRoZSAvYXV0aCByZXNvdXJjZQ0KPiA+ID4gPiAyKSBNYW5kYXRlIHRo ZSB1c2Ugb2YgemVyby1sZW5ndGggQ29BUCB0b2tlbg0KPiA+ID4gPiANCj4gPiA+ID4gVGhlIGZp cnN0LCBhbmQgdGhlIG1vcmUgc2ltcGxlIG9uZSwgaXMgLSB3b3VsZCBpdCBiZSBwb3NzaWJsZSB0 byANCj4gPiA+IGNoYW5nZSB0aGUgbmFtZSBvZiB0aGUgYXV0aGVudGljYXRpb24gcmVzb3VyY2Ug ZnJvbSAvYXV0aCB0byBhIA0KPiA+ID4gc2hvcnRlciBvbmUgKGxpa2UgL2EpPyBNYXliZSBpdCBj b3VsZCBiZSBhbiBvcHRpb24gdG8gY2hhbmdlIHRoZSANCj4gPiA+IG5hbWUgb2YgdGhpcyByZXNv dXJjZSwgYmFzZWQgb24gdGhlIHVuZGVybGF5aW5nIGFyY2hpdGVjdHVyZSwgZS5nLiANCj4gPiA+ IGFuIFJGQyBjb3VsZCBtYW5kYXRlIHRoYXQgaW4gYSBzcGVjaWZpYyBuZXR3b3JrIHRoZSByZXNv dXJjZSBjb3VsZCANCj4gPiA+IGJlIG5hbWVkIC9hLCB3aGVyZWFzIHRoZSBkZWZhdWx0IHZhbHVl IGNvdWxkIHJlbWFpbiAvYXV0aD8NCj4gPiA+IA0KPiA+ID4gW1JhZmFdIEkgZG8gbm90IHNlZSBh bnkgcHJvYmxlbSB0byBzaG9ydGVuIHRoZSByZXNvdXJjZSBuYW1lLg0KPiA+ID4gDQo+ID4gPiA+ IA0KPiA+ID4gPiBUaGUgc2Vjb25kLCB3aGljaCBpcyBhIGxpdHRsZSBiaXQgbW9yZSBzdWJ0bGUu IFRva2VucyBhcmUgdXNlZCB0byANCj4gPiA+IG1hdGNoIHJlc3BvbnNlcyB0byByZXF1ZXN0cywg YnV0IGR1cmluZyB0aGUgYXV0aGVudGljYXRpb24vDQo+ID4gPiBhdXRob3JpemF0aW9uIHBoYXNl IGEgc2luZ2xlIHBlZXIgKGVuZHBvaW50KSB3b3VsZCBjb21tdW5pY2F0ZSB3aXRoIA0KPiA+ID4g YSBzaW5nbGUgYXV0aGVudGljYXRvci4gTW9yZW92ZXIsIHRoZSBjb21tdW5pY2F0aW9uIGhhcHBl bnMgaW4gYSANCj4gPiA+IHNlcmlhbCBmYXNoaW9uLCBhbmQgcmVzcG9uc2VzIGFyZSBwaWdneWJh Y2tlZC4gVGhpcyBmYWxscyBpbiB0aGUgDQo+ID4gPiBjYXNlIHdoZW4gemVyby1sZW5ndGggdG9r ZW4gaXMgYWxzbyBhZHZpc2VkIGJ5IFJGQzcyNTIuIERvIHlvdSB0aGluaw0KPiA+ID4gdGhhdCBp dCB3b3VsZCBiZSBhcHByb3ByaWF0ZSB0byBtYWtlIHRoZSB1c2Ugb2YgemVyby1sZW5ndGggdG9r ZW4gDQo+ID4gPiBtYW5kYXRvcnkgZm9yIEVBUC1vdmVyLUNvQVA/DQo+ID4gPiANCj4gPiA+IFtS YWZhXSBJIGd1ZXNzIHlvdSBhcmUgcmVmZXJyaW5nIHRvIHRoaXMgdGV4dDogDQo+ID4gPiANCj4g PiA+ICJBbiBlbXB0eSB0b2tlbiB2YWx1ZSBpcyBhcHByb3ByaWF0ZSBlLmcuLCB3aGVuDQo+ID4g PiAgICBubyBvdGhlciB0b2tlbnMgYXJlIGluIHVzZSB0byBhIGRlc3RpbmF0aW9uLCAib3Igd2hl biByZXF1ZXN0cyANCmFyZQ0KPiA+ID4gICAgbWFkZSBzZXJpYWxseSBwZXIgZGVzdGluYXRpb24g YW5kIHJlY2VpdmUgcGlnZ3liYWNrZWQgcmVzcG9uc2VzLuKAnQ0KPiA+ID4gDQo+ID4gPiBJIHdv dWxkIHNheSB0aGF0IHVzaW5nIHplcm8tbGVuZ3RoIHRva2VuIGlzIHBvc3NpYmxlLiBXaGF0IEkg YW0gbm90IA0KPiA+ID4gc3VyZSBpcyB3aGV0aGVyIG1ha2UgaXQgbWFuZGF0b3J5IG9yIG5vdC4g SSBtZWFuIHdlIGNvdWxkIHNheSB0aGF0IA0KPiA+ID4gaWYgdGhlIGNsaWVudCBzZW5kcyBhIHpl cm8tbGVuZ3RoIHRva2VuIHRoZSBzZXJ2ZXIgY2FuIGNvbnNpZGVyIGl0IA0KPiA+ID4gT0sgYXMg cGVyIHRoZSB0ZXh0IGFib3ZlLiBJZiB0aGVyZSBpcyBhIG5vbi16ZXJvIGxlbmd0aCB0b2tlbiB2 YWx1ZSANCj4gPiA+IHNob3VsZCBiZSBhbHNvIGZpbmUuDQo+ID4gPiANCj4gPiA+IFdoYXQgZG8g eW91IHRoaW5rPw0KPiA+ID4gDQo+ID4gPiBCZXN0IFJlZ2FyZHMuDQo+ID4gPiANCj4gPiA+ID4g DQo+ID4gPiA+IEJlc3QsDQo+ID4gPiA+IEFsZXhhbmRlcg0KPiA+ID4gPiANCj4gPiA+ID4gX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPiA+ID4gQWNl IG1haWxpbmcgbGlzdA0KPiA+ID4gPiBBY2VAaWV0Zi5vcmcNCj4gPiA+ID4gaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9hY2UNCj4gPiA+IA0KPiA+ID4gLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiA+ID4gUmFmYWVs IE1hcmluIExvcGV6LCBQaEQNCj4gPiA+IERlcHQuIEluZm9ybWF0aW9uIGFuZCBDb21tdW5pY2F0 aW9ucyBFbmdpbmVlcmluZyAoRElJQykNCj4gPiA+IEZhY3VsdHkgb2YgQ29tcHV0ZXIgU2NpZW5j ZS1Vbml2ZXJzaXR5IG9mIE11cmNpYQ0KPiA+ID4gMzAxMDAgTXVyY2lhIC0gU3BhaW4NCj4gPiA+ IFRlbGY6ICszNDg2ODg4ODUwMSBGYXg6ICszNDg2ODg4NDE1MSBlLW1haWw6IHJhZmFAdW0uZXMN Cj4gPiA+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0NCj4gPiA+IA0KPiA+ID4gDQo+ID4gPiANCj4gPiA+IA0KPiA+ID4gX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPiA+IEFjZSBtYWlsaW5nIGxp c3QNCj4gPiA+IEFjZUBpZXRmLm9yZw0KPiA+ID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9hY2UNCj4gPiA9PT09PS0tLS0tPT09PT0tLS0tLT09PT09DQo+ID4gTm90aWNl OiBUaGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGluIHRoaXMgZS1tYWlsDQo+ID4gbWVzc2FnZSBh bmQvb3IgYXR0YWNobWVudHMgdG8gaXQgbWF5IGNvbnRhaW4gDQo+ID4gY29uZmlkZW50aWFsIG9y IHByaXZpbGVnZWQgaW5mb3JtYXRpb24uIElmIHlvdSBhcmUgDQo+ID4gbm90IHRoZSBpbnRlbmRl ZCByZWNpcGllbnQsIGFueSBkaXNzZW1pbmF0aW9uLCB1c2UsIA0KPiA+IHJldmlldywgZGlzdHJp YnV0aW9uLCBwcmludGluZyBvciBjb3B5aW5nIG9mIHRoZSANCj4gPiBpbmZvcm1hdGlvbiBjb250 YWluZWQgaW4gdGhpcyBlLW1haWwgbWVzc2FnZSANCj4gPiBhbmQvb3IgYXR0YWNobWVudHMgdG8g aXQgYXJlIHN0cmljdGx5IHByb2hpYml0ZWQuIElmIA0KPiA+IHlvdSBoYXZlIHJlY2VpdmVkIHRo aXMgY29tbXVuaWNhdGlvbiBpbiBlcnJvciwgDQo+ID4gcGxlYXNlIG5vdGlmeSB1cyBieSByZXBs eSBlLW1haWwgb3IgdGVsZXBob25lIGFuZCANCj4gPiBpbW1lZGlhdGVseSBhbmQgcGVybWFuZW50 bHkgZGVsZXRlIHRoZSBtZXNzYWdlIA0KPiA+IGFuZCBhbnkgYXR0YWNobWVudHMuIFRoYW5rIHlv dQ0KPiA+IA0KPiA+IA0KPiA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fDQo+ID4gQWNlIG1haWxpbmcgbGlzdA0KPiA+IEFjZUBpZXRmLm9yZw0KPiA+IGh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vYWNlDQo+IA0KPiAtLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+IFJhZmFlbCBN YXJpbiBMb3BleiwgUGhEDQo+IERlcHQuIEluZm9ybWF0aW9uIGFuZCBDb21tdW5pY2F0aW9ucyBF bmdpbmVlcmluZyAoRElJQykNCj4gRmFjdWx0eSBvZiBDb21wdXRlciBTY2llbmNlLVVuaXZlcnNp dHkgb2YgTXVyY2lhDQo+IDMwMTAwIE11cmNpYSAtIFNwYWluDQo+IFRlbGY6ICszNDg2ODg4ODUw MSBGYXg6ICszNDg2ODg4NDE1MSBlLW1haWw6IHJhZmFAdW0uZXMNCj4gLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiANCj4gDQo+IA0KPiAN Cj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gQWNl IG1haWxpbmcgbGlzdA0KPiBBY2VAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9hY2UNCg0K --=_alternative 001020BC65257EDF_= Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: base64 PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhpIFJhZmEsPC9mb250Pg0KPGJyPg0KPGJy Pjx0dD48Zm9udCBzaXplPTI+Jmd0OyBCdXQgSSBzZWUgeW91IHdvdWxkIHJlcXVpcmUgYW4gYWRk aXRpb25hbCBleGNoYW5nZS4NCkkgZ3Vlc3MgeW91IGFyZSA8YnI+DQomZ3Q7IHRoaW5raW5nIHRo ZSBjb21tdW5pY2F0aW9uIGFtb25nIHNtYXJ0IG9iamVjdHMgYWZ0ZXIgdGhlIGJvb3RzdHJhcHBp bmcuPC9mb250PjwvdHQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPlllcy4g R2VuZXJhdGluZyBhIHRlbXBvcmFyeSBzZXNzaW9uDQprZXkgZm9yIGVhY2ggc2Vzc2lvbiBiZXR3 ZWVuIHRoZSBvYmplY3RzLjwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fu cy1zZXJpZiI+UmVnYXJkczxicj4NCkFiaGlqYW4gQmhhdHRhY2hhcnl5YTxicj4NCkFzc29jaWF0 ZSBDb25zdWx0YW50PGJyPg0KU2NpZW50aXN0LCBJbm5vdmF0aW9uIExhYiwgS29sa2F0YSwgSW5k aWE8YnI+DQpUYXRhIENvbnN1bHRhbmN5IFNlcnZpY2VzPGJyPg0KTWFpbHRvOiBhYmhpamFuLmJo YXR0YWNoYXJ5eWFAdGNzLmNvbTxicj4NCldlYnNpdGU6IDwvZm9udD48YSBocmVmPWh0dHA6Ly93 d3cudGNzLmNvbS8+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPmh0dHA6Ly93d3cudGNz LmNvbTwvZm9udD48L2E+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPjxicj4NCl9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KRXhwZXJpZW5jZSBj ZXJ0YWludHkuICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO0lUIFNlcnZpY2VzPGJyPg0KICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO0J1c2luZXNzIFNvbHV0aW9uczxicj4NCiAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDtDb25zdWx0aW5nPGJyPg0KX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX188YnI+DQo8L2ZvbnQ+DQo8YnI+DQo8YnI+PHR0Pjxmb250 IHNpemU9Mj4mcXVvdDtBY2UmcXVvdDsgJmx0O2FjZS1ib3VuY2VzQGlldGYub3JnJmd0OyB3cm90 ZQ0Kb24gMTAvMTQvMjAxNSAxMToyMzo0NSBQTTo8YnI+DQo8YnI+DQomZ3Q7IEZyb206IFJhZmEg TWFyaW4gTG9wZXogJmx0O3JhZmFAdW0uZXMmZ3Q7PC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250 IHNpemU9Mj4mZ3Q7IFRvOiBBYmhpamFuIEJoYXR0YWNoYXJ5eWEgJmx0O2FiaGlqYW4uYmhhdHRh Y2hhcnl5YUB0Y3MuY29tJmd0OzwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0 OyBDYzogNnRpc2NoQGlldGYub3JnLCBhY2VAaWV0Zi5vcmcsIGFAYWNrbC5pbywNClJhZmEgTWFy aW4gTG9wZXogPGJyPg0KJmd0OyAmbHQ7cmFmYUB1bS5lcyZndDssIGRhbi5nYXJjaWFAdW0uZXM8 L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgRGF0ZTogMTAvMTQvMjAxNSAx MToyNCBQTTwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyBTdWJqZWN0OiBS ZTogW0FjZV0gT3B0aW1pemluZyBFQVAtb3Zlci1Db0FQIHBheWxvYWQ8L2ZvbnQ+PC90dD4NCjxi cj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgU2VudCBieTogJnF1b3Q7QWNlJnF1b3Q7ICZsdDthY2Ut Ym91bmNlc0BpZXRmLm9yZyZndDs8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZn dDsgPGJyPg0KJmd0OyBIaSBBYmhpamFuOjxicj4NCiZndDsgPGJyPg0KJmd0OyAmZ3Q7IEVsIDEz IG9jdCAyMDE1LCBhIGxhcyAxNDo0OCwgQWJoaWphbiBCaGF0dGFjaGFyeXlhIDxicj4NCiZndDsg Jmx0O2FiaGlqYW4uYmhhdHRhY2hhcnl5YUB0Y3MuY29tJmd0OyBlc2NyaWJpw7M6PGJyPg0KJmd0 OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyBIaSBSYWZhLCA8YnI+DQomZ3Q7ICZndDsgVGhlIGFwcGxp Y2F0aW9uIGxheWVyIGRyaXZlbiBhcHByb2FjaCBpcyByZWFsbHkgaW50ZXJlc3RpbmcgaW4NCnRo ZTxicj4NCiZndDsgY29uc3RyYWluZWQgZW52aXJvbm1lbnQgY29udGV4dC4gV2UgaGFkIGEgc2lt aWxhciBhcHByb2FjaCBmb3IgPGJyPg0KJmd0OyBzZWN1cmUgc2Vzc2lvbiBlc3RhYmxpc2htZW50 IChhc3N1bWluZyB0aGF0IGJvb3Qtc3RyYXBwaW5nIGlzIDxicj4NCiZndDsgYWxyZWFkeSBkb25l KSB3aGljaCBwZXJmb3JtcyB0aGUgc2Vzc2lvbiBlc3RhYmxpc2htZW50IGluIENvQVAgYnV0DQo8 YnI+DQomZ3Q7IHVzZXMgdGhlIERUTFMgZW5jcnlwdGlvbiBhbmQgaGVhZGVyLXN0cnVjdHVyZSBm b3Igc2VjdXJlIGV4Y2hhbmdlDQpvZjxicj4NCiZndDsgdGhlIGFwcGxpY2F0aW9uLWxheWVyIG1l c3NhZ2UuIENvaW5jaWRlbnRhbGx5IHdlIGhhdmUgYWxzbyBkZWZpbmVkDQo8YnI+DQomZ3Q7IGFu IG9wdGlvbiBjYWxsZWQgJnF1b3Q7QXV0aCZxdW90OyAuIDxicj4NCiZndDsgPGJyPg0KJmd0OyBB cyB5b3UgbWVudGlvbiB0aGUgYm9vdHN0cmFwcGluZyBjYW4gcHJvdmlkZSBhIHN5bW1ldHJpYyBr ZXkgKHdlIDxicj4NCiZndDsgY2FsbCBpdCBDT0FQX0FVVEhfUFNLKSB0byBwcm90ZWN0IENvQVAg bWVzc2FnZXMgd2l0aCBBVVRIIG9wdGlvbi4NCjxicj4NCiZndDsgQnV0IEkgc2VlIHlvdSB3b3Vs ZCByZXF1aXJlIGFuIGFkZGl0aW9uYWwgZXhjaGFuZ2UuIEkgZ3Vlc3MgeW91IGFyZQ0KPGJyPg0K Jmd0OyB0aGlua2luZyB0aGUgY29tbXVuaWNhdGlvbiBhbW9uZyBzbWFydCBvYmplY3RzIGFmdGVy IHRoZSBib290c3RyYXBwaW5nLjxicj4NCiZndDsgPGJyPg0KJmd0OyBCZXN0IFJlZ2FyZHMuPGJy Pg0KJmd0OyA8YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7IEhlcmUgaXMgdGhlIGxpbmsg dG8gdGhlIGRyYWZ0OiA8L2ZvbnQ+PC90dD48YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3Jn L2h0bWwvZHJhZnQtIj48dHQ+PGZvbnQgc2l6ZT0yPmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRt bC9kcmFmdC08L2ZvbnQ+PC90dD48L2E+PHR0Pjxmb250IHNpemU9Mj48YnI+DQomZ3Q7IGJoYXR0 YWNoYXJ5eWEtZGljZS1sZXNzLW9uLWNvYXAtMDAgKEhhZCBhbiBvbGRlciB3b3JrIGluIHByb2dy ZXNzOg0KPGJyPg0KJmd0OyA8L2ZvbnQ+PC90dD48YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYu b3JnL2h0bWwvZHJhZnQtYmhhdHRhY2hhcnl5YS1jb3JlLWNvYXAtbGl0ZS1hdXRoLTAwIj48dHQ+ PGZvbnQgc2l6ZT0yPmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1iaGF0dGFjaGFy eXlhLWNvcmUtY29hcC1saXRlLWF1dGgtMDA8L2ZvbnQ+PC90dD48L2E+PHR0Pjxmb250IHNpemU9 Mj48YnI+DQomZ3Q7IC4gQnV0IHRoaXMgb25lIGRpZCBub3QgcHJvdmlkZSBjaGFubmVsIHNlY3Vy aXR5KS4gPGJyPg0KJmd0OyAmZ3Q7IEkgc3VibWl0dGVkIHRoaXMgZHJhZnQgdG8gZGljZSwgaG93 ZXZlciwgZGljZSB3YXMgbm90IHJlYWxseQ0KdGhlIDxicj4NCiZndDsgcGxhY2UgdG8gZGlzY3Vz cyB0aGlzLiBPdXIgZHJhZnQgaXMgZHVlIHRvIGV4cGlyZSBpbiBhYm91dCA0IGRheXMuDQo8YnI+ DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZn dDsgUmVnYXJkczxicj4NCiZndDsgJmd0OyBBYmhpamFuIEJoYXR0YWNoYXJ5eWE8YnI+DQomZ3Q7 ICZndDsgQXNzb2NpYXRlIENvbnN1bHRhbnQ8YnI+DQomZ3Q7ICZndDsgU2NpZW50aXN0LCBJbm5v dmF0aW9uIExhYiwgS29sa2F0YSwgSW5kaWE8YnI+DQomZ3Q7ICZndDsgVGF0YSBDb25zdWx0YW5j eSBTZXJ2aWNlczxicj4NCiZndDsgJmd0OyBNYWlsdG86IGFiaGlqYW4uYmhhdHRhY2hhcnl5YUB0 Y3MuY29tPGJyPg0KJmd0OyAmZ3Q7IFdlYnNpdGU6IDwvZm9udD48L3R0PjxhIGhyZWY9aHR0cDov L3d3dy50Y3MuY29tLz48dHQ+PGZvbnQgc2l6ZT0yPmh0dHA6Ly93d3cudGNzLmNvbTwvZm9udD48 L3R0PjwvYT48dHQ+PGZvbnQgc2l6ZT0yPjxicj4NCiZndDsgJmd0OyBfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCiZndDsgJmd0OyBFeHBlcmllbmNlIGNl cnRhaW50eS4gJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7SVQgU2VydmljZXM8YnI+DQomZ3Q7 ICZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsNCiZuYnNwOyAmbmJzcDsgJm5ic3A7QnVzaW5lc3MgU29sdXRpb25zPGJyPg0K Jmd0OyAmZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7DQombmJzcDsgJm5ic3A7ICZuYnNwO0NvbnN1bHRpbmc8YnI+DQomZ3Q7 ICZndDsgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQom Z3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAmcXVvdDtBY2UmcXVvdDsg Jmx0O2FjZS1ib3VuY2VzQGlldGYub3JnJmd0OyB3cm90ZSBvbiAxMC8xMy8yMDE1DQoxMjoxMTo0 NiBBTTo8YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgRnJvbTogUmFmYSBNYXJp biBMb3BleiAmbHQ7cmFmYUB1bS5lcyZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgVG86IEFsZXhh bmRlciBQZWxvdiAmbHQ7YUBhY2tsLmlvJmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyBDYzogNnRp c2NoQGlldGYub3JnLCBEYW4gR2FyY2lhICZsdDtkYW4uZ2FyY2lhQHVtLmVzJmd0OywNClJhZmEg TWFyaW4gTG9wZXo8YnI+DQomZ3Q7ICZndDsgJmd0OyAmbHQ7cmFmYUB1bS5lcyZndDssIGFjZUBp ZXRmLm9yZyA8YnI+DQomZ3Q7ICZndDsgJmd0OyBEYXRlOiAxMC8xMy8yMDE1IDEyOjE2IEFNIDxi cj4NCiZndDsgJmd0OyAmZ3Q7IFN1YmplY3Q6IFJlOiBbQWNlXSBPcHRpbWl6aW5nIEVBUC1vdmVy LUNvQVAgcGF5bG9hZCA8YnI+DQomZ3Q7ICZndDsgJmd0OyBTZW50IGJ5OiAmcXVvdDtBY2UmcXVv dDsgJmx0O2FjZS1ib3VuY2VzQGlldGYub3JnJmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyA8YnI+ DQomZ3Q7ICZndDsgJmd0OyBEZWFyIEFsZXhhbmRlcjo8YnI+DQomZ3Q7ICZndDsgJmd0OyA8YnI+ DQomZ3Q7ICZndDsgJmd0OyBUaGFua3MgZm9yIHlvdXIgY29tbWVudHMgPGJyPg0KJmd0OyAmZ3Q7 ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyBFbCA4IG9jdCAyMDE1LCBhIGxhcyAxMDo1 MywgQWxleGFuZGVyIFBlbG92ICZsdDthQGFja2wuaW8mZ3Q7DQplc2NyaWJpw7M6PGJyPg0KJmd0 OyAmZ3Q7ICZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IERlYXIgUmFmYSw8YnI+ DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgSSd2ZSBiZWVu IHJlYWRpbmcgdGhlIGxhdGVzdCB2ZXJzaW9uIG9mIHlvdXIgZHJhZnQNCiggZHJhZnQtbWFyaW4t PGJyPg0KJmd0OyAmZ3Q7ICZndDsgYWNlLXdnLWNvYXAtZWFwLTAxLnR4dCApLCBhbmQgSSBoYXZl IGEgY291cGxlIG9mIHF1ZXN0aW9ucw0KcmVnYXJkaW5nPGJyPg0KJmd0OyAmZ3Q7ICZndDsgc29t ZSBvZiB0aGUgcGF5bG9hZCBvcHRpb25zLCB3aGljaCBjb3VsZCBiZSBvcHRpbWl6ZWQgZXZlbg0K ZnVydGhlcjo8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZn dDsgMSkgVXNlIHNob3J0ZXIgbmFtZSBmb3IgdGhlIC9hdXRoIHJlc291cmNlPGJyPg0KJmd0OyAm Z3Q7ICZndDsgJmd0OyAyKSBNYW5kYXRlIHRoZSB1c2Ugb2YgemVyby1sZW5ndGggQ29BUCB0b2tl bjxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyBUaGUg Zmlyc3QsIGFuZCB0aGUgbW9yZSBzaW1wbGUgb25lLCBpcyAtIHdvdWxkIGl0IGJlDQpwb3NzaWJs ZSB0byA8YnI+DQomZ3Q7ICZndDsgJmd0OyBjaGFuZ2UgdGhlIG5hbWUgb2YgdGhlIGF1dGhlbnRp Y2F0aW9uIHJlc291cmNlIGZyb20gL2F1dGgNCnRvIGEgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgc2hv cnRlciBvbmUgKGxpa2UgL2EpPyBNYXliZSBpdCBjb3VsZCBiZSBhbiBvcHRpb24gdG8gY2hhbmdl DQp0aGUgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgbmFtZSBvZiB0aGlzIHJlc291cmNlLCBiYXNlZCBv biB0aGUgdW5kZXJsYXlpbmcgYXJjaGl0ZWN0dXJlLA0KZS5nLiA8YnI+DQomZ3Q7ICZndDsgJmd0 OyBhbiBSRkMgY291bGQgbWFuZGF0ZSB0aGF0IGluIGEgc3BlY2lmaWMgbmV0d29yayB0aGUgcmVz b3VyY2UNCmNvdWxkIDxicj4NCiZndDsgJmd0OyAmZ3Q7IGJlIG5hbWVkIC9hLCB3aGVyZWFzIHRo ZSBkZWZhdWx0IHZhbHVlIGNvdWxkIHJlbWFpbiAvYXV0aD88YnI+DQomZ3Q7ICZndDsgJmd0OyA8 YnI+DQomZ3Q7ICZndDsgJmd0OyBbUmFmYV0gSSBkbyBub3Qgc2VlIGFueSBwcm9ibGVtIHRvIHNo b3J0ZW4gdGhlIHJlc291cmNlDQpuYW1lLjxicj4NCiZndDsgJmd0OyAmZ3Q7IDxicj4NCiZndDsg Jmd0OyAmZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyBUaGUgc2Vjb25kLCB3aGlj aCBpcyBhIGxpdHRsZSBiaXQgbW9yZSBzdWJ0bGUuIFRva2Vucw0KYXJlIHVzZWQgdG8gPGJyPg0K Jmd0OyAmZ3Q7ICZndDsgbWF0Y2ggcmVzcG9uc2VzIHRvIHJlcXVlc3RzLCBidXQgZHVyaW5nIHRo ZSBhdXRoZW50aWNhdGlvbi88YnI+DQomZ3Q7ICZndDsgJmd0OyBhdXRob3JpemF0aW9uIHBoYXNl IGEgc2luZ2xlIHBlZXIgKGVuZHBvaW50KSB3b3VsZCBjb21tdW5pY2F0ZQ0Kd2l0aCA8YnI+DQom Z3Q7ICZndDsgJmd0OyBhIHNpbmdsZSBhdXRoZW50aWNhdG9yLiBNb3Jlb3ZlciwgdGhlIGNvbW11 bmljYXRpb24gaGFwcGVucw0KaW4gYSA8YnI+DQomZ3Q7ICZndDsgJmd0OyBzZXJpYWwgZmFzaGlv biwgYW5kIHJlc3BvbnNlcyBhcmUgcGlnZ3liYWNrZWQuIFRoaXMgZmFsbHMNCmluIHRoZSA8YnI+ DQomZ3Q7ICZndDsgJmd0OyBjYXNlIHdoZW4gemVyby1sZW5ndGggdG9rZW4gaXMgYWxzbyBhZHZp c2VkIGJ5IFJGQzcyNTIuDQpEbyB5b3UgdGhpbms8YnI+DQomZ3Q7ICZndDsgJmd0OyB0aGF0IGl0 IHdvdWxkIGJlIGFwcHJvcHJpYXRlIHRvIG1ha2UgdGhlIHVzZSBvZiB6ZXJvLWxlbmd0aA0KdG9r ZW4gPGJyPg0KJmd0OyAmZ3Q7ICZndDsgbWFuZGF0b3J5IGZvciBFQVAtb3Zlci1Db0FQPzxicj4N CiZndDsgJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7IFtSYWZhXSBJIGd1ZXNzIHlvdSBh cmUgcmVmZXJyaW5nIHRvIHRoaXMgdGV4dDogJm5ic3A7PGJyPg0KJmd0OyAmZ3Q7ICZndDsgPGJy Pg0KJmd0OyAmZ3Q7ICZndDsgJnF1b3Q7QW4gZW1wdHkgdG9rZW4gdmFsdWUgaXMgYXBwcm9wcmlh dGUgZS5nLiwgd2hlbjxicj4NCiZndDsgJmd0OyAmZ3Q7ICZuYnNwOyAmbmJzcDtubyBvdGhlciB0 b2tlbnMgYXJlIGluIHVzZSB0byBhIGRlc3RpbmF0aW9uLA0KJnF1b3Q7b3Igd2hlbiByZXF1ZXN0 cyBhcmU8YnI+DQomZ3Q7ICZndDsgJmd0OyAmbmJzcDsgJm5ic3A7bWFkZSBzZXJpYWxseSBwZXIg ZGVzdGluYXRpb24gYW5kIHJlY2VpdmUgcGlnZ3liYWNrZWQNCnJlc3BvbnNlcy7igJ08YnI+DQom Z3Q7ICZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyBJIHdvdWxkIHNheSB0aGF0IHVzaW5n IHplcm8tbGVuZ3RoIHRva2VuIGlzIHBvc3NpYmxlLiBXaGF0DQpJIGFtIG5vdCA8YnI+DQomZ3Q7 ICZndDsgJmd0OyBzdXJlIGlzIHdoZXRoZXIgbWFrZSBpdCBtYW5kYXRvcnkgb3Igbm90LiBJIG1l YW4gd2UgY291bGQNCnNheSB0aGF0IDxicj4NCiZndDsgJmd0OyAmZ3Q7IGlmIHRoZSBjbGllbnQg c2VuZHMgYSB6ZXJvLWxlbmd0aCB0b2tlbiB0aGUgc2VydmVyIGNhbiBjb25zaWRlcg0KaXQgPGJy Pg0KJmd0OyAmZ3Q7ICZndDsgT0sgYXMgcGVyIHRoZSB0ZXh0IGFib3ZlLiBJZiB0aGVyZSBpcyBh IG5vbi16ZXJvIGxlbmd0aA0KdG9rZW4gdmFsdWUgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgc2hvdWxk IGJlIGFsc28gZmluZS48YnI+DQomZ3Q7ICZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyBX aGF0IGRvIHlvdSB0aGluaz88YnI+DQomZ3Q7ICZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0 OyBCZXN0IFJlZ2FyZHMuPGJyPg0KJmd0OyAmZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsg Jmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IEJlc3QsPGJyPg0KJmd0OyAmZ3Q7ICZndDsg Jmd0OyBBbGV4YW5kZXI8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAm Z3Q7ICZndDsgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188 YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IEFjZSBtYWlsaW5nIGxpc3Q8YnI+DQomZ3Q7ICZndDsg Jmd0OyAmZ3Q7IEFjZUBpZXRmLm9yZzxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgPC9mb250Pjwv dHQ+PGEgaHJlZj1odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2FjZT48dHQ+ PGZvbnQgc2l6ZT0yPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vYWNlPC9m b250PjwvdHQ+PC9hPjx0dD48Zm9udCBzaXplPTI+PGJyPg0KJmd0OyAmZ3Q7ICZndDsgPGJyPg0K Jmd0OyAmZ3Q7ICZndDsgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLTxicj4NCiZndDsgJmd0OyAmZ3Q7IFJhZmFlbCBNYXJpbiBMb3BleiwgUGhE PGJyPg0KJmd0OyAmZ3Q7ICZndDsgRGVwdC4gSW5mb3JtYXRpb24gYW5kIENvbW11bmljYXRpb25z IEVuZ2luZWVyaW5nIChESUlDKTxicj4NCiZndDsgJmd0OyAmZ3Q7IEZhY3VsdHkgb2YgQ29tcHV0 ZXIgU2NpZW5jZS1Vbml2ZXJzaXR5IG9mIE11cmNpYTxicj4NCiZndDsgJmd0OyAmZ3Q7IDMwMTAw IE11cmNpYSAtIFNwYWluPGJyPg0KJmd0OyAmZ3Q7ICZndDsgVGVsZjogKzM0ODY4ODg4NTAxIEZh eDogKzM0ODY4ODg0MTUxIGUtbWFpbDogcmFmYUB1bS5lczxicj4NCiZndDsgJmd0OyAmZ3Q7IC0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08YnI+ DQomZ3Q7ICZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0 OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyBfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCiZndDsgJmd0OyAmZ3Q7IEFj ZSBtYWlsaW5nIGxpc3Q8YnI+DQomZ3Q7ICZndDsgJmd0OyBBY2VAaWV0Zi5vcmc8YnI+DQomZ3Q7 ICZndDsgJmd0OyA8L2ZvbnQ+PC90dD48YSBocmVmPWh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vYWNlPjx0dD48Zm9udCBzaXplPTI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9hY2U8L2ZvbnQ+PC90dD48L2E+PHR0Pjxmb250IHNpemU9Mj48YnI+DQom Z3Q7ICZndDsgPT09PT0tLS0tLT09PT09LS0tLS09PT09PTxicj4NCiZndDsgJmd0OyBOb3RpY2U6 IFRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaW4gdGhpcyBlLW1haWw8YnI+DQomZ3Q7ICZndDsg bWVzc2FnZSBhbmQvb3IgYXR0YWNobWVudHMgdG8gaXQgbWF5IGNvbnRhaW4gPGJyPg0KJmd0OyAm Z3Q7IGNvbmZpZGVudGlhbCBvciBwcml2aWxlZ2VkIGluZm9ybWF0aW9uLiBJZiB5b3UgYXJlIDxi cj4NCiZndDsgJmd0OyBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwgYW55IGRpc3NlbWluYXRp b24sIHVzZSwgPGJyPg0KJmd0OyAmZ3Q7IHJldmlldywgZGlzdHJpYnV0aW9uLCBwcmludGluZyBv ciBjb3B5aW5nIG9mIHRoZSA8YnI+DQomZ3Q7ICZndDsgaW5mb3JtYXRpb24gY29udGFpbmVkIGlu IHRoaXMgZS1tYWlsIG1lc3NhZ2UgPGJyPg0KJmd0OyAmZ3Q7IGFuZC9vciBhdHRhY2htZW50cyB0 byBpdCBhcmUgc3RyaWN0bHkgcHJvaGliaXRlZC4gSWYgPGJyPg0KJmd0OyAmZ3Q7IHlvdSBoYXZl IHJlY2VpdmVkIHRoaXMgY29tbXVuaWNhdGlvbiBpbiBlcnJvciwgPGJyPg0KJmd0OyAmZ3Q7IHBs ZWFzZSBub3RpZnkgdXMgYnkgcmVwbHkgZS1tYWlsIG9yIHRlbGVwaG9uZSBhbmQgPGJyPg0KJmd0 OyAmZ3Q7IGltbWVkaWF0ZWx5IGFuZCBwZXJtYW5lbnRseSBkZWxldGUgdGhlIG1lc3NhZ2UgPGJy Pg0KJmd0OyAmZ3Q7IGFuZCBhbnkgYXR0YWNobWVudHMuIFRoYW5rIHlvdTxicj4NCiZndDsgJmd0 OyA8YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7IF9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KJmd0OyAmZ3Q7IEFjZSBtYWlsaW5nIGxpc3Q8 YnI+DQomZ3Q7ICZndDsgQWNlQGlldGYub3JnPGJyPg0KJmd0OyAmZ3Q7IDwvZm9udD48L3R0Pjxh IGhyZWY9aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9hY2U+PHR0Pjxmb250 IHNpemU9Mj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2FjZTwvZm9udD48 L3R0PjwvYT48dHQ+PGZvbnQgc2l6ZT0yPjxicj4NCiZndDsgPGJyPg0KJmd0OyAtLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPGJyPg0KJmd0OyBS YWZhZWwgTWFyaW4gTG9wZXosIFBoRDxicj4NCiZndDsgRGVwdC4gSW5mb3JtYXRpb24gYW5kIENv bW11bmljYXRpb25zIEVuZ2luZWVyaW5nIChESUlDKTxicj4NCiZndDsgRmFjdWx0eSBvZiBDb21w dXRlciBTY2llbmNlLVVuaXZlcnNpdHkgb2YgTXVyY2lhPGJyPg0KJmd0OyAzMDEwMCBNdXJjaWEg LSBTcGFpbjxicj4NCiZndDsgVGVsZjogKzM0ODY4ODg4NTAxIEZheDogKzM0ODY4ODg0MTUxIGUt bWFpbDogcmFmYUB1bS5lczxicj4NCiZndDsgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTxicj4NCiZndDsgPGJyPg0KJmd0OyA8YnI+DQomZ3Q7 IDxicj4NCiZndDsgPGJyPg0KJmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXzxicj4NCiZndDsgQWNlIG1haWxpbmcgbGlzdDxicj4NCiZndDsgQWNlQGll dGYub3JnPGJyPg0KJmd0OyA8L2ZvbnQ+PC90dD48YSBocmVmPWh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vYWNlPjx0dD48Zm9udCBzaXplPTI+aHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9hY2U8L2ZvbnQ+PC90dD48L2E+PHR0Pjxmb250IHNpemU9Mj48 YnI+DQo8L2ZvbnQ+PC90dD4NCg== --=_alternative 001020BC65257EDF_=-- From nobody Mon Oct 19 06:00:14 2015 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 489921A9071; Mon, 19 Oct 2015 06:00:08 -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.6.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151019130008.20530.56573.idtracker@ietfa.amsl.com> Date: Mon, 19 Oct 2015 06:00:08 -0700 Archived-At: Cc: ace@ietf.org Subject: [Ace] I-D Action: draft-ietf-ace-actors-02.txt X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Oct 2015 13:00:08 -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 Working Group 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-02.txt Pages : 32 Date : 2015-10-19 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-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ace-actors-02 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 Mon Oct 19 06:07:21 2015 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C87F51A9093 for ; Mon, 19 Oct 2015 06:07:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.55 X-Spam-Level: X-Spam-Status: No, score=-1.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5VhYsxuMqwVI for ; Mon, 19 Oct 2015 06:07:19 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 939AA1A909F for ; Mon, 19 Oct 2015 06:07:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [134.102.201.11]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id t9JD75aV014590 for ; Mon, 19 Oct 2015 15:07:05 +0200 (CEST) Received: from nar.local (p5DC7F6AE.dip0.t-ipconnect.de [93.199.246.174]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3nfdf12wgJz4pnm; Mon, 19 Oct 2015 15:07:05 +0200 (CEST) Message-ID: <5624EAF7.4080807@tzi.org> Date: Mon, 19 Oct 2015 15:07:03 +0200 From: Carsten Bormann User-Agent: Postbox 4.0.5 (Macintosh/20150923) MIME-Version: 1.0 To: ace@ietf.org X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Archived-At: Subject: [Ace] We submitted draft-ietf-ace-actors-02.txt, time to read it (again) X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 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, 19 Oct 2015 13:07:21 -0000 This new version takes in the review comments from the WG. Unfortunately, the authors ran out of time fine-tuning the content before the I-D deadline, so more than usually please consider all errors those of the editor. This version should be a solid basis for closing the remaining discussion items in (hallways and working group meetings in) Yokohama, so if you haven't reviewed it yet, this might be a good time. (If you already did, we'd like to know whether your comments were addressed properly.) Grüße, Carsten internet-drafts@ietf.org wrote: > 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 Working Group 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-02.txt > Pages : 32 > Date : 2015-10-19 > > 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-02 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-ace-actors-02 > > > 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/ > > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace > From nobody Mon Oct 19 10:49:00 2015 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E810F1A8BC2 for ; Mon, 19 Oct 2015 10:48:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lqUFaUC44DuX for ; Mon, 19 Oct 2015 10:48:50 -0700 (PDT) Received: from mail-lf0-f45.google.com (mail-lf0-f45.google.com [209.85.215.45]) (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 978431A898F for ; Mon, 19 Oct 2015 10:48:49 -0700 (PDT) Received: by lffz202 with SMTP id z202so33483970lff.3 for ; Mon, 19 Oct 2015 10:48:47 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:references:to:from:message-id:date :user-agent:mime-version:in-reply-to:content-type; bh=hfepCXvScX47kk0ljAX/SDXwwVZKvNd/ht5UuWd8Gmc=; b=QRxCfhESN9+k5vcGjmpzeaT6/514vMuuyJmqVwAqMxA96UWXNBCEJLVbfjXMqJqpUx op7gK+R5lH4764J/ygI/hDOwlSOjKLv3y5obfJxUrrb9h2/ia8nQOIHSbtgfJrUyVadn Xiv+NUpBvYIBAkqXFbqn/80FWkSJxRp8MaUfJV/pdn8a+y5P+wMhp9zNAB69voPATL/J ucyKJ1HvTGukX1jfpGwo0tPgQ0vrKbe7COgidEl9A2nQSglKfTgPmLmmm7Ozf+n7WJ7l u1exY3CcB7FzszbLZ9S39duYaIIfIIWbzQ+q9AKjzjTpyCWI+m4YfmlTYyHXPYFsJJHC qLHQ== X-Gm-Message-State: ALoCoQltah+zqXnuZWHQvBdhcnnYmyNunAwweYB1YLPi2K2NB5QVyrAePT7J9kg/UyUMLRr8yM7I X-Received: by 10.25.157.15 with SMTP id g15mr10089640lfe.113.1445276927857; Mon, 19 Oct 2015 10:48:47 -0700 (PDT) Received: from [192.168.0.103] (89-253-76-185.customers.ownit.se. [89.253.76.185]) by smtp.gmail.com with ESMTPSA id jb10sm5610498lbc.46.2015.10.19.10.48.47 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 19 Oct 2015 10:48:47 -0700 (PDT) References: <20151019174548.4496.38910.idtracker@ietfa.amsl.com> To: "ace@ietf.org" From: Ludwig Seitz X-Forwarded-Message-Id: <20151019174548.4496.38910.idtracker@ietfa.amsl.com> Message-ID: <56252CFE.7080707@sics.se> Date: Mon, 19 Oct 2015 19:48:46 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <20151019174548.4496.38910.idtracker@ietfa.amsl.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms040608070908030605070802" Archived-At: Subject: [Ace] Fwd: New Version Notification for draft-seitz-ace-oauth-authz-00.txt X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 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, 19 Oct 2015 17:48:58 -0000 This is a cryptographically signed message in MIME format. --------------ms040608070908030605070802 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable I have submitted a new draft on authorization using OAuth for ACE. It defines a number of profiles that allow to adapt the vanilla OAuth=20 protocols to various constrained settings. Comments are welcome. @chairs: I'd like a presentation slot for this one at IETF 94. Regards, Ludwig Seitz -------- Forwarded Message -------- Subject: New Version Notification for draft-seitz-ace-oauth-authz-00.txt Date: Mon, 19 Oct 2015 10:45:48 -0700 From: internet-drafts@ietf.org To: Goeran Selander , Erik Wahlstroem=20 , Ludwig Seitz , Goran=20 Selander , Hannes Tschofenig=20 , Samuel Erdtman A new version of I-D, draft-seitz-ace-oauth-authz-00.txt has been successfully submitted by Ludwig Seitz and posted to the IETF repository. Name: draft-seitz-ace-oauth-authz Revision: 00 Title: Authorization for the Internet of Things using OAuth 2.0 Document date: 2015-10-19 Group: Individual Submission Pages: 45 URL:=20 https://www.ietf.org/internet-drafts/draft-seitz-ace-oauth-authz-00.txt Status:=20 https://datatracker.ietf.org/doc/draft-seitz-ace-oauth-authz/ Htmlized: https://tools.ietf.org/html/draft-seitz-ace-oauth-authz-0= 0 Abstract: This memo defines how to use OAuth 2.0 as an authorization framework with Internet of Things (IoT) deployments, thus bringing a well-known= and widely used security solution to IoT devices. Where possible vanilla OAuth 2.0 is used, but where the limitations of IoT devices require it, profiles and extensions are provided. =20 Please note that it may take a couple of minutes from the time of submiss= ion until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat --------------ms040608070908030605070802 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 DFQwggYYMIIFAKADAgECAgMMhpgwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYw FAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZp Y2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJt ZWRpYXRlIENsaWVudCBDQTAeFw0xNTAxMDgwODM5MDZaFw0xNjAxMDkyMjQxMzBaMDgxFzAV BgNVBAMMDmx1ZHdpZ0BzaWNzLnNlMR0wGwYJKoZIhvcNAQkBFg5sdWR3aWdAc2ljcy5zZTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMVB4rAuq4FxbARxwRqPLpc/3C194F+V H4XMKK6fu3Y8zDLijzNSjh6tG41oZhXvJcvAs1nZNjUutNLeyBAUFiYhy7HXNdlKpjbMEFKQ +6KpEdZ0Rk+pXgB2E1mqZEfp3M2djcQ/h+7uGVlSGYNAxYk6rWPIIWBx2GMvAQaHP4xxu/F+ PiSQILOVzmtIFZe1t/Lw71aaNeMYVhARo8z5PVsVoq6gBeujxfiRLtiQ/S8xW6RKvNvUkVyT BQfcKaEDZR9FENNf9rFgiAcT6R7hI8RBf1d2fxdlbDU8uM72K3fvzGDt8N9Bfm1kDWbDBxJE 1taRIYs+60D1kwV6DvBb9MECAwEAAaOCAtQwggLQMAkGA1UdEwQCMAAwCwYDVR0PBAQDAgSw MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAdBgNVHQ4EFgQU6ryrKahJtBOEdbIL AAWCpOsQyagwHwYDVR0jBBgwFoAUU3Ltkpzg2ssBXHx+ljVO8tS4UYIwGQYDVR0RBBIwEIEO bHVkd2lnQHNpY3Muc2UwggFMBgNVHSAEggFDMIIBPzCCATsGCysGAQQBgbU3AQIDMIIBKjAu BggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjCB9wYIKwYB BQUHAgIwgeowJxYgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwAwIBARqBvlRo aXMgY2VydGlmaWNhdGUgd2FzIGlzc3VlZCBhY2NvcmRpbmcgdG8gdGhlIENsYXNzIDEgVmFs aWRhdGlvbiByZXF1aXJlbWVudHMgb2YgdGhlIFN0YXJ0Q29tIENBIHBvbGljeSwgcmVsaWFu Y2Ugb25seSBmb3IgdGhlIGludGVuZGVkIHB1cnBvc2UgaW4gY29tcGxpYW5jZSBvZiB0aGUg cmVseWluZyBwYXJ0eSBvYmxpZ2F0aW9ucy4wNgYDVR0fBC8wLTAroCmgJ4YlaHR0cDovL2Ny bC5zdGFydHNzbC5jb20vY3J0dTEtY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEF BQcwAYYtaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczEvY2xpZW50L2NhMEIG CCsGAQUFBzAChjZodHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MxLmNs aWVudC5jYS5jcnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqG SIb3DQEBBQUAA4IBAQBl8BbG0n7+JjFqiJOuAqMbkeqM6Oyd+4oHGu3fbaSiM1SKesae2bfm vifV99a+M4DERZ2SVkOYcvNlv31Q3hvYtzRjDOqewzVKxo021R3ddQULW1DhvTEpclikG5rd 0NRJQn+EkSwEKLeUj68i0dhU8ULhZDDq3A81cTcZzIGrTjNnwDvCktB/sF/iO4At6RJ24P3j KjYFPirW3NsvZ2gzZizSzeubPE0/cWcqEBJ/UtaFPF54efejjLuPRHHMLPDcvrwBhEiBxuG6 oTEo465g4pS9Vo/Z0GoZgZyA+aGQ+YPbPSsqsYmSBjZ6MGGDqQq0niE2dW+8IOdHQvMkqI52 MIIGNDCCBBygAwIBAgIBHjANBgkqhkiG9w0BAQUFADB9MQswCQYDVQQGEwJJTDEWMBQGA1UE ChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUg U2lnbmluZzEpMCcGA1UEAxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwHhcN MDcxMDI0MjEwMTU1WhcNMTcxMDI0MjEwMTU1WjCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoT DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUg Q2xpZW50IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAxwmDzM4t2BqxKaQu E6uWvooyg4ymiEGWVUet1G8SD+rqvyNH4QrvnEIaFHxOhESip7vMz39ScLpNLbL1QpOlPW/t FIzNHS3qd2XRNYG5Sv9RcGE+T4qbLtsjjJbi6sL7Ls/f/X9ftTyhxvxWkf8KW37iKrueKsxw 2HqolH7GM6FX5UfNAwAu4ZifkpmZzU1slBhyWwaQPEPPZRsWoTb7q8hmgv6Nv3Hg9rmA1/VP BIOQ6SKRkHXG0Hhmq1dOFoAFI411+a/9nWm5rcVjGcIWZ2v/43Yksq60jExipA4l5uv9/+Hm 33mbgmCszdj/Dthf13tgAv2O83hLJ0exTqfrlwIDAQABo4IBrTCCAakwDwYDVR0TAQH/BAUw AwEB/zAOBgNVHQ8BAf8EBAMCAQYwHQYDVR0OBBYEFFNy7ZKc4NrLAVx8fpY1TvLUuFGCMB8G A1UdIwQYMBaAFE4L7xqkQFulF2mHMMo0aEPQQa7yMGYGCCsGAQUFBwEBBFowWDAnBggrBgEF BQcwAYYbaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL2NhMC0GCCsGAQUFBzAChiFodHRwOi8v d3d3LnN0YXJ0c3NsLmNvbS9zZnNjYS5jcnQwWwYDVR0fBFQwUjAnoCWgI4YhaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vc2ZzY2EuY3JsMCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNv bS9zZnNjYS5jcmwwgYAGA1UdIAR5MHcwdQYLKwYBBAGBtTcBAgEwZjAuBggrBgEFBQcCARYi aHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEFBQcCARYoaHR0cDov L3d3dy5zdGFydHNzbC5jb20vaW50ZXJtZWRpYXRlLnBkZjANBgkqhkiG9w0BAQUFAAOCAgEA CoMIfXirLAZcuGOMXq4cuSN3TaFx2H2GvD5VSy/6rV55BYHbWNaPeQn3oBSU8KgQZn/Kck1J xbLpAxVCNtsxeW1R87ifhsYZ0qjdrA9anrW2MAWCtosmAOT4OxK9QPoSjCMxM3HbkZCDJgnl E8jMopH21BbyAYr7b5EfGRQJNtgWcvqSXwKHnTutR08+Kkn0KAkXCzeQNLeA5LlYUzFyM7kP Ap8pIRMQ+seHunmyG642S2+y/qHEdMuGIwpfz3eDF1PdctL04qYK/zu+Qg1Bw0RwgigVZs/0 c5HP2/e9DBHh7eSwtzYlk4AUr6yxLlcwSjOfOmKEQ/Q8tzh0IFiNu9IPuTGAPBn4CPxD0+Ru 8T2wg8/s43R/PT3kd1OEqOJUl7q+h+r6fpvU0Fzxd2tC8Ga6fDEPme+1Nbi+03pVjuZQKbGw KJ66gEn06WqaxVZC+J8hh/jR0k9mST1iAZPNYulcNJ8tKmVtjYsv0L1TSm2+NwON58tO+pIV zu3DWwSEXSf+qkDavQam+QtEOZxLBXI++aMUEapSn+k3Lxm48ZCYfAWLb/Xj7F5JQMbZvCex glAbYR0kIHqW5DnsYSdMD/IplJMojx0NBrxJ3fN9dvX2Y6BIXRsF1du4qESm4/3CKuyUV7p9 DW3mPlHTGLvYxnyKQy7VFBkoLINszBrOUeIxggPtMIID6QIBATCBlDCBjDELMAkGA1UEBhMC SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENl cnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJ bnRlcm1lZGlhdGUgQ2xpZW50IENBAgMMhpgwDQYJYIZIAWUDBAIBBQCgggIpMBgGCSqGSIb3 DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE1MTAxOTE3NDg0NlowLwYJKoZI hvcNAQkEMSIEIDLi3pGA6F/97jg5/iuP/FMRsMSlHPhJjFbaaHa0QXGVMGwGCSqGSIb3DQEJ DzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0D AgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgaUGCSsGAQQB gjcQBDGBlzCBlDCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzAp BgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0 YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgMMhpgwgacG CyqGSIb3DQEJEAILMYGXoIGUMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20g THRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG A1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EC AwyGmDANBgkqhkiG9w0BAQEFAASCAQADUxZ/HNBRhx1GNSXIS8OfJnc6xpwk/pAe+QTqCw5i KH4ZhN/GrLy+YGUSHGu19OZ8paSr/9zJYUBIb9csCWg1Vg7ad42fdG7uM2N3mAsMvqlJzK4v 0kwk2jtt9nRUoH/JEKXTg730FHw67f9TrlizEHUCrNPXwyDMe+/RSi8nZ21Hnpha4OLVE5kG ZvSFoVJlHhRI3aytkBY0o+FRIiokttRAJYw5cRB9CP0Sqn6gfSOFvg/C0TjQdDl3mcpvYf6i gnmyv9IxLoIBOMR49UUWvj6uF4fkDSFT+ElJr5il5WgAdhrVnToIfmHrw2b9TUAR2CdRNuv/ NvE1oIlbB10PAAAAAAAA --------------ms040608070908030605070802-- From nobody Tue Oct 20 02:06:35 2015 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F28931B2FDB; Tue, 20 Oct 2015 02:06:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.901 X-Spam-Level: X-Spam-Status: No, score=-3.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bJXp_oFijw7P; Tue, 20 Oct 2015 02:06:29 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2DD031B2FE0; Tue, 20 Oct 2015 02:06:28 -0700 (PDT) X-AuditID: c1b4fb25-f79a26d00000149a-4c-562604120348 Received: from ESESSHC024.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id CA.4F.05274.21406265; Tue, 20 Oct 2015 11:06:26 +0200 (CEST) Received: from ESESSMB303.ericsson.se ([169.254.3.10]) by ESESSHC024.ericsson.se ([153.88.183.90]) with mapi id 14.03.0248.002; Tue, 20 Oct 2015 11:06:25 +0200 From: =?utf-8?B?R8O2cmFuIFNlbGFuZGVy?= To: "Ace@ietf.org" , "core@ietf.org" , "cose@ietf.org" Thread-Topic: OSCOAP version -03 Thread-Index: AQHRCxaYBgV53xaj7EGOeqPGeMhtCQ== Date: Tue, 20 Oct 2015 09:06:25 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.7.141117 x-originating-ip: [153.88.183.20] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrDLMWRmVeSWpSXmKPExsUyM+Jvja4Qi1qYwdkmMYvv33qYLfa9Xc9s MW3rVFYHZo8lS34yBTBGcdmkpOZklqUW6dslcGUs2N/MVvBLsmLhuScsDYxLJLsYOTkkBEwk ujc1sEDYYhIX7q1n62Lk4hASOMooMenAB2YIZzGjxONtc9hBqtgEXCQeNDxiArFFBFIl9k/5 DdYtLCAtsXfyA3aIuILE9FmXoWr0JD5uv8oKYrMIqEocurUVrIZXwEKio6MfrIYRaPP3U2vA bGYBcYlbT+YzQVwkILFkz3lmCFtU4uXjf2BzRIFmrrzexAYRV5S4On05UD0HUK+mxPpd+hBj rCUOf50DNVJRYkr3Q6i1ghInZz5hmcAoOgvJtlkI3bOQdM9C0j0LSfcCRtZVjKLFqcVJuelG xnqpRZnJxcX5eXp5qSWbGIHRc3DLb9UdjJffOB5iFOBgVOLhfZCuGibEmlhWXJl7iFGag0VJ nLeZ6UGokEB6YklqdmpqQWpRfFFpTmrxIUYmDk6pBkbHfxPufIxnvpgi+fy885PfuYwpU9x6 ZWM2n6w/cSxvs+aC50tvhW2I3LRAcN5ibzaz7x+OveFdUsWlu+vqx4ePX1gp3fSz2j6DbWnR 2w0uZ0uvHrnIesG0qPmv3TxRgx3rFh7rbWy9q7RftKR4b6b0pe6Kl0ssgg673hDY2hEXuNrP V//SS+fTSizFGYmGWsxFxYkALoRKQH8CAAA= Archived-At: Subject: [Ace] OSCOAP version -03 X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 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, 20 Oct 2015 09:06:31 -0000 RGVhciBBQ0UsIENPUkUgYW5kIENPU0UgZmVsbG93cywNCg0KV2UgaGF2ZSB1cGRhdGVkIHRoZSBk cmFmdCBvbiBPYmplY3QgU2VjdXJpdHkgb2YgQ29BUDogVGhlIG1haW4gY29udGVudCBpcw0KdGhl IHNhbWUgYXMgcHJldmlvdXMgdmVyc2lvbiBidXQgdGhlIGRyYWZ0IGhhcyB1bmRlcmdvbmUgYSBs YXJnZQ0KcmVzdHJ1Y3R1cmluZyBmb3IgKGhvcGVmdWxseSkgaW1wcm92ZWQgcmVhZGVyIGV4cGVy aWVuY2UsIGluY2x1ZGluZyBzb21lDQpzaW1wbGlmaWNhdGlvbnMuIA0KDQpGb3IgZXhhbXBsZSwg dGhlIHR3byBDb0FQIG9wdGlvbnMgcHJvcG9zZWQgaW4gLTAyIGFyZSByZXBsYWNlZCB3aXRoIG9u ZQ0Kb3B0aW9uIGNhbGxlZCAiT2JqZWN0LVNlY3VyaXR5IiBpbmRpY2F0aW5nIHRoYXQgYSBDT1NF IG1lc3NhZ2UgaXMgaW5jbHVkZWQNCnRvIHByb3RlY3QgcmVsZXZhbnQgcGFydHMgb2YgdGhlIENv QVAgbWVzc2FnZS4gV2UgaGF2ZSBhbHNvIHVwZGF0ZWQgdGhlDQptZXNzYWdlIHNpemUgb3B0aW1p emF0aW9ucyBhbmQgY2FsY3VsYXRpb25zIGJhc2VkIG9uDQpkcmFmdC1pZXRmLWNvc2UtbXNnLTA1 Lg0KDQpDT1JFIGNoYWlyczogQ291bGQgd2UgaGF2ZSBhIHRpbWUgc2xvdCBhdCB0aGUgRjJGIHRv IG91dGxpbmUgdGhlIHVwZGF0ZXMNCmFuZCBhbHNvIGhhdmUgYSBkaXNjdXNzaW9uIGFib3V0IHdo YXQgQ29BUCBmZWF0dXJlcyB3ZSB3YW50IHRvIHByb3RlY3QNCmVuZC10by1lbmQ/DQoNCkNPU0Ug Y2hhaXJzOiBDb3VsZCB3ZSBoYXZlIGEgdGltZSBzbG90IGF0IHRoZSBGMkYgZm9yIGRpc2N1c3Np bmcgdGhlIENPU0UNCm1lc3NhZ2UgZm9ybWF0IGNvbnNpZGVyYXRpb25zIGluIHRoaXMgZHJhZnQ/ DQoNCg0KVGhhbmtzLA0KR8O2cmFuDQoNCg0KDQoNCg0KT24gMjAxNS0xMC0xOSAyMDo0OSwgImlu dGVybmV0LWRyYWZ0c0BpZXRmLm9yZyIgPGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZz4NCndyb3Rl Og0KDQo+DQo+QSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LXNlbGFuZGVyLWFjZS1vYmplY3Qt c2VjdXJpdHktMDMudHh0DQo+aGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBHb2Vy YW4gU2VsYW5kZXIgYW5kIHBvc3RlZCB0byB0aGUNCj5JRVRGIHJlcG9zaXRvcnkuDQo+DQo+TmFt ZToJCWRyYWZ0LXNlbGFuZGVyLWFjZS1vYmplY3Qtc2VjdXJpdHkNCj5SZXZpc2lvbjoJMDMNCj5U aXRsZToJCU9iamVjdCBTZWN1cml0eSBvZiBDb0FQIChPU0NPQVApDQo+RG9jdW1lbnQgZGF0ZToJ MjAxNS0xMC0xOQ0KPkdyb3VwOgkJSW5kaXZpZHVhbCBTdWJtaXNzaW9uDQo+UGFnZXM6CQk0Mg0K PlVSTDogICAgICAgICAgICANCj5odHRwczovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMv ZHJhZnQtc2VsYW5kZXItYWNlLW9iamVjdC1zZWN1cml0eS0wMw0KPi50eHQNCj5TdGF0dXM6ICAg ICAgICAgDQo+aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtc2VsYW5kZXIt YWNlLW9iamVjdC1zZWN1cml0eS8NCj5IdG1saXplZDogICAgICAgDQo+aHR0cHM6Ly90b29scy5p ZXRmLm9yZy9odG1sL2RyYWZ0LXNlbGFuZGVyLWFjZS1vYmplY3Qtc2VjdXJpdHktMDMNCj5EaWZm OiAgICAgICAgICAgDQo+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LXNl bGFuZGVyLWFjZS1vYmplY3Qtc2VjdXJpdHktMDMNCj4NCj5BYnN0cmFjdDoNCj4gICBUaGlzIG1l bW8gZGVmaW5lcyBPYmplY3QgU2VjdXJpdHkgb2YgQ29BUCAoT1NDT0FQKSwgYSBtZXRob2QgZm9y DQo+ICAgcHJvdGVjdGlvbiBvZiByZXF1ZXN0IGFuZCByZXNwb25zZSBtZXNzYWdlIGV4Y2hhbmdl cyBvZiB0aGUNCj4gICBDb25zdHJhaW5lZCBBcHBsaWNhdGlvbiBQcm90b2NvbCAoQ29BUCkgdXNp bmcgZGF0YSBvYmplY3Qgc2VjdXJpdHkuDQo+ICAgT1NDT0FQIHByb3ZpZGVzIGVuZC10by1lbmQg ZW5jcnlwdGlvbiwgaW50ZWdyaXR5IGFuZCByZXBsYXkNCj4gICBwcm90ZWN0aW9uIHRvIENvQVAg cGF5bG9hZCwgb3B0aW9ucyBhbmQgaGVhZGVyIGZpZWxkcywgYW5kIGEgc2VjdXJlDQo+ICAgYmlu ZGluZyBiZXR3ZWVuIENvQVAgcmVxdWVzdCBhbmQgcmVzcG9uc2UgbWVzc2FnZXMuICBUaGUgdXNl IG9mDQo+ICAgT1NDT0FQIGlzIHNpZ25hbGVkIHdpdGggdGhlIE9iamVjdC1TZWN1cml0eSBvcHRp b24sIGFsc28gZGVmaW5lZCBpbg0KPiAgIHRoaXMgbWVtby4NCj4NCj4gICAgICAgICAgICAgICAg ICANCj4gICAgICAgIA0KPg0KPg0KPlBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3Vw bGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mDQo+c3VibWlzc2lvbg0KPnVudGlsIHRoZSBo dG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0Zi5vcmcu DQo+DQo+VGhlIElFVEYgU2VjcmV0YXJpYXQNCj4NCg0K From nobody Tue Oct 20 03:20:21 2015 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6D5C1B317D for ; Tue, 20 Oct 2015 03:20:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.55 X-Spam-Level: X-Spam-Status: No, score=-1.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zo81qWcWJ2se for ; Tue, 20 Oct 2015 03:20:19 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EC8C91B3204 for ; Tue, 20 Oct 2015 03:20:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [134.102.201.11]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id t9KAKEU9006304 for ; Tue, 20 Oct 2015 12:20:14 +0200 (CEST) Received: from aung.tzi.org (eduroam-pool8-442.wlan.uni-bremen.de [134.102.7.185]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3ng9v22ZW8z4q1N for ; Tue, 20 Oct 2015 12:20:14 +0200 (CEST) From: Olaf Bergmann To: ace@ietf.org Date: Tue, 20 Oct 2015 12:20:14 +0200 Message-ID: <87r3kpu9i9.fsf@aung.informatik.uni-bremen.de> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: [Ace] Fwd: New Version Notification for draft-bergmann-ace-dcaf-cose-00.txt X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 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, 20 Oct 2015 10:20:21 -0000 Dear working group, we have submitted a document that specifies how the CBOR Encoded Message Syntax (aka COSE) can be used to achieve delegated authenticated authorization using DCAF as currently discussed in the ACE WG. Gr=C3=BC=C3=9Fe Olaf -------------------------------------------------------------------- A new version of I-D, draft-bergmann-ace-dcaf-cose-00.txt has been successfully submitted by Olaf Bergmann and posted to the IETF repository. Name: draft-bergmann-ace-dcaf-cose Revision: 00 Title: Using The Delegated CoAP Authentication and Authorization Framework= (DCAF) With CBOR Encoded Message Syntax Document date: 2015-10-19 Group: Individual Submission Pages: 19 URL: https://www.ietf.org/internet-drafts/draft-bergmann-ace-dca= f-cose-00.txt Status: https://datatracker.ietf.org/doc/draft-bergmann-ace-dcaf-co= se/ Htmlized: https://tools.ietf.org/html/draft-bergmann-ace-dcaf-cose-00 Abstract: This specification defines a profile for the Delegated CoAP Authentication and Authorization Framework (DCAF) that facilitates client authentication and authorization in a constrained environment using the CBOR Encoded Message Syntax. From nobody Tue Oct 20 14:47:23 2015 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 6FA6B1ACCF8; Tue, 20 Oct 2015 14:47:21 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Benoit Claise" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.6.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151020214721.21478.64042.idtracker@ietfa.amsl.com> Date: Tue, 20 Oct 2015 14:47:21 -0700 Archived-At: Cc: Hannes.Tschofenig@gmx.net, ace-chairs@ietf.org, ace@ietf.org, draft-ietf-ace-usecases@ietf.org Subject: [Ace] Benoit Claise's No Objection on draft-ietf-ace-usecases-09: (with COMMENT) X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Oct 2015 21:47:21 -0000 Benoit Claise has entered the following ballot position for draft-ietf-ace-usecases-09: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-ace-usecases/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- "ACE use cases." And ACE stands for :-) From nobody Wed Oct 21 02:21:45 2015 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D22F1A033A; Wed, 21 Oct 2015 02:21:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XXYt9AFdV3Bo; Wed, 21 Oct 2015 02:21:39 -0700 (PDT) Received: from xenon23.um.es (xenon23.um.es [155.54.212.163]) by ietfa.amsl.com (Postfix) with ESMTP id 196FB1A0338; Wed, 21 Oct 2015 02:21:39 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by xenon23.um.es (Postfix) with ESMTP id 2DBDB353F; Wed, 21 Oct 2015 11:21:38 +0200 (CEST) X-Virus-Scanned: by antispam in UMU at xenon23.um.es Received: from xenon23.um.es ([127.0.0.1]) by localhost (xenon23.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id PmSNqgPhaci6; Wed, 21 Oct 2015 11:21:38 +0200 (CEST) Received: from inf-205-216.inf.um.es (inf-205-216.inf.um.es [155.54.205.216]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: rafa) by xenon23.um.es (Postfix) with ESMTPSA id 05FAF338F; Wed, 21 Oct 2015 11:21:36 +0200 (CEST) From: Rafa Marin Lopez Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Date: Wed, 21 Oct 2015 11:21:36 +0200 Message-Id: To: 6tisch@ietf.org, ace@ietf.org, 6band@ietf.org Mime-Version: 1.0 (Mac OS X Mail 9.0 \(3094\)) X-Mailer: Apple Mail (2.3094) Archived-At: Cc: Dan Garcia , Rafa Marin Lopez Subject: [Ace] New update of EAP over CoAP X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 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, 21 Oct 2015 09:21:41 -0000 Dear all: Please find the link to an updated version of the draft about EAP over = CoAP. https://tools.ietf.org/html/draft-marin-ace-wg-coap-eap-02 The changes we have added are the following:=20 - Change to the name of the derived keys and the derivation method. - Added some missing details to the exchange flow. - Added a section =E2=80=9COptimization Considerations=E2=80=9D = commenting the reduction on the URI of the authentication service and = the possibility of using the zero-length token.=20 Comments are welcome. Best Regards.=20 ------------------------------------------------------- Rafael Marin Lopez, PhD Dept. Information and Communications Engineering (DIIC) Faculty of Computer Science-University of Murcia 30100 Murcia - Spain Telf: +34868888501 Fax: +34868884151 e-mail: rafa@um.es ------------------------------------------------------- From nobody Wed Oct 21 10:15:52 2015 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 7674B1B29DE; Wed, 21 Oct 2015 10:15:51 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Spencer Dawkins" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.6.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151021171551.26016.74086.idtracker@ietfa.amsl.com> Date: Wed, 21 Oct 2015 10:15:51 -0700 Archived-At: Cc: Hannes.Tschofenig@gmx.net, ace-chairs@ietf.org, ace@ietf.org, draft-ietf-ace-usecases@ietf.org Subject: [Ace] Spencer Dawkins' Yes on draft-ietf-ace-usecases-09: (with COMMENT) X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Oct 2015 17:15:51 -0000 Spencer Dawkins has entered the following ballot position for draft-ietf-ace-usecases-09: Yes When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-ace-usecases/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- This draft seems especially worth the effort of publishing a use case draft as an RFC. I learned a lot while reviewing it. The security considerations section seemed unusually valuable for a use case draft. Do the title and abstract call enough attention to that? The section title "2.1.1. Bananas for Munich" would also be a great name for a rock band ... :-) From nobody Wed Oct 21 11:40:24 2015 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9A231A8A8E; Wed, 21 Oct 2015 11:40:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ebglHfejg6GT; Wed, 21 Oct 2015 11:40:20 -0700 (PDT) Received: from mail-wi0-x235.google.com (mail-wi0-x235.google.com [IPv6:2a00:1450:400c:c05::235]) (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 75E4F1A8A8C; Wed, 21 Oct 2015 11:40:20 -0700 (PDT) Received: by wikq8 with SMTP id q8so106908910wik.1; Wed, 21 Oct 2015 11:40:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=tj7h4XFORI4V0yeBXHcRaBMQcufE2Ii2o1Dez+tE/g0=; b=KTmirN453/cObM19ynim53xS9JsINMM8MS+oVLpewB3w+gpdGSSgwXuLxz0VdCNART jV6pOxHxwGJQEXCDanQOVM0FOmclmwy04RlRMzkOnH2HiOEuWbJqU0ZSJwOBtEL62CCW ZMJncDrmW1LhgxRrr9bMT+qzteVLdkoMutW+378X0b3oDACZLywV71SHvMT4ALqS30CC bnqw1JgityOQIoc3Tk4rV4pflrPBijgg57Podz3jI/3mkZpN2Gad4x33FZn71+Iwtxlm AmM3mhoD0ly4pRccJQgyPFQaXuynmORhGwvI9kp5jkL+Sc9kCyDDkfDmG7KH/qbl/CkF 4TVQ== MIME-Version: 1.0 X-Received: by 10.195.11.72 with SMTP id eg8mr14087257wjd.14.1445452819032; Wed, 21 Oct 2015 11:40:19 -0700 (PDT) Received: by 10.28.214.213 with HTTP; Wed, 21 Oct 2015 11:40:18 -0700 (PDT) In-Reply-To: References: <20151021182333.7911.40602.idtracker@ietfa.amsl.com> Date: Wed, 21 Oct 2015 14:40:18 -0400 Message-ID: From: Kathleen Moriarty To: Ben Campbell Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: ace-chairs@ietf.org, Hannes Tschofenig , draft-ietf-ace-usecases@ietf.org, The IESG , "ace@ietf.org" Subject: Re: [Ace] Ben Campbell's Yes on draft-ietf-ace-usecases-09: (with COMMENT) X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 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, 21 Oct 2015 18:40:22 -0000 On Wed, Oct 21, 2015 at 2:36 PM, Ben Campbell wrote: > On 21 Oct 2015, at 13:34, Kathleen Moriarty wrote: > >>> - 2.7: An informational reference for stuxnet might be helpful. >> >> >> >> Agreed, this would be helpful for some readers. Can you queue up the >> addition so we have a version ready to go with the changes needed from >> reviews? > > > Hi, > > Does the "you" in that sentence refer to the authors, or to me? (perhaps to > propose a reference?) Oops, the you refers to the authors :-) I'd like them to have a version ready to post with changes so I can quickly approve this assuming no hard to resolve discussions arise. Thanks, Kathleen > > Ben. -- Best regards, Kathleen From nobody Wed Oct 21 11:42:11 2015 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FE3B1A8ABF; Wed, 21 Oct 2015 11:42:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, SPF_PASS=-0.001] autolearn=unavailable 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 dKHuSWG6uhsn; Wed, 21 Oct 2015 11:42:09 -0700 (PDT) Received: from mail-wi0-x22a.google.com (mail-wi0-x22a.google.com [IPv6:2a00:1450:400c:c05::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 36C891A8A1C; Wed, 21 Oct 2015 11:34:08 -0700 (PDT) Received: by wicll6 with SMTP id ll6so103775669wic.0; Wed, 21 Oct 2015 11:34:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=hTGBSRFKSfVUnrtAXHIMheWMMEtBst7FggpJM9CEEwE=; b=On2sp8LUmqTkzJTe4lYjt9NQNL1S1wt5VIoykrh07mA6hHL6UkCu+lPrXOJuxdqOWm sZtbfYun9O1YMPLJ1GrNU+iTMgAmbxGhkRwj94pYOpOAj6E40F1Zdm6U2/hK5soql3P5 yW/tv1EXyMMH7miXjBSgsF+6VOGtgqv2PjzqkWm1OyqTxatUd1M0NTn+IZPMHtCBebiy OmTg0Bc3cs+Y+M9aMuaokcdAhFZXN7gyNjjK66jBgGVh9u0Wp9UXPcv1jdnHbUVnBcdx J9ngVbIOnpRO+Fb36X8XQdgUl5YfpUzIZa1np0DvOctA4iIU6CSj+XGeACLmlOAbF3wd XQDQ== MIME-Version: 1.0 X-Received: by 10.194.191.161 with SMTP id gz1mr13874472wjc.0.1445452446758; Wed, 21 Oct 2015 11:34:06 -0700 (PDT) Received: by 10.28.214.213 with HTTP; Wed, 21 Oct 2015 11:34:06 -0700 (PDT) In-Reply-To: <20151021182333.7911.40602.idtracker@ietfa.amsl.com> References: <20151021182333.7911.40602.idtracker@ietfa.amsl.com> Date: Wed, 21 Oct 2015 14:34:06 -0400 Message-ID: From: Kathleen Moriarty To: Ben Campbell Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: ace-chairs@ietf.org, Hannes Tschofenig , draft-ietf-ace-usecases@ietf.org, The IESG , "ace@ietf.org" Subject: Re: [Ace] Ben Campbell's Yes on draft-ietf-ace-usecases-09: (with COMMENT) X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 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, 21 Oct 2015 18:42:10 -0000 Hi Ben, On Wed, Oct 21, 2015 at 2:23 PM, Ben Campbell wrote: > Ben Campbell has entered the following ballot position for > draft-ietf-ace-usecases-09: Yes > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-ace-usecases/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > While I'm not ordinarily a big fan of publishing use cases as RFCs, I > think this one has value. > > Otherwise, I have only a few minor comments: > > -Please expand ACE in the title, abstract, and body. > > - 2.6.1: Is it reasonable to expect wearable devices to have what sound > like multi-user-profile capabilities? Funny you should ask, I pushed on this in my review as well. Apparently, it is reasonable and coming out with a particular vendor's product. I also pushed on the functionality to see if it was reasonable, but apparently my running watch isn't as fancy as some of the options being worked on. > > - 2.7: An informational reference for stuxnet might be helpful. Agreed, this would be helpful for some readers. Can you queue up the addition so we have a version ready to go with the changes needed from reviews? Thank you, Kathleen > > -- Best regards, Kathleen From nobody Wed Oct 21 21:45:01 2015 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5827B1AD0D1 for ; Wed, 21 Oct 2015 21:45:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.702 X-Spam-Level: X-Spam-Status: No, score=0.702 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2FAWhoucIF5F for ; Wed, 21 Oct 2015 21:44:59 -0700 (PDT) Received: from out4133-114.mail.aliyun.com (out4133-114.mail.aliyun.com [42.120.133.114]) by ietfa.amsl.com (Postfix) with ESMTP id C2B391AD0C9 for ; Wed, 21 Oct 2015 21:44:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alibaba-inc.com; s=default; t=1445489097; h=Date:Subject:From:To:Message-ID:Mime-version:Content-type; bh=3jvFLBglNu5ksscBR/G3MJ4S/+F/pYtjWZRVMekj8ns=; b=MDzRT9tyPF1H6cIet7OhDZ+ORhrXczyeMSuZ5QM7CYQljyjoJ325bg8aZbEQte+GNw7Xd6AzYLag68o12ts53v2BM/SzWfmE9u1EHH3WKiWYxL4R9ZUO2ShgcMkW+49CUljps59XGJJVwWPIlHpSuZXkYXvRx3GfmRKIdH0qcf0= X-Alimail-AntiSpam: AC=PASS; BC=-1|-1; BR=01201311R171e4; FP=0|-1|-1|-1|0|-1|-1|-1; HT=e02c03283; MF=kepeng.lkp@alibaba-inc.com; NM=1; PH=DS; RN=1; SR=0; Received: from 10.1.152.166(mailfrom:kepeng.lkp@alibaba-inc.com ip:42.120.74.161) by smtp.aliyun-inc.com(127.0.0.1); Thu, 22 Oct 2015 12:44:55 +0800 User-Agent: Microsoft-MacOutlook/14.4.8.150116 Date: Thu, 22 Oct 2015 12:44:52 +0800 From: "Kepeng Li" To: "Ace@ietf.org" Message-ID: Thread-Topic: Call for Presentations for IETF94 Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3528362695_7887760" Archived-At: Subject: [Ace] Call for Presentations for IETF94 X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Oct 2015 04:45:00 -0000 > ʼʹ MIME ʽʼĶʶ ˸ʽˣ޷ʶʼķֲ򲿷ݡ --B_3528362695_7887760 Content-type: text/plain; charset="GB2312" Content-transfer-encoding: quoted-printable Hi everyone, So far, the chairs have had two requests for presentations at the ACE meeting of IETF94, which we will be accommodating along with discussion on the current draft progress. We=A1=AFre putting the agenda together now, and we would like to know if anyone else has a topic that they=A1=AFd like to present and discuss at the upcoming face to face. Kepeng & Hannes --B_3528362695_7887760 Content-type: text/html; charset="GB2312" Content-transfer-encoding: quoted-printable
= Hi everyone,

So far, the chairs have had two requests for presentations a= t the ACE meeting of IETF94, which we will be accommodating along with discu= ssion on the current draft progress. 

We’re putting the agenda= together now, and we would like to know if anyone else has a topic that the= y’d like to present and discuss at the upcoming face to face.

Kepen= g & Hannes
--B_3528362695_7887760-- From nobody Thu Oct 22 01:28:15 2015 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF88C1A000F for ; Thu, 22 Oct 2015 01:28:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.55 X-Spam-Level: X-Spam-Status: No, score=-1.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 418mYTY_BKBe for ; Thu, 22 Oct 2015 01:28:13 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE5591A000D for ; Thu, 22 Oct 2015 01:28:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [134.102.201.11]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id t9M8S9Tj029668 for ; Thu, 22 Oct 2015 10:28:09 +0200 (CEST) Received: from [IPv6:2001:638:708:30da:1065:2ebf:dbae:976c] (unknown [IPv6:2001:638:708:30da:1065:2ebf:dbae:976c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3nhMJn25JqzDv7v for ; Thu, 22 Oct 2015 10:28:09 +0200 (CEST) From: Stefanie Gerdes X-Enigmail-Draft-Status: N1110 To: "Ace@ietf.org" Message-ID: <56289E19.8090308@tzi.de> Date: Thu, 22 Oct 2015 10:28:09 +0200 User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Subject: [Ace] General Solution Framework for ACE X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Oct 2015 08:28:14 -0000 Hi, We submitted the ACE Solutions draft [1] that presents a general solution framework for the Privacy-Enhanced Tokens [2] and DCAF [3]. We updated DCAF accordingly. The new version also addresses Renzo's comments and contains more explanatory text how DCAF payloads can be transferred using COSE. More details about how DCAF works with object security can be found in the new DCAF-COSE draft [4]. Moreover, we submitted the Server-Initiated Ticket Request (SITR) draft [5] that explains how a (possibly constrained) server can request a ticket for a (possibly constrained) client that represents the mutual authentication and authorization of the Client Authorization Manager and the Server Authorization Manager. Comments are very welcome. Best regards, Steffi [1] https://tools.ietf.org/html/draft-cuellar-ace-solutions-00 [2] https://tools.ietf.org/id/draft-cuellar-ace-pat-priv-enhanced-authz-tokens-01.txt [3] https://tools.ietf.org/html/draft-gerdes-ace-dcaf-authorize-04 [4] https://tools.ietf.org/html/draft-bergmann-ace-dcaf-cose-00 [5] https://tools.ietf.org/id/draft-gerdes-ace-dcaf-sitr-00.txt -- Stefanie Gerdes Tel: +49 421 218 63906 TZI Universität Bremen E-Mail: gerdes@tzi.de Bibliothekstr. 1, MZH 5150 28359 Bremen, Germany From nobody Thu Oct 22 01:34:13 2015 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A2A11AC3FE for ; Thu, 22 Oct 2015 01:34:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.55 X-Spam-Level: X-Spam-Status: No, score=-1.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IQ-4WSvN2Irf for ; Thu, 22 Oct 2015 01:34:10 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E0251A8945 for ; Thu, 22 Oct 2015 01:34:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::b]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id t9M8Y1AM015792; Thu, 22 Oct 2015 10:34:02 +0200 (CEST) Received: from [IPv6:2001:638:708:30da:1065:2ebf:dbae:976c] (unknown [IPv6:2001:638:708:30da:1065:2ebf:dbae:976c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3nhMRY6QPQzDv8G; Thu, 22 Oct 2015 10:34:01 +0200 (CEST) To: Kepeng Li , "Ace@ietf.org" References: From: Stefanie Gerdes X-Enigmail-Draft-Status: N1110 Message-ID: <56289F79.30506@tzi.de> Date: Thu, 22 Oct 2015 10:34:01 +0200 User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Ace] Call for Presentations for IETF94 X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Oct 2015 08:34:11 -0000 Hi Kepeng, We would like to request a slot to present the DCAF-related Drafts [1][2][3]. Thanks, Steffi [1] https://tools.ietf.org/html/draft-bergmann-ace-dcaf-cose-00 [2] https://tools.ietf.org/id/draft-gerdes-ace-dcaf-sitr-00.txt [3] https://tools.ietf.org/html/draft-gerdes-ace-dcaf-authorize-04 From nobody Thu Oct 22 06:29:04 2015 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 0357D1A88DF; Thu, 22 Oct 2015 06:29:04 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Stephen Farrell" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.6.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151022132903.23826.2689.idtracker@ietfa.amsl.com> Date: Thu, 22 Oct 2015 06:29:03 -0700 Archived-At: Cc: Hannes.Tschofenig@gmx.net, ace-chairs@ietf.org, ace@ietf.org, draft-ietf-ace-usecases@ietf.org Subject: [Ace] Stephen Farrell's Yes on draft-ietf-ace-usecases-09: (with COMMENT) X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Oct 2015 13:29:04 -0000 Stephen Farrell has entered the following ballot position for draft-ietf-ace-usecases-09: Yes When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-ace-usecases/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Excellent and well written document, thanks. I think there are five things you could usefully add, see below. That said, I agree that this cannot and should not try to be fully complete so I won't argue (much:-) if you prefer to omit these. We/you can figure out what if any text to add I'm sure, but I'm happy to chat about that. 1. Software update is really needed and often missing and usually hard. There's at least a need to authenticate and authorize new firmware, when there is any update. That may not be the same as authorizing a new config. 2. Alice buys a new device, and would like to know if it is calling home or what it is doing before she configures it, or perhaps before she accepts it in her network. Even if she accepts it, she may want to be able to monitor the data it is sending "home" e.g. to ensure her TV is not sending data when she inserts a USB stick, if that is undesired. 3. Device fingerprinting is a threat that ought be considered by solution developers, especially if there is no reliable software update. Probably the best to be done is to try to make it hard for unauthorized parties to fingerprint a device, but that's also hard. 4. Commercial Devices will be end-of-lifed by vendors, and yet Alice still needs to be able to use, and perhaos to update, the device. That calls for some kind of authorization handover which is not quite the same as a change of ownership. 5. Penetration testing will happen and devices should not barf even then. Maybe that's a security consideration worth a mention. See also the secdir review. [1] It'd be good to see a response to that. [1] https://www.ietf.org/mail-archive/web/secdir/current/msg06101.html From nobody Thu Oct 22 06:59:37 2015 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF8181ACDA6; Thu, 22 Oct 2015 06:59:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.55 X-Spam-Level: X-Spam-Status: No, score=-1.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3fIJ5QfRrqMY; Thu, 22 Oct 2015 06:59:30 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 724621ACDB0; Thu, 22 Oct 2015 06:59:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [134.102.201.11]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id t9MDxJdG004719; Thu, 22 Oct 2015 15:59:19 +0200 (CEST) Received: from [192.168.217.118] (p5DC7F6AE.dip0.t-ipconnect.de [93.199.246.174]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3nhVfv4JxgzHxGp; Thu, 22 Oct 2015 15:59:19 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\)) From: Carsten Bormann In-Reply-To: <20151022132903.23826.2689.idtracker@ietfa.amsl.com> Date: Thu, 22 Oct 2015 15:59:18 +0200 X-Mao-Original-Outgoing-Id: 467215124.590428-2fe0e48fd64f0b753c2b5e230dd602b1 Content-Transfer-Encoding: quoted-printable Message-Id: <9727B59F-CD2D-4A32-8F7B-F5C89EE2E388@tzi.org> References: <20151022132903.23826.2689.idtracker@ietfa.amsl.com> To: Stephen Farrell X-Mailer: Apple Mail (2.3096.5) Archived-At: Cc: ace-chairs@ietf.org, The IESG , ace@ietf.org, Carsten Bormann , Hannes.Tschofenig@gmx.net, draft-ietf-ace-usecases@ietf.org Subject: Re: [Ace] Stephen Farrell's Yes on draft-ietf-ace-usecases-09: (with COMMENT) X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Oct 2015 13:59:33 -0000 Hi Stephen, I agree with all of these. However, they are not specific to ACE; they are general security = considerations for constrained devices (or IoT things in general). I think what we need to do is collect the security considerations we = have in, say, RFC 7252, RFC 7228, etc., combine this with the points = below and a few more that came up, and generate a referenceable = =E2=80=9CSecurity Considerations for Constrained Devices on the = Internet=E2=80=9D document. I=E2=80=99d love to reference that from any = document I=E2=80=99m working on. Gr=C3=BC=C3=9Fe, Carsten > On 22 Oct 2015, at 15:29, Stephen Farrell = wrote: >=20 > Stephen Farrell has entered the following ballot position for > draft-ietf-ace-usecases-09: Yes >=20 > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut = this > introductory paragraph, however.) >=20 >=20 > Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-ace-usecases/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 >=20 > Excellent and well written document, thanks. I think there are > five things you could usefully add, see below. That said, I > agree that this cannot and should not try to be fully complete > so I won't argue (much:-) if you prefer to omit these. We/you > can figure out what if any text to add I'm sure, but I'm happy > to chat about that. >=20 > 1. Software update is really needed and often missing and > usually hard. There's at least a need to authenticate and > authorize new firmware, when there is any update. That may not > be the same as authorizing a new config. >=20 > 2. Alice buys a new device, and would like to know if it is > calling home or what it is doing before she configures it, or > perhaps before she accepts it in her network. Even if she > accepts it, she may want to be able to monitor the data it > is sending "home" e.g. to ensure her TV is not sending=20 > data when she inserts a USB stick, if that is undesired. >=20 > 3. Device fingerprinting is a threat that ought be considered > by solution developers, especially if there is no reliable > software update. Probably the best to be done is to try to > make it hard for unauthorized parties to fingerprint a device, > but that's also hard. >=20 > 4. Commercial Devices will be end-of-lifed by vendors, and yet > Alice still needs to be able to use, and perhaos to update, > the device. That calls for some kind of authorization handover > which is not quite the same as a change of ownership. >=20 > 5. Penetration testing will happen and devices should not barf > even then. Maybe that's a security consideration worth a > mention. >=20 > See also the secdir review. [1] It'd be good to see a=20 > response to that. >=20 > [1] = https://www.ietf.org/mail-archive/web/secdir/current/msg06101.html >=20 >=20 > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace >=20 From nobody Thu Oct 22 07:06:33 2015 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B17F01ACE78; Thu, 22 Oct 2015 07:06:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 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_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XJzD_KeA3G48; Thu, 22 Oct 2015 07:06:24 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 11D421ACE70; Thu, 22 Oct 2015 07:06:24 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 3C796BE35; Thu, 22 Oct 2015 15:06:22 +0100 (IST) Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y7sH1WKm8yvZ; Thu, 22 Oct 2015 15:06:22 +0100 (IST) Received: from [134.226.36.93] (bilbo.dsg.cs.tcd.ie [134.226.36.93]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 33EF5BE32; Thu, 22 Oct 2015 15:06:21 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1445522782; bh=2B7Gx0Z87Wp3DyGFoF+ryLVezsshz4TKDw5bc1ThzXE=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=nnSBQr7wjV/17IaB7w9SbWZuxPtxm4NNiyROb3DVKQG4nMAgQllRJZ+EQB9azhKKw lgjm5ijyUDgvm3hio/wp/1E51Puwmj7FLdF7wDdbXP+174bDNhAgcQPMIBN6zLn4zh 9xUrT6Lzf9nnSN6Otu6Xi7ew6an6tlgM84f4t5Uc= To: Carsten Bormann References: <20151022132903.23826.2689.idtracker@ietfa.amsl.com> <9727B59F-CD2D-4A32-8F7B-F5C89EE2E388@tzi.org> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <5628ED5D.7070508@cs.tcd.ie> Date: Thu, 22 Oct 2015 15:06:21 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <9727B59F-CD2D-4A32-8F7B-F5C89EE2E388@tzi.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: Hannes.Tschofenig@gmx.net, ace-chairs@ietf.org, draft-ietf-ace-usecases@ietf.org, The IESG , ace@ietf.org Subject: Re: [Ace] Stephen Farrell's Yes on draft-ietf-ace-usecases-09: (with COMMENT) X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Oct 2015 14:06:29 -0000 On 22/10/15 14:59, Carsten Bormann wrote: > Hi Stephen, > > I agree with all of these. However, they are not specific to ACE; > they are general security considerations for constrained devices (or > IoT things in general). I think what we need to do is collect the > security considerations we have in, say, RFC 7252, RFC 7228, etc., > combine this with the points below and a few more that came up, and > generate a referenceable “Security Considerations for Constrained > Devices on the Internet” document. I’d love to reference that from > any document I’m working on. Such a document would indeed be a fine thing. Do we have folks who are willing and able already? That said, I do think there may be ace-specific use-cases to be derived from (some of) the points raised, e.g. handling end of life is maybe not the same as a handover after the vendor is off the stage. S. > > Grüße, Carsten > > >> On 22 Oct 2015, at 15:29, Stephen Farrell >> wrote: >> >> Stephen Farrell has entered the following ballot position for >> draft-ietf-ace-usecases-09: Yes >> >> When responding, please keep the subject line intact and reply to >> all email addresses included in the To and CC lines. (Feel free to >> cut this introductory paragraph, however.) >> >> >> Please refer to >> https://www.ietf.org/iesg/statement/discuss-criteria.html for more >> information about IESG DISCUSS and COMMENT positions. >> >> >> The document, along with other ballot positions, can be found >> here: https://datatracker.ietf.org/doc/draft-ietf-ace-usecases/ >> >> >> >> ---------------------------------------------------------------------- >> >> COMMENT: >> ---------------------------------------------------------------------- >> >> >> >> Excellent and well written document, thanks. I think there are >> five things you could usefully add, see below. That said, I agree >> that this cannot and should not try to be fully complete so I won't >> argue (much:-) if you prefer to omit these. We/you can figure out >> what if any text to add I'm sure, but I'm happy to chat about >> that. >> >> 1. Software update is really needed and often missing and usually >> hard. There's at least a need to authenticate and authorize new >> firmware, when there is any update. That may not be the same as >> authorizing a new config. >> >> 2. Alice buys a new device, and would like to know if it is calling >> home or what it is doing before she configures it, or perhaps >> before she accepts it in her network. Even if she accepts it, she >> may want to be able to monitor the data it is sending "home" e.g. >> to ensure her TV is not sending data when she inserts a USB stick, >> if that is undesired. >> >> 3. Device fingerprinting is a threat that ought be considered by >> solution developers, especially if there is no reliable software >> update. Probably the best to be done is to try to make it hard for >> unauthorized parties to fingerprint a device, but that's also >> hard. >> >> 4. Commercial Devices will be end-of-lifed by vendors, and yet >> Alice still needs to be able to use, and perhaos to update, the >> device. That calls for some kind of authorization handover which is >> not quite the same as a change of ownership. >> >> 5. Penetration testing will happen and devices should not barf even >> then. Maybe that's a security consideration worth a mention. >> >> See also the secdir review. [1] It'd be good to see a response to >> that. >> >> [1] >> https://www.ietf.org/mail-archive/web/secdir/current/msg06101.html >> >> >> _______________________________________________ Ace mailing list >> Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace >> > From nobody Thu Oct 22 12:53:46 2015 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C0421B3EA4 for ; Thu, 22 Oct 2015 12:53:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.701 X-Spam-Level: X-Spam-Status: No, score=-0.701 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dncz6IIfK1bg for ; Thu, 22 Oct 2015 12:53:44 -0700 (PDT) Received: from smtp1.pacifier.net (smtp1.pacifier.net [64.255.237.171]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 38D851B3EA3 for ; Thu, 22 Oct 2015 12:53:44 -0700 (PDT) Received: from hebrews (winery.augustcellars.com [206.212.239.129]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp1.pacifier.net (Postfix) with ESMTPSA id 6D33A2CA2A for ; Thu, 22 Oct 2015 12:53:43 -0700 (PDT) From: "Jim Schaad" To: Date: Thu, 22 Oct 2015 12:51:01 -0700 Message-ID: <07d101d10d02$fb099560$f11cc020$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 15.0 Content-Language: en-us Thread-Index: AdEM/FFF01Gp/iL+R+esO1BkVWE8OA== Archived-At: Subject: [Ace] More replay questions X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Oct 2015 19:53:45 -0000 I have a couple of more questions about replay 1. Is there any reason to think that relay protection is going to be wanted without the object security wrapper? I note that DTLS does provide some replay protection but not complete replay protection. It allows for the ability to do the "last n messages" check that you don't do a replay for one of those messages (or out of zone messages) but it does not allow for a high water mark style of replay protection (don't replay a messages sent before the last one I processed). How this is not supported can be seen from the following sequence of events: a) C sends message M1 b) C sends message M2 c) Proxy receives M2 and re-sends as M_p1 d) Proxy receives M1 and re-sends as M_p2 e) Server receives message M_p1 and processes f) Server receives message M_p2 and processes The proxy reversed the order of the messages, but sense it uses a different counter for the sequence number than what the client does the server cannot detect that M1 arrived after M2 and thus should not be processed. 2. Do you expect any intermediaries to help and do the same replay protection that you are getting at the endpoint? For example, would you expect the proxy in the previous example to potentially not re-send message M1 because it does not make the high water replay conditions? 3. Do you expect to apply replay protection before or after doing the cryptographic integrity checks? My expectation is that one should be doing this BEFORE doing any cryptographic operations. This says that putting it in the options might be better if it can be accessed faster. Would also say that making it an unprotected attribute is better as there would be one less decoding step required to use it. 4. Is there ever any reason to think that replay protection items might need to be encrypted? I have no idea if there would ever be any leakage of information here. I kind of doubt it. Jim From nobody Thu Oct 22 14:47:35 2015 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90BD51A8981; Thu, 22 Oct 2015 14:47:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GkX6dMxbOSEA; Thu, 22 Oct 2015 14:47:29 -0700 (PDT) Received: from emea01-db3-obe.outbound.protection.outlook.com (mail-db3on0778.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe04::778]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2E7911A1B15; Thu, 22 Oct 2015 14:47:29 -0700 (PDT) Received: from AM3PR04CA0018.eurprd04.prod.outlook.com (10.242.16.18) by AMSPR04MB209.eurprd04.prod.outlook.com (10.242.84.15) with Microsoft SMTP Server (TLS) id 15.1.300.14; Thu, 22 Oct 2015 21:47:10 +0000 Received: from DB3FFO11FD037.protection.gbl (2a01:111:f400:7e04::102) by AM3PR04CA0018.outlook.office365.com (2a01:111:e400:8814::18) with Microsoft SMTP Server (TLS) id 15.1.306.13 via Frontend Transport; Thu, 22 Oct 2015 21:47:09 +0000 Authentication-Results: spf=none (sender IP is 23.103.247.180) smtp.mailfrom=philips.com; cs.tcd.ie; dkim=none (message not signed) header.d=none;cs.tcd.ie; dmarc=none action=none header.from=philips.com; Received-SPF: None (protection.outlook.com: philips.com does not designate permitted sender hosts) Received: from 011-smtp-out.Philips.com (23.103.247.180) by DB3FFO11FD037.mail.protection.outlook.com (10.47.217.68) with Microsoft SMTP Server (TLS) id 15.1.306.13 via Frontend Transport; Thu, 22 Oct 2015 21:47:09 +0000 Received: from DB5PR9001MB0167.MGDPHG.emi.philips.com (141.251.190.211) by DB5PR9001MB0166.MGDPHG.emi.philips.com (141.251.190.210) with Microsoft SMTP Server (TLS) id 15.1.293.16; Thu, 22 Oct 2015 21:47:04 +0000 Received: from DB5PR9001MB0167.MGDPHG.emi.philips.com ([141.251.190.211]) by DB5PR9001MB0167.MGDPHG.emi.philips.com ([141.251.190.211]) with mapi id 15.01.0293.007; Thu, 22 Oct 2015 21:47:04 +0000 From: "Kumar, Sandeep" To: Stephen Farrell , Carsten Bormann Thread-Topic: [Ace] Stephen Farrell's Yes on draft-ietf-ace-usecases-09: (with COMMENT) Thread-Index: AQHRDM2hj5ReQhaYXUij9SmMGT4SqZ53ihQAgAAB+ICAAH9fAA== Date: Thu, 22 Oct 2015 21:47:04 +0000 Message-ID: <13a9cf15d35c4889ada98e789680e047@DB5PR9001MB0167.MGDPHG.emi.philips.com> References: <20151022132903.23826.2689.idtracker@ietfa.amsl.com> <9727B59F-CD2D-4A32-8F7B-F5C89EE2E388@tzi.org> <5628ED5D.7070508@cs.tcd.ie> In-Reply-To: <5628ED5D.7070508@cs.tcd.ie> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [85.150.192.178] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Microsoft-Exchange-Diagnostics: 1; DB3FFO11FD037; 1:SX2aAzP+oEVLdogbGjkx+Uu9vZPJDpP8jcbYUXS81qzkUGX8tv+H3uVK8d1Xix9oILbUol8/fapGQHT8nm4OHKsENziKJRkXcVOlxHu+pNUmJXkorcb7aa4okOW8apmlRomplOznnILxZU0AdBqRIFMJVe/m3b1SWBUfghDlkR4cvd1zLqyH8D7aX9Z++190fKoB+8JE6Cqa2aGoAOlHHp2UbR314soVykY9cgHDj4lVrUILqUix9dguPkfYlMJccODSPWnrLJKu+DWxFfZ4IwZiL9wvphIc+aRMQ6nn2P4HjdSYBjFo8jeiNxCqQ6hMmPIWJYWaF3nWa/e0PZAg5n4WZVR24LGIjbP64HZe6x4= X-Forefront-Antispam-Report: CIP:23.103.247.180; CTRY:; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(2980300002)(428002)(479174004)(374574003)(85714005)(55904004)(199003)(377454003)(24454002)(189002)(13464003)(52044002)(24736003)(47776003)(97736004)(86362001)(87936001)(33646002)(5003600100002)(69596002)(19580405001)(50466002)(19580395003)(5001960100002)(189998001)(16796002)(92566002)(81156007)(54356999)(5001770100001)(76176999)(101416001)(50986999)(5008740100001)(6806005)(5004730100002)(2950100001)(102836002)(11100500001)(15975445007)(106116001)(2900100001)(105586002)(230783001)(10400500002)(106466001)(108616004)(23676002)(66066001)(5007970100001); DIR:OUT; SFP:1102; SCL:1; SRVR:AMSPR04MB209; H:011-smtp-out.Philips.com; FPR:; SPF:None; PTR:InfoDomainNonexistent; A:1; MX:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; AMSPR04MB209; 2:8f2NldDsTMFlrmco1ohcGW7aj+Ipn3v/lVXswtA/XfpF0m6H9NKcMfiqd7k5GSVFDrTUevhwdOuq4F0c8VXWw7pqdETsqtnCTF5Ehx2g3AjIwDlhDx4YSnsODT+0aLAINQvv0S9xiXzRpNy6brVy/j63ngK64Jek1ScwW6wsagE=; 3:ZJRTdijjFDqJ4BrTgE2hs9MnhTh0v4Ei6Btn4Z29a2PSyU1fZbRjwJtqe90+Uq+/OckK1unLjfk6VbWhJZYDYw1o3hdwLrwRV6FaV8zGUDEzma1WnBz1+P1gn25kBlI2T4Fxl800i67tObpKr8UALgxQw/UI0b+Fo1S1r2HUthrNrCl0sbX+frI9jR0BHJRfX7ek5Wf+MQPUxkpb+ehol72vtBY4y52yzu9Pc1h52AY=; 25:AjZNHzBI4wOg2gmUpjg9AEbkzi4qXZejRUP6zp6PMmiNIMyNZCRVKFNiY1RLqh8SHFuKp1jRrVtpLRdWGzQ6sMmyrFSFVf+LlhfgZmo06OBuydlYb97osHHN3qtcqBvE6cDWwlUMRzDuf4ho8+CwwjDhFZo+gSoBNtSN79WQC5o6CY+55K4NGADZ9MauzrytLBTktAjCYrU0SAh7NbDGQpP8x4NExREY7xYdX7lsJhY6/DyH+D/DFDvHkG1ncbUBYnLxymLhTZY/t8KrAe7m8Q== X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:AMSPR04MB209; X-Microsoft-Exchange-Diagnostics: 1; AMSPR04MB209; 20:vIWb6zllDqYT8ZQ5EwORHP79U43fD6ODwNSSngoluHkvhTxew7mbTMZvCpbTO78Lmcvrn2RPl6jQuVf4QyBGaWls0bUfh3Yt6jePWaPbpcxBEz1PAf6D/aEgJoPROIzPkTQluc1p8UMSp3l2kb4lgX4NQokNpVSQ8vTY6joptBBVoZ+Q3C1AJc0Za9xzBZB/eSR9QmBoc0iq0Hj27WNlIrDjvePsNTM1RJ8Er7ySCStiiuWWqa/GDo+zOWmUARH6Gcdob2sMpnkOqjONMawfeIhQf3NfrJxhZ4iumOHgp/7LcQXgJoJm4mqfCj/Qrls8VlhbvH0JMwjqJ6GnupXimXdUQt3UgDFnGUON3IIdMkfiQwo2imUIfzrVg/mFJ/wVoGmRVhB8J6WywBqTdBhgv209DjgLb2vurq4COKcl4j8V8MLXSUMF8/u55+/fqIw/f4eFP6CRrbr4nzd8jKVQfXvizC9y/9oocUBWFLSHKU4XVf18MATpE986SODt3d4r; 4:D5t/ScaA0fWW/1lrRZlwwrKpjsQUtESV/JjEjHSKhadXHNfzpil+ImGp7aEo3HL8+7D1+GZfdJJmUP0WTlCD9a+uzc5feFZTFPJt0Vm9xxw+oL+SbKoJWyIzh7fUsRA5/jzPiIFRB9xNQM62b+cjiMw3NHSyzTgTmeO+vd9s0hPEWgV/j2YqkPNT8AdwBzGVoofP4qOhZpTVhGkRj+pmtKplpnxW9bRDlvqySmM9rnnVIenweJk+LzhiPJ2ZWa7EJ2T1UIEAFFK0w08+Ppxzgk+m1Gz2wKxZxGzcYXeTJz+mIUUNU9aacXUO+9k1+jtUuuSm+aQCtt87/ZC/9nRHBS3K1p1O0uKBU69msJZo4b2iw8p8LDj99+QtE/hwxazc X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(32856632585715); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(520078)(3002001)(102215026); SRVR:AMSPR04MB209; BCL:0; PCL:0; RULEID:; SRVR:AMSPR04MB209; X-Forefront-PRVS: 0737B96801 X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtBTVNQUjA0TUIyMDk7MjM6QkM2bGIvMjlYSXZBWWMwZ1VCYzhQK3haUmsy?= =?utf-8?B?dFFFcFZxYnR1a01kRzNLUEJVNEJRUGx6K0g5eVBIWFJZbU5jY3BtZWg3bjNX?= =?utf-8?B?T3dDS1FMbHhoR2x5YXliVDdDaXloSjFGNTZ6VkRQQWRsSmpqM2krOEYrdW12?= =?utf-8?B?cWpHVDFyVVJOUEV3WUhhN1NNUTBnd1JyUEhhSWhWZjhKZGZpck9lSDdLN0pu?= =?utf-8?B?MjJ2d2tWRUIrYjF5Yjh4VHFQRGsrSFVkd1BONkZ4cGx5TVl6YW5PSjFPeTJC?= =?utf-8?B?SnR3dVZwMXAwWXFFaHpyd05WSVBJdmgxK2ZCUW94Zm5NK2ZZM3NkcUsrRENr?= =?utf-8?B?cnVtTFJVWUQ5ZXFUQzVZanRzQ093d2QrWnJHNjFzS3IrYmVyc2d0UUxwd24r?= =?utf-8?B?MHZFeWg3aUJvRUFTNjA2QXc1RVFlZlo5bkIwV3RHejA0SjlyRVVDTXZLM2NO?= =?utf-8?B?aXlYcWppV1Y0OFBYUUJPWDRjSWJGaDRSSWtyTFo3RG5RK1p4T1ZHbkw3a0Vu?= =?utf-8?B?R3prVUJDcVRldDUzRTZ4RWlRSGJFL3NFMzNVQWpLcUhwSVBhckZnd1ZVWWFs?= =?utf-8?B?QWhmUy9CVGVlcHRxTzFwMFVvbnorNjZudllOU1dpVDc3OHRycnY3NWFndzA2?= =?utf-8?B?ZGREcC9zRUtMcm1YR0g4TWZVbWVscEZpaGNZckJFVlhETWtNTlh0U0xTMjhv?= =?utf-8?B?aVVSaXBleFQ1ZlJYbWc5VWgvTHJnQVJicDlWVGtubE5sTThyWEFDdVFqWCtB?= =?utf-8?B?VVlZRG5ndXdmU0RJdU40bGs3aHhVa1h2allDcEFMTTJNaUpUZFhVK0xmRmFr?= =?utf-8?B?YSs5ZllNYUJZaTlmb3lMblQyNXFMa1NrOG05Ym1QUFo2VUUrOWQzQWk0cWM4?= =?utf-8?B?dHR5d0JJNWRwR0xiQVJaa01jRmE4Y3JsRVF4Vk1IQURrcmZINEUxK3BPck14?= =?utf-8?B?ODRiQXhKMGVETzlUdTVoVDlpQW5mMGFSSzRjdDBybk13WEJFRmdIcFA3RFJK?= =?utf-8?B?TzVYSCtscmRTcVIrSTI0R1hEUzBaeDZZZU5VT2g5R2l4VEg4dHFETUdrMHht?= =?utf-8?B?NVNhU3FYQ0wzT05FVk9ydng5ZzBXL0pLdkZxdHRENHRQTzRVMWx0ZHR3L1pM?= =?utf-8?B?bHF6MWp6YXVKcDJBT1JlbDE1WFlGcEdUWGhoamlvaWVuenhaQVFvSmVHem42?= =?utf-8?B?Y2M1M04zd2M5MDdPOSswVGFzeDRJZ0NmUnRKY2pJTm5xZ2IweTZYblpGa0tV?= =?utf-8?B?OXBmQ01Ea2dmU0huOWhNOGc5TXk2aGpxaExvNnozdk82Yk5tSGRyM1dsTjFJ?= =?utf-8?B?bmZEcVFtSFNocWgrZ25iL3AzU2hMbWNQR2puOWsxNHYyYXlyTmpmSUhFeSth?= =?utf-8?B?OFRyMHZRYThVeVM4SDdmNnh2Q3pvM1U5RjVsNUFZcWlPdFh2eCsxaTU2b2N4?= =?utf-8?B?SzdJZGE1MFVRam9Dc3ZpSDMwZG5Kclc1dkM3WU0vRGE3cFJVQTRGL2ZYK05q?= =?utf-8?B?ZWluQnlJOHlkamJqaDF3WWY3d0V0UGw5VFM3SVI2R1RvS1JwdWU5cFhtOTUv?= =?utf-8?B?ZDZvcWdlTE9MdjJFNjNpV0dJdjhoVkFJaDk1cGc5SDJ1dzVtblZhanhsMmpo?= =?utf-8?B?eXpLZllnd0dlS2pTUHRjYnBxejk0QllPZUtsS0toTFpZMUNtY3haTWtLSTlS?= =?utf-8?B?Zm9iZVJnYWJUNnNDQkw4cmJhd1ZkTnVSeUF0TWczWGJrS1FTaFdkODFVdXll?= =?utf-8?B?VVh2RnVBbkEyM2dkUWZpTmRQVEI0N3cyZFVGVENTL3NUUm5reVptbklHUmZj?= =?utf-8?B?V1dOallCcmRFZ1cxa3V1SUpPMFNXZEo3M0tjR0JUeWZlZz09?= X-Microsoft-Exchange-Diagnostics: 1; AMSPR04MB209; 5:cxKpILEo3AbvQHPC23GXakZcDRDVQeNYk46HaWUoME0NBvP/O3Nq4verstSE1H/CZ/L8yVHiJDs2KGpPyqOvb6DGLGyZ9ZuzxuQqDO9wHaFvTJkQXXqoHR2O4Ateuf0eks2VGshaFztYBmSWLU2tow==; 24:vL8/gzd1x0MHDHhbBrZynY82pLaZJn9Of94w6t9hPFvDCwPFUc9H1voYxsevQvSRE3ssV4VsLJ+4JkuSx23Y5Zknbq5hqXz+AT6wwfhrY40=; 20:PDxwO6epSKfV1W0CiOrGTUaZDremz9dqQUS7f7x742B7I4mBflOqLLcaqv4o9zzvxt4D9fGyUektLj8FKiYuUQ== SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: philips.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 22 Oct 2015 21:47:09.3579 (UTC) X-MS-Exchange-CrossTenant-Id: 1a407a2d-7675-4d17-8692-b3ac285306e4 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=1a407a2d-7675-4d17-8692-b3ac285306e4; Ip=[23.103.247.180]; Helo=[011-smtp-out.Philips.com] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: AMSPR04MB209 Archived-At: Cc: "Hannes.Tschofenig@gmx.net" , "ace-chairs@ietf.org" , "draft-ietf-ace-usecases@ietf.org" , The IESG , "ace@ietf.org" Subject: Re: [Ace] Stephen Farrell's Yes on draft-ietf-ace-usecases-09: (with COMMENT) X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Oct 2015 21:47:33 -0000 ZHJhZnQtZ2FyY2lhLWNvcmUtc2VjdXJpdHktMDYgd2FzIHN1Y2ggYW4gYXR0ZW1wdC4gTWF5YmUg YSBnb29kIHRpbWUgdG8gcmVzdXJyZWN0IGl0Lg0KDQpTYW5kZWVwDQoNCi0tLS0tT3JpZ2luYWwg TWVzc2FnZS0tLS0tDQpGcm9tOiBTdGVwaGVuIEZhcnJlbGwgW21haWx0bzpzdGVwaGVuLmZhcnJl bGxAY3MudGNkLmllXQ0KU2VudDogVGh1cnNkYXksIE9jdG9iZXIgMjIsIDIwMTUgNDowNiBQTQ0K VG86IENhcnN0ZW4gQm9ybWFubg0KQ2M6IGFjZS1jaGFpcnNAaWV0Zi5vcmc7IFRoZSBJRVNHOyBh Y2VAaWV0Zi5vcmc7IEhhbm5lcy5Uc2Nob2ZlbmlnQGdteC5uZXQ7IGRyYWZ0LWlldGYtYWNlLXVz ZWNhc2VzQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW0FjZV0gU3RlcGhlbiBGYXJyZWxsJ3MgWWVz IG9uIGRyYWZ0LWlldGYtYWNlLXVzZWNhc2VzLTA5OiAod2l0aCBDT01NRU5UKQ0KDQoNCg0KT24g MjIvMTAvMTUgMTQ6NTksIENhcnN0ZW4gQm9ybWFubiB3cm90ZToNCj4gSGkgU3RlcGhlbiwNCj4N Cj4gSSBhZ3JlZSB3aXRoIGFsbCBvZiB0aGVzZS4gSG93ZXZlciwgdGhleSBhcmUgbm90IHNwZWNp ZmljIHRvIEFDRTsgdGhleQ0KPiBhcmUgZ2VuZXJhbCBzZWN1cml0eSBjb25zaWRlcmF0aW9ucyBm b3IgY29uc3RyYWluZWQgZGV2aWNlcyAob3IgSW9UDQo+IHRoaW5ncyBpbiBnZW5lcmFsKS4gSSB0 aGluayB3aGF0IHdlIG5lZWQgdG8gZG8gaXMgY29sbGVjdCB0aGUgc2VjdXJpdHkNCj4gY29uc2lk ZXJhdGlvbnMgd2UgaGF2ZSBpbiwgc2F5LCBSRkMgNzI1MiwgUkZDIDcyMjgsIGV0Yy4sIGNvbWJp bmUgdGhpcw0KPiB3aXRoIHRoZSBwb2ludHMgYmVsb3cgYW5kIGEgZmV3IG1vcmUgdGhhdCBjYW1l IHVwLCBhbmQgZ2VuZXJhdGUgYQ0KPiByZWZlcmVuY2VhYmxlIOKAnFNlY3VyaXR5IENvbnNpZGVy YXRpb25zIGZvciBDb25zdHJhaW5lZCBEZXZpY2VzIG9uIHRoZQ0KPiBJbnRlcm5ldOKAnSBkb2N1 bWVudC4gIEnigJlkIGxvdmUgdG8gcmVmZXJlbmNlIHRoYXQgZnJvbSBhbnkgZG9jdW1lbnQgSeKA mW0NCj4gd29ya2luZyBvbi4NCg0KU3VjaCBhIGRvY3VtZW50IHdvdWxkIGluZGVlZCBiZSBhIGZp bmUgdGhpbmcuIERvIHdlIGhhdmUgZm9sa3Mgd2hvIGFyZSB3aWxsaW5nIGFuZCBhYmxlIGFscmVh ZHk/DQoNClRoYXQgc2FpZCwgSSBkbyB0aGluayB0aGVyZSBtYXkgYmUgYWNlLXNwZWNpZmljIHVz ZS1jYXNlcyB0byBiZSBkZXJpdmVkIGZyb20gKHNvbWUgb2YpIHRoZSBwb2ludHMgcmFpc2VkLCBl LmcuIGhhbmRsaW5nIGVuZCBvZiBsaWZlIGlzIG1heWJlIG5vdCB0aGUgc2FtZSBhcyBhIGhhbmRv dmVyIGFmdGVyIHRoZSB2ZW5kb3IgaXMgb2ZmIHRoZSBzdGFnZS4NCg0KUy4NCg0KPg0KPiBHcsO8 w59lLCBDYXJzdGVuDQo+DQo+DQo+PiBPbiAyMiBPY3QgMjAxNSwgYXQgMTU6MjksIFN0ZXBoZW4g RmFycmVsbCA8c3RlcGhlbi5mYXJyZWxsQGNzLnRjZC5pZT4NCj4+IHdyb3RlOg0KPj4NCj4+IFN0 ZXBoZW4gRmFycmVsbCBoYXMgZW50ZXJlZCB0aGUgZm9sbG93aW5nIGJhbGxvdCBwb3NpdGlvbiBm b3INCj4+IGRyYWZ0LWlldGYtYWNlLXVzZWNhc2VzLTA5OiBZZXMNCj4+DQo+PiBXaGVuIHJlc3Bv bmRpbmcsIHBsZWFzZSBrZWVwIHRoZSBzdWJqZWN0IGxpbmUgaW50YWN0IGFuZCByZXBseSB0byBh bGwNCj4+IGVtYWlsIGFkZHJlc3NlcyBpbmNsdWRlZCBpbiB0aGUgVG8gYW5kIENDIGxpbmVzLiAo RmVlbCBmcmVlIHRvIGN1dA0KPj4gdGhpcyBpbnRyb2R1Y3RvcnkgcGFyYWdyYXBoLCBob3dldmVy LikNCj4+DQo+Pg0KPj4gUGxlYXNlIHJlZmVyIHRvDQo+PiBodHRwczovL3d3dy5pZXRmLm9yZy9p ZXNnL3N0YXRlbWVudC9kaXNjdXNzLWNyaXRlcmlhLmh0bWwgZm9yIG1vcmUNCj4+IGluZm9ybWF0 aW9uIGFib3V0IElFU0cgRElTQ1VTUyBhbmQgQ09NTUVOVCBwb3NpdGlvbnMuDQo+Pg0KPj4NCj4+ IFRoZSBkb2N1bWVudCwgYWxvbmcgd2l0aCBvdGhlciBiYWxsb3QgcG9zaXRpb25zLCBjYW4gYmUg Zm91bmQNCj4+IGhlcmU6IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWll dGYtYWNlLXVzZWNhc2VzLw0KPj4NCj4+DQo+Pg0KPj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+PiAtDQo+Pg0K Pj4NCkNPTU1FTlQ6DQo+PiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4+IC0NCj4+DQo+Pg0KPj4NCj4+DQpFeGNl bGxlbnQgYW5kIHdlbGwgd3JpdHRlbiBkb2N1bWVudCwgdGhhbmtzLiBJIHRoaW5rIHRoZXJlIGFy ZQ0KPj4gZml2ZSB0aGluZ3MgeW91IGNvdWxkIHVzZWZ1bGx5IGFkZCwgc2VlIGJlbG93LiBUaGF0 IHNhaWQsIEkgYWdyZWUNCj4+IHRoYXQgdGhpcyBjYW5ub3QgYW5kIHNob3VsZCBub3QgdHJ5IHRv IGJlIGZ1bGx5IGNvbXBsZXRlIHNvIEkgd29uJ3QNCj4+IGFyZ3VlIChtdWNoOi0pIGlmIHlvdSBw cmVmZXIgdG8gb21pdCB0aGVzZS4gV2UveW91IGNhbiBmaWd1cmUgb3V0DQo+PiB3aGF0IGlmIGFu eSB0ZXh0IHRvIGFkZCBJJ20gc3VyZSwgYnV0IEknbSBoYXBweSB0byBjaGF0IGFib3V0IHRoYXQu DQo+Pg0KPj4gMS4gU29mdHdhcmUgdXBkYXRlIGlzIHJlYWxseSBuZWVkZWQgYW5kIG9mdGVuIG1p c3NpbmcgYW5kIHVzdWFsbHkNCj4+IGhhcmQuIFRoZXJlJ3MgYXQgbGVhc3QgYSBuZWVkIHRvIGF1 dGhlbnRpY2F0ZSBhbmQgYXV0aG9yaXplIG5ldw0KPj4gZmlybXdhcmUsIHdoZW4gdGhlcmUgaXMg YW55IHVwZGF0ZS4gVGhhdCBtYXkgbm90IGJlIHRoZSBzYW1lIGFzDQo+PiBhdXRob3JpemluZyBh IG5ldyBjb25maWcuDQo+Pg0KPj4gMi4gQWxpY2UgYnV5cyBhIG5ldyBkZXZpY2UsIGFuZCB3b3Vs ZCBsaWtlIHRvIGtub3cgaWYgaXQgaXMgY2FsbGluZw0KPj4gaG9tZSBvciB3aGF0IGl0IGlzIGRv aW5nIGJlZm9yZSBzaGUgY29uZmlndXJlcyBpdCwgb3IgcGVyaGFwcyBiZWZvcmUNCj4+IHNoZSBh Y2NlcHRzIGl0IGluIGhlciBuZXR3b3JrLiBFdmVuIGlmIHNoZSBhY2NlcHRzIGl0LCBzaGUgbWF5 IHdhbnQNCj4+IHRvIGJlIGFibGUgdG8gbW9uaXRvciB0aGUgZGF0YSBpdCBpcyBzZW5kaW5nICJo b21lIiBlLmcuDQo+PiB0byBlbnN1cmUgaGVyIFRWIGlzIG5vdCBzZW5kaW5nIGRhdGEgd2hlbiBz aGUgaW5zZXJ0cyBhIFVTQiBzdGljaywgaWYNCj4+IHRoYXQgaXMgdW5kZXNpcmVkLg0KPj4NCj4+ IDMuIERldmljZSBmaW5nZXJwcmludGluZyBpcyBhIHRocmVhdCB0aGF0IG91Z2h0IGJlIGNvbnNp ZGVyZWQgYnkNCj4+IHNvbHV0aW9uIGRldmVsb3BlcnMsIGVzcGVjaWFsbHkgaWYgdGhlcmUgaXMg bm8gcmVsaWFibGUgc29mdHdhcmUNCj4+IHVwZGF0ZS4gUHJvYmFibHkgdGhlIGJlc3QgdG8gYmUg ZG9uZSBpcyB0byB0cnkgdG8gbWFrZSBpdCBoYXJkIGZvcg0KPj4gdW5hdXRob3JpemVkIHBhcnRp ZXMgdG8gZmluZ2VycHJpbnQgYSBkZXZpY2UsIGJ1dCB0aGF0J3MgYWxzbyBoYXJkLg0KPj4NCj4+ IDQuIENvbW1lcmNpYWwgRGV2aWNlcyB3aWxsIGJlIGVuZC1vZi1saWZlZCBieSB2ZW5kb3JzLCBh bmQgeWV0IEFsaWNlDQo+PiBzdGlsbCBuZWVkcyB0byBiZSBhYmxlIHRvIHVzZSwgYW5kIHBlcmhh b3MgdG8gdXBkYXRlLCB0aGUgZGV2aWNlLg0KPj4gVGhhdCBjYWxscyBmb3Igc29tZSBraW5kIG9m IGF1dGhvcml6YXRpb24gaGFuZG92ZXIgd2hpY2ggaXMgbm90IHF1aXRlDQo+PiB0aGUgc2FtZSBh cyBhIGNoYW5nZSBvZiBvd25lcnNoaXAuDQo+Pg0KPj4gNS4gUGVuZXRyYXRpb24gdGVzdGluZyB3 aWxsIGhhcHBlbiBhbmQgZGV2aWNlcyBzaG91bGQgbm90IGJhcmYgZXZlbg0KPj4gdGhlbi4gTWF5 YmUgdGhhdCdzIGEgc2VjdXJpdHkgY29uc2lkZXJhdGlvbiB3b3J0aCBhIG1lbnRpb24uDQo+Pg0K Pj4gU2VlIGFsc28gdGhlIHNlY2RpciByZXZpZXcuIFsxXSBJdCdkIGJlIGdvb2QgdG8gc2VlIGEg cmVzcG9uc2UgdG8NCj4+IHRoYXQuDQo+Pg0KPj4gWzFdDQo+PiBodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsLWFyY2hpdmUvd2ViL3NlY2Rpci9jdXJyZW50L21zZzA2MTAxLmh0bWwNCj4+DQo+Pg0K Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18gQWNlIG1h aWxpbmcgbGlzdA0KPj4gQWNlQGlldGYub3JnIGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vYWNlDQo+Pg0KPg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K VGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpbiB0aGlzIG1lc3NhZ2UgbWF5IGJlIGNvbmZpZGVu dGlhbCBhbmQgbGVnYWxseSBwcm90ZWN0ZWQgdW5kZXIgYXBwbGljYWJsZSBsYXcuIFRoZSBtZXNz YWdlIGlzIGludGVuZGVkIHNvbGVseSBmb3IgdGhlIGFkZHJlc3NlZShzKS4gSWYgeW91IGFyZSBu b3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwgeW91IGFyZSBoZXJlYnkgbm90aWZpZWQgdGhhdCBh bnkgdXNlLCBmb3J3YXJkaW5nLCBkaXNzZW1pbmF0aW9uLCBvciByZXByb2R1Y3Rpb24gb2YgdGhp cyBtZXNzYWdlIGlzIHN0cmljdGx5IHByb2hpYml0ZWQgYW5kIG1heSBiZSB1bmxhd2Z1bC4gSWYg eW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwgcGxlYXNlIGNvbnRhY3QgdGhlIHNl bmRlciBieSByZXR1cm4gZS1tYWlsIGFuZCBkZXN0cm95IGFsbCBjb3BpZXMgb2YgdGhlIG9yaWdp bmFsIG1lc3NhZ2UuDQo= From nobody Thu Oct 22 15:22:53 2015 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC7E11B2E1B for ; Thu, 22 Oct 2015 15:22:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kw_Arh5dZh2T for ; Thu, 22 Oct 2015 15:22:47 -0700 (PDT) Received: from mail-qk0-f172.google.com (mail-qk0-f172.google.com [209.85.220.172]) (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 945E01B2E0E for ; Thu, 22 Oct 2015 15:22:46 -0700 (PDT) Received: by qkcy65 with SMTP id y65so60513713qkc.0 for ; Thu, 22 Oct 2015 15:22:45 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=JtEaQ02coFPjXMHgENHkKL0gxCM7r6nMS+WSJT77QFA=; b=TbTOoVCNYS6NUjogHI+2dOgOI1CEDYKctJQEK57PG1k8WDcEpciugAqm2OXYUEp1vW lOszZHnQogSL9QXqL1z1O6+X5qpeNvzUXw87WQfhYeFz3N9AYF6IxMArc5b/mWJDjv5u jPVl4SVe8W1QlxmxODpZ+40IjKh4ouLcoUwMZ/2jZixN5JYZXEKoaJPoDFBjMKPhECRH 52clbSsMQhw7fQC9T7BiBo6HQ/ZrBkYa2rWlhhmNhaWE2boF85Uqvh0chhyHZX4RfkMr 1dp4wkTq2JZrKLXkAEvdGLBmd6N5r2iCi6WAhYmGER8RSQT66T/ehHKHgLMJWjQziIJ3 GC4Q== X-Gm-Message-State: ALoCoQlhGf1FCNn3a1/sK5wFJQNHI2xroXM7PBpKwz9ADZHWGvJjBF0pqc9VzLh0XYaIlld7ggW/ MIME-Version: 1.0 X-Received: by 10.55.207.134 with SMTP id v6mr21680451qkl.53.1445552565584; Thu, 22 Oct 2015 15:22:45 -0700 (PDT) Received: by 10.55.181.69 with HTTP; Thu, 22 Oct 2015 15:22:45 -0700 (PDT) Date: Fri, 23 Oct 2015 00:22:45 +0200 Message-ID: From: Samuel Erdtman To: Ace@ietf.org Content-Type: multipart/alternative; boundary=001a1145b8be2d1e3f0522b8ef7b Archived-At: Subject: [Ace] Review of actors draft X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Oct 2015 22:22:52 -0000 --001a1145b8be2d1e3f0522b8ef7b Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, Review is based on https://tools.ietf.org/html/draft-ietf-ace-actors-01 I absolutely do not want to be rude but the actors draft contributed more to my confusion then to my understanding. This might be a lack in me but IMHO the document needs to be reworked before becoming useful, sorry for saying it. It might be better to spend the energy on the solution drafts instead of reworking this into a useful state. =3D=3D General comments The text is written with lots of parantheses, IMHO that makes the text harder to read. I don=E2=80=99t like the we-statements, this is of cource a subjective opin= ion but i prefer specifications to be written in a more neutral form. The text feels quite academic and unnecessarily complex, from my point of view readably is very important I some times had to read paragraphs several times to get what they meant (this could of cource once again just be me, english is not my native language but I usually get things) This might be do to my lack of understanding but I cannot se the point with CAS I think it adds unnecessary complexity without any added value. Could I get a practical example, I can easily envision the AS being a server managing policies and access rules on who can access what and lists of resources but I have a hard time getting a picture of a CAS. With CAS it is hard to see how RS and C gets a common point of trust, I am therefor is in favour of just AS that serves both C and RS. I think that what is included in CAS should be split up into AS and C. I think that by taking things from AS and C and putting it into CAS the description of things become complicated and it is hard to understand how things are connected. The constrained device limitations are mentioned again and again in the document but seldom with specific connection to the problem e.g is never says to limit code since one should use this technology, it is alway these are the constrains and then comes the list (processing power, memory, non-volatile storage, etc) and after that a choice but seldom or never a direct connection. for an example look at =E2=80=9C6. Kinds of Protocols= =E2=80=9D >From here on comes a list of comments on small and large things in the text, As mentioned previously I don=E2=80=99t think the document is ready t= o be taken to RFC level and that is visible in the amount of comments. Many of the comments are questions as a result of the text being hard to read for me. 1. Introduction I think the section is to long and with sections that is a bit to general. =E2=80=9CWithout appropriate security mechanisms attackers might gain contr= ol over things relevant to our lives.=E2=80=9D What is ment by =E2=80=9Crelevant to out lives=E2=80=9D? will it hurt us ph= ysical? will it be problematic integrity wise? It is nuclear to me what is meant hear. My first interpretation was that it was privacy that was the problem but when I read it again I was not so sure. =E2=80=9C(for example, it may be sufficient to authenticate the age of an actor, so no identifier is needed or even desired)=E2=80=9D This example does not feel very IoT connected, I would rather have an example that authenticates the user as an employee of a company but not the specific person. =E2=80=9CMoreover, several use cases illustrate the need for fine-grained access control policies, for which for instance a basic access control list concept may not be sufficiently powerful.=E2=80=9D What use cases? I guess it refers to the use case document, if so a reference two it would be appreciated 1.1. Terminology =E2=80=9CClient (C): An entity which attempts to access a resource on an R= S.=E2=80=9D change to =E2=80=9CClient (C): An entity which attempts to access a resource on a RS= .=E2=80=9D =E2=80=9CAuthorization Server (AS): An entity that prepares and endorses authentication and authorization data for a Resource Server.=E2=80=9D =E2=80=9CClient Authorization Server (CAS): An entity that prepares and endorses authentication and authorization data for a Client.=E2=80=9D I might be stupid but I don=E2=80=99t get the description, maybe a few more= words could make it clearer. =E2=80=9CAuthenticated Authorization: A synthesis of mechanisms for authentication and authorization.=E2=80=9D Once again i don=E2=80=99t get it, why is this term needed here? could it b= e explained a bit more. =E2=80=9CNote that other authorization architectures such as OAuth [RFC6749= ] or UMA [I-D.hardjono-oauth-umacore] focus on the authorization problems on the RS side, in particular what accesses to resources the RS is to allow. In this document the term authorization includes this aspect, but is also used for the client-side aspect of authorization, i.e., more generally to describe allowed interactions with other endpoints.=E2=80=9D I agree that UMA and OAuth2 focuses on the authoriztion of the client to access a resource at RS but they do not leave client to chance, in the original context of OAuth2 and UMA the endpoints are more powerful and the authentication of the server is offloaded to TLS and the CA list of the involved clients. In UMA and OAuth2 the client will not accept a RS if it does not trust its certificate. I agree that we in this environment need to give the client more help on this part but I think this statement is a bit simplified. 2. Architecture and High-level Problem Statement Absolutely not necessary but it looks better and is usually good to have a section introduction. 2.1. Elements of an Architecture =E2=80=9CThe following setting is assumed:=E2=80=9D How does these release to the whole chapter =E2=80=9C8. Assumptions and Requirements=E2=80=9D, there is no referens to it from here, I prefer the t= ext from this section. =E2=80=9CTo reuse OAuth and UMA terminology, the present document calls C's controlling principal the Requesting Party (RqP), and calls RS's controlling principal the Resource Owner (RO).=E2=80=9D It might be correct that the RqP takes authorisation decisions for the client but it feels quite contra intuitively so some more explanation of it would be appreciated. 2.3. Information flows This section show that to allow initiation of communication from either of the two endpoint they would need to both act as RS and C. with the section title I expected more details on each arrow. I also feel that what is in the section is a bit abundant as it is now, it mostly complicates things that can be implicitly understod I have not seen the HTTP specification saying that if the server would like to communicate with the client the client also needs to deploy a server. 2.4. Problem statement =E2=80=9CThe interaction between potentially constrained endpoints is controlled by control information provided by less-constrained nodes on behalf of the principals of the endpoints.=E2=80=9D Is this really a problem? To me this sounds more like a solution =E2=80=9Ccontrol information=E2=80=9D new concept, is it the same as authorization information? should it maybe be mentioned in the terminology list. 3. Security Objectives =E2=80=9CMisconfigured or wrongly designed authorization solutions can result in availability breaches: Users might no longer be able to use data and services as they are supposed to.=E2=80=9D I guess this refers to a denial of service (DOS) attack, maybe that could be mentioned, it would very quickly put it in a security context by just mentioning the word. =E2=80=9Cif RqP requires the integrity of representations of a resource R that RS is hosting, both C and RS need to partake in integrity-protecting the transmitted data.=E2=80=9D Why does C need to participate? is it because it validates the returned R from RS before presenting it to RqP? if thats it I=E2=80=99m okay with that= but one again could be clearer. =E2=80=9CMoreover, RS needs to protect any write access to this resource as well as to relevant other resources (such as configuration information, firmware update resources) to prevent unauthorized users from manipulating R.=E2=80=9D What is this sentens trying to say? Is it referring to physical tampering? or is it again the integrity and confidentiality of the data returned and/or received? Or is it that RS needs to verify all wire access, i.e. incoming data? 3.1. End-to-End Security Objectives =E2=80=9CNote that there may also be cases of intermediary nodes that very much partake in the security objectives to be achieved.=E2=80=9D It is a bit unclear what these cases may be, is that intentional? or did you not find any? =E2=80=9CWhat is the endpoint to which communication needs end-to-end protection is defined by the use case.=E2=80=9C What use case? a general use case or one from the use case document or a potential use case? 4. Authentication and Authorization This whole section is very unspecific and adds very little to the IoT setting it mostly speaks of Authentication and Authorisation in general terms so it could probably be shortened to a third without losing much valuable information for the context. 5. Actors and their Tasks =E2=80=9CThis section provides a more detailed description of the various "actors" in the architecture=E2=80= =9D Why is actors within quotation marks? is it not really actors in the architecture? if not what is it then? =E2=80=9Cthe logical functional entities performing the tasks required=E2=80=9D The tasks required for what? secure communication? authorisation? something else? 5.1. Constrained Level Actors =E2=80=9CValidate that an entity is an authorized server for R.=E2=80=9D Does this mean that C validates the identity of RS or that it validates the integrity of a response form RS i.e. R? =E2=80=9CFor simplicity of exposition, these resources are described as if they had separate RS.=E2=80=9D What does this relate to I see no further descriptions that this is relevant for so I would just skip this sentence. 5.2. Principal Level Actors I think there need to bee more motivation for why and how RqP decides on the communication security required between C and RS. In practice RpQ will not take any decisions it will be based on the system setup in the same way as you don=E2=80=99t look at all your TLS handshakes when you surf the web = then you just accept that the browser comes bundled with a set of good CAs. In this setting it will probably have be a more dynamic setup where AS will inform C how to communicate with RS instead of as on the web there is one size fits all, TLS. 5.3. Less-Constrained Level Actors I think this section becomes problematic since I don=E2=80=99t think CAS ad= ds value just complexity 7.1. Authorization =E2=80=9CAS needs to transfer authorization information to RS and CAS needs to transfer authorization information to C.=E2=80=9D And how does CAS and AS relate to each other so that the authorisation information transfered to RS and C is compatible? Once again I thin CAS adds more complexity then value. 7.4. Cryptographic Keys Does this section at all belong in this draft 7.4. Cryptographic Keys Symmetric vs Asymmetric Keys feels half done, with the unanswerd question and the headline is like a question but with no answer 7.4. Cryptographic Keys - Key Establishment I like the reference to the use case document, that is missing in the rest of the document 8.1. Architecture Architecture is defined again? is that really necessary? 8.2. Constrained Devices =E2=80=9CAll devices under consideration can process symmetric cryptography without incurring an excessive performance penalty.=E2=80=9D Then there is two bullets that AES is used and for super constrained devices SHA256, that is two completely different things, that does not solve the same problem further one could agree that for super constrained devices we can only do integrity protection and the use a MAC algorithm i.e. not SHA256 but HMAC with SHA256. 8.7. Resource Access =E2=80=9CResources are accessed in a RESTful manner using GET, PUT, POST, DELETE.=E2=80=9D Feels like a technology choice that maybe should not be done in this document, I think it unnecessarily limits where the architecture could be used. =E2=80=9CBy default, the response to a request needs to be integrity protected and encrypted end-to-end from RS to C. It needs to be possible for C to detect a replayed response.=E2=80=9D Encryption does not necessarily provide integrity protection 8.8. Keys and Cipher Suites Here comes a new concept authorization manager, do we need it? if yes mate we should have it in the terminology section. Best Regard Samuel Erdtman --001a1145b8be2d1e3f0522b8ef7b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Hi,

I absolutely do not want to be rude but the actors draft contri= buted more to my confusion then to my understanding. This might be a lack i= n me but IMHO the document needs to be reworked before becoming useful, sor= ry for saying it. It might be better to spend the energy on the solution dr= afts instead of reworking this into a useful state.


=3D=3D General comments
The text is written with= lots of parantheses, IMHO that makes the text harder to read.
I don=E2=80=99t like the we-statements, this is of cource a su= bjective opinion but i prefer specifications to be written in a more neutra= l form.

The text feels quite academic and unnecess= arily complex, from my point of view readably is very important I some time= s had to read paragraphs several times to get what they meant (this could o= f cource once again just be me, english is not my native language but I usu= ally get things)

This might be do to my lack of un= derstanding but I cannot se the point with CAS I think it adds unnecessary = complexity without any added value.=C2=A0
Could I get a practical= example, I can easily envision the AS being a server managing policies and= access rules on who can access what and lists of resources but I have a ha= rd time getting a picture of a CAS.
With CAS it is hard to see ho= w RS and C gets a common point of trust, I am therefor is in favour of just= AS that serves both C and RS.
I think that what is included in C= AS should be split up into AS and C. I think that by taking things from AS = and C and putting it into CAS the description of things become complicated = and it is hard to understand how things are connected.

=
The constrained device limitations are mentioned again and again in th= e document but seldom with specific connection to the problem e.g is never = says to limit code since one should use this technology, it is alway these = are the constrains and then comes the list (processing power, memory, non-v= olatile storage, etc) and after that a choice but seldom or never a direct = connection. for an example look at =E2=80=9C6.=C2=A0 Kinds of Protocols=E2= =80=9D




From here on comes a list of comments on small and large things in the te= xt, As mentioned previously I don=E2=80=99t think the document is ready to = be taken to RFC level and that is visible in the amount of comments. Many o= f the comments are questions as a result of the text being hard to read for= me.



1.=C2=A0 Introd= uction
I think the section is to long and with sections that is a= bit to general.


=E2=80=9CWithout a= ppropriate security mechanisms attackers might gain control
=C2= =A0 =C2=A0over things relevant to our lives.=E2=80=9D
What is men= t by =E2=80=9Crelevant to out lives=E2=80=9D? will it hurt us physical? wil= l it be problematic integrity wise? It is nuclear to me what is meant hear.= My first interpretation was that it was privacy that was the problem but w= hen I read it again I was not so sure.

=E2=80=9C(f= or example, it may be
=C2=A0 =C2=A0sufficient to authenticate the= age of an actor, so no identifier is
=C2=A0 =C2=A0needed or even= desired)=E2=80=9D
This example does not feel very IoT connected,= I would rather have an example that authenticates the user as an employee = of a company but not the specific person.

=E2=80= =9CMoreover, several use cases illustrate the need for fine-grained
=C2=A0 =C2=A0access control policies, for which for instance a basic acc= ess
=C2=A0 =C2=A0control list concept may not be sufficiently pow= erful.=E2=80=9D
What use cases? I guess it refers to the use case= document, if so a reference two it would be appreciated
=C2=A0

1.1.=C2=A0 Terminology
=E2=80=9CClient (C= ): =C2=A0An entity which attempts to access a resource on an RS.=E2=80=9D
change to=C2=A0
=E2=80=9CClient (C): =C2=A0An entity whi= ch attempts to access a resource on a RS.=E2=80=9D

=E2=80=9CAuthorization Server (AS): =C2=A0An entity that prepares and endo= rses
=C2=A0 =C2=A0 =C2=A0 authentication and authorization data f= or a Resource Server.=E2=80=9D
=E2=80=9CClient Authorization Serv= er (CAS): =C2=A0An entity that prepares and
=C2=A0 =C2=A0 =C2=A0 = endorses authentication and authorization data for a Client.=E2=80=9D
=
I might be stupid but I don=E2=80=99t get the description, maybe a few= more words could make it clearer.

=E2=80=9CAuthen= ticated Authorization: =C2=A0A synthesis of mechanisms for
=C2=A0= =C2=A0 =C2=A0 authentication and authorization.=E2=80=9D
Once ag= ain i don=E2=80=99t get it, why is this term needed here? could it be expla= ined a bit more.

=E2=80=9CNote that other authoriz= ation architectures such as OAuth [RFC6749]
=C2=A0 =C2=A0or UMA [= I-D.hardjono-oauth-umacore] focus on the authorization
=C2=A0 =C2= =A0problems on the RS side, in particular what accesses to resources the
=C2=A0 =C2=A0RS is to allow.=C2=A0 In this document the term author= ization includes
=C2=A0 =C2=A0this aspect, but is also used for t= he client-side aspect of
=C2=A0 =C2=A0authorization, i.e., more g= enerally to describe allowed interactions
=C2=A0 =C2=A0with other= endpoints.=E2=80=9D
I agree that UMA and OAuth2 focuses on the a= uthoriztion of the client to access a resource at RS but they do not leave = client to chance, in the original context of OAuth2 and UMA the endpoints a= re more powerful and the authentication of the server is offloaded to TLS a= nd the CA list of the involved clients. In UMA and OAuth2 the client will n= ot accept a RS if it does not trust its certificate. I agree that we in thi= s environment need to give the client more help on this part but I think th= is statement is a bit simplified.


2= .=C2=A0 Architecture and High-level Problem Statement
Absolutely = not necessary but it looks better and is usually good to have a section int= roduction.


2.1.=C2=A0 Elements of a= n Architecture
=E2=80=9CThe following
=C2=A0 =C2=A0sett= ing is assumed:=E2=80=9D
How does these release to the whole chap= ter =E2=80=9C8.=C2=A0 Assumptions and Requirements=E2=80=9D, there is no re= ferens to it from here, I prefer the text from this section.

=
=E2=80=9CTo reuse OAuth and UMA
=C2=A0 =C2=A0terminolo= gy, the present document calls C's controlling principal the
= =C2=A0 =C2=A0Requesting Party (RqP), and calls RS's controlling princip= al the
=C2=A0 =C2=A0Resource Owner (RO).=E2=80=9D
It mi= ght be correct that the RqP takes authorisation decisions for the client bu= t it feels quite contra intuitively so some more explanation of it would be= appreciated.



2.3.= =C2=A0 Information flows
This section show that to allow initiati= on of communication from either of the two endpoint they would need to both= act as RS and C. with the section title I expected more details on each ar= row. I also feel that what is in the section is a bit abundant as it is now= , it mostly complicates things that can be implicitly understod I have not = seen the HTTP specification saying that if the server would like to communi= cate with the client the client also needs to deploy a server.

2.4.=C2=A0 Problem statement
=E2=80= =9CThe interaction between potentially constrained endpoints is
= =C2=A0 =C2=A0 =C2=A0 controlled by control information provided by less-con= strained
=C2=A0 =C2=A0 =C2=A0 nodes on behalf of the principals o= f the endpoints.=E2=80=9D
Is this really a problem? To me this so= unds more like a solution

=E2=80=9Ccontrol informa= tion=E2=80=9D
new concept, is it the same as authorization inform= ation? should it maybe be mentioned in the terminology list.

=

3.=C2=A0 Security Objectives
=E2=80=9CM= isconfigured or
=C2=A0 =C2=A0wrongly designed authorization solut= ions can result in availability
=C2=A0 =C2=A0breaches: Users migh= t no longer be able to use data and services as
=C2=A0 =C2=A0they= are supposed to.=E2=80=9D
I guess this refers to a denial of ser= vice (DOS) attack, maybe that could be mentioned, it would very quickly put= it in a security context by just mentioning the word.

=
=E2=80=9Cif RqP requires the integrity of representations of a
=C2=A0 =C2=A0resource R that RS is hosting, both C and RS need to partak= e in
=C2=A0 =C2=A0integrity-protecting the transmitted data.=E2= =80=9D
Why does C need to participate? is it because it validates= the returned R from RS before presenting it to RqP? if thats it I=E2=80=99= m okay with that but one again could be clearer.

= =E2=80=9CMoreover, RS needs to
=C2=A0 =C2=A0protect any write acc= ess to this resource as well as to relevant
=C2=A0 =C2=A0other re= sources (such as configuration information, firmware update
=C2= =A0 =C2=A0resources) to prevent unauthorized users from manipulating R.=E2= =80=9D
What is this sentens trying to say? Is it referring to phy= sical tampering? or is it again the integrity and confidentiality of the da= ta returned and/or received? Or is it that RS needs to verify all wire acce= ss, i.e. incoming data?


3.1.=C2=A0 = End-to-End Security Objectives
=E2=80=9CNote that there may also = be cases of intermediary nodes that very
=C2=A0 =C2=A0much partak= e in the security objectives to be achieved.=E2=80=9D
It is a bit= unclear what these cases may be, is that intentional? or did you not find = any?


=E2=80=9CWhat is the
=C2=A0 =C2=A0endpoint to which communication needs end-to-end protection i= s
=C2=A0 =C2=A0defined by the use case.=E2=80=9C
What u= se case? a general use case or one from the use case document or a potentia= l use case?


4.=C2=A0 Authentication= and Authorization
This whole section is very unspecific and adds= very little to the IoT setting it mostly speaks of Authentication and Auth= orisation in general terms so it could probably be shortened to a third wit= hout losing much valuable information for the context.

=
5.=C2=A0 Actors and their Tasks
=E2=80=9CThis section provid= es a more
=C2=A0 =C2=A0detailed description of the various "= actors" in the architecture=E2=80=9D
Why is actors within qu= otation marks? is it not really actors in the architecture? if not what is = it then?

=E2=80=9Cthe
=C2=A0 =C2=A0logic= al functional entities performing the tasks required=E2=80=9D
The= tasks required for what? secure communication? authorisation? something el= se?


5.1.=C2=A0 Constrained Level Ac= tors
=E2=80=9CValidate that an entity is an authorized server for= R.=E2=80=9D
Does this mean that C validates the identity of RS o= r that it validates the integrity of a response form RS i.e. R?
<= br>
=E2=80=9CFor simplicity of exposition, these resources are de= scribed as if
=C2=A0 =C2=A0they had separate RS.=E2=80=9D
What does this relate to I see no further descriptions that this is rele= vant for so I would just skip this sentence.


<= /div>
5.2.=C2=A0 Principal Level Actors
I think there need to= bee more motivation for why and how RqP decides on the communication secur= ity required between C and RS. In practice RpQ will not take any decisions = it will be based on the system setup in the same way as you don=E2=80=99t l= ook at all your TLS handshakes when you surf the web then you just accept t= hat the browser comes bundled with a set of good CAs. In this setting it wi= ll probably have be a more dynamic setup where AS will inform C how to comm= unicate with RS instead of as on the web there is one size fits all, TLS.


5.3.=C2=A0 Less-Constrained Level Ac= tors
I think this section becomes problematic since I don=E2=80= =99t think CAS adds value just complexity

7.1.=C2= =A0 Authorization
=E2=80=9CAS needs to transfer authorization inf= ormation to RS and CAS needs
=C2=A0 =C2=A0 =C2=A0 to transfer aut= horization information to C.=E2=80=9D
And how does CAS and AS rel= ate to each other so that the authorisation information transfered to RS an= d C is compatible? Once again I thin CAS adds more complexity then value.


7.4.=C2=A0 Cryptographic Keys
<= div>Does this section at all belong in this draft

= 7.4.=C2=A0 Cryptographic Keys
Symmetric vs Asymmetric Keys
<= div>feels half done, with the unanswerd question and the headline is like a= question but with no answer

7.4.=C2=A0 Cryptograp= hic Keys - Key Establishment
I like the reference to the use case= document, that is missing in the rest of the document

=

8.1.=C2=A0 Architecture
Architecture is defin= ed again? is that really necessary?


8.2.=C2=A0 Constrained Devices
=E2=80=9CAll devices under consid= eration can process symmetric cryptography
=C2=A0 =C2=A0 =C2=A0 w= ithout incurring an excessive performance penalty.=E2=80=9D
Then = there is two bullets that AES is used and for super constrained devices SHA= 256, that is two completely different things, that does not solve the same = problem further one could agree that for super constrained devices we can o= nly do integrity protection and the use a MAC algorithm i.e. not SHA256 but= HMAC with SHA256.


8.7.=C2=A0 Resou= rce Access
=E2=80=9CResources are accessed in a RESTful manner us= ing GET, PUT, POST,
=C2=A0 =C2=A0 =C2=A0 DELETE.=E2=80=9D
Feels like a technology choice that maybe should not be done in this doc= ument, I think it unnecessarily limits where the architecture could be used= .

=E2=80=9CBy default, the response to a request n= eeds to be integrity
=C2=A0 =C2=A0 =C2=A0 protected and encrypted= end-to-end from RS to C.=C2=A0 It needs to be
=C2=A0 =C2=A0 =C2= =A0 possible for C to detect a replayed response.=E2=80=9D
Encryp= tion does not necessarily provide integrity protection

=
8.8.=C2=A0 Keys and Cipher Suites
Here comes a new concept a= uthorization manager, do we need it? if yes mate we should have it in the t= erminology section.



= Best Regard
Samuel Erdtman


 --001a1145b8be2d1e3f0522b8ef7b-- From nobody Thu Oct 22 16:10:59 2015 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F8AB1B2FF9; Thu, 22 Oct 2015 16:10:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.55 X-Spam-Level: X-Spam-Status: No, score=-1.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vyiibw4bKEyu; Thu, 22 Oct 2015 16:10:56 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D5901B2FF3; Thu, 22 Oct 2015 16:10:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::b]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id t9MNAmwN003037; Fri, 23 Oct 2015 01:10:48 +0200 (CEST) Received: from nar.local (p5DC7F6AE.dip0.t-ipconnect.de [93.199.246.174]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3nhkvC6lr6zHxXB; Fri, 23 Oct 2015 01:10:47 +0200 (CEST) Message-ID: <56296CF6.4090202@tzi.org> Date: Fri, 23 Oct 2015 01:10:46 +0200 From: Carsten Bormann User-Agent: Postbox 4.0.7 (Macintosh/20151021) MIME-Version: 1.0 To: "Kumar, Sandeep" References: <20151022132903.23826.2689.idtracker@ietfa.amsl.com> <9727B59F-CD2D-4A32-8F7B-F5C89EE2E388@tzi.org> <5628ED5D.7070508@cs.tcd.ie> <13a9cf15d35c4889ada98e789680e047@DB5PR9001MB0167.MGDPHG.emi.philips.com> In-Reply-To: <13a9cf15d35c4889ada98e789680e047@DB5PR9001MB0167.MGDPHG.emi.philips.com> X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: Stephen Farrell , "ace-chairs@ietf.org" , The IESG , "ace@ietf.org" , "Hannes.Tschofenig@gmx.net" , "draft-ietf-ace-usecases@ietf.org" Subject: Re: [Ace] Stephen Farrell's Yes on draft-ietf-ace-usecases-09: (with COMMENT) X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Oct 2015 23:10:58 -0000 Kumar, Sandeep wrote: > draft-garcia-core-security-06 was such an attempt. Maybe a good time to resurrect it. Absolutely. I keep wanting to find a good home for it. One approach would be to work on it as a T2TRG deliverable. That said, the document I had in mind may be even more useful if it is shorter, more focused on a few points we want implementers to understand. So maybe we'll have two documents in the end, that kind of brief security considerations, and the more encompassing document that is like core-security (the latter also now has a few more documents it actually can delegate things to, such as ace-actors). Grüße, Carsten From nobody Thu Oct 22 19:33:18 2015 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D2341B30D7; Thu, 22 Oct 2015 19:33:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b8zHd6AFP64m; Thu, 22 Oct 2015 19:33:11 -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 2F6B61B30ED; Thu, 22 Oct 2015 19:33:10 -0700 (PDT) Received: by qkbl190 with SMTP id l190so63810819qkb.2; Thu, 22 Oct 2015 19:33:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:mime-version:subject:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=2VWU27podWyZsOPSGtYcutko/tBFxc9cz82iSgCtdcU=; b=TNOopgmKfnEAEXPcnrE4nNF5gE+gdow/RyekXvu9ePrCkeqIfjapjMcF9i/bwFoB3h YLu6VfwsYUYZVxtg9yXiklq0FYrqi+iUSwCzqGYj11IMoPHbvA5ZJsaPPnl8O7NueOV2 qVVTBpd8CcXJ2hT8uhPZmXRdWJLqMPDjC833n5xv/FBBlIYuDijz0KtFSw5X2cf077Wg 4R5zCQVa6cvTpo/1wLjmfNoIK0O2DbuxcXqqqgTkrTt2cXAUtW7tH8Zg4WtKqqc4hU3V hmD93vugBVPrM6dEtWlk3xZdrGGKfK9iGDYA8sGu7FX/6RdyqEQrgsE8+9REjoLxs8/P kWQg== X-Received: by 10.55.215.211 with SMTP id t80mr22609128qkt.62.1445567589377; Thu, 22 Oct 2015 19:33:09 -0700 (PDT) Received: from [192.168.1.3] (209-6-114-252.c3-0.arl-ubr1.sbo-arl.ma.cable.rcn.com. [209.6.114.252]) by smtp.gmail.com with ESMTPSA id k102sm4207628qgd.24.2015.10.22.19.33.08 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 22 Oct 2015 19:33:08 -0700 (PDT) From: Kathleen Moriarty X-Google-Original-From: Kathleen Moriarty Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) X-Mailer: iPhone Mail (12H143) In-Reply-To: <56296CF6.4090202@tzi.org> Date: Thu, 22 Oct 2015 22:33:07 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <2AAFBBB7-5967-45D7-83CE-C56149721794@gmail.com> References: <20151022132903.23826.2689.idtracker@ietfa.amsl.com> <9727B59F-CD2D-4A32-8F7B-F5C89EE2E388@tzi.org> <5628ED5D.7070508@cs.tcd.ie> <13a9cf15d35c4889ada98e789680e047@DB5PR9001MB0167.MGDPHG.emi.philips.com> <56296CF6.4090202@tzi.org> To: Carsten Bormann Archived-At: Cc: "ace-chairs@ietf.org" , "draft-ietf-ace-usecases@ietf.org" , The IESG , "ace@ietf.org" , "Hannes.Tschofenig@gmx.net" , "Kumar, Sandeep" , Stephen Farrell Subject: Re: [Ace] Stephen Farrell's Yes on draft-ietf-ace-usecases-09: (with COMMENT) X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Oct 2015 02:33:13 -0000 As long as it happens as we've discussed this option (and I like it) before w= ithout progress. Thank you, Kathleen=20 Sent from my iPhone > On Oct 22, 2015, at 7:10 PM, Carsten Bormann wrote: >=20 > Kumar, Sandeep wrote: >> draft-garcia-core-security-06 was such an attempt. Maybe a good time to r= esurrect it. >=20 > Absolutely. I keep wanting to find a good home for it. One approach > would be to work on it as a T2TRG deliverable. >=20 > That said, the document I had in mind may be even more useful if it is > shorter, more focused on a few points we want implementers to > understand. So maybe we'll have two documents in the end, that kind of > brief security considerations, and the more encompassing document that > is like core-security (the latter also now has a few more documents it > actually can delegate things to, such as ace-actors). >=20 > Gr=C3=BC=C3=9Fe, Carsten >=20 From nobody Thu Oct 22 23:26:23 2015 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 834331AD356 for ; Thu, 22 Oct 2015 23:26:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.901 X-Spam-Level: X-Spam-Status: No, score=-3.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8BLKgKn64G_r for ; Thu, 22 Oct 2015 23:26:20 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 45D351AD2AF for ; Thu, 22 Oct 2015 23:26:20 -0700 (PDT) X-AuditID: c1b4fb25-f79a26d00000149a-f4-5629d3098385 Received: from ESESSHC006.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 68.5C.05274.903D9265; Fri, 23 Oct 2015 08:26:17 +0200 (CEST) Received: from ESESSMB303.ericsson.se ([169.254.3.10]) by ESESSHC006.ericsson.se ([153.88.183.36]) with mapi id 14.03.0248.002; Fri, 23 Oct 2015 08:26:17 +0200 From: =?utf-8?B?R8O2cmFuIFNlbGFuZGVy?= To: Stefanie Gerdes , Olaf Bergmann , "Ace@ietf.org" Thread-Topic: [Ace] General Solution Framework for ACE Thread-Index: AQHRDKObOb8tfSCBgEyIZbXCQ50B5554niiA Date: Fri, 23 Oct 2015 06:26:16 +0000 Message-ID: References: <56289E19.8090308@tzi.de> In-Reply-To: <56289E19.8090308@tzi.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.7.141117 x-originating-ip: [153.88.183.149] Content-Type: text/plain; charset="utf-8" Content-ID: <9B6D3456076EAD409EC45B184B3CE498@ericsson.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrEIsWRmVeSWpSXmKPExsUyM+JvjS7XZc0wgzscFt+/9TBbNC1uZLLY ePEuowOzx5IlP5k8tr39yuwxbVFmAHMUl01Kak5mWWqRvl0CV8auY9eYC9rUKq49WM/awNih 2sXIySEhYCJx49EvJghbTOLCvfVsXYxcHEICRxklFh7dBZYQEljMKPHwQxiIzSbgIvGg4RFQ nINDRCBN4minOkhYWMBU4s3SfnaIsJlEw+JwCNNIYkcPmMkioCrx50cKSDGvgIXExU8fWCBm q0r8uzOHGcTmFFCTmPLyFxuIzQh0zPdTa8D2MwuIS9x6Mh/qSAGJJXvOM0PYohIvH/9jBbFF BfQkVl5vYoOIK0msPbydBWQts4CmxPpd+hBjrCUu7Glng7AVJaZ0P2SHOEdQ4uTMJywTGMVn Idk2C6F7FpLuWUi6ZyHpXsDIuopRtDi1OCk33chYL7UoM7m4OD9PLy+1ZBMjMOYObvmtuoPx 8hvHQ4wCHIxKPLwLp2iGCbEmlhVX5h5ilOBgVhLhDWkGCvGmJFZWpRblxxeV5qQWH2KU5mBR EudtZnoQKiSQnliSmp2aWpBaBJNl4uCUamBMn8Ezz/1G+bcooYUezXoXpUss70rKTjVIXXNq p7hotvFrE5Wzhy6uiv7xYabi01uXfQ1NNJ/ffuRe7Fif/WiGgbd8e9jR9ct+GKSF/f1U9Mb9 /UynKefU7uS5Nt9yT2XIKBMpsDMXmuhr8yuy9lhAho/ks+lKOVOF5p/7v/mn5t+Ulj9V5c1K LMUZiYZazEXFiQC7Ux4MtQIAAA== Archived-At: Subject: Re: [Ace] General Solution Framework for ACE X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Oct 2015 06:26:22 -0000 SGkgU3RlZmZpIGFuZCBPbGFmLA0KDQpJdCBzZWVtcyB0byBtZSB0aGF0IERDQUYgY2xhaW1zIHRv IHByb3ZpZGUgc2VjdXJpdHkgb24gYXBwbGljYXRpb24gbGF5ZXINCnRocm91Z2ggaW50ZXJtZWRp YXJ5IG5vZGVzLCBzdWNoIGFzIENvQVAgcHJveGllcywgYnV0IGZhaWxzIHRvIGRvIHNvLg0KDQpU aGUgY29uc3RydWN0aW9uIHlvdSBtYWtlIGluIFs0XSBpbnRlZ3JpdHkgcHJvdGVjdHMgb3B0aW9u cyB0aGF0IGFyZQ0KdW5zYWZlIGFuZCBtYXkgYmUgY2hhbmdlZCBieSBhIENvQVAgcHJveHkuIEhl bmNlIHRoZSBNQUMgY2FsY3VsYXRlZCBieSB0aGUNCmNsaWVudCB3aWxsIGJlIGRpZmZlcmVudCBm cm9tIHRoZSBNQUMgY2FsY3VsYXRlZCBieSB0aGUgc2VydmVyIGFuZCB0aGUNCm1lc3NhZ2Ugd2ls bCBiZSByZWplY3RlZCwgZGVzcGl0ZSB0aGlzIGJlaW5nIGEgbGVnaXRpbWF0ZSBwcm94eSBvcGVy YXRpb24uDQoNCg0KRGV0YWlscyBhcmUgaW4gWzRdOg0KDQpTZWN0aW9uIDE6DQoiSW4gdGhlIHBy ZXNlbmNlIG9mIGludGVybWVkaWFyaWVzIHN1Y2ggYXMsIGUuZy4sIENvQVAgcHJveGllcywgY2hh bm5lbA0Kc2VjdXJpdHkgbWF5IG5vdCBiZSBhcHBsaWNhYmxlIGZvciBhbGwgY29uZmlndXJhdGlv bnMuICBJZiB0aGlzIGlzIHRoZQ0KY2FzZSwgdGhlIGV4Y2hhbmdlZCBpbmZvcm1hdGlvbiBtdXN0 IGJlIHByb3RlY3RlZCBhdCB0aGUgYXBwbGljYXRpb24gbGV2ZWwNCnRvIGhlbHAgYWNoaWV2aW5n IHRoZSBwcmluY2lwYWxzJyBzZWN1cml0eSByZXF1aXJlbWVudHMuICINCg0KIlRoaXMgc3BlY2lm aWNhdGlvbiB1c2VzIHRoaXMgQ0JPUiBFbmNvZGVkIE1lc3NhZ2UgU3ludGF4DQpbSS1ELmlldGYt Y29zZS1tc2ddIHRvIHByb3RlY3QgdGhlIERDQUYgcHJvdG9jb2wgZmxvdyBvbiB0aGUgYXBwbGlj YXRpb24NCmxldmVsLiINCg0KU2VjdGlvbiAyLjE6DQoiYSBDT1NFX01hYyBzdHJ1Y3R1cmUgdXNl ZCB0byBpbnRlZ3JpdHktcHJvdGVjdCB0aGUgcmVxdWVzdCINCg0KIk5vdGUgdGhhdCB0aGUgaW50 ZWdyaXR5IHByb3RlY3Rpb24gbm90IG9ubHkgY292ZXJzIHRoZSBtZXNzYWdlIHBheWxvYWQNCmJ1 dCBhbHNvIHRoZSBjb250ZW50IHR5cGUgYW5kIHZhcmlvdXMgc2Vuc2l0aXZlIENvQVAgb3B0aW9u cyBzdWNoIGFzDQpVcmktUGF0aCB0aGF0IHdpbGwgYmUgcGFzc2VkIHRvIHRoZSBNQUMgY3JlYXRp b24gZnVuY3Rpb25zIGFzDQpjYW5vbmljYWxpemVkIGV4dGVybmFsX2FhZCBhcyBkZXNjcmliZWQg aW4gU2VjdGlvbiA2LiINCg0KU2VjdGlvbiA2IGxpc3RzIHRoZSBvcHRpb25zIHdoaWNoIGFyZSBp bnRlZ3JpdHkgcHJvdGVjdGVkIGluY2x1ZGluZw0KVXJpLUhvc3QsIE9ic2VydmUsIFVyaS1Qb3J0 LCBVcmktUGF0aCwgVXJpLVF1ZXJ5LCBQcm94eS1VcmkgYW5kDQpQcm94eS1TY2hlbWUsIHdoaWNo IGFyZSB1bnNhZmUuIEUuZy4gUHJveHktVXJpIGlzIHNwbGl0IGJ5IGEgZm9yd2FyZCBwcm94eQ0K aW50byBVcmktSG9zdCwgVXJpLVBvcnQsIFVyaS1QYXRoLCBhbmQgVXJpLVF1ZXJ5LCBhcyBleHBs YWluZWQgaW4gUkZDNzI1Mg0Kc2VjdGlvbiA1LjcuMjoNCg0KIkNvQVAgcmVxdWVzdHMgdG8gYSBm b3J3YXJkLXByb3h5IGFyZSBtYWRlIGFzIG5vcm1hbCBDb25maXJtYWJsZSBvcg0KTm9uLWNvbmZp cm1hYmxlICByZXF1ZXN0cyB0byB0aGUgZm9yd2FyZC1wcm94eSBlbmRwb2ludCwgYnV0IHRoZXkg c3BlY2lmeQ0KdGhlIHJlcXVlc3QgVVJJIGluIGEgZGlmZmVyZW50IHdheTogVGhlIHJlcXVlc3Qg VVJJIGluIGEgcHJveHkgcmVxdWVzdCBpcw0Kc3BlY2lmaWVkIGFzIGEgc3RyaW5nIGluIHRoZSBQ cm94eS1VcmkgT3B0aW9uIChzZWUgU2VjdGlvbiA1LjEwLjIpLCB3aGlsZQ0KdGhlIHJlcXVlc3Qg VVJJIGluIGEgcmVxdWVzdCB0byBhbiBvcmlnaW4gc2VydmVyIGlzIHNwbGl0IGludG8gdGhlDQpV cmktSG9zdCwgVXJpLVBvcnQsIFVyaS1QYXRoLCBhbmQgVXJpLVF1ZXJ5IE9wdGlvbnMgKHNlZSBT ZWN0aW9uIDUuMTAuMSkuIg0KDQoNCkfDtnJhbg0KDQoNCg0KDQpPbiAyMDE1LTEwLTIyIDEwOjI4 LCAiU3RlZmFuaWUgR2VyZGVzIiA8Z2VyZGVzQHR6aS5kZT4gd3JvdGU6DQoNCj5IaSwNCj4NCj5X ZSBzdWJtaXR0ZWQgdGhlIEFDRSBTb2x1dGlvbnMgZHJhZnQgWzFdIHRoYXQgcHJlc2VudHMgYSBn ZW5lcmFsDQo+c29sdXRpb24gZnJhbWV3b3JrIGZvciB0aGUgUHJpdmFjeS1FbmhhbmNlZCBUb2tl bnMgWzJdIGFuZCBEQ0FGIFszXS4NCj4NCj5XZSB1cGRhdGVkIERDQUYgYWNjb3JkaW5nbHkuIFRo ZSBuZXcgdmVyc2lvbiBhbHNvIGFkZHJlc3NlcyBSZW56bydzDQo+Y29tbWVudHMgYW5kIGNvbnRh aW5zIG1vcmUgZXhwbGFuYXRvcnkgdGV4dCBob3cgRENBRiBwYXlsb2FkcyBjYW4gYmUNCj50cmFu c2ZlcnJlZCB1c2luZyBDT1NFLiBNb3JlIGRldGFpbHMgYWJvdXQgaG93IERDQUYgd29ya3Mgd2l0 aCBvYmplY3QNCj5zZWN1cml0eSBjYW4gYmUgZm91bmQgaW4gdGhlIG5ldyBEQ0FGLUNPU0UgZHJh ZnQgWzRdLg0KPg0KPk1vcmVvdmVyLCB3ZSBzdWJtaXR0ZWQgdGhlIFNlcnZlci1Jbml0aWF0ZWQg VGlja2V0IFJlcXVlc3QgKFNJVFIpIGRyYWZ0DQo+WzVdIHRoYXQgZXhwbGFpbnMgaG93IGEgKHBv c3NpYmx5IGNvbnN0cmFpbmVkKSBzZXJ2ZXIgY2FuIHJlcXVlc3QgYQ0KPnRpY2tldCBmb3IgYSAo cG9zc2libHkgY29uc3RyYWluZWQpIGNsaWVudCB0aGF0IHJlcHJlc2VudHMgdGhlIG11dHVhbA0K PmF1dGhlbnRpY2F0aW9uIGFuZCBhdXRob3JpemF0aW9uIG9mIHRoZSBDbGllbnQgQXV0aG9yaXph dGlvbiBNYW5hZ2VyIGFuZA0KPnRoZSBTZXJ2ZXIgQXV0aG9yaXphdGlvbiBNYW5hZ2VyLg0KPg0K PkNvbW1lbnRzIGFyZSB2ZXJ5IHdlbGNvbWUuDQo+DQo+QmVzdCByZWdhcmRzLA0KPlN0ZWZmaQ0K Pg0KPlsxXSBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtY3VlbGxhci1hY2Utc29s dXRpb25zLTAwDQo+WzJdDQo+aHR0cHM6Ly90b29scy5pZXRmLm9yZy9pZC9kcmFmdC1jdWVsbGFy LWFjZS1wYXQtcHJpdi1lbmhhbmNlZC1hdXRoei10b2tlbnMNCj4tMDEudHh0DQo+WzNdIGh0dHBz Oi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1nZXJkZXMtYWNlLWRjYWYtYXV0aG9yaXplLTA0 DQo+WzRdIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1iZXJnbWFubi1hY2UtZGNh Zi1jb3NlLTAwDQo+WzVdIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaWQvZHJhZnQtZ2VyZGVzLWFj ZS1kY2FmLXNpdHItMDAudHh0DQo+DQo+LS0gDQo+U3RlZmFuaWUgR2VyZGVzCQkJVGVsOiArNDkg NDIxIDIxOCA2MzkwNg0KPlRaSSBVbml2ZXJzaXTDpHQgQnJlbWVuCQlFLU1haWw6IGdlcmRlc0B0 emkuZGUNCj5CaWJsaW90aGVrc3RyLiAxLCBNWkggNTE1MA0KPjI4MzU5IEJyZW1lbiwgR2VybWFu eQ0KPg0KPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ QWNlIG1haWxpbmcgbGlzdA0KPkFjZUBpZXRmLm9yZw0KPmh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vYWNlDQoNCg== From nobody Fri Oct 23 01:04:25 2015 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5D5C1B32EB for ; Fri, 23 Oct 2015 01:04:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V0OqOXOn6oNY for ; Fri, 23 Oct 2015 01:04:21 -0700 (PDT) Received: from mail-lf0-x22d.google.com (mail-lf0-x22d.google.com [IPv6:2a00:1450:4010:c07::22d]) (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 00EEC1B32EE for ; Fri, 23 Oct 2015 01:04:20 -0700 (PDT) Received: by lffz202 with SMTP id z202so74770509lff.3 for ; Fri, 23 Oct 2015 01:04:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sics_se.20150623.gappssmtp.com; s=20150623; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-type; bh=Of1bRzGs2iskzlYciUP/XnJT0nluNMfPnnOMJxa3+cg=; b=SfL4oHcUVao0hPUM6ucqGYZh54N+uTe8pmU9uh9215yOMdwlpnWXjY5HpE/V+1U0gt D6lk1W2BWEnurPAQjUWzwqeCpYxy4Y+Ik/iU0qTHU655dU0qfRW6pBZLy0Y+HPwozwGR ZM1X0wX6DLjv5e7I+eNUyaZ7KtOmv16vFfOUEpNU8CM3ZaMl3X+ErRLxllKQguhyWVV+ hAsARg3T+1qblICS10PJCF1Gsv7KyRJ1+w9KBDY+HQvisphy5xsKCmPyXZ6FcnTBMBHI oCJzAcl31TAzmrVHo1Lixvj5sqGHG8vbcoFwwphfd+AfZdo/jZLKkEOfZxXMjMa/Y3ip InkA== 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:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-type; bh=Of1bRzGs2iskzlYciUP/XnJT0nluNMfPnnOMJxa3+cg=; b=dEMP3Du/9hLFfqhFvurGffKUf1pIsLnRhzeoEWhhZ9M28+4ToVvFUi4jDNWduT3C6/ EDOboq9OQMlide4OQMy3TeP7mYfC+mZVezHg1H7Q0qNKl6QdvekDsMOCYI1IKjZve4kG iaSwa2/5HFatiHVPpyYBsS9mA9FY5r+R7PgxDQ/q3ZF4v6kg3qPrCdCtDJgERfdf1ksC 2ZQY8sxX9pjYGa6OnukDhzoFFi20AAXT9CaIGfMxhcmosZg0zPxbLmIysTguSmVi5nmT 2K9n2tjq7F9qaxr99DPWFOd4H1+hv4CyVDyKLMRzKRWSNbEFL918cxpxCseDV8+/Tr/4 DYlw== X-Gm-Message-State: ALoCoQlpmi1/1bHjTXtPrd0hLwRr3F4r3qAZjm7MTvApfj1sVJSqTKGjYTdVKYO96nvUfPKtk6Rw X-Received: by 10.25.23.208 with SMTP id 77mr6844899lfx.44.1445587459171; Fri, 23 Oct 2015 01:04:19 -0700 (PDT) Received: from [192.168.0.108] ([85.235.11.178]) by smtp.gmail.com with ESMTPSA id k4sm3028389lbp.12.2015.10.23.01.04.18 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 23 Oct 2015 01:04:18 -0700 (PDT) To: Stephen Farrell References: <20151022132903.23826.2689.idtracker@ietfa.amsl.com> From: Ludwig Seitz Message-ID: <5629EA01.6020506@sics.se> Date: Fri, 23 Oct 2015 10:04:17 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <20151022132903.23826.2689.idtracker@ietfa.amsl.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms040104020804090900070304" Archived-At: Cc: ace@ietf.org Subject: Re: [Ace] Stephen Farrell's Yes on draft-ietf-ace-usecases-09: (with COMMENT) X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Oct 2015 08:04:23 -0000 This is a cryptographically signed message in MIME format. --------------ms040104020804090900070304 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable On 2015-10-22 15:29, Stephen Farrell wrote: [...] > > 1. Software update is really needed and often missing and > usually hard. There's at least a need to authenticate and > authorize new firmware, when there is any update. That may not > be the same as authorizing a new config. > > 2. Alice buys a new device, and would like to know if it is > calling home or what it is doing before she configures it, or > perhaps before she accepts it in her network. Even if she > accepts it, she may want to be able to monitor the data it > is sending "home" e.g. to ensure her TV is not sending > data when she inserts a USB stick, if that is undesired. > > 3. Device fingerprinting is a threat that ought be considered > by solution developers, especially if there is no reliable > software update. Probably the best to be done is to try to > make it hard for unauthorized parties to fingerprint a device, > but that's also hard. > > 4. Commercial Devices will be end-of-lifed by vendors, and yet > Alice still needs to be able to use, and perhaos to update, > the device. That calls for some kind of authorization handover > which is not quite the same as a change of ownership. > > 5. Penetration testing will happen and devices should not barf > even then. Maybe that's a security consideration worth a > mention. > > See also the secdir review. [1] It'd be good to see a > response to that. > > [1] https://www.ietf.org/mail-archive/web/secdir/current/msg06101.h= tml > Hi Stephen, Thank you for your comments! We are making final adjustments to the document based on the *-DIR and=20 the ballot comments. In the light of the discussion of your comments, Steffi and I are=20 leaning towards not including them in this draft, since they are of a=20 more general nature and would fit better in a general IoT/CoRE security=20 document. Would that be ok with you? /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 http://www.sics.se --------------ms040104020804090900070304 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 DFQwggYYMIIFAKADAgECAgMMhpgwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYw FAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZp Y2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJt ZWRpYXRlIENsaWVudCBDQTAeFw0xNTAxMDgwODM5MDZaFw0xNjAxMDkyMjQxMzBaMDgxFzAV BgNVBAMMDmx1ZHdpZ0BzaWNzLnNlMR0wGwYJKoZIhvcNAQkBFg5sdWR3aWdAc2ljcy5zZTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMVB4rAuq4FxbARxwRqPLpc/3C194F+V H4XMKK6fu3Y8zDLijzNSjh6tG41oZhXvJcvAs1nZNjUutNLeyBAUFiYhy7HXNdlKpjbMEFKQ +6KpEdZ0Rk+pXgB2E1mqZEfp3M2djcQ/h+7uGVlSGYNAxYk6rWPIIWBx2GMvAQaHP4xxu/F+ PiSQILOVzmtIFZe1t/Lw71aaNeMYVhARo8z5PVsVoq6gBeujxfiRLtiQ/S8xW6RKvNvUkVyT BQfcKaEDZR9FENNf9rFgiAcT6R7hI8RBf1d2fxdlbDU8uM72K3fvzGDt8N9Bfm1kDWbDBxJE 1taRIYs+60D1kwV6DvBb9MECAwEAAaOCAtQwggLQMAkGA1UdEwQCMAAwCwYDVR0PBAQDAgSw MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAdBgNVHQ4EFgQU6ryrKahJtBOEdbIL AAWCpOsQyagwHwYDVR0jBBgwFoAUU3Ltkpzg2ssBXHx+ljVO8tS4UYIwGQYDVR0RBBIwEIEO bHVkd2lnQHNpY3Muc2UwggFMBgNVHSAEggFDMIIBPzCCATsGCysGAQQBgbU3AQIDMIIBKjAu BggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjCB9wYIKwYB BQUHAgIwgeowJxYgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwAwIBARqBvlRo aXMgY2VydGlmaWNhdGUgd2FzIGlzc3VlZCBhY2NvcmRpbmcgdG8gdGhlIENsYXNzIDEgVmFs aWRhdGlvbiByZXF1aXJlbWVudHMgb2YgdGhlIFN0YXJ0Q29tIENBIHBvbGljeSwgcmVsaWFu Y2Ugb25seSBmb3IgdGhlIGludGVuZGVkIHB1cnBvc2UgaW4gY29tcGxpYW5jZSBvZiB0aGUg cmVseWluZyBwYXJ0eSBvYmxpZ2F0aW9ucy4wNgYDVR0fBC8wLTAroCmgJ4YlaHR0cDovL2Ny bC5zdGFydHNzbC5jb20vY3J0dTEtY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEF BQcwAYYtaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczEvY2xpZW50L2NhMEIG CCsGAQUFBzAChjZodHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MxLmNs aWVudC5jYS5jcnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqG SIb3DQEBBQUAA4IBAQBl8BbG0n7+JjFqiJOuAqMbkeqM6Oyd+4oHGu3fbaSiM1SKesae2bfm vifV99a+M4DERZ2SVkOYcvNlv31Q3hvYtzRjDOqewzVKxo021R3ddQULW1DhvTEpclikG5rd 0NRJQn+EkSwEKLeUj68i0dhU8ULhZDDq3A81cTcZzIGrTjNnwDvCktB/sF/iO4At6RJ24P3j KjYFPirW3NsvZ2gzZizSzeubPE0/cWcqEBJ/UtaFPF54efejjLuPRHHMLPDcvrwBhEiBxuG6 oTEo465g4pS9Vo/Z0GoZgZyA+aGQ+YPbPSsqsYmSBjZ6MGGDqQq0niE2dW+8IOdHQvMkqI52 MIIGNDCCBBygAwIBAgIBHjANBgkqhkiG9w0BAQUFADB9MQswCQYDVQQGEwJJTDEWMBQGA1UE ChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUg U2lnbmluZzEpMCcGA1UEAxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwHhcN MDcxMDI0MjEwMTU1WhcNMTcxMDI0MjEwMTU1WjCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoT DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUg Q2xpZW50IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAxwmDzM4t2BqxKaQu E6uWvooyg4ymiEGWVUet1G8SD+rqvyNH4QrvnEIaFHxOhESip7vMz39ScLpNLbL1QpOlPW/t FIzNHS3qd2XRNYG5Sv9RcGE+T4qbLtsjjJbi6sL7Ls/f/X9ftTyhxvxWkf8KW37iKrueKsxw 2HqolH7GM6FX5UfNAwAu4ZifkpmZzU1slBhyWwaQPEPPZRsWoTb7q8hmgv6Nv3Hg9rmA1/VP BIOQ6SKRkHXG0Hhmq1dOFoAFI411+a/9nWm5rcVjGcIWZ2v/43Yksq60jExipA4l5uv9/+Hm 33mbgmCszdj/Dthf13tgAv2O83hLJ0exTqfrlwIDAQABo4IBrTCCAakwDwYDVR0TAQH/BAUw AwEB/zAOBgNVHQ8BAf8EBAMCAQYwHQYDVR0OBBYEFFNy7ZKc4NrLAVx8fpY1TvLUuFGCMB8G A1UdIwQYMBaAFE4L7xqkQFulF2mHMMo0aEPQQa7yMGYGCCsGAQUFBwEBBFowWDAnBggrBgEF BQcwAYYbaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL2NhMC0GCCsGAQUFBzAChiFodHRwOi8v d3d3LnN0YXJ0c3NsLmNvbS9zZnNjYS5jcnQwWwYDVR0fBFQwUjAnoCWgI4YhaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vc2ZzY2EuY3JsMCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNv bS9zZnNjYS5jcmwwgYAGA1UdIAR5MHcwdQYLKwYBBAGBtTcBAgEwZjAuBggrBgEFBQcCARYi aHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEFBQcCARYoaHR0cDov L3d3dy5zdGFydHNzbC5jb20vaW50ZXJtZWRpYXRlLnBkZjANBgkqhkiG9w0BAQUFAAOCAgEA CoMIfXirLAZcuGOMXq4cuSN3TaFx2H2GvD5VSy/6rV55BYHbWNaPeQn3oBSU8KgQZn/Kck1J xbLpAxVCNtsxeW1R87ifhsYZ0qjdrA9anrW2MAWCtosmAOT4OxK9QPoSjCMxM3HbkZCDJgnl E8jMopH21BbyAYr7b5EfGRQJNtgWcvqSXwKHnTutR08+Kkn0KAkXCzeQNLeA5LlYUzFyM7kP Ap8pIRMQ+seHunmyG642S2+y/qHEdMuGIwpfz3eDF1PdctL04qYK/zu+Qg1Bw0RwgigVZs/0 c5HP2/e9DBHh7eSwtzYlk4AUr6yxLlcwSjOfOmKEQ/Q8tzh0IFiNu9IPuTGAPBn4CPxD0+Ru 8T2wg8/s43R/PT3kd1OEqOJUl7q+h+r6fpvU0Fzxd2tC8Ga6fDEPme+1Nbi+03pVjuZQKbGw KJ66gEn06WqaxVZC+J8hh/jR0k9mST1iAZPNYulcNJ8tKmVtjYsv0L1TSm2+NwON58tO+pIV zu3DWwSEXSf+qkDavQam+QtEOZxLBXI++aMUEapSn+k3Lxm48ZCYfAWLb/Xj7F5JQMbZvCex glAbYR0kIHqW5DnsYSdMD/IplJMojx0NBrxJ3fN9dvX2Y6BIXRsF1du4qESm4/3CKuyUV7p9 DW3mPlHTGLvYxnyKQy7VFBkoLINszBrOUeIxggPtMIID6QIBATCBlDCBjDELMAkGA1UEBhMC SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENl cnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJ bnRlcm1lZGlhdGUgQ2xpZW50IENBAgMMhpgwDQYJYIZIAWUDBAIBBQCgggIpMBgGCSqGSIb3 DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE1MTAyMzA4MDQxN1owLwYJKoZI hvcNAQkEMSIEIDCH6KBr6i568JuGqyY+KXj/aMAnYrSP0aQxeMLHHOyLMGwGCSqGSIb3DQEJ DzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0D AgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgaUGCSsGAQQB gjcQBDGBlzCBlDCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzAp BgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0 YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgMMhpgwgacG CyqGSIb3DQEJEAILMYGXoIGUMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20g THRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG A1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EC AwyGmDANBgkqhkiG9w0BAQEFAASCAQBdapznQEdeIPWmLLDu05GWqsiO+dmZdaEUGGi99mcD rrhjfdN6kSnMuChL721dHFfRZHhocRAf3eVK/1uxbHGM3+5OaVgVANiFTToSG+djgO8KDzZP X6DsStYp+lyP0zrQmNDcxYd253SgW8YFot/Oc5No8jjT1PhRxvhHJUg5K+OzSBsB/Jezz/9N xtjoZqkD+s4prCa+TAaozGDYPGQAZXj2SV22Pc62Cd4qshTE8bGqiIH3CWYyMpeSpunPQyVC hUTihrEGu3fXA7EBOxoz5Ek6MaltCIoeTj27EUUKPoFUUyY6MlborB97PLs3O2TyrVzyLg6F AU1ZWdWkGD3IAAAAAAAA --------------ms040104020804090900070304-- From nobody Fri Oct 23 01:25:00 2015 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC8CC1B3303 for ; Fri, 23 Oct 2015 01:24:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 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_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rGU07wtwDVCi for ; Fri, 23 Oct 2015 01:24:55 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 35D281B32F9 for ; Fri, 23 Oct 2015 01:24:55 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id D926CBE50; Fri, 23 Oct 2015 09:24:52 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mULmOPZlvsGG; Fri, 23 Oct 2015 09:24:51 +0100 (IST) Received: from [10.87.48.91] (unknown [86.46.30.221]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id BA953BE4D; Fri, 23 Oct 2015 09:24:50 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1445588691; bh=7nyCIwka0d2CnZyCSB4IyUdrzodEWLi+FyFvojqmvyc=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=aOt+ICOypJuNW7wntrxt44t64FFD7o9McaeRcsgbnCSWUCpvS7St1qTgtvjR8ffQU F5qBtojeys5dk76wKhOr1OEtjAkv71+wKmGpFJg8G6DejwZ8BpVElBW4KbQ3T+N9F0 WgnNhgKpHtUDjee4aT9uX2H9nvk02RJaIwohYFaE= To: Ludwig Seitz References: <20151022132903.23826.2689.idtracker@ietfa.amsl.com> <5629EA01.6020506@sics.se> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <5629EED2.5080005@cs.tcd.ie> Date: Fri, 23 Oct 2015 09:24:50 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <5629EA01.6020506@sics.se> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: ace@ietf.org Subject: Re: [Ace] Stephen Farrell's Yes on draft-ietf-ace-usecases-09: (with COMMENT) X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Oct 2015 08:24:58 -0000 Hiya, On 23/10/15 09:04, Ludwig Seitz wrote: > On 2015-10-22 15:29, Stephen Farrell wrote: > [...] >> >> 1. Software update is really needed and often missing and >> usually hard. There's at least a need to authenticate and >> authorize new firmware, when there is any update. That may not >> be the same as authorizing a new config. >> >> 2. Alice buys a new device, and would like to know if it is >> calling home or what it is doing before she configures it, or >> perhaps before she accepts it in her network. Even if she >> accepts it, she may want to be able to monitor the data it >> is sending "home" e.g. to ensure her TV is not sending >> data when she inserts a USB stick, if that is undesired. >> >> 3. Device fingerprinting is a threat that ought be considered >> by solution developers, especially if there is no reliable >> software update. Probably the best to be done is to try to >> make it hard for unauthorized parties to fingerprint a device, >> but that's also hard. >> >> 4. Commercial Devices will be end-of-lifed by vendors, and yet >> Alice still needs to be able to use, and perhaos to update, >> the device. That calls for some kind of authorization handover >> which is not quite the same as a change of ownership. >> >> 5. Penetration testing will happen and devices should not barf >> even then. Maybe that's a security consideration worth a >> mention. >> >> See also the secdir review. [1] It'd be good to see a >> response to that. >> >> [1] >> https://www.ietf.org/mail-archive/web/secdir/current/msg06101.html >> > > Hi Stephen, > > Thank you for your comments! > > We are making final adjustments to the document based on the *-DIR and > the ballot comments. > > In the light of the discussion of your comments, Steffi and I are > leaning towards not including them in this draft, since they are of a > more general nature and would fit better in a general IoT/CoRE security > document. > > Would that be ok with you? That is ok, but I disagree of course:-) I do think there are ace-specific use-cases arising from the above. But I can fully understand not wanting to take on such additions at this stage as well. S > > > /Ludwig > > > From nobody Fri Oct 23 05:37:27 2015 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7F7A1B35B0 for ; Fri, 23 Oct 2015 05:37:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ova7rwiECyOa for ; Fri, 23 Oct 2015 05:37:25 -0700 (PDT) Received: from mail-wi0-x229.google.com (mail-wi0-x229.google.com [IPv6:2a00:1450:400c:c05::229]) (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 B35561B35A2 for ; Fri, 23 Oct 2015 05:37:24 -0700 (PDT) Received: by wijp11 with SMTP id p11so75493427wij.0 for ; Fri, 23 Oct 2015 05:37:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=tAxAeL+LBqatp8wRrP721z4RReKmkM0vuTt2xuyWA6g=; b=XCF5f4s89IXIYQ7YusRWwnZHNzfVVUSwbMxce0Ee2K5lQDHmgerzX870AVN8OV9i6J viy3B7zjf5sbont07rfJRI4pFnmxDSJ1koyyAs94a4yShc2tqswjH+ufgaAVncNA62hL f5P9RnVlNRXM+s3wBBU4m9Mdnum3Yy0+BCkHtvaCdekSAJY4DUed7f9/biQCSQSPRZrf pIeSJvoVA6iltChmxOmq/3MveddEjIJZE6MRWXC+EAyK/3s/VtN0/+OIhKdnetvTEU5d yjrK8LyQxhAAbI/dZsGZte3HhYVVaeJyMiMe3p/NeSnHivKVsMkkvMcFUISjxP0vz/U5 rULw== MIME-Version: 1.0 X-Received: by 10.180.36.15 with SMTP id m15mr4022735wij.90.1445603843255; Fri, 23 Oct 2015 05:37:23 -0700 (PDT) Received: by 10.28.214.142 with HTTP; Fri, 23 Oct 2015 05:37:23 -0700 (PDT) In-Reply-To: <5629EED2.5080005@cs.tcd.ie> References: <20151022132903.23826.2689.idtracker@ietfa.amsl.com> <5629EA01.6020506@sics.se> <5629EED2.5080005@cs.tcd.ie> Date: Fri, 23 Oct 2015 08:37:23 -0400 Message-ID: From: Kathleen Moriarty To: Stephen Farrell Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Ludwig Seitz , "ace@ietf.org" Subject: Re: [Ace] Stephen Farrell's Yes on draft-ietf-ace-usecases-09: (with COMMENT) X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Oct 2015 12:37:26 -0000 I just went through Stephen's comments again before approving the draft, and I do think his first comment should be added in since it is specific to authentication and authorization. Is there a place this can fit in nicely? The problem he calls out is one that has been a thorn in the side for vendors of other products (not constrained), so it would be good to require updates to be authenticated and authorized. SUpply chain attacks are easier when these measures are not in place. A possible scenario (derived from real world events) is that you could manufacture a knock off and have it use a specific vendors firmware in an update without this protection in place. It would be appropriate to have this in a general document, but since this is authentication and authorization focused, it would be good to see it here as well. This is a very well written document and may get more not-as-technical readers using it for education, so it would be a shame to leave this out and get burned by it later. It might not be in scope for ACE, but you can also just state that so the concern is known. Thank you, Kathleen On Fri, Oct 23, 2015 at 4:24 AM, Stephen Farrell wrote: > > Hiya, > > On 23/10/15 09:04, Ludwig Seitz wrote: >> On 2015-10-22 15:29, Stephen Farrell wrote: >> [...] >>> >>> 1. Software update is really needed and often missing and >>> usually hard. There's at least a need to authenticate and >>> authorize new firmware, when there is any update. That may not >>> be the same as authorizing a new config. >>> >>> 2. Alice buys a new device, and would like to know if it is >>> calling home or what it is doing before she configures it, or >>> perhaps before she accepts it in her network. Even if she >>> accepts it, she may want to be able to monitor the data it >>> is sending "home" e.g. to ensure her TV is not sending >>> data when she inserts a USB stick, if that is undesired. >>> >>> 3. Device fingerprinting is a threat that ought be considered >>> by solution developers, especially if there is no reliable >>> software update. Probably the best to be done is to try to >>> make it hard for unauthorized parties to fingerprint a device, >>> but that's also hard. >>> >>> 4. Commercial Devices will be end-of-lifed by vendors, and yet >>> Alice still needs to be able to use, and perhaos to update, >>> the device. That calls for some kind of authorization handover >>> which is not quite the same as a change of ownership. >>> >>> 5. Penetration testing will happen and devices should not barf >>> even then. Maybe that's a security consideration worth a >>> mention. >>> >>> See also the secdir review. [1] It'd be good to see a >>> response to that. >>> >>> [1] >>> https://www.ietf.org/mail-archive/web/secdir/current/msg06101.html >>> >> >> Hi Stephen, >> >> Thank you for your comments! >> >> We are making final adjustments to the document based on the *-DIR and >> the ballot comments. >> >> In the light of the discussion of your comments, Steffi and I are >> leaning towards not including them in this draft, since they are of a >> more general nature and would fit better in a general IoT/CoRE security >> document. >> >> Would that be ok with you? > > That is ok, but I disagree of course:-) > > I do think there are ace-specific use-cases arising from > the above. But I can fully understand not wanting to take > on such additions at this stage as well. > > S > >> >> >> /Ludwig >> >> >> > > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace -- Best regards, Kathleen From nobody Fri Oct 23 06:29:50 2015 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67B151A00F4 for ; Fri, 23 Oct 2015 06:29:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lbEm8bjBVzCe for ; Fri, 23 Oct 2015 06:29:47 -0700 (PDT) Received: from mail-lf0-x232.google.com (mail-lf0-x232.google.com [IPv6:2a00:1450:4010:c07::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D6291A00F5 for ; Fri, 23 Oct 2015 06:29:47 -0700 (PDT) Received: by lffz202 with SMTP id z202so83708116lff.3 for ; Fri, 23 Oct 2015 06:29:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sics_se.20150623.gappssmtp.com; s=20150623; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-type; bh=ZO3zuDKfs+dAWdE9DTgwzwcQm6NJLyLxFZkDPGtTZhY=; b=SpInB3F/1glhZeFwN3TIIqef9xDpyiFYGileOTBh51QxRZ/AOVxRP7i7xXLFanP5tF QUPHWcmyl4hSZFIrFJ0OxoWzzFLc4f4QfZmLhy4w+NpzTIiwU2+1n3XRrj3gqwRC0F06 0jxctFIBeYx92AzSb/V/TGdgsG0vDfy1dL0htNC5NspYgRnthcTTGJ8DSy3rEts8qXW6 NsvPMy4Wo9ljoenSb4MGc84MD2JW/uwIPaAlfRTJFQCPNp4yCm1wPPiRQBTVzYHtDOdQ HVysVZh5CPLv8DwDnrm4O1cD+Q49anKctI1lnxyfFrnbpMsPKRakP441gnm05lABKImP Rnzg== 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:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-type; bh=ZO3zuDKfs+dAWdE9DTgwzwcQm6NJLyLxFZkDPGtTZhY=; b=TLm1wywfotb2KiDvnXao2MZ3J4oeI4U144tG8mhKrr95MLGP3cy3kBFAVVcFs0zB6u C0qU+c5Uqeh7ymgqsTKHxfjTL0hsqAnV2ayxIB1R+lAtvpcCFR6+NNasjsVkhdFwJAZR SCgPfyLJ8bTfOv0ahYw6PwgvJ/xJJIQTkcCuulsUoa4eFu5KJKuUUD1IWeWxJUAgc2x0 eT4/Q7p0uhdZJypdF6XCPcrTqw/NiUaxkIWtIxKU/5gxetuSGkmB4DYUr9AHwclRs/A3 Nail+ezdAgRtVfANB06tcKYVxY2ZjOP4pCFaFxNZId1xgdrIGV6wTsoBjKR1VQJJYJWp Sg4w== X-Gm-Message-State: ALoCoQnOI7KpHPY/L+9azM7Mupf+XjS6z8e0rVdKG90+V/e1C91Lz7LEZSwmX1Es5wOKduTFmslW X-Received: by 10.112.156.193 with SMTP id wg1mr10976184lbb.24.1445606985079; Fri, 23 Oct 2015 06:29:45 -0700 (PDT) Received: from [192.168.0.108] ([85.235.11.178]) by smtp.gmail.com with ESMTPSA id e138sm3305147lfg.36.2015.10.23.06.29.43 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 23 Oct 2015 06:29:44 -0700 (PDT) To: Kathleen Moriarty , Stephen Farrell References: <20151022132903.23826.2689.idtracker@ietfa.amsl.com> <5629EA01.6020506@sics.se> <5629EED2.5080005@cs.tcd.ie> From: Ludwig Seitz Message-ID: <562A3647.3030101@sics.se> Date: Fri, 23 Oct 2015 15:29:43 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms050605050307070000050507" Archived-At: Cc: "ace@ietf.org" Subject: Re: [Ace] Stephen Farrell's Yes on draft-ietf-ace-usecases-09: (with COMMENT) X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Oct 2015 13:29:49 -0000 This is a cryptographically signed message in MIME format. --------------ms050605050307070000050507 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable On 2015-10-23 14:37, Kathleen Moriarty wrote: > I just went through Stephen's comments again before approving the > draft, and I do think his first comment should be added in since it is > specific to authentication and authorization. Is there a place this > can fit in nicely? > >[....] > > Thank you, > Kathleen > > [...] >> 1. Software update is really needed and often missing and >> usually hard. There's at least a need to authenticate and >> authorize new firmware, when there is any update. That may not >> be the same as authorizing a new config. Isn't this covered in section 2.4.1.3. ? "At some point the facility management company wants to update the firmware of lighting devices in order to eliminate software bugs. Before accepting the new firmware, each device checks the authorization of the facility management company to perform this update." There is simply not a specific authorization problem listed for this, I=20 could argue that it is subsumed under U4.4 but if you think it deserves=20 specific mention under the problems section I can live with adding a poin= t. /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 http://www.sics.se --------------ms050605050307070000050507 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 DFQwggYYMIIFAKADAgECAgMMhpgwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYw FAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZp Y2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJt ZWRpYXRlIENsaWVudCBDQTAeFw0xNTAxMDgwODM5MDZaFw0xNjAxMDkyMjQxMzBaMDgxFzAV BgNVBAMMDmx1ZHdpZ0BzaWNzLnNlMR0wGwYJKoZIhvcNAQkBFg5sdWR3aWdAc2ljcy5zZTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMVB4rAuq4FxbARxwRqPLpc/3C194F+V H4XMKK6fu3Y8zDLijzNSjh6tG41oZhXvJcvAs1nZNjUutNLeyBAUFiYhy7HXNdlKpjbMEFKQ +6KpEdZ0Rk+pXgB2E1mqZEfp3M2djcQ/h+7uGVlSGYNAxYk6rWPIIWBx2GMvAQaHP4xxu/F+ PiSQILOVzmtIFZe1t/Lw71aaNeMYVhARo8z5PVsVoq6gBeujxfiRLtiQ/S8xW6RKvNvUkVyT BQfcKaEDZR9FENNf9rFgiAcT6R7hI8RBf1d2fxdlbDU8uM72K3fvzGDt8N9Bfm1kDWbDBxJE 1taRIYs+60D1kwV6DvBb9MECAwEAAaOCAtQwggLQMAkGA1UdEwQCMAAwCwYDVR0PBAQDAgSw MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAdBgNVHQ4EFgQU6ryrKahJtBOEdbIL AAWCpOsQyagwHwYDVR0jBBgwFoAUU3Ltkpzg2ssBXHx+ljVO8tS4UYIwGQYDVR0RBBIwEIEO bHVkd2lnQHNpY3Muc2UwggFMBgNVHSAEggFDMIIBPzCCATsGCysGAQQBgbU3AQIDMIIBKjAu BggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjCB9wYIKwYB BQUHAgIwgeowJxYgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwAwIBARqBvlRo aXMgY2VydGlmaWNhdGUgd2FzIGlzc3VlZCBhY2NvcmRpbmcgdG8gdGhlIENsYXNzIDEgVmFs aWRhdGlvbiByZXF1aXJlbWVudHMgb2YgdGhlIFN0YXJ0Q29tIENBIHBvbGljeSwgcmVsaWFu Y2Ugb25seSBmb3IgdGhlIGludGVuZGVkIHB1cnBvc2UgaW4gY29tcGxpYW5jZSBvZiB0aGUg cmVseWluZyBwYXJ0eSBvYmxpZ2F0aW9ucy4wNgYDVR0fBC8wLTAroCmgJ4YlaHR0cDovL2Ny bC5zdGFydHNzbC5jb20vY3J0dTEtY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEF BQcwAYYtaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczEvY2xpZW50L2NhMEIG CCsGAQUFBzAChjZodHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MxLmNs aWVudC5jYS5jcnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqG SIb3DQEBBQUAA4IBAQBl8BbG0n7+JjFqiJOuAqMbkeqM6Oyd+4oHGu3fbaSiM1SKesae2bfm vifV99a+M4DERZ2SVkOYcvNlv31Q3hvYtzRjDOqewzVKxo021R3ddQULW1DhvTEpclikG5rd 0NRJQn+EkSwEKLeUj68i0dhU8ULhZDDq3A81cTcZzIGrTjNnwDvCktB/sF/iO4At6RJ24P3j KjYFPirW3NsvZ2gzZizSzeubPE0/cWcqEBJ/UtaFPF54efejjLuPRHHMLPDcvrwBhEiBxuG6 oTEo465g4pS9Vo/Z0GoZgZyA+aGQ+YPbPSsqsYmSBjZ6MGGDqQq0niE2dW+8IOdHQvMkqI52 MIIGNDCCBBygAwIBAgIBHjANBgkqhkiG9w0BAQUFADB9MQswCQYDVQQGEwJJTDEWMBQGA1UE ChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUg U2lnbmluZzEpMCcGA1UEAxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwHhcN MDcxMDI0MjEwMTU1WhcNMTcxMDI0MjEwMTU1WjCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoT DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUg Q2xpZW50IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAxwmDzM4t2BqxKaQu E6uWvooyg4ymiEGWVUet1G8SD+rqvyNH4QrvnEIaFHxOhESip7vMz39ScLpNLbL1QpOlPW/t FIzNHS3qd2XRNYG5Sv9RcGE+T4qbLtsjjJbi6sL7Ls/f/X9ftTyhxvxWkf8KW37iKrueKsxw 2HqolH7GM6FX5UfNAwAu4ZifkpmZzU1slBhyWwaQPEPPZRsWoTb7q8hmgv6Nv3Hg9rmA1/VP BIOQ6SKRkHXG0Hhmq1dOFoAFI411+a/9nWm5rcVjGcIWZ2v/43Yksq60jExipA4l5uv9/+Hm 33mbgmCszdj/Dthf13tgAv2O83hLJ0exTqfrlwIDAQABo4IBrTCCAakwDwYDVR0TAQH/BAUw AwEB/zAOBgNVHQ8BAf8EBAMCAQYwHQYDVR0OBBYEFFNy7ZKc4NrLAVx8fpY1TvLUuFGCMB8G A1UdIwQYMBaAFE4L7xqkQFulF2mHMMo0aEPQQa7yMGYGCCsGAQUFBwEBBFowWDAnBggrBgEF BQcwAYYbaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL2NhMC0GCCsGAQUFBzAChiFodHRwOi8v d3d3LnN0YXJ0c3NsLmNvbS9zZnNjYS5jcnQwWwYDVR0fBFQwUjAnoCWgI4YhaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vc2ZzY2EuY3JsMCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNv bS9zZnNjYS5jcmwwgYAGA1UdIAR5MHcwdQYLKwYBBAGBtTcBAgEwZjAuBggrBgEFBQcCARYi aHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEFBQcCARYoaHR0cDov L3d3dy5zdGFydHNzbC5jb20vaW50ZXJtZWRpYXRlLnBkZjANBgkqhkiG9w0BAQUFAAOCAgEA CoMIfXirLAZcuGOMXq4cuSN3TaFx2H2GvD5VSy/6rV55BYHbWNaPeQn3oBSU8KgQZn/Kck1J xbLpAxVCNtsxeW1R87ifhsYZ0qjdrA9anrW2MAWCtosmAOT4OxK9QPoSjCMxM3HbkZCDJgnl E8jMopH21BbyAYr7b5EfGRQJNtgWcvqSXwKHnTutR08+Kkn0KAkXCzeQNLeA5LlYUzFyM7kP Ap8pIRMQ+seHunmyG642S2+y/qHEdMuGIwpfz3eDF1PdctL04qYK/zu+Qg1Bw0RwgigVZs/0 c5HP2/e9DBHh7eSwtzYlk4AUr6yxLlcwSjOfOmKEQ/Q8tzh0IFiNu9IPuTGAPBn4CPxD0+Ru 8T2wg8/s43R/PT3kd1OEqOJUl7q+h+r6fpvU0Fzxd2tC8Ga6fDEPme+1Nbi+03pVjuZQKbGw KJ66gEn06WqaxVZC+J8hh/jR0k9mST1iAZPNYulcNJ8tKmVtjYsv0L1TSm2+NwON58tO+pIV zu3DWwSEXSf+qkDavQam+QtEOZxLBXI++aMUEapSn+k3Lxm48ZCYfAWLb/Xj7F5JQMbZvCex glAbYR0kIHqW5DnsYSdMD/IplJMojx0NBrxJ3fN9dvX2Y6BIXRsF1du4qESm4/3CKuyUV7p9 DW3mPlHTGLvYxnyKQy7VFBkoLINszBrOUeIxggPtMIID6QIBATCBlDCBjDELMAkGA1UEBhMC SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENl cnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJ bnRlcm1lZGlhdGUgQ2xpZW50IENBAgMMhpgwDQYJYIZIAWUDBAIBBQCgggIpMBgGCSqGSIb3 DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE1MTAyMzEzMjk0M1owLwYJKoZI hvcNAQkEMSIEIKkfHtwtjGWSSTxLjLFODHo/mmpARbSdXf2jOxjyg2DjMGwGCSqGSIb3DQEJ DzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0D AgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgaUGCSsGAQQB gjcQBDGBlzCBlDCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzAp BgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0 YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgMMhpgwgacG CyqGSIb3DQEJEAILMYGXoIGUMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20g THRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG A1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EC AwyGmDANBgkqhkiG9w0BAQEFAASCAQAFoSvNwYB+cHeIFFAeSIDsjSr2avYpwh9jwsS55Ypa RVAQNT99+d9QwCMC+FMdU+B7HdqDTtZ0xJ39QpCkanaIZOMdLMBCY01JkgyejTkWyCbizvfg Fu67Si6QryxBwRA1UXroclxkYxM9TXAoEM0JCYADmPcCDxxuz8YV+8rrp+J00V9E/X6EM/pM S9VhbthqM5fsJNqlh1kTTbjw5Tyg1iUfrtmun4GDvfBKht1fZPB8B1sQxD1C0413flTTnMtL PhiepEJQn6lzTzimM7kPyVC5VxaWdswiojouVe1HNWxE2HX56ZdgQpJ0P+AoeMpN1II3uB0v P+vGLdOt4XfVAAAAAAAA --------------ms050605050307070000050507-- From nobody Fri Oct 23 07:58:24 2015 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 474B41A1BEC for ; Fri, 23 Oct 2015 07:58:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.55 X-Spam-Level: X-Spam-Status: No, score=-1.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wc86EztJCbYP for ; Fri, 23 Oct 2015 07:58:21 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AB09E1A1BE9 for ; Fri, 23 Oct 2015 07:58:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [134.102.201.11]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id t9NEwFdD013702; Fri, 23 Oct 2015 16:58:15 +0200 (CEST) Received: from [192.168.1.109] (pD9F6184A.dip0.t-ipconnect.de [217.246.24.74]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3nj7wR3VdszHy06; Fri, 23 Oct 2015 16:58:15 +0200 (CEST) To: Ludwig Seitz , Kathleen Moriarty , Stephen Farrell References: <20151022132903.23826.2689.idtracker@ietfa.amsl.com> <5629EA01.6020506@sics.se> <5629EED2.5080005@cs.tcd.ie> <562A3647.3030101@sics.se> From: Stefanie Gerdes X-Enigmail-Draft-Status: N1110 Message-ID: <562A4B07.9080305@tzi.de> Date: Fri, 23 Oct 2015 16:58:15 +0200 User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <562A3647.3030101@sics.se> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Cc: "ace@ietf.org" Subject: Re: [Ace] Stephen Farrell's Yes on draft-ietf-ace-usecases-09: (with COMMENT) X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Oct 2015 14:58:22 -0000 Hi all, >>> 1. Software update is really needed and often missing and >>> usually hard. There's at least a need to authenticate and >>> authorize new firmware, when there is any update. That may not >>> be the same as authorizing a new config. > > > Isn't this covered in section 2.4.1.3. ? > > "At some point the facility management company wants to update the > firmware of lighting devices in order to eliminate software bugs. > Before accepting the new firmware, each device checks the > authorization of the facility management company to perform this > update." > > There is simply not a specific authorization problem listed for this, I > could argue that it is subsumed under U4.4 but if you think it deserves > specific mention under the problems section I can live with adding a point. > I think adding a point in 2.4.3 is a good idea. We could also add an item to 3.3 that emphasizes the problem. Thanks, Steffi From nobody Fri Oct 23 08:21:59 2015 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 920A81A1C02 for ; Fri, 23 Oct 2015 08:21:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z3OZudJQnFWC for ; Fri, 23 Oct 2015 08:21:48 -0700 (PDT) Received: from mail-qg0-x22e.google.com (mail-qg0-x22e.google.com [IPv6:2607:f8b0:400d:c04::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 A4DE51A1EF6 for ; Fri, 23 Oct 2015 08:21:47 -0700 (PDT) Received: by qgad10 with SMTP id d10so73389488qga.3 for ; Fri, 23 Oct 2015 08:21:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:mime-version:subject:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=T+0+PWOCLLfEmW2GXbx9D24Am2XBuvtJpHUc1tpAr/U=; b=JlqucZGLJEOiT3jpCrN/7NMPYcG71AfaLvWd3eb/7e6UeaLf+jQWCG610XUVxBf3kn v/Jk3v6a00RN3RFxR2Q9FfBFRVb7EkpfiIgI1tqFRExvjE7Y7iEOqapo3/z1nibsw6fh oAFLTW5oWOy4TU8QYYbEXE047ZGA8VdNGzlK/6PZmLJ/8oSblpz9JqoKb1lZ1j0lHM2X Br4ZYxmNmS23Kn7b7z4PI5L9dIWka9hd5NCQIANr9P/jwLi/5Z9lwvu8qGqT4d1vyER0 poimyrSRqS4dhzzWRWAv8mMvLyYGyjycEe9sLF0pABwmlLu4e8WfqpDJUTZ2FNpyADUW uXEw== X-Received: by 10.140.39.199 with SMTP id v65mr2350487qgv.34.1445613706854; Fri, 23 Oct 2015 08:21:46 -0700 (PDT) Received: from [192.168.1.3] (209-6-114-252.c3-0.arl-ubr1.sbo-arl.ma.cable.rcn.com. [209.6.114.252]) by smtp.gmail.com with ESMTPSA id k201sm7011638qhc.34.2015.10.23.08.21.45 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 23 Oct 2015 08:21:45 -0700 (PDT) From: Kathleen Moriarty X-Google-Original-From: Kathleen Moriarty Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) X-Mailer: iPhone Mail (12H143) In-Reply-To: <562A4B07.9080305@tzi.de> Date: Fri, 23 Oct 2015 11:21:44 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <6E79B71B-FBE1-4FB6-B9B9-16E6C44C67BA@gmail.com> References: <20151022132903.23826.2689.idtracker@ietfa.amsl.com> <5629EA01.6020506@sics.se> <5629EED2.5080005@cs.tcd.ie> <562A3647.3030101@sics.se> <562A4B07.9080305@tzi.de> To: Stefanie Gerdes Archived-At: Cc: "ace@ietf.org" , Ludwig Seitz , Stephen Farrell Subject: Re: [Ace] Stephen Farrell's Yes on draft-ietf-ace-usecases-09: (with COMMENT) X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Oct 2015 15:21:54 -0000 Sent from my iPhone > On Oct 23, 2015, at 10:58 AM, Stefanie Gerdes wrote: >=20 > Hi all, >=20 >>>> 1. Software update is really needed and often missing and >>>> usually hard. There's at least a need to authenticate and >>>> authorize new firmware, when there is any update. That may not >>>> be the same as authorizing a new config. >>=20 >>=20 >> Isn't this covered in section 2.4.1.3. ? >>=20 >> "At some point the facility management company wants to update the >> firmware of lighting devices in order to eliminate software bugs. >> Before accepting the new firmware, each device checks the >> authorization of the facility management company to perform this >> update." >>=20 >> There is simply not a specific authorization problem listed for this, I >> could argue that it is subsumed under U4.4 but if you think it deserves >> specific mention under the problems section I can live with adding a poin= t. >=20 > I think adding a point in 2.4.3 is a good idea. We could also add an > item to 3.3 that emphasizes the problem. >=20 Great, I think adding a point would be helpful. You'd be authenticating the= device to receive the update preventing fraud, which is different from the e= xisting point referenced. Thanks, Kathleen=20 > Thanks, > Steffi From nobody Mon Oct 26 00:39:54 2015 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF66B1AD277 for ; Mon, 26 Oct 2015 00:39:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LBwjzqw3LhNn for ; Mon, 26 Oct 2015 00:39:50 -0700 (PDT) Received: from mail-lf0-x235.google.com (mail-lf0-x235.google.com [IPv6:2a00:1450:4010:c07::235]) (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 458F31AD26B for ; Mon, 26 Oct 2015 00:39:50 -0700 (PDT) Received: by lfaz124 with SMTP id z124so138038716lfa.1 for ; Mon, 26 Oct 2015 00:39:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sics_se.20150623.gappssmtp.com; s=20150623; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-type; bh=zW96W5w5uRXKwxm3LEY72IXNQbkqFoAjwzb4sRlq3po=; b=iHx8yBim4Rsz259HLdPjD6lTNmLAVx5a22WlNUmdU/LLy8vyPnQcE+2uEhnkdEDPfM 4CWm0R5+hErcAJSEUTxMhjAxcnzTI92i3W8AiRDMbF6cExLd70JenVU8sRdFRaA5re0o r0UUIBLw8v+m28sZzwQOLnA8rKq87lmUxJ0ashzJlRssk542O/tShcM3gMZxC0bgwu1X T5OM/gsOfpUJYZoA6TMDdYnf/xASwpgQiLecYHgEyj6NrxSmUx9t+VSxd18Z3xChBh6m B693fXiCoL0dSPCn3uRAMUs+AIiqWhw2OzAmb7ahc489OUc9D0WCkDi8oVLi7MYZErRB SAXA== 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:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-type; bh=zW96W5w5uRXKwxm3LEY72IXNQbkqFoAjwzb4sRlq3po=; b=D4fuJ9H6skhXR8Y4dVFWTpeyPEA4QKSrQ1TyKM7l6uw/koyN6gB+olAOUItuwXBkLB eTADvFTCVuqYz0ljPu6iyV8uf+bI3LgZrlJNwCEa0Z4eFOwJhLUeRwI+RUemtZ6BW3qC jSC6mk+TFpF0ZlYw6KdbjXYC6S9Oy1fhD9DmgMF8KcXJRCYqlQ6ggoK87z2JWL/hRtsF u8UYmJ81EJlD0P9DKsr8aiSFFI+ixPwEdya5k2DI3zLeezswPTTRsihnShuvdICkZLCe q0IY7Ba+Jr6XfXvw41NrRLosu7VTaiebigvm0Cy+PMn4yPuLLiiE++Irdz66B0jUWqCQ Rjcg== X-Gm-Message-State: ALoCoQloTx2KJrTuZ2qQD5/C215oiz895qcGYCmdRZT2KK5JaRiRIiJetViMxpXqfQONAeOYdiCI X-Received: by 10.112.16.164 with SMTP id h4mr3645661lbd.63.1445845188220; Mon, 26 Oct 2015 00:39:48 -0700 (PDT) Received: from [192.168.0.108] ([85.235.11.178]) by smtp.gmail.com with ESMTPSA id w143sm5800920lfd.2.2015.10.26.00.39.46 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 26 Oct 2015 00:39:47 -0700 (PDT) To: Kathleen Moriarty References: <20151022132903.23826.2689.idtracker@ietfa.amsl.com> <5629EA01.6020506@sics.se> <5629EED2.5080005@cs.tcd.ie> <562A3647.3030101@sics.se> <562A4B07.9080305@tzi.de> <6E79B71B-FBE1-4FB6-B9B9-16E6C44C67BA@gmail.com> From: Ludwig Seitz Message-ID: <562DD8C2.3020508@sics.se> Date: Mon, 26 Oct 2015 08:39:46 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <6E79B71B-FBE1-4FB6-B9B9-16E6C44C67BA@gmail.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms010004050500030203080906" Archived-At: Cc: Stefanie Gerdes , "ace@ietf.org" , Stephen Farrell Subject: Re: [Ace] Stephen Farrell's Yes on draft-ietf-ace-usecases-09: (with COMMENT) X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 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 Oct 2015 07:39:53 -0000 This is a cryptographically signed message in MIME format. --------------ms010004050500030203080906 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable On 2015-10-23 17:21, Kathleen Moriarty wrote: > > > Sent from my iPhone > >> On Oct 23, 2015, at 10:58 AM, Stefanie Gerdes >> wrote: >> >> Hi all, >> >>>>> 1. Software update is really needed and often missing and >>>>> usually hard. There's at least a need to authenticate and >>>>> authorize new firmware, when there is any update. That may >>>>> not be the same as authorizing a new config. >>> >>> >>> Isn't this covered in section 2.4.1.3. ? >>> >>> "At some point the facility management company wants to update >>> the firmware of lighting devices in order to eliminate software >>> bugs. Before accepting the new firmware, each device checks the >>> authorization of the facility management company to perform this >>> update." >>> >>> There is simply not a specific authorization problem listed for >>> this, I could argue that it is subsumed under U4.4 but if you >>> think it deserves specific mention under the problems section I >>> can live with adding a point. >> >> I think adding a point in 2.4.3 is a good idea. We could also add >> an item to 3.3 that emphasizes the problem. >> > > Great, I think adding a point would be helpful. You'd be > authenticating the device to receive the update preventing fraud, > which is different from the existing point referenced. > Hello Kathleen, I'm a bit puzzled by this last sentence. That is not at all how I read=20 Stephen's comment, which was, in my understanding, all about=20 authenticating and authorizing the software update, not the receiver of=20 the update. Now obviously, authenticating the receiver of a software update is not a = bad idea either, but do you think this also requires specific mention? /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 http://www.sics.se --------------ms010004050500030203080906 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 DFQwggYYMIIFAKADAgECAgMMhpgwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYw FAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZp Y2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJt ZWRpYXRlIENsaWVudCBDQTAeFw0xNTAxMDgwODM5MDZaFw0xNjAxMDkyMjQxMzBaMDgxFzAV BgNVBAMMDmx1ZHdpZ0BzaWNzLnNlMR0wGwYJKoZIhvcNAQkBFg5sdWR3aWdAc2ljcy5zZTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMVB4rAuq4FxbARxwRqPLpc/3C194F+V H4XMKK6fu3Y8zDLijzNSjh6tG41oZhXvJcvAs1nZNjUutNLeyBAUFiYhy7HXNdlKpjbMEFKQ +6KpEdZ0Rk+pXgB2E1mqZEfp3M2djcQ/h+7uGVlSGYNAxYk6rWPIIWBx2GMvAQaHP4xxu/F+ PiSQILOVzmtIFZe1t/Lw71aaNeMYVhARo8z5PVsVoq6gBeujxfiRLtiQ/S8xW6RKvNvUkVyT BQfcKaEDZR9FENNf9rFgiAcT6R7hI8RBf1d2fxdlbDU8uM72K3fvzGDt8N9Bfm1kDWbDBxJE 1taRIYs+60D1kwV6DvBb9MECAwEAAaOCAtQwggLQMAkGA1UdEwQCMAAwCwYDVR0PBAQDAgSw MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAdBgNVHQ4EFgQU6ryrKahJtBOEdbIL AAWCpOsQyagwHwYDVR0jBBgwFoAUU3Ltkpzg2ssBXHx+ljVO8tS4UYIwGQYDVR0RBBIwEIEO bHVkd2lnQHNpY3Muc2UwggFMBgNVHSAEggFDMIIBPzCCATsGCysGAQQBgbU3AQIDMIIBKjAu BggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjCB9wYIKwYB BQUHAgIwgeowJxYgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwAwIBARqBvlRo aXMgY2VydGlmaWNhdGUgd2FzIGlzc3VlZCBhY2NvcmRpbmcgdG8gdGhlIENsYXNzIDEgVmFs aWRhdGlvbiByZXF1aXJlbWVudHMgb2YgdGhlIFN0YXJ0Q29tIENBIHBvbGljeSwgcmVsaWFu Y2Ugb25seSBmb3IgdGhlIGludGVuZGVkIHB1cnBvc2UgaW4gY29tcGxpYW5jZSBvZiB0aGUg cmVseWluZyBwYXJ0eSBvYmxpZ2F0aW9ucy4wNgYDVR0fBC8wLTAroCmgJ4YlaHR0cDovL2Ny bC5zdGFydHNzbC5jb20vY3J0dTEtY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEF BQcwAYYtaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczEvY2xpZW50L2NhMEIG CCsGAQUFBzAChjZodHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MxLmNs aWVudC5jYS5jcnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqG SIb3DQEBBQUAA4IBAQBl8BbG0n7+JjFqiJOuAqMbkeqM6Oyd+4oHGu3fbaSiM1SKesae2bfm vifV99a+M4DERZ2SVkOYcvNlv31Q3hvYtzRjDOqewzVKxo021R3ddQULW1DhvTEpclikG5rd 0NRJQn+EkSwEKLeUj68i0dhU8ULhZDDq3A81cTcZzIGrTjNnwDvCktB/sF/iO4At6RJ24P3j KjYFPirW3NsvZ2gzZizSzeubPE0/cWcqEBJ/UtaFPF54efejjLuPRHHMLPDcvrwBhEiBxuG6 oTEo465g4pS9Vo/Z0GoZgZyA+aGQ+YPbPSsqsYmSBjZ6MGGDqQq0niE2dW+8IOdHQvMkqI52 MIIGNDCCBBygAwIBAgIBHjANBgkqhkiG9w0BAQUFADB9MQswCQYDVQQGEwJJTDEWMBQGA1UE ChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUg U2lnbmluZzEpMCcGA1UEAxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwHhcN MDcxMDI0MjEwMTU1WhcNMTcxMDI0MjEwMTU1WjCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoT DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUg Q2xpZW50IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAxwmDzM4t2BqxKaQu E6uWvooyg4ymiEGWVUet1G8SD+rqvyNH4QrvnEIaFHxOhESip7vMz39ScLpNLbL1QpOlPW/t FIzNHS3qd2XRNYG5Sv9RcGE+T4qbLtsjjJbi6sL7Ls/f/X9ftTyhxvxWkf8KW37iKrueKsxw 2HqolH7GM6FX5UfNAwAu4ZifkpmZzU1slBhyWwaQPEPPZRsWoTb7q8hmgv6Nv3Hg9rmA1/VP BIOQ6SKRkHXG0Hhmq1dOFoAFI411+a/9nWm5rcVjGcIWZ2v/43Yksq60jExipA4l5uv9/+Hm 33mbgmCszdj/Dthf13tgAv2O83hLJ0exTqfrlwIDAQABo4IBrTCCAakwDwYDVR0TAQH/BAUw AwEB/zAOBgNVHQ8BAf8EBAMCAQYwHQYDVR0OBBYEFFNy7ZKc4NrLAVx8fpY1TvLUuFGCMB8G A1UdIwQYMBaAFE4L7xqkQFulF2mHMMo0aEPQQa7yMGYGCCsGAQUFBwEBBFowWDAnBggrBgEF BQcwAYYbaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL2NhMC0GCCsGAQUFBzAChiFodHRwOi8v d3d3LnN0YXJ0c3NsLmNvbS9zZnNjYS5jcnQwWwYDVR0fBFQwUjAnoCWgI4YhaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vc2ZzY2EuY3JsMCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNv bS9zZnNjYS5jcmwwgYAGA1UdIAR5MHcwdQYLKwYBBAGBtTcBAgEwZjAuBggrBgEFBQcCARYi aHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEFBQcCARYoaHR0cDov L3d3dy5zdGFydHNzbC5jb20vaW50ZXJtZWRpYXRlLnBkZjANBgkqhkiG9w0BAQUFAAOCAgEA CoMIfXirLAZcuGOMXq4cuSN3TaFx2H2GvD5VSy/6rV55BYHbWNaPeQn3oBSU8KgQZn/Kck1J xbLpAxVCNtsxeW1R87ifhsYZ0qjdrA9anrW2MAWCtosmAOT4OxK9QPoSjCMxM3HbkZCDJgnl E8jMopH21BbyAYr7b5EfGRQJNtgWcvqSXwKHnTutR08+Kkn0KAkXCzeQNLeA5LlYUzFyM7kP Ap8pIRMQ+seHunmyG642S2+y/qHEdMuGIwpfz3eDF1PdctL04qYK/zu+Qg1Bw0RwgigVZs/0 c5HP2/e9DBHh7eSwtzYlk4AUr6yxLlcwSjOfOmKEQ/Q8tzh0IFiNu9IPuTGAPBn4CPxD0+Ru 8T2wg8/s43R/PT3kd1OEqOJUl7q+h+r6fpvU0Fzxd2tC8Ga6fDEPme+1Nbi+03pVjuZQKbGw KJ66gEn06WqaxVZC+J8hh/jR0k9mST1iAZPNYulcNJ8tKmVtjYsv0L1TSm2+NwON58tO+pIV zu3DWwSEXSf+qkDavQam+QtEOZxLBXI++aMUEapSn+k3Lxm48ZCYfAWLb/Xj7F5JQMbZvCex glAbYR0kIHqW5DnsYSdMD/IplJMojx0NBrxJ3fN9dvX2Y6BIXRsF1du4qESm4/3CKuyUV7p9 DW3mPlHTGLvYxnyKQy7VFBkoLINszBrOUeIxggPtMIID6QIBATCBlDCBjDELMAkGA1UEBhMC SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENl cnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJ bnRlcm1lZGlhdGUgQ2xpZW50IENBAgMMhpgwDQYJYIZIAWUDBAIBBQCgggIpMBgGCSqGSIb3 DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE1MTAyNjA3Mzk0NlowLwYJKoZI hvcNAQkEMSIEIHpWr/6xb5j/aas5RF250hU9SsGj3hizdd7WUr03OjAvMGwGCSqGSIb3DQEJ DzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0D AgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgaUGCSsGAQQB gjcQBDGBlzCBlDCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzAp BgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0 YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgMMhpgwgacG CyqGSIb3DQEJEAILMYGXoIGUMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20g THRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG A1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EC AwyGmDANBgkqhkiG9w0BAQEFAASCAQCrx3a8kQ+5pPL1KP8N4Rwbmqt5sTlhPPxRE0Rs1AkR O8bYdRt0NG7RgFDcUqRklTUpmT1f9tbmR2g0ox3GcjpRM/Y0TC/UCw0MCz2TICjn7S4tquEO d2JXQEultimOolfH8fojVo3GmynzFxkXzUASvNPbS3YiSvzEUj+TPurnHhdSR+5250IU22EJ ud1avEVjor9UiKd6jbHPlrlp7ViLBk/aJn79ZK2FlFnpFBipaD8wM5jZ3clszLPc/b3dH2DH jS0iJVIwV3pc0kLWMJ2Q1nhWo8ZvoTqY0leLhaX0EmDPwMFzy6WgmCClvjHCGnz/ElQtc5bo gwiUPAgMsCErAAAAAAAA --------------ms010004050500030203080906-- From nobody Mon Oct 26 05:53:53 2015 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8DC51B2E1B for ; Mon, 26 Oct 2015 05:53:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YJBCe358Kpxa for ; Mon, 26 Oct 2015 05:53:45 -0700 (PDT) Received: from mail-qg0-x22b.google.com (mail-qg0-x22b.google.com [IPv6:2607:f8b0:400d:c04::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 90D8C1B2E16 for ; Mon, 26 Oct 2015 05:53:45 -0700 (PDT) Received: by qgeo38 with SMTP id o38so118597497qge.0 for ; Mon, 26 Oct 2015 05:53:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:mime-version:subject:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=WpQbLtIYUyzq7BzIU9/bkKe4zes/CPIPHFfaUrj1W7c=; b=EBhqJYvf4CW6HZl0hVWwQDa1Lfwr1NgIKnY26ZoTzxtaidd9qQT67krMl/EHKME1R1 3XiLE/XyuAZ9QcLNRWMARUKAIjNCxPHFT+3MwLEaQyCl8yZWmsQoSchbvHhGTOMgq9cu +xoAnv7pqf2jRoZEH5mFCgkz5XkvjxoQZ/TwTYN1xVr1/wxwFDOLpfwfgI0GqV1KSGQr YDO1/FqvL7UwVns1+LlJ7dPGpWDfE9lO/rwN7IN7lCAyYWLcYDozNopJ9YXCeHXZ1FXU dlEXfdx6WyZBDyMxLQh8Sm6BDj2l2RHzqctow0nX0KObARzeCtPSA4w7RNmR0pXCW4ul SQwg== X-Received: by 10.140.194.8 with SMTP id p8mr45100486qha.63.1445864024721; Mon, 26 Oct 2015 05:53:44 -0700 (PDT) Received: from [10.186.122.192] (mobile-166-171-187-116.mycingular.net. [166.171.187.116]) by smtp.gmail.com with ESMTPSA id 22sm683400qhq.39.2015.10.26.05.53.43 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 26 Oct 2015 05:53:43 -0700 (PDT) From: Kathleen Moriarty X-Google-Original-From: Kathleen Moriarty Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) X-Mailer: iPhone Mail (12H143) In-Reply-To: <562DD8C2.3020508@sics.se> Date: Mon, 26 Oct 2015 08:53:42 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <4E22F8C6-5C2E-4E31-96D4-2D9DC1D5B2D7@gmail.com> References: <20151022132903.23826.2689.idtracker@ietfa.amsl.com> <5629EA01.6020506@sics.se> <5629EED2.5080005@cs.tcd.ie> <562A3647.3030101@sics.se> <562A4B07.9080305@tzi.de> <6E79B71B-FBE1-4FB6-B9B9-16E6C44C67BA@gmail.com> <562DD8C2.3020508@sics.se> To: Ludwig Seitz Archived-At: Cc: Stefanie Gerdes , "ace@ietf.org" , Stephen Farrell Subject: Re: [Ace] Stephen Farrell's Yes on draft-ietf-ace-usecases-09: (with COMMENT) X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 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 Oct 2015 12:53:51 -0000 Yes, it should be both. Thanks, Kathleen=20 Sent from my iPhone > On Oct 26, 2015, at 3:39 AM, Ludwig Seitz wrote: >=20 >> On 2015-10-23 17:21, Kathleen Moriarty wrote: >>=20 >>=20 >> Sent from my iPhone >>=20 >>> On Oct 23, 2015, at 10:58 AM, Stefanie Gerdes >>> wrote: >>>=20 >>> Hi all, >>>=20 >>>>>> 1. Software update is really needed and often missing and >>>>>> usually hard. There's at least a need to authenticate and >>>>>> authorize new firmware, when there is any update. That may >>>>>> not be the same as authorizing a new config. >>>>=20 >>>>=20 >>>> Isn't this covered in section 2.4.1.3. ? >>>>=20 >>>> "At some point the facility management company wants to update >>>> the firmware of lighting devices in order to eliminate software >>>> bugs. Before accepting the new firmware, each device checks the >>>> authorization of the facility management company to perform this >>>> update." >>>>=20 >>>> There is simply not a specific authorization problem listed for >>>> this, I could argue that it is subsumed under U4.4 but if you >>>> think it deserves specific mention under the problems section I >>>> can live with adding a point. >>>=20 >>> I think adding a point in 2.4.3 is a good idea. We could also add >>> an item to 3.3 that emphasizes the problem. >>=20 >> Great, I think adding a point would be helpful. You'd be >> authenticating the device to receive the update preventing fraud, >> which is different from the existing point referenced. >=20 > Hello Kathleen, >=20 > I'm a bit puzzled by this last sentence. That is not at all how I read Ste= phen's comment, which was, in my understanding, all about authenticating and= authorizing the software update, not the receiver of the update. >=20 > Now obviously, authenticating the receiver of a software update is not a b= ad idea either, but do you think this also requires specific mention? >=20 > /Ludwig >=20 >=20 > --=20 > Ludwig Seitz, PhD > SICS Swedish ICT AB > Ideon Science Park > Building Beta 2 > Scheelev=C3=A4gen 17 > SE-223 70 Lund >=20 > Phone +46(0)70-349 92 51 > http://www.sics.se >=20 From nobody Mon Oct 26 09:23:28 2015 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 2AA7A1B4E33; Mon, 26 Oct 2015 09:23:27 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.7.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151026162327.10444.18407.idtracker@ietfa.amsl.com> Date: Mon, 26 Oct 2015 09:23:27 -0700 Archived-At: Cc: ace@ietf.org Subject: [Ace] I-D Action: draft-ietf-ace-usecases-10.txt X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 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 Oct 2015 16:23:27 -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 Working Group of the IETF. Title : Use Cases for Authentication and Authorization in Constrained Environments Authors : Ludwig Seitz Stefanie Gerdes Göran Selander Mehdi Mani Sandeep S. Kumar Filename : draft-ietf-ace-usecases-10.txt Pages : 29 Date : 2015-10-26 Abstract: Constrained devices are nodes with limited processing power, storage space and transmission capacities. These devices in many cases do not provide user interfaces and are often intended to interact without human intervention. This document includes a collection of representative use cases for authentication and authorization in constrained environments. These use cases aim at identifying authorization problems that arise during the lifecycle of a constrained device and are intended to provide a guideline for developing a comprehensive authentication and authorization solution for this class of scenarios. Where specific details are relevant, it is assumed that the devices use the Constrained Application Protocol (CoAP) as communication protocol, however most conclusions apply generally. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ace-usecases/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-ace-usecases-10 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ace-usecases-10 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 Mon Oct 26 09:28:13 2015 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 AE7341B4EA2; Mon, 26 Oct 2015 09:28:07 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.7.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151026162807.8327.67513.idtracker@ietfa.amsl.com> Date: Mon, 26 Oct 2015 09:28:07 -0700 Archived-At: Cc: ace-chairs@ietf.org, Kathleen.Moriarty.ietf@gmail.com, draft-ietf-ace-usecases@ietf.org, The IESG , ace@ietf.org, Hannes.Tschofenig@gmx.net, rfc-editor@rfc-editor.org Subject: [Ace] Document Action: 'Use Cases for Authentication and Authorization in Constrained Environments' to Informational RFC (draft-ietf-ace-usecases-10.txt) X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 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 Oct 2015 16:28:07 -0000 The IESG has approved the following document: - 'Use Cases for Authentication and Authorization in Constrained Environments' (draft-ietf-ace-usecases-10.txt) as Informational RFC This document is the product of the Authentication and Authorization for Constrained Environments Working Group. The IESG contact persons are Stephen Farrell and Kathleen Moriarty. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-ace-usecases/ Technical Summary This document is an Informational RFC describing use cases motivating the work on authentication and authorization for the Internet of Things environment. Working Group Summary Consensus from the working group was clear. While the draft took a long time to get through the process, I think it was more an artifact of a small number of people not being in favor of publishing a use case draft. There was adequate review of this draft and agreement on the content. Document Quality No additional reviews are requested. Personnel The document shepherd is Hannes Tschofenig. The responsible Area Director is Kathleen Moriarty. From nobody Mon Oct 26 09:34:43 2015 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD2871B4F1B for ; Mon, 26 Oct 2015 09:34:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 33frw5Uw0NPi for ; Mon, 26 Oct 2015 09:34:40 -0700 (PDT) Received: from mail-lf0-x231.google.com (mail-lf0-x231.google.com [IPv6:2a00:1450:4010:c07::231]) (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 A62781B4F14 for ; Mon, 26 Oct 2015 09:34:39 -0700 (PDT) Received: by lffv3 with SMTP id v3so155566563lff.0 for ; Mon, 26 Oct 2015 09:34:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; bh=pUjqh5M+K1u2nibqPkkCYREHkztlDSvNUAQSevLlaGo=; b=okQjwCtOlAIemhBTABGRr8sQwnf1fptOedI9XUuN8VtfGGzwphmDOUtYbJlG/TAKTl TNgrwBOrXzORSfVkeuCX39WjJKF6ieQgMwF6pO1NKgWEQnm4u64q3qG7PDKj7YWJexXg PPfdbwsiZAudEiK3jf4XvgnRDJIfVDlheMYFAAsNckPRz6X59WwkNxMiA8X37VjqgVzR ez7MiWorLMY3voMF7clXqmTu67AGtA/L5+WiX51GYr0sP9Js+zjEvzpfHxIOvm9FTaNb evLrHP/9+jAZJKyZDWgzwsX8jnnD9ev/WFnrXJUTGaiPYht8sOWFNWGyu53ZBnBfqYKv mkGA== MIME-Version: 1.0 X-Received: by 10.28.94.194 with SMTP id s185mr2251219wmb.90.1445877277708; Mon, 26 Oct 2015 09:34:37 -0700 (PDT) Received: by 10.28.214.142 with HTTP; Mon, 26 Oct 2015 09:34:37 -0700 (PDT) In-Reply-To: <20151026162327.10444.18407.idtracker@ietfa.amsl.com> References: <20151026162327.10444.18407.idtracker@ietfa.amsl.com> Date: Mon, 26 Oct 2015 12:34:37 -0400 Message-ID: From: Kathleen Moriarty To: "ace@ietf.org" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Ace] I-D Action: draft-ietf-ace-usecases-10.txt X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 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 Oct 2015 16:34:41 -0000 Nice job to all who edited and contributed to this use case draft! The IESG review went very smoothly with many more YES ballots than normal. The draft was easy to read and helpful to many. It will now move into the RFC editor queue, so there is a little more work to do before it gets an RFC number. Thank you, Kathleen On Mon, Oct 26, 2015 at 12:23 PM, wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > This draft is a work item of the Authentication and Authorization for Co= nstrained Environments Working Group of the IETF. > > Title : Use Cases for Authentication and Authorization = in Constrained Environments > Authors : Ludwig Seitz > Stefanie Gerdes > G=C3=B6ran Selander > Mehdi Mani > Sandeep S. Kumar > Filename : draft-ietf-ace-usecases-10.txt > Pages : 29 > Date : 2015-10-26 > > Abstract: > Constrained devices are nodes with limited processing power, storage > space and transmission capacities. These devices in many cases do > not provide user interfaces and are often intended to interact > without human intervention. > > This document includes a collection of representative use cases for > authentication and authorization in constrained environments. These > use cases aim at identifying authorization problems that arise during > the lifecycle of a constrained device and are intended to provide a > guideline for developing a comprehensive authentication and > authorization solution for this class of scenarios. > > Where specific details are relevant, it is assumed that the devices > use the Constrained Application Protocol (CoAP) as communication > protocol, however most conclusions apply generally. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-ace-usecases/ > > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-ace-usecases-10 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ace-usecases-10 > > > Please note that it may take a couple of minutes from the time of submiss= ion > 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/ > > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace --=20 Best regards, Kathleen From nobody Wed Oct 28 07:50:09 2015 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1602F1B558F for ; Wed, 28 Oct 2015 07:50:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jmDYTag2WvPO for ; Wed, 28 Oct 2015 07:50:05 -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 670EC1B55B1 for ; Wed, 28 Oct 2015 07:50:05 -0700 (PDT) Received: from [192.168.10.221] ([80.92.119.240]) by mail.gmx.com (mrgmx001) with ESMTPSA (Nemesis) id 0M7pDs-1adeup0RMG-00vT78 for ; Wed, 28 Oct 2015 15:50:03 +0100 To: "Ace@ietf.org" From: Hannes Tschofenig Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9 X-Enigmail-Draft-Status: N1110 Message-ID: <5630E097.6030508@gmx.net> Date: Wed, 28 Oct 2015 15:49:59 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="tGUCxvWFH1G8fpAvribGRrnBxUa3nuo1o" X-Provags-ID: V03:K0:ruElUf4iQeFUo82465z5jfchv/3eRAoMRgaJmS0sRYZBAJjo02K yOZBDU4v3+T/tGt1Yje64V5zlf9Il4VwtZIeqQ1Y2+qV9C7TXHk5babMHG1GI8g7A1vJ1qS RGTByaisGP7vcsDY6Abqgu53mmklEeH5LugBddU8qamKGV4GF4ByhWrCBbh2DCND7AMdKkS uUE4tLcE0O1lUucbPVZEQ== X-UI-Out-Filterresults: notjunk:1;V01:K0:oQwBntJtmVQ=:+zjdJm4+bjyIN3wEv3TfoJ Vn2pdKLu79gnGghUogb1o5scGhAo+iq/KDsQD1AVuvRzG7uToHNkDza7pNx/zSi1iBA8vv9I6 zPfZq82V2XFMp/63dw3Z1EBMeSkm/0OJmp7//usUsGnlSi8PYwiRwp6hZgyMKlLtPwKZNVabw Yzb3cQl/2artT03PSTAd+F9LZrOCQg6KHxcDnn1RQG6IavFV4OJFflFG7WghZv53iWeZjCbfO eiYcalJwoCkj3dSjt8Rz2QLdiuaBm0WpfV+EYL72oXTQ1VKQlbHlhRZGzoAZHvC9UTIw1Eo8l ljh27KEKter+KAfNjdVcIzwXL/UmBH0Ls5GMW08804HMuBiAXg5PnA/0a6NDO91p80U8QDUTa QoiQhUqmZsa4BakhuXCD90W+ndEjPvpGoHoh3h6YzuDGkh10K7gYD94pCX73F8Ai/as15ZybE +JURW9dDtFSDFXGSkm81xy0hbYWSlhe9ht37pfPYAHTJkqaYVwdAQqIjFOtTABp4FzYPco84T +Z88CKTBfQ8fZext+kN6lTzNgNP8jEdFkebyIQ13pyN9fgkQBRC69uHfj77WOgpyrlqlp5PNd xDeoObn+PoKrepgSZAp3NzKh5YX61DdF9cvWfIxQBqogo0h2k9EFLZx6LCpHY/lAx6983r9P4 VMFyC/GG76SMEuXSyN4YybS9+3DX4rb28j++sprYMFNa1h1LAYdMw+fgejDR9lXKjN+xvCgmL kJNOY0BLnvJczEiSA3vi+zb14giHbIrsSVpTwzRSEvOsABzTm10n7sgeYM8= Archived-At: Subject: [Ace] draft-bergmann-ace-dcaf-cose-00 vs. draft-selander-ace-object-security-03 X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 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 Oct 2015 14:50:07 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --tGUCxvWFH1G8fpAvribGRrnBxUa3nuo1o Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi all, Kepeng and I are talking about the agenda and here is an interesting case where we need to get the feedback from the working group. We have gotten an agenda request for draft-bergmann-ace-dcaf-cose-00, which is about using COSE to provide a object-level security for DCAF. In previous IETF meetings we have heard about a more generic solution, namely draft-selander-ace-object-security-03. It will be presented in COSE/CORE (if the requests get granted). Here is the issue: 1) Officially, we have no milestone in ACE to work on such a document at all right now. 2) Should we have a presentation about draft-bergmann-ace-dcaf-cose-00 when we have already heard about the more generic version before hand? Hence, the question to the group is the following: a) Where does the COAP application layer security belong? Is ACE the right place or is it rather CORE or COSE? If it is ACE should we ask our AD to add another milestone? b) What would the purpose of a presentation of draft-bergmann-ace-dcaf-cose-00 and / or draft-selander-ace-object-security-03 be in ACE for this meeting? If we indeed to the work in ACE then wouldn't it be a useful goal for the meeting be to make a decision about the solution direction? This would of course require us to listen to both solution directions rather than only to one. I would in particular be interested what motivated the work on draft-bergmann-ace-dcaf-cose-00 given the existence of draft-selander-ace-object-security-03... Ciao Hannes & Kepeng --tGUCxvWFH1G8fpAvribGRrnBxUa3nuo1o Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJWMOCYAAoJEGhJURNOOiAtj8kH/iL+zVnRbhJIbmjBK4rdltVF jAOI9Unw8R2QJHaEp8IiwJZMOLp0XZ5LbpeHomHxSyjIbreVkNWTp2rOV6rMcBgf iGhCfX/uddCAYoENkA8qerO1nwROrmAY61U1ZUGt5rKcx8eZMCAdaeCn8Cm0mHr9 VHM4t9lObOhxQoZ4+dR3RRzgoISXEpqThrNZKjdYIUjsRSdmhS7TjG8o6LmxK05i Lca0mYyLlm/p2Z2A9Xrl6eG/RNAeJX1gdLBxx2Uvn/skKXUYB2YXBKL1KkV486BM MxOiC9jmsfMnocpe/IMDmncLlShCrrlvcqCQ7SdPbgrKXZqEmoXzTscgEaio0fA= =j6xc -----END PGP SIGNATURE----- --tGUCxvWFH1G8fpAvribGRrnBxUa3nuo1o-- From nobody Wed Oct 28 08:21:40 2015 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D35C61A8A84 for ; Wed, 28 Oct 2015 08:21:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.55 X-Spam-Level: X-Spam-Status: No, score=-1.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sYpDxwtA174D for ; Wed, 28 Oct 2015 08:21:38 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BACA01A8A77 for ; Wed, 28 Oct 2015 08:21:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::b]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id t9SFLXb1017134; Wed, 28 Oct 2015 16:21:33 +0100 (CET) Received: from aung.tzi.org (unknown [IPv6:2001:638:708:30da:211:22ff:fedd:aa18]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3nmDC14mgkz2CWs; Wed, 28 Oct 2015 16:21:33 +0100 (CET) From: Olaf Bergmann To: Hannes Tschofenig References: <5630E097.6030508@gmx.net> Date: Wed, 28 Oct 2015 16:21:33 +0100 In-Reply-To: <5630E097.6030508@gmx.net> (Hannes Tschofenig's message of "Wed, 28 Oct 2015 15:49:59 +0100") Message-ID: <87oafjkohu.fsf@aung.informatik.uni-bremen.de> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "Ace@ietf.org" Subject: Re: [Ace] draft-bergmann-ace-dcaf-cose-00 vs. draft-selander-ace-object-security-03 X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 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 Oct 2015 15:21:40 -0000 Hi Hannes, Hannes Tschofenig writes: > We have gotten an agenda request for draft-bergmann-ace-dcaf-cose-00, > which is about using COSE to provide a object-level security for DCAF. No, it's not. It is about providing authenticated authorization which is clearly in the focus of the ACE WG. It does this by using DCAF. At the IETF-93 meeting in Prague, several people criticized draft-gerdes-ace-dcaf-authorize because it uses DTLS to provide secure communication. The new draft-bergmann-ace-dcaf-cose specifies how DCAF can be used with COSE syntax. It does *not* specify how object security works, it just *makes use* of what is already there. The intention of the presentation therefore is to explain how DCAF can be used in the presence of intermediaries. I am not going to discuss in ACE whether CoAP option X needs to be protected by mechanism Y as other people tried to. This is clearly something that needs to be discussed in CORE and COSE where it belongs. Once a viable object security mechanism has been defined by these to working groups (my dcaf example shows that COSE is close by while CORE has some work to do in this regard). > In previous IETF meetings we have heard about a more generic solution, Please, do not mix up things. DCAF-COSE is about authenticated authorization, draft-selander-ace-object-security is about object security. =20 > namely draft-selander-ace-object-security-03. It will be presented in > COSE/CORE (if the requests get granted). > > Here is the issue: > > 1) Officially, we have no milestone in ACE to work on such a document at > all right now. We are going to standardize a solution for authenticated authorization, aren't we? DCAF is a proposal for this, and draft-bergmann-ace-dcaf-cose addresses on of the open issues that have been raised in the past. > 2) Should we have a presentation about draft-bergmann-ace-dcaf-cose-00 > when we have already heard about the more generic version before hand? See above. You are missing the point of draft-bergmann-ace-dcaf-cose. > Hence, the question to the group is the following: > > a) Where does the COAP application layer security belong? Is ACE the > right place or is it rather CORE or COSE? COAP application layer security belongs to CORE. > If it is ACE should we ask our AD to add another milestone? > > b) What would the purpose of a presentation of > draft-bergmann-ace-dcaf-cose-00 Addressing the issue raised at the Prague meeting: DCAF is a perfect fit for ACE because it can be used with transport layer security and object security and is able to handle the three communication patterns that have been brought on the table (IIRC they have been called "push", "pull", and "client pull"). > and / or draft-selander-ace-object-security-03 be in ACE for this > meeting? I am happy to discuss this I-D during COSE and CORE. > If we indeed to the work in ACE then wouldn't it be a useful goal for > the meeting be to make a decision about the solution direction? This > would of course require us to listen to both solution directions rather > than only to one. I would in particular be interested what motivated the > work on draft-bergmann-ace-dcaf-cose-00 given the existence of > draft-selander-ace-object-security-03... My hope is to have explained that it bit. draft-bergmann-ace-dcaf-cose is not in concurrency to draft-selander-ace-object-security. It just happens to use COSE in a more REST-like way. But that is a discussion for CORE. Let ACE focus on the authorization aspects of both drafts where draft-bergmann-ace-dcaf-cose is a perfect amendment of draft-gerdes-ace-dcaf-authorize. Gr=C3=BC=C3=9Fe Olaf From nobody Wed Oct 28 08:29:08 2015 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 103971A8AB2 for ; Wed, 28 Oct 2015 08:29:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z8hqk2gzYeLz for ; Wed, 28 Oct 2015 08:29:05 -0700 (PDT) Received: from out4133-130.mail.aliyun.com (out4133-130.mail.aliyun.com [42.120.133.130]) by ietfa.amsl.com (Postfix) with ESMTP id EE31B1A8AA6 for ; Wed, 28 Oct 2015 08:29:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alibaba-inc.com; s=default; t=1446046143; h=Date:Subject:From:To:Message-ID:Mime-version:Content-type; bh=BaPXVrwPZxSl6GaqWGanRqGmu9rbyEGQeexfAiioyq4=; b=ch5lHNTyZ333OINEE63xCJSm3ivkDEl3stF31dwIb/aWYEJruXRwJgHcKOjlQWhgdxQY0ENyxARHJJc17bItFkzff/J37RRxHPu4XsbJUG0/ovRV2HzF1U3NtgqKOviwGpRVLkhixCORxKqk8TQ/oiYHHLSum4gEpXt9cbp5MUg= X-Alimail-AntiSpam: AC=PASS; BC=-1|-1; BR=01201311R101e4; FP=0|-1|-1|-1|0|-1|-1|-1; HT=e02c03307; MF=kepeng.lkp@alibaba-inc.com; NM=1; PH=DS; RN=1; SR=0; Received: from 10.22.54.75(mailfrom:kepeng.lkp@alibaba-inc.com ip:42.120.73.208) by smtp.aliyun-inc.com(127.0.0.1); Wed, 28 Oct 2015 23:29:00 +0800 User-Agent: Microsoft-MacOutlook/14.4.8.150116 Date: Thu, 29 Oct 2015 00:28:55 +0800 From: "Kepeng Li" To: "Ace@ietf.org" Message-ID: Thread-Topic: DCAF draft and ACE solutions Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3528923340_6076838" Archived-At: Subject: [Ace] DCAF draft and ACE solutions X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 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 Oct 2015 15:29:07 -0000 > ʼʹ MIME ʽʼĶʶ ˸ʽˣ޷ʶʼķֲ򲿷ݡ --B_3528923340_6076838 Content-type: text/plain; charset="GB2312" Content-transfer-encoding: 7bit Hi Steffi, Olaf and Jorge, When Hannes and I arrange the agenda, one question comes to us is: What is the difference and relationship between these two documents? (1)-https://tools.ietf.org/html/draft-gerdes-ace-dcaf-authorize-04 (2) https://datatracker.ietf.org/doc/draft-cuellar-ace-solutions/ Thanks, Kind Regards Kepeng & Hannes --B_3528923340_6076838 Content-type: text/html; charset="GB2312" Content-transfer-encoding: quoted-printable
Hi Steffi, Olaf and Jorge,
=

When Hannes and I arrange the agenda, one question comes= to us is:

What is the difference and relationship = between these two documents?

Thank= s,

Kind Regards
Kepeng & Hannes
= --B_3528923340_6076838-- From nobody Wed Oct 28 08:33:03 2015 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B0D21A8AB8 for ; Wed, 28 Oct 2015 08:33:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.549 X-Spam-Level: X-Spam-Status: No, score=-6.549 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aHcdMhqPTGSF for ; Wed, 28 Oct 2015 08:33:00 -0700 (PDT) Received: from thoth.sbs.de (thoth.sbs.de [192.35.17.2]) (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 AF7231A8AB6 for ; Wed, 28 Oct 2015 08:32:59 -0700 (PDT) Received: from mail1.sbs.de (mail1.sbs.de [192.129.41.35]) by thoth.sbs.de (8.15.2/8.15.2) with ESMTPS id t9SFWrt6014662 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 28 Oct 2015 16:32:54 +0100 Received: from DEFTHW99ERHMSX.ww902.siemens.net (defthw99erhmsx.ww902.siemens.net [139.22.70.133]) by mail1.sbs.de (8.15.1/8.15.1) with ESMTPS id t9SFWrwG011204 (version=TLSv1 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 28 Oct 2015 16:32:53 +0100 Received: from DEFTHW99ERBMSX.ww902.siemens.net (139.22.70.76) by DEFTHW99ERHMSX.ww902.siemens.net (139.22.70.133) with Microsoft SMTP Server (TLS) id 14.3.266.1; Wed, 28 Oct 2015 16:32:52 +0100 Received: from DEFTHW99EI4MSX.ww902.siemens.net ([169.254.9.63]) by DEFTHW99ERBMSX.ww902.siemens.net ([139.22.70.76]) with mapi id 14.03.0266.001; Wed, 28 Oct 2015 16:32:52 +0100 From: "Cuellar, Jorge" To: "kepeng.lkp@alibaba-inc.com" , "Ace@ietf.org" Thread-Topic: [Ace] DCAF draft and ACE solutions Thread-Index: AQHREZVpEBmZnrt3pkadSMKUHgepQ56BB8ZA Date: Wed, 28 Oct 2015 15:32:52 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [139.22.70.55] Content-Type: multipart/alternative; boundary="_000_FFE9A7A8D3904741935F44C6429E3B9D859D7DDEFTHW99EI4MSXww9_" MIME-Version: 1.0 Archived-At: Subject: Re: [Ace] DCAF draft and ACE solutions X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 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 Oct 2015 15:33:02 -0000 --_000_FFE9A7A8D3904741935F44C6429E3B9D859D7DDEFTHW99EI4MSXww9_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Kepeng, Hannes, In "solutions" we're trying to find a common generic protocol, of which "DC= AF" is a particular solution (instantiation). Hopefully also oauth and others ;) will be merged inot the generic protocol= . Best, Jorge From: Ace [mailto:ace-bounces@ietf.org] On Behalf Of Kepeng Li Sent: 28 October 2015 17:29 To: Ace@ietf.org Subject: [Ace] DCAF draft and ACE solutions Hi Steffi, Olaf and Jorge, When Hannes and I arrange the agenda, one question comes to us is: What is the difference and relationship between these two documents? (1)-https://tools.ietf.org/html/draft-gerdes-ace-dcaf-authorize-04 (2) https://datatracker.ietf.org/doc/draft-cuellar-ace-solutions/ Thanks, Kind Regards Kepeng & Hannes --_000_FFE9A7A8D3904741935F44C6429E3B9D859D7DDEFTHW99EI4MSXww9_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Kepeng,= Hannes,

 = ;

In „= solutions“ we’re trying to find a common generic protocol, of w= hich “DCAF” is a particular solution (instantiation).

Hopefully = also oauth and others ;) will be merged inot the generic protocol.

 = ;

Best, Jorg= e

 = ;

 

From: Ace [mailto:ace-bounces@ietf.org] On Behalf Of Kepeng Li
Sent: 28 October 2015 17:29
To: Ace@ietf.org
Subject: [Ace] DCAF draft and ACE solutions

 

Hi Steffi, Olaf and Jorge,

 

When Hannes and I arrange the = agenda, one question comes to us is:

 

What is the difference and rel= ationship between these two documents?

 

Thanks,

 

Kind Regards=

Kepeng & Hannes=

--_000_FFE9A7A8D3904741935F44C6429E3B9D859D7DDEFTHW99EI4MSXww9_-- From nobody Wed Oct 28 08:36:51 2015 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B1B31A8ADB for ; Wed, 28 Oct 2015 08:36:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yg5jeSy-_CVN for ; Wed, 28 Oct 2015 08:36:49 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (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 BCCDE1A8A64 for ; Wed, 28 Oct 2015 08:36:05 -0700 (PDT) Received: from [192.168.10.221] ([80.92.119.240]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0LgdBZ-1aEgZ43z3V-00nwaw; Wed, 28 Oct 2015 16:36:04 +0100 To: Olaf Bergmann References: <5630E097.6030508@gmx.net> <87oafjkohu.fsf@aung.informatik.uni-bremen.de> From: Hannes Tschofenig Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9 X-Enigmail-Draft-Status: N1110 Message-ID: <5630EB61.3070407@gmx.net> Date: Wed, 28 Oct 2015 16:36:01 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <87oafjkohu.fsf@aung.informatik.uni-bremen.de> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="3Rx1HQdkgcCNXw45xkkcEfTmHXmB1PFuH" X-Provags-ID: V03:K0:0+f2FXwoi2j/j5I0Dwjhfeuc5zLZykQw/Oa1suo5htcvZ/mx9Rl n83+Lkb+eVy52NET3e32oEbmDU31/zbmXjMyRH+Q9OetZdrLQtSWl3QE6oVDEdD8V1lAIIK s6pT2SKExx+ygb6JsUEQMF1ciWwd3vJGkcZ/WznbbEJp3sQX3Jook6K3u9Sce0M9bUBPzTx AXFzcuxQVuzSK1cZxapKw== X-UI-Out-Filterresults: notjunk:1;V01:K0:Lx6/1NmxMX8=:PTtgKzMffLNBhVrYo8RAYk R1NTtBWz4IYR5QGHJQuhkE8DOV1b/Rr5GLX3iIuO/zoz1zJM1XJzPntpZ6nzNN1wkJZff8qYN tuEO24ZdnLFq+V9RFC8EdXMJPyN9f5HKZvW66ctRL7z/4xzS7m2YrzcHCCS/BCzmUf16IpsKp 8m/j2JYxvhz50v3ge2goJZ4W/Ya5Do3/xdfCOJ+aqAkfAS30PlsHBoeYAe9d3jy5ZBgT9xY7g s3Y/4Dv6WOHFGCi19W9XIbYDhjvVCA+rhLWFxo4NG6/NGTQkft/Tv2VfsGKJzrfxI058j/Bva bZtf4cOFT95DIOZNJcql6grXzJ8Fi7eYpSSApQtiMM08SxZM2/eAeqwDsE7olO3DepREG/OOg t0UH1Vi8hzbF0EIGdTt15pUnVvEae3kaCbHovRuqHYDKZD7wkVIc3jhDAKei27EOieRZq86iY Es0/PK6NAkNiPhYJPBnT77ENMosDCWCzIZtJdBplUU5Yilz4dGi7VSBwC91MMM19iWgkvW0ZK Rlf71mLmUsjx+PaK/fboWVgB31pyVfGI1fjM0GUsT8pEP7yf2tGHBIbGdO6tSZz87X6h5du0l IPRI1n9vJp7Rs4c7ZPTAhR24Hl5HqFuTN+FSNY3IeR2BYlIgQFitDi+nI3wiWwiC1L1O6daYQ rMItYxyf7ebLi2tUHg4v/uETMCS1U165NvH6S7Dqcyd49PS1MFzL5U0zXOkrt03UwvgTyOEZp U+htscokOM5rmnKywDgVn5UJ5Cn+55Y+NWPJ1VgRxFLc9cvKk1CZ3QPr86U= Archived-At: Cc: "Ace@ietf.org" Subject: Re: [Ace] draft-bergmann-ace-dcaf-cose-00 vs. draft-selander-ace-object-security-03 X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 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 Oct 2015 15:36:51 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --3Rx1HQdkgcCNXw45xkkcEfTmHXmB1PFuH Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Olaf, I think you are playing with words a bit when you say it is about "authenticated authorization rather than object security" when there is clearly an overlap between the two solutions. Anyway, if you believe this is special to DCAF then it should be covered as part of the DCAF presentation rather than as a separate solution. When I had a chat with Kepeng we noticed that you split up the solution into separate different documents and I believe it would be a bit boring for the working group to hear (Steffi, or Carsten) talk for 60 mins about something that others only get 20 or 30mins only because they have decided to put everything into one document. I let the authors of draft-selander-ace-object-security-03 present their views before we should decide where this topic should be covered. Ciao Hannes On 10/28/2015 04:21 PM, Olaf Bergmann wrote: > Hi Hannes, >=20 > Hannes Tschofenig writes: >=20 >> We have gotten an agenda request for draft-bergmann-ace-dcaf-cose-00, >> which is about using COSE to provide a object-level security for DCAF.= >=20 > No, it's not. It is about providing authenticated authorization which i= s > clearly in the focus of the ACE WG. It does this by using DCAF. >=20 > At the IETF-93 meeting in Prague, several people criticized > draft-gerdes-ace-dcaf-authorize because it uses DTLS to provide secure > communication. The new draft-bergmann-ace-dcaf-cose specifies how DCAF > can be used with COSE syntax. It does *not* specify how object security= > works, it just *makes use* of what is already there. >=20 > The intention of the presentation therefore is to explain how DCAF can > be used in the presence of intermediaries. I am not going to discuss in= > ACE whether CoAP option X needs to be protected by mechanism Y as other= > people tried to. This is clearly something that needs to be discussed i= n > CORE and COSE where it belongs. Once a viable object security mechanism= > has been defined by these to working groups (my dcaf example shows that= > COSE is close by while CORE has some work to do in this regard). >=20 >> In previous IETF meetings we have heard about a more generic solution,= >=20 > Please, do not mix up things. DCAF-COSE is about authenticated > authorization, draft-selander-ace-object-security is about object > security. > =20 >> namely draft-selander-ace-object-security-03. It will be presented in >> COSE/CORE (if the requests get granted). >> >> Here is the issue: >> >> 1) Officially, we have no milestone in ACE to work on such a document = at >> all right now. >=20 > We are going to standardize a solution for authenticated authorization,= > aren't we? DCAF is a proposal for this, and draft-bergmann-ace-dcaf-cos= e > addresses on of the open issues that have been raised in the past. >=20 >> 2) Should we have a presentation about draft-bergmann-ace-dcaf-cose-00= >> when we have already heard about the more generic version before hand?= >=20 > See above. You are missing the point of draft-bergmann-ace-dcaf-cose. >=20 >> Hence, the question to the group is the following: >> >> a) Where does the COAP application layer security belong? Is ACE the >> right place or is it rather CORE or COSE? >=20 > COAP application layer security belongs to CORE. >=20 >> If it is ACE should we ask our AD to add another milestone? >> >> b) What would the purpose of a presentation of >> draft-bergmann-ace-dcaf-cose-00 >=20 > Addressing the issue raised at the Prague meeting: DCAF is a perfect fi= t > for ACE because it can be used with transport layer security and object= > security and is able to handle the three communication patterns that > have been brought on the table (IIRC they have been called "push", > "pull", and "client pull"). >=20 >> and / or draft-selander-ace-object-security-03 be in ACE for this >> meeting? >=20 > I am happy to discuss this I-D during COSE and CORE. >=20 >> If we indeed to the work in ACE then wouldn't it be a useful goal for >> the meeting be to make a decision about the solution direction? This >> would of course require us to listen to both solution directions rathe= r >> than only to one. I would in particular be interested what motivated t= he >> work on draft-bergmann-ace-dcaf-cose-00 given the existence of >> draft-selander-ace-object-security-03... >=20 > My hope is to have explained that it bit. draft-bergmann-ace-dcaf-cose > is not in concurrency to draft-selander-ace-object-security. It just > happens to use COSE in a more REST-like way. But that is a discussion > for CORE. Let ACE focus on the authorization aspects of both drafts > where draft-bergmann-ace-dcaf-cose is a perfect amendment of > draft-gerdes-ace-dcaf-authorize. >=20 > Gr=C3=BC=C3=9Fe > Olaf >=20 --3Rx1HQdkgcCNXw45xkkcEfTmHXmB1PFuH Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJWMOtiAAoJEGhJURNOOiAthLoH/2u+DRcJsI/Tg3I2gFN7F0+h 95WTce+ZUwlxskTzm7FzLgJobiWK7ME4dMA0LpaLzvsu7RPCqxEnMG+K9+uze2Sx vz910fvZW9xeWOOx1LaxZCR3C7T063EkJiaXCZGLRCGfgwB/jEEgXW4KrIGF0LsQ EXJDDosevo2Rjr1NmBGLxqouI/m0EA84Hyqy7n3Hrdf2ZeBivUo6TFPWhrmONFuV i6JE1TQqmejYOC+OkvtenvQ+fHZ52pQ9pqmSTHdQYmpyuvhSVLxLzD+6oXNhqi25 4pOYGmscyvarn+MvwxqfUo/SpJBr/gOg/Ods4uKOp6nEzeYDzz5JSWhvJ1Xt3xc= =b3S0 -----END PGP SIGNATURE----- --3Rx1HQdkgcCNXw45xkkcEfTmHXmB1PFuH-- From nobody Wed Oct 28 08:38:27 2015 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6D301A8AC3 for ; Wed, 28 Oct 2015 08:38:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iSXjO_6IYtN0 for ; Wed, 28 Oct 2015 08:38:25 -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 69BBB1A8A77 for ; Wed, 28 Oct 2015 08:37:39 -0700 (PDT) Received: from [192.168.10.221] ([80.92.119.240]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0MMXVC-1ZqvM40TZm-008GFO; Wed, 28 Oct 2015 16:37:22 +0100 To: "Cuellar, Jorge" , "kepeng.lkp@alibaba-inc.com" , "Ace@ietf.org" References: From: Hannes Tschofenig Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9 Message-ID: <5630EBAE.5060307@gmx.net> Date: Wed, 28 Oct 2015 16:37:18 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="e2lHdTB3RfnROfb96duU552snkSTW4BB8" X-Provags-ID: V03:K0:Jmxcg+/l8s7DzTB2OqX+b0Snr8lrVFMP8Ir4SFXI/FT7OkPQctR o+BAxdn8bwd+ZQnPggT1yFvyZb5kYv2vnt4LOz6GQHtcpknuD7ZBEZ0CE+4tz4gn058LdkH NsieN5P9fNhstV9+2Dl8S8hv6XEnMreIZs0F/HMDzljId2N6AgyQARxBdnIknSYZGLXDVTl xd9mPObleuAYq1VHxbSiQ== X-UI-Out-Filterresults: notjunk:1;V01:K0:Nek9D2Ha91k=:glmmJhLkBVQVYDFWp0c0E0 GTMFH6x/j2+WwNToSqT+dbQS2VjGdYWhbVyzxukMBDC0MJM2yYw/9sndHDNYnD8inAw8tddOa /4pRzs6TP/u3DCn82rzHxFJ+CFw2ZjH0vviCdqGyT1e5Id5DSFtpnixpyE/6BDFPuXIy5dYtp XOG1vdTn3ktxMXuzEu17aIdJEovpOhsBYotGCn8QOREWUyxdALYk74e6wKXxGk5PCkrPLrtZW fGR1C0u05nAxtfY/pEGiBoQeTQZJj5+n+QmKScpq4WfV/UiIPQi2Tn2Be6oWMD+eVswNPTXI3 8AOt7aRHucGoyWDgQ6PFMkM3p7pv5fjSFAOtL/2Y0pVEINcG3E/rWUSXs7r8QtZloqaWwNMpy rS4IK8ODUxmtNmvvKsJ8zX2cAbB7L0DsbptcdeF6dEr+5nV2Z1QGHFl4VtvIAXko0QlboQAEJ 19o+OGS3dkCvLCmVqW0w8hvN4QDqLTHfphI1yhQAN/F0wXQRPpw+kywVPiF+8XPqfcnEmDX0n 9vsL5EZawNBnm28u8AYukQd/SjylX4qDpkcMp9BG/hTqYN7jM8yRUrB9UcG8uRXK4kvATLvLx Og5gLm/lxG9FBizNU7N0WpIwgQibGWqXD7MJ9GJpBvo37Yncmrcv3hO1tDZjBscrufzq2CqER cGe1KwcPRzkHWzCt6HAkh3q1PV+sbdkyTxSte4kAdEzlNVebXs2q00azAqPxkBVn38I8WUkj8 67EzxI13u5lmu6e94Wl1hq6wW5UyTi8nkUOgot18zBVbERY4k2D3CxC0rxA= Archived-At: Subject: Re: [Ace] DCAF draft and ACE solutions X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 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 Oct 2015 15:38:26 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --e2lHdTB3RfnROfb96duU552snkSTW4BB8 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Jorge, when I looked at the so-called solution document it looked almost empty to me. To you think it will help us in our attempt to figure out which solution direction we should go? Ciao Hannes On 10/28/2015 04:32 PM, Cuellar, Jorge wrote: > Hi Kepeng, Hannes, >=20 > =20 >=20 > In =84solutions=93 we=92re trying to find a common generic protocol, of= which > =93DCAF=94 is a particular solution (instantiation). >=20 > Hopefully also oauth and others ;) will be merged inot the generic prot= ocol. >=20 > =20 >=20 > Best, Jorge >=20 > =20 >=20 > =20 >=20 > *From:*Ace [mailto:ace-bounces@ietf.org] *On Behalf Of *Kepeng Li > *Sent:* 28 October 2015 17:29 > *To:* Ace@ietf.org > *Subject:* [Ace] DCAF draft and ACE solutions >=20 > =20 >=20 > Hi Steffi, Olaf and Jorge, >=20 > =20 >=20 > When Hannes and I arrange the agenda, one question comes to us is: >=20 > =20 >=20 > What is the difference and relationship between these two documents? >=20 > (1)-https://tools.ietf.org/html/draft-gerdes-ace-dcaf-authorize-04 >=20 > (2) https://datatracker.ietf.org/doc/draft-cuellar-ace-solutions/ >=20 > =20 >=20 > Thanks, >=20 > =20 >=20 > Kind Regards >=20 > Kepeng & Hannes >=20 >=20 >=20 > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace >=20 --e2lHdTB3RfnROfb96duU552snkSTW4BB8 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJWMOuvAAoJEGhJURNOOiAtfEAH/1f+jYMjY3A+4EC26mCAcUIc nHRHosI6vCDBNld8onCS4Ec2fAp5N4ue9uvjrsj0HS48Y6jW/1w1HdCvC/OqTA1U 7feoWfSb5pRo7k5DU97Ughb93Y8/qq/1o69mDxDtkGl6y0fydi/NCpF19R0Czm/q TYaUg9Eh8s2LDQQX138BFdxFUTOjLFzCADwyF/0e9+yA4ZHC5QhR8M1uD0uVVgFb Lze78Rd9p0Xy+CKLetQFWKOq0F8ecvWifUmwf7yje7zSfZqSszLyktuAnIBAZjaE 1R4OkUYLGwte2foO6nEbHlQmIKuyf/dnpiHYGOHhL6zXcmMsD8ZzDOEf+FiCuo0= =pe32 -----END PGP SIGNATURE----- --e2lHdTB3RfnROfb96duU552snkSTW4BB8-- From nobody Wed Oct 28 08:43:07 2015 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3187F1B57B2 for ; Wed, 28 Oct 2015 08:43:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.55 X-Spam-Level: X-Spam-Status: No, score=-6.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1CE7q-9bl74W for ; Wed, 28 Oct 2015 08:43:05 -0700 (PDT) Received: from goliath.siemens.de (goliath.siemens.de [192.35.17.28]) (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 B03691B57B1 for ; Wed, 28 Oct 2015 08:43:04 -0700 (PDT) Received: from mail2.sbs.de (mail2.sbs.de [192.129.41.66]) by goliath.siemens.de (8.15.2/8.15.2) with ESMTPS id t9SFguf4021474 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 28 Oct 2015 16:42:56 +0100 Received: from DEFTHW99ERIMSX.ww902.siemens.net (defthw99erimsx.ww902.siemens.net [139.22.70.134]) by mail2.sbs.de (8.15.1/8.15.1) with ESMTPS id t9SFguK7015811 (version=TLSv1 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 28 Oct 2015 16:42:56 +0100 Received: from DEFTHW99ER0MSX.ww902.siemens.net (139.22.70.175) by DEFTHW99ERIMSX.ww902.siemens.net (139.22.70.134) with Microsoft SMTP Server (TLS) id 14.3.266.1; Wed, 28 Oct 2015 16:42:56 +0100 Received: from DEFTHW99EI4MSX.ww902.siemens.net ([169.254.9.63]) by DEFTHW99ER0MSX.ww902.siemens.net ([139.22.70.175]) with mapi id 14.03.0266.001; Wed, 28 Oct 2015 16:42:55 +0100 From: "Cuellar, Jorge" To: "hannes.tschofenig@gmx.net" , "kepeng.lkp@alibaba-inc.com" , "Ace@ietf.org" Thread-Topic: [Ace] DCAF draft and ACE solutions Thread-Index: AQHREZVpEBmZnrt3pkadSMKUHgepQ56BB8ZA///xWQCAABD8cA== Date: Wed, 28 Oct 2015 15:42:54 +0000 Message-ID: References: <5630EBAE.5060307@gmx.net> In-Reply-To: <5630EBAE.5060307@gmx.net> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [139.22.70.55] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Ace] DCAF draft and ACE solutions X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 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 Oct 2015 15:43:07 -0000 Hi Hannes, yes, I agree, the document has not much content. But in Prague we proposed to "merge the different solutions" and this is si= mply a start. If we put too many restrictions on the text, we will find out that the whol= e approach does not work. So we preferred to have a very general sketch (I would not require too much= time to present it) but then we may have the opportunity of discussing - if such a general approach is wanted and - if there are specific things that must be changed or taken into considera= tion in order to be able to merge with other solutions that we consider rel= evant. Best, Jorge -----Original Message----- From: Hannes Tschofenig [mailto:hannes.tschofenig@gmx.net] Sent: 28 October 2015 16:37 To: Cuellar, Jorge; kepeng.lkp@alibaba-inc.com; Ace@ietf.org Subject: Re: [Ace] DCAF draft and ACE solutions Hi Jorge, when I looked at the so-called solution document it looked almost empty to = me. To you think it will help us in our attempt to figure out which solution di= rection we should go? Ciao Hannes On 10/28/2015 04:32 PM, Cuellar, Jorge wrote: > Hi Kepeng, Hannes, > > > > In "solutions" we're trying to find a common generic protocol, of > which "DCAF" is a particular solution (instantiation). > > Hopefully also oauth and others ;) will be merged inot the generic protoc= ol. > > > > Best, Jorge > > > > > > *From:*Ace [mailto:ace-bounces@ietf.org] *On Behalf Of *Kepeng Li > *Sent:* 28 October 2015 17:29 > *To:* Ace@ietf.org > *Subject:* [Ace] DCAF draft and ACE solutions > > > > Hi Steffi, Olaf and Jorge, > > > > When Hannes and I arrange the agenda, one question comes to us is: > > > > What is the difference and relationship between these two documents? > > (1)-https://tools.ietf.org/html/draft-gerdes-ace-dcaf-authorize-04 > > (2) https://datatracker.ietf.org/doc/draft-cuellar-ace-solutions/ > > > > Thanks, > > > > Kind Regards > > Kepeng & Hannes > > > > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace > From nobody Wed Oct 28 08:48:45 2015 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA4591A8AF5 for ; Wed, 28 Oct 2015 08:48:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dSzuXk_0Ttts for ; Wed, 28 Oct 2015 08:48:41 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (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 36AFB1A8AE1 for ; Wed, 28 Oct 2015 08:48:41 -0700 (PDT) Received: from [192.168.10.221] ([80.92.119.240]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0LedVG-1aH94z0JMU-00qRJz; Wed, 28 Oct 2015 16:48:31 +0100 To: Olaf Bergmann References: <5630E097.6030508@gmx.net> <87oafjkohu.fsf@aung.informatik.uni-bremen.de> From: Hannes Tschofenig Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9 Message-ID: <5630EE4D.7080202@gmx.net> Date: Wed, 28 Oct 2015 16:48:29 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <87oafjkohu.fsf@aung.informatik.uni-bremen.de> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="GjEDcLAQX1ri6gIk42wH7M8vJp3VSbNSJ" X-Provags-ID: V03:K0:LRUw5gSPhze1Ko0wKqDvGuD0VVYcsSz/PZ81Q1tU4W0+dgIf7PT 2AiX7dQNIuzcZyurx7c0ek0LjCmpYYI8JYsYKpXw/TVY4KjUQPlU7tEhYQtWec2wqaT2O5j vyrSup2Mhr0lZudT8IQpZBehCZW9zxtI7rxgpXX5ywLa8YjZlO45B3mVNdRIHe2IEMRnq+3 8puDFzxiTy1B2t83Frumg== X-UI-Out-Filterresults: notjunk:1;V01:K0:Nz0/ohHpbRM=:BEDZeJAbtI1rfxFPk2pfv3 zCXt24fGgrVXsfiCwAlF3Io4yHCSadYVALULQKPorjDNXsE5nlH5D2EcJ7VQYfgZ5Z8TrU5rU hOqdvX2MbRisfoo+oJt34NLqRrKftwtcGvrYS+J3HSdqhZFEqDgWG7ZxwfoiIK+w5k4fJ8Dwt n9IamRfk/1gxeKSphRAeifxXTvDGCgfQlSf6Ze4ZqdUEunDRz86KuQCqFIfiyg4ydI5kApCVD nxTcLc/ZpPUKGH2SnADrEIQSy8CzoiDRQydb06rC0lBxX7DANbV+w4jrBPdC+mlRQMXzrNqSh VLoFOXh/SoA+9dseUtxgbqB+RThZ9XzOYlUd0a5DHfOoC1UUMtkG0/v5s+pOUYFjvNsNbMVYf OdwROojRnQUSFV3yEq3YT2Hf8D4yWHJUvAaVD78ASrslQiF26k5tAZ7RB4Pg4YHtCC539o8gV zkL6DoXaaqGx8z6I/1kvjr2TUCHrqOqy1o908LUtWFKEZjtuPcXlwNnu7WqaDMp7xohIX7izW 36xNJ0F1qwdaDf30R5E4PP2oz39exge83qLGEbRouEnI2LbjnasFgk2fro78b5drBzuP8FpFT HasAlpjnZ5oy0izSCatYWhAsvGY9LIryRD0p4mCDsSHZJgOezmShG5Oquv+Bt7gChu8878ewP 0bM8OWR/CMBEfgPlTmveTSrYqVnciuiGCQfLWRxdlMWE1OIJC5WwYAIzT6hxK9MRIg4zN7kyd 2CTBtvfCJo685GnD5nlbq/2RtY6jIg4P0ysp2ZyujzAE5zV6CXd9O6xk7ts= Archived-At: Cc: "Ace@ietf.org" Subject: Re: [Ace] draft-bergmann-ace-dcaf-cose-00 vs. draft-selander-ace-object-security-03 X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 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 Oct 2015 15:48:44 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --GjEDcLAQX1ri6gIk42wH7M8vJp3VSbNSJ Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Olaf, I took a look at draft-selander-ace-object-security-03 again and in Section 5 the document describes how CoAP messages are protected. This is motivated by the presence of intermediaries where DTLS terminates prematurely. You are proposing essentially the same but the test is written in such a way that it talks about DCAF. In your mail below you have said already that you believe that this work belongs to ACE. So, I believe you are saying that we should ask our AD to add another milestone for this type of work item. Another possibility is to see it as part of the overall solution and it may well be part of the solution document itself. Ciao Hannes On 10/28/2015 04:21 PM, Olaf Bergmann wrote: > Hi Hannes, >=20 > Hannes Tschofenig writes: >=20 >> We have gotten an agenda request for draft-bergmann-ace-dcaf-cose-00, >> which is about using COSE to provide a object-level security for DCAF.= >=20 > No, it's not. It is about providing authenticated authorization which i= s > clearly in the focus of the ACE WG. It does this by using DCAF. >=20 > At the IETF-93 meeting in Prague, several people criticized > draft-gerdes-ace-dcaf-authorize because it uses DTLS to provide secure > communication. The new draft-bergmann-ace-dcaf-cose specifies how DCAF > can be used with COSE syntax. It does *not* specify how object security= > works, it just *makes use* of what is already there. >=20 > The intention of the presentation therefore is to explain how DCAF can > be used in the presence of intermediaries. I am not going to discuss in= > ACE whether CoAP option X needs to be protected by mechanism Y as other= > people tried to. This is clearly something that needs to be discussed i= n > CORE and COSE where it belongs. Once a viable object security mechanism= > has been defined by these to working groups (my dcaf example shows that= > COSE is close by while CORE has some work to do in this regard). >=20 >> In previous IETF meetings we have heard about a more generic solution,= >=20 > Please, do not mix up things. DCAF-COSE is about authenticated > authorization, draft-selander-ace-object-security is about object > security. > =20 >> namely draft-selander-ace-object-security-03. It will be presented in >> COSE/CORE (if the requests get granted). >> >> Here is the issue: >> >> 1) Officially, we have no milestone in ACE to work on such a document = at >> all right now. >=20 > We are going to standardize a solution for authenticated authorization,= > aren't we? DCAF is a proposal for this, and draft-bergmann-ace-dcaf-cos= e > addresses on of the open issues that have been raised in the past. >=20 >> 2) Should we have a presentation about draft-bergmann-ace-dcaf-cose-00= >> when we have already heard about the more generic version before hand?= >=20 > See above. You are missing the point of draft-bergmann-ace-dcaf-cose. >=20 >> Hence, the question to the group is the following: >> >> a) Where does the COAP application layer security belong? Is ACE the >> right place or is it rather CORE or COSE? >=20 > COAP application layer security belongs to CORE. >=20 >> If it is ACE should we ask our AD to add another milestone? >> >> b) What would the purpose of a presentation of >> draft-bergmann-ace-dcaf-cose-00 >=20 > Addressing the issue raised at the Prague meeting: DCAF is a perfect fi= t > for ACE because it can be used with transport layer security and object= > security and is able to handle the three communication patterns that > have been brought on the table (IIRC they have been called "push", > "pull", and "client pull"). >=20 >> and / or draft-selander-ace-object-security-03 be in ACE for this >> meeting? >=20 > I am happy to discuss this I-D during COSE and CORE. >=20 >> If we indeed to the work in ACE then wouldn't it be a useful goal for >> the meeting be to make a decision about the solution direction? This >> would of course require us to listen to both solution directions rathe= r >> than only to one. I would in particular be interested what motivated t= he >> work on draft-bergmann-ace-dcaf-cose-00 given the existence of >> draft-selander-ace-object-security-03... >=20 > My hope is to have explained that it bit. draft-bergmann-ace-dcaf-cose > is not in concurrency to draft-selander-ace-object-security. It just > happens to use COSE in a more REST-like way. But that is a discussion > for CORE. Let ACE focus on the authorization aspects of both drafts > where draft-bergmann-ace-dcaf-cose is a perfect amendment of > draft-gerdes-ace-dcaf-authorize. >=20 > Gr=C3=BC=C3=9Fe > Olaf >=20 --GjEDcLAQX1ri6gIk42wH7M8vJp3VSbNSJ Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJWMO5NAAoJEGhJURNOOiAtn8gH/0xNb1Jy+SZJcKHkv4KiDsT2 D5xMAz60j5G+I+J54jfAdRkiHIlPSFI5Zk8VbPwiXhjIPI3bdsPpdrzRE9R/PENI gBuw76cKH9H0jrhM8jqif4gC6glNEMJVRLD9f78OzfH91eMGRyMmLKQ7btxsBwzW AQatSZauMaTazMQ1OZIiC2YykqbjXpq/sv1r6l50CLqT+ZG1yyuqST2RgM0d7t8p oxM1MHlfXMp+fzuVA2x/2XDqOwnSlKadcKLowhvbNOWGeJCC8bj24tQvbxaJmo0I kEbW9bNqy0RnFBPL98Dw2S9ZgGOgdYv9Gu0aJUF8eeNIgWwRd+iv/2UfJfH2Iq8= =c7Jg -----END PGP SIGNATURE----- --GjEDcLAQX1ri6gIk42wH7M8vJp3VSbNSJ-- From nobody Wed Oct 28 09:03:16 2015 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A114D1B5844 for ; Wed, 28 Oct 2015 09:03:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.55 X-Spam-Level: X-Spam-Status: No, score=-1.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QNf8POrZ7N7z for ; Wed, 28 Oct 2015 09:03:14 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 55FAA1A904A for ; Wed, 28 Oct 2015 09:02:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::b]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id t9SG2ZtA024265; Wed, 28 Oct 2015 17:02:35 +0100 (CET) Received: from aung.tzi.org (unknown [IPv6:2001:638:708:30da:211:22ff:fedd:aa18]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3nmF6M3vBQz2CYX; Wed, 28 Oct 2015 17:02:35 +0100 (CET) From: Olaf Bergmann To: Hannes Tschofenig References: <5630E097.6030508@gmx.net> <87oafjkohu.fsf@aung.informatik.uni-bremen.de> <5630EB61.3070407@gmx.net> Date: Wed, 28 Oct 2015 17:02:35 +0100 In-Reply-To: <5630EB61.3070407@gmx.net> (Hannes Tschofenig's message of "Wed, 28 Oct 2015 16:36:01 +0100") Message-ID: <87fv0vkmlg.fsf@aung.informatik.uni-bremen.de> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "Ace@ietf.org" Subject: Re: [Ace] draft-bergmann-ace-dcaf-cose-00 vs. draft-selander-ace-object-security-03 X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 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 Oct 2015 16:03:15 -0000 Hannes, Hannes Tschofenig writes: > I think you are playing with words a bit when you say it is about > "authenticated authorization rather than object security" when there is > clearly an overlap between the two solutions. I tried to make clear that I do not think that the ACE session is the right place to discuss the details of object security but rather to discuss how this can be used to achieve the goals of the ACE WG. The overlap is something that does not affect the work in the ACE WG. > Anyway, if you believe this is special to DCAF then it should be covered > as part of the DCAF presentation rather than as a separate solution. > > When I had a chat with Kepeng we noticed that you split up the solution > into separate different documents and I believe it would be a bit boring > for the working group to hear (Steffi, or Carsten) talk for 60 mins > about something that others only get 20 or 30mins only because they have > decided to put everything into one document. First of all: I was not aware that discussing different things in different documents is considered a bad thing. The split was made to avoid draft-gerdes-ace-dcaf-authorize getting too complex in this stage. If later in the process, the WG thinks that these two documents should be merged, we will be happy to do that. Regarding the agenda slot: We did not intend to talk 60 mins on the DCAF-related documents or have multiple slots for DCAF. Feel free to make it a single slot of 20--30 mins. Gr=C3=BC=C3=9Fe Olaf From nobody Wed Oct 28 09:21:45 2015 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70A881A90EE for ; Wed, 28 Oct 2015 09:21:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.55 X-Spam-Level: X-Spam-Status: No, score=-1.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GdLUkBO_luCY for ; Wed, 28 Oct 2015 09:21:42 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 560AB1A90E7 for ; Wed, 28 Oct 2015 09:21:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [134.102.201.11]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id t9SGLbSp007283; Wed, 28 Oct 2015 17:21:37 +0100 (CET) Received: from aung.tzi.org (unknown [IPv6:2001:638:708:30da:211:22ff:fedd:aa18]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3nmFXK44rrz2CZ2; Wed, 28 Oct 2015 17:21:37 +0100 (CET) From: Olaf Bergmann To: Hannes Tschofenig References: <5630E097.6030508@gmx.net> <87oafjkohu.fsf@aung.informatik.uni-bremen.de> <5630EE4D.7080202@gmx.net> Date: Wed, 28 Oct 2015 17:21:37 +0100 In-Reply-To: <5630EE4D.7080202@gmx.net> (Hannes Tschofenig's message of "Wed, 28 Oct 2015 16:48:29 +0100") Message-ID: <87a8r3klpq.fsf@aung.informatik.uni-bremen.de> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "Ace@ietf.org" Subject: Re: [Ace] draft-bergmann-ace-dcaf-cose-00 vs. draft-selander-ace-object-security-03 X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 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 Oct 2015 16:21:44 -0000 Hannes Tschofenig writes: > how CoAP messages are protected > You are proposing essentially the same but the test is written in such a > way that it talks about DCAF. Again: We have addressed the request for transferring DCAF in a way that allows for protecting the contents on the application layer instead of using transport layer security. Hence it should not come as a surprise that this document talks about DCAF. > In your mail below you have said already that you believe that this work > belongs to ACE. DCAF belongs to ACE. The question how CoAP messages are protected on the application layer IMO does not belong to ACE. I think that the CoAP experts in the CoRE WG should define how COSE can be used for that. Hence, it is a CoRE item. > So, I believe you are saying that we should ask our AD to add another > milestone for this type of work item. I am not sure I understand what you mean whith "this type of work item". > Another possibility is to see it as part of the overall solution and it > may well be part of the solution document itself. My approach would be to let CoRE (possibly together with COSE folks) standardize a mechanism to protect CoAP messages on the application layer and then use that mechanism for the authorization solution in ACE. We do this with DCAF-DTLS and that is also where DCAF-COSE is heading. But since CoRE does not yet have a working group item on the object security part I went for my own basic understanding of how COSE messaging is designed to be used. It is pretty much a high-level summary of which DCAF information item must go where, the details still to be worked out. Gr=C3=BC=C3=9Fe Olaf From nobody Wed Oct 28 14:17:21 2015 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CB7D1B5E41 for ; Wed, 28 Oct 2015 14:17:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.901 X-Spam-Level: X-Spam-Status: No, score=-3.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UHuXuFmghYUg for ; Wed, 28 Oct 2015 14:17:18 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 693CD1B5E3E for ; Wed, 28 Oct 2015 14:17:17 -0700 (PDT) X-AuditID: c1b4fb25-f79a26d00000149a-83-56313b5b3569 Received: from ESESSHC021.ericsson.se (Unknown_Domain [153.88.253.125]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id B8.B2.05274.B5B31365; Wed, 28 Oct 2015 22:17:15 +0100 (CET) Received: from ESESSMB303.ericsson.se ([169.254.3.10]) by ESESSHC021.ericsson.se ([153.88.183.81]) with mapi id 14.03.0248.002; Wed, 28 Oct 2015 22:17:15 +0100 From: =?utf-8?B?R8O2cmFuIFNlbGFuZGVy?= To: Olaf Bergmann , Hannes Tschofenig Thread-Topic: [Ace] draft-bergmann-ace-dcaf-cose-00 vs. draft-selander-ace-object-security-03 Thread-Index: AQHREY/yaUXOV48wzEG97jc1zGEkzp6BBZT6gABjU4A= Date: Wed, 28 Oct 2015 21:17:14 +0000 Message-ID: References: <5630E097.6030508@gmx.net> <87oafjkohu.fsf@aung.informatik.uni-bremen.de> In-Reply-To: <87oafjkohu.fsf@aung.informatik.uni-bremen.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.7.141117 x-originating-ip: [153.88.183.148] Content-Type: text/plain; charset="utf-8" Content-ID: <7A24C1E567BA90499419133F161BA34C@ericsson.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrEIsWRmVeSWpSXmKPExsUyM+JvrW60tWGYwaYmbYvv33qYLZoWNzJZ LN15j9WB2WPxpv1sHkuW/GTymLYoM4A5issmJTUnsyy1SN8ugSvjyvU/LAXzDCvefPnL2sD4 R7+LkZNDQsBE4vHq/8wQtpjEhXvr2boYuTiEBI4wSkx//wHKWcwo8eDeCXaQKjYBF4kHDY+Y QGwRgVCJpRvfsYDYzAKKErtnnQWq4eAQFoiT+NnpA1ESL3Hj12ZmCNtK4ujpN2A2i4CqxKOb O9hAbF4BC4nve1+CjRESCJf4f+gVG8gYTgFridb91iBhRqDbvp9awwSxSVzi1pP5TBA3C0gs 2XMe6n5RiZeP/7GC2KICehIrrzexQcSVJBqXPGEFGcksoCmxfpc+xBhrie5NCMdP6X7IDnGN oMTJmU9YJjBKzEKybRZC9ywk3bOQdM9C0r2AkXUVo2hxanFSbrqRsV5qUWZycXF+nl5easkm RmBMHtzyW3UH4+U3jocYBTgYlXh4PzwyCBNiTSwrrsw9xCjBwawkwivNYhgmxJuSWFmVWpQf X1Sak1p8iFGag0VJnLeZ6UGokEB6YklqdmpqQWoRTJaJg1OqgZE5Smddo5zd23KH6WfL3z2I /Xk1bcWJnfVTLBg+65cvaZ8X+lf19dqVk9brXD7DadUhdG9Z15bNuQf3/HbuUJ7AdpH3ikvB 28vfNPdMMN374pue5OrTit8n6mtdSfov/iB03o4tUqzPPm/otvK7lKFtt6LA9oPBWf+I+7Mv t7/aufXh8YTdSq+mKbEUZyQaajEXFScCABOnNpbFAgAA Archived-At: Cc: "Ace@ietf.org" Subject: Re: [Ace] draft-bergmann-ace-dcaf-cose-00 vs. draft-selander-ace-object-security-03 X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 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 Oct 2015 21:17:20 -0000 DQpIaSBPbGFmLCBIYW5uZXMsIGFuZCBhbGwsDQoNCkxhc3Qgd2VlayBJIHBvaW50ZWQgb3V0IHNv bWUgZmxhd3MgaW4gdGhlIHNlY3VyaXR5IHNvbHV0aW9uIG9mIERDQUYNCihkcmFmdC1iZXJnbWFu bi1hY2UtZGNhZi1jb3NlLTAwKS4gSGVyZSBpcyB0aGUgbWFpbDoNCg0KaHR0cDovL3d3dy5pZXRm Lm9yZy9tYWlsLWFyY2hpdmUvd2ViL2FjZS9jdXJyZW50L21zZzAxNDc4Lmh0bWwNCg0KSSBoYXZl buKAmXQgc2VlbiBhbnkgcmVwbHkgdG8gdGhhdC4gTWVhbndoaWxlIEkgZG9u4oCZdCBjb25zaWRl ciBEQ0FGLUNPU0UgdG8NCmJlIGEgc29sdXRpb24gdG8gYW55dGhpbmcuDQoNCknigJltIG5vdCB0 aGUgb25lIHNldHRpbmcgdGhlIGFnZW5kYSwgYnV0IGluIG9yZGVyIHRvIHJlc2VydmUgdGltZSBm b3IgYQ0KZHJhZnQgYXQgdGhlIEYyRiBtZWV0aW5nLCBpc27igJl0IGl0IHJlYXNvbmFibGUgdGhh dCB0aGUgYXV0aG9ycyBiZWZvcmUgdGhlDQptZWV0aW5nIGF0IGxlYXN0IG1ha2UgaXQgcGxhdXNp YmxlIHRoYXQgdGhlaXIgc2VjdXJpdHkgc29sdXRpb24gY2FuIHdvcms/DQoNCg0KR8O2cmFuDQoN Cg0KDQpPbiAyMDE1LTEwLTI4IDE2OjIxLCAiT2xhZiBCZXJnbWFubiIgPGJlcmdtYW5uQHR6aS5v cmc+IHdyb3RlOg0KDQo+SGkgSGFubmVzLA0KPg0KPkhhbm5lcyBUc2Nob2ZlbmlnIDxoYW5uZXMu dHNjaG9mZW5pZ0BnbXgubmV0PiB3cml0ZXM6DQo+DQo+PiBXZSBoYXZlIGdvdHRlbiBhbiBhZ2Vu ZGEgcmVxdWVzdCBmb3IgZHJhZnQtYmVyZ21hbm4tYWNlLWRjYWYtY29zZS0wMCwNCj4+IHdoaWNo IGlzIGFib3V0IHVzaW5nIENPU0UgdG8gcHJvdmlkZSBhIG9iamVjdC1sZXZlbCBzZWN1cml0eSBm b3IgRENBRi4NCj4NCj5ObywgaXQncyBub3QuIEl0IGlzIGFib3V0IHByb3ZpZGluZyBhdXRoZW50 aWNhdGVkIGF1dGhvcml6YXRpb24gd2hpY2ggaXMNCj5jbGVhcmx5IGluIHRoZSBmb2N1cyBvZiB0 aGUgQUNFIFdHLiBJdCBkb2VzIHRoaXMgYnkgdXNpbmcgRENBRi4NCj4NCj5BdCB0aGUgSUVURi05 MyBtZWV0aW5nIGluIFByYWd1ZSwgc2V2ZXJhbCBwZW9wbGUgY3JpdGljaXplZA0KPmRyYWZ0LWdl cmRlcy1hY2UtZGNhZi1hdXRob3JpemUgYmVjYXVzZSBpdCB1c2VzIERUTFMgdG8gcHJvdmlkZSBz ZWN1cmUNCj5jb21tdW5pY2F0aW9uLiBUaGUgbmV3IGRyYWZ0LWJlcmdtYW5uLWFjZS1kY2FmLWNv c2Ugc3BlY2lmaWVzIGhvdyBEQ0FGDQo+Y2FuIGJlIHVzZWQgd2l0aCBDT1NFIHN5bnRheC4gSXQg ZG9lcyAqbm90KiBzcGVjaWZ5IGhvdyBvYmplY3Qgc2VjdXJpdHkNCj53b3JrcywgaXQganVzdCAq bWFrZXMgdXNlKiBvZiB3aGF0IGlzIGFscmVhZHkgdGhlcmUuDQo+DQo+VGhlIGludGVudGlvbiBv ZiB0aGUgcHJlc2VudGF0aW9uIHRoZXJlZm9yZSBpcyB0byBleHBsYWluIGhvdyBEQ0FGIGNhbg0K PmJlIHVzZWQgaW4gdGhlIHByZXNlbmNlIG9mIGludGVybWVkaWFyaWVzLiBJIGFtIG5vdCBnb2lu ZyB0byBkaXNjdXNzIGluDQo+QUNFIHdoZXRoZXIgQ29BUCBvcHRpb24gWCBuZWVkcyB0byBiZSBw cm90ZWN0ZWQgYnkgbWVjaGFuaXNtIFkgYXMgb3RoZXINCj5wZW9wbGUgdHJpZWQgdG8uIFRoaXMg aXMgY2xlYXJseSBzb21ldGhpbmcgdGhhdCBuZWVkcyB0byBiZSBkaXNjdXNzZWQgaW4NCj5DT1JF IGFuZCBDT1NFIHdoZXJlIGl0IGJlbG9uZ3MuIE9uY2UgYSB2aWFibGUgb2JqZWN0IHNlY3VyaXR5 IG1lY2hhbmlzbQ0KPmhhcyBiZWVuIGRlZmluZWQgYnkgdGhlc2UgdG8gd29ya2luZyBncm91cHMg KG15IGRjYWYgZXhhbXBsZSBzaG93cyB0aGF0DQo+Q09TRSBpcyBjbG9zZSBieSB3aGlsZSBDT1JF IGhhcyBzb21lIHdvcmsgdG8gZG8gaW4gdGhpcyByZWdhcmQpLg0KPg0KPj4gSW4gcHJldmlvdXMg SUVURiBtZWV0aW5ncyB3ZSBoYXZlIGhlYXJkIGFib3V0IGEgbW9yZSBnZW5lcmljIHNvbHV0aW9u LA0KPg0KPlBsZWFzZSwgZG8gbm90IG1peCB1cCB0aGluZ3MuIERDQUYtQ09TRSBpcyBhYm91dCBh dXRoZW50aWNhdGVkDQo+YXV0aG9yaXphdGlvbiwgZHJhZnQtc2VsYW5kZXItYWNlLW9iamVjdC1z ZWN1cml0eSBpcyBhYm91dCBvYmplY3QNCj5zZWN1cml0eS4NCj4gDQo+PiBuYW1lbHkgZHJhZnQt c2VsYW5kZXItYWNlLW9iamVjdC1zZWN1cml0eS0wMy4gSXQgd2lsbCBiZSBwcmVzZW50ZWQgaW4N Cj4+IENPU0UvQ09SRSAoaWYgdGhlIHJlcXVlc3RzIGdldCBncmFudGVkKS4NCj4+DQo+PiBIZXJl IGlzIHRoZSBpc3N1ZToNCj4+DQo+PiAxKSBPZmZpY2lhbGx5LCB3ZSBoYXZlIG5vIG1pbGVzdG9u ZSBpbiBBQ0UgdG8gd29yayBvbiBzdWNoIGEgZG9jdW1lbnQgYXQNCj4+IGFsbCByaWdodCBub3cu DQo+DQo+V2UgYXJlIGdvaW5nIHRvIHN0YW5kYXJkaXplIGEgc29sdXRpb24gZm9yIGF1dGhlbnRp Y2F0ZWQgYXV0aG9yaXphdGlvbiwNCj5hcmVuJ3Qgd2U/IERDQUYgaXMgYSBwcm9wb3NhbCBmb3Ig dGhpcywgYW5kIGRyYWZ0LWJlcmdtYW5uLWFjZS1kY2FmLWNvc2UNCj5hZGRyZXNzZXMgb24gb2Yg dGhlIG9wZW4gaXNzdWVzIHRoYXQgaGF2ZSBiZWVuIHJhaXNlZCBpbiB0aGUgcGFzdC4NCj4NCj4+ IDIpIFNob3VsZCB3ZSBoYXZlIGEgcHJlc2VudGF0aW9uIGFib3V0IGRyYWZ0LWJlcmdtYW5uLWFj ZS1kY2FmLWNvc2UtMDANCj4+IHdoZW4gd2UgaGF2ZSBhbHJlYWR5IGhlYXJkIGFib3V0IHRoZSBt b3JlIGdlbmVyaWMgdmVyc2lvbiBiZWZvcmUgaGFuZD8NCj4NCj5TZWUgYWJvdmUuIFlvdSBhcmUg bWlzc2luZyB0aGUgcG9pbnQgb2YgZHJhZnQtYmVyZ21hbm4tYWNlLWRjYWYtY29zZS4NCj4NCj4+ IEhlbmNlLCB0aGUgcXVlc3Rpb24gdG8gdGhlIGdyb3VwIGlzIHRoZSBmb2xsb3dpbmc6DQo+Pg0K Pj4gYSkgV2hlcmUgZG9lcyB0aGUgQ09BUCBhcHBsaWNhdGlvbiBsYXllciBzZWN1cml0eSBiZWxv bmc/IElzIEFDRSB0aGUNCj4+IHJpZ2h0IHBsYWNlIG9yIGlzIGl0IHJhdGhlciBDT1JFIG9yIENP U0U/DQo+DQo+Q09BUCBhcHBsaWNhdGlvbiBsYXllciBzZWN1cml0eSBiZWxvbmdzIHRvIENPUkUu DQo+DQo+PiBJZiBpdCBpcyBBQ0Ugc2hvdWxkIHdlIGFzayBvdXIgQUQgdG8gYWRkIGFub3RoZXIg bWlsZXN0b25lPw0KPj4NCj4+IGIpIFdoYXQgd291bGQgdGhlIHB1cnBvc2Ugb2YgYSBwcmVzZW50 YXRpb24gb2YNCj4+IGRyYWZ0LWJlcmdtYW5uLWFjZS1kY2FmLWNvc2UtMDANCj4NCj5BZGRyZXNz aW5nIHRoZSBpc3N1ZSByYWlzZWQgYXQgdGhlIFByYWd1ZSBtZWV0aW5nOiBEQ0FGIGlzIGEgcGVy ZmVjdCBmaXQNCj5mb3IgQUNFIGJlY2F1c2UgaXQgY2FuIGJlIHVzZWQgd2l0aCB0cmFuc3BvcnQg bGF5ZXIgc2VjdXJpdHkgYW5kIG9iamVjdA0KPnNlY3VyaXR5IGFuZCBpcyBhYmxlIHRvIGhhbmRs ZSB0aGUgdGhyZWUgY29tbXVuaWNhdGlvbiBwYXR0ZXJucyB0aGF0DQo+aGF2ZSBiZWVuIGJyb3Vn aHQgb24gdGhlIHRhYmxlIChJSVJDIHRoZXkgaGF2ZSBiZWVuIGNhbGxlZCAicHVzaCIsDQo+InB1 bGwiLCBhbmQgImNsaWVudCBwdWxsIikuDQo+DQo+PiBhbmQgLyBvciBkcmFmdC1zZWxhbmRlci1h Y2Utb2JqZWN0LXNlY3VyaXR5LTAzIGJlIGluIEFDRSBmb3IgdGhpcw0KPj4gbWVldGluZz8NCj4N Cj5JIGFtIGhhcHB5IHRvIGRpc2N1c3MgdGhpcyBJLUQgZHVyaW5nIENPU0UgYW5kIENPUkUuDQo+ DQo+PiBJZiB3ZSBpbmRlZWQgdG8gdGhlIHdvcmsgaW4gQUNFIHRoZW4gd291bGRuJ3QgaXQgYmUg YSB1c2VmdWwgZ29hbCBmb3INCj4+IHRoZSBtZWV0aW5nIGJlIHRvIG1ha2UgYSBkZWNpc2lvbiBh Ym91dCB0aGUgc29sdXRpb24gZGlyZWN0aW9uPyBUaGlzDQo+PiB3b3VsZCBvZiBjb3Vyc2UgcmVx dWlyZSB1cyB0byBsaXN0ZW4gdG8gYm90aCBzb2x1dGlvbiBkaXJlY3Rpb25zIHJhdGhlcg0KPj4g dGhhbiBvbmx5IHRvIG9uZS4gSSB3b3VsZCBpbiBwYXJ0aWN1bGFyIGJlIGludGVyZXN0ZWQgd2hh dCBtb3RpdmF0ZWQgdGhlDQo+PiB3b3JrIG9uIGRyYWZ0LWJlcmdtYW5uLWFjZS1kY2FmLWNvc2Ut MDAgIGdpdmVuIHRoZSBleGlzdGVuY2Ugb2YNCj4+IGRyYWZ0LXNlbGFuZGVyLWFjZS1vYmplY3Qt c2VjdXJpdHktMDMuLi4NCj4NCj5NeSBob3BlIGlzIHRvIGhhdmUgZXhwbGFpbmVkIHRoYXQgaXQg Yml0LiBkcmFmdC1iZXJnbWFubi1hY2UtZGNhZi1jb3NlDQo+aXMgbm90IGluIGNvbmN1cnJlbmN5 IHRvIGRyYWZ0LXNlbGFuZGVyLWFjZS1vYmplY3Qtc2VjdXJpdHkuIEl0IGp1c3QNCj5oYXBwZW5z IHRvIHVzZSBDT1NFIGluIGEgbW9yZSBSRVNULWxpa2Ugd2F5LiBCdXQgdGhhdCBpcyBhIGRpc2N1 c3Npb24NCj5mb3IgQ09SRS4gTGV0IEFDRSBmb2N1cyBvbiB0aGUgYXV0aG9yaXphdGlvbiBhc3Bl Y3RzIG9mIGJvdGggZHJhZnRzDQo+d2hlcmUgZHJhZnQtYmVyZ21hbm4tYWNlLWRjYWYtY29zZSBp cyBhIHBlcmZlY3QgYW1lbmRtZW50IG9mDQo+ZHJhZnQtZ2VyZGVzLWFjZS1kY2FmLWF1dGhvcml6 ZS4NCj4NCj5HcsO8w59lDQo+T2xhZg0KPg0KPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQo+QWNlIG1haWxpbmcgbGlzdA0KPkFjZUBpZXRmLm9yZw0KPmh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vYWNlDQoNCg== From nobody Wed Oct 28 17:41:32 2015 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBBA71B607E for ; Wed, 28 Oct 2015 17:41:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.25 X-Spam-Level: X-Spam-Status: No, score=-1.25 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1zsw_3uyeJv1 for ; Wed, 28 Oct 2015 17:41:29 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CBAFA1B6079 for ; Wed, 28 Oct 2015 17:41:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::b]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id t9T0f4bT024759; Thu, 29 Oct 2015 01:41:04 +0100 (CET) Received: from dhcp-private-21-117.tpac.keio.w3.org (unknown [210.227.101.101]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3nmScY72F7z2CjK; Thu, 29 Oct 2015 01:41:01 +0100 (CET) Message-ID: <56316B19.2060800@tzi.org> Date: Thu, 29 Oct 2015 09:40:57 +0900 From: Carsten Bormann User-Agent: Postbox 4.0.7 (Macintosh/20151021) MIME-Version: 1.0 To: =?UTF-8?B?R8O2cmFuIFNlbGFuZGVy?= References: <5630E097.6030508@gmx.net> <87oafjkohu.fsf@aung.informatik.uni-bremen.de> In-Reply-To: X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: Hannes Tschofenig , Olaf Bergmann , "Ace@ietf.org" Subject: Re: [Ace] draft-bergmann-ace-dcaf-cose-00 vs. draft-selander-ace-object-security-03 X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 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, 29 Oct 2015 00:41:32 -0000 Göran, maybe I didn't pay enough attention, but I thought what you pointed out was not so much a security flaw but protecting too much: There are some transformations that might be performed by a proxy that are detected by the current version of DCAF-COSE (and thus would be rejected). The OSCOAP draft addresses this by either not protecting this information (PAYL, now called OSCON) or by a somewhat more invasive approach to CoAP attributes (new options, what you call OSCOAP now). Which CoAP attributes need to be protected in what use cases (and how the attributes might have to change to enable protecting them better) is an important discussion to have; we had that on the CoRE agenda already but I just allocated more time to that. What I expect ACE to deliver is the security protocol for setting up that protection. Grüße, Carsten Göran Selander wrote: > Hi Olaf, Hannes, and all, > > Last week I pointed out some flaws in the security solution of DCAF > (draft-bergmann-ace-dcaf-cose-00). Here is the mail: > > http://www.ietf.org/mail-archive/web/ace/current/msg01478.html > > I haven’t seen any reply to that. Meanwhile I don’t consider DCAF-COSE to > be a solution to anything. > > I’m not the one setting the agenda, but in order to reserve time for a > draft at the F2F meeting, isn’t it reasonable that the authors before the > meeting at least make it plausible that their security solution can work? > > > Göran > > > > On 2015-10-28 16:21, "Olaf Bergmann" wrote: > >> Hi Hannes, >> >> Hannes Tschofenig writes: >> >>> We have gotten an agenda request for draft-bergmann-ace-dcaf-cose-00, >>> which is about using COSE to provide a object-level security for DCAF. >> No, it's not. It is about providing authenticated authorization which is >> clearly in the focus of the ACE WG. It does this by using DCAF. >> >> At the IETF-93 meeting in Prague, several people criticized >> draft-gerdes-ace-dcaf-authorize because it uses DTLS to provide secure >> communication. The new draft-bergmann-ace-dcaf-cose specifies how DCAF >> can be used with COSE syntax. It does *not* specify how object security >> works, it just *makes use* of what is already there. >> >> The intention of the presentation therefore is to explain how DCAF can >> be used in the presence of intermediaries. I am not going to discuss in >> ACE whether CoAP option X needs to be protected by mechanism Y as other >> people tried to. This is clearly something that needs to be discussed in >> CORE and COSE where it belongs. Once a viable object security mechanism >> has been defined by these to working groups (my dcaf example shows that >> COSE is close by while CORE has some work to do in this regard). >> >>> In previous IETF meetings we have heard about a more generic solution, >> Please, do not mix up things. DCAF-COSE is about authenticated >> authorization, draft-selander-ace-object-security is about object >> security. >> >>> namely draft-selander-ace-object-security-03. It will be presented in >>> COSE/CORE (if the requests get granted). >>> >>> Here is the issue: >>> >>> 1) Officially, we have no milestone in ACE to work on such a document at >>> all right now. >> We are going to standardize a solution for authenticated authorization, >> aren't we? DCAF is a proposal for this, and draft-bergmann-ace-dcaf-cose >> addresses on of the open issues that have been raised in the past. >> >>> 2) Should we have a presentation about draft-bergmann-ace-dcaf-cose-00 >>> when we have already heard about the more generic version before hand? >> See above. You are missing the point of draft-bergmann-ace-dcaf-cose. >> >>> Hence, the question to the group is the following: >>> >>> a) Where does the COAP application layer security belong? Is ACE the >>> right place or is it rather CORE or COSE? >> COAP application layer security belongs to CORE. >> >>> If it is ACE should we ask our AD to add another milestone? >>> >>> b) What would the purpose of a presentation of >>> draft-bergmann-ace-dcaf-cose-00 >> Addressing the issue raised at the Prague meeting: DCAF is a perfect fit >> for ACE because it can be used with transport layer security and object >> security and is able to handle the three communication patterns that >> have been brought on the table (IIRC they have been called "push", >> "pull", and "client pull"). >> >>> and / or draft-selander-ace-object-security-03 be in ACE for this >>> meeting? >> I am happy to discuss this I-D during COSE and CORE. >> >>> If we indeed to the work in ACE then wouldn't it be a useful goal for >>> the meeting be to make a decision about the solution direction? This >>> would of course require us to listen to both solution directions rather >>> than only to one. I would in particular be interested what motivated the >>> work on draft-bergmann-ace-dcaf-cose-00 given the existence of >>> draft-selander-ace-object-security-03... >> My hope is to have explained that it bit. draft-bergmann-ace-dcaf-cose >> is not in concurrency to draft-selander-ace-object-security. It just >> happens to use COSE in a more REST-like way. But that is a discussion >> for CORE. Let ACE focus on the authorization aspects of both drafts >> where draft-bergmann-ace-dcaf-cose is a perfect amendment of >> draft-gerdes-ace-dcaf-authorize. >> >> Grüße >> Olaf >> >> _______________________________________________ >> 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 Wed Oct 28 18:10:00 2015 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECAF11B60DF for ; Wed, 28 Oct 2015 18:09:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.298 X-Spam-Level: *** X-Spam-Status: No, score=3.298 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, MIME_BAD_LINEBREAK=0.5, RDNS_NONE=0.793, UNPARSEABLE_RELAY=0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IBeIONtvGvRR for ; Wed, 28 Oct 2015 18:09:57 -0700 (PDT) Received: from mailgw02.mediatek.com (unknown [66.228.70.112]) by ietfa.amsl.com (Postfix) with ESMTP id 388D91B60C7 for ; Wed, 28 Oct 2015 18:09:56 -0700 (PDT) X-Listener-Flag: 11101 Received: from mtkcas64.mediatek.inc [(172.29.17.144)] by mailgw02.mediatek.com (envelope-from ) (Cellopoint E-mail Firewall v3.9.12 Build 0312 with TLS) with ESMTP id 844078983; Wed, 28 Oct 2015 21:00:19 -0500 Received: from MTKCAS63.mediatek.inc (172.29.17.143) by MTKCAS64.mediatek.inc (172.29.17.144) with Microsoft SMTP Server (TLS) id 14.3.181.6; Wed, 28 Oct 2015 21:09:53 -0400 Received: from MTKMBS61N1.mediatek.inc ([fe80::2898:86df:e627:42ee]) by MTKCAS63.mediatek.inc ([fe80::69ba:ee95:46f7:711d%10]) with mapi id 14.03.0181.006; Wed, 28 Oct 2015 21:09:53 -0400 From: Madjid Nakhjiri To: "ace@ietf.org" Thread-Topic: comments on draft-seitz-ace-oauth-authz-00 Thread-Index: AQHREeZtLoYHI1sV0UKYlZCdCQHqyw== Date: Thu, 29 Oct 2015 01:09:52 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.29.122.112] Content-Type: multipart/alternative; boundary="_000_D256BFEE69BEmadjidnakhjirimediatekcom_" MIME-Version: 1.0 X-TM-AS-Product-Ver: SMEX-10.2.0.3176-8.000.1202-21908.003 X-TM-AS-Result: No--11.909500-8.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No Archived-At: Subject: [Ace] comments on draft-seitz-ace-oauth-authz-00 X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 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, 29 Oct 2015 01:09:59 -0000 --_000_D256BFEE69BEmadjidnakhjirimediatekcom_ Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: quoted-printable Hi all, authors of the draft I was asked to review by one of the authors and I did it last week=2E = Unfortunately, I have not read all the drafts/ RFCs that the draft is = referencing, and my knowledge of OAUTH is a few years old, so I apologize = for potential ignorance on that regard =2E I think the draft is doing a good job of trying to create a = =1B$B!H=1B(Bsystem solution=1B$B!I=1B(B by bringing OAUTH, COAP, CBOR and = the app layer security solutions together=2E Issues that I see with the over all framework that still requires = addressing (within IETF??): 1=2E provisioning of client keys for authentication and registration = with the AS=2E Having a global key/ID in the client has been an issue for = some OAUTH implementations in the past=2E Given that the clients are IoT = devices, this is not as straight forward as mobile app clients=2E 2=2E Same thing for RS to AS registration=2E RS is many times a = constrained device itself=2E Also I am not clear how the AS will get the = authorization policies (scope/claim?) from RS=2E Is it that it is the AS = that decides?? 3=2E Is authorization subject based (identity of client) or role based? 4=2E Restrospection of the tokens can be expensive and unscalable for = the AS (if there are many RS nodes), but verification of self-contained = tokens by the RS also sounds expensive, plus the verification keys need to = be provisioned in the RS=2E Would be nice to have guidance on which makes = sense taking device capabilities/class into account=2E Any network = simulators out there? 5=2E Wonder if the two app layer security solutions (OSCOAP/ OSCON) = cover the provisioning of the keys they are using? 6=2E If COAP option max length is 256 bits, how can a signature = mechanism that requires that many bits be used? Regards, Madjid Nakhjiri =1B$BG~;VF@=1B(B Principal Security Architect MediaTek Inc=2E =1B$B!H=1B(BSimplicity is the ultimate sophistication" =0D --_000_D256BFEE69BEmadjidnakhjirimediatekcom_ Content-Type: text/html; charset="iso-2022-jp" Content-ID: <659825E7087805408967530EF5106499@mediatek.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PWlzby0yMDIyLWpwIj4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3 b3JkLXdyYXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1s aW5lLWJyZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1z aXplOiAxNHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KPGRpdj4NCjxk aXY+DQo8ZGl2PkhpIGFsbCwgYXV0aG9ycyBvZiB0aGUgZHJhZnQ8L2Rpdj4NCjxkaXY+PGJyPg0K PC9kaXY+DQo8ZGl2Pkkgd2FzIGFza2VkIHRvIHJldmlldyBieSBvbmUgb2YgdGhlIGF1dGhvcnMg YW5kIEkgZGlkIGl0IGxhc3Qgd2Vlay4gVW5mb3J0dW5hdGVseSwgSSBoYXZlIG5vdCByZWFkIGFs bCB0aGUgZHJhZnRzLyBSRkNzIHRoYXQgdGhlIGRyYWZ0IGlzIHJlZmVyZW5jaW5nLCZuYnNwO2Fu ZCBteSBrbm93bGVkZ2Ugb2YgT0FVVEggaXMgYSBmZXcgeWVhcnMgb2xkLCBzbyAmbmJzcDtJIGFw b2xvZ2l6ZSBmb3IgcG90ZW50aWFsIGlnbm9yYW5jZSBvbiB0aGF0IHJlZ2FyZA0KIC4mbmJzcDs8 L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PkkgdGhpbmsgdGhlIGRyYWZ0IGlzIGRvaW5n IGEgZ29vZCBqb2Igb2YgdHJ5aW5nIHRvIGNyZWF0ZSBhIBskQiFIGyhCc3lzdGVtIHNvbHV0aW9u GyRCIUkbKEIgYnkgYnJpbmdpbmcgT0FVVEgsIENPQVAsIENCT1IgYW5kIHRoZSBhcHAgbGF5ZXIg c2VjdXJpdHkgc29sdXRpb25zIHRvZ2V0aGVyLiZuYnNwOzwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rp dj4NCjxkaXY+SXNzdWVzIHRoYXQgSSBzZWUgd2l0aCB0aGUgb3ZlciBhbGwgZnJhbWV3b3JrIHRo YXQgc3RpbGwgcmVxdWlyZXMgYWRkcmVzc2luZyAod2l0aGluIElFVEY/Pyk6Jm5ic3A7PC9kaXY+ DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPG9sPg0KPGxpPnByb3Zpc2lvbmluZyBvZiBjbGllbnQga2V5 cyBmb3IgYXV0aGVudGljYXRpb24gYW5kIHJlZ2lzdHJhdGlvbiB3aXRoIHRoZSBBUy4gSGF2aW5n IGEgZ2xvYmFsIGtleS9JRCBpbiB0aGUgY2xpZW50IGhhcyBiZWVuIGFuIGlzc3VlIGZvciBzb21l IE9BVVRIIGltcGxlbWVudGF0aW9ucyBpbiB0aGUgcGFzdC4gR2l2ZW4gdGhhdCB0aGUgY2xpZW50 cyBhcmUgSW9UIGRldmljZXMsIHRoaXMgaXMgbm90IGFzIHN0cmFpZ2h0IGZvcndhcmQgYXMgbW9i aWxlDQogYXBwIGNsaWVudHMuJm5ic3A7PC9saT48bGk+U2FtZSB0aGluZyBmb3IgUlMgdG8gQVMg cmVnaXN0cmF0aW9uLiBSUyBpcyBtYW55IHRpbWVzIGEgY29uc3RyYWluZWQgZGV2aWNlIGl0c2Vs Zi4gQWxzbyBJIGFtIG5vdCBjbGVhciBob3cgdGhlIEFTIHdpbGwgZ2V0IHRoZSBhdXRob3JpemF0 aW9uIHBvbGljaWVzIChzY29wZS9jbGFpbT8pIGZyb20gUlMuIElzIGl0IHRoYXQgaXQgaXMgdGhl IEFTIHRoYXQgZGVjaWRlcz8/PC9saT48bGk+SXMgYXV0aG9yaXphdGlvbiBzdWJqZWN0IGJhc2Vk IChpZGVudGl0eSBvZiBjbGllbnQpIG9yIHJvbGUgYmFzZWQ/PC9saT48bGk+UmVzdHJvc3BlY3Rp b24gb2YgdGhlIHRva2VucyBjYW4gYmUgZXhwZW5zaXZlIGFuZCB1bnNjYWxhYmxlIGZvciB0aGUg QVMgKGlmIHRoZXJlIGFyZSBtYW55IFJTIG5vZGVzKSwgYnV0IHZlcmlmaWNhdGlvbiBvZiBzZWxm LWNvbnRhaW5lZCB0b2tlbnMgYnkgdGhlIFJTIGFsc28gc291bmRzIGV4cGVuc2l2ZSwgcGx1cyB0 aGUgdmVyaWZpY2F0aW9uIGtleXMgbmVlZCB0byBiZSBwcm92aXNpb25lZCBpbiB0aGUgUlMuIFdv dWxkIGJlIG5pY2UgdG8NCiBoYXZlIGd1aWRhbmNlIG9uIHdoaWNoIG1ha2VzIHNlbnNlIHRha2lu ZyBkZXZpY2UgY2FwYWJpbGl0aWVzL2NsYXNzIGludG8gYWNjb3VudC4gQW55IG5ldHdvcmsgc2lt dWxhdG9ycyBvdXQgdGhlcmU/PC9saT48bGk+V29uZGVyIGlmIHRoZSB0d28gYXBwIGxheWVyIHNl Y3VyaXR5IHNvbHV0aW9ucyAoT1NDT0FQLyBPU0NPTikgY292ZXIgdGhlIHByb3Zpc2lvbmluZyBv ZiB0aGUga2V5cyB0aGV5IGFyZSB1c2luZz88L2xpPjxsaT5JZiBDT0FQIG9wdGlvbiBtYXggbGVu Z3RoIGlzIDI1NiBiaXRzLCBob3cgY2FuIGEgc2lnbmF0dXJlIG1lY2hhbmlzbSB0aGF0IHJlcXVp cmVzIHRoYXQgbWFueSBiaXRzIGJlIHVzZWQ/PC9saT48L29sPg0KPGRpdj48YnI+DQo8L2Rpdj4N CjxkaXY+DQo8ZGl2PlJlZ2FyZHMsPC9kaXY+DQo8ZGl2PjxiPk1hZGppZCBOYWtoamlyaTwvYj48 L2Rpdj4NCjxkaXY+PHNwYW4gc3R5bGU9ImxpbmUtaGVpZ2h0OiAxMS4xOTk5OTk4MDkyNjUxMzdw eDsgdGV4dC1pbmRlbnQ6IDBpbjsgbGV0dGVyLXNwYWNpbmc6IC0xLjVwdDsiPhskQkd+O1ZGQBso QiZuYnNwOzwvc3Bhbj48L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW46 IDBpbiAwaW4gMC4wMDAxcHQ7Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMHB0OyBmb250LWZh bWlseTogQ2FsaWJyaTsgY29sb3I6IHJnYig0MCwgNDEsIDM2KTsiPlByaW5jaXBhbCBTZWN1cml0 eSBBcmNoaXRlY3QmbmJzcDs8L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsiPjxiPjx1PjxzcGFuIHN0eWxlPSJmb250LXNpemU6 IDEwcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpOyBjb2xvcjogcmdiKDIzOCwgMTM2LCAyNSk7Ij5N ZWRpYTwvc3Bhbj48L3U+PC9iPjxiPjx1PjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDEwcHQ7IGZv bnQtZmFtaWx5OiBDYWxpYnJpOyBjb2xvcjogcmdiKDIzOCwgMTM2LCAyNSk7Ij5UPC9zcGFuPjwv dT48L2I+PGI+PHU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTBwdDsgZm9udC1mYW1pbHk6IENh bGlicmk7IGNvbG9yOiByZ2IoMjM4LCAxMzYsIDI1KTsiPmVrDQogSW5jLjxvOnA+PC9vOnA+PC9z cGFuPjwvdT48L2I+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbjogMGlu IDBpbiAwLjAwMDFwdDsiPjxmb250IGZhY2U9IkNhbWJyaWEiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6IDEycHg7Ij4bJEIhSBsoQlNpbXBsaWNpdHkgaXMgdGhlIHVsdGltYXRlIHNvcGhpc3RpY2F0 aW9uJnF1b3Q7PC9zcGFuPjwvZm9udD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jv ZHk+DQo8L2h0bWw+DQoNPHRhYmxlPjx0cj48dGQ+PCEtLXR5cGU6dGV4dC0tPjwhLS17LS0+PHBy ZT4qKioqKioqKioqKioqIEVtYWlsIENvbmZpZGVudGlhbGl0eSBOb3RpY2UgKioqKioqKioqKioq KioqKioqKioNClRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaW4gdGhpcyBlLW1haWwgbWVzc2Fn ZSAoaW5jbHVkaW5nIGFueSANCmF0dGFjaG1lbnRzKSBtYXkgYmUgY29uZmlkZW50aWFsLCBwcm9w cmlldGFyeSwgcHJpdmlsZWdlZCwgb3Igb3RoZXJ3aXNlDQpleGVtcHQgZnJvbSBkaXNjbG9zdXJl IHVuZGVyIGFwcGxpY2FibGUgbGF3cy4gSXQgaXMgaW50ZW5kZWQgdG8gYmUgDQpjb252ZXllZCBv bmx5IHRvIHRoZSBkZXNpZ25hdGVkIHJlY2lwaWVudChzKS4gQW55IHVzZSwgZGlzc2VtaW5hdGlv biwgDQpkaXN0cmlidXRpb24sIHByaW50aW5nLCByZXRhaW5pbmcgb3IgY29weWluZyBvZiB0aGlz IGUtbWFpbCAoaW5jbHVkaW5nIGl0cyANCmF0dGFjaG1lbnRzKSBieSB1bmludGVuZGVkIHJlY2lw aWVudChzKSBpcyBzdHJpY3RseSBwcm9oaWJpdGVkIGFuZCBtYXkgDQpiZSB1bmxhd2Z1bC4gSWYg eW91IGFyZSBub3QgYW4gaW50ZW5kZWQgcmVjaXBpZW50IG9mIHRoaXMgZS1tYWlsLCBvciBiZWxp ZXZlIA0KdGhhdCB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGUtbWFpbCBpbiBlcnJvciwgcGxlYXNl IG5vdGlmeSB0aGUgc2VuZGVyIA0KaW1tZWRpYXRlbHkgKGJ5IHJlcGx5aW5nIHRvIHRoaXMgZS1t YWlsKSwgZGVsZXRlIGFueSBhbmQgYWxsIGNvcGllcyBvZiANCnRoaXMgZS1tYWlsIChpbmNsdWRp bmcgYW55IGF0dGFjaG1lbnRzKSBmcm9tIHlvdXIgc3lzdGVtLCBhbmQgZG8gbm90DQpkaXNjbG9z ZSB0aGUgY29udGVudCBvZiB0aGlzIGUtbWFpbCB0byBhbnkgb3RoZXIgcGVyc29uLiBUaGFuayB5 b3UhDQo8L3ByZT48IS0tfS0tPjwvdGQ+PC90cj48L3RhYmxlPg== --_000_D256BFEE69BEmadjidnakhjirimediatekcom_-- From nobody Wed Oct 28 18:24:46 2015 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 820EC1B6130 for ; Wed, 28 Oct 2015 18:24:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.55 X-Spam-Level: X-Spam-Status: No, score=-1.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 324_Rx-BXofA for ; Wed, 28 Oct 2015 18:24:40 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 854641B612F for ; Wed, 28 Oct 2015 18:24:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::b]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id t9T1Oa5V005050; Thu, 29 Oct 2015 02:24:36 +0100 (CET) Received: from dhcp-private-21-117.tpac.keio.w3.org (unknown [IPv6:2400:4040:0:23:61c4:8088:bbab:7c7b]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3nmTZp5b5Vz2Cjf; Thu, 29 Oct 2015 02:24:34 +0100 (CET) Message-ID: <5631754C.6010901@tzi.org> Date: Thu, 29 Oct 2015 10:24:28 +0900 From: Carsten Bormann User-Agent: Postbox 4.0.7 (Macintosh/20151021) MIME-Version: 1.0 To: Madjid Nakhjiri References: In-Reply-To: X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: "ace@ietf.org" Subject: Re: [Ace] comments on draft-seitz-ace-oauth-authz-00 X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 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, 29 Oct 2015 01:24:41 -0000 Madjid Nakhjiri wrote: > # If COAP option max length is 256 bits, how can a signature mechanism > that requires that many bits be used? It's not -- there is no fundamental limit to CoAP option size. Practically speaking, however, it is often advantageous to be able to put a CoAP message into a datagram that is of appropriate size. RFC 7252 gives 1152 bytes as a practical upper bound of that; some radios are much happier with 80 bytes or less (not excluding the occasional larger message, but that might have a harder time getting through, so you might want to use them sparingly). Also note that the CoAP block protocol helps with splitting up payloads into blocks, but options do not benefit from that. So the gist is: a 256-bit (32-byte) signature is quite possible in an option; for some applications the burden such an option places on the remaining message size is rather significant, but mostly not prohibitive. Grüße, Carsten From nobody Thu Oct 29 01:06:25 2015 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E1C91B2A91 for ; Thu, 29 Oct 2015 01:06:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.901 X-Spam-Level: X-Spam-Status: No, score=-3.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JOcR5Xm_mzAx for ; Thu, 29 Oct 2015 01:06:21 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 48B901B2A9B for ; Thu, 29 Oct 2015 01:06:16 -0700 (PDT) X-AuditID: c1b4fb2d-f79626d000004282-68-5631d376fc80 Received: from ESESSHC010.ericsson.se (Unknown_Domain [153.88.253.125]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 97.EA.17026.673D1365; Thu, 29 Oct 2015 09:06:14 +0100 (CET) Received: from ESESSMB303.ericsson.se ([169.254.3.10]) by ESESSHC010.ericsson.se ([153.88.183.48]) with mapi id 14.03.0248.002; Thu, 29 Oct 2015 09:06:13 +0100 From: =?utf-8?B?R8O2cmFuIFNlbGFuZGVy?= To: Carsten Bormann , "Ace@ietf.org" , "Olaf Bergmann" , Hannes Tschofenig Thread-Topic: [Ace] draft-bergmann-ace-dcaf-cose-00 vs. draft-selander-ace-object-security-03 Thread-Index: AQHREY/yaUXOV48wzEG97jc1zGEkzg== Date: Thu, 29 Oct 2015 08:06:12 +0000 Message-ID: References: <5630E097.6030508@gmx.net> <87oafjkohu.fsf@aung.informatik.uni-bremen.de> <56316B19.2060800@tzi.org> In-Reply-To: <56316B19.2060800@tzi.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.7.141117 x-originating-ip: [153.88.183.149] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrLIsWRmVeSWpSXmKPExsUyM+JvrW7ZZcMwg2mPBC2+f+thtmha3Mhk cWTKXVaLpTvvsTqweCzetJ/NY8mSn0we0xZlBjBHcdmkpOZklqUW6dslcGXcmX+HsWBCTUXf w2+MDYw/KroYOTkkBEwkDkxczgRhi0lcuLeeDcQWEjjCKNGy2r+LkQvIXswosf/FT2aQBJuA i8SDhkdMIAkRgWmMEic/7gZKcHAIC8RJ/Oz0AakREYiXuPFrMzOErSdxfP4FVhCbRUBV4vbm F2ALeAUsJDr/3GCBWLCQUaLtQh9YglNAXeL7u9lgzYxAF30/tQbsOmYBcYlbT+ZDXSogsWTP eWYIW1Ti5eN/YAtEgZatvN7EBhFXklh7eDsLyG3MApoS63fpQ4yxljj19iYrhK0oMaX7ITvE PYISJ2c+YZnAKD4LybZZCN2zkHTPQtI9C0n3AkbWVYyixanFxbnpRsZ6qUWZycXF+Xl6eakl mxiBkXhwy2/dHYyrXzseYhTgYFTi4S0INgwTYk0sK67MPcQowcGsJMIrzQIU4k1JrKxKLcqP LyrNSS0+xCjNwaIkztvC9CBUSCA9sSQ1OzW1ILUIJsvEwSnVwJgannDHrlRAJWi6g4oJ2/mn oXUCNkon2ST9j365Ffdm0bKIud4Mq9INCtVfXJli9TxKulyxwr/5m0ALZ8c8AQaL4LvCkXZZ iQcvXppa86z9QUqU62IJ5timiwoSB/bKWz/oNotcsuKX/uffvDMO/+HW+WzNYX5vjVHSzurF 4q/XpLjMYDcsUmIpzkg01GIuKk4EANPQIJLAAgAA Archived-At: Subject: Re: [Ace] draft-bergmann-ace-dcaf-cose-00 vs. draft-selander-ace-object-security-03 X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 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, 29 Oct 2015 08:06:24 -0000 DQpDYXJzdGVuIGFuZCBhbGwsIA0KDQpPbiAyMDE1LTEwLTI5IDAxOjQwLCAiQ2Fyc3RlbiBCb3Jt YW5uIiA8Y2Fib0B0emkub3JnPiB3cm90ZToNCg0KPkfDtnJhbiwNCj4NCj5tYXliZSBJIGRpZG4n dCBwYXkgZW5vdWdoIGF0dGVudGlvbiwNCj4gDQoNCltHU10gUGVyaGFwcy4gT3IgbWF5YmUgdGhl cmUgYXJlIG1vcmUgcGVvcGxlIHRoYXQgaGFzbuKAmXQgdW5kZXJzdG9vZCB0aGlzLg0KTGV0IG1l IHRyeSB3aXRoIG1vcmUgd29yZHMuDQoNCj5idXQgSSB0aG91Z2h0IHdoYXQgeW91IHBvaW50ZWQg b3V0DQo+d2FzIG5vdCBzbyBtdWNoIGEgc2VjdXJpdHkgZmxhdyBidXQgcHJvdGVjdGluZyB0b28g bXVjaDoNCg0KW0dTXSBTZWN1cml0eSBpcyBhYm91dCBwcm90ZWN0aW5nIHRoZSByaWdodCB0aGlu Zywgbm90IHRvbyBsaXR0bGUsIG5vdCB0b28NCm11Y2guIElmIHRoZSBzZWN1cml0eSBtZWNoYW5p c20gZG9lc27igJl0IHdvcmsgZHVyaW5nIG5vcm1hbCBvcGVyYXRpb25zIGl0DQppcyBub3QgYSBz ZWN1cml0eSBzb2x1dGlvbi4NCg0KPlRoZXJlIGFyZSBzb21lIHRyYW5zZm9ybWF0aW9ucyB0aGF0 IG1pZ2h0IGJlIHBlcmZvcm1lZCBieSBhIHByb3h5IHRoYXQNCj5hcmUgZGV0ZWN0ZWQgYnkgdGhl IGN1cnJlbnQgdmVyc2lvbiBvZiBEQ0FGLUNPU0UgKGFuZCB0aHVzIHdvdWxkIGJlDQo+cmVqZWN0 ZWQpLg0KDQpbR1NdIElmIHlvdSBjYW7igJl0IGRpc3Rpbmd1aXNoIGEgbm9ybWFsIG9wZXJhdGlv biBmcm9tIGFuIGF0dGFjayB0aGVuIHRoZXJlDQppcyBub3QgbXVjaCBzZWN1cml0eSBwcm92aWRl ZC4gUmVjYWxsIHRoYXQgdGhpcyBpcyBub3QgYSBjb3JuZXIgY2FzZSwgaXQNCmlzIGV4YWN0bHkg dGhlIHByb2JsZW0gaXMgRENBRi1DT1NFIGNsYWltcyB0byBzb2x2ZSBhcyBpcyBzdGF0ZWQgaW4N ClNlY3Rpb24gMToNCg0KIkluIHRoZSBwcmVzZW5jZSBvZiBpbnRlcm1lZGlhcmllcyBzdWNoIGFz LCBlLmcuLCBDb0FQIHByb3hpZXMsIGNoYW5uZWwNCnNlY3VyaXR5IG1heSBub3QgYmUgYXBwbGlj YWJsZSBmb3IgYWxsIGNvbmZpZ3VyYXRpb25zLiAgSWYgdGhpcyBpcyB0aGUNCmNhc2UsIHRoZSBl eGNoYW5nZWQgaW5mb3JtYXRpb24gbXVzdCBiZSBwcm90ZWN0ZWQgYXQgdGhlIGFwcGxpY2F0aW9u IGxldmVsDQp0byBoZWxwIGFjaGlldmluZyB0aGUgcHJpbmNpcGFscycgc2VjdXJpdHkgcmVxdWly ZW1lbnRzLiINCg0KVG8gc3VtbWFyaXplOiBDb0FQIGRlZmluZXMgb3BlcmF0aW9ucyB0aGF0IHBy b3hpZXMgY2FuIHBlcmZvcm0gb24NCm1lc3NhZ2VzLiBJZiB5b3UgdXNlIERUTFMsIHRoYXQgbXVz dCBiZSB0ZXJtaW5hdGVkIGF0IHRoZSBwcm94eSBmb3IgaXQgdG8NCnBlcmZvcm0gdGhvc2Ugb3Bl cmF0aW9ucy4gVG8gYWNoaWV2ZSBlbmQtdG8tZW5kIHNlY3VyaXR5IG9mIHNlbnNpdGl2ZQ0KcGFy dHMgb2YgdGhlIENvQVAgbWVzc2FnZSB0aG9zZSBtdXN0IHRoZXJlZm9yZSBiZSBwcm90ZWN0ZWQg YXBwcm9wcmlhdGVseSwNCmJ1dCBvYnZpb3VzbHkgbm90IGF0IHRoZSBjb3N0IG9mIHByZXZlbnRp bmcgbm9ybWFsIG9wZXJhdGlvbnMuIFRoaXMgaXMNCndoZXJlIERDQUYtQ09TRSBmYWlscyBhbmQg dGh1cyBpcyBub3QgYSBzb2x1dGlvbi4NCg0KPlRoZSBPU0NPQVAgZHJhZnQgYWRkcmVzc2VzIHRo aXMgYnkgZWl0aGVyIG5vdCBwcm90ZWN0aW5nIHRoaXMNCj5pbmZvcm1hdGlvbiAoUEFZTCwgbm93 IGNhbGxlZCBPU0NPTikgb3IgYnkgYSBzb21ld2hhdCBtb3JlIGludmFzaXZlDQo+YXBwcm9hY2gg dG8gQ29BUCBhdHRyaWJ1dGVzIChuZXcgb3B0aW9ucywgd2hhdCB5b3UgY2FsbCBPU0NPQVAgbm93 KS4NCg0KW0dTXSBMZXTigJlzIHRha2UgYSBzdGVwIGJhY2suIEkgbWFkZSBhIHJldmlldyBvZiBE Q0FGLUNPU0UgYW5kIHByZXNlbnRlZA0Kc29tZSBpc3N1ZXMuIFRoZXJlIGlzIG5vIG5lZWQgdG8g ZGlzY3VzcyBPU0NPQVAgdG8gdW5kZXJzdGFuZCB0aGUNCmxpbWl0YXRpb25zIG9mIERDQUYtQ09T RS4gT2xhZiBldmVuIGNsYWltcyB0aGF0IERDQUYtQ09TRSBoYXMgbm90aGluZyB0bw0KZG8gd2l0 aCBPU0NPQVAuIEJ1dCBzaW5jZSB5b3UgYnJpbmcgaXQgdXAgSeKAmW0gaGFwcHkgdG8gZXhwbGFp biBob3cgT1NDT0FQDQpwcm9wb3NlcyB0byBzb2x2ZSB0aGUgc2VjdXJpdHkgcHJvYmxlbSBEQ0FG LUNPU0UgZmFpbHMgdG8gc29sdmUuIChUaGlzIHdhcw0KYWxyZWFkeSBpbiB2ZXJzaW9uIC0wMCwg c3VibWl0dGVkIGEgeWVhciBhZ28uKQ0KDQpCdXQgZmlyc3QsIHllcywgdGhlIHRlcm1pbm9sb2d5 IGhhcyBjaGFuZ2VkOiB0aGUgdGVybXMg4oCcTW9kZTpDT0FQ4oCdIGFuZA0K4oCcTW9kZTpQQVlM IiB0dXJuZWQgb3V0IHRvIGJlIG1pc2xlYWRpbmcuIEl0IGltcGxpZWQgdHdvIGRpZmZlcmVudCBt b2RlcyBvZg0Kb3BlcmF0aW9uIG9mIGEgc2luZ2xlIHByb3RvY29sIGJ1dCB0aGUgcHJvdG9jb2xz IGFyZSBpbiBmYWN0IHF1aXRlDQpkaWZmZXJlbnQuIFNvIGluc3RlYWQgd2Ugbm93IGRpc3Rpbmd1 aXNoIGJldHdlZW4gb2JqZWN0IHNlY3VyaXR5IG9mIENvQVANCm1lc3NhZ2VzIChPU0NPQVApIHdo aWNoIHByb3RlY3RzIENvQVAgcGF5bG9hZCBhbmQgc2Vuc2l0aXZlIG9wdGlvbnMgYW5kDQpoZWFk ZXIgZmllbGRzOyBhbmQgb2JqZWN0IHNlY3VyaXR5IG9mIOKAnGNvbnRlbnTigJ0gKE9TQ09OKSB3 aGljaCBvbmx5DQpwcm90ZWN0cyBwYXlsb2FkIGFuZCBpcyBub3QgYm91bmQgdG8gQ29BUC4gT1ND T04gaXMgYSBxdWl0ZSB0cml2aWFsDQp3cmFwcGluZyBvZiBtZXNzYWdlIGNvbnRlbnQgaW4gYSBj ZXJ0YWluIGtpbmQgb2YgbWVzc2FnZSBmb3JtYXQgYW5kIGlzDQppbmNsdWRlZCBpbiBhcHBlbmRp eCBDIG9mIHRoZSBPU0NPQVAgZHJhZnQganVzdCBmb3IgY29tcGFyaXNvbi4NCg0KT1NDT0FQIGFk ZHJlc3NlcyB0aGUgaXNzdWUgbWVudGlvbmVkIHByZXZpb3VzbHkgaW4gdGhpcyBtYWlsIGJ5IGRl ZmluaW5nDQrigJxpbnZhcmlhbnRzIi4gQSBDb0FQIHByb3h5IG1heSBwZXJmb3JtIGNlcnRhaW4g bGVnaXRpbWF0ZSBhY3Rpb25zIGFuZA0KY2hhbmdlIHRoZSBjb250ZW50IG9mIENvQVAgb3B0aW9u cywgYnV0IHRoZSBvcmlnaW5hdGluZyBhbmQgZGVzdGluYXRpb24NCmVuZHBvaW50IHNob3VsZCBi b3RoIGJlIGFibGUgdG8gZXN0YWJsaXNoIGNlcnRhaW4gaW52YXJpYW50IGluZm9ybWF0aW9uDQp0 aGF0IGlzIG5vdCBzdXBwb3NlZCB0byBiZSBjaGFuZ2VkIGJ5IGEgbGVnaXRpbWF0ZSBwcm94eSwg ZS5nLiB0aGUNCmludGVuZGVkIHJlc291cmNlIFVSSSBvciBVUkkgc2NoZW1lIGFkZHJlc3NlZCBi eSB0aGUgcmVxdWVzdCByZWFjaGluZyB0aGUNCmRlc3RpbmF0aW9uIHNlcnZlci4gVGhpcyBpbmZv cm1hdGlvbiBpcyBpbnRlZ3JpdHkgcHJvdGVjdGVkIGluIE9TQ09BUCBieQ0KY29uc2lkZXJpbmcg aG93IG9wdGlvbnMgYXJlIGxlZ2l0aW1hdGVseSBjaGFuZ2VkIGJ5IGludGVybWVkaWF0ZSBub2Rl cyAodG8NCnRoZSBiZXN0IG9mIG91ciB1bmRlcnN0YW5kbmluZyBmcm9tIHJlYWRpbmcgdGhlIENv QVAgZHJhZnQsIGZ1cnRoZXINCnJldmlld3Mgd291bGQgYmUgaGVscGZ1bCBoZXJlISkuIE5vdGUg dGhhdCB0aGUgaW52YXJpYW50IGluIGl0c2VsZiBpcw0KKm5vdCogdHJhbnNwb3J0ZWQgaW4gdGhl IG1lc3NhZ2UuIEl0IGlzIGNvbnN0cnVjdGVkIGJ5IGJvdGggY2xpZW50IGFuZA0Kc2VydmVyLCBh bmQgZmVkIGludG8gdGhlIGFsZ29yaXRobSBmb3IgcHJvdmluZyBhbmQgdmVyaWZ5aW5nIHRoZSBp bnRlZ3JpdHkNCm9mIHRoZSBtZXNzYWdlLiBUaGUgZGV0YWlscyBhcmUgaW4gc2VjdGlvbiA2LjIu MS4yIG9mIHRoZSBPU0NPQVAgZHJhZnQuDQoNCg0KSSBkb27igJl0IHVuZGVyc3RhbmQgd2hhdCB5 b3UgbWVhbiBieSDigJxpbnZhc2l2ZSBhcHByb2FjaCB0byBDb0FQIGF0dHJpYnV0ZXMNCihuZXcg b3B0aW9ucyAuLi4p4oCdLiBPU0NPQVAgdXNlZCB0byBkZWZpbmUgdHdvIG5ldyBvcHRpb25zIOKA nEVuY+KAnSBhbmQg4oCcU2ln4oCdDQooaW5kaWNhdGluZyBhIEpXRSBvYmplY3Qgb3IgSldTIG9i amVjdCwgcmVzcGVjdGl2ZWx5KSwgYnV0IHRoZXkgYXJlIG5vdw0KcmVwbGFjZWQgd2l0aCBvbmUg c2luZ2xlIG9wdGlvbiBjYWxsZWQg4oCcT2JqZWN0LVNlY3VyaXR54oCdIChpbmRpY2F0aW5nIGEN CkNPU0Ugb2JqZWN0KS4gQXMgYSBjb21wYXJpc29uIERDQUYtQ09TRSBhZGRzIHR3byBuZXcgQ29B UCBvcHRpb25zLg0KDQo+DQo+V2hpY2ggQ29BUCBhdHRyaWJ1dGVzIG5lZWQgdG8gYmUgcHJvdGVj dGVkIGluIHdoYXQgdXNlIGNhc2VzIChhbmQgaG93DQo+dGhlIGF0dHJpYnV0ZXMgbWlnaHQgaGF2 ZSB0byBjaGFuZ2UgdG8gZW5hYmxlIHByb3RlY3RpbmcgdGhlbSBiZXR0ZXIpIGlzDQo+YW4gaW1w b3J0YW50IGRpc2N1c3Npb24gdG8gaGF2ZTsgd2UgaGFkIHRoYXQgb24gdGhlIENvUkUgYWdlbmRh IGFscmVhZHkNCj5idXQgSSBqdXN0IGFsbG9jYXRlZCBtb3JlIHRpbWUgdG8gdGhhdC4NCg0KWWVz LCBhbmQgbWF5YmUgd2UgbmVlZCB0byBhbGxvY2F0ZSBtb3JlIHRpbWUgdG8gdGhpcyBzaW5jZSB0 aGVyZSBhcmUNCmZ1bmRhbWVudGFsIHBhcnRzIGhlcmUgdGhhdCBkb2VzbuKAmXQgc2VlbSB0byBi ZSB1bmRlcnN0b29kPw0KDQo+DQo+V2hhdCBJIGV4cGVjdCBBQ0UgdG8gZGVsaXZlciBpcyB0aGUg c2VjdXJpdHkgcHJvdG9jb2wgZm9yIHNldHRpbmcgdXANCj50aGF0IHByb3RlY3Rpb24uDQoNClRo ZXJlIGFyZSBzZXZlcmFsIHBhcnRzIHRvIHRoaXMg4oCcc2VjdXJpdHkgcHJvdG9jb2zigJ0uDQoN Ci0gSSBhZ3JlZSB0aGF0IOKAnFdoaWNoIENvQVAgYXR0cmlidXRlcyBuZWVkIHRvIGJlIHByb3Rl Y3RlZCBpbiB3aGF0IHVzZQ0KY2FzZXMgKGFuZCBob3cgdGhlIGF0dHJpYnV0ZXMgbWlnaHQgaGF2 ZSB0byBjaGFuZ2UgdG8gZW5hYmxlIHByb3RlY3RpbmcNCnRoZW0gYmV0dGVyKeKAnSBuZWVkIHRv IGJlIGRpc2N1c3NlZCBhbmQgZGVmaW5lZCBpbiBDT1JFLiBUaGlzIGFsc28gaW5jbHVkZXMNCipo b3cqIHRoZSBDb0FQIGF0dHJpYnV0ZXMgYXJlIHByb3RlY3RlZCwgYW5kIGhvdyB0aGUgQ29BUCBt ZXNzYWdlDQoqY2hhbmdlcyogd2hlbiBzb21lIG9mIGl0cyBhdHRyaWJ1dGVzIGFyZSBlLmcuIGVu Y3J5cHRlZC4gVGhpcyBpcyBpbiB0aGUNCk9TQ09BUCBkcmFmdC4gRENBRi1DT1NFIGRvZXNu4oCZ dCBhdCBhbGwgZ28gaW50byB0aGlzIGFuZCBqdXN0IG5vdGVzOg0K4oCcTm90ZSAxOiBXaGVyZSBj b25maWRlbnRpYWxpdHkgaXMgcmVxdWlyZWQsIGEgQ09TRV9lbmNyeXB0RGF0YSBzdHJ1Y3R1cmUN CndpbGwgYmUgdXNlZCBpbnN0ZWFkIG9mIHRoZSBDT1NFX01hYyBzdHJ1Y3R1cmUuIg0KDQotIFRo ZSBpbnZhcmlhbnRzIG1lbnRpb25lZCBhYm92ZSBtdXN0IGFsc28gYmUgZGVmaW5lZCBpbiBDT1JF IHNpbmNlIHRoZXkNCmFyZSBjbG9zZWx5IHRpZWQgdG8gdGhlIGxlZ2l0aW1hdGUgQ29BUCBwcm94 eSBvcGVyYXRpb25zLiBUaGlzIGlzIGluIHRoZQ0KT1NDT0FQIGRyYWZ0Lg0KDQotIFRoZSBDb0FQ IG9wdGlvbiBpbmRpY2F0aW5nIHRoYXQgdGhlIENvQVAgbWVzc2FnZSBpcyBwcm90ZWN0ZWQgYnkg b2JqZWN0DQpzZWN1cml0eSBpcyBzb21ldGhpbmcgdGhhdCBJIHN1cHBvc2UgYmV0dGVyIGJlIGRl ZmluZWQgaW4gQ09SRS4gVGhpcyBpcyBpbg0KdGhlIE9TQ09BUCBkcmFmdC4NCg0KLSBIb3cgdGhl IENvQVAgYXR0cmlidXRlcywgaW52YXJpYW50cyBldGMuIGFyZSBmb3JtYXR0ZWQgYXMg4oCcZXh0 ZXJuYWwNCmF1dGhlbnRpY2F0ZWQgZGF0YeKAnSAob3IgZXh0ZXJuYWxfYWFkIGFzIENPU0UgcmVu YW1lZCBpdCkgKmNvdWxkKiBiZQ0KZGVmaW5lZCBpbiBBQ0UgYnV0IHNlZW1zIG1vcmUgcmVsZXZh bnQgdG8gZGVmaW5lIGluIENPUkUsIGluIHRoZSBzYW1lDQpkcmFmdCBhcyB0aGUgT2JqZWN0LVNl Y3VyaXR5IG9wdGlvbiwgaW52YXJpYW50cyBldGMuIGFyZSBkZWZpbmVkLiBUaGlzIGlzDQppbiB0 aGUgT1NDT0FQIGRyYWZ0Lg0KDQpPbmNlIHRoaXMgaXMgZGVmaW5lZCwgQ09TRSBkb2VzIHRoZSBq b2Igb2YgcHJvdGVjdGluZyB0aGF0IENvQVAgbWVzc2FnZQ0KYXNzb2NpYXRlZCBkYXRhLg0KDQpX aGF0IEkgc2VlIGxlZnQgZm9yIEFDRSB0byBwcm92aWRlIGlzIGUuZy4gaG93IHRoZSBhdXRob3Jp emF0aW9uIHNlcnZlcg0Kc2lnbmFscyB3aGF0IHNlY3VyaXR5IHByb3RvY29sIChEVExTLCBUTFMs IE9TQ09BUCwgT1NDT04sIGV0Yy4pIGFuZCB3aGF0DQpzZWN1cml0eSBjb250ZXh0IHRvIHVzZSBi ZXR3ZWVuIGNsaWVudCBhbmQgcmVzb3VyY2Ugc2VydmVyLCBpbiB0aGUNCnBhcnRpY3VsYXIgc2Vj dXJpdHkgc2V0dGluZyB0aGUgQVMgaXMgc2V0IHRvIGNvbnRyb2wuIFRoaXMgaXMgd2hhdCB3ZQ0K cHJvcG9zZSBhcyBvbmUgT0F1dGggZXh0ZW5zaW9uIGZvciBJb1QuDQoNCg0KR8O2cmFuDQoNClBT IFdpdGggdGhpcyBpbiBtaW5kIG1heWJlIE9TQ09BUCBzaG91bGQgYmUgcmVzdWJtaXR0ZWQgYXMg YSBDT1JFIGRyYWZ0Pw0KDQoNCj4NCj5HcsO8w59lLCBDYXJzdGVuDQo+DQo+DQo+R8O2cmFuIFNl bGFuZGVyIHdyb3RlOg0KPj4gSGkgT2xhZiwgSGFubmVzLCBhbmQgYWxsLA0KPj4gDQo+PiBMYXN0 IHdlZWsgSSBwb2ludGVkIG91dCBzb21lIGZsYXdzIGluIHRoZSBzZWN1cml0eSBzb2x1dGlvbiBv ZiBEQ0FGDQo+PiAoZHJhZnQtYmVyZ21hbm4tYWNlLWRjYWYtY29zZS0wMCkuIEhlcmUgaXMgdGhl IG1haWw6DQo+PiANCj4+IGh0dHA6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9hY2Uv Y3VycmVudC9tc2cwMTQ3OC5odG1sDQo+PiANCj4+IEkgaGF2ZW7igJl0IHNlZW4gYW55IHJlcGx5 IHRvIHRoYXQuIE1lYW53aGlsZSBJIGRvbuKAmXQgY29uc2lkZXIgRENBRi1DT1NFDQo+PnRvDQo+ PiBiZSBhIHNvbHV0aW9uIHRvIGFueXRoaW5nLg0KPj4gDQo+PiBJ4oCZbSBub3QgdGhlIG9uZSBz ZXR0aW5nIHRoZSBhZ2VuZGEsIGJ1dCBpbiBvcmRlciB0byByZXNlcnZlIHRpbWUgZm9yIGENCj4+ IGRyYWZ0IGF0IHRoZSBGMkYgbWVldGluZywgaXNu4oCZdCBpdCByZWFzb25hYmxlIHRoYXQgdGhl IGF1dGhvcnMgYmVmb3JlDQo+PnRoZQ0KPj4gbWVldGluZyBhdCBsZWFzdCBtYWtlIGl0IHBsYXVz aWJsZSB0aGF0IHRoZWlyIHNlY3VyaXR5IHNvbHV0aW9uIGNhbg0KPj53b3JrPw0KPj4gDQo+PiAN Cj4+IEfDtnJhbg0KPj4gDQo+PiANCj4+IA0KPj4gT24gMjAxNS0xMC0yOCAxNjoyMSwgIk9sYWYg QmVyZ21hbm4iIDxiZXJnbWFubkB0emkub3JnPiB3cm90ZToNCj4+IA0KPj4+IEhpIEhhbm5lcywN Cj4+Pg0KPj4+IEhhbm5lcyBUc2Nob2ZlbmlnIDxoYW5uZXMudHNjaG9mZW5pZ0BnbXgubmV0PiB3 cml0ZXM6DQo+Pj4NCj4+Pj4gV2UgaGF2ZSBnb3R0ZW4gYW4gYWdlbmRhIHJlcXVlc3QgZm9yIGRy YWZ0LWJlcmdtYW5uLWFjZS1kY2FmLWNvc2UtMDAsDQo+Pj4+IHdoaWNoIGlzIGFib3V0IHVzaW5n IENPU0UgdG8gcHJvdmlkZSBhIG9iamVjdC1sZXZlbCBzZWN1cml0eSBmb3IgRENBRi4NCj4+PiBO bywgaXQncyBub3QuIEl0IGlzIGFib3V0IHByb3ZpZGluZyBhdXRoZW50aWNhdGVkIGF1dGhvcml6 YXRpb24gd2hpY2gNCj4+PmlzDQo+Pj4gY2xlYXJseSBpbiB0aGUgZm9jdXMgb2YgdGhlIEFDRSBX Ry4gSXQgZG9lcyB0aGlzIGJ5IHVzaW5nIERDQUYuDQo+Pj4NCj4+PiBBdCB0aGUgSUVURi05MyBt ZWV0aW5nIGluIFByYWd1ZSwgc2V2ZXJhbCBwZW9wbGUgY3JpdGljaXplZA0KPj4+IGRyYWZ0LWdl cmRlcy1hY2UtZGNhZi1hdXRob3JpemUgYmVjYXVzZSBpdCB1c2VzIERUTFMgdG8gcHJvdmlkZSBz ZWN1cmUNCj4+PiBjb21tdW5pY2F0aW9uLiBUaGUgbmV3IGRyYWZ0LWJlcmdtYW5uLWFjZS1kY2Fm LWNvc2Ugc3BlY2lmaWVzIGhvdyBEQ0FGDQo+Pj4gY2FuIGJlIHVzZWQgd2l0aCBDT1NFIHN5bnRh eC4gSXQgZG9lcyAqbm90KiBzcGVjaWZ5IGhvdyBvYmplY3Qgc2VjdXJpdHkNCj4+PiB3b3Jrcywg aXQganVzdCAqbWFrZXMgdXNlKiBvZiB3aGF0IGlzIGFscmVhZHkgdGhlcmUuDQo+Pj4NCj4+PiBU aGUgaW50ZW50aW9uIG9mIHRoZSBwcmVzZW50YXRpb24gdGhlcmVmb3JlIGlzIHRvIGV4cGxhaW4g aG93IERDQUYgY2FuDQo+Pj4gYmUgdXNlZCBpbiB0aGUgcHJlc2VuY2Ugb2YgaW50ZXJtZWRpYXJp ZXMuIEkgYW0gbm90IGdvaW5nIHRvIGRpc2N1c3MgaW4NCj4+PiBBQ0Ugd2hldGhlciBDb0FQIG9w dGlvbiBYIG5lZWRzIHRvIGJlIHByb3RlY3RlZCBieSBtZWNoYW5pc20gWSBhcyBvdGhlcg0KPj4+ IHBlb3BsZSB0cmllZCB0by4gVGhpcyBpcyBjbGVhcmx5IHNvbWV0aGluZyB0aGF0IG5lZWRzIHRv IGJlIGRpc2N1c3NlZA0KPj4+aW4NCj4+PiBDT1JFIGFuZCBDT1NFIHdoZXJlIGl0IGJlbG9uZ3Mu IE9uY2UgYSB2aWFibGUgb2JqZWN0IHNlY3VyaXR5IG1lY2hhbmlzbQ0KPj4+IGhhcyBiZWVuIGRl ZmluZWQgYnkgdGhlc2UgdG8gd29ya2luZyBncm91cHMgKG15IGRjYWYgZXhhbXBsZSBzaG93cyB0 aGF0DQo+Pj4gQ09TRSBpcyBjbG9zZSBieSB3aGlsZSBDT1JFIGhhcyBzb21lIHdvcmsgdG8gZG8g aW4gdGhpcyByZWdhcmQpLg0KPj4+DQo+Pj4+IEluIHByZXZpb3VzIElFVEYgbWVldGluZ3Mgd2Ug aGF2ZSBoZWFyZCBhYm91dCBhIG1vcmUgZ2VuZXJpYyBzb2x1dGlvbiwNCj4+PiBQbGVhc2UsIGRv IG5vdCBtaXggdXAgdGhpbmdzLiBEQ0FGLUNPU0UgaXMgYWJvdXQgYXV0aGVudGljYXRlZA0KPj4+ IGF1dGhvcml6YXRpb24sIGRyYWZ0LXNlbGFuZGVyLWFjZS1vYmplY3Qtc2VjdXJpdHkgaXMgYWJv dXQgb2JqZWN0DQo+Pj4gc2VjdXJpdHkuDQo+Pj4NCj4+Pj4gbmFtZWx5IGRyYWZ0LXNlbGFuZGVy LWFjZS1vYmplY3Qtc2VjdXJpdHktMDMuIEl0IHdpbGwgYmUgcHJlc2VudGVkIGluDQo+Pj4+IENP U0UvQ09SRSAoaWYgdGhlIHJlcXVlc3RzIGdldCBncmFudGVkKS4NCj4+Pj4NCj4+Pj4gSGVyZSBp cyB0aGUgaXNzdWU6DQo+Pj4+DQo+Pj4+IDEpIE9mZmljaWFsbHksIHdlIGhhdmUgbm8gbWlsZXN0 b25lIGluIEFDRSB0byB3b3JrIG9uIHN1Y2ggYSBkb2N1bWVudA0KPj4+PmF0DQo+Pj4+IGFsbCBy aWdodCBub3cuDQo+Pj4gV2UgYXJlIGdvaW5nIHRvIHN0YW5kYXJkaXplIGEgc29sdXRpb24gZm9y IGF1dGhlbnRpY2F0ZWQgYXV0aG9yaXphdGlvbiwNCj4+PiBhcmVuJ3Qgd2U/IERDQUYgaXMgYSBw cm9wb3NhbCBmb3IgdGhpcywgYW5kDQo+Pj5kcmFmdC1iZXJnbWFubi1hY2UtZGNhZi1jb3NlDQo+ Pj4gYWRkcmVzc2VzIG9uIG9mIHRoZSBvcGVuIGlzc3VlcyB0aGF0IGhhdmUgYmVlbiByYWlzZWQg aW4gdGhlIHBhc3QuDQo+Pj4NCj4+Pj4gMikgU2hvdWxkIHdlIGhhdmUgYSBwcmVzZW50YXRpb24g YWJvdXQgZHJhZnQtYmVyZ21hbm4tYWNlLWRjYWYtY29zZS0wMA0KPj4+PiB3aGVuIHdlIGhhdmUg YWxyZWFkeSBoZWFyZCBhYm91dCB0aGUgbW9yZSBnZW5lcmljIHZlcnNpb24gYmVmb3JlIGhhbmQ/ DQo+Pj4gU2VlIGFib3ZlLiBZb3UgYXJlIG1pc3NpbmcgdGhlIHBvaW50IG9mIGRyYWZ0LWJlcmdt YW5uLWFjZS1kY2FmLWNvc2UuDQo+Pj4NCj4+Pj4gSGVuY2UsIHRoZSBxdWVzdGlvbiB0byB0aGUg Z3JvdXAgaXMgdGhlIGZvbGxvd2luZzoNCj4+Pj4NCj4+Pj4gYSkgV2hlcmUgZG9lcyB0aGUgQ09B UCBhcHBsaWNhdGlvbiBsYXllciBzZWN1cml0eSBiZWxvbmc/IElzIEFDRSB0aGUNCj4+Pj4gcmln aHQgcGxhY2Ugb3IgaXMgaXQgcmF0aGVyIENPUkUgb3IgQ09TRT8NCj4+PiBDT0FQIGFwcGxpY2F0 aW9uIGxheWVyIHNlY3VyaXR5IGJlbG9uZ3MgdG8gQ09SRS4NCj4+Pg0KPj4+PiBJZiBpdCBpcyBB Q0Ugc2hvdWxkIHdlIGFzayBvdXIgQUQgdG8gYWRkIGFub3RoZXIgbWlsZXN0b25lPw0KPj4+Pg0K Pj4+PiBiKSBXaGF0IHdvdWxkIHRoZSBwdXJwb3NlIG9mIGEgcHJlc2VudGF0aW9uIG9mDQo+Pj4+ IGRyYWZ0LWJlcmdtYW5uLWFjZS1kY2FmLWNvc2UtMDANCj4+PiBBZGRyZXNzaW5nIHRoZSBpc3N1 ZSByYWlzZWQgYXQgdGhlIFByYWd1ZSBtZWV0aW5nOiBEQ0FGIGlzIGEgcGVyZmVjdA0KPj4+Zml0 DQo+Pj4gZm9yIEFDRSBiZWNhdXNlIGl0IGNhbiBiZSB1c2VkIHdpdGggdHJhbnNwb3J0IGxheWVy IHNlY3VyaXR5IGFuZCBvYmplY3QNCj4+PiBzZWN1cml0eSBhbmQgaXMgYWJsZSB0byBoYW5kbGUg dGhlIHRocmVlIGNvbW11bmljYXRpb24gcGF0dGVybnMgdGhhdA0KPj4+IGhhdmUgYmVlbiBicm91 Z2h0IG9uIHRoZSB0YWJsZSAoSUlSQyB0aGV5IGhhdmUgYmVlbiBjYWxsZWQgInB1c2giLA0KPj4+ ICJwdWxsIiwgYW5kICJjbGllbnQgcHVsbCIpLg0KPj4+DQo+Pj4+IGFuZCAvIG9yIGRyYWZ0LXNl bGFuZGVyLWFjZS1vYmplY3Qtc2VjdXJpdHktMDMgYmUgaW4gQUNFIGZvciB0aGlzDQo+Pj4+IG1l ZXRpbmc/DQo+Pj4gSSBhbSBoYXBweSB0byBkaXNjdXNzIHRoaXMgSS1EIGR1cmluZyBDT1NFIGFu ZCBDT1JFLg0KPj4+DQo+Pj4+IElmIHdlIGluZGVlZCB0byB0aGUgd29yayBpbiBBQ0UgdGhlbiB3 b3VsZG4ndCBpdCBiZSBhIHVzZWZ1bCBnb2FsIGZvcg0KPj4+PiB0aGUgbWVldGluZyBiZSB0byBt YWtlIGEgZGVjaXNpb24gYWJvdXQgdGhlIHNvbHV0aW9uIGRpcmVjdGlvbj8gVGhpcw0KPj4+PiB3 b3VsZCBvZiBjb3Vyc2UgcmVxdWlyZSB1cyB0byBsaXN0ZW4gdG8gYm90aCBzb2x1dGlvbiBkaXJl Y3Rpb25zDQo+Pj4+cmF0aGVyDQo+Pj4+IHRoYW4gb25seSB0byBvbmUuIEkgd291bGQgaW4gcGFy dGljdWxhciBiZSBpbnRlcmVzdGVkIHdoYXQgbW90aXZhdGVkDQo+Pj4+dGhlDQo+Pj4+IHdvcmsg b24gZHJhZnQtYmVyZ21hbm4tYWNlLWRjYWYtY29zZS0wMCAgZ2l2ZW4gdGhlIGV4aXN0ZW5jZSBv Zg0KPj4+PiBkcmFmdC1zZWxhbmRlci1hY2Utb2JqZWN0LXNlY3VyaXR5LTAzLi4uDQo+Pj4gTXkg aG9wZSBpcyB0byBoYXZlIGV4cGxhaW5lZCB0aGF0IGl0IGJpdC4gZHJhZnQtYmVyZ21hbm4tYWNl LWRjYWYtY29zZQ0KPj4+IGlzIG5vdCBpbiBjb25jdXJyZW5jeSB0byBkcmFmdC1zZWxhbmRlci1h Y2Utb2JqZWN0LXNlY3VyaXR5LiBJdCBqdXN0DQo+Pj4gaGFwcGVucyB0byB1c2UgQ09TRSBpbiBh IG1vcmUgUkVTVC1saWtlIHdheS4gQnV0IHRoYXQgaXMgYSBkaXNjdXNzaW9uDQo+Pj4gZm9yIENP UkUuIExldCBBQ0UgZm9jdXMgb24gdGhlIGF1dGhvcml6YXRpb24gYXNwZWN0cyBvZiBib3RoIGRy YWZ0cw0KPj4+IHdoZXJlIGRyYWZ0LWJlcmdtYW5uLWFjZS1kY2FmLWNvc2UgaXMgYSBwZXJmZWN0 IGFtZW5kbWVudCBvZg0KPj4+IGRyYWZ0LWdlcmRlcy1hY2UtZGNhZi1hdXRob3JpemUuDQo+Pj4N Cj4+PiBHcsO8w59lDQo+Pj4gT2xhZg0KPj4+DQo+Pj4gX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCj4+PiBBY2UgbWFpbGluZyBsaXN0DQo+Pj4gQWNlQGll dGYub3JnDQo+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9hY2UNCj4+ IA0KPj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+ IEFjZSBtYWlsaW5nIGxpc3QNCj4+IEFjZUBpZXRmLm9yZw0KPj4gaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9hY2UNCj4+IA0KPj4gDQoNCg== From nobody Thu Oct 29 02:44:31 2015 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DFAE1B2C0F for ; Thu, 29 Oct 2015 02:44:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k0pj7obeoZMT for ; Thu, 29 Oct 2015 02:44:27 -0700 (PDT) Received: from mail-lb0-x22d.google.com (mail-lb0-x22d.google.com [IPv6:2a00:1450:4010:c04::22d]) (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 41D671B2BB0 for ; Thu, 29 Oct 2015 02:44:27 -0700 (PDT) Received: by lbbes7 with SMTP id es7so24242613lbb.2 for ; Thu, 29 Oct 2015 02:44:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sics_se.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-type; bh=o6vcfWvdIeAY+dDptNulhLGkpA4TFV9gx14HnMUbllg=; b=1bGp0fskKmIB8Lr2lTnOO0AM+XKSCcGFjD0r5CLKQ4O+sUPp006hDTR6ZZ0MbkT+5O WnSwChQ9QAyeU5GaZy6sQxIBof7v9NcoIppBKNLrbPGwg37eMUzFClpTKD2rZwj1gqVE eEpChNzyAwJrL5SVNkrk5b8T9tTN9++L+SoUJk+qxY6kW7JBfg8HURK9Vum5lYXYeQwd 2VSiWgmXwWQI6nXwRCs12iEPYPExHPIYeTQ8ccQvpe6C1Tnoi2g5L10lW3+ksm3NSZfG +W7j6nfVVw/RdXBrYvYZe8s1EMvjCK6RRoeFaZ24alXqExqJByMHcTVUM7uxNJxs3fgd 605A== 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:content-type; bh=o6vcfWvdIeAY+dDptNulhLGkpA4TFV9gx14HnMUbllg=; b=NUODy8roR2mUdcSTWJ3IsCPVKA9Jeaw9hYPOp6kl5JMFobk0zx6tRX8rp7Rc1hyJru B8l6n/5HIFArF1LXGZ5ttyvyBEeZiSRdjqHp4Sts8a36sDJvtxG5mdRuaohmsOj5WAtC Afy3SMsarfgxeHvJIpvIrMsUTsAIpsP2j3IngUZeeafqhD11Zui+ghICsAjcL22m5iRq G/mMLyCE+DGTdGSvlYUfQFAllI8/fsU+bIIktnOEjcJ/u4ZWSRlOjwjdONUGfVgQrg3o iS8VQsGzBiDUwrwGZITdfQRqRmI+EsVOzMcBnJZ8mCCCqu0/XsPQiNWRVZtw6NlEEe0i 3qMA== X-Gm-Message-State: ALoCoQkNYnwCKCOvxVkFDlp+FD5b4xA5gvRtEybGtFFzRmgwgzY8nhqzGQwseq2pbePv33dD7BoG X-Received: by 10.112.54.130 with SMTP id j2mr359271lbp.120.1446111865370; Thu, 29 Oct 2015 02:44:25 -0700 (PDT) Received: from [192.168.0.108] ([85.235.11.178]) by smtp.gmail.com with ESMTPSA id tp5sm141169lbb.27.2015.10.29.02.44.23 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 29 Oct 2015 02:44:24 -0700 (PDT) To: ace@ietf.org References: From: Ludwig Seitz Message-ID: <5631EA77.2060405@sics.se> Date: Thu, 29 Oct 2015 10:44:23 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms010509030403020301010500" Archived-At: Subject: Re: [Ace] comments on draft-seitz-ace-oauth-authz-00 X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 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, 29 Oct 2015 09:44:30 -0000 This is a cryptographically signed message in MIME format. --------------ms010509030403020301010500 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable Hello Madjid, Thank you for providing your comments on our draft! Answers are inline. /Ludwig On 2015-10-29 02:09, Madjid Nakhjiri wrote: [...] > 1. provisioning of client keys for authentication and registration wit= h > the AS. Having a global key/ID in the client has been an issue for > some OAUTH implementations in the past. Given that the clients are > IoT devices, this is not as straight forward as mobile app clients.= If I understand you correctly the problem is about having global IDs=20 that clients and AS can use to reference keys. I expect that in many cases the clients will only be served by a single=20 AS (or a few ones at most), which means that the key management problem=20 on that side is less difficult. Since the AS will probably manage keys for many clients, the IDs need to = be unique at least per AS. Therefore defining a namespace that is unique = for a specific AS and prefixing the key ID with that namespace should=20 work towards solving that problem. You seem to have experience with specific issues in that matter, could=20 you describe those issues in more detail? NOTE: ACE is explicitly not chartered to work with key management and=20 the word has been shunned from any document, therefore I do not expect=20 that ACE will work on that issue. > 2. Same thing for RS to AS registration. RS is many times a constraine= d > device itself. Also I am not clear how the AS will get the > authorization policies (scope/claim?) from RS. Is it that it is the= > AS that decides?? Actually it was never planned that the itself RS should provide and=20 manage the authorization policies at the AS. The resource owners are=20 expected to do this at the AS directly, when they enroll a RS they own. > 3. Is authorization subject based (identity of client) or role based? The solution should work with both approaches. The client is expected to = present credentials to the AS when requesting a token. These credentials = can then be resolved to an identity, or a role, or some security=20 attributes of the client. The AS is then expected to make an=20 authorization decision based on the credentials and the existing=20 authorization policies. > 4. Restrospection of the tokens can be expensive and unscalable for th= e > AS (if there are many RS nodes), but verification of self-contained= > tokens by the RS also sounds expensive, plus the verification keys > need to be provisioned in the RS. Would be nice to have guidance on= > which makes sense taking device capabilities/class into account. An= y > network simulators out there? I'm guessing you meant Introspection here right? The AS is not expected to be a constrained device, thus it should be=20 able to serve a significant number of introspection requests from=20 different RS. Introspection works best if the RS has a good connectivity = to the AS while the client has intermittent connectivity or simply=20 connectivity for the client is expensive (e.g. costs a lot of battery). Of course the number of AS has to be scaled up with the number of RS,=20 but I don't think that is any different for non-constrained scenarios. Verifying a self-contained token certainly can be expensive, but the=20 alternative is to be connected to the network in order to get a=20 real-time access control decision from an AS. We assume roughly the following "hierarchy" of costs (from most=20 expensive to least): 1. Network traffic (sending/receiving/listening for incoming messages) 2. Crypto operations 3. Matching requests against permissions granted by access tokens Several experiments I conducted have shown that 3. is almost negligible=20 when compared to the cost of 2. and 1. When you add the overhead of=20 running a security protocol when doing network communication, this makes = both 2. & 3. very cheap compared with 1. > 5. Wonder if the two app layer security solutions (OSCOAP/ OSCON) cove= r > the provisioning of the keys they are using? OSCOAP and OSCON are based on COSE, which in turn is based on JOSE=20 (JWE/JWS). JOSE and COSE have some key provisioning functionality > 6. If COAP option max length is 256 bits, how can a signature mechanis= m > that requires that many bits be used? > Carsten has already answered that and I agree with his assessment. --=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 http://www.sics.se --------------ms010509030403020301010500 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 DFQwggYYMIIFAKADAgECAgMMhpgwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYw FAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZp Y2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJt ZWRpYXRlIENsaWVudCBDQTAeFw0xNTAxMDgwODM5MDZaFw0xNjAxMDkyMjQxMzBaMDgxFzAV BgNVBAMMDmx1ZHdpZ0BzaWNzLnNlMR0wGwYJKoZIhvcNAQkBFg5sdWR3aWdAc2ljcy5zZTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMVB4rAuq4FxbARxwRqPLpc/3C194F+V H4XMKK6fu3Y8zDLijzNSjh6tG41oZhXvJcvAs1nZNjUutNLeyBAUFiYhy7HXNdlKpjbMEFKQ +6KpEdZ0Rk+pXgB2E1mqZEfp3M2djcQ/h+7uGVlSGYNAxYk6rWPIIWBx2GMvAQaHP4xxu/F+ PiSQILOVzmtIFZe1t/Lw71aaNeMYVhARo8z5PVsVoq6gBeujxfiRLtiQ/S8xW6RKvNvUkVyT BQfcKaEDZR9FENNf9rFgiAcT6R7hI8RBf1d2fxdlbDU8uM72K3fvzGDt8N9Bfm1kDWbDBxJE 1taRIYs+60D1kwV6DvBb9MECAwEAAaOCAtQwggLQMAkGA1UdEwQCMAAwCwYDVR0PBAQDAgSw MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAdBgNVHQ4EFgQU6ryrKahJtBOEdbIL AAWCpOsQyagwHwYDVR0jBBgwFoAUU3Ltkpzg2ssBXHx+ljVO8tS4UYIwGQYDVR0RBBIwEIEO bHVkd2lnQHNpY3Muc2UwggFMBgNVHSAEggFDMIIBPzCCATsGCysGAQQBgbU3AQIDMIIBKjAu BggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjCB9wYIKwYB BQUHAgIwgeowJxYgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwAwIBARqBvlRo aXMgY2VydGlmaWNhdGUgd2FzIGlzc3VlZCBhY2NvcmRpbmcgdG8gdGhlIENsYXNzIDEgVmFs aWRhdGlvbiByZXF1aXJlbWVudHMgb2YgdGhlIFN0YXJ0Q29tIENBIHBvbGljeSwgcmVsaWFu Y2Ugb25seSBmb3IgdGhlIGludGVuZGVkIHB1cnBvc2UgaW4gY29tcGxpYW5jZSBvZiB0aGUg cmVseWluZyBwYXJ0eSBvYmxpZ2F0aW9ucy4wNgYDVR0fBC8wLTAroCmgJ4YlaHR0cDovL2Ny bC5zdGFydHNzbC5jb20vY3J0dTEtY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEF BQcwAYYtaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczEvY2xpZW50L2NhMEIG CCsGAQUFBzAChjZodHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MxLmNs aWVudC5jYS5jcnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqG SIb3DQEBBQUAA4IBAQBl8BbG0n7+JjFqiJOuAqMbkeqM6Oyd+4oHGu3fbaSiM1SKesae2bfm vifV99a+M4DERZ2SVkOYcvNlv31Q3hvYtzRjDOqewzVKxo021R3ddQULW1DhvTEpclikG5rd 0NRJQn+EkSwEKLeUj68i0dhU8ULhZDDq3A81cTcZzIGrTjNnwDvCktB/sF/iO4At6RJ24P3j KjYFPirW3NsvZ2gzZizSzeubPE0/cWcqEBJ/UtaFPF54efejjLuPRHHMLPDcvrwBhEiBxuG6 oTEo465g4pS9Vo/Z0GoZgZyA+aGQ+YPbPSsqsYmSBjZ6MGGDqQq0niE2dW+8IOdHQvMkqI52 MIIGNDCCBBygAwIBAgIBHjANBgkqhkiG9w0BAQUFADB9MQswCQYDVQQGEwJJTDEWMBQGA1UE ChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUg U2lnbmluZzEpMCcGA1UEAxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwHhcN MDcxMDI0MjEwMTU1WhcNMTcxMDI0MjEwMTU1WjCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoT DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUg Q2xpZW50IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAxwmDzM4t2BqxKaQu E6uWvooyg4ymiEGWVUet1G8SD+rqvyNH4QrvnEIaFHxOhESip7vMz39ScLpNLbL1QpOlPW/t FIzNHS3qd2XRNYG5Sv9RcGE+T4qbLtsjjJbi6sL7Ls/f/X9ftTyhxvxWkf8KW37iKrueKsxw 2HqolH7GM6FX5UfNAwAu4ZifkpmZzU1slBhyWwaQPEPPZRsWoTb7q8hmgv6Nv3Hg9rmA1/VP BIOQ6SKRkHXG0Hhmq1dOFoAFI411+a/9nWm5rcVjGcIWZ2v/43Yksq60jExipA4l5uv9/+Hm 33mbgmCszdj/Dthf13tgAv2O83hLJ0exTqfrlwIDAQABo4IBrTCCAakwDwYDVR0TAQH/BAUw AwEB/zAOBgNVHQ8BAf8EBAMCAQYwHQYDVR0OBBYEFFNy7ZKc4NrLAVx8fpY1TvLUuFGCMB8G A1UdIwQYMBaAFE4L7xqkQFulF2mHMMo0aEPQQa7yMGYGCCsGAQUFBwEBBFowWDAnBggrBgEF BQcwAYYbaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL2NhMC0GCCsGAQUFBzAChiFodHRwOi8v d3d3LnN0YXJ0c3NsLmNvbS9zZnNjYS5jcnQwWwYDVR0fBFQwUjAnoCWgI4YhaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vc2ZzY2EuY3JsMCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNv bS9zZnNjYS5jcmwwgYAGA1UdIAR5MHcwdQYLKwYBBAGBtTcBAgEwZjAuBggrBgEFBQcCARYi aHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEFBQcCARYoaHR0cDov L3d3dy5zdGFydHNzbC5jb20vaW50ZXJtZWRpYXRlLnBkZjANBgkqhkiG9w0BAQUFAAOCAgEA CoMIfXirLAZcuGOMXq4cuSN3TaFx2H2GvD5VSy/6rV55BYHbWNaPeQn3oBSU8KgQZn/Kck1J xbLpAxVCNtsxeW1R87ifhsYZ0qjdrA9anrW2MAWCtosmAOT4OxK9QPoSjCMxM3HbkZCDJgnl E8jMopH21BbyAYr7b5EfGRQJNtgWcvqSXwKHnTutR08+Kkn0KAkXCzeQNLeA5LlYUzFyM7kP Ap8pIRMQ+seHunmyG642S2+y/qHEdMuGIwpfz3eDF1PdctL04qYK/zu+Qg1Bw0RwgigVZs/0 c5HP2/e9DBHh7eSwtzYlk4AUr6yxLlcwSjOfOmKEQ/Q8tzh0IFiNu9IPuTGAPBn4CPxD0+Ru 8T2wg8/s43R/PT3kd1OEqOJUl7q+h+r6fpvU0Fzxd2tC8Ga6fDEPme+1Nbi+03pVjuZQKbGw KJ66gEn06WqaxVZC+J8hh/jR0k9mST1iAZPNYulcNJ8tKmVtjYsv0L1TSm2+NwON58tO+pIV zu3DWwSEXSf+qkDavQam+QtEOZxLBXI++aMUEapSn+k3Lxm48ZCYfAWLb/Xj7F5JQMbZvCex glAbYR0kIHqW5DnsYSdMD/IplJMojx0NBrxJ3fN9dvX2Y6BIXRsF1du4qESm4/3CKuyUV7p9 DW3mPlHTGLvYxnyKQy7VFBkoLINszBrOUeIxggPtMIID6QIBATCBlDCBjDELMAkGA1UEBhMC SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENl cnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJ bnRlcm1lZGlhdGUgQ2xpZW50IENBAgMMhpgwDQYJYIZIAWUDBAIBBQCgggIpMBgGCSqGSIb3 DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE1MTAyOTA5NDQyM1owLwYJKoZI hvcNAQkEMSIEILA9HhqOb7Lfhr5sHzHPi0J2rEyYxtNKLjHBnmu9nv+DMGwGCSqGSIb3DQEJ DzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0D AgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgaUGCSsGAQQB gjcQBDGBlzCBlDCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzAp BgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0 YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgMMhpgwgacG CyqGSIb3DQEJEAILMYGXoIGUMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20g THRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG A1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EC AwyGmDANBgkqhkiG9w0BAQEFAASCAQB61ehqzRCNwpjP2so+7y+BjtTn2LgjmEaPOm/k88gf z+dxNgwHX2C5ttP87aanvLbPb9NnJaU60qwtTqEs3fhv8t+g0pm7OzicliRzYB6gP0TXrifR dojN4eCbOfBTMw5mDSgYgVTRfGKb66xuOItTelaf86gm0OuznU4vVTSKqAVx7AQCPRSMLjoZ 4MemtgfivsY/SY5UHBisCC2kR/lf6UjWbeSN89wdF1tIwWTKBX0Kcr5XuS++gQpIU8may1/+ 3HrIhNNdTjVO0dNAz1NI2d9IyxybpL/m1XsQbFa+OjmyfBO+SqFLK82bqWEZy/DtvvEztNhR RA14xfIb/D/PAAAAAAAA --------------ms010509030403020301010500-- From nobody Thu Oct 29 02:45:13 2015 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23F611B2C16 for ; Thu, 29 Oct 2015 02:45:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.25 X-Spam-Level: X-Spam-Status: No, score=-1.25 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dhNF7lm-GQkq for ; Thu, 29 Oct 2015 02:45:10 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EBC9C1B2C0F for ; Thu, 29 Oct 2015 02:45:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [134.102.201.11]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id t9T9j5Wi021173; Thu, 29 Oct 2015 10:45:05 +0100 (CET) Received: from dhcp-private-21-117.tpac.keio.w3.org (unknown [IPv6:2400:4040:0:23:109c:811c:bd4b:deb3]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3nmhhH1253z2Dkj; Thu, 29 Oct 2015 10:45:02 +0100 (CET) Message-ID: <5631EA97.5080609@tzi.org> Date: Thu, 29 Oct 2015 18:44:55 +0900 From: Carsten Bormann User-Agent: Postbox 4.0.7 (Macintosh/20151021) MIME-Version: 1.0 To: =?UTF-8?B?R8O2cmFuIFNlbGFuZGVy?= References: <5630E097.6030508@gmx.net> <87oafjkohu.fsf@aung.informatik.uni-bremen.de> <56316B19.2060800@tzi.org> In-Reply-To: X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: Hannes Tschofenig , Olaf Bergmann , "Ace@ietf.org" Subject: Re: [Ace] draft-bergmann-ace-dcaf-cose-00 vs. draft-selander-ace-object-security-03 X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 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, 29 Oct 2015 09:45:12 -0000 Well, OK, so both drafts are not security solutions by your definition, because the work on OSCOAP invariants also appears to be unfinished (or we wouldn't have to discuss it). I think the more interesting observation is that we need a way for the client to integrity-protect a view by the server about what the client *should* have received from the proxy as the set of URI options. For instance, it is not clear to me that the host part that the client uses to tell the proxy what server it wants it to talk to needs to be known to the server (e.g., the client may be using an RD endpoint name or DNS name as the host part, and the server may be blissfully unaware about all that). More generally, the operation of a reverse-proxy has even more freedoms for the proxy, and I'm not sure that we can always treat all reverse-proxies as having all of the authorizations of the server. (And that is where DCAF-COSE's Authorization-Format option comes in handy: There may be quite different ways to construct the Authorization Option. Of course, that information could instead be encoded into different values of the Authorization option number for each new such format.) Yes, we need that time in the CoRE meeting... (And, indeed, the interesting questions here appear to be CoRE questions.) When we're done with the above, we can start to think about the best ways to protect Max-Age via caching intermediaries (the spoofing of which clearly has significant security implications). (In parallel, we could do a version that survives an HTTP-CoAP mapper.) Grüße, Carsten From nobody Thu Oct 29 03:24:22 2015 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A121C1B2CD2 for ; Thu, 29 Oct 2015 03:24:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.901 X-Spam-Level: X-Spam-Status: No, score=-3.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y0qk3mo53-EC for ; Thu, 29 Oct 2015 03:24:15 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D89AC1B2CD4 for ; Thu, 29 Oct 2015 03:24:14 -0700 (PDT) X-AuditID: c1b4fb30-f79626d000006adf-6a-5631f3cc9c7f Received: from ESESSHC015.ericsson.se (Unknown_Domain [153.88.183.63]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 7F.EC.27359.CC3F1365; Thu, 29 Oct 2015 11:24:13 +0100 (CET) Received: from ESESSMB303.ericsson.se ([169.254.3.10]) by ESESSHC015.ericsson.se ([153.88.183.63]) with mapi id 14.03.0248.002; Thu, 29 Oct 2015 11:24:11 +0100 From: =?utf-8?B?R8O2cmFuIFNlbGFuZGVy?= To: Carsten Bormann Thread-Topic: [Ace] draft-bergmann-ace-dcaf-cose-00 vs. draft-selander-ace-object-security-03 Thread-Index: AQHREY/yaUXOV48wzEG97jc1zGEkzp6CKQuAgAAbuYA= Date: Thu, 29 Oct 2015 10:24:10 +0000 Message-ID: References: <5630E097.6030508@gmx.net> <87oafjkohu.fsf@aung.informatik.uni-bremen.de> <56316B19.2060800@tzi.org> <5631EA97.5080609@tzi.org> In-Reply-To: <5631EA97.5080609@tzi.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.7.141117 x-originating-ip: [153.88.183.20] Content-Type: text/plain; charset="utf-8" Content-ID: <7D6EE1E5022068478782D288A337A909@ericsson.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrOIsWRmVeSWpSXmKPExsUyM2K7ve7Zz4ZhBudPMFp8/9bDbNG0uJHJ 4siUu6wWS3feY3Vg8Vi8aT+bx5IlP5k8pi3KDGCO4rJJSc3JLEst0rdL4MqYs3UhS8EFqYrN c44zNjD+kOxi5OSQEDCRmP7xOxOELSZx4d56ti5GLg4hgcOMEicfz2WEcBYzShy99YQRpIpN wEXiQcMjsA4RASWJCxfXsIHYzAJlEl+Pn2XuYuTgEBaIk/jZ6QNREi9x49dmZgjbSmLz/RVg NouAqsTBpXtZQWxeAQuJ9xvOM0Pses0o0dHeADafU0BdonfBKTCbEei676fWMEHsEpe49WQ+ 1NUCEkv2nGeGsEUlXj7+BzZUVEBPYuX1JjaIuKLE1enLmUBuYxbQlFi/Sx/CtJbo3GcDMVFR Ykr3Q3aIcwQlTs58wjKBUWIWkmWzEJpnITTPQtI8C0nzAkbWVYyixanFSbnpRkZ6qUWZycXF +Xl6eaklmxiB0Xlwy2+DHYwvnzseYhTgYFTi4S0INgwTYk0sK67MPcQowcGsJMIrdAMoxJuS WFmVWpQfX1Sak1p8iFGag0VJnLeZ6UGokEB6YklqdmpqQWoRTJaJg1OqgZFD97bw+lqnK7vP JBqUa3T/ela45l2cQesFEW175vP/N1opLL7wM09hkuzDWR9Lbdg6N260KHTQPhSvcrVj9eJa a/ZEpuLr9sdLHj7ukvMLuPqkb7Ls080LSns3emdWPpJaziPWWu1bWuxiP/0lW/2H0FcH5174 +urfYbbD/HY6QrWvn5Q8MVFiKc5INNRiLipOBACU4oYFygIAAA== Archived-At: Cc: Hannes Tschofenig , Olaf Bergmann , "Ace@ietf.org" Subject: Re: [Ace] draft-bergmann-ace-dcaf-cose-00 vs. draft-selander-ace-object-security-03 X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 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, 29 Oct 2015 10:24:20 -0000 DQpPbiAyMDE1LTEwLTI5IDEwOjQ0LCAiQ2Fyc3RlbiBCb3JtYW5uIiA8Y2Fib0B0emkub3JnPiB3 cm90ZToNCg0KPldlbGwsIE9LLCBzbyBib3RoIGRyYWZ0cyBhcmUgbm90IHNlY3VyaXR5IHNvbHV0 aW9ucyBieSB5b3VyIGRlZmluaXRpb24sDQo+YmVjYXVzZSB0aGUgd29yayBvbiBPU0NPQVAgaW52 YXJpYW50cyBhbHNvIGFwcGVhcnMgdG8gYmUgdW5maW5pc2hlZCAob3INCj53ZSB3b3VsZG4ndCBo YXZlIHRvIGRpc2N1c3MgaXQpLg0KDQpXZWxsLCBpbiBDT1JFIEkgd2FzIHRoaW5raW5nIG9mIGRp c2N1c3NpbmcgZS5nLiBibG9ja3dpc2UsIHdoaWNoIGNhbm5vdA0KcHJvdmlkZSBlbmQtdG8tZW5k IHNlY3VyaXR5IG9mIGluZGl2aWR1YWwgYmxvY2tzLCBhbmQgd2hpY2ggZG9lcyBub3QgYWxsb3cN CmFuIGludmFyaWFudCB0byBiZSBkZWZpbmVkLiBCdXQgdGhpcyBpcyBhIHNlY3VyaXR5IGlzc3Vl IHdpdGggYmxvY2t3aXNlLA0Kbm90IHdpdGggT1NDT0FQLiBPciBPYnNlcnZlLCB3aGljaCBpcyBz dXBwb3J0ZWQgaW4gT1NDT0FQIGJ5IGludHJvZHVjaW5nDQpzZXBhcmF0ZSBjb250ZXh0cyBmb3Ig c2VuZGluZyBhbmQgcmVjZWl2ZSwgYnV0IHdoaWNoIGNvdWxkIGJlIG9wdGltaXplZC4NCkluIGJv dGggdGhlc2UgY2FzZXMsIHNlY3VyZSBibG9jayBvcHRpb25zIGFuZCBhIHNlY3VyZSBvYnNlcnZl IG9wdGlvbiBhcmUNCklNSE8gY2FuZGlkYXRlIHNvbHV0aW9ucy4gQXMgbWVudGlvbmVkIHdlIHdl bGNvbWUgYSByZXZpZXcgb2YgT1NDT0FQOyB3ZQ0KYXJlIG5vdCBhd2FyZSBvZiBhbnkgaXNzdWVz LCBpbiBjb250cmFzdCB0byBEQ0FGLUNPU0Ugd2hpY2ggZXNzZW50aWFsbHkNCndvdWxkIG5lZWQg dG8gcmUtaW52ZW50IE9TQ09BUCB0byBhZGRyZXNzIHRoZSB0aGluZ3Mgd2UgaGF2ZSBkaXNjdXNz ZWQgc28NCmZhci4NCg0KPg0KPkkgdGhpbmsgdGhlIG1vcmUgaW50ZXJlc3Rpbmcgb2JzZXJ2YXRp b24gaXMgdGhhdCB3ZSBuZWVkIGEgd2F5IGZvciB0aGUNCj5jbGllbnQgdG8gaW50ZWdyaXR5LXBy b3RlY3QgYSB2aWV3IGJ5IHRoZSBzZXJ2ZXIgYWJvdXQgd2hhdCB0aGUgY2xpZW50DQo+KnNob3Vs ZCogaGF2ZSByZWNlaXZlZCBmcm9tIHRoZSBwcm94eSBhcyB0aGUgc2V0IG9mIFVSSSBvcHRpb25z LiAgRm9yDQo+aW5zdGFuY2UsIGl0IGlzIG5vdCBjbGVhciB0byBtZSB0aGF0IHRoZSBob3N0IHBh cnQgdGhhdCB0aGUgY2xpZW50IHVzZXMNCj50byB0ZWxsIHRoZSBwcm94eSB3aGF0IHNlcnZlciBp dCB3YW50cyBpdCB0byB0YWxrIHRvIG5lZWRzIHRvIGJlIGtub3duDQo+dG8gdGhlIHNlcnZlciAo ZS5nLiwgdGhlIGNsaWVudCBtYXkgYmUgdXNpbmcgYW4gUkQgZW5kcG9pbnQgbmFtZSBvciBETlMN Cj5uYW1lIGFzIHRoZSBob3N0IHBhcnQsIGFuZCB0aGUgc2VydmVyIG1heSBiZSBibGlzc2Z1bGx5 IHVuYXdhcmUgYWJvdXQNCj5hbGwgdGhhdCkuIA0KDQpZZXMsIHRoYXQgaXMgdGhlIHR5cGUgb2Yg ZGlzY3Vzc2lvbiB3ZSB3YW50IHRvIGhhdmUuDQoNCj4gTW9yZSBnZW5lcmFsbHksIHRoZSBvcGVy YXRpb24gb2YgYSByZXZlcnNlLXByb3h5IGhhcyBldmVuDQo+bW9yZSBmcmVlZG9tcyBmb3IgdGhl IHByb3h5LCBhbmQgSSdtIG5vdCBzdXJlIHRoYXQgd2UgY2FuIGFsd2F5cyB0cmVhdA0KPmFsbCBy ZXZlcnNlLXByb3hpZXMgYXMgaGF2aW5nIGFsbCBvZiB0aGUgYXV0aG9yaXphdGlvbnMgb2YgdGhl IHNlcnZlci4NCj4NCj4oQW5kIHRoYXQgaXMgd2hlcmUgRENBRi1DT1NFJ3MgQXV0aG9yaXphdGlv bi1Gb3JtYXQgb3B0aW9uIGNvbWVzIGluDQo+aGFuZHk6IFRoZXJlIG1heSBiZSBxdWl0ZSBkaWZm ZXJlbnQgd2F5cyB0byBjb25zdHJ1Y3QgdGhlIEF1dGhvcml6YXRpb24NCj5PcHRpb24uICBPZiBj b3Vyc2UsIHRoYXQgaW5mb3JtYXRpb24gY291bGQgaW5zdGVhZCBiZSBlbmNvZGVkIGludG8NCj5k aWZmZXJlbnQgdmFsdWVzIG9mIHRoZSBBdXRob3JpemF0aW9uIG9wdGlvbiBudW1iZXIgZm9yIGVh Y2ggbmV3IHN1Y2gNCj5mb3JtYXQuKQ0KPg0KPlllcywgd2UgbmVlZCB0aGF0IHRpbWUgaW4gdGhl IENvUkUgbWVldGluZy4uLg0KPihBbmQsIGluZGVlZCwgdGhlIGludGVyZXN0aW5nIHF1ZXN0aW9u cyBoZXJlIGFwcGVhciB0byBiZSBDb1JFIHF1ZXN0aW9ucy4pDQo+DQo+V2hlbiB3ZSdyZSBkb25l IHdpdGggdGhlIGFib3ZlLCB3ZSBjYW4gc3RhcnQgdG8gdGhpbmsgYWJvdXQgdGhlIGJlc3QNCj53 YXlzIHRvIHByb3RlY3QgTWF4LUFnZSB2aWEgY2FjaGluZyBpbnRlcm1lZGlhcmllcyAodGhlIHNw b29maW5nIG9mDQo+d2hpY2ggY2xlYXJseSBoYXMgc2lnbmlmaWNhbnQgc2VjdXJpdHkgaW1wbGlj YXRpb25zKS4gIChJbiBwYXJhbGxlbCwgd2UNCj5jb3VsZCBkbyBhIHZlcnNpb24gdGhhdCBzdXJ2 aXZlcyBhbiBIVFRQLUNvQVAgbWFwcGVyLikNCg0KQWxzbyBnb29kIHRvcGljcyBmb3IgdGhlIENv UkUgbWVldGluZy4NCg0KPg0KPkdyw7zDn2UsIENhcnN0ZW4NCg0K From nobody Thu Oct 29 08:49:27 2015 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3891C1A8902 for ; Thu, 29 Oct 2015 08:49:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.901 X-Spam-Level: X-Spam-Status: No, score=-3.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iPga6Wvt_liq for ; Thu, 29 Oct 2015 08:49:24 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9AEDE1A8901 for ; Thu, 29 Oct 2015 08:49:23 -0700 (PDT) X-AuditID: c1b4fb25-f79a26d00000149a-4a-563240011a10 Received: from ESESSHC008.ericsson.se (Unknown_Domain [153.88.183.42]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id B8.78.05274.10042365; Thu, 29 Oct 2015 16:49:21 +0100 (CET) Received: from ESESSMB303.ericsson.se ([169.254.3.10]) by ESESSHC008.ericsson.se ([153.88.183.42]) with mapi id 14.03.0248.002; Thu, 29 Oct 2015 16:48:38 +0100 From: =?utf-8?B?R8O2cmFuIFNlbGFuZGVy?= To: Olaf Bergmann , Hannes Tschofenig Thread-Topic: [Ace] draft-bergmann-ace-dcaf-cose-00 vs. draft-selander-ace-object-security-03 Thread-Index: AQHREY/yaUXOV48wzEG97jc1zGEkzp6BBZT6///2toCAABoT14ABiQ4A Date: Thu, 29 Oct 2015 15:48:37 +0000 Message-ID: References: <5630E097.6030508@gmx.net> <87oafjkohu.fsf@aung.informatik.uni-bremen.de> <5630EE4D.7080202@gmx.net> <87a8r3klpq.fsf@aung.informatik.uni-bremen.de> In-Reply-To: <87a8r3klpq.fsf@aung.informatik.uni-bremen.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.7.141117 x-originating-ip: [153.88.183.20] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrMIsWRmVeSWpSXmKPExsUyM2K7li6jg1GYwfzZUhbfv/UwWzQtbmSy WLrzHqsDs8fiTfvZPJYs+cnkMW1RZgBzFJdNSmpOZllqkb5dAlfGo7n7GAvatCuON69mb2D8 odnFyMkhIWAi8fZbKzOELSZx4d56ti5GLg4hgcOMEn/ufGOHcBYzSuw+PYcNpIpNwEXiQcMj JhBbRCBUYunGdywgNrOAosTuWWeBGjg4hAXiJH52+kCUxEvc+LWZGSQsIuAmcfNcAUiYRUBV 4mPPO7ApvAIWEiv2TWCBW/Vw5VewVZwC1hJ9828wgtiMQMd9P7WGCWKVuMStJ/OZII4WkFiy 5zzUA6ISLx//YwWxRQX0JFZeb2KDiCtKXJ2+nAnkBmYBTYn1u/QhxlhLzN3cywRz/ZTuh+wQ 9whKnJz5hGUCo8QsJNtmIXTPQtI9C0n3LCTdCxhZVzGKFqcWJ+WmGxnrpRZlJhcX5+fp5aWW bGIERuXBLb9VdzBefuN4iFGAg1GJh7cg2DBMiDWxrLgy9xCjBAezkghvh6FRmBBvSmJlVWpR fnxRaU5q8SFGaQ4WJXHeZqYHoUIC6YklqdmpqQWpRTBZJg5OqQZG/r08EUdE7M595LM5fv/i rmtxq9WvSftaevFO6lv3mjX40F3uqRURR727Hmoeu5Ljev8J6/3PO/Jnrrt0xeicyLMkG6PL DuG7L+b6cL9NvBWs8k7qVesiTjstjp/+Il+Y3ibIF6uGylr0O5fNPlVR/sL956IQ2zXRkdc3 cD+bcqmWKdovc3GYEktxRqKhFnNRcSIAP6FYucYCAAA= Archived-At: Cc: "Ace@ietf.org" Subject: Re: [Ace] draft-bergmann-ace-dcaf-cose-00 vs. draft-selander-ace-object-security-03 X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 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, 29 Oct 2015 15:49:26 -0000 SGkgT2xhZiwgSGFubmVzIGFuZCBhbGwsDQoNCkNvbWluZyBiYWNrIHRvIHRoZSBBQ0UgZGlzY3Vz c2lvbi4NCg0KT24gMjAxNS0xMC0yOCAxNzoyMSwgIk9sYWYgQmVyZ21hbm4iIDxiZXJnbWFubkB0 emkub3JnPiB3cm90ZToNCj4NCj5NeSBhcHByb2FjaCB3b3VsZCBiZSB0byBsZXQgQ29SRSAocG9z c2libHkgdG9nZXRoZXIgd2l0aCBDT1NFIGZvbGtzKQ0KPnN0YW5kYXJkaXplIGEgbWVjaGFuaXNt IHRvIHByb3RlY3QgQ29BUCBtZXNzYWdlcyBvbiB0aGUgYXBwbGljYXRpb24NCj5sYXllciBhbmQg dGhlbiB1c2UgdGhhdCBtZWNoYW5pc20gZm9yIHRoZSBhdXRob3JpemF0aW9uIHNvbHV0aW9uIGlu DQo+QUNFLiBXZSBkbyB0aGlzIHdpdGggRENBRi1EVExTIGFuZCB0aGF0IGlzIGFsc28gd2hlcmUg RENBRi1DT1NFIGlzDQo+aGVhZGluZy4gQnV0IHNpbmNlIENvUkUgZG9lcyBub3QgeWV0IGhhdmUg YSB3b3JraW5nIGdyb3VwIGl0ZW0gb24gdGhlDQo+b2JqZWN0IHNlY3VyaXR5IHBhcnQgSSB3ZW50 IGZvciBteSBvd24gYmFzaWMgdW5kZXJzdGFuZGluZyBvZiBob3cgQ09TRQ0KPm1lc3NhZ2luZyBp cyBkZXNpZ25lZCB0byBiZSB1c2VkLiBJdCBpcyBwcmV0dHkgbXVjaCBhIGhpZ2gtbGV2ZWwgc3Vt bWFyeQ0KPm9mIHdoaWNoIERDQUYgaW5mb3JtYXRpb24gaXRlbSBtdXN0IGdvIHdoZXJlLCB0aGUg ZGV0YWlscyBzdGlsbCB0byBiZQ0KPndvcmtlZCBvdXQuDQo+DQoNCg0KW0dTXSBJIGFsc28gYWdy ZWUgdGhhdCB0aGUgb2JqZWN0IHNlY3VyaXR5IG9mIENvQVAgZGlzY3Vzc2lvbiBiZWxvbmdzIGlu DQpDT1JFIGFuZCBhcyBzdWNoLCB0aGVyZSBpcyBubyBuZWVkIHRvIHByZXNlbnQgdGhhdCBpbiBB Q0UuIEFsdGhvdWdoIG9iamVjdA0Kc2VjdXJpdHkgZm9yIENvQVAgaXNu4oCZdCBhIHdvcmtpbmcg Z3JvdXAgaXRlbSwgdGhlcmUgaXMgb25seSBvbmUgY2FuZGlkYXRlDQpwcm9wb3NhbCwgaXQgaGFz IGJlZW4gYXJvdW5kIGZvciBhIHllYXIsIGl0IGhhcyBiZWVuIHByZXNlbnRlZCBpbiB0aGUgbGFz dA0KdHdvIENPUkUgRjJGIG1lZXRpbmdzIHNvIGlzIGNsZWFybHkga25vd24gdG8gdGhlIGF1dGhv cnMuDQoNCk5ldmVydGhlbGVzcywgdGhleSBjaG9zZSB0byBub3QgdXNlIHRoYXQgYnV0IGluc3Rl YWQgdHJpZXMgdG8gcmVpbnZlbnQgdGhlDQp3aGVlbCBhbmQgaXQgaXMgb2J2aW91c2x5IG92ZXJs YXBwaW5nIHdpdGggT1NDT0FQOiBJbmRlZWQsIGJvdGggc29sdXRpb25zDQpkZXNjcmliZSBwcm90 ZWN0aW9uIG9mIENvQVAgbWVzc2FnZXMgYmFzZWQgb24gd3JhcHBpbmcgQ29BUCBoZWFkZXIgZmll bGRzDQpDb2RlIGFuZCBWZXJzaW9uIHRvZ2V0aGVyIHdpdGggYSBzZWxlY3RlZCBsaXN0IG9mIGRl bHRhLWVuY29kZWQgb3B0aW9ucw0KKHNlY3Rpb24gNikgYW5kIHBheWxvYWQgYXMgYSBDT1NFIG1l c3NhZ2Ugd2hpY2ggaW5jbHVkZXMgYSBjb250ZXh0DQppZGVudGlmaWVyIGluIHRoZSBwcm90ZWN0 ZWQgaGVhZGVyIGFuZCBzZW5kIHRoaXMgYXMgcGF5bG9hZCBvZiBhIENvQVANCm1lc3NhZ2UsIHVu bGVzcyB0aGUgQ29BUCBtZXNzYWdlIHBheWxvYWQgaXMgbm90IHBvc3NpYmxlIChlLmcuIGluIEdF VA0KcmVxdWVzdHMpIGluIHdoaWNoIGNhc2UgYSBuZXcgQ29BUCBvcHRpb24gaXMgaW50cm9kdWNl ZCB3aGljaCB0aGVuDQpjb250YWlucyB0aGUgQ09TRSBtZXNzYWdlLiBUaGVyZSBhcmUgb2YgY291 cnNlIGRpZmZlcmVuY2VzIGluIGRldGFpbHMsDQplLmcuIERDQUYtQ09TRSB0dXJucyBvdXQgdG8g bWlzcyBzb21lIG9mIHRoZSBzZWN1cml0eSBmZWF0dXJlcyBvZiBPU0NPQVAuDQoNCk9mIGNvdXJz ZSwgZXZlcnlvbmUgaXMgZW50aXRsZWQgdG8gc3VibWl0IHRoZWlyIG93biBwcm9wb3NhbCBldmVu IHRob3VnaA0KdGhlcmUgYXJlIGNhbmRpZGF0ZXMgd2hpY2ggaGFzIGJlZW4gYXJvdW5kIGZvciBh IHdoaWxlLiBUaGUgaW50ZXJlc3RpbmcNCnBvaW50IGlzIHRoYXQgdGhpcyBpcyBhY3R1YWxseSBz eW1wdG9tYXRpYyBvZiBEQ0FGLCBzZWUgYmVsb3cuDQoNCg0KT24gMjAxNS0xMC0yOCAxNjoyMSwg Ik9sYWYgQmVyZ21hbm4iIDxiZXJnbWFubkB0emkub3JnPiB3cm90ZToNCg0KPkhpIEhhbm5lcywN Cj4NCj5IYW5uZXMgVHNjaG9mZW5pZyA8aGFubmVzLnRzY2hvZmVuaWdAZ214Lm5ldD4gd3JpdGVz Og0KPg0KPj5XZSBoYXZlIGdvdHRlbiBhbiBhZ2VuZGEgcmVxdWVzdCBmb3IgZHJhZnQtYmVyZ21h bm4tYWNlLWRjYWYtY29zZS0wMCwNCj4+d2hpY2ggaXMgYWJvdXQgdXNpbmcgQ09TRSB0byBwcm92 aWRlIGEgb2JqZWN0LWxldmVsIHNlY3VyaXR5IGZvciBEQ0FGLg0KPg0KPk5vLCBpdCdzIG5vdC4g SXQgaXMgYWJvdXQgcHJvdmlkaW5nIGF1dGhlbnRpY2F0ZWQgYXV0aG9yaXphdGlvbiB3aGljaCBp cw0KPmNsZWFybHkgaW4gdGhlIGZvY3VzIG9mIHRoZSBBQ0UgV0cuIEl0IGRvZXMgdGhpcyBieSB1 c2luZyBEQ0FGLg0KPg0KPkF0IHRoZSBJRVRGLTkzIG1lZXRpbmcgaW4gUHJhZ3VlLCBzZXZlcmFs IHBlb3BsZSBjcml0aWNpemVkDQo+ZHJhZnQtZ2VyZGVzLWFjZS1kY2FmLWF1dGhvcml6ZSBiZWNh dXNlIGl0IHVzZXMgRFRMUyB0byBwcm92aWRlIHNlY3VyZQ0KPmNvbW11bmljYXRpb24uIFRoZSBu ZXcgZHJhZnQtYmVyZ21hbm4tYWNlLWRjYWYtY29zZSBzcGVjaWZpZXMgaG93IERDQUYNCj5jYW4g YmUgdXNlZCB3aXRoIENPU0Ugc3ludGF4LiBJdCBkb2VzICpub3QqIHNwZWNpZnkgaG93IG9iamVj dCBzZWN1cml0eQ0KPndvcmtzLCBpdCBqdXN0ICptYWtlcyB1c2UqIG9mIHdoYXQgaXMgYWxyZWFk eSB0aGVyZS4NCj4NCg0KDQoNCkFjdHVhbGx5LCBEQ0FGIGluIGdlbmVyYWwgZG9lcyAqbm90KiBt YWtlIHVzZSBvZiB3aGF0IOKAnGlzIGFscmVhZHkgdGhlcmXigJ0uDQpPU0NPQVAg4oCcd2FzIGFs cmVhZHkgdGhlcmXigJ0gYnV0IGluc3RlYWQgRENBRiBpbnN0ZWFkIHRyaWVzIHRvIHJlLWludmVu dCBpdC4NCkFuZCB0aGlzIGlzIG5vdCBhbiBpc29sYXRlZCBleGFtcGxlLCBoZXJlIGlzIGEgc2hv cnQgbGlzdA0KDQoNCjAuIERDQUYgZG9lcyBub3QgbWFrZSB1c2Ugb2YgT1NDT0FQIGJ1dCB0cmll cyB0byByZWludmVudCBzb21ldGhpbmcNCnNpbWlsYXIgDQoxLiBEQ0FGIGRvZXMgbm90IHVzZSBl c3RhYmxpc2hlZCB0ZXJtaW5vbG9neSwgaXQgaW52ZW50cyBpdHMgb3duIG5hbWVzOiBvZg0Kbm9k ZXMgaW4gdGhlIGFyY2hpdGVjdHVyZSwgb2YgbWVzc2FnZXMsIG9mIGFjY2VzcyB0b2tlbiwgcGFy dHMgb2YgYWNjZXNzDQp0b2tlbiwg4oCcYXV0aGVudGljYXRlZCBhdXRob3JpemF0aW9u4oCdLCBl dGMuDQoyLiBEQ0FGIGRvZXMgbm90IHVzZSBSRkM0NjgwIGZvciB0cmFuc21pdHRpbmcgdGhlIGFj Y2VzcyB0b2tlbiAod2hpY2ggRENBRg0KY2FsbHMg4oCcdGlja2V0IikgaW4gdGhlIERUTFMgaGFu ZHNoYWtlLCBpdCBpbnZlbnRzIGl0cyBvd24gdmVyc2lvbiBiYXNlZCBvbg0KUFNLLWlkZW50aXR5 DQozLiBEQ0FGIGRvZXMgbm90IGF0dGVtcHQgdG8gcHJvZmlsZSBhbnkgZXhpc3RpbmcgYXV0aG9y aXphdGlvbiBwcm90b2NvbCwNCmxpa2UgdGhlIGVzdGFibGlzaGVkIGFuZCB3aWRlbHkgZGVwbG95 ZWQgT0F1dGgsIGJ1dCBtYWtlcyBhIGNsZWFuIHNsYXRlLg0KDQoNCg0KSSB0aGluayB0aGlzIGlz IHRoZSBtYWluIHF1ZXN0aW9uIGZvciB0aGUgdXBjb21pbmcgQUNFIFdHIG1lZXRpbmc6IERvIHdl DQp3YW50IHRvIHJldXNlIHdoYXQg4oCcaXMgYWxyZWFkeSB0aGVyZeKAnSBvciBkbyB3ZSB3YW50 IGEgY2xlYW4gc2xhdGU/DQoNCkhhdmluZyBzYWlkIHRoaXMsIEkgd291bGQgbGlrZSB0byBhY2tu b3dsZWRnZSB0aGF0IERDQUYgaGFzIHNvbWUgZ29vZA0KaW1wbGVtZW50YXRpb24gY29uc2lkZXJh dGlvbnMuIExldCdzIHJldXNlIHRob3NlIChpbnN0ZWFkIG9mIHJlLWludmVudGluZw0KdGhlIHdo ZWVsKSAgd2hlbiB3ZSBwcm9maWxlIE9BdXRoIGZvciBJb1QgaW4gQUNFIQ0KDQoNClNlZSB5b3Ug aW4gWW9rb2hhbWEuDQoNCkfDtnJhbg0KDQoNCg0KDQoNCg== From nobody Thu Oct 29 12:02:08 2015 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 946731A8A17 for ; Thu, 29 Oct 2015 12:02:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.649 X-Spam-Level: X-Spam-Status: No, score=0.649 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sKQLlZKxqZMJ for ; Thu, 29 Oct 2015 12:02:01 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3BDB11A8A07 for ; Thu, 29 Oct 2015 12:01:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::b]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id t9TJ1e0n000120; Thu, 29 Oct 2015 20:01:40 +0100 (CET) Received: from nar.local (s228060.ppp.asahi-net.or.jp [220.157.228.60]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3nmx2V2HtRz2G6q; Thu, 29 Oct 2015 20:01:37 +0100 (CET) Message-ID: <56326D0D.9020309@tzi.org> Date: Fri, 30 Oct 2015 04:01:33 +0900 From: Carsten Bormann User-Agent: Postbox 4.0.7 (Macintosh/20151021) MIME-Version: 1.0 To: =?UTF-8?B?R8O2cmFuIFNlbGFuZGVy?= X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: Hannes Tschofenig , Olaf Bergmann , "Ace@ietf.org" Subject: [Ace] Innovating X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 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, 29 Oct 2015 19:02:07 -0000 Much of the IETF work in the constrained space has been about taking a fresh look instead of succumbing to "because its there" (BIT) arguments. 6LoWPAN did not take ROHC, but invented a new header compression (twice, throwing out the first one after four years). It dared to make multi-link subnets its standard approach. It did not just take ND, but modified it into 6LoWPAN-ND. ROLL did not take OSPF or IS-IS, but standardized RPL (and can let a thousand flowers bloom there, as e.g. Thread is using RIP). We didn't take HTTP in CoRE, but designed CoAP, using many of the same principles. But of course many other things were taken as is, because: -- they do solve the actual problem -- they don't bring prohibitive baggage/drawbacks and/or -- there are substantial network effects from BIT. You can read more about this approach in https://www.iab.org/wp-content/IAB-uploads/2011/04/Bormann.pdf A nice illustration of where we were if we weren't doing that is in http://j.mp/gsD4r7 Each time the constrained work entered a new domain (INT, RTG, APP), there are these heated arguments about not always using the existing hammers. In Security, BIT arguments are often quite compelling, so the threshold is probably higher (I'm sure RTG people will disagree). Oh, and in the development of both 6LoWPAN-ND and CoAP, we have thrown out things that had been in the WG document (or even standardized!) for over a year or longer when better alternatives came along. This sometimes has been painful, when the old way of doing things already had been well-accepted and implemented interoperably. I hope we can do that here, as well. Grüße, Carsten From nobody Thu Oct 29 13:52:30 2015 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BB8F1ACD05 for ; Thu, 29 Oct 2015 13:52:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.31 X-Spam-Level: X-Spam-Status: No, score=-2.31 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FakU7L_UEMkn for ; Thu, 29 Oct 2015 13:52:22 -0700 (PDT) Received: from smtp.nexusgroup.com (smtp.nexusgroup.com [83.241.133.121]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E3BE91ACD04 for ; Thu, 29 Oct 2015 13:52:21 -0700 (PDT) Received: from NG-EX01.ad.nexusgroup.com (10.75.28.40) by NG-EX02.ad.nexusgroup.com (10.75.28.43) with Microsoft SMTP Server (TLS) id 15.0.995.29; Thu, 29 Oct 2015 21:52:18 +0100 Received: from NG-EX01.ad.nexusgroup.com ([fe80::1d3d:b319:f020:2bab]) by NG-EX01.ad.nexusgroup.com ([fe80::1d3d:b319:f020:2bab%12]) with mapi id 15.00.0995.032; Thu, 29 Oct 2015 21:52:18 +0100 From: =?utf-8?B?RXJpayBXYWhsc3Ryw7ZtIG5lWHVz?= To: Carsten Bormann Thread-Topic: [Ace] Innovating Thread-Index: AQHREnxVshZUyXaFa0mKUZLtQV2z3p6C4ayA Date: Thu, 29 Oct 2015 20:52:17 +0000 Message-ID: References: <56326D0D.9020309@tzi.org> In-Reply-To: <56326D0D.9020309@tzi.org> Accept-Language: en-US, sv-SE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.2104) x-originating-ip: [94.234.170.26] Content-Type: text/plain; charset="utf-8" Content-ID: <11EC5E0CB7CB1848ABD541D88D2744AF@nexusgroup.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: Hannes Tschofenig , =?utf-8?B?R8O2cmFuIFNlbGFuZGVy?= , Olaf Bergmann , "Ace@ietf.org" Subject: Re: [Ace] Innovating X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 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, 29 Oct 2015 20:52:28 -0000 SSBoYXZlIG5vIGludGVyZXN0IGluIHRocm93aW5nIGF3YXkgdGhpbmdzIHRoYXTigJlzIHdlbGwg YWNjZXB0ZWQgYW5kIHdvcmtzIGp1c3QgYmVjYXVzZSB3ZSBjYW4uIFdlIGNvdWxkIGVxdWFsbHkg dGFsayBhYm91dCDigJxpZiBpdOKAmXMgbm90IGJyb2tlLCBkb27igJl0IGZpeCBpdOKAnSBoZXJl Lg0KDQpNYWtpbmcgc29tZXRoaW5nIG5ldyBqdXN0IGJlY2F1c2UgaXTigJlzIGZ1biBpcyBub3Qg YSBnb29kIHRoaW5nIHdoZW4gaXQgY29tZXMgdG8gc2VjdXJpdHkuIEludHJvZHVjaW5nIG5ldyB0 ZXJtaW5vbG9neSAgYW5kIGNvbmNlcHRzIG9uIGV4aXN0aW5nIHRoaW5ncyBpcyBub3QgaW5ub3Zh dGl2ZS4gTGltaXRpbmcgdGhlIHdvcmsgdG8gc3ltbWV0cmljIGtleSBjcnlwdG8gYW5kIG9ubHkg Y29uc3RyYWluZWQgZGV2aWNlcyBpcyBub3QgaW5ub3ZhdGlvbi4gQ3JlYXRpbmcgYW4gb3duIHNw aGVyZSBvZiBwcm90b2NvbHMgdGhhdCBkb27igJl0IGludGVyb3Agd2l0aCBvdGhlcnMgaXMgbm90 IHRoZSB3YXkgZm9yd2FyZC4NCg0KV2UgbXVzdCBoZWxwIHRoZSBkZXZlbG9wZXJzIHdobyBpbXBs ZW1lbnQgdGhlIHNlY3VyaXR5IGZvciwgYm90aCBiaWcgYW5kIHNtYWxsLCBkZXZpY2VzIGFuZCBt YWtlIGl0IHN1cGVyIGNsZWFyIGFuZCBjb25zaXN0YW50IGJldHdlZW4gdGhlbSBhbGwuIEl04oCZ cyBkZWZpbml0ZWx5IG5vdCBhIGdvb2QgdGhpbmcgaWYgZGV2ZWxvcGVycyBnZXQgaXQgd3Jvbmcg d2hlbiB0aGV5IGltcGxlbWVudCB5ZXQgYW5vdGhlciBzZWN1cml0eSBmcmFtZXdvcmsuIFdlIHNo b3VsZCBub3QgY29uZnVzZSBhbmQgYnJpbmcgc29tZXRoaW5nIG5ldyB0byB0aGUgdGFibGUsIGp1 c3QgYmVjYXVzZSB3ZSB3YW50IHRvIGJlIGlubm92YXRpdmUuIA0KDQpXZSBzaG91bGQgZm9jdXMg b3VyIGVmZm9ydHMgaW4gdGFraW5nIHdoYXQgd2UgaGF2ZSwgdGhhdCB3ZSBrbm93cyBzY2FsZXMg YW5kIHdvcmtzLCBhbmQgY2FuIGJlIHRpZWQgaW50byBleGlzdGluZyBpbmZyYXN0cnVjdHVyZXMg YW5kIHBvbGljaWVzLCBhbmQgcHJvZmlsZSBpdCB3b3JrIGZvciBjb25zdHJhaW5lZCBkZXZpY2Vz Lg0KDQpJRVRGIGhhdmUgYmVlbiBoYXJkIGF0IHdvcmsgYW5kIGJlZW4gd29ya2luZyBpdCdzIHdh eSB1cCB0aGUgc3RhY2sgYW5kIGFyZSBub3csIHdpdGggYWNlLCB1cCBpbiB0aGUgYXBwbGljYXRp b24gbGF5ZXIuIFRoYXTigJlzIHdoZXJlIGEgd2hvbGUgb3RoZXIga2luZCBvZiBpbXBsZW1lbnRv cnMgYW5kIGRldmVsb3BlcnMgY29tZXMgaW4uIFRoYXTigJlzIGRldmVsb3BlcnMgd2hvIGRvbuKA mXQgY2FyZSBhYm91dCBSUEwsIElQIG9yIDZMb1dQQU4gKGEgbG90IG9mIHRoZW0gZG8gYW5kIHRo YXTigJlzIHN1cGVyIGdvb2QpIHRoZXkganVzdCB3YW50IHRvIHNvbHZlIGEgYnVzaW5lc3MgcHJv YmxlbSBhbmQgcmV1c2Ugd2hhdCB0aGV5IGhhdmUuIEJvdGgga25vd2xlZGdlLXdpc2UgYW5kIGNv ZGUtd2lzZS4gVGhhdCBleGFjdGx5IHdoYXQgd2Ugc2hvdWxkIGdpdmUgdGhlbS4NCg0KLyBFcmlr DQoNCg0KPiBPbiAyOSBPY3QgMjAxNSwgYXQgMjA6MDEsIENhcnN0ZW4gQm9ybWFubiA8Y2Fib0B0 emkub3JnPiB3cm90ZToNCj4gDQo+IE11Y2ggb2YgdGhlIElFVEYgd29yayBpbiB0aGUgY29uc3Ry YWluZWQgc3BhY2UgaGFzIGJlZW4gYWJvdXQgdGFraW5nIGENCj4gZnJlc2ggbG9vayBpbnN0ZWFk IG9mIHN1Y2N1bWJpbmcgdG8gImJlY2F1c2UgaXRzIHRoZXJlIiAoQklUKSBhcmd1bWVudHMuDQo+ IA0KPiA2TG9XUEFOIGRpZCBub3QgdGFrZSBST0hDLCBidXQgaW52ZW50ZWQgYSBuZXcgaGVhZGVy IGNvbXByZXNzaW9uDQo+ICh0d2ljZSwgdGhyb3dpbmcgb3V0IHRoZSBmaXJzdCBvbmUgYWZ0ZXIg Zm91ciB5ZWFycykuICBJdCBkYXJlZCB0bw0KPiBtYWtlIG11bHRpLWxpbmsgc3VibmV0cyBpdHMg c3RhbmRhcmQgYXBwcm9hY2guICBJdCBkaWQgbm90IGp1c3QgdGFrZQ0KPiBORCwgYnV0IG1vZGlm aWVkIGl0IGludG8gNkxvV1BBTi1ORC4NCj4gDQo+IFJPTEwgZGlkIG5vdCB0YWtlIE9TUEYgb3Ig SVMtSVMsIGJ1dCBzdGFuZGFyZGl6ZWQgUlBMIChhbmQgY2FuIGxldCBhDQo+IHRob3VzYW5kIGZs b3dlcnMgYmxvb20gdGhlcmUsIGFzIGUuZy4gVGhyZWFkIGlzIHVzaW5nIFJJUCkuDQo+IA0KPiBX ZSBkaWRuJ3QgdGFrZSBIVFRQIGluIENvUkUsIGJ1dCBkZXNpZ25lZCBDb0FQLCB1c2luZyBtYW55 IG9mIHRoZSBzYW1lDQo+IHByaW5jaXBsZXMuDQo+IA0KPiBCdXQgb2YgY291cnNlIG1hbnkgb3Ro ZXIgdGhpbmdzIHdlcmUgdGFrZW4gYXMgaXMsIGJlY2F1c2U6DQo+IA0KPiAtLSB0aGV5IGRvIHNv bHZlIHRoZSBhY3R1YWwgcHJvYmxlbQ0KPiAtLSB0aGV5IGRvbid0IGJyaW5nIHByb2hpYml0aXZl IGJhZ2dhZ2UvZHJhd2JhY2tzDQo+IGFuZC9vcg0KPiAtLSB0aGVyZSBhcmUgc3Vic3RhbnRpYWwg bmV0d29yayBlZmZlY3RzIGZyb20gQklULg0KPiANCj4gWW91IGNhbiByZWFkIG1vcmUgYWJvdXQg dGhpcyBhcHByb2FjaCBpbg0KPiBodHRwczovL3d3dy5pYWIub3JnL3dwLWNvbnRlbnQvSUFCLXVw bG9hZHMvMjAxMS8wNC9Cb3JtYW5uLnBkZg0KPiANCj4gQSBuaWNlIGlsbHVzdHJhdGlvbiBvZiB3 aGVyZSB3ZSB3ZXJlIGlmIHdlIHdlcmVuJ3QgZG9pbmcgdGhhdCBpcw0KPiBpbiBodHRwOi8vai5t cC9nc0Q0cjcNCj4gDQo+IEVhY2ggdGltZSB0aGUgY29uc3RyYWluZWQgd29yayBlbnRlcmVkIGEg bmV3IGRvbWFpbiAoSU5ULCBSVEcsIEFQUCksDQo+IHRoZXJlIGFyZSB0aGVzZSBoZWF0ZWQgYXJn dW1lbnRzIGFib3V0IG5vdCBhbHdheXMgdXNpbmcgdGhlIGV4aXN0aW5nDQo+IGhhbW1lcnMuICBJ biBTZWN1cml0eSwgQklUIGFyZ3VtZW50cyBhcmUgb2Z0ZW4gcXVpdGUgY29tcGVsbGluZywgc28N Cj4gdGhlIHRocmVzaG9sZCBpcyBwcm9iYWJseSBoaWdoZXIgKEknbSBzdXJlIFJURyBwZW9wbGUg d2lsbCBkaXNhZ3JlZSkuDQo+IA0KPiBPaCwgYW5kIGluIHRoZSBkZXZlbG9wbWVudCBvZiBib3Ro IDZMb1dQQU4tTkQgYW5kIENvQVAsIHdlIGhhdmUgdGhyb3duDQo+IG91dCB0aGluZ3MgdGhhdCBo YWQgYmVlbiBpbiB0aGUgV0cgZG9jdW1lbnQgKG9yIGV2ZW4gc3RhbmRhcmRpemVkISkNCj4gZm9y IG92ZXIgYSB5ZWFyIG9yIGxvbmdlciB3aGVuIGJldHRlciBhbHRlcm5hdGl2ZXMgY2FtZSBhbG9u Zy4gIFRoaXMNCj4gc29tZXRpbWVzIGhhcyBiZWVuIHBhaW5mdWwsIHdoZW4gdGhlIG9sZCB3YXkg b2YgZG9pbmcgdGhpbmdzIGFscmVhZHkNCj4gaGFkIGJlZW4gd2VsbC1hY2NlcHRlZCBhbmQgaW1w bGVtZW50ZWQgaW50ZXJvcGVyYWJseS4gIEkgaG9wZSB3ZSBjYW4NCj4gZG8gdGhhdCBoZXJlLCBh cyB3ZWxsLg0KPiANCj4gR3LDvMOfZSwgQ2Fyc3Rlbg0KPiANCj4gX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gQWNlIG1haWxpbmcgbGlzdA0KPiBBY2VA aWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9hY2UNCg0K From nobody Thu Oct 29 14:51:40 2015 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25EF11B31FC for ; Thu, 29 Oct 2015 14:51:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.309 X-Spam-Level: X-Spam-Status: No, score=-2.309 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U1eAZNwJu72b for ; Thu, 29 Oct 2015 14:51:35 -0700 (PDT) Received: from smtp.nexusgroup.com (smtp.nexusgroup.com [83.241.133.120]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3FA2D1B31FE for ; Thu, 29 Oct 2015 14:51:34 -0700 (PDT) Received: from NG-EX01.ad.nexusgroup.com (10.75.28.40) by NG-EX01.ad.nexusgroup.com (10.75.28.40) with Microsoft SMTP Server (TLS) id 15.0.995.29; Thu, 29 Oct 2015 22:51:32 +0100 Received: from NG-EX01.ad.nexusgroup.com ([fe80::1d3d:b319:f020:2bab]) by NG-EX01.ad.nexusgroup.com ([fe80::1d3d:b319:f020:2bab%12]) with mapi id 15.00.0995.032; Thu, 29 Oct 2015 22:51:32 +0100 From: =?Windows-1252?Q?Erik_Wahlstr=F6m_neXus?= To: Ludwig Seitz Thread-Topic: [Ace] comments on draft-seitz-ace-oauth-authz-00 Thread-Index: AQHREeZtLoYHI1sV0UKYlZCdCQHqy56CKDiAgADLKIA= Date: Thu, 29 Oct 2015 21:51:32 +0000 Message-ID: <1F59D107-A0B7-410D-A246-D1C98884A9E3@nexusgroup.com> References: <5631EA77.2060405@sics.se> In-Reply-To: <5631EA77.2060405@sics.se> Accept-Language: en-US, sv-SE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.2104) x-originating-ip: [94.234.170.26] Content-Type: multipart/alternative; boundary="_000_1F59D107A0B7410DA246D1C98884A9E3nexusgroupcom_" MIME-Version: 1.0 Archived-At: Cc: "ace@ietf.org" Subject: Re: [Ace] comments on draft-seitz-ace-oauth-authz-00 X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 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, 29 Oct 2015 21:51:39 -0000 --_000_1F59D107A0B7410DA246D1C98884A9E3nexusgroupcom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable The good thing about building with existing protocols is that problems like= this have already been thought of, implemented and solved :) - RFC7591 is the "OAuth 2.0 Dynamic Client Registration Protocol=94 that de= scribes how to bind new clients to any AS. That could be profiled for CoAP = and CBOR in the same way as the OAuth2 for IoT drafts does. - There is also the "OAuth 2.0 Resource Set Registration=94 work (https://t= ools.ietf.org/html/draft-hardjono-oauth-resource-reg-06) in the oauth wg th= at gives the RS a way to bind it self to an AS dynamically and telling it e= xactly what it should protect. That too could be profiled if needed. - UMA, builds on top of OAuth2, also introduced the claims gathering flows = that lets an user/device authenticate it self using any type of claims/attr= ibutes/methods and it lets the system discover the proper way dynamically. There are some good pieces out there to get authentication and authorizatio= n flows working in a dynamic and disperse connected world already. / Erik On 29 Oct 2015, at 10:44, Ludwig Seitz > wrote: Hello Madjid, Thank you for providing your comments on our draft! Answers are inline. /Ludwig On 2015-10-29 02:09, Madjid Nakhjiri wrote: [...] 1. provisioning of client keys for authentication and registration with the AS. Having a global key/ID in the client has been an issue for some OAUTH implementations in the past. Given that the clients are IoT devices, this is not as straight forward as mobile app clients. If I understand you correctly the problem is about having global IDs that c= lients and AS can use to reference keys. I expect that in many cases the clients will only be served by a single AS = (or a few ones at most), which means that the key management problem on tha= t side is less difficult. Since the AS will probably manage keys for many clients, the IDs need to be= unique at least per AS. Therefore defining a namespace that is unique for = a specific AS and prefixing the key ID with that namespace should work towa= rds solving that problem. You seem to have experience with specific issues in that matter, could you = describe those issues in more detail? NOTE: ACE is explicitly not chartered to work with key management and the w= ord has been shunned from any document, therefore I do not expect that ACE = will work on that issue. 2. Same thing for RS to AS registration. RS is many times a constrained device itself. Also I am not clear how the AS will get the authorization policies (scope/claim?) from RS. Is it that it is the AS that decides?? Actually it was never planned that the itself RS should provide and manage = the authorization policies at the AS. The resource owners are expected to d= o this at the AS directly, when they enroll a RS they own. 3. Is authorization subject based (identity of client) or role based? The solution should work with both approaches. The client is expected to pr= esent credentials to the AS when requesting a token. These credentials can = then be resolved to an identity, or a role, or some security attributes of = the client. The AS is then expected to make an authorization decision based= on the credentials and the existing authorization policies. 4. Restrospection of the tokens can be expensive and unscalable for the AS (if there are many RS nodes), but verification of self-contained tokens by the RS also sounds expensive, plus the verification keys need to be provisioned in the RS. Would be nice to have guidance on which makes sense taking device capabilities/class into account. Any network simulators out there? I'm guessing you meant Introspection here right? The AS is not expected to be a constrained device, thus it should be able t= o serve a significant number of introspection requests from different RS. I= ntrospection works best if the RS has a good connectivity to the AS while t= he client has intermittent connectivity or simply connectivity for the clie= nt is expensive (e.g. costs a lot of battery). Of course the number of AS has to be scaled up with the number of RS, but I= don't think that is any different for non-constrained scenarios. Verifying a self-contained token certainly can be expensive, but the altern= ative is to be connected to the network in order to get a real-time access = control decision from an AS. We assume roughly the following "hierarchy" of costs (from most expensive t= o least): 1. Network traffic (sending/receiving/listening for incoming messages) 2. Crypto operations 3. Matching requests against permissions granted by access tokens Several experiments I conducted have shown that 3. is almost negligible whe= n compared to the cost of 2. and 1. When you add the overhead of running a= security protocol when doing network communication, this makes both 2. & 3= . very cheap compared with 1. 5. Wonder if the two app layer security solutions (OSCOAP/ OSCON) cover the provisioning of the keys they are using? OSCOAP and OSCON are based on COSE, which in turn is based on JOSE (JWE/JWS= ). JOSE and COSE have some key provisioning functionality 6. If COAP option max length is 256 bits, how can a signature mechanism that requires that many bits be used? Carsten has already answered that and I agree with his assessment. -- 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 http://www.sics.se _______________________________________________ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace --_000_1F59D107A0B7410DA246D1C98884A9E3nexusgroupcom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable The good thing about building with existing protocols is that problems like= this have already been thought of, implemented and solved :)

- RFC7591 is the "OAuth 2.0 Dynamic Client Registratio= n Protocol=94 that describes how to bind new clients to any AS. That could = be profiled for CoAP and CBOR in the same way as the OAuth2 for IoT drafts = does.
- There is also the "OAuth 2.0 Resource Set Registrati= on=94 work (https://tools.ietf.org/html/draft-hardjono-oauth-r= esource-reg-06) in the oauth wg that gives the RS a way to bind it self to an AS dynamically and telling it exactly w= hat it should protect. That too could be profiled if needed.
- UMA, builds on top of OAuth2, also introduced the claims = gathering flows that lets an user/device authenticate it self using any typ= e of claims/attributes/methods and it lets the system discover the proper w= ay dynamically.

There are some good pieces out there to get authentication = and authorization flows working in a dynamic and disperse connected wo= rld already.

/ Erik


On 29 Oct 2015, at 10:44, Ludwig Seitz <ludwig@sics.se> wrote:

Hello Madjid,

Thank you for providing your comments on our draft! Answers are inline.

/Ludwig

On 2015-10-29 02:09, Madjid Nakhjiri wrote:
[...]
1. provisioning of client keys for aut= hentication and registration with
   the AS. Having a global key/ID in the client has been an = issue for
   some OAUTH implementations in the past. Given that the cl= ients are
   IoT devices, this is not as straight forward as mobile ap= p clients.

If I understand you correctly the problem is about having global IDs that c= lients and AS can use to reference keys.

I expect that in many cases the clients will only be served by a single AS = (or a few ones at most), which means that the key management problem on tha= t side is less difficult.

Since the AS will probably manage keys for many clients, the IDs need to be= unique at least per AS. Therefore defining a namespace that is unique for = a specific AS and prefixing the key ID with that namespace should work towa= rds solving that problem.

You seem to have experience with specific issues in that matter, could you = describe those issues in more detail?

NOTE: ACE is explicitly not chartered to work with key management and the w= ord has been shunned from any document, therefore I do not expect that ACE = will work on that issue.


2. Same thing for RS to AS registratio= n. RS is many times a constrained
   device itself. Also I am not clear how the AS will get th= e
   authorization policies (scope/claim?) from RS. Is it that= it is the
   AS that decides??


Actually it was never planned that the itself RS should provide and manage = the authorization policies at the AS. The resource owners are expected to d= o this at the AS directly, when they enroll a RS they own.

3. Is authorization subject based (ide= ntity of client) or role based?

The solution should work with both approaches. The client is expected to pr= esent credentials to the AS when requesting a token. These credentials can = then be resolved to an identity, or a role, or some security attributes of = the client. The AS is then expected to make an authorization decision based on the credentials and the existin= g authorization policies.


4. Restrospection of the tokens can be= expensive and unscalable for the
   AS (if there are many RS nodes), but verification of self= -contained
   tokens by the RS also sounds expensive, plus the verifica= tion keys
   need to be provisioned in the RS. Would be nice to have g= uidance on
   which makes sense taking device capabilities/class into a= ccount. Any
   network simulators out there?

I'm guessing you meant Introspection here right?

The AS is not expected to be a constrained device, thus it should be able t= o serve a significant number of introspection requests from different RS. I= ntrospection works best if the RS has a good connectivity to the AS while t= he client has intermittent connectivity or simply connectivity for the client is expensive (e.g. costs a lot of ba= ttery).
Of course the number of AS has to be scaled up with the number of RS, but I= don't think that is any different for non-constrained scenarios.

Verifying a self-contained token certainly can be expensive, but the altern= ative is to be connected to the network in order to get a real-time access = control decision from an AS.

We assume roughly the following "hierarchy" of costs (from most e= xpensive to least):

1. Network traffic (sending/receiving/listening for incoming messages)
2. Crypto operations
3. Matching requests against permissions granted by access tokens

Several experiments I conducted have shown that 3. is almost negligible whe= n compared to the cost of 2. and 1.  When you add the overhead of runn= ing a security protocol when doing network communication, this makes both 2= . & 3. very cheap compared with 1.

5. Wonder if the two app layer securit= y solutions (OSCOAP/ OSCON) cover
   the provisioning of the keys they are using?

OSCOAP and OSCON are based on COSE, which in turn is based on JOSE (JWE/JWS= ).  JOSE and COSE have some key provisioning functionality


6. If COAP option max length is 256 bi= ts, how can a signature mechanism
   that requires that many bits be used?


Carsten has already answered that and I agree with his assessment.



--
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
http://www.sics.se

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

--_000_1F59D107A0B7410DA246D1C98884A9E3nexusgroupcom_-- From nobody Thu Oct 29 16:44:54 2015 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6ADB51ACE24 for ; Thu, 29 Oct 2015 16:44:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.25 X-Spam-Level: X-Spam-Status: No, score=-1.25 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2VBQrzmpu1P7 for ; Thu, 29 Oct 2015 16:44:52 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AD8641ACE22 for ; Thu, 29 Oct 2015 16:44:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [134.102.201.11]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id t9TNik6H022291; Fri, 30 Oct 2015 00:44:46 +0100 (CET) Received: from dhcp-private-21-117.tpac.keio.w3.org (unknown [IPv6:2400:4040:0:23:74ef:5ab1:a69:b582]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3nn3K834vGz2F9k; Fri, 30 Oct 2015 00:44:44 +0100 (CET) Message-ID: <5632AF66.3060501@tzi.org> Date: Fri, 30 Oct 2015 08:44:38 +0900 From: Carsten Bormann User-Agent: Postbox 4.0.7 (Macintosh/20151021) MIME-Version: 1.0 To: =?UTF-8?B?RXJpayBXYWhsc3Ryw7ZtIG5lWHVz?= References: <56326D0D.9020309@tzi.org> In-Reply-To: X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: Hannes Tschofenig , Olaf Bergmann , "Ace@ietf.org" , =?UTF-8?B?R8O2cmFuIFNl?= =?UTF-8?B?bGFuZGVy?= Subject: Re: [Ace] Innovating X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 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, 29 Oct 2015 23:44:53 -0000 > I have no interest in throwing away things that’s well accepted and works just because we can. I'm not sure I'm responding to the right thread, because nobody has made the inverse argument. But anyway, let's try out that argument. I have that spool of barbed wire and need to make an Ethernet cable. I have no interest in throwing away things that’s well accepted and works just because we can. Hmm, that didn't work too well. In particular if I add "Its security properties have served me well in the past, so I'll make a secure Ethernet cable out of it." Let's not discuss this in generalities. That doesn't work in engineering. Let me try again. I have that security protocol called DTLS and need to secure my communication. Its security properties have served me well in the past. I have no interest in throwing away things that’s well accepted and works just because we can. Works much better when discussed in specifics, no? In the development of CoAP, we selected DTLS as our comsec protocol. This hasn't been a marriage of love (DTLS 1.2 is not a perfect fit to the constrained space), but it works. As I said, in the constrained space I'm very well in favor of considering throwing away what we have if something clearly better comes along. With object security, we aren't there yet, and I'm not sure we'll ever be there. But we have to try. While this is going on, we may always opt to keep multiple tools in our toolkit. For CoAP, we selected a set of three DTLS security models; X.509 for those who already have it, RPK as an innovation (which became MTI), and PSK as a baseline. It turns out that PSK works quite well, beyond what we originally thought, if we just add a little ACE to it. Grüße, Carsten From nobody Thu Oct 29 17:14:34 2015 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 184821AD09A for ; Thu, 29 Oct 2015 17:14:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.08 X-Spam-Level: X-Spam-Status: No, score=-3.08 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_NEUTRAL=0.779, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3UuDfUoj0BIc for ; Thu, 29 Oct 2015 17:14:29 -0700 (PDT) Received: from rominette.imag.fr (mx2.imag.fr [129.88.30.17]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 414141AD084 for ; Thu, 29 Oct 2015 17:14:28 -0700 (PDT) Received: from globule.imag.fr (globule.imag.fr [129.88.34.238]) by rominette.imag.fr (8.13.8/8.13.8) with ESMTP id t9U0EHlL011299 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Fri, 30 Oct 2015 01:14:17 +0100 Received: from [192.168.1.21] (8.55.31.93.rev.sfr.net [93.31.55.8]) (authenticated bits=0) by globule.imag.fr (8.13.8/8.13.8) with ESMTP id t9U0EJT2025417 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Fri, 30 Oct 2015 01:14:20 +0100 Content-Type: multipart/alternative; boundary="Apple-Mail=_88411C33-40DB-40BF-91CC-6903E6C0342E" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Malisa Vucinic In-Reply-To: <5632AF66.3060501@tzi.org> Date: Fri, 30 Oct 2015 01:14:19 +0100 Message-Id: <0D122069-7B66-4C7E-9784-590E768AA9D3@imag.fr> References: <56326D0D.9020309@tzi.org> <5632AF66.3060501@tzi.org> To: Carsten Bormann X-Mailer: Apple Mail (2.2104) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.2 (rominette.imag.fr [129.88.30.17]); Fri, 30 Oct 2015 01:14:17 +0100 (CET) X-IMAG-MailScanner-Information: Please contact MI2S MIM for more information X-MailScanner-ID: t9U0EHlL011299 X-IMAG-MailScanner: Found to be clean X-IMAG-MailScanner-SpamCheck: X-IMAG-MailScanner-From: malisa.vucinic@imag.fr MailScanner-NULL-Check: 1446768860.62134@gHd4jWwM76mNCRKZ8uOLQA Archived-At: Cc: Hannes Tschofenig , =?utf-8?Q?Erik_Wahlstr=C3=B6m_neXus?= , =?utf-8?Q?G=C3=B6ran_Selander?= , Olaf Bergmann , "Ace@ietf.org" Subject: Re: [Ace] Innovating X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 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, 30 Oct 2015 00:14:33 -0000 --Apple-Mail=_88411C33-40DB-40BF-91CC-6903E6C0342E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Just to make sure I follow the thread, the definition of innovation = brought up here is that in 2015 we should constrain ourselves to PSKs?=20= > On 30 Oct 2015, at 00:44, Carsten Bormann wrote: >=20 > It turns out that PSK works quite well, > beyond what we originally thought, if we just add a little ACE to it. --Apple-Mail=_88411C33-40DB-40BF-91CC-6903E6C0342E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
Just to make sure I follow the thread, the = definition of innovation brought up here is that in 2015 we should = constrain ourselves to PSKs? 

On 30 Oct 2015, at 00:44, Carsten Bormann <cabo@tzi.org> = wrote:

It turns out that PSK works quite = well,
beyond what we originally = thought, if we just add a little ACE to it.

= --Apple-Mail=_88411C33-40DB-40BF-91CC-6903E6C0342E-- From nobody Thu Oct 29 23:59:29 2015 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4552B1B37C5 for ; Thu, 29 Oct 2015 23:59:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.901 X-Spam-Level: X-Spam-Status: No, score=-3.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DCRK1sSn5kuf for ; Thu, 29 Oct 2015 23:59:26 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F2091A6F5A for ; Thu, 29 Oct 2015 23:59:25 -0700 (PDT) X-AuditID: c1b4fb2d-f79626d000004282-65-5633154c7155 Received: from ESESSHC018.ericsson.se (Unknown_Domain [153.88.183.72]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id FE.82.17026.C4513365; Fri, 30 Oct 2015 07:59:24 +0100 (CET) Received: from ESESSMB303.ericsson.se ([169.254.3.10]) by ESESSHC018.ericsson.se ([153.88.183.72]) with mapi id 14.03.0248.002; Fri, 30 Oct 2015 07:59:15 +0100 From: =?utf-8?B?R8O2cmFuIFNlbGFuZGVy?= To: Carsten Bormann , "Ace@ietf.org" Thread-Topic: [ACE] Innovating Thread-Index: AQHREuB8FHefGkL37U2yBmEgEPAD4w== Date: Fri, 30 Oct 2015 06:59:14 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.7.141117 x-originating-ip: [153.88.183.154] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrIIsWRmVeSWpSXmKPExsUyM2K7h66PqHGYwctvQhbfv/UwWzQtbmSy ODLlLqvF0p33WB1YPBZv2s/msWTJTyaPaYsyA5ijuGxSUnMyy1KL9O0SuDIWnrnJVjBNoWLb 3B2sDYxr5LsYOTkkBEwkWu6fYYGwxSQu3FvP1sXIxSEkcJhRovdjLyuEs5hR4vD7BUwgVWwC LhIPGh6B2SICjhInJ68Fs5kFQiWmNhxnBLGFBSQlTixYyQxRIydxYl4jO4StJ3Hm8gawOIuA qsT3XRBzeAUsJBZ3/QSLMwJd8f3UGqiZ4hK3nsxngrhOQGLJnvPMELaoxMvH/1hBbFGgmSuv N7FBxJUkFt3+DFTPAdSrKbF+lz7EGGuJRwueM0LYihJTuh+yQ6wVlDg58wnLBEaxWUi2zULo noWkexaS7llIuhcwsq5iFC1OLS7OTTcy1kstykwuLs7P08tLLdnECIy4g1t+6+5gXP3a8RCj AAejEg/vhhyjMCHWxLLiytxDjBIczEoivL8vAYV4UxIrq1KL8uOLSnNSiw8xSnOwKInztjA9 CBUSSE8sSc1OTS1ILYLJMnFwSjUwut9mmC48ifGx7v9CBs44wV/Geg/3tAsqBPTJP93zWqJj mucKdfb836c6rt98NLuMYeUbz96XKVbb91xYU3i3Kbzb7XFDaN1K3xPuDMlHL0yWFP8n4Rew KD9ZTsGwMe3nzEUTxafO3ub5f9KuBx5pionrb3axrp/+/F7VaZ3irWdtK/RWzGqoU2Ipzkg0 1GIuKk4EAHvpf220AgAA Archived-At: Cc: Hannes Tschofenig , Olaf Bergmann Subject: [Ace] [ACE] Innovating X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 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, 30 Oct 2015 06:59:28 -0000 DQoNCk9uIDIwMTUtMTAtMjkgMjA6MDEsICJDYXJzdGVuIEJvcm1hbm4iIDxjYWJvQHR6aS5vcmc+ IHdyb3RlOg0KDQo+TXVjaCBvZiB0aGUgSUVURiB3b3JrIGluIHRoZSBjb25zdHJhaW5lZCBzcGFj ZSBoYXMgYmVlbiBhYm91dCB0YWtpbmcgYQ0KPmZyZXNoIGxvb2sgaW5zdGVhZCBvZiBzdWNjdW1i aW5nIHRvICJiZWNhdXNlIGl0cyB0aGVyZSIgKEJJVCkgYXJndW1lbnRzLg0KPg0KPjZMb1dQQU4g ZGlkIG5vdCB0YWtlIFJPSEMsIGJ1dCBpbnZlbnRlZCBhIG5ldyBoZWFkZXIgY29tcHJlc3Npb24N Cj4odHdpY2UsIHRocm93aW5nIG91dCB0aGUgZmlyc3Qgb25lIGFmdGVyIGZvdXIgeWVhcnMpLiAg SXQgZGFyZWQgdG8NCj5tYWtlIG11bHRpLWxpbmsgc3VibmV0cyBpdHMgc3RhbmRhcmQgYXBwcm9h Y2guICBJdCBkaWQgbm90IGp1c3QgdGFrZQ0KPk5ELCBidXQgbW9kaWZpZWQgaXQgaW50byA2TG9X UEFOLU5ELg0KPg0KPlJPTEwgZGlkIG5vdCB0YWtlIE9TUEYgb3IgSVMtSVMsIGJ1dCBzdGFuZGFy ZGl6ZWQgUlBMIChhbmQgY2FuIGxldCBhDQo+dGhvdXNhbmQgZmxvd2VycyBibG9vbSB0aGVyZSwg YXMgZS5nLiBUaHJlYWQgaXMgdXNpbmcgUklQKS4NCj4NCj5XZSBkaWRuJ3QgdGFrZSBIVFRQIGlu IENvUkUsIGJ1dCBkZXNpZ25lZCBDb0FQLCB1c2luZyBtYW55IG9mIHRoZSBzYW1lDQo+cHJpbmNp cGxlcy4NCj4NCj5CdXQgb2YgY291cnNlIG1hbnkgb3RoZXIgdGhpbmdzIHdlcmUgdGFrZW4gYXMg aXMsIGJlY2F1c2U6DQo+DQo+LS0gdGhleSBkbyBzb2x2ZSB0aGUgYWN0dWFsIHByb2JsZW0NCj4t LSB0aGV5IGRvbid0IGJyaW5nIHByb2hpYml0aXZlIGJhZ2dhZ2UvZHJhd2JhY2tzDQo+YW5kL29y DQo+LS0gdGhlcmUgYXJlIHN1YnN0YW50aWFsIG5ldHdvcmsgZWZmZWN0cyBmcm9tIEJJVC4NCj4N Cj5Zb3UgY2FuIHJlYWQgbW9yZSBhYm91dCB0aGlzIGFwcHJvYWNoIGluDQo+aHR0cHM6Ly93d3cu aWFiLm9yZy93cC1jb250ZW50L0lBQi11cGxvYWRzLzIwMTEvMDQvQm9ybWFubi5wZGYNCj4NCj5B IG5pY2UgaWxsdXN0cmF0aW9uIG9mIHdoZXJlIHdlIHdlcmUgaWYgd2Ugd2VyZW4ndCBkb2luZyB0 aGF0IGlzDQo+aW4gaHR0cDovL2oubXAvZ3NENHI3DQo+DQo+RWFjaCB0aW1lIHRoZSBjb25zdHJh aW5lZCB3b3JrIGVudGVyZWQgYSBuZXcgZG9tYWluIChJTlQsIFJURywgQVBQKSwNCj50aGVyZSBh cmUgdGhlc2UgaGVhdGVkIGFyZ3VtZW50cyBhYm91dCBub3QgYWx3YXlzIHVzaW5nIHRoZSBleGlz dGluZw0KPmhhbW1lcnMuICBJbiBTZWN1cml0eSwgQklUIGFyZ3VtZW50cyBhcmUgb2Z0ZW4gcXVp dGUgY29tcGVsbGluZywgc28NCj50aGUgdGhyZXNob2xkIGlzIHByb2JhYmx5IGhpZ2hlciAoSSdt IHN1cmUgUlRHIHBlb3BsZSB3aWxsIGRpc2FncmVlKS4NCg0KWWVzLCBhbmQgaW4gQUNFIHdlIGFy ZSBsb29raW5nIGF0IGF1dGhlbnRpY2F0aW9uIGFuZCBhdXRob3JpemF0aW9uLCB3aGF0DQphcmUg dGhlIHN1Y2Nlc3Mgc3RvcmllcyBpbiBzZWN1cml0eT8NCg0KSGF2aW5nIGV2YWx1YXRlZCBxdWl0 ZSBhIGZldyBzZWN1cml0eSByZWxhdGVkIGNhbmRpZGF0ZSBwYXRlbnQNCmFwcGxpY2F0aW9ucyBt eSBleHBlcmllbmNlIGlzIHRoYXQgbWFueSBpbm5vdmF0aW9ucyBieSBsYXltZW4gZmFpbCB0byBi ZQ0Kc2VjdXJlLiBUaGVyZSBhcmUgcGxlbnR5IG9mIGV4YW1wbGVzIG9mICJpbm5vdmF0aXZlIiBz ZWN1cml0eSBiZWhpbmQgdGhlDQpoZWFkbGluZXMgb2YgaGFja2VkIHN5c3RlbXMuIEnigJltIG5v dCBzYXlpbmcgaXQgaXMgaW1wb3NzaWJsZSB0byBpbm5vdmF0ZQ0KaW4gdGhlIHNlY3VyaXR5IGFy ZWEsIGJ1dCBpdCBpcyBwZXJoYXBzIG5vdCBhcyBlYXN5IGFzIHlvdSBtYXkgdGhpbmsuDQoNCkNv QVAgaW4gaXRzZWxmIGlzIGFjdHVhbGx5IG5vdCB2ZXJ5IGNvbnZpbmNpbmcgaW4gaXRzIHNlY3Vy aXR5IGRlc2lnbi4NCkNvQVAgb24gb25lIGhhbmQgc2lkZSBvdXRzb3VyY2VkIHNlY3VyaXR5IHRv IERUTFMsIGFuZCBvbiB0aGUgb3RoZXIgaGFuZA0KZGVmaW5lcyBhZHZhbmNlZCBwcm94eSBvcGVy YXRpb25zIHRoYXQgcmVxdWlyZXMgRFRMUyB0byBiZSB0ZXJtaW5hdGVkIGF0DQp0aGUgcHJveHkg YW5kIGhlbmNlIHRoYXQgdGhlIHByb3h5IGlzIGNvbXBsZXRlbHkgdHJ1c3RlZCAobm90IG9ubHkg d2l0aA0KdGhlIHByb3h5IG9wZXJhdGlvbikgdW5sZXNzIHlvdSB1c2Ugb2JqZWN0IHNlY3VyaXR5 LiBBcyBhbm90aGVyIGV4YW1wbGUsDQp1c2luZyBDT0FQIGZvciB3aXJlbGVzcyBhY3R1YXRvcnMs IGEgdXNlIGNhc2Ugd2hpY2ggbXVzdCBiZSBjb25zaWRlcmVkDQpjZW50cmFsLCBoYXMgc2VyaW91 cyBzZWN1cml0eSBpc3N1ZXMgZXZlbiB3aXRoIERUTFMgYW5kIHdpdGhvdXQgcHJveGllcy4NCihU aGUgdHdvIHN1YmplY3RzIG9mIHRoaXMgcGFyYWdyYXBoIGFyZSB0b3BpY3MgZm9yIHRoZSBDT1JF IFdHIG9uIEZyaWRheS4pDQoNClRoZSBzZWN1cml0eSBpc3N1ZXMgd2l0aCBEQ0FGIHdoZW4gcmVp bnZlbnRpbmcgb2JqZWN0IHNlY3VyaXR5IGZvciBDb0FQIGlzDQpub3QgdmVyeSByZWFzc3VyaW5n IGluIHRoaXMgcmVzcGVjdC4NCg0KR8O2cmFuDQoNCg0KDQo+DQo+T2gsIGFuZCBpbiB0aGUgZGV2 ZWxvcG1lbnQgb2YgYm90aCA2TG9XUEFOLU5EIGFuZCBDb0FQLCB3ZSBoYXZlIHRocm93bg0KPm91 dCB0aGluZ3MgdGhhdCBoYWQgYmVlbiBpbiB0aGUgV0cgZG9jdW1lbnQgKG9yIGV2ZW4gc3RhbmRh cmRpemVkISkNCj5mb3Igb3ZlciBhIHllYXIgb3IgbG9uZ2VyIHdoZW4gYmV0dGVyIGFsdGVybmF0 aXZlcyBjYW1lIGFsb25nLiAgVGhpcw0KPnNvbWV0aW1lcyBoYXMgYmVlbiBwYWluZnVsLCB3aGVu IHRoZSBvbGQgd2F5IG9mIGRvaW5nIHRoaW5ncyBhbHJlYWR5DQo+aGFkIGJlZW4gd2VsbC1hY2Nl cHRlZCBhbmQgaW1wbGVtZW50ZWQgaW50ZXJvcGVyYWJseS4gIEkgaG9wZSB3ZSBjYW4NCj5kbyB0 aGF0IGhlcmUsIGFzIHdlbGwuDQo+DQo+R3LDvMOfZSwgQ2Fyc3Rlbg0KDQo= From nobody Fri Oct 30 00:07:51 2015 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5F521B3810 for ; Fri, 30 Oct 2015 00:07:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.901 X-Spam-Level: X-Spam-Status: No, score=-3.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EF9MnIK7Oe9U for ; Fri, 30 Oct 2015 00:07:48 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 06F4B1B3807 for ; Fri, 30 Oct 2015 00:07:47 -0700 (PDT) X-AuditID: c1b4fb30-f79626d000006adf-f7-56331741dbee Received: from ESESSHC006.ericsson.se (Unknown_Domain [153.88.253.125]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id BE.D7.27359.14713365; Fri, 30 Oct 2015 08:07:46 +0100 (CET) Received: from ESESSMB303.ericsson.se ([169.254.3.10]) by ESESSHC006.ericsson.se ([153.88.183.36]) with mapi id 14.03.0248.002; Fri, 30 Oct 2015 08:07:45 +0100 From: =?utf-8?B?R8O2cmFuIFNlbGFuZGVy?= To: Carsten Bormann , =?utf-8?B?RXJpayBXYWhsc3Ryw7ZtIG5lWHVz?= Thread-Topic: [Ace] Innovating Thread-Index: AQHREnxBH+G/NF6jq069q22sAXskIZ6C4aiAgAAwJwCAAIyRAA== Date: Fri, 30 Oct 2015 07:07:45 +0000 Message-ID: References: <56326D0D.9020309@tzi.org> <5632AF66.3060501@tzi.org> In-Reply-To: <5632AF66.3060501@tzi.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.7.141117 x-originating-ip: [153.88.183.150] Content-Type: text/plain; charset="utf-8" Content-ID: <8AAFC486B1AA3A4E88DA65F1484100D5@ericsson.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrHIsWRmVeSWpSXmKPExsUyM+Jvra6TuHGYwdJvrBbfv/UwWzQtbmSy ODLlLqvFsV2L2SyW7rzH6sDqsXjTfjaPJUt+Mnlsvf+b0WPaoswAligum5TUnMyy1CJ9uwSu jNsv/rIWfJOs2Lf4GFMD4wLJLkZODgkBE4kpHe+YIWwxiQv31rN1MXJxCAkcYZS4OHsaI4Sz mFFi/v/vLCBVbAIuEg8aHjF1MXJwiAjkSfya4goSZhYokfh0txlskLCArETjx3/MECVyEhvv 2kCYThILus1AKlgEVCXOzdvMBmLzClhI/F+5AcwWEqiWuHxiAxOIzSmgLnFq8yR2EJsR6LTv p9YwQWwSl7j1ZD4TxMkCEkv2nIc6X1Ti5eN/rCC2qICexMrrTWwQcSWJFdsvMYKcwCygKbF+ lz6EaS1xb6sfxERFiSndD9khrhGUODnzCcsERolZSJbNQmiehdA8C0nzLCTNCxhZVzGKFqcW J+WmGxnppRZlJhcX5+fp5aWWbGIExurBLb8NdjC+fO54iFGAg1GJh3dDjlGYEGtiWXFl7iFG CQ5mJRHe35eAQrwpiZVVqUX58UWlOanFhxilOViUxHmbmR6ECgmkJ5akZqemFqQWwWSZODil GhgFLJcH1V3L6VRZsZhF+Vv1s1c5dYsu5U57azudu997nZD/u85Ti+/KBb6ex7p/C7eqdLbV TZlf81W5/2p+XWrj3+cV3LqMbXL6/pndtcmic59tlTpboB9QeWh70MVynUc2H/n/BIl0Kots X6W2vn3iNs2XFytsV/2xi82ovqRxIGdB0Nfg7PNKLMUZiYZazEXFiQAk1t4f0QIAAA== Archived-At: Cc: Hannes Tschofenig , Olaf Bergmann , "Ace@ietf.org" Subject: Re: [Ace] Innovating X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 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, 30 Oct 2015 07:07:50 -0000 DQoNCk9uIDIwMTUtMTAtMzAgMDA6NDQsICJDYXJzdGVuIEJvcm1hbm4iIDxjYWJvQHR6aS5vcmc+ IHdyb3RlOg0KDQo+PiBJIGhhdmUgbm8gaW50ZXJlc3QgaW4gdGhyb3dpbmcgYXdheSB0aGluZ3Mg dGhhdOKAmXMgd2VsbCBhY2NlcHRlZCBhbmQNCj4+d29ya3MganVzdCBiZWNhdXNlIHdlIGNhbi4N Cj4NCj5JJ20gbm90IHN1cmUgSSdtIHJlc3BvbmRpbmcgdG8gdGhlIHJpZ2h0IHRocmVhZCwgYmVj YXVzZSBub2JvZHkgaGFzIG1hZGUNCj50aGUgaW52ZXJzZSBhcmd1bWVudC4NCj4NCj5CdXQgYW55 d2F5LCBsZXQncyB0cnkgb3V0IHRoYXQgYXJndW1lbnQuDQo+DQo+SSBoYXZlIHRoYXQgc3Bvb2wg b2YgYmFyYmVkIHdpcmUgYW5kIG5lZWQgdG8gbWFrZSBhbiBFdGhlcm5ldCBjYWJsZS4NCj5JIGhh dmUgbm8gaW50ZXJlc3QgaW4gdGhyb3dpbmcgYXdheSB0aGluZ3MgdGhhdOKAmXMgd2VsbCBhY2Nl cHRlZCBhbmQNCj53b3JrcyBqdXN0IGJlY2F1c2Ugd2UgY2FuLg0KPg0KPkhtbSwgdGhhdCBkaWRu J3Qgd29yayB0b28gd2VsbC4gIEluIHBhcnRpY3VsYXIgaWYgSSBhZGQgIkl0cyBzZWN1cml0eQ0K PnByb3BlcnRpZXMgaGF2ZSBzZXJ2ZWQgbWUgd2VsbCBpbiB0aGUgcGFzdCwgc28gSSdsbCBtYWtl IGEgc2VjdXJlDQo+RXRoZXJuZXQgY2FibGUgb3V0IG9mIGl0LiINCj4NCj5MZXQncyBub3QgZGlz Y3VzcyB0aGlzIGluIGdlbmVyYWxpdGllcy4gIFRoYXQgZG9lc24ndCB3b3JrIGluIGVuZ2luZWVy aW5nLg0KPg0KPkxldCBtZSB0cnkgYWdhaW4uDQo+DQo+SSBoYXZlIHRoYXQgc2VjdXJpdHkgcHJv dG9jb2wgY2FsbGVkIERUTFMgYW5kIG5lZWQgdG8gc2VjdXJlIG15DQo+Y29tbXVuaWNhdGlvbi4g IEl0cyBzZWN1cml0eSBwcm9wZXJ0aWVzIGhhdmUgc2VydmVkIG1lIHdlbGwgaW4gdGhlIHBhc3Qu DQo+IEkgaGF2ZSBubyBpbnRlcmVzdCBpbiB0aHJvd2luZyBhd2F5IHRoaW5ncyB0aGF04oCZcyB3 ZWxsIGFjY2VwdGVkIGFuZA0KPndvcmtzIGp1c3QgYmVjYXVzZSB3ZSBjYW4uDQo+DQo+V29ya3Mg bXVjaCBiZXR0ZXIgd2hlbiBkaXNjdXNzZWQgaW4gc3BlY2lmaWNzLCBubz8NCj4NCj5JbiB0aGUg ZGV2ZWxvcG1lbnQgb2YgQ29BUCwgd2Ugc2VsZWN0ZWQgRFRMUyBhcyBvdXIgY29tc2VjIHByb3Rv Y29sLg0KPlRoaXMgaGFzbid0IGJlZW4gYSBtYXJyaWFnZSBvZiBsb3ZlIChEVExTIDEuMiBpcyBu b3QgYSBwZXJmZWN0IGZpdCB0bw0KPnRoZSBjb25zdHJhaW5lZCBzcGFjZSksIGJ1dCBpdCB3b3Jr cy4NCj4NCj5BcyBJIHNhaWQsIGluIHRoZSBjb25zdHJhaW5lZCBzcGFjZSBJJ20gdmVyeSB3ZWxs IGluIGZhdm9yIG9mDQo+Y29uc2lkZXJpbmcgdGhyb3dpbmcgYXdheSB3aGF0IHdlIGhhdmUgaWYg c29tZXRoaW5nIGNsZWFybHkgYmV0dGVyIGNvbWVzDQo+YWxvbmcuICBXaXRoIG9iamVjdCBzZWN1 cml0eSwgd2UgYXJlbid0IHRoZXJlIHlldCwgYW5kIEknbSBub3Qgc3VyZQ0KPndlJ2xsIGV2ZXIg YmUgdGhlcmUuICBCdXQgd2UgaGF2ZSB0byB0cnkuDQoNClllcywgd2UgaGFkIGJldHRlciB0cnkg YmVjYXVzZSBvdGhlcndpc2UgdGhlIHVzZSBvZiBDb0FQIHJlcXVpcmVzIHByb3hpZXMNCnRvIGJl IGZ1bGx5IHRydXN0ZWQuDQoNCg0KRm9yIHRoZSB1bmluaXRpYXRlZCByZWFkZXI6IE5vdGUgdGhh dCB0aGUgZGlzY3Vzc2lvbiBpbiBBQ0UgaXMgKm5vdCogYWJvdXQNCkRUTFMgdnMgb2JqZWN0IHNl Y3VyaXR5LiBCb3RoIEFDRSBzb2x1dGlvbiBjYW5kaWRhdGVzIGluY2x1ZGUgYm90aA0KYWx0ZXJu YXRpdmVzLCBhbHRob3VnaCB0aGUgb2JqZWN0IHNlY3VyaXR5IHZhcmlhbnQgaW4gRENBRiBvYnZp b3VzbHkNCmRvZXNu4oCZdCB3b3JrLiBGdXJ0aGVybW9yZSBEVExTIGFuZCBvYmplY3Qgc2VjdXJp dHkgaGF2ZSBkaWZmZXJlbnQgc2VjdXJpdHkNCm9iamVjdGl2ZXMgYW5kIGNhbiBiZSB1c2VkIHRv Z2V0aGVyLCBzbyBpdCBpcyBub3QgYSBxdWVzdGlvbiBvZiB0aHJvd2luZw0Kb3V0IG9uZSBhbmQg cmVwbGFjZSB3aXRoIHRoZSBvdGhlci4NCg0KR8O2cmFuDQoNCj4NCj5XaGlsZSB0aGlzIGlzIGdv aW5nIG9uLCB3ZSBtYXkgYWx3YXlzIG9wdCB0byBrZWVwIG11bHRpcGxlIHRvb2xzIGluIG91cg0K PnRvb2xraXQuICBGb3IgQ29BUCwgd2Ugc2VsZWN0ZWQgYSBzZXQgb2YgdGhyZWUgRFRMUyBzZWN1 cml0eSBtb2RlbHM7DQo+WC41MDkgZm9yIHRob3NlIHdobyBhbHJlYWR5IGhhdmUgaXQsIFJQSyBh cyBhbiBpbm5vdmF0aW9uICh3aGljaCBiZWNhbWUNCj5NVEkpLCBhbmQgUFNLIGFzIGEgYmFzZWxp bmUuICBJdCB0dXJucyBvdXQgdGhhdCBQU0sgd29ya3MgcXVpdGUgd2VsbCwNCj5iZXlvbmQgd2hh dCB3ZSBvcmlnaW5hbGx5IHRob3VnaHQsIGlmIHdlIGp1c3QgYWRkIGEgbGl0dGxlIEFDRSB0byBp dC4NCj4NCj5HcsO8w59lLCBDYXJzdGVuDQoNCg== From nobody Fri Oct 30 00:41:03 2015 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D77D61B2D42 for ; Fri, 30 Oct 2015 00:41:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZE-xuRQXDsnd for ; Fri, 30 Oct 2015 00:40:59 -0700 (PDT) Received: from mail-qg0-x230.google.com (mail-qg0-x230.google.com [IPv6:2607:f8b0:400d:c04::230]) (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 37F0C1B2AA1 for ; Fri, 30 Oct 2015 00:40:58 -0700 (PDT) Received: by qgeo38 with SMTP id o38so55338507qge.0 for ; Fri, 30 Oct 2015 00:40:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=erdtman_se.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=AKcwvGcWsVKTuXwEklr5ufS9tDIRI9i4zKOkmkmFZ64=; b=abqIwhlQ/HbQ7MTvpj3RBJdLVtz2uL+OWNxFtgnkZH6nhI8wAZUP/A/83M0RvqjrxR GyJVB7d2wO3h4oRLYSZlmi2jpo5JKvyDY8wUPXdClWTwGH598xVWUTBzGMhCLApquebe T8AiOaCMMEESOOmITA6GftYt+0/9H5zhjR9IzAGPGzh3W3SQli9DvebE32MmRDOj40+g AMIR8ec0RWrjt/NP7jRZkoCxEfrGiSAc/wQl63DqlEwo8DGlAV//AyVL4MKRGnj6h6Sh VFekBZrVRamXJECLsMBohS+MyeBkGGgq8gQgpkuEo+N/gYBXsk4Kfv4QlpQsPQlXrpbW XsBA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=AKcwvGcWsVKTuXwEklr5ufS9tDIRI9i4zKOkmkmFZ64=; b=Qr0WQlpyY/L+2+YN57XjuoJdw6ntc9uySKMLLrR8qQDu5GKucWEyJVSHEq2E6rCkM5 lT9QFYHeDWQ57Tnn9eUbYYjuGrwLLtZP7AkkocTIROq2Vdew93ploB+h+ws8Dk7kdyO9 nhHrEUjXcfswBXFOzw1G5v2Y7Xu2HWYX7HUUk5OEG5xizJ/YVBOfCQcZYwgDdf9SXrI5 fRWVAHP/RauOtnxmZxO3ruih3CjYoDhEBQoqorKA0SjUBuJb+OWaSv4Q0CXZqZN11WdE ZbODW4xIACab3F3CWZTur7l/O8K7G5AAa3REG7OmnwbY4Gf5KoTtvir4iMXwzq2m2mYF H2ew== X-Gm-Message-State: ALoCoQlvhMhht21amIt9gY8RebjHDJFzEg2Hc30COlOh/HB99jMFUfbhyJfti2Oyd8ayvCAehbqQ MIME-Version: 1.0 X-Received: by 10.140.106.182 with SMTP id e51mr7934390qgf.41.1446190858161; Fri, 30 Oct 2015 00:40:58 -0700 (PDT) Received: by 10.55.181.69 with HTTP; Fri, 30 Oct 2015 00:40:58 -0700 (PDT) In-Reply-To: <56326D0D.9020309@tzi.org> References: <56326D0D.9020309@tzi.org> Date: Fri, 30 Oct 2015 08:40:58 +0100 Message-ID: From: Samuel Erdtman To: Carsten Bormann Content-Type: multipart/alternative; boundary=001a113957e0611a6205234d8c15 Archived-At: Cc: Hannes Tschofenig , =?UTF-8?Q?G=C3=B6ran_Selander?= , Olaf Bergmann , "Ace@ietf.org" Subject: Re: [Ace] Innovating X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 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, 30 Oct 2015 07:41:02 -0000 --001a113957e0611a6205234d8c15 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Carsten, My interpretation of your email is that some times it is preferable to re-invent and sometimes it is good to reuse. I=C2=B4m behind you 100% on th= is. However if I try to read between the lines in your email it seems like you are slightly more in favour of re-inventing since thats what your examples are about, and the linked document seem to further indicate the benefit of re-inventing and how good that worked out for CoAP. If I have completely misinterpreted you I=C2=B4m sorry about that. So I guess that the question is, should we re-invent or reuse. I think both can be equally innovative so I don=E2=80=99t think the question should be t= o innovate or not, but to re-invent or reuse. And as you mentioned there are cases when it is right to reuse =E2=80=9C -- they do solve the actual problem -- they don't bring prohibitive baggage/drawbacks and/or -- there are substantial network effects from BIT. =E2=80=9C Based on this I think we have a case where OAuth2 (and UMA) actually is very suitable for reuse. It is a protocol that there has gone in a lot of thinking into to keep them relatively slimed and secure, and as can be seen in the draft submitted by me, Erik, Hannes, Ludwig and G=C3=B6ran it can wi= th limited effort be extended to suite the constrained environment. I think this goes well in line with what G=C3=B6ran indicated in a previous email, = when working with security we need to be very careful to not get things wrong and to ride on the time spend on validating the correctness of OAuth2 seems to be a smart thing to do. To put it in a quote =E2=80=9CIf I have seen fur= ther it is by standing on the shoulders of giants=E2=80=9D, Isaac Newton. I know there was no explicit question in your email but I guess that it was meant to advocate DCAF over OAuth2. My vote, not surprisingly, goes to OAuth2 as the most compelling way forward. Best Regards Samuel Erdtman PS. The past week I have tested out the ides presented in our draft and it works out very well :-) DS. On Thu, Oct 29, 2015 at 8:01 PM, Carsten Bormann wrote: > Much of the IETF work in the constrained space has been about taking a > fresh look instead of succumbing to "because its there" (BIT) arguments. > > 6LoWPAN did not take ROHC, but invented a new header compression > (twice, throwing out the first one after four years). It dared to > make multi-link subnets its standard approach. It did not just take > ND, but modified it into 6LoWPAN-ND. > > ROLL did not take OSPF or IS-IS, but standardized RPL (and can let a > thousand flowers bloom there, as e.g. Thread is using RIP). > > We didn't take HTTP in CoRE, but designed CoAP, using many of the same > principles. > > But of course many other things were taken as is, because: > > -- they do solve the actual problem > -- they don't bring prohibitive baggage/drawbacks > and/or > -- there are substantial network effects from BIT. > > You can read more about this approach in > https://www.iab.org/wp-content/IAB-uploads/2011/04/Bormann.pdf > > A nice illustration of where we were if we weren't doing that is > in http://j.mp/gsD4r7 > > Each time the constrained work entered a new domain (INT, RTG, APP), > there are these heated arguments about not always using the existing > hammers. In Security, BIT arguments are often quite compelling, so > the threshold is probably higher (I'm sure RTG people will disagree). > > Oh, and in the development of both 6LoWPAN-ND and CoAP, we have thrown > out things that had been in the WG document (or even standardized!) > for over a year or longer when better alternatives came along. This > sometimes has been painful, when the old way of doing things already > had been well-accepted and implemented interoperably. I hope we can > do that here, as well. > > Gr=C3=BC=C3=9Fe, Carsten > > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace > --001a113957e0611a6205234d8c15 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Carsten,

My interpret= ation of your email is that some times it is preferable to re-invent and so= metimes it is good to reuse. I=C2=B4m behind you 100% on this. However if I= try to read between the lines in your email it seems like you are slightly= more in favour of re-inventing since thats what your examples are about, a= nd the linked document seem to further indicate the benefit of re-inventing= and how good that worked out for CoAP. If I have completely misinterpreted= you I=C2=B4m sorry about that.

So I guess that th= e question is, should we re-invent or reuse. I think both can be equally in= novative so I don=E2=80=99t think the question should be to innovate or not= , but to re-invent or reuse.

And as you mentioned = there are cases when it is right to reuse
=E2=80=9C
-- = they do solve the actual problem
-- they don't bring prohibit= ive baggage/drawbacks and/or
-- there are substantial network eff= ects from BIT.
=E2=80=9C

Based on this I= think we have a case where OAuth2 (and UMA) actually is very suitable for = reuse. It is a protocol that there has gone in a lot of thinking into to ke= ep them relatively slimed and secure, and as can be seen in the draft submi= tted by me, Erik, Hannes, Ludwig and G=C3=B6ran it can with limited effort = be extended to suite the constrained environment. I think this goes well in= line with what G=C3=B6ran indicated in a previous email, when working with= security we need to be very careful to not get things wrong and to ride on= the time spend on validating the correctness of OAuth2 seems to be a smart= thing to do. To put it in a quote =E2=80=9CIf I have seen further it is by= standing on the shoulders of giants=E2=80=9D, Isaac Newton.

=
I know there was no explicit question in your email but I guess = that it was meant to advocate DCAF over OAuth2. My vote, not surprisingly, = goes to OAuth2 as the most compelling way forward.

Best Regards
Samuel Erdtman

PS.
The past week I have tested out the ides presented in our draft and it w= orks out very well :-)
DS.


On Thu, Oct 29, 2015 at 8:0= 1 PM, Carsten Bormann <cabo@tzi.org> wrote:
Much of the IETF work in the constrained space has been about= taking a
fresh look instead of succumbing to "because its there" (BIT) arg= uments.

6LoWPAN did not take ROHC, but invented a new header compression
(twice, throwing out the first one after four years).=C2=A0 It dared to
make multi-link subnets its standard approach.=C2=A0 It did not just take ND, but modified it into 6LoWPAN-ND.

ROLL did not take OSPF or IS-IS, but standardized RPL (and can let a
thousand flowers bloom there, as e.g. Thread is using RIP).

We didn't take HTTP in CoRE, but designed CoAP, using many of the same<= br> principles.

But of course many other things were taken as is, because:

-- they do solve the actual problem
-- they don't bring prohibitive baggage/drawbacks
and/or
-- there are substantial network effects from BIT.

You can read more about this approach in
https://www.iab.org/wp-content/IAB-upl= oads/2011/04/Bormann.pdf

A nice illustration of where we were if we weren't doing that is
in http= ://j.mp/gsD4r7

Each time the constrained work entered a new domain (INT, RTG, APP),
there are these heated arguments about not always using the existing
hammers.=C2=A0 In Security, BIT arguments are often quite compelling, so the threshold is probably higher (I'm sure RTG people will disagree).
Oh, and in the development of both 6LoWPAN-ND and CoAP, we have thrown
out things that had been in the WG document (or even standardized!)
for over a year or longer when better alternatives came along.=C2=A0 This sometimes has been painful, when the old way of doing things already
had been well-accepted and implemented interoperably.=C2=A0 I hope we can do that here, as well.

Gr=C3=BC=C3=9Fe, Carsten

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

--001a113957e0611a6205234d8c15-- From nobody Fri Oct 30 06:46:01 2015 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 240F91A1B1B for ; Fri, 30 Oct 2015 06:46:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dNKx5dBrSxnR for ; Fri, 30 Oct 2015 06:45:57 -0700 (PDT) Received: from xenon21.um.es (xenon21.um.es [155.54.212.161]) by ietfa.amsl.com (Postfix) with ESMTP id 605B71A1B19 for ; Fri, 30 Oct 2015 06:45:57 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by xenon21.um.es (Postfix) with ESMTP id CBF9740CC6; Fri, 30 Oct 2015 14:45:55 +0100 (CET) X-Virus-Scanned: by antispam in UMU at xenon21.um.es Received: from xenon21.um.es ([127.0.0.1]) by localhost (xenon21.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id q3hHpGv7cWYm; Fri, 30 Oct 2015 14:45:55 +0100 (CET) Received: from inf-205-219.inf.um.es (inf-205-219.inf.um.es [155.54.205.219]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: rafa) by xenon21.um.es (Postfix) with ESMTPSA id 5D96040CC5; Fri, 30 Oct 2015 14:45:54 +0100 (CET) From: Rafa Marin Lopez Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Date: Fri, 30 Oct 2015 14:46:00 +0100 Message-Id: <33297FDC-BAA8-402B-80B8-B9CE19991D02@um.es> To: ace@ietf.org Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\)) X-Mailer: Apple Mail (2.3096.5) Archived-At: Cc: Rafa Marin Lopez Subject: [Ace] My comments about draft-seitz-ace-oauth-authz-00 X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 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, 30 Oct 2015 13:46:00 -0000 Dear authors, all: Here you can find my review about draft-seitz-ace-oauth-authz-00. The document is very detailed, which helps to understand the proposal. = In my opinion, using a well-known protocol such as OAuth 2.0 where many = people are working and have worked gives maturity and makes = comprehensible the proposal to a broader audience. I also think it would = be good to have some performance data (if available) such as message = size, processing time , etc=E2=80=A6 . In any case, I believe the usage = of OAuth 2.0 is a right and reasonable path for achieving an ACE = solution. Here some more detail comments/questions: In page 3: "This memo describes how to re-use OAuth 2.0 [RFC6749] to extend authorization to Internet of Things devices with different kinds of constrainedness. At the time of writing OAuth 2.0 is already used with certain types of IoT devices and this document will provide..." [Rafa] What types of IoT devices already use OAuth 2.0? A reference = with this usage of OAuth 2.0 would be helpful. "Figure 1: Overview of the basic protocol flow Requesting an Access Token (A):=E2=80=9D [Rafa] Is there any assumption for the client authentication here? "The /token resource (called "endpoint" in OAuth 2.0), defined in Section 3.2 of [RFC6749], is used by the client to obtain an access token. Requests sent to the /token resource use the HTTP POST = method=E2=80=A6" [Rafa] Mmmmm=E2=80=A6 if client is constrained =E2=80=A6 will it use = HTTP POST?=20 =E2=80=9C6.1 Client and Resource Server are Offline" [Rafa] I realize that offline is sometimes confusing. client and = resource server can communicate each other. The AS is offline since it = is not reachable. But anyway, this is a minor thing. "A: The client first generates a public-private key pair used for communication security with the RS." [Rafa] In the same section 6.1, you describe the case where client and = resource server cannot contact the AS. However you describe the = communication with the AS. This might result confusing is shown. Perhaps = the interaction with the AS should be placed out of this section. Page 16 "Figure 5: Access Token including Public Key of the Client. Messages C and F are shown in Figure 6 - Figure 7. C: The client then sends the PoP token to the /authz-info resource at the RS. This is a plain CoAP request, i.e. no DTLS/OSCOAP between client and RS, since the token is integrity protected between AS and RS." =20 [Rafa] I think I am missing something here. A PoP token proves that the = client knows a key (key confirmation). But the reason you give for not = using DTLS/OSCOAP is that the token is integrity protected AS and RS. = The client should prove that it owns the key anyway, no? "The RS verifies that the PoP token was created by a known and trusted AS, is valid, and responds to the client. The RS caches the security context together with authorization information about this client contained in the PoP token." [Rafa] This is related to my previous comment. Is it possible for an = attacker to reply the PoP token? It should not due to PoP token nature = but nothing is mentioned about it, just the verification that it was = created by a trusted AS. Maybe my understanding of PoP token is wrong.=20= "6.3. Token Introspection with an Offline Client" [Rafa] Although token introspection may be an interesting feature, I am = thinking that sending additional messages from the RS to the AS is not = good when RS is constrained. I understand it is a tradeoff between = =E2=80=9Cauthorization freshness=E2=80=9D vs additional signaling.=20 Page 25: "In case 2., the RS does not need to receive any message from = the client,"=20 [Rafa] I do not understand why the RS does not need to receive any = message from the client=E2=80=A6 could you clarify? Hope this helps. Best Regards. ------------------------------------------------------- Rafael Marin Lopez, PhD Dept. Information and Communications Engineering (DIIC) Faculty of Computer Science-University of Murcia 30100 Murcia - Spain Telf: +34868888501 Fax: +34868884151 e-mail: rafa@um.es ------------------------------------------------------- From nobody Fri Oct 30 13:22:22 2015 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55D881A9097 for ; Fri, 30 Oct 2015 13:22:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.575 X-Spam-Level: X-Spam-Status: No, score=-1.575 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, T_RP_MATCHES_RCVD=-0.01, UNPARSEABLE_RELAY=0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ETBTuaPha7O2 for ; Fri, 30 Oct 2015 13:22:04 -0700 (PDT) Received: from mailgw02.mediatek.com (mailgw02.mediatek.com [69.46.227.142]) by ietfa.amsl.com (Postfix) with ESMTP id 62EC61A90A6 for ; Fri, 30 Oct 2015 13:22:04 -0700 (PDT) X-Listener-Flag: 11101 Received: from mtkcas64.mediatek.inc [(172.29.17.144)] by mailgw02.mediatek.com (envelope-from ) (Cellopoint E-mail Firewall v3.9.12 Build 0312 with TLS) with ESMTP id 498127671; Fri, 30 Oct 2015 16:12:15 -0500 Received: from MTKMBS61N1.mediatek.inc ([fe80::2898:86df:e627:42ee]) by MTKCAS64.mediatek.inc ([::1]) with mapi id 14.03.0181.006; Fri, 30 Oct 2015 16:22:00 -0400 From: Madjid Nakhjiri To: Carsten Bormann Thread-Topic: [Ace] comments on draft-seitz-ace-oauth-authz-00 Thread-Index: AQHREeZtLoYHI1sV0UKYlZCdCQHqy56B8FwAgAJazQA= Date: Fri, 30 Oct 2015 20:21:59 +0000 Message-ID: In-Reply-To: <5631754C.6010901@tzi.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.29.122.58] x-tm-as-product-ver: SMEX-10.2.0.3176-8.000.1202-21912.002 x-tm-as-result: No--49.976200-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="utf-8" Content-ID: <0B97E5BD31BE344C887CE7500823F90C@mediatek.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "ace@ietf.org" Subject: Re: [Ace] comments on draft-seitz-ace-oauth-authz-00 X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 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, 30 Oct 2015 20:22:06 -0000 SGkgQ2Fyc3RlbiwgDQoNClRoYW5rcyBmb3IgdGhlIGNsYXJpZmljYXRpb24uIEkgdGhpbmsgSSBw aWNrZWQgdXAgb24gdGhlIGZvbGxvd2luZw0Kc3RhdGVtZW50IGFuZCB0aGVuIG1peGVkIHVwIG15 IGJpdHMgYW5kIGJ5dGVzOikNCg0KIjUuMiBBdXRob3JpemF0aW9uIEluZm9ybWF0aW9uIFJlc291 cmNlIGF0IHRoZSBSZXNvdXJjZSBTZXJ2ZXINCkEgY29uc2VxdWVuY2Ugb2YgYWxsb3dpbmcgdGhl IHVzZSBvZiBDb0FQIGFzIHdlYiB0cmFuc2ZlciBwcm90b2NvbCBpcyB0aGF0DQp3ZSBjYW5ub3Qg cmVseSBvbiBIVFRQIHNwZWNpZmljIG1lY2hhbmlzbXMsIHN1Y2ggYXMgdHJhbnNmZXJyaW5nDQpp bmZvcm1hdGlvbiBlbGVtZW50cyBpbiBIVFRQIGhlYWRlcnMgc2luY2UgdGhvc2UgYXJlIG5vdCBu ZWNlc3NhcmlseQ0KZ3JhY2VmdWxseSBtYXBwZWQgdG8gQ29BUC4gIEluIGNhc2UgdGhlIGFjY2Vz cyB0b2tlbiBpcyBsYXJnZXIgdGhlbiAyNTUNCmJ5dGVzIGl0IHNob3VsZCBub3QgYmUgc2VudCBh cyBhIENvQVAgb3B0aW9uLuKAnQ0KDQoNCg0KWWVzLCBhcyB5b3Ugc2F5LCB3ZSBkbyB3YW50IHRv IHJlZHVjZSB0aGUgc2l6ZSBvZiB0aGUgbWVzc2FnZXMgb3IgcHJvYmFibHkNCnRoZSBmcmVxdWVu Y3kgd2l0aCB3aGljaCBsYXJnZSBtZXNzYWdlcyBhcmUgc2VudCwgZS5nLiBCeSBpbmNyZWFzaW5n IHRoZQ0KbGlmZSB0aW1lIG9mIHRoZSBPQVVUSCB0b2tlbi4gTm93LCAgdGhlIHF1ZXN0aW9ucyBh cmUNCjEpIHdoZXRoZXIgd2Ugd2FudCB0byBwdXQgdGhlIHRva2VuIG9yIGFueSB0eXBlIG9mIHNp Z25hdHVyZSBpbnNpZGUgYW4NCm9wdGlvbiwgZ2l2ZW4gdGhhdCBDT0FQIGJsb2NrIHByb3RvY29s IChub3Qgc3VyZSBvZiB0aGUgZGV0YWlscykgY2Fubm90DQpzcGxpdCB0aGUgb3B0aW9uIGFzIHlv dSBzYXk/DQoyKSBpZiB3ZSBkb27igJl0IHdhbnQgdG8gdGFrZSB1cCBzbyBtdWNoIG1lc3NhZ2Ug Qlcgb24gYSBzaWduYXR1cmUsIHdoYXQNCmludGVncml0eSBwcm90ZWN0aW9uLyBhdXRoZW50aWNh dGlvbiBtZWNoYW5pc21zIGFyZSB3ZSBzdWdnZXN0aW5nPyBGcm9tDQp3aGF0IEkgdW5kZXJzdGFu ZCB3aXRoIDI1NiBiaXRzIEVDIGtleXMsIHRoZSBFQ0RTQSBzaWcgaXMgNTEyKyBiaXRzLiBBcmUN CmZvbGtzIHN1Z2dlc3RpbmcgTUFDcz8NCg0KUmVhZGluZyBDT0FQIFJGQyA3MjUyLCBzZWN0aW9u IDUuNCwgSSBkb27igJl0IHNlZSBhbnkgb3B0aW9uIHRoYXQgc291bmRzDQpsaWtlIG9uZSB0aGF0 IHdvdWxkIGNhcnJ5IGFuIE9BVVRIIHRva2VuIG9yIGEgc2lnbmF0dXJlLiBBbHNvIG15IDEwIG1p bg0KaW52ZXN0aWdhdGlvbiBzaG93cyAoc2VjdGlvbiAzLjEgb3B0aW9uIGZvcm1hdCkgdGhhdCB0 aGUgb3B0aW9uIGxlbmd0aCBpcw0Kb25seSA0IGJpdHMgYW5kIGFmdGVyIHRoZSByZXNlcnZlZCB2 YWx1ZXMsIG9ubHkgYWxsb3cgZm9yIDEtMTIgYnl0ZXMuIElzDQp0aGVyZSBzb21lIG90aGVyIGNs YXVzZSB0aGF0IEkgbWlzc2VkPyBUaGUgb3B0aW9uIGxlbmd0aCBleHRlbmRlZCBtYXliZT8NCg0K DQoNCg0KUmVnYXJkcywNCk1hZGppZCBOYWtoamlyaQ0K6bqm5b+X5b6XIA0KDQpQcmluY2lwYWwg U2VjdXJpdHkgQXJjaGl0ZWN0DQpNZWRpYVRlayBJbmMuDQrigJxTaW1wbGljaXR5IGlzIHRoZSB1 bHRpbWF0ZSBzb3BoaXN0aWNhdGlvbiINCg0KDQoNCg0KT24gMTAvMjgvMTUsIDY6MjQgUE0sICJD YXJzdGVuIEJvcm1hbm4iIDxjYWJvQHR6aS5vcmc+IHdyb3RlOg0KDQo+TWFkamlkIE5ha2hqaXJp IHdyb3RlOg0KPj4gIyBJZiBDT0FQIG9wdGlvbiBtYXggbGVuZ3RoIGlzIDI1NiBiaXRzLCBob3cg Y2FuIGEgc2lnbmF0dXJlIG1lY2hhbmlzbQ0KPj4gdGhhdCByZXF1aXJlcyB0aGF0IG1hbnkgYml0 cyBiZSB1c2VkPw0KPg0KPkl0J3Mgbm90IC0tIHRoZXJlIGlzIG5vIGZ1bmRhbWVudGFsIGxpbWl0 IHRvIENvQVAgb3B0aW9uIHNpemUuDQo+UHJhY3RpY2FsbHkgc3BlYWtpbmcsIGhvd2V2ZXIsIGl0 IGlzIG9mdGVuIGFkdmFudGFnZW91cyB0byBiZSBhYmxlIHRvDQo+cHV0IGEgQ29BUCBtZXNzYWdl IGludG8gYSBkYXRhZ3JhbSB0aGF0IGlzIG9mIGFwcHJvcHJpYXRlIHNpemUuDQo+UkZDIDcyNTIg Z2l2ZXMgMTE1MiBieXRlcyBhcyBhIHByYWN0aWNhbCB1cHBlciBib3VuZCBvZiB0aGF0OyBzb21l DQo+cmFkaW9zIGFyZSBtdWNoIGhhcHBpZXIgd2l0aCA4MCBieXRlcyBvciBsZXNzIChub3QgZXhj bHVkaW5nIHRoZQ0KPm9jY2FzaW9uYWwgbGFyZ2VyIG1lc3NhZ2UsIGJ1dCB0aGF0IG1pZ2h0IGhh dmUgYSBoYXJkZXIgdGltZSBnZXR0aW5nDQo+dGhyb3VnaCwgc28geW91IG1pZ2h0IHdhbnQgdG8g dXNlIHRoZW0gc3BhcmluZ2x5KS4gIEFsc28gbm90ZSB0aGF0IHRoZQ0KPkNvQVAgYmxvY2sgcHJv dG9jb2wgaGVscHMgd2l0aCBzcGxpdHRpbmcgdXAgcGF5bG9hZHMgaW50byBibG9ja3MsIGJ1dA0K Pm9wdGlvbnMgZG8gbm90IGJlbmVmaXQgZnJvbSB0aGF0Lg0KPg0KPlNvIHRoZSBnaXN0IGlzOiBh IDI1Ni1iaXQgKDMyLWJ5dGUpIHNpZ25hdHVyZSBpcyBxdWl0ZSBwb3NzaWJsZSBpbiBhbg0KPm9w dGlvbjsgZm9yIHNvbWUgYXBwbGljYXRpb25zIHRoZSBidXJkZW4gc3VjaCBhbiBvcHRpb24gcGxh Y2VzIG9uIHRoZQ0KPnJlbWFpbmluZyBtZXNzYWdlIHNpemUgaXMgcmF0aGVyIHNpZ25pZmljYW50 LCBidXQgbW9zdGx5IG5vdCBwcm9oaWJpdGl2ZS4NCj4NCj5HcsO8w59lLCBDYXJzdGVuDQo+DQo+ X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj5BY2UgbWFp bGluZyBsaXN0DQo+QWNlQGlldGYub3JnDQo+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9hY2UNCg0KDQoqKioqKioqKioqKioqIEVtYWlsIENvbmZpZGVudGlhbGl0eSBOb3Rp Y2UgKioqKioqKioqKioqKioqKioqKioNClRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaW4gdGhp cyBlLW1haWwgbWVzc2FnZSAoaW5jbHVkaW5nIGFueSANCmF0dGFjaG1lbnRzKSBtYXkgYmUgY29u ZmlkZW50aWFsLCBwcm9wcmlldGFyeSwgcHJpdmlsZWdlZCwgb3Igb3RoZXJ3aXNlDQpleGVtcHQg ZnJvbSBkaXNjbG9zdXJlIHVuZGVyIGFwcGxpY2FibGUgbGF3cy4gSXQgaXMgaW50ZW5kZWQgdG8g YmUgDQpjb252ZXllZCBvbmx5IHRvIHRoZSBkZXNpZ25hdGVkIHJlY2lwaWVudChzKS4gQW55IHVz ZSwgZGlzc2VtaW5hdGlvbiwgDQpkaXN0cmlidXRpb24sIHByaW50aW5nLCByZXRhaW5pbmcgb3Ig Y29weWluZyBvZiB0aGlzIGUtbWFpbCAoaW5jbHVkaW5nIGl0cyANCmF0dGFjaG1lbnRzKSBieSB1 bmludGVuZGVkIHJlY2lwaWVudChzKSBpcyBzdHJpY3RseSBwcm9oaWJpdGVkIGFuZCBtYXkgDQpi ZSB1bmxhd2Z1bC4gSWYgeW91IGFyZSBub3QgYW4gaW50ZW5kZWQgcmVjaXBpZW50IG9mIHRoaXMg ZS1tYWlsLCBvciBiZWxpZXZlIA0KdGhhdCB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGUtbWFpbCBp biBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIA0KaW1tZWRpYXRlbHkgKGJ5IHJlcGx5 aW5nIHRvIHRoaXMgZS1tYWlsKSwgZGVsZXRlIGFueSBhbmQgYWxsIGNvcGllcyBvZiANCnRoaXMg ZS1tYWlsIChpbmNsdWRpbmcgYW55IGF0dGFjaG1lbnRzKSBmcm9tIHlvdXIgc3lzdGVtLCBhbmQg ZG8gbm90DQpkaXNjbG9zZSB0aGUgY29udGVudCBvZiB0aGlzIGUtbWFpbCB0byBhbnkgb3RoZXIg cGVyc29uLiBUaGFuayB5b3UhDQo= From nobody Fri Oct 30 14:06:23 2015 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DA821AC3E7 for ; Fri, 30 Oct 2015 14:05:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.898 X-Spam-Level: X-Spam-Status: No, score=0.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.793, UNPARSEABLE_RELAY=0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WllfU3122mUG for ; Fri, 30 Oct 2015 14:05:35 -0700 (PDT) Received: from mailgw02.mediatek.com (unknown [66.228.70.112]) by ietfa.amsl.com (Postfix) with ESMTP id 9B9121AC3F2 for ; Fri, 30 Oct 2015 14:05:35 -0700 (PDT) X-Listener-Flag: 11101 Received: from mtkcas64.mediatek.inc [(172.29.17.144)] by mailgw02.mediatek.com (envelope-from ) (Cellopoint E-mail Firewall v3.9.12 Build 0312 with TLS) with ESMTP id 1124321133; Fri, 30 Oct 2015 16:55:46 -0500 Received: from MTKCAS63.mediatek.inc (172.29.17.143) by MTKCAS64.mediatek.inc (172.29.17.144) with Microsoft SMTP Server (TLS) id 14.3.181.6; Fri, 30 Oct 2015 17:05:30 -0400 Received: from MTKMBS61N1.mediatek.inc ([fe80::2898:86df:e627:42ee]) by MTKCAS63.mediatek.inc ([fe80::69ba:ee95:46f7:711d%10]) with mapi id 14.03.0181.006; Fri, 30 Oct 2015 17:05:30 -0400 From: Madjid Nakhjiri To: Ludwig Seitz , "ace@ietf.org" Thread-Topic: [Ace] comments on draft-seitz-ace-oauth-authz-00 Thread-Index: AQHREeZtLoYHI1sV0UKYlZCdCQHqy56CfAmAgAHbRoA= Date: Fri, 30 Oct 2015 21:05:29 +0000 Message-ID: In-Reply-To: <5631EA77.2060405@sics.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.29.122.58] Content-Type: text/plain; charset="utf-8" Content-ID: <7DEC22C48992A04AB2FBD23B277CBF63@mediatek.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-TM-AS-Product-Ver: SMEX-10.2.0.3176-8.000.1202-21912.002 X-TM-AS-Result: No--17.754100-8.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No Archived-At: Subject: Re: [Ace] comments on draft-seitz-ace-oauth-authz-00 X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 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, 30 Oct 2015 21:05:38 -0000 SGkgTHVkd2lnLCANCg0KUmVnYXJkaW5nIA0KDQoiWW91IHNlZW0gdG8gaGF2ZSBleHBlcmllbmNl IHdpdGggc3BlY2lmaWMgaXNzdWVzIGluIHRoYXQgbWF0dGVyLCBjb3VsZA0KeW91IGRlc2NyaWJl IHRob3NlIGlzc3VlcyBpbiBtb3JlIGRldGFpbD/igJ0NCg0KSSBhcHByZWNpYXRlIHlvdXIgaW5x dWlyeSBmb3IgbWUgdG8gYmUgZnJhbmssIHNvIGxldCBtZSBwcm92aWRlIGEgY291cGxlDQpvZiBi cm9hZCBhbnN3ZXJzOg0KDQoxKSBJIGFtIGludm9sdmVkIHdpdGggYXQgbGVhc3QgMyBzdGFuZGFy ZHMgd2hvIGVpdGhlciBhcmUgc3RydWdnbGluZyBvcg0Kd29ya2luZyBoYXJkIHRvIHNvbHZlIHRo ZSBvbmJvYXJkaW5nLyBwcm92aXNpb25pbmcgcHJvYmxlbXMgb3IgSU9UIHR5cGUNCmVudmlyb25t ZW50cy4NClRoZSBwcm9ibGVtcyBhcmUgc2V2ZXJhbDoNCmEpIGRldmljZXMgbWF5IG9yIG1heSBu b3QgaGF2ZSBiZWVuIHBlcnNvbmFsaXplZCBpbiB0aGUgZmFjdG9yeSB3aXRoDQpnbG9iYWwga2V5 LyBJRCBhbmQgcHJvZHVjdCBtYW5hZ2VycyBhcmUgc3RpbGwgc3RydWdnbGluZyB3aGV0aGVyIHRo ZSBjb3N0DQppcyB3b3J0aCBpdCwgZXNwZWNpYWxseSBnaXZlbiBzb21lIG9mIHRoZSBwcml2YWN5 LyB1c2VyIHRyYWNraW5nIGlzc3VlcyAoSQ0KYW0gdGhpbmtpbmcgb3V0IGxvdWQgaGVyZSkuIFNv IGxvdHMgb2YgdHJpY2tzIGFyZSBiZWluZyBwbGF5ZWQgZm9yIHRoYXQNCmFuZCB0aGUgZm9sbG93 aW5nIHJlYXNvbi4NCkIpIHRoZSBJT1QgZGV2aWNlIGFuZCB0aGUgcHJvdmlzaW9uaW5nIGRldmlj ZSAoeW91ciBBUykgYXJlIGNvbXBsZXRlbHkNCnVua25vd24gdG8gZWFjaCBvdGhlciwgc28gdGhl IHByb2JsZW0gb2YgaW5pdGlhbCBpbnRyb2R1Y3Rpb24gYW5kIHRydXN0DQpib290c3RyYXBwaW5n IGlzIHZlcnkgcmVhbCBhbmQgcHJldmFsZW50LiBFdmVuIFBLSSBtYXkgbm90IGhlbHAgaW4gY2Fz ZQ0KdGhlIHJvb3RzIGFyZSBub3QgbXV0dWFsbHkgdHJ1c3RlZC4gVGhpcyBtZWFucyBpbi1iYW5k IGF1dGhlbnRpY2F0aW9uIGlzDQpub3QgcG9zc2libGUgdy9vIHRydXN0IGJvb3RzdHJhcHBpbmcu IFRvIG1ha2UgdGhlIG1hdHRlciB3b3JzZSwgdGhlDQpkZXZpY2VzIGFyZSBoZWFkbGVzcywgbWVh bmluZyB0aGF0IHRoZXJlIGlzIG5vIHNjcmVlbiBvciBrZXkgYm9hcmQgdG8gdHlwZQ0Kc29tZXRo aW5nIG9yIHJlYWQgc29tZXRoaW5nLg0KSSBhbSBub3Qgc3VyZSBpZiB0aGVzZSBhcmUgdGhlIHR5 cGUgb2YgcHJvYmxlbXMgdGhhdCBJRVRGIGRlYWxzIHdpdGggcmlnaHQNCm5vdy4gSSBhbSBqdXN0 IG1ha2luZyBhIHNsb3cgZW50cnkgaW50byBJRVRGIHNwYWNlIG5vdzopDQoNCjIpIEkgYW0gaW50 ZXJlc3RlZCBpbiBmaWd1cmluZyBvdXQgd2hhdCBzb3J0IG9mIHN1cHBvcnQgSFcgdmVuZG9ycyBs aWtlDQpNZWRpYXRlayBuZWVkIHRvIHByb3ZpZGUgZm9yIHN1cHBvcnRpbmcgYXV0aG9yaXphdGlv biBtZWNoYW5pc21zIHN1Y2ggYXMNCk9BVVRILiANCg0KTGV0IG1lIGFuc3dlciBvdGhlciBxdWVz dGlvbnMgaW5saW5lDQoNCg0KUmVnYXJkcywNCk1hZGppZCBOYWtoamlyaQ0K6bqm5b+X5b6XIA0K DQpQcmluY2lwYWwgU2VjdXJpdHkgQXJjaGl0ZWN0DQpNZWRpYVRlayBJbmMuDQrigJxTaW1wbGlj aXR5IGlzIHRoZSB1bHRpbWF0ZSBzb3BoaXN0aWNhdGlvbiINCg0KDQoNCg0KT24gMTAvMjkvMTUs IDI6NDQgQU0sICJMdWR3aWcgU2VpdHoiIDxsdWR3aWdAc2ljcy5zZT4gd3JvdGU6DQoNCj5IZWxs byBNYWRqaWQsDQo+DQo+VGhhbmsgeW91IGZvciBwcm92aWRpbmcgeW91ciBjb21tZW50cyBvbiBv dXIgZHJhZnQhIEFuc3dlcnMgYXJlIGlubGluZS4NCj4NCj4vTHVkd2lnDQo+DQo+T24gMjAxNS0x MC0yOSAwMjowOSwgTWFkamlkIE5ha2hqaXJpIHdyb3RlOg0KPlsuLi5dDQo+PiAgMS4gcHJvdmlz aW9uaW5nIG9mIGNsaWVudCBrZXlzIGZvciBhdXRoZW50aWNhdGlvbiBhbmQgcmVnaXN0cmF0aW9u IHdpdGgNCj4+ICAgICB0aGUgQVMuIEhhdmluZyBhIGdsb2JhbCBrZXkvSUQgaW4gdGhlIGNsaWVu dCBoYXMgYmVlbiBhbiBpc3N1ZSBmb3INCj4+ICAgICBzb21lIE9BVVRIIGltcGxlbWVudGF0aW9u cyBpbiB0aGUgcGFzdC4gR2l2ZW4gdGhhdCB0aGUgY2xpZW50cyBhcmUNCj4+ICAgICBJb1QgZGV2 aWNlcywgdGhpcyBpcyBub3QgYXMgc3RyYWlnaHQgZm9yd2FyZCBhcyBtb2JpbGUgYXBwIGNsaWVu dHMuDQo+DQo+SWYgSSB1bmRlcnN0YW5kIHlvdSBjb3JyZWN0bHkgdGhlIHByb2JsZW0gaXMgYWJv dXQgaGF2aW5nIGdsb2JhbCBJRHMNCj50aGF0IGNsaWVudHMgYW5kIEFTIGNhbiB1c2UgdG8gcmVm ZXJlbmNlIGtleXMuDQoNCk1hZGppZD4+RnJvbSB3aGF0IEkgcmVjYWxsIGZyb20gbG9va2luZyBh dCBPQVVUSCBhIHllYXIgb3IgdHdvIGJhY2sgd2FzDQp0aGF0IHRoZXkgZGlzdGluZ3Vpc2ggYmV0 d2VlbiBjb25maWRlbnRpYWwgYW5kIHB1YmxpYyBjbGllbnRzLCBkZXBlbmRpbmcNCm9uIHRoZWly IGFiaWxpdHkgdG8gcGVyZm9ybSDigJxwcm9wZXIgYXV0aGVudGljYXRpb27igJ0gYW5kIGtlZXAg dGhlaXINCmNyZWRlbnRpYWxzIHNlY3JldC4gVGhpcyB3b3VsZCBhbHNvIGRldGVybWluZSB0aGUg dHlwZSBvZiBncmFudCB0aGF0IHRoZQ0KY2xpZW50IGdldHMuICBJIGRvbuKAmXQgdGhpbmsgT0FV VEggc3BlYyBkZWFscyB3aXRoIGhvdyB0aGUgY2xpZW50DQpjcmVkZW50aWFscyBnZXRzIHByb3Zp c2lvbmVkIGludG8gdGhlIGNsaWVudHMgYW5kIGFzIGEgcmVzdWx0cywgc29tZQ0KZGV2ZWxvcGVy cyBoYXZlIHNpbXBseSBoYXJkY29kZSB0aGUgc2VjcmV0IGludG8gdGhlIGNsaWVudCBjb2RlIGFu ZCBvbiB0aGUNCnNlcnZlciBzaWRlLiBUaGlzIHdvdWxkIG5vdCBldmVuIHBvc3NpYmxlIGluIHRo ZSB3b3JsZCBvZiBJT1QgYmVjYXVzZSB0aGUNCmRldmljZSBhY3RpbmcgYXMgY2xpZW50LCB0aGUg ZGV2aWNlIGFjdGluZyBhcyBBUyBpbiB0aGUgc3lzdGVtIGFyZSBub3QNCmZyb20gdGhlIHNhbWUg dmVuZG9yIGFuZCBkb27igJl0IGtub3cgZWFjaCBvdGhlciBmcm9tIHRoZSBwYXN0LiBGdXJ0aGVy bW9yZSwNCmN1cnJlbnRseSB0aGVyZSBpcyBubyDigJxnbG9iYWxpemF0aW9uIG1lY2hhbmlzbeKA nSBmb3IgZGVmaW5pbmcgSWRzLg0KPg0KPkkgZXhwZWN0IHRoYXQgaW4gbWFueSBjYXNlcyB0aGUg Y2xpZW50cyB3aWxsIG9ubHkgYmUgc2VydmVkIGJ5IGEgc2luZ2xlDQo+QVMgKG9yIGEgZmV3IG9u ZXMgYXQgbW9zdCksIHdoaWNoIG1lYW5zIHRoYXQgdGhlIGtleSBtYW5hZ2VtZW50IHByb2JsZW0N Cj5vbiB0aGF0IHNpZGUgaXMgbGVzcyBkaWZmaWN1bHQuDQo+DQo+U2luY2UgdGhlIEFTIHdpbGwg cHJvYmFibHkgbWFuYWdlIGtleXMgZm9yIG1hbnkgY2xpZW50cywgdGhlIElEcyBuZWVkIHRvDQo+ YmUgdW5pcXVlIGF0IGxlYXN0IHBlciBBUy4gVGhlcmVmb3JlIGRlZmluaW5nIGEgbmFtZXNwYWNl IHRoYXQgaXMgdW5pcXVlDQo+Zm9yIGEgc3BlY2lmaWMgQVMgYW5kIHByZWZpeGluZyB0aGUga2V5 IElEIHdpdGggdGhhdCBuYW1lc3BhY2Ugc2hvdWxkDQo+d29yayB0b3dhcmRzIHNvbHZpbmcgdGhh dCBwcm9ibGVtLg0KPg0KPllvdSBzZWVtIHRvIGhhdmUgZXhwZXJpZW5jZSB3aXRoIHNwZWNpZmlj IGlzc3VlcyBpbiB0aGF0IG1hdHRlciwgY291bGQNCj55b3UgZGVzY3JpYmUgdGhvc2UgaXNzdWVz IGluIG1vcmUgZGV0YWlsPw0KPg0KPk5PVEU6IEFDRSBpcyBleHBsaWNpdGx5IG5vdCBjaGFydGVy ZWQgdG8gd29yayB3aXRoIGtleSBtYW5hZ2VtZW50IGFuZA0KPnRoZSB3b3JkIGhhcyBiZWVuIHNo dW5uZWQgZnJvbSBhbnkgZG9jdW1lbnQsIHRoZXJlZm9yZSBJIGRvIG5vdCBleHBlY3QNCj50aGF0 IEFDRSB3aWxsIHdvcmsgb24gdGhhdCBpc3N1ZS4NCg0KTWFkamlkPj5mYWlyIGVub3VnaC4gSXMg dGhlcmUgYW55IG90aGVyIHBsYWNlIGluIElFVEYgdGhhdCBkZWFscyB3aXRoIGl0Pw0KDQo+DQo+ DQo+PiAgMi4gU2FtZSB0aGluZyBmb3IgUlMgdG8gQVMgcmVnaXN0cmF0aW9uLiBSUyBpcyBtYW55 IHRpbWVzIGEgY29uc3RyYWluZWQNCj4+ICAgICBkZXZpY2UgaXRzZWxmLiBBbHNvIEkgYW0gbm90 IGNsZWFyIGhvdyB0aGUgQVMgd2lsbCBnZXQgdGhlDQo+PiAgICAgYXV0aG9yaXphdGlvbiBwb2xp Y2llcyAoc2NvcGUvY2xhaW0/KSBmcm9tIFJTLiBJcyBpdCB0aGF0IGl0IGlzIHRoZQ0KPj4gICAg IEFTIHRoYXQgZGVjaWRlcz8/DQo+DQo+DQo+QWN0dWFsbHkgaXQgd2FzIG5ldmVyIHBsYW5uZWQg dGhhdCB0aGUgaXRzZWxmIFJTIHNob3VsZCBwcm92aWRlIGFuZA0KPm1hbmFnZSB0aGUgYXV0aG9y aXphdGlvbiBwb2xpY2llcyBhdCB0aGUgQVMuIFRoZSByZXNvdXJjZSBvd25lcnMgYXJlDQo+ZXhw ZWN0ZWQgdG8gZG8gdGhpcyBhdCB0aGUgQVMgZGlyZWN0bHksIHdoZW4gdGhleSBlbnJvbGwgYSBS UyB0aGV5IG93bi4NCg0KTWFkamlkPj5PaywgbWFrZXMgc2Vuc2UuIEFyZSB0aGUgcG9saWN5IGRl ZmluaXRpb25zIHN0YW5kYXJkaXplZD8gT3IgdXAgdG8NCmVhY2ggdmVuZG9yPw0KDQoNCj4NCj4+ ICAzLiBJcyBhdXRob3JpemF0aW9uIHN1YmplY3QgYmFzZWQgKGlkZW50aXR5IG9mIGNsaWVudCkg b3Igcm9sZSBiYXNlZD8NCj4NCj5UaGUgc29sdXRpb24gc2hvdWxkIHdvcmsgd2l0aCBib3RoIGFw cHJvYWNoZXMuIFRoZSBjbGllbnQgaXMgZXhwZWN0ZWQgdG8NCj5wcmVzZW50IGNyZWRlbnRpYWxz IHRvIHRoZSBBUyB3aGVuIHJlcXVlc3RpbmcgYSB0b2tlbi4gVGhlc2UgY3JlZGVudGlhbHMNCj5j YW4gdGhlbiBiZSByZXNvbHZlZCB0byBhbiBpZGVudGl0eSwgb3IgYSByb2xlLCBvciBzb21lIHNl Y3VyaXR5DQo+YXR0cmlidXRlcyBvZiB0aGUgY2xpZW50LiBUaGUgQVMgaXMgdGhlbiBleHBlY3Rl ZCB0byBtYWtlIGFuDQo+YXV0aG9yaXphdGlvbiBkZWNpc2lvbiBiYXNlZCBvbiB0aGUgY3JlZGVu dGlhbHMgYW5kIHRoZSBleGlzdGluZw0KPmF1dGhvcml6YXRpb24gcG9saWNpZXMuDQoNCk1hZGpp ZD4+c291bmRzIGdvb2QuIEkgYW0gZ2xhZCBib3RoIGlkZW50aXR5IGFuZCByb2xlIGFyZSBiZWlu ZyBzdXBwb3J0ZWQuDQoNCj4NCj4NCj4+ICA0LiBSZXN0cm9zcGVjdGlvbiBvZiB0aGUgdG9rZW5z IGNhbiBiZSBleHBlbnNpdmUgYW5kIHVuc2NhbGFibGUgZm9yIHRoZQ0KPj4gICAgIEFTIChpZiB0 aGVyZSBhcmUgbWFueSBSUyBub2RlcyksIGJ1dCB2ZXJpZmljYXRpb24gb2Ygc2VsZi1jb250YWlu ZWQNCj4+ICAgICB0b2tlbnMgYnkgdGhlIFJTIGFsc28gc291bmRzIGV4cGVuc2l2ZSwgcGx1cyB0 aGUgdmVyaWZpY2F0aW9uIGtleXMNCj4+ICAgICBuZWVkIHRvIGJlIHByb3Zpc2lvbmVkIGluIHRo ZSBSUy4gV291bGQgYmUgbmljZSB0byBoYXZlIGd1aWRhbmNlIG9uDQo+PiAgICAgd2hpY2ggbWFr ZXMgc2Vuc2UgdGFraW5nIGRldmljZSBjYXBhYmlsaXRpZXMvY2xhc3MgaW50byBhY2NvdW50LiBB bnkNCj4+ICAgICBuZXR3b3JrIHNpbXVsYXRvcnMgb3V0IHRoZXJlPw0KPg0KPkknbSBndWVzc2lu ZyB5b3UgbWVhbnQgSW50cm9zcGVjdGlvbiBoZXJlIHJpZ2h0Pw0KPg0KPlRoZSBBUyBpcyBub3Qg ZXhwZWN0ZWQgdG8gYmUgYSBjb25zdHJhaW5lZCBkZXZpY2UsIHRodXMgaXQgc2hvdWxkIGJlDQo+ YWJsZSB0byBzZXJ2ZSBhIHNpZ25pZmljYW50IG51bWJlciBvZiBpbnRyb3NwZWN0aW9uIHJlcXVl c3RzIGZyb20NCj5kaWZmZXJlbnQgUlMuIEludHJvc3BlY3Rpb24gd29ya3MgYmVzdCBpZiB0aGUg UlMgaGFzIGEgZ29vZCBjb25uZWN0aXZpdHkNCj50byB0aGUgQVMgd2hpbGUgdGhlIGNsaWVudCBo YXMgaW50ZXJtaXR0ZW50IGNvbm5lY3Rpdml0eSBvciBzaW1wbHkNCj5jb25uZWN0aXZpdHkgZm9y IHRoZSBjbGllbnQgaXMgZXhwZW5zaXZlIChlLmcuIGNvc3RzIGEgbG90IG9mIGJhdHRlcnkpLg0K Pk9mIGNvdXJzZSB0aGUgbnVtYmVyIG9mIEFTIGhhcyB0byBiZSBzY2FsZWQgdXAgd2l0aCB0aGUg bnVtYmVyIG9mIFJTLA0KPmJ1dCBJIGRvbid0IHRoaW5rIHRoYXQgaXMgYW55IGRpZmZlcmVudCBm b3Igbm9uLWNvbnN0cmFpbmVkIHNjZW5hcmlvcy4NCg0KTWFkamlkPj5ZZXMsIEludHJvc3BlY3Rp b24sIHNvcnJ5Lg0KWW91IGFyZSBhc3N1bWluZyB0aGF0IEFTIGlzIGluIHRoZSBjbG91ZD8gT3Ig d2l0aGluIHRoZSDigJxsb2NhbOKAnQ0KZW52aXJvbm1lbnQ/IEkgZ3Vlc3MsIGlmIGluIHRoZSBj bG91ZCwgdGhlbiBzY2FsYWJpbGl0eSBzaG91bGQgYmUgbm8NCmlzc3VlLiANCklmIGxvY2FsLCB0 aGVuIHRoZSB2b2x1bWUgc2hvdWxkIGJlIGxvdywgd2hpY2ggYWxzbyBvay4NCkVpdGhlciB3YXks IHRoZSBhc3N1bXB0aW9uIG9mIGludHJvc3BlY3Rpb24gaXMgdGhhdCB0aGUgY29zdCBvZiBzZW5k aW5nIGENCnRva2VuIGJhY2sgdG8gQVMgaXMgbG93ZXIgdGhhbiB2ZXJpZnlpbmcgaXQgbG9jYWxs eS4gVGhlIHF1ZXN0aW9uIGlzIGhvdw0KZG8ga25vdyB0aGUgdmVyaWZpY2F0aW9uIGFjdHVhbGx5 IGNhbWUgZnJvbSBBUz8gQXJlIHlvdSBhc3N1bWluZyBhDQpwZXJzaXN0ZW50IFRMUy8gRFRMUyAo aWYgdGhlcmUgaXMgc3VjaCBhIHRoaW5nKSBjb25uZWN0aW9uIHRvIGF2b2lkDQptZXNzYWdlIGlu dGVncml0eSB2ZXJpZmljYXRpb24gY29zdHM/DQoNCj4NCj5WZXJpZnlpbmcgYSBzZWxmLWNvbnRh aW5lZCB0b2tlbiBjZXJ0YWlubHkgY2FuIGJlIGV4cGVuc2l2ZSwgYnV0IHRoZQ0KPmFsdGVybmF0 aXZlIGlzIHRvIGJlIGNvbm5lY3RlZCB0byB0aGUgbmV0d29yayBpbiBvcmRlciB0byBnZXQgYQ0K PnJlYWwtdGltZSBhY2Nlc3MgY29udHJvbCBkZWNpc2lvbiBmcm9tIGFuIEFTLg0KPg0KPldlIGFz c3VtZSByb3VnaGx5IHRoZSBmb2xsb3dpbmcgImhpZXJhcmNoeSIgb2YgY29zdHMgKGZyb20gbW9z dA0KPmV4cGVuc2l2ZSB0byBsZWFzdCk6DQo+DQo+MS4gTmV0d29yayB0cmFmZmljIChzZW5kaW5n L3JlY2VpdmluZy9saXN0ZW5pbmcgZm9yIGluY29taW5nIG1lc3NhZ2VzKQ0KPjIuIENyeXB0byBv cGVyYXRpb25zDQo+My4gTWF0Y2hpbmcgcmVxdWVzdHMgYWdhaW5zdCBwZXJtaXNzaW9ucyBncmFu dGVkIGJ5IGFjY2VzcyB0b2tlbnMNCg0KDQo+DQo+U2V2ZXJhbCBleHBlcmltZW50cyBJIGNvbmR1 Y3RlZCBoYXZlIHNob3duIHRoYXQgMy4gaXMgYWxtb3N0IG5lZ2xpZ2libGUNCj53aGVuIGNvbXBh cmVkIHRvIHRoZSBjb3N0IG9mIDIuIGFuZCAxLiAgV2hlbiB5b3UgYWRkIHRoZSBvdmVyaGVhZCBv Zg0KPnJ1bm5pbmcgYSBzZWN1cml0eSBwcm90b2NvbCB3aGVuIGRvaW5nIG5ldHdvcmsgY29tbXVu aWNhdGlvbiwgdGhpcyBtYWtlcw0KPmJvdGggMi4gJiAzLiB2ZXJ5IGNoZWFwIGNvbXBhcmVkIHdp dGggMS4NCg0KTWFkamlkPj5JbnRlcmVzdGluZy4gU28gd2hhdCBpcyB0aGUgbWV0cmljIGZvciBj b3N0PyBDUFUgY3ljbGVzPyBUaW1lDQpzcGVudCBpbiBhIHRhc2sgbG9jaz8gV2hhdCBzb3J0IG9m IE9TIHlvdSBoYXZlIGluIG1pbmQ/IE9TIG9yIFJUT1M/DQpJIHdvdWxkIGxvdmUgdG8gc2VlIGFu eSBwYXBlciBvciBpbmZvIG9uIHRoZSBleHBlcmltZW50cyB5b3UgY29uZHVjdGVkLg0KDQoNCj4N Cj4+ICA1LiBXb25kZXIgaWYgdGhlIHR3byBhcHAgbGF5ZXIgc2VjdXJpdHkgc29sdXRpb25zIChP U0NPQVAvIE9TQ09OKSBjb3Zlcg0KPj4gICAgIHRoZSBwcm92aXNpb25pbmcgb2YgdGhlIGtleXMg dGhleSBhcmUgdXNpbmc/DQo+DQo+T1NDT0FQIGFuZCBPU0NPTiBhcmUgYmFzZWQgb24gQ09TRSwg d2hpY2ggaW4gdHVybiBpcyBiYXNlZCBvbiBKT1NFDQo+KEpXRS9KV1MpLiAgSk9TRSBhbmQgQ09T RSBoYXZlIHNvbWUga2V5IHByb3Zpc2lvbmluZyBmdW5jdGlvbmFsaXR5DQo+DQo+DQo+PiAgNi4g SWYgQ09BUCBvcHRpb24gbWF4IGxlbmd0aCBpcyAyNTYgYml0cywgaG93IGNhbiBhIHNpZ25hdHVy ZSBtZWNoYW5pc20NCj4+ICAgICB0aGF0IHJlcXVpcmVzIHRoYXQgbWFueSBiaXRzIGJlIHVzZWQ/ DQo+Pg0KPg0KPkNhcnN0ZW4gaGFzIGFscmVhZHkgYW5zd2VyZWQgdGhhdCBhbmQgSSBhZ3JlZSB3 aXRoIGhpcyBhc3Nlc3NtZW50Lg0KPg0KPg0KPg0KPi0tIA0KPkx1ZHdpZyBTZWl0eiwgUGhEDQo+ U0lDUyBTd2VkaXNoIElDVCBBQg0KPklkZW9uIFNjaWVuY2UgUGFyaw0KPkJ1aWxkaW5nIEJldGEg Mg0KPlNjaGVlbGV2w6RnZW4gMTcNCj5TRS0yMjMgNzAgTHVuZA0KPg0KPlBob25lICs0NigwKTcw LTM0OSA5MiA1MQ0KPmh0dHA6Ly93d3cuc2ljcy5zZQ0KPg0KPl9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+QWNlIG1haWxpbmcgbGlzdA0KPkFjZUBpZXRm Lm9yZw0KPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vYWNlDQoNCg0KKioq KioqKioqKioqKiBFbWFpbCBDb25maWRlbnRpYWxpdHkgTm90aWNlICoqKioqKioqKioqKioqKioq KioqDQpUaGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGluIHRoaXMgZS1tYWlsIG1lc3NhZ2UgKGlu Y2x1ZGluZyBhbnkgDQphdHRhY2htZW50cykgbWF5IGJlIGNvbmZpZGVudGlhbCwgcHJvcHJpZXRh cnksIHByaXZpbGVnZWQsIG9yIG90aGVyd2lzZQ0KZXhlbXB0IGZyb20gZGlzY2xvc3VyZSB1bmRl ciBhcHBsaWNhYmxlIGxhd3MuIEl0IGlzIGludGVuZGVkIHRvIGJlIA0KY29udmV5ZWQgb25seSB0 byB0aGUgZGVzaWduYXRlZCByZWNpcGllbnQocykuIEFueSB1c2UsIGRpc3NlbWluYXRpb24sIA0K ZGlzdHJpYnV0aW9uLCBwcmludGluZywgcmV0YWluaW5nIG9yIGNvcHlpbmcgb2YgdGhpcyBlLW1h aWwgKGluY2x1ZGluZyBpdHMgDQphdHRhY2htZW50cykgYnkgdW5pbnRlbmRlZCByZWNpcGllbnQo cykgaXMgc3RyaWN0bHkgcHJvaGliaXRlZCBhbmQgbWF5IA0KYmUgdW5sYXdmdWwuIElmIHlvdSBh cmUgbm90IGFuIGludGVuZGVkIHJlY2lwaWVudCBvZiB0aGlzIGUtbWFpbCwgb3IgYmVsaWV2ZSAN CnRoYXQgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlLW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3Rp ZnkgdGhlIHNlbmRlciANCmltbWVkaWF0ZWx5IChieSByZXBseWluZyB0byB0aGlzIGUtbWFpbCks IGRlbGV0ZSBhbnkgYW5kIGFsbCBjb3BpZXMgb2YgDQp0aGlzIGUtbWFpbCAoaW5jbHVkaW5nIGFu eSBhdHRhY2htZW50cykgZnJvbSB5b3VyIHN5c3RlbSwgYW5kIGRvIG5vdA0KZGlzY2xvc2UgdGhl IGNvbnRlbnQgb2YgdGhpcyBlLW1haWwgdG8gYW55IG90aGVyIHBlcnNvbi4gVGhhbmsgeW91IQ0K From nobody Fri Oct 30 14:22:55 2015 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A83D1B3BEE for ; Fri, 30 Oct 2015 14:22:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.274 X-Spam-Level: X-Spam-Status: No, score=-1.274 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, MIME_8BIT_HEADER=0.3, T_RP_MATCHES_RCVD=-0.01, UNPARSEABLE_RELAY=0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9wiCHxcIJqL7 for ; Fri, 30 Oct 2015 14:22:15 -0700 (PDT) Received: from mailgw02.mediatek.com (mailgw02.mediatek.com [69.46.227.142]) by ietfa.amsl.com (Postfix) with ESMTP id 46D261B3BEA for ; Fri, 30 Oct 2015 14:22:14 -0700 (PDT) X-Listener-Flag: 11101 Received: from mtkcas64.mediatek.inc [(172.29.17.144)] by mailgw02.mediatek.com (envelope-from ) (Cellopoint E-mail Firewall v3.9.12 Build 0312 with TLS) with ESMTP id 1279057443; Fri, 30 Oct 2015 17:12:28 -0500 Received: from MTKCAS63.mediatek.inc (172.29.17.143) by MTKCAS64.mediatek.inc (172.29.17.144) with Microsoft SMTP Server (TLS) id 14.3.181.6; Fri, 30 Oct 2015 17:22:12 -0400 Received: from MTKMBS61N1.mediatek.inc ([fe80::2898:86df:e627:42ee]) by MTKCAS63.mediatek.inc ([fe80::69ba:ee95:46f7:711d%10]) with mapi id 14.03.0181.006; Fri, 30 Oct 2015 17:22:12 -0400 From: Madjid Nakhjiri To: =?utf-8?B?RXJpayBXYWhsc3Ryw7ZtIG5lWHVz?= , Ludwig Seitz Thread-Topic: [Ace] comments on draft-seitz-ace-oauth-authz-00 Thread-Index: AQHREeZtLoYHI1sV0UKYlZCdCQHqy56CfAmAgADLKgCAARTIAA== Date: Fri, 30 Oct 2015 21:22:11 +0000 Message-ID: In-Reply-To: <1F59D107-A0B7-410D-A246-D1C98884A9E3@nexusgroup.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.29.122.58] Content-Type: multipart/alternative; boundary="_000_D2592D7C6BD4madjidnakhjirimediatekcom_" MIME-Version: 1.0 X-TM-AS-Product-Ver: SMEX-10.2.0.3176-8.000.1202-21912.002 X-TM-AS-Result: No--21.190100-8.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No Archived-At: Cc: "ace@ietf.org" Subject: Re: [Ace] comments on draft-seitz-ace-oauth-authz-00 X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 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, 30 Oct 2015 21:22:18 -0000 --_000_D2592D7C6BD4madjidnakhjirimediatekcom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhhbmtzIEVyaWsuDQoNCkkgd2lsbCB0aHJvdyB0aGVzZSBvdmVyIG9uIHRoZSB0by1yZWFkIHBp bGU6KQ0KDQpSZWdhcmRzLA0KTWFkamlkIE5ha2hqaXJpDQrpuqblv5flvpcNClByaW5jaXBhbCBT ZWN1cml0eSBBcmNoaXRlY3QNCk1lZGlhVGVrIEluYy4NCuKAnFNpbXBsaWNpdHkgaXMgdGhlIHVs dGltYXRlIHNvcGhpc3RpY2F0aW9uIg0KDQpGcm9tOiBFcmlrIFdhaGxzdHLDtm0gbmVYdXMgPGVy aWsud2FobHN0cm9tQG5leHVzZ3JvdXAuY29tPG1haWx0bzplcmlrLndhaGxzdHJvbUBuZXh1c2dy b3VwLmNvbT4+DQpEYXRlOiBUaHUsIDI5IE9jdCAyMDE1IDIxOjUxOjMyICswMDAwDQpUbzogTHVk d2lnIFNlaXR6IDxsdWR3aWdAc2ljcy5zZTxtYWlsdG86bHVkd2lnQHNpY3Muc2U+Pg0KQ2M6ICJh Y2VAaWV0Zi5vcmc8bWFpbHRvOmFjZUBpZXRmLm9yZz4iIDxhY2VAaWV0Zi5vcmc8bWFpbHRvOmFj ZUBpZXRmLm9yZz4+DQpTdWJqZWN0OiBSZTogW0FjZV0gY29tbWVudHMgb24gZHJhZnQtc2VpdHot YWNlLW9hdXRoLWF1dGh6LTAwDQoNClRoZSBnb29kIHRoaW5nIGFib3V0IGJ1aWxkaW5nIHdpdGgg ZXhpc3RpbmcgcHJvdG9jb2xzIGlzIHRoYXQgcHJvYmxlbXMgbGlrZSB0aGlzIGhhdmUgYWxyZWFk eSBiZWVuIHRob3VnaHQgb2YsIGltcGxlbWVudGVkIGFuZCBzb2x2ZWQgOikNCg0KLSBSRkM3NTkx IGlzIHRoZSAiT0F1dGggMi4wIER5bmFtaWMgQ2xpZW50IFJlZ2lzdHJhdGlvbiBQcm90b2NvbOKA nSB0aGF0IGRlc2NyaWJlcyBob3cgdG8gYmluZCBuZXcgY2xpZW50cyB0byBhbnkgQVMuIFRoYXQg Y291bGQgYmUgcHJvZmlsZWQgZm9yIENvQVAgYW5kIENCT1IgaW4gdGhlIHNhbWUgd2F5IGFzIHRo ZSBPQXV0aDIgZm9yIElvVCBkcmFmdHMgZG9lcy4NCi0gVGhlcmUgaXMgYWxzbyB0aGUgIk9BdXRo IDIuMCBSZXNvdXJjZSBTZXQgUmVnaXN0cmF0aW9u4oCdIHdvcmsgKGh0dHBzOi8vdG9vbHMuaWV0 Zi5vcmcvaHRtbC9kcmFmdC1oYXJkam9uby1vYXV0aC1yZXNvdXJjZS1yZWctMDYpIGluIHRoZSBv YXV0aCB3ZyB0aGF0IGdpdmVzIHRoZSBSUyBhIHdheSB0byBiaW5kIGl0IHNlbGYgdG8gYW4gQVMg ZHluYW1pY2FsbHkgYW5kIHRlbGxpbmcgaXQgZXhhY3RseSB3aGF0IGl0IHNob3VsZCBwcm90ZWN0 LiBUaGF0IHRvbyBjb3VsZCBiZSBwcm9maWxlZCBpZiBuZWVkZWQuDQotIFVNQSwgYnVpbGRzIG9u IHRvcCBvZiBPQXV0aDIsIGFsc28gaW50cm9kdWNlZCB0aGUgY2xhaW1zIGdhdGhlcmluZyBmbG93 cyB0aGF0IGxldHMgYW4gdXNlci9kZXZpY2UgYXV0aGVudGljYXRlIGl0IHNlbGYgdXNpbmcgYW55 IHR5cGUgb2YgY2xhaW1zL2F0dHJpYnV0ZXMvbWV0aG9kcyBhbmQgaXQgbGV0cyB0aGUgc3lzdGVt IGRpc2NvdmVyIHRoZSBwcm9wZXIgd2F5IGR5bmFtaWNhbGx5Lg0KDQpUaGVyZSBhcmUgc29tZSBn b29kIHBpZWNlcyBvdXQgdGhlcmUgdG8gZ2V0IGF1dGhlbnRpY2F0aW9uIGFuZCBhdXRob3JpemF0 aW9uIGZsb3dzIHdvcmtpbmcgaW4gYSBkeW5hbWljIGFuZCBkaXNwZXJzZSBjb25uZWN0ZWQgd29y bGQgYWxyZWFkeS4NCg0KLyBFcmlrDQoNCg0KT24gMjkgT2N0IDIwMTUsIGF0IDEwOjQ0LCBMdWR3 aWcgU2VpdHogPGx1ZHdpZ0BzaWNzLnNlPG1haWx0bzpsdWR3aWdAc2ljcy5zZT4+IHdyb3RlOg0K DQpIZWxsbyBNYWRqaWQsDQoNClRoYW5rIHlvdSBmb3IgcHJvdmlkaW5nIHlvdXIgY29tbWVudHMg b24gb3VyIGRyYWZ0ISBBbnN3ZXJzIGFyZSBpbmxpbmUuDQoNCi9MdWR3aWcNCg0KT24gMjAxNS0x MC0yOSAwMjowOSwgTWFkamlkIE5ha2hqaXJpIHdyb3RlOg0KWy4uLl0NCjEuIHByb3Zpc2lvbmlu ZyBvZiBjbGllbnQga2V5cyBmb3IgYXV0aGVudGljYXRpb24gYW5kIHJlZ2lzdHJhdGlvbiB3aXRo DQogICB0aGUgQVMuIEhhdmluZyBhIGdsb2JhbCBrZXkvSUQgaW4gdGhlIGNsaWVudCBoYXMgYmVl biBhbiBpc3N1ZSBmb3INCiAgIHNvbWUgT0FVVEggaW1wbGVtZW50YXRpb25zIGluIHRoZSBwYXN0 LiBHaXZlbiB0aGF0IHRoZSBjbGllbnRzIGFyZQ0KICAgSW9UIGRldmljZXMsIHRoaXMgaXMgbm90 IGFzIHN0cmFpZ2h0IGZvcndhcmQgYXMgbW9iaWxlIGFwcCBjbGllbnRzLg0KDQpJZiBJIHVuZGVy c3RhbmQgeW91IGNvcnJlY3RseSB0aGUgcHJvYmxlbSBpcyBhYm91dCBoYXZpbmcgZ2xvYmFsIElE cyB0aGF0IGNsaWVudHMgYW5kIEFTIGNhbiB1c2UgdG8gcmVmZXJlbmNlIGtleXMuDQoNCkkgZXhw ZWN0IHRoYXQgaW4gbWFueSBjYXNlcyB0aGUgY2xpZW50cyB3aWxsIG9ubHkgYmUgc2VydmVkIGJ5 IGEgc2luZ2xlIEFTIChvciBhIGZldyBvbmVzIGF0IG1vc3QpLCB3aGljaCBtZWFucyB0aGF0IHRo ZSBrZXkgbWFuYWdlbWVudCBwcm9ibGVtIG9uIHRoYXQgc2lkZSBpcyBsZXNzIGRpZmZpY3VsdC4N Cg0KU2luY2UgdGhlIEFTIHdpbGwgcHJvYmFibHkgbWFuYWdlIGtleXMgZm9yIG1hbnkgY2xpZW50 cywgdGhlIElEcyBuZWVkIHRvIGJlIHVuaXF1ZSBhdCBsZWFzdCBwZXIgQVMuIFRoZXJlZm9yZSBk ZWZpbmluZyBhIG5hbWVzcGFjZSB0aGF0IGlzIHVuaXF1ZSBmb3IgYSBzcGVjaWZpYyBBUyBhbmQg cHJlZml4aW5nIHRoZSBrZXkgSUQgd2l0aCB0aGF0IG5hbWVzcGFjZSBzaG91bGQgd29yayB0b3dh cmRzIHNvbHZpbmcgdGhhdCBwcm9ibGVtLg0KDQpZb3Ugc2VlbSB0byBoYXZlIGV4cGVyaWVuY2Ug d2l0aCBzcGVjaWZpYyBpc3N1ZXMgaW4gdGhhdCBtYXR0ZXIsIGNvdWxkIHlvdSBkZXNjcmliZSB0 aG9zZSBpc3N1ZXMgaW4gbW9yZSBkZXRhaWw/DQoNCk5PVEU6IEFDRSBpcyBleHBsaWNpdGx5IG5v dCBjaGFydGVyZWQgdG8gd29yayB3aXRoIGtleSBtYW5hZ2VtZW50IGFuZCB0aGUgd29yZCBoYXMg YmVlbiBzaHVubmVkIGZyb20gYW55IGRvY3VtZW50LCB0aGVyZWZvcmUgSSBkbyBub3QgZXhwZWN0 IHRoYXQgQUNFIHdpbGwgd29yayBvbiB0aGF0IGlzc3VlLg0KDQoNCjIuIFNhbWUgdGhpbmcgZm9y IFJTIHRvIEFTIHJlZ2lzdHJhdGlvbi4gUlMgaXMgbWFueSB0aW1lcyBhIGNvbnN0cmFpbmVkDQog ICBkZXZpY2UgaXRzZWxmLiBBbHNvIEkgYW0gbm90IGNsZWFyIGhvdyB0aGUgQVMgd2lsbCBnZXQg dGhlDQogICBhdXRob3JpemF0aW9uIHBvbGljaWVzIChzY29wZS9jbGFpbT8pIGZyb20gUlMuIElz IGl0IHRoYXQgaXQgaXMgdGhlDQogICBBUyB0aGF0IGRlY2lkZXM/Pw0KDQoNCkFjdHVhbGx5IGl0 IHdhcyBuZXZlciBwbGFubmVkIHRoYXQgdGhlIGl0c2VsZiBSUyBzaG91bGQgcHJvdmlkZSBhbmQg bWFuYWdlIHRoZSBhdXRob3JpemF0aW9uIHBvbGljaWVzIGF0IHRoZSBBUy4gVGhlIHJlc291cmNl IG93bmVycyBhcmUgZXhwZWN0ZWQgdG8gZG8gdGhpcyBhdCB0aGUgQVMgZGlyZWN0bHksIHdoZW4g dGhleSBlbnJvbGwgYSBSUyB0aGV5IG93bi4NCg0KMy4gSXMgYXV0aG9yaXphdGlvbiBzdWJqZWN0 IGJhc2VkIChpZGVudGl0eSBvZiBjbGllbnQpIG9yIHJvbGUgYmFzZWQ/DQoNClRoZSBzb2x1dGlv biBzaG91bGQgd29yayB3aXRoIGJvdGggYXBwcm9hY2hlcy4gVGhlIGNsaWVudCBpcyBleHBlY3Rl ZCB0byBwcmVzZW50IGNyZWRlbnRpYWxzIHRvIHRoZSBBUyB3aGVuIHJlcXVlc3RpbmcgYSB0b2tl bi4gVGhlc2UgY3JlZGVudGlhbHMgY2FuIHRoZW4gYmUgcmVzb2x2ZWQgdG8gYW4gaWRlbnRpdHks IG9yIGEgcm9sZSwgb3Igc29tZSBzZWN1cml0eSBhdHRyaWJ1dGVzIG9mIHRoZSBjbGllbnQuIFRo ZSBBUyBpcyB0aGVuIGV4cGVjdGVkIHRvIG1ha2UgYW4gYXV0aG9yaXphdGlvbiBkZWNpc2lvbiBi YXNlZCBvbiB0aGUgY3JlZGVudGlhbHMgYW5kIHRoZSBleGlzdGluZyBhdXRob3JpemF0aW9uIHBv bGljaWVzLg0KDQoNCjQuIFJlc3Ryb3NwZWN0aW9uIG9mIHRoZSB0b2tlbnMgY2FuIGJlIGV4cGVu c2l2ZSBhbmQgdW5zY2FsYWJsZSBmb3IgdGhlDQogICBBUyAoaWYgdGhlcmUgYXJlIG1hbnkgUlMg bm9kZXMpLCBidXQgdmVyaWZpY2F0aW9uIG9mIHNlbGYtY29udGFpbmVkDQogICB0b2tlbnMgYnkg dGhlIFJTIGFsc28gc291bmRzIGV4cGVuc2l2ZSwgcGx1cyB0aGUgdmVyaWZpY2F0aW9uIGtleXMN CiAgIG5lZWQgdG8gYmUgcHJvdmlzaW9uZWQgaW4gdGhlIFJTLiBXb3VsZCBiZSBuaWNlIHRvIGhh dmUgZ3VpZGFuY2Ugb24NCiAgIHdoaWNoIG1ha2VzIHNlbnNlIHRha2luZyBkZXZpY2UgY2FwYWJp bGl0aWVzL2NsYXNzIGludG8gYWNjb3VudC4gQW55DQogICBuZXR3b3JrIHNpbXVsYXRvcnMgb3V0 IHRoZXJlPw0KDQpJJ20gZ3Vlc3NpbmcgeW91IG1lYW50IEludHJvc3BlY3Rpb24gaGVyZSByaWdo dD8NCg0KVGhlIEFTIGlzIG5vdCBleHBlY3RlZCB0byBiZSBhIGNvbnN0cmFpbmVkIGRldmljZSwg dGh1cyBpdCBzaG91bGQgYmUgYWJsZSB0byBzZXJ2ZSBhIHNpZ25pZmljYW50IG51bWJlciBvZiBp bnRyb3NwZWN0aW9uIHJlcXVlc3RzIGZyb20gZGlmZmVyZW50IFJTLiBJbnRyb3NwZWN0aW9uIHdv cmtzIGJlc3QgaWYgdGhlIFJTIGhhcyBhIGdvb2QgY29ubmVjdGl2aXR5IHRvIHRoZSBBUyB3aGls ZSB0aGUgY2xpZW50IGhhcyBpbnRlcm1pdHRlbnQgY29ubmVjdGl2aXR5IG9yIHNpbXBseSBjb25u ZWN0aXZpdHkgZm9yIHRoZSBjbGllbnQgaXMgZXhwZW5zaXZlIChlLmcuIGNvc3RzIGEgbG90IG9m IGJhdHRlcnkpLg0KT2YgY291cnNlIHRoZSBudW1iZXIgb2YgQVMgaGFzIHRvIGJlIHNjYWxlZCB1 cCB3aXRoIHRoZSBudW1iZXIgb2YgUlMsIGJ1dCBJIGRvbid0IHRoaW5rIHRoYXQgaXMgYW55IGRp ZmZlcmVudCBmb3Igbm9uLWNvbnN0cmFpbmVkIHNjZW5hcmlvcy4NCg0KVmVyaWZ5aW5nIGEgc2Vs Zi1jb250YWluZWQgdG9rZW4gY2VydGFpbmx5IGNhbiBiZSBleHBlbnNpdmUsIGJ1dCB0aGUgYWx0 ZXJuYXRpdmUgaXMgdG8gYmUgY29ubmVjdGVkIHRvIHRoZSBuZXR3b3JrIGluIG9yZGVyIHRvIGdl dCBhIHJlYWwtdGltZSBhY2Nlc3MgY29udHJvbCBkZWNpc2lvbiBmcm9tIGFuIEFTLg0KDQpXZSBh c3N1bWUgcm91Z2hseSB0aGUgZm9sbG93aW5nICJoaWVyYXJjaHkiIG9mIGNvc3RzIChmcm9tIG1v c3QgZXhwZW5zaXZlIHRvIGxlYXN0KToNCg0KMS4gTmV0d29yayB0cmFmZmljIChzZW5kaW5nL3Jl Y2VpdmluZy9saXN0ZW5pbmcgZm9yIGluY29taW5nIG1lc3NhZ2VzKQ0KMi4gQ3J5cHRvIG9wZXJh dGlvbnMNCjMuIE1hdGNoaW5nIHJlcXVlc3RzIGFnYWluc3QgcGVybWlzc2lvbnMgZ3JhbnRlZCBi eSBhY2Nlc3MgdG9rZW5zDQoNClNldmVyYWwgZXhwZXJpbWVudHMgSSBjb25kdWN0ZWQgaGF2ZSBz aG93biB0aGF0IDMuIGlzIGFsbW9zdCBuZWdsaWdpYmxlIHdoZW4gY29tcGFyZWQgdG8gdGhlIGNv c3Qgb2YgMi4gYW5kIDEuICBXaGVuIHlvdSBhZGQgdGhlIG92ZXJoZWFkIG9mIHJ1bm5pbmcgYSBz ZWN1cml0eSBwcm90b2NvbCB3aGVuIGRvaW5nIG5ldHdvcmsgY29tbXVuaWNhdGlvbiwgdGhpcyBt YWtlcyBib3RoIDIuICYgMy4gdmVyeSBjaGVhcCBjb21wYXJlZCB3aXRoIDEuDQoNCjUuIFdvbmRl ciBpZiB0aGUgdHdvIGFwcCBsYXllciBzZWN1cml0eSBzb2x1dGlvbnMgKE9TQ09BUC8gT1NDT04p IGNvdmVyDQogICB0aGUgcHJvdmlzaW9uaW5nIG9mIHRoZSBrZXlzIHRoZXkgYXJlIHVzaW5nPw0K DQpPU0NPQVAgYW5kIE9TQ09OIGFyZSBiYXNlZCBvbiBDT1NFLCB3aGljaCBpbiB0dXJuIGlzIGJh c2VkIG9uIEpPU0UgKEpXRS9KV1MpLiAgSk9TRSBhbmQgQ09TRSBoYXZlIHNvbWUga2V5IHByb3Zp c2lvbmluZyBmdW5jdGlvbmFsaXR5DQoNCg0KNi4gSWYgQ09BUCBvcHRpb24gbWF4IGxlbmd0aCBp cyAyNTYgYml0cywgaG93IGNhbiBhIHNpZ25hdHVyZSBtZWNoYW5pc20NCiAgIHRoYXQgcmVxdWly ZXMgdGhhdCBtYW55IGJpdHMgYmUgdXNlZD8NCg0KDQpDYXJzdGVuIGhhcyBhbHJlYWR5IGFuc3dl cmVkIHRoYXQgYW5kIEkgYWdyZWUgd2l0aCBoaXMgYXNzZXNzbWVudC4NCg0KDQoNCi0tDQpMdWR3 aWcgU2VpdHosIFBoRA0KU0lDUyBTd2VkaXNoIElDVCBBQg0KSWRlb24gU2NpZW5jZSBQYXJrDQpC dWlsZGluZyBCZXRhIDINClNjaGVlbGV2w6RnZW4gMTcNClNFLTIyMyA3MCBMdW5kDQoNClBob25l ICs0NigwKTcwLTM0OSA5MiA1MQ0KaHR0cDovL3d3dy5zaWNzLnNlDQoNCl9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpBY2UgbWFpbGluZyBsaXN0DQpBY2VA aWV0Zi5vcmc8bWFpbHRvOkFjZUBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vYWNlDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fIEFjZSBtYWlsaW5nIGxpc3QgQWNlQGlldGYub3JnPG1haWx0bzpBY2VAaWV0Zi5v cmc+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vYWNlDQo= --_000_D2592D7C6BD4madjidnakhjirimediatekcom_ Content-Type: text/html; charset="utf-8" Content-ID: <509BEB31B33A2B448DEE45A8824D578A@mediatek.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx NHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KPGRpdj4NCjxkaXY+DQo8 ZGl2PlRoYW5rcyBFcmlrLiZuYnNwOzwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+SSB3 aWxsIHRocm93IHRoZXNlIG92ZXIgb24gdGhlIHRvLXJlYWQgcGlsZTopPC9kaXY+DQo8ZGl2Pjxi cj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+UmVnYXJkcyw8L2Rpdj4NCjxkaXY+PGI+TWFkamlkIE5h a2hqaXJpPC9iPjwvZGl2Pg0KPGRpdj48c3BhbiBzdHlsZT0ibGluZS1oZWlnaHQ6IDExLjE5OTk5 OTgwOTI2NTEzN3B4OyB0ZXh0LWluZGVudDogMGluOyBsZXR0ZXItc3BhY2luZzogLTEuNXB0OyI+ 6bqm5b+X5b6XJm5ic3A7PC9zcGFuPjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDEwcHQ7 IGZvbnQtZmFtaWx5OiBDYWxpYnJpOyBjb2xvcjogcmdiKDQwLCA0MSwgMzYpOyI+UHJpbmNpcGFs IFNlY3VyaXR5IEFyY2hpdGVjdCZuYnNwOzwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyI+PGI+PHU+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZTogMTBwdDsgZm9udC1mYW1pbHk6IENhbGlicmk7IGNvbG9yOiByZ2IoMjM4LCAxMzYs IDI1KTsiPk1lZGlhPC9zcGFuPjwvdT48L2I+PGI+PHU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTog MTBwdDsgZm9udC1mYW1pbHk6IENhbGlicmk7IGNvbG9yOiByZ2IoMjM4LCAxMzYsIDI1KTsiPlQ8 L3NwYW4+PC91PjwvYj48Yj48dT48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMHB0OyBmb250LWZh bWlseTogQ2FsaWJyaTsgY29sb3I6IHJnYigyMzgsIDEzNiwgMjUpOyI+ZWsNCiBJbmMuPG86cD48 L286cD48L3NwYW4+PC91PjwvYj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFy Z2luOiAwaW4gMGluIDAuMDAwMXB0OyI+PGZvbnQgZmFjZT0iQ2FtYnJpYSI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZTogMTJweDsiPuKAnFNpbXBsaWNpdHkgaXMgdGhlIHVsdGltYXRlIHNvcGhpc3Rp Y2F0aW9uJnF1b3Q7PC9zcGFuPjwvZm9udD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 ZGl2Pjxicj4NCjwvZGl2Pg0KPHNwYW4gaWQ9Ik9MS19TUkNfQk9EWV9TRUNUSU9OIj4NCjxkaXYg c3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmk7IGZvbnQtc2l6ZToxMXB0OyB0ZXh0LWFsaWduOmxl ZnQ7IGNvbG9yOmJsYWNrOyBCT1JERVItQk9UVE9NOiBtZWRpdW0gbm9uZTsgQk9SREVSLUxFRlQ6 IG1lZGl1bSBub25lOyBQQURESU5HLUJPVFRPTTogMGluOyBQQURESU5HLUxFRlQ6IDBpbjsgUEFE RElORy1SSUdIVDogMGluOyBCT1JERVItVE9QOiAjYjVjNGRmIDFwdCBzb2xpZDsgQk9SREVSLVJJ R0hUOiBtZWRpdW0gbm9uZTsgUEFERElORy1UT1A6IDNwdCI+DQo8c3BhbiBzdHlsZT0iZm9udC13 ZWlnaHQ6Ym9sZCI+RnJvbTogPC9zcGFuPkVyaWsgV2FobHN0csO2bSBuZVh1cyAmbHQ7PGEgaHJl Zj0ibWFpbHRvOmVyaWsud2FobHN0cm9tQG5leHVzZ3JvdXAuY29tIj5lcmlrLndhaGxzdHJvbUBu ZXh1c2dyb3VwLmNvbTwvYT4mZ3Q7PGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQi PkRhdGU6IDwvc3Bhbj5UaHUsIDI5IE9jdCAyMDE1IDIxOjUxOjMyICYjNDM7MDAwMDxicj4NCjxz cGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5UbzogPC9zcGFuPkx1ZHdpZyBTZWl0eiAmbHQ7 PGEgaHJlZj0ibWFpbHRvOmx1ZHdpZ0BzaWNzLnNlIj5sdWR3aWdAc2ljcy5zZTwvYT4mZ3Q7PGJy Pg0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPkNjOiA8L3NwYW4+JnF1b3Q7PGEgaHJl Zj0ibWFpbHRvOmFjZUBpZXRmLm9yZyI+YWNlQGlldGYub3JnPC9hPiZxdW90OyAmbHQ7PGEgaHJl Zj0ibWFpbHRvOmFjZUBpZXRmLm9yZyI+YWNlQGlldGYub3JnPC9hPiZndDs8YnI+DQo8c3BhbiBz dHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+U3ViamVjdDogPC9zcGFuPlJlOiBbQWNlXSBjb21tZW50 cyBvbiBkcmFmdC1zZWl0ei1hY2Utb2F1dGgtYXV0aHotMDA8YnI+DQo8L2Rpdj4NCjxkaXY+PGJy Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0id29yZC13cmFwOiBicmVhay13b3JkOyAtd2Vi a2l0LW5ic3AtbW9kZTogc3BhY2U7IC13ZWJraXQtbGluZS1icmVhazogYWZ0ZXItd2hpdGUtc3Bh Y2U7IiBjbGFzcz0iIj4NClRoZSBnb29kIHRoaW5nIGFib3V0IGJ1aWxkaW5nIHdpdGggZXhpc3Rp bmcgcHJvdG9jb2xzIGlzIHRoYXQgcHJvYmxlbXMgbGlrZSB0aGlzIGhhdmUgYWxyZWFkeSBiZWVu IHRob3VnaHQgb2YsIGltcGxlbWVudGVkIGFuZCBzb2x2ZWQgOikNCjxkaXYgY2xhc3M9IiI+PGJy IGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPi0gUkZDNzU5MSBpcyB0aGUgJnF1b3Q7 T0F1dGggMi4wIER5bmFtaWMgQ2xpZW50IFJlZ2lzdHJhdGlvbiBQcm90b2NvbOKAnSB0aGF0IGRl c2NyaWJlcyBob3cgdG8gYmluZCBuZXcgY2xpZW50cyB0byBhbnkgQVMuIFRoYXQgY291bGQgYmUg cHJvZmlsZWQgZm9yIENvQVAgYW5kIENCT1IgaW4gdGhlIHNhbWUgd2F5IGFzIHRoZSBPQXV0aDIg Zm9yIElvVCBkcmFmdHMgZG9lcy48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+LSBUaGVyZSBpcyBhbHNv IHRoZSAmcXVvdDtPQXV0aCAyLjAgUmVzb3VyY2UgU2V0IFJlZ2lzdHJhdGlvbuKAnSB3b3JrICg8 YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaGFyZGpvbm8tb2F1dGgt cmVzb3VyY2UtcmVnLTA2IiBjbGFzcz0iIj5odHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJh ZnQtaGFyZGpvbm8tb2F1dGgtcmVzb3VyY2UtcmVnLTA2PC9hPikmbmJzcDtpbiB0aGUgb2F1dGgg d2cgdGhhdCBnaXZlcw0KIHRoZSBSUyBhIHdheSB0byBiaW5kIGl0IHNlbGYgdG8gYW4gQVMgZHlu YW1pY2FsbHkgYW5kIHRlbGxpbmcgaXQgZXhhY3RseSB3aGF0IGl0IHNob3VsZCBwcm90ZWN0LiZu YnNwO1RoYXQgdG9vIGNvdWxkIGJlIHByb2ZpbGVkIGlmIG5lZWRlZC48L2Rpdj4NCjxkaXYgY2xh c3M9IiI+LSBVTUEsIGJ1aWxkcyBvbiB0b3Agb2YgT0F1dGgyLCBhbHNvIGludHJvZHVjZWQgdGhl IGNsYWltcyBnYXRoZXJpbmcgZmxvd3MgdGhhdCBsZXRzIGFuIHVzZXIvZGV2aWNlIGF1dGhlbnRp Y2F0ZSBpdCBzZWxmIHVzaW5nIGFueSB0eXBlIG9mIGNsYWltcy9hdHRyaWJ1dGVzL21ldGhvZHMg YW5kIGl0IGxldHMgdGhlIHN5c3RlbSBkaXNjb3ZlciB0aGUgcHJvcGVyIHdheSBkeW5hbWljYWxs eS48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNz PSIiPlRoZXJlIGFyZSBzb21lIGdvb2QgcGllY2VzIG91dCB0aGVyZSB0byBnZXQgYXV0aGVudGlj YXRpb24gYW5kIGF1dGhvcml6YXRpb24gZmxvd3Mgd29ya2luZyBpbiBhIGR5bmFtaWMgYW5kJm5i c3A7ZGlzcGVyc2UgY29ubmVjdGVkIHdvcmxkIGFscmVhZHkuPC9kaXY+DQo8ZGl2IGNsYXNzPSIi PjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4vIEVyaWs8L2Rpdj4NCjxkaXYg Y2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8ZGl2 Pg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPk9uIDI5 IE9jdCAyMDE1LCBhdCAxMDo0NCwgTHVkd2lnIFNlaXR6ICZsdDs8YSBocmVmPSJtYWlsdG86bHVk d2lnQHNpY3Muc2UiIGNsYXNzPSIiPmx1ZHdpZ0BzaWNzLnNlPC9hPiZndDsgd3JvdGU6PC9kaXY+ DQo8YnIgY2xhc3M9IkFwcGxlLWludGVyY2hhbmdlLW5ld2xpbmUiPg0KPGRpdiBjbGFzcz0iIj5I ZWxsbyBNYWRqaWQsPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KVGhhbmsgeW91IGZvciBw cm92aWRpbmcgeW91ciBjb21tZW50cyBvbiBvdXIgZHJhZnQhIEFuc3dlcnMgYXJlIGlubGluZS48 YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQovTHVkd2lnPGJyIGNsYXNzPSIiPg0KPGJyIGNs YXNzPSIiPg0KT24gMjAxNS0xMC0yOSAwMjowOSwgTWFkamlkIE5ha2hqaXJpIHdyb3RlOjxiciBj bGFzcz0iIj4NClsuLi5dPGJyIGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xh c3M9IiI+MS4gcHJvdmlzaW9uaW5nIG9mIGNsaWVudCBrZXlzIGZvciBhdXRoZW50aWNhdGlvbiBh bmQgcmVnaXN0cmF0aW9uIHdpdGg8YnIgY2xhc3M9IiI+DQombmJzcDsmbmJzcDsmbmJzcDt0aGUg QVMuIEhhdmluZyBhIGdsb2JhbCBrZXkvSUQgaW4gdGhlIGNsaWVudCBoYXMgYmVlbiBhbiBpc3N1 ZSBmb3I8YnIgY2xhc3M9IiI+DQombmJzcDsmbmJzcDsmbmJzcDtzb21lIE9BVVRIIGltcGxlbWVu dGF0aW9ucyBpbiB0aGUgcGFzdC4gR2l2ZW4gdGhhdCB0aGUgY2xpZW50cyBhcmU8YnIgY2xhc3M9 IiI+DQombmJzcDsmbmJzcDsmbmJzcDtJb1QgZGV2aWNlcywgdGhpcyBpcyBub3QgYXMgc3RyYWln aHQgZm9yd2FyZCBhcyBtb2JpbGUgYXBwIGNsaWVudHMuPGJyIGNsYXNzPSIiPg0KPC9ibG9ja3F1 b3RlPg0KPGJyIGNsYXNzPSIiPg0KSWYgSSB1bmRlcnN0YW5kIHlvdSBjb3JyZWN0bHkgdGhlIHBy b2JsZW0gaXMgYWJvdXQgaGF2aW5nIGdsb2JhbCBJRHMgdGhhdCBjbGllbnRzIGFuZCBBUyBjYW4g dXNlIHRvIHJlZmVyZW5jZSBrZXlzLjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCkkgZXhw ZWN0IHRoYXQgaW4gbWFueSBjYXNlcyB0aGUgY2xpZW50cyB3aWxsIG9ubHkgYmUgc2VydmVkIGJ5 IGEgc2luZ2xlIEFTIChvciBhIGZldyBvbmVzIGF0IG1vc3QpLCB3aGljaCBtZWFucyB0aGF0IHRo ZSBrZXkgbWFuYWdlbWVudCBwcm9ibGVtIG9uIHRoYXQgc2lkZSBpcyBsZXNzIGRpZmZpY3VsdC48 YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpTaW5jZSB0aGUgQVMgd2lsbCBwcm9iYWJseSBt YW5hZ2Uga2V5cyBmb3IgbWFueSBjbGllbnRzLCB0aGUgSURzIG5lZWQgdG8gYmUgdW5pcXVlIGF0 IGxlYXN0IHBlciBBUy4gVGhlcmVmb3JlIGRlZmluaW5nIGEgbmFtZXNwYWNlIHRoYXQgaXMgdW5p cXVlIGZvciBhIHNwZWNpZmljIEFTIGFuZCBwcmVmaXhpbmcgdGhlIGtleSBJRCB3aXRoIHRoYXQg bmFtZXNwYWNlIHNob3VsZCB3b3JrIHRvd2FyZHMgc29sdmluZyB0aGF0IHByb2JsZW0uPGJyIGNs YXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KWW91IHNlZW0gdG8gaGF2ZSBleHBlcmllbmNlIHdpdGgg c3BlY2lmaWMgaXNzdWVzIGluIHRoYXQgbWF0dGVyLCBjb3VsZCB5b3UgZGVzY3JpYmUgdGhvc2Ug aXNzdWVzIGluIG1vcmUgZGV0YWlsPzxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCk5PVEU6 IEFDRSBpcyBleHBsaWNpdGx5IG5vdCBjaGFydGVyZWQgdG8gd29yayB3aXRoIGtleSBtYW5hZ2Vt ZW50IGFuZCB0aGUgd29yZCBoYXMgYmVlbiBzaHVubmVkIGZyb20gYW55IGRvY3VtZW50LCB0aGVy ZWZvcmUgSSBkbyBub3QgZXhwZWN0IHRoYXQgQUNFIHdpbGwgd29yayBvbiB0aGF0IGlzc3VlLjxi ciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCjxibG9ja3F1b3RlIHR5 cGU9ImNpdGUiIGNsYXNzPSIiPjIuIFNhbWUgdGhpbmcgZm9yIFJTIHRvIEFTIHJlZ2lzdHJhdGlv bi4gUlMgaXMgbWFueSB0aW1lcyBhIGNvbnN0cmFpbmVkPGJyIGNsYXNzPSIiPg0KJm5ic3A7Jm5i c3A7Jm5ic3A7ZGV2aWNlIGl0c2VsZi4gQWxzbyBJIGFtIG5vdCBjbGVhciBob3cgdGhlIEFTIHdp bGwgZ2V0IHRoZTxiciBjbGFzcz0iIj4NCiZuYnNwOyZuYnNwOyZuYnNwO2F1dGhvcml6YXRpb24g cG9saWNpZXMgKHNjb3BlL2NsYWltPykgZnJvbSBSUy4gSXMgaXQgdGhhdCBpdCBpcyB0aGU8YnIg Y2xhc3M9IiI+DQombmJzcDsmbmJzcDsmbmJzcDtBUyB0aGF0IGRlY2lkZXM/PzxiciBjbGFzcz0i Ij4NCjwvYmxvY2txdW90ZT4NCjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCkFjdHVhbGx5 IGl0IHdhcyBuZXZlciBwbGFubmVkIHRoYXQgdGhlIGl0c2VsZiBSUyBzaG91bGQgcHJvdmlkZSBh bmQgbWFuYWdlIHRoZSBhdXRob3JpemF0aW9uIHBvbGljaWVzIGF0IHRoZSBBUy4gVGhlIHJlc291 cmNlIG93bmVycyBhcmUgZXhwZWN0ZWQgdG8gZG8gdGhpcyBhdCB0aGUgQVMgZGlyZWN0bHksIHdo ZW4gdGhleSBlbnJvbGwgYSBSUyB0aGV5IG93bi48YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+ DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj4zLiBJcyBhdXRob3JpemF0aW9uIHN1 YmplY3QgYmFzZWQgKGlkZW50aXR5IG9mIGNsaWVudCkgb3Igcm9sZSBiYXNlZD88YnIgY2xhc3M9 IiI+DQo8L2Jsb2NrcXVvdGU+DQo8YnIgY2xhc3M9IiI+DQpUaGUgc29sdXRpb24gc2hvdWxkIHdv cmsgd2l0aCBib3RoIGFwcHJvYWNoZXMuIFRoZSBjbGllbnQgaXMgZXhwZWN0ZWQgdG8gcHJlc2Vu dCBjcmVkZW50aWFscyB0byB0aGUgQVMgd2hlbiByZXF1ZXN0aW5nIGEgdG9rZW4uIFRoZXNlIGNy ZWRlbnRpYWxzIGNhbiB0aGVuIGJlIHJlc29sdmVkIHRvIGFuIGlkZW50aXR5LCBvciBhIHJvbGUs IG9yIHNvbWUgc2VjdXJpdHkgYXR0cmlidXRlcyBvZiB0aGUgY2xpZW50LiBUaGUgQVMgaXMgdGhl biBleHBlY3RlZA0KIHRvIG1ha2UgYW4gYXV0aG9yaXphdGlvbiBkZWNpc2lvbiBiYXNlZCBvbiB0 aGUgY3JlZGVudGlhbHMgYW5kIHRoZSBleGlzdGluZyBhdXRob3JpemF0aW9uIHBvbGljaWVzLjxi ciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCjxibG9ja3F1b3RlIHR5 cGU9ImNpdGUiIGNsYXNzPSIiPjQuIFJlc3Ryb3NwZWN0aW9uIG9mIHRoZSB0b2tlbnMgY2FuIGJl IGV4cGVuc2l2ZSBhbmQgdW5zY2FsYWJsZSBmb3IgdGhlPGJyIGNsYXNzPSIiPg0KJm5ic3A7Jm5i c3A7Jm5ic3A7QVMgKGlmIHRoZXJlIGFyZSBtYW55IFJTIG5vZGVzKSwgYnV0IHZlcmlmaWNhdGlv biBvZiBzZWxmLWNvbnRhaW5lZDxiciBjbGFzcz0iIj4NCiZuYnNwOyZuYnNwOyZuYnNwO3Rva2Vu cyBieSB0aGUgUlMgYWxzbyBzb3VuZHMgZXhwZW5zaXZlLCBwbHVzIHRoZSB2ZXJpZmljYXRpb24g a2V5czxiciBjbGFzcz0iIj4NCiZuYnNwOyZuYnNwOyZuYnNwO25lZWQgdG8gYmUgcHJvdmlzaW9u ZWQgaW4gdGhlIFJTLiBXb3VsZCBiZSBuaWNlIHRvIGhhdmUgZ3VpZGFuY2Ugb248YnIgY2xhc3M9 IiI+DQombmJzcDsmbmJzcDsmbmJzcDt3aGljaCBtYWtlcyBzZW5zZSB0YWtpbmcgZGV2aWNlIGNh cGFiaWxpdGllcy9jbGFzcyBpbnRvIGFjY291bnQuIEFueTxiciBjbGFzcz0iIj4NCiZuYnNwOyZu YnNwOyZuYnNwO25ldHdvcmsgc2ltdWxhdG9ycyBvdXQgdGhlcmU/PGJyIGNsYXNzPSIiPg0KPC9i bG9ja3F1b3RlPg0KPGJyIGNsYXNzPSIiPg0KSSdtIGd1ZXNzaW5nIHlvdSBtZWFudCBJbnRyb3Nw ZWN0aW9uIGhlcmUgcmlnaHQ/PGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KVGhlIEFTIGlz IG5vdCBleHBlY3RlZCB0byBiZSBhIGNvbnN0cmFpbmVkIGRldmljZSwgdGh1cyBpdCBzaG91bGQg YmUgYWJsZSB0byBzZXJ2ZSBhIHNpZ25pZmljYW50IG51bWJlciBvZiBpbnRyb3NwZWN0aW9uIHJl cXVlc3RzIGZyb20gZGlmZmVyZW50IFJTLiBJbnRyb3NwZWN0aW9uIHdvcmtzIGJlc3QgaWYgdGhl IFJTIGhhcyBhIGdvb2QgY29ubmVjdGl2aXR5IHRvIHRoZSBBUyB3aGlsZSB0aGUgY2xpZW50IGhh cyBpbnRlcm1pdHRlbnQgY29ubmVjdGl2aXR5DQogb3Igc2ltcGx5IGNvbm5lY3Rpdml0eSBmb3Ig dGhlIGNsaWVudCBpcyBleHBlbnNpdmUgKGUuZy4gY29zdHMgYSBsb3Qgb2YgYmF0dGVyeSkuPGJy IGNsYXNzPSIiPg0KT2YgY291cnNlIHRoZSBudW1iZXIgb2YgQVMgaGFzIHRvIGJlIHNjYWxlZCB1 cCB3aXRoIHRoZSBudW1iZXIgb2YgUlMsIGJ1dCBJIGRvbid0IHRoaW5rIHRoYXQgaXMgYW55IGRp ZmZlcmVudCBmb3Igbm9uLWNvbnN0cmFpbmVkIHNjZW5hcmlvcy48YnIgY2xhc3M9IiI+DQo8YnIg Y2xhc3M9IiI+DQpWZXJpZnlpbmcgYSBzZWxmLWNvbnRhaW5lZCB0b2tlbiBjZXJ0YWlubHkgY2Fu IGJlIGV4cGVuc2l2ZSwgYnV0IHRoZSBhbHRlcm5hdGl2ZSBpcyB0byBiZSBjb25uZWN0ZWQgdG8g dGhlIG5ldHdvcmsgaW4gb3JkZXIgdG8gZ2V0IGEgcmVhbC10aW1lIGFjY2VzcyBjb250cm9sIGRl Y2lzaW9uIGZyb20gYW4gQVMuPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KV2UgYXNzdW1l IHJvdWdobHkgdGhlIGZvbGxvd2luZyAmcXVvdDtoaWVyYXJjaHkmcXVvdDsgb2YgY29zdHMgKGZy b20gbW9zdCBleHBlbnNpdmUgdG8gbGVhc3QpOjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4N CjEuIE5ldHdvcmsgdHJhZmZpYyAoc2VuZGluZy9yZWNlaXZpbmcvbGlzdGVuaW5nIGZvciBpbmNv bWluZyBtZXNzYWdlcyk8YnIgY2xhc3M9IiI+DQoyLiBDcnlwdG8gb3BlcmF0aW9uczxiciBjbGFz cz0iIj4NCjMuIE1hdGNoaW5nIHJlcXVlc3RzIGFnYWluc3QgcGVybWlzc2lvbnMgZ3JhbnRlZCBi eSBhY2Nlc3MgdG9rZW5zPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KU2V2ZXJhbCBleHBl cmltZW50cyBJIGNvbmR1Y3RlZCBoYXZlIHNob3duIHRoYXQgMy4gaXMgYWxtb3N0IG5lZ2xpZ2li bGUgd2hlbiBjb21wYXJlZCB0byB0aGUgY29zdCBvZiAyLiBhbmQgMS4gJm5ic3A7V2hlbiB5b3Ug YWRkIHRoZSBvdmVyaGVhZCBvZiBydW5uaW5nIGEgc2VjdXJpdHkgcHJvdG9jb2wgd2hlbiBkb2lu ZyBuZXR3b3JrIGNvbW11bmljYXRpb24sIHRoaXMgbWFrZXMgYm90aCAyLiAmYW1wOyAzLiB2ZXJ5 IGNoZWFwIGNvbXBhcmVkIHdpdGggMS48YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQo8Ymxv Y2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj41LiBXb25kZXIgaWYgdGhlIHR3byBhcHAgbGF5 ZXIgc2VjdXJpdHkgc29sdXRpb25zIChPU0NPQVAvIE9TQ09OKSBjb3ZlcjxiciBjbGFzcz0iIj4N CiZuYnNwOyZuYnNwOyZuYnNwO3RoZSBwcm92aXNpb25pbmcgb2YgdGhlIGtleXMgdGhleSBhcmUg dXNpbmc/PGJyIGNsYXNzPSIiPg0KPC9ibG9ja3F1b3RlPg0KPGJyIGNsYXNzPSIiPg0KT1NDT0FQ IGFuZCBPU0NPTiBhcmUgYmFzZWQgb24gQ09TRSwgd2hpY2ggaW4gdHVybiBpcyBiYXNlZCBvbiBK T1NFIChKV0UvSldTKS4gJm5ic3A7Sk9TRSBhbmQgQ09TRSBoYXZlIHNvbWUga2V5IHByb3Zpc2lv bmluZyBmdW5jdGlvbmFsaXR5PGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNz PSIiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+Ni4gSWYgQ09BUCBvcHRpb24g bWF4IGxlbmd0aCBpcyAyNTYgYml0cywgaG93IGNhbiBhIHNpZ25hdHVyZSBtZWNoYW5pc208YnIg Y2xhc3M9IiI+DQombmJzcDsmbmJzcDsmbmJzcDt0aGF0IHJlcXVpcmVzIHRoYXQgbWFueSBiaXRz IGJlIHVzZWQ/PGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KPC9ibG9ja3F1b3RlPg0KPGJy IGNsYXNzPSIiPg0KQ2Fyc3RlbiBoYXMgYWxyZWFkeSBhbnN3ZXJlZCB0aGF0IGFuZCBJIGFncmVl IHdpdGggaGlzIGFzc2Vzc21lbnQuPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KPGJyIGNs YXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KLS0gPGJyIGNsYXNzPSIiPg0KTHVkd2lnIFNlaXR6LCBQ aEQ8YnIgY2xhc3M9IiI+DQpTSUNTIFN3ZWRpc2ggSUNUIEFCPGJyIGNsYXNzPSIiPg0KSWRlb24g U2NpZW5jZSBQYXJrPGJyIGNsYXNzPSIiPg0KQnVpbGRpbmcgQmV0YSAyPGJyIGNsYXNzPSIiPg0K U2NoZWVsZXbDpGdlbiAxNzxiciBjbGFzcz0iIj4NClNFLTIyMyA3MCBMdW5kPGJyIGNsYXNzPSIi Pg0KPGJyIGNsYXNzPSIiPg0KUGhvbmUgJiM0Mzs0NigwKTcwLTM0OSA5MiA1MTxiciBjbGFzcz0i Ij4NCjxhIGhyZWY9Imh0dHA6Ly93d3cuc2ljcy5zZSIgY2xhc3M9IiI+aHR0cDovL3d3dy5zaWNz LnNlPC9hPjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCl9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyIGNsYXNzPSIiPg0KQWNlIG1haWxpbmcgbGlz dDxiciBjbGFzcz0iIj4NCjxhIGhyZWY9Im1haWx0bzpBY2VAaWV0Zi5vcmciPkFjZUBpZXRmLm9y ZzwvYT48YnIgY2xhc3M9IiI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL2FjZSI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9hY2U8 L2E+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxiciBjbGFz cz0iIj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18gQWNlIG1haWxpbmcgbGlzdCA8YSBocmVmPSJt YWlsdG86QWNlQGlldGYub3JnIj4NCkFjZUBpZXRmLm9yZzwvYT4gPGEgaHJlZj0iaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9hY2UiPmh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vYWNlPC9hPg0KPC9zcGFuPg0KPC9ib2R5Pg0KPC9odG1sPg0KPHRhYmxl Pjx0cj48dGQ+PCEtLXR5cGU6dGV4dC0tPjwhLS17LS0+PHByZT4qKioqKioqKioqKioqIEVtYWls IENvbmZpZGVudGlhbGl0eSBOb3RpY2UgKioqKioqKioqKioqKioqKioqKioNClRoZSBpbmZvcm1h dGlvbiBjb250YWluZWQgaW4gdGhpcyBlLW1haWwgbWVzc2FnZSAoaW5jbHVkaW5nIGFueSANCmF0 dGFjaG1lbnRzKSBtYXkgYmUgY29uZmlkZW50aWFsLCBwcm9wcmlldGFyeSwgcHJpdmlsZWdlZCwg b3Igb3RoZXJ3aXNlDQpleGVtcHQgZnJvbSBkaXNjbG9zdXJlIHVuZGVyIGFwcGxpY2FibGUgbGF3 cy4gSXQgaXMgaW50ZW5kZWQgdG8gYmUgDQpjb252ZXllZCBvbmx5IHRvIHRoZSBkZXNpZ25hdGVk IHJlY2lwaWVudChzKS4gQW55IHVzZSwgZGlzc2VtaW5hdGlvbiwgDQpkaXN0cmlidXRpb24sIHBy aW50aW5nLCByZXRhaW5pbmcgb3IgY29weWluZyBvZiB0aGlzIGUtbWFpbCAoaW5jbHVkaW5nIGl0 cyANCmF0dGFjaG1lbnRzKSBieSB1bmludGVuZGVkIHJlY2lwaWVudChzKSBpcyBzdHJpY3RseSBw cm9oaWJpdGVkIGFuZCBtYXkgDQpiZSB1bmxhd2Z1bC4gSWYgeW91IGFyZSBub3QgYW4gaW50ZW5k ZWQgcmVjaXBpZW50IG9mIHRoaXMgZS1tYWlsLCBvciBiZWxpZXZlIA0KdGhhdCB5b3UgaGF2ZSBy ZWNlaXZlZCB0aGlzIGUtbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIA0K aW1tZWRpYXRlbHkgKGJ5IHJlcGx5aW5nIHRvIHRoaXMgZS1tYWlsKSwgZGVsZXRlIGFueSBhbmQg YWxsIGNvcGllcyBvZiANCnRoaXMgZS1tYWlsIChpbmNsdWRpbmcgYW55IGF0dGFjaG1lbnRzKSBm cm9tIHlvdXIgc3lzdGVtLCBhbmQgZG8gbm90DQpkaXNjbG9zZSB0aGUgY29udGVudCBvZiB0aGlz IGUtbWFpbCB0byBhbnkgb3RoZXIgcGVyc29uLiBUaGFuayB5b3UhDQo8L3ByZT48IS0tfS0tPjwv dGQ+PC90cj48L3RhYmxlPg== --_000_D2592D7C6BD4madjidnakhjirimediatekcom_-- From nobody Fri Oct 30 16:32:16 2015 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E78761B3C95 for ; Fri, 30 Oct 2015 16:32:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.55 X-Spam-Level: X-Spam-Status: No, score=-1.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 27EBQ5teasmX for ; Fri, 30 Oct 2015 16:32:13 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C65C1B3C94 for ; Fri, 30 Oct 2015 16:32:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [134.102.201.11]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id t9UNW78l029032; Sat, 31 Oct 2015 00:32:07 +0100 (CET) Received: from [192.168.1.109] (pD9F61E6C.dip0.t-ipconnect.de [217.246.30.108]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3nng071cmkz2FMg; Sat, 31 Oct 2015 00:32:07 +0100 (CET) From: Stefanie Gerdes To: Samuel Erdtman , Carsten Bormann References: <56326D0D.9020309@tzi.org> Message-ID: <5633FDF6.2010501@tzi.de> Date: Sat, 31 Oct 2015 00:32:06 +0100 User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Cc: Hannes Tschofenig , Olaf Bergmann , "Ace@ietf.org" , =?UTF-8?Q?G=c3=b6ran_Selander?= Subject: Re: [Ace] Innovating X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 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, 30 Oct 2015 23:32:15 -0000 Hi all, The solutions in ACE are all reusing existing solutions, they are just using different solutions to a different extent. The use cases show that there is a large variety of scenarios with different characteristics. The scenarios differ from the web scenarios which is why we founded ACE in the first place. Some of the use cases might only require a little tweaking of existing protocols, others need more consideration about how those protocols can be applied. We designed DCAF to address scenarios where the client, the server or both can be class-1 devices (see RFC 7228 [1]), where the client and the server may belong to different owners with distinct authorization policies and where these owners may not intervene in the authorization process at the time of the communication. As far as I understand draft-seitz-ace-oauth, it only supports less-constrained clients. That might be fine for the use cases and devices that you have in mind. With DCAF, we go a bit further into the constrained world and want to enable constrained devices to securely communicate with other constrained devices. Of course we want DCAF to interoperate with existing protocols. That is why we describe how such interactions can work (see draft-gerdes-ace-dcaf-examples [2]). Best regards, Steffi [1] https://tools.ietf.org/html/rfc7228 [2] https://tools.ietf.org/html/draft-gerdes-ace-dcaf-examples-00 From nobody Fri Oct 30 16:32:36 2015 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AC2B1B3C98 for ; Fri, 30 Oct 2015 16:32:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.25 X-Spam-Level: X-Spam-Status: No, score=-1.25 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yt4aut0leKLa for ; Fri, 30 Oct 2015 16:32:35 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 990121B3C94 for ; Fri, 30 Oct 2015 16:32:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [134.102.201.11]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id t9UNWUbw029594; Sat, 31 Oct 2015 00:32:30 +0100 (CET) Received: from [192.168.1.109] (pD9F61E6C.dip0.t-ipconnect.de [217.246.30.108]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3nng0Z2rxxz2FMh; Sat, 31 Oct 2015 00:32:30 +0100 (CET) From: Stefanie Gerdes To: =?UTF-8?Q?G=c3=b6ran_Selander?= , Carsten Bormann , =?UTF-8?Q?Erik_Wahlstr=c3=b6m_neXus?= References: <56326D0D.9020309@tzi.org> <5632AF66.3060501@tzi.org> Message-ID: <5633FE0E.8060206@tzi.de> Date: Sat, 31 Oct 2015 00:32:30 +0100 User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: Hannes Tschofenig , Olaf Bergmann , "Ace@ietf.org" Subject: Re: [Ace] Innovating X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 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, 30 Oct 2015 23:32:35 -0000 Hi Göran, On 10/30/2015 08:07 AM, Göran Selander wrote: > the object security variant in DCAF obviously > doesn’t work. I wonder where that is coming from. I may have missed something but your argument against DCAF-COSE seems to be that we are protecting an option that you think we shouldn't. However, the discussion about which options need to be protected how is still going on so I don't understand your remarks. All current solutions in ACE are not perfect yet. That's why we call it "work in progress". Best regards, Steffi From nobody Fri Oct 30 23:47:23 2015 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E5941B3554 for ; Fri, 30 Oct 2015 23:47:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.901 X-Spam-Level: X-Spam-Status: No, score=-3.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gy_JnU5pWuyj for ; Fri, 30 Oct 2015 23:47:20 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 44A581B3550 for ; Fri, 30 Oct 2015 23:47:20 -0700 (PDT) X-AuditID: c1b4fb3a-f79136d0000071e2-8e-563463f6dc4d Received: from ESESSHC020.ericsson.se (Unknown_Domain [153.88.253.125]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id D2.83.29154.6F364365; Sat, 31 Oct 2015 07:47:18 +0100 (CET) Received: from ESESSMB303.ericsson.se ([169.254.3.162]) by ESESSHC020.ericsson.se ([153.88.183.78]) with mapi id 14.03.0248.002; Sat, 31 Oct 2015 07:47:17 +0100 From: =?utf-8?B?R8O2cmFuIFNlbGFuZGVy?= To: Stefanie Gerdes , Carsten Bormann , =?utf-8?B?RXJpayBXYWhsc3Ryw7ZtIG5lWHVz?= Thread-Topic: [Ace] Innovating Thread-Index: AQHREnxBH+G/NF6jq069q22sAXskIZ6C4aiAgAAwJwCAAIyRAIABAmAAgACKPQA= Date: Sat, 31 Oct 2015 06:47:17 +0000 Message-ID: References: <56326D0D.9020309@tzi.org> <5632AF66.3060501@tzi.org> <5633FE0E.8060206@tzi.de> In-Reply-To: <5633FE0E.8060206@tzi.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.7.141117 x-originating-ip: [153.88.183.154] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrLIsWRmVeSWpSXmKPExsUyM+Jvre63ZJMwg/2L5S2+f+thtmha3Mhk cWTKXVaLY7sWs1lsvHiX0WLpznusDmweizftZ/NYsuQnk8fW+78ZPba9/crsMW1RZgBrFJdN SmpOZllqkb5dAlfG2RuNrAWvRCqenzBtYFwi0sXIySEhYCIxZ+YSVghbTOLCvfVsXYxcHEIC RxglFvfPYIJwljBKvJrezQ5SxSbgIvGg4RFYQkSgn1Fi98n3zCAJZoESiU93m8FsYQFZicaP /4BsDqAiOYmNd21AwiICfhJvO/cxgdgsAqoS21/OZwGxeQUsJLYefMMOt/lX53qwIk4BNYlJ qxaxgdiMQOd9P7WGCWKXuMStJ/OZIM4WkFiy5zwzhC0q8fLxP7B3RAX0JFZeb2KDiCtJLLr9 mQnkHmYBTYn1u/QhxlhL7PvQwQphK0pM6X7IDnGPoMTJmU9YJjBKzEKybRZC9ywk3bOQdM9C 0r2AkXUVo2hxanFxbrqRkV5qUWZycXF+nl5easkmRmAkH9zy22oH48HnjocYBTgYlXh4DfYZ hwmxJpYVV+YeYpTgYFYS4eXVNAkT4k1JrKxKLcqPLyrNSS0+xCjNwaIkztvM9CBUSCA9sSQ1 OzW1ILUIJsvEwSnVwGi/7Ovk3PnZonER4YujX1fEzz0j9LZvHn+WrsqtSx+EG9nlV0Qdfrvs pvizF5Mm//96bv/O7XVpzy9IfZ3CL/PxGdv1uPMrZj5eruak25jy/aBwe/bB707RG1YZVS/r 2FwtMPNZ3+w0oZylB3NU89yr/0+Ym2RZyedz9Ys0x4I6S8c/Rp7Sfm1KLMUZiYZazEXFiQDQ oC8k4AIAAA== Archived-At: Cc: Hannes Tschofenig , Olaf Bergmann , "Ace@ietf.org" Subject: Re: [Ace] Innovating X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 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, 31 Oct 2015 06:47:22 -0000 SGkgU3RlZmZpLA0KDQpPbiAyMDE1LTEwLTMxIDAwOjMyLCAiU3RlZmFuaWUgR2VyZGVzIiA8Z2Vy ZGVzQHR6aS5kZT4gd3JvdGU6DQoNCj5IaSBHw7ZyYW4sDQo+DQo+T24gMTAvMzAvMjAxNSAwODow NyBBTSwgR8O2cmFuIFNlbGFuZGVyIHdyb3RlOg0KPg0KPj4gdGhlIG9iamVjdCBzZWN1cml0eSB2 YXJpYW50IGluIERDQUYgb2J2aW91c2x5DQo+PiBkb2VzbuKAmXQgd29yay4gDQo+DQo+SSB3b25k ZXIgd2hlcmUgdGhhdCBpcyBjb21pbmcgZnJvbS4gSSBtYXkgaGF2ZSBtaXNzZWQgc29tZXRoaW5n IGJ1dCB5b3VyDQo+YXJndW1lbnQgYWdhaW5zdCBEQ0FGLUNPU0Ugc2VlbXMgdG8gYmUgdGhhdCB3 ZSBhcmUgcHJvdGVjdGluZyBhbiBvcHRpb24NCj50aGF0IHlvdSB0aGluayB3ZSBzaG91bGRuJ3Qu IEhvd2V2ZXIsIHRoZSBkaXNjdXNzaW9uIGFib3V0IHdoaWNoIG9wdGlvbnMNCj5uZWVkIHRvIGJl IHByb3RlY3RlZCBob3cgaXMgc3RpbGwgZ29pbmcgb24gc28gSSBkb24ndCB1bmRlcnN0YW5kIHlv dXINCj5yZW1hcmtzLg0KDQoNCkkgZG9u4oCZdCBrbm93IG9mIGFueSBkaXNjdXNzaW9uIGFib3V0 IHdoaWNoIG9wdGlvbnMgbmVlZHMgdG8gYmUgcHJvdGVjdGVkLA0KdGhvc2UgYXJlIGxpc3RlZCBp biB0aGUgdGFibGUgaW4gZmlndXJlIDIgb2YgT1NDT0FQOg0KDQpodHRwczovL3Rvb2xzLmlldGYu b3JnL2h0bWwvZHJhZnQtc2VsYW5kZXItYWNlLW9iamVjdC1zZWN1cml0eS0wMyNzZWN0aW9uLTYN Ci4yDQoNClRoZXJlIGlzIG9uZSBkaXNjdXNzaW9uIGFib3V0IGhvdyBjZXJ0YWluIG9wdGlvbiB2 YWx1ZXMgY2FuIGJlIHJlcHJlc2VudGVkDQppbiBjZXJ0YWluIGNhc2VzIHRvIGVuc3VyZSB0aGF0 IGNsaWVudCBhbmQgc2VydmVyIGJvdGggY2FuIGdldCB0aGUgc2FtZQ0KdmFsdWUuIFRoZXJlIGlz IGEgc2Vjb25kIGRpc2N1c3Npb24gYWJvdXQgaG93IHdlIHNob3VsZCBwcm90ZWN0IGNlcnRhaW4N CnByb3BlcnRpZXMgb2YgYSBDb0FQIG1lc3NhZ2UgdGhhdCBjYW7igJl0IGJlIHByb3RlY3RlZCB0 b2RheS4gRm9yIGV4YW1wbGUgd2UNCm5lZWQgdG8gcHJvdGVjdCB0aGUgcGFydGl0aW9uaW5nIG9m IGEgbGFyZ2UgbWVzc2FnZSBpbnRvIGJsb2NrczogVGhlcmUgaXMNCm5vIGRpc2N1c3Npb24gYWJv dXQgb3B0aW9ucyBibG9jazEgYW5kIGJsb2NrMiBhcyBkZWZpbmVkIGluIHRoZSBibG9ja3dpc2UN CmRyYWZ0IC0gdGhleSBjYW7igJl0IGJlIHByb3RlY3RlZCBiZWNhdXNlIGEgcHJveHkgbWF5IHNw bGl0IHRoZSBtZXNzYWdlIGluIGENCmJsb2NrIHNpemUgdW5rbm93biB0byBjbGllbnQgYW5kIHNl cnZlci4gVGhlIGRpc2N1c3Npb24gaXMgYWJvdXQgaG93IHRvDQpkZWZpbmUgZW5kLXRvLWVuZCBz ZWN1cmUgYmxvY2sgb3B0aW9ucy4NCg0KSW4gRENBRi1DT1NFIHlvdSBhcmUgcHJvdGVjdGluZyBh IG51bWJlciBvZiBvcHRpb25zIChsaXN0ZWQgaW4gYSBwcmV2aW91cw0KbWFpbCkgd2hpY2ggYXJl IGNoYW5nZWQgYnkgbGVnaXRpbWF0ZSBDb0FQIHByb3h5IG9wZXJhdGlvbnMuIFRoZXJlZm9yZSB0 aGUNCnNlY3VyaXR5IHNvbHV0aW9uIG9idmlvdXNseSBkb2VzbuKAmXQgd29yay4NCg0KDQo+DQo+ QWxsIGN1cnJlbnQgc29sdXRpb25zIGluIEFDRSBhcmUgbm90IHBlcmZlY3QgeWV0LiBUaGF0J3Mg d2h5IHdlIGNhbGwgaXQNCj4id29yayBpbiBwcm9ncmVzcyIuDQoNCg0KU3VyZSwgaXQgaXMgcG9z c2libGUgdGhhdCB0aGVyZSBhcmUgZXJyb3JzIGluIE9TQ09BUCB0aGF0IHdlIGFyZSBub3QgYXdh cmUNCm9mLiBUaGUgZGlmZmVyZW5jZSBpcyB0aGF0IERDQUYtQ09TRSBkb2VzIG5vdCBzb2x2ZSBi YXNpYyBwcm9ibGVtcyB3aXRoDQp0aGUgc2VjdXJpdHkgZGVzaWduIHdlIHNvbHZlZCBpbiBPU0NP QVAgYmVmb3JlIHN1Ym1pdHRpbmcgdGhlIDAwLXZlcnNpb24gYQ0KeWVhciBhZ28uDQoNCkfDtnJh bg0KDQoNCg== From nobody Sat Oct 31 00:16:00 2015 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 740EC1B35BF for ; Sat, 31 Oct 2015 00:16:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.901 X-Spam-Level: X-Spam-Status: No, score=-3.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vSQZnK0RU9Yk for ; Sat, 31 Oct 2015 00:15:58 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E0A831B3472 for ; Sat, 31 Oct 2015 00:15:57 -0700 (PDT) X-AuditID: c1b4fb30-f79626d000006adf-69-56346aabb96c Received: from ESESSHC009.ericsson.se (Unknown_Domain [153.88.253.125]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 6A.D5.27359.CAA64365; Sat, 31 Oct 2015 08:15:56 +0100 (CET) Received: from ESESSMB303.ericsson.se ([169.254.3.162]) by ESESSHC009.ericsson.se ([153.88.183.45]) with mapi id 14.03.0248.002; Sat, 31 Oct 2015 08:15:55 +0100 From: =?utf-8?B?R8O2cmFuIFNlbGFuZGVy?= To: Madjid Nakhjiri , Carsten Bormann Thread-Topic: [Ace] comments on draft-seitz-ace-oauth-authz-00 Thread-Index: AQHREeZtLoYHI1sV0UKYlZCdCQHqy56BnIsAgALQJoCAAMd2gA== Date: Sat, 31 Oct 2015 07:15:55 +0000 Message-ID: References: <5631754C.6010901@tzi.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.7.141117 x-originating-ip: [153.88.183.150] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrIIsWRmVeSWpSXmKPExsUyM+Jvre6aLJMwg3ObeC2+f+thtjgy5S6r xZXWj4wOzB5Llvxk8mg5uZ/FY9qizADmKC6blNSczLLUIn27BK6MOSfuMRe8Mq341beKvYFx h0kXIyeHhICJxJ/PR9ggbDGJC/fWA9lcHEICRxglvnVPY4VwljBKTFz7jxWkik3AReJBwyMm EFtEIERi4ooOsDizgKLEujl9YHFhAVuJnSvWsEDU2En87Wpgg7CdJA70nGQHsVkEVCXats9m 7GLk4OAVsJA4f94AJCwkECrxZO9JsDGcApYSM9r/MoPYjEDHfT+1hglilbjErSfzmSCOFpBY suc8M4QtKvHyMcSZogJ6EiuvN0E9piSxYvslsFXMApoS63fpQ5jWEovb3GCOn9L9EOwwXgFB iZMzn7BMYJSYhWTZLITmWQjNs5A0z0LSvICRdRWjaHFqcVJuupGRXmpRZnJxcX6eXl5qySZG YEQe3PLbYAfjy+eOhxgFOBiVeHgN9hmHCbEmlhVX5h5ilOBgVhLh5dU0CRPiTUmsrEotyo8v Ks1JLT7EKM3BoiTO28z0IFRIID2xJDU7NbUgtQgmy8TBKdXAGDQp6JqUlaZo5iGR+9w8ZUuW XlJ+5tTRvfTX+r8lFYk6/3J3FNvnTUztPqH2ecn78y4bchmO7epk5mj+9aTQsvqzLW/qBA6+ u57zFzUVxK2JeGOszyUQbrkjfdayqU2Hnp9+sqrxteeOhStL/8ye6fS38arcR+71DT/iXRpW floe86SKZxl3gBJLcUaioRZzUXEiALtba5rEAgAA Archived-At: Cc: "ace@ietf.org" Subject: Re: [Ace] comments on draft-seitz-ace-oauth-authz-00 X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 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, 31 Oct 2015 07:16:00 -0000 SGkgTWFkamlkLA0KDQpUaGFua3MgZm9yIGdvb2QgY29tbWVudHMsIGlubGluZS4NCg0KT24gMjAx NS0xMC0zMCAyMToyMSwgIk1hZGppZCBOYWtoamlyaSIgPG1hZGppZC5uYWtoamlyaUBtZWRpYXRl ay5jb20+DQp3cm90ZToNCg0KPkhpIENhcnN0ZW4sIA0KPg0KPlRoYW5rcyBmb3IgdGhlIGNsYXJp ZmljYXRpb24uIEkgdGhpbmsgSSBwaWNrZWQgdXAgb24gdGhlIGZvbGxvd2luZw0KPnN0YXRlbWVu dCBhbmQgdGhlbiBtaXhlZCB1cCBteSBiaXRzIGFuZCBieXRlczopDQo+DQo+IjUuMiBBdXRob3Jp emF0aW9uIEluZm9ybWF0aW9uIFJlc291cmNlIGF0IHRoZSBSZXNvdXJjZSBTZXJ2ZXINCj5BIGNv bnNlcXVlbmNlIG9mIGFsbG93aW5nIHRoZSB1c2Ugb2YgQ29BUCBhcyB3ZWIgdHJhbnNmZXIgcHJv dG9jb2wgaXMgdGhhdA0KPndlIGNhbm5vdCByZWx5IG9uIEhUVFAgc3BlY2lmaWMgbWVjaGFuaXNt cywgc3VjaCBhcyB0cmFuc2ZlcnJpbmcNCj5pbmZvcm1hdGlvbiBlbGVtZW50cyBpbiBIVFRQIGhl YWRlcnMgc2luY2UgdGhvc2UgYXJlIG5vdCBuZWNlc3NhcmlseQ0KPmdyYWNlZnVsbHkgbWFwcGVk IHRvIENvQVAuICBJbiBjYXNlIHRoZSBhY2Nlc3MgdG9rZW4gaXMgbGFyZ2VyIHRoZW4gMjU1DQo+ Ynl0ZXMgaXQgc2hvdWxkIG5vdCBiZSBzZW50IGFzIGEgQ29BUCBvcHRpb24u4oCdDQo+DQo+DQo+ DQo+WWVzLCBhcyB5b3Ugc2F5LCB3ZSBkbyB3YW50IHRvIHJlZHVjZSB0aGUgc2l6ZSBvZiB0aGUg bWVzc2FnZXMgb3IgcHJvYmFibHkNCj50aGUgZnJlcXVlbmN5IHdpdGggd2hpY2ggbGFyZ2UgbWVz c2FnZXMgYXJlIHNlbnQsIGUuZy4gQnkgaW5jcmVhc2luZyB0aGUNCj5saWZlIHRpbWUgb2YgdGhl IE9BVVRIIHRva2VuLiBOb3csICB0aGUgcXVlc3Rpb25zIGFyZQ0KPjEpIHdoZXRoZXIgd2Ugd2Fu dCB0byBwdXQgdGhlIHRva2VuIG9yIGFueSB0eXBlIG9mIHNpZ25hdHVyZSBpbnNpZGUgYW4NCj5v cHRpb24sIGdpdmVuIHRoYXQgQ09BUCBibG9jayBwcm90b2NvbCAobm90IHN1cmUgb2YgdGhlIGRl dGFpbHMpIGNhbm5vdA0KPnNwbGl0IHRoZSBvcHRpb24gYXMgeW91IHNheT8NCj4yKSBpZiB3ZSBk b27igJl0IHdhbnQgdG8gdGFrZSB1cCBzbyBtdWNoIG1lc3NhZ2UgQlcgb24gYSBzaWduYXR1cmUs IHdoYXQNCj5pbnRlZ3JpdHkgcHJvdGVjdGlvbi8gYXV0aGVudGljYXRpb24gbWVjaGFuaXNtcyBh cmUgd2Ugc3VnZ2VzdGluZz8gRnJvbQ0KPndoYXQgSSB1bmRlcnN0YW5kIHdpdGggMjU2IGJpdHMg RUMga2V5cywgdGhlIEVDRFNBIHNpZyBpcyA1MTIrIGJpdHMuIEFyZQ0KPmZvbGtzIHN1Z2dlc3Rp bmcgTUFDcz8NCj4NCj5SZWFkaW5nIENPQVAgUkZDIDcyNTIsIHNlY3Rpb24gNS40LCBJIGRvbuKA mXQgc2VlIGFueSBvcHRpb24gdGhhdCBzb3VuZHMNCj5saWtlIG9uZSB0aGF0IHdvdWxkIGNhcnJ5 IGFuIE9BVVRIIHRva2VuIG9yIGEgc2lnbmF0dXJlLg0KDQpBcyB5b3UgcHJvYmFibHkgbm90ZWQs IHRoZSBkZWZhdWx0IGNhc2UgYWNjb3JkaW5nIHRvIHRoZSBkcmFmdCBpcyB0aGF0IHRoZQ0KY2xp ZW50IFBPU1RzIHRoZSBhY2Nlc3MgdG9rZW4gdG8gL2F1dGh6LWluZm8gYXQgdGhlIHJlc291cmNl IHNlcnZlciwgaS5lLg0KdGhhdCB0aGUgYWNjZXNzIHRva2VuIGlzIHNlbnQgaW4gcGF5bG9hZCBp cyB0aHVzIG5vdCByZXN0cmljdGVkIGluIHNpemUNCmFuZCBjYW4gY29udGFpbiBzaWduYXR1cmUs IE1BQywgb3IgdHJ1bmNhdGVkIE1BQyBhcyBhcHByb3ByaWF0ZSBmb3IgdGhlDQp1c2UgY2FzZS4g SW4gQXBwZW5kaXggQiB3ZSBsaXN0IHNvbWUgcG90ZW50aWFsIG9wdGltaXphdGlvbnMgaW5jbHVk aW5nIGENCm5ldyBDb0FQIG9wdGlvbiBpbnRlbmRlZCB0byBjYXJyeSBhIHJlZmVyZW5jZSB0b2tl biwgd2hpY2ggaXMgdGhlbiB1c2VkIGJ5DQp0aGUgcmVzb3VyY2Ugc2VydmVyIGluIGludHJvc3Bl Y3Rpb24gdG8gbG9vayB1cCByZWxldmFudCBhdXRob3JpemF0aW9uDQppbmZvcm1hdGlvbi4gSWYg dGhlIGFjY2VzcyB0b2tlbiBpcyBzbWFsbCBzdWNoIGEgQ29BUCBvcHRpb24gY291bGQgaW4NCnBy aW5jaXBsZSBiZSB1c2VkIHdpdGhvdXQgaW50cm9zcGVjdGlvbiBidXQgdGhlIGV4YWN0IHNpemUg Y29uZGl0aW9ucyBpcw0KVEJELiBNeSBiZXN0IGd1ZXNzIGlzIHRoYXQgYSB0b2tlbiBjb250YWlu aW5nIGVzc2VudGlhbGx5IGFuIGlkZW50aWZpZXIgb2YNCmEgcm9sZS9jYXBhYmlsaXR5IGxpc3Qg KyBhIHRydW5jYXRlZCBNQUMgc2hvdWxkIGZpdCBpbnRvIHN1Y2ggYSBDb0FQDQpvcHRpb24gYW5k IHRodXMgZW5hYmxlIHRoZSB0b2tlbiB0byBiZSBjYXJyaWVkIHdpdGhpbiB0aGUgcmVzb3VyY2Ug cmVxdWVzdC4NCg0KSSBkb27igJl0IGtub3cgaWYgdGhpcyBhbnN3ZXJlZCBhbnkgb2YgeW91ciBx dWVzdGlvbnMuDQoNCkfDtnJhbg0KDQoNCj5BbHNvIG15IDEwIG1pbg0KPmludmVzdGlnYXRpb24g c2hvd3MgKHNlY3Rpb24gMy4xIG9wdGlvbiBmb3JtYXQpIHRoYXQgdGhlIG9wdGlvbiBsZW5ndGgg aXMNCj5vbmx5IDQgYml0cyBhbmQgYWZ0ZXIgdGhlIHJlc2VydmVkIHZhbHVlcywgb25seSBhbGxv dyBmb3IgMS0xMiBieXRlcy4gSXMNCj50aGVyZSBzb21lIG90aGVyIGNsYXVzZSB0aGF0IEkgbWlz c2VkPyBUaGUgb3B0aW9uIGxlbmd0aCBleHRlbmRlZCBtYXliZT8NCj4NCj4NCj4NCj4NCj5SZWdh cmRzLA0KPk1hZGppZCBOYWtoamlyaQ0KPum6puW/l+W+lyANCj4NCj5QcmluY2lwYWwgU2VjdXJp dHkgQXJjaGl0ZWN0DQo+TWVkaWFUZWsgSW5jLg0KPuKAnFNpbXBsaWNpdHkgaXMgdGhlIHVsdGlt YXRlIHNvcGhpc3RpY2F0aW9uIg0KPg0KPg0KPg0KPg0KPk9uIDEwLzI4LzE1LCA2OjI0IFBNLCAi Q2Fyc3RlbiBCb3JtYW5uIiA8Y2Fib0B0emkub3JnPiB3cm90ZToNCj4NCj4+TWFkamlkIE5ha2hq aXJpIHdyb3RlOg0KPj4+ICMgSWYgQ09BUCBvcHRpb24gbWF4IGxlbmd0aCBpcyAyNTYgYml0cywg aG93IGNhbiBhIHNpZ25hdHVyZSBtZWNoYW5pc20NCj4+PiB0aGF0IHJlcXVpcmVzIHRoYXQgbWFu eSBiaXRzIGJlIHVzZWQ/DQo+Pg0KPj5JdCdzIG5vdCAtLSB0aGVyZSBpcyBubyBmdW5kYW1lbnRh bCBsaW1pdCB0byBDb0FQIG9wdGlvbiBzaXplLg0KPj5QcmFjdGljYWxseSBzcGVha2luZywgaG93 ZXZlciwgaXQgaXMgb2Z0ZW4gYWR2YW50YWdlb3VzIHRvIGJlIGFibGUgdG8NCj4+cHV0IGEgQ29B UCBtZXNzYWdlIGludG8gYSBkYXRhZ3JhbSB0aGF0IGlzIG9mIGFwcHJvcHJpYXRlIHNpemUuDQo+ PlJGQyA3MjUyIGdpdmVzIDExNTIgYnl0ZXMgYXMgYSBwcmFjdGljYWwgdXBwZXIgYm91bmQgb2Yg dGhhdDsgc29tZQ0KPj5yYWRpb3MgYXJlIG11Y2ggaGFwcGllciB3aXRoIDgwIGJ5dGVzIG9yIGxl c3MgKG5vdCBleGNsdWRpbmcgdGhlDQo+Pm9jY2FzaW9uYWwgbGFyZ2VyIG1lc3NhZ2UsIGJ1dCB0 aGF0IG1pZ2h0IGhhdmUgYSBoYXJkZXIgdGltZSBnZXR0aW5nDQo+PnRocm91Z2gsIHNvIHlvdSBt aWdodCB3YW50IHRvIHVzZSB0aGVtIHNwYXJpbmdseSkuICBBbHNvIG5vdGUgdGhhdCB0aGUNCj4+ Q29BUCBibG9jayBwcm90b2NvbCBoZWxwcyB3aXRoIHNwbGl0dGluZyB1cCBwYXlsb2FkcyBpbnRv IGJsb2NrcywgYnV0DQo+Pm9wdGlvbnMgZG8gbm90IGJlbmVmaXQgZnJvbSB0aGF0Lg0KPj4NCj4+ U28gdGhlIGdpc3QgaXM6IGEgMjU2LWJpdCAoMzItYnl0ZSkgc2lnbmF0dXJlIGlzIHF1aXRlIHBv c3NpYmxlIGluIGFuDQo+Pm9wdGlvbjsgZm9yIHNvbWUgYXBwbGljYXRpb25zIHRoZSBidXJkZW4g c3VjaCBhbiBvcHRpb24gcGxhY2VzIG9uIHRoZQ0KPj5yZW1haW5pbmcgbWVzc2FnZSBzaXplIGlz IHJhdGhlciBzaWduaWZpY2FudCwgYnV0IG1vc3RseSBub3QgcHJvaGliaXRpdmUuDQo+Pg0KPj5H csO8w59lLCBDYXJzdGVuDQo+Pg0KPj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXw0KPj5BY2UgbWFpbGluZyBsaXN0DQo+PkFjZUBpZXRmLm9yZw0KPj5odHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2FjZQ0KPg0KPg0KPioqKioqKioqKioq KiogRW1haWwgQ29uZmlkZW50aWFsaXR5IE5vdGljZSAqKioqKioqKioqKioqKioqKioqKg0KPlRo ZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaW4gdGhpcyBlLW1haWwgbWVzc2FnZSAoaW5jbHVkaW5n IGFueQ0KPmF0dGFjaG1lbnRzKSBtYXkgYmUgY29uZmlkZW50aWFsLCBwcm9wcmlldGFyeSwgcHJp dmlsZWdlZCwgb3Igb3RoZXJ3aXNlDQo+ZXhlbXB0IGZyb20gZGlzY2xvc3VyZSB1bmRlciBhcHBs aWNhYmxlIGxhd3MuIEl0IGlzIGludGVuZGVkIHRvIGJlDQo+Y29udmV5ZWQgb25seSB0byB0aGUg ZGVzaWduYXRlZCByZWNpcGllbnQocykuIEFueSB1c2UsIGRpc3NlbWluYXRpb24sDQo+ZGlzdHJp YnV0aW9uLCBwcmludGluZywgcmV0YWluaW5nIG9yIGNvcHlpbmcgb2YgdGhpcyBlLW1haWwgKGlu Y2x1ZGluZw0KPml0cyANCj5hdHRhY2htZW50cykgYnkgdW5pbnRlbmRlZCByZWNpcGllbnQocykg aXMgc3RyaWN0bHkgcHJvaGliaXRlZCBhbmQgbWF5DQo+YmUgdW5sYXdmdWwuIElmIHlvdSBhcmUg bm90IGFuIGludGVuZGVkIHJlY2lwaWVudCBvZiB0aGlzIGUtbWFpbCwgb3INCj5iZWxpZXZlIA0K PnRoYXQgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlLW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3Rp ZnkgdGhlIHNlbmRlcg0KPmltbWVkaWF0ZWx5IChieSByZXBseWluZyB0byB0aGlzIGUtbWFpbCks IGRlbGV0ZSBhbnkgYW5kIGFsbCBjb3BpZXMgb2YNCj50aGlzIGUtbWFpbCAoaW5jbHVkaW5nIGFu eSBhdHRhY2htZW50cykgZnJvbSB5b3VyIHN5c3RlbSwgYW5kIGRvIG5vdA0KPmRpc2Nsb3NlIHRo ZSBjb250ZW50IG9mIHRoaXMgZS1tYWlsIHRvIGFueSBvdGhlciBwZXJzb24uIFRoYW5rIHlvdSEN Cj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPkFjZSBt YWlsaW5nIGxpc3QNCj5BY2VAaWV0Zi5vcmcNCj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL2FjZQ0KDQo= From nobody Sat Oct 31 01:18:06 2015 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84EA11A1ADD for ; Sat, 31 Oct 2015 01:18:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.901 X-Spam-Level: X-Spam-Status: No, score=-3.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y0VtfMmrrhBj for ; Sat, 31 Oct 2015 01:18:03 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 32A901A1ACA for ; Sat, 31 Oct 2015 01:18:03 -0700 (PDT) X-AuditID: c1b4fb30-f79626d000006adf-85-5634793944cc Received: from ESESSHC012.ericsson.se (Unknown_Domain [153.88.183.54]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 46.8B.27359.93974365; Sat, 31 Oct 2015 09:18:01 +0100 (CET) Received: from ESESSMB303.ericsson.se ([169.254.3.162]) by ESESSHC012.ericsson.se ([153.88.183.54]) with mapi id 14.03.0248.002; Sat, 31 Oct 2015 09:17:06 +0100 From: =?utf-8?B?R8O2cmFuIFNlbGFuZGVy?= To: Stefanie Gerdes , Samuel Erdtman , Carsten Bormann Thread-Topic: [Ace] Innovating Thread-Index: AQHREnxBH+G/NF6jq069q22sAXskIZ6DluUAgAEJvwCAAKNxgA== Date: Sat, 31 Oct 2015 08:17:06 +0000 Message-ID: References: <56326D0D.9020309@tzi.org> <5633FDF6.2010501@tzi.de> In-Reply-To: <5633FDF6.2010501@tzi.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.7.141117 x-originating-ip: [153.88.183.154] Content-Type: text/plain; charset="utf-8" Content-ID: <70D23C58578F0A4E87248AB7F2693355@ericsson.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrBIsWRmVeSWpSXmKPExsUyM2K7ma5lpUmYwY/fshbfv/UwWzQtbmSy ODLlLqvFxot3GS2W7rzHavF/6SkmBzaPF//2MHos3rSfzWPJkp9MHtvefmX2mLYoM4A1issm JTUnsyy1SN8ugSvj179PrAV9UhUvXiU0MO6Q7GLk5JAQMJFoOXOBDcIWk7hwbz2YLSRwmFHi wTfmLkYuIHsJo8Tu05MZQRJsAi4SDxoeMYHYIgKZEq9W3WYFsZkFSiQ+3W1mBrGFBWQlGj/+ A7I5gGrkJDbetYEod5L49qsFbD6LgKrE/SfdYK28AhYS+27PYIHY1ckocXTOdzaQXk4BNYnG pfwgNYxAt30/tYYJYpW4xK0n85kgbhaQWLLnPDOELSrx8vE/sJmiAnoSK683Qf2lJLHo9mcm kJHMApoS63fpQ5jWEuufSkFMVJSY0v2QHeIaQYmTM5+wTGCUmIVk2SyE5lkIzbOQNM9C0ryA kXUVo2hxanFSbrqRkV5qUWZycXF+nl5easkmRmD8Htzy22AH48vnjocYBTgYlXh4DfYZhwmx JpYVV+YeYpTgYFYS4eXVNAkT4k1JrKxKLcqPLyrNSS0+xCjNwaIkztvM9CBUSCA9sSQ1OzW1 ILUIJsvEwSnVwMj29WjcS/stKVvOPejTsjjU3XBjoeRzIa9Ziy4sYvumuNu5doaS3rVo1Ufp 7v07Oz8ssQyfuvrQlw+3Nqe9CzixIeQ0h2lnhv80/dDtTt6BQQxq7P6lfn5MKhta119Tkzsc Ir9k+cxvhr9Xts/scTK0v+T08HX9qlO9ynOTppXsSUqZvuOfyh4lluKMREMt5qLiRABgDaOs 2wIAAA== Archived-At: Cc: Hannes Tschofenig , Olaf Bergmann , "Ace@ietf.org" Subject: Re: [Ace] Innovating X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 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, 31 Oct 2015 08:18:05 -0000 DQoNCk9uIDIwMTUtMTAtMzEgMDA6MzIsICJTdGVmYW5pZSBHZXJkZXMiIDxnZXJkZXNAdHppLmRl PiB3cm90ZToNCg0KPkhpIGFsbCwNCj4NCj5UaGUgc29sdXRpb25zIGluIEFDRSBhcmUgYWxsIHJl dXNpbmcgZXhpc3Rpbmcgc29sdXRpb25zLCB0aGV5IGFyZSBqdXN0DQo+dXNpbmcgZGlmZmVyZW50 IHNvbHV0aW9ucyB0byBhIGRpZmZlcmVudCBleHRlbnQuDQo+DQo+VGhlIHVzZSBjYXNlcyBzaG93 IHRoYXQgdGhlcmUgaXMgYSBsYXJnZSB2YXJpZXR5IG9mIHNjZW5hcmlvcyB3aXRoDQo+ZGlmZmVy ZW50IGNoYXJhY3RlcmlzdGljcy4gVGhlIHNjZW5hcmlvcyBkaWZmZXIgZnJvbSB0aGUgd2ViIHNj ZW5hcmlvcw0KPndoaWNoIGlzIHdoeSB3ZSBmb3VuZGVkIEFDRSBpbiB0aGUgZmlyc3QgcGxhY2Uu IFNvbWUgb2YgdGhlIHVzZSBjYXNlcw0KPm1pZ2h0IG9ubHkgcmVxdWlyZSBhIGxpdHRsZSB0d2Vh a2luZyBvZiBleGlzdGluZyBwcm90b2NvbHMsIG90aGVycyBuZWVkDQo+bW9yZSBjb25zaWRlcmF0 aW9uIGFib3V0IGhvdyB0aG9zZSBwcm90b2NvbHMgY2FuIGJlIGFwcGxpZWQuDQo+DQo+V2UgZGVz aWduZWQgRENBRiB0byBhZGRyZXNzIHNjZW5hcmlvcyB3aGVyZSB0aGUgY2xpZW50LCB0aGUgc2Vy dmVyIG9yDQo+Ym90aCBjYW4gYmUgY2xhc3MtMSBkZXZpY2VzIChzZWUgUkZDIDcyMjggWzFdKSwg d2hlcmUgdGhlIGNsaWVudCBhbmQgdGhlDQo+c2VydmVyIG1heSBiZWxvbmcgdG8gZGlmZmVyZW50 IG93bmVycyB3aXRoIGRpc3RpbmN0IGF1dGhvcml6YXRpb24NCj5wb2xpY2llcyBhbmQgd2hlcmUg dGhlc2Ugb3duZXJzIG1heSBub3QgaW50ZXJ2ZW5lIGluIHRoZSBhdXRob3JpemF0aW9uDQo+cHJv Y2VzcyBhdCB0aGUgdGltZSBvZiB0aGUgY29tbXVuaWNhdGlvbi4gQXMgZmFyIGFzIEkgdW5kZXJz dGFuZA0KPmRyYWZ0LXNlaXR6LWFjZS1vYXV0aCwgaXQgb25seSBzdXBwb3J0cyBsZXNzLWNvbnN0 cmFpbmVkIGNsaWVudHMuDQoNCk5vLCB0aGF0IGlzIG5vdCBjb3JyZWN0LiBXaGF0IGdhdmUgeW91 IHRoYXQgaW1wcmVzc2lvbj8gSW5zdGVhZCBvZiBtZQ0KZ29pbmcgdGhyb3VnaCBob3cgdmFyaW91 cyBkZXBsb3ltZW50IHNjZW5hcmlvcyBpbiBzZWN0aW9uIDYgY291bGQgYmUgdXNlZA0Kd2l0aCBj b25zdHJhaW5lZCBjbGllbnRzLCBpdCB3b3VsZCBiZSBoZWxwZnVsIGl0IHlvdSBnYXZlIHNvbWUg cmVmZXJlbmNlDQp0byB0aGUgZHJhZnQgc3VwcG9ydGluZyB5b3VyIGNsYWltLiBCdXQganVzdCB0 byBnaXZlIGFuIGV4YW1wbGUgc2VlDQpzZWN0aW9uIDYuMzoNCg0KaHR0cHM6Ly90b29scy5pZXRm Lm9yZy9odG1sL2RyYWZ0LXNlaXR6LWFjZS1vYXV0aC1hdXRoei0wMCNzZWN0aW9uLTYuMw0KDQoN CkluIHRoaXMgY2FzZSB0aGUgaW50ZXJhY3Rpb24gYW5kIHByb2Nlc3NpbmcgcGVyZm9ybWVkIGJ5 IHRoZSBjbGllbnQgY291bGQNCmJlIHJlc3RyaWN0ZWQgdG8gcGFzc2luZyBhIHJlZmVyZW5jZSB0 b2tlbiwgd2hpY2ggY2FuIGJlIG1hZGUgYXJiaXRyYXJpbHkNCnNtYWxsLCB0byB0aGUgcmVzb3Vy Y2Ugc2VydmVyIGFuZCB0aGVuIG1ha2luZyB0aGUgcmVzb3VyY2UgcmVxdWVzdC4gVGhlc2UNCnR3 byByZXF1ZXN0cyBjb3VsZCBldmVuIGJlIGNvbWJpbmVkIGludG8gb25lIHJlcXVlc3QvcmVzcG9u c2UgdXNpbmcNCm9wdGltaXphdGlvbnMgZGVzY3JpYmVkIGluIEFwcGVuZGl4IEIsIHNlZSBmaWd1 cmUgMjMuDQoNCmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1zZWl0ei1hY2Utb2F1 dGgtYXV0aHotMDAjYXBwZW5kaXgtQg0KDQpBcyBvbmUgY29uY3JldGUgdXNlIGNhc2UgdGhlIGNs aWVudCBjb3VsZCBiZSBrZXkgZm9iIHVzaW5nIHJhZGlvIGVuZXJneQ0KaGFydmVzdGluZy4NCg0K R8O2cmFuDQoNCg0KDQo+VGhhdA0KPm1pZ2h0IGJlIGZpbmUgZm9yIHRoZSB1c2UgY2FzZXMgYW5k IGRldmljZXMgdGhhdCB5b3UgaGF2ZSBpbiBtaW5kLiBXaXRoDQo+RENBRiwgd2UgZ28gYSBiaXQg ZnVydGhlciBpbnRvIHRoZSBjb25zdHJhaW5lZCB3b3JsZCBhbmQgd2FudCB0byBlbmFibGUNCj5j b25zdHJhaW5lZCBkZXZpY2VzIHRvIHNlY3VyZWx5IGNvbW11bmljYXRlIHdpdGggb3RoZXIgY29u c3RyYWluZWQgZGV2aWNlcw0KPg0KPk9mIGNvdXJzZSB3ZSB3YW50IERDQUYgdG8gaW50ZXJvcGVy YXRlIHdpdGggZXhpc3RpbmcgcHJvdG9jb2xzLiBUaGF0IGlzDQo+d2h5IHdlIGRlc2NyaWJlIGhv dyBzdWNoIGludGVyYWN0aW9ucyBjYW4gd29yayAoc2VlDQo+ZHJhZnQtZ2VyZGVzLWFjZS1kY2Fm LWV4YW1wbGVzIFsyXSkuDQo+DQo+QmVzdCByZWdhcmRzLA0KPlN0ZWZmaQ0KPg0KPlsxXSBodHRw czovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNzIyOA0KPlsyXSBodHRwczovL3Rvb2xzLmlldGYu b3JnL2h0bWwvZHJhZnQtZ2VyZGVzLWFjZS1kY2FmLWV4YW1wbGVzLTAwDQoNCg== From nobody Sat Oct 31 03:40:51 2015 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82FD31B3700 for ; Sat, 31 Oct 2015 03:40:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.31 X-Spam-Level: X-Spam-Status: No, score=-2.31 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f5kzPSvmst-O for ; Sat, 31 Oct 2015 03:40:47 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (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 95AE71B36FE for ; Sat, 31 Oct 2015 03:40:47 -0700 (PDT) Received: from [192.168.10.226] ([118.243.125.63]) by mail.gmx.com (mrgmx001) with ESMTPSA (Nemesis) id 0LvV1X-1abGL13CFf-010dUu; Sat, 31 Oct 2015 11:40:45 +0100 To: Carsten Bormann , =?UTF-8?Q?G=c3=b6ran_Selander?= References: <56326D0D.9020309@tzi.org> From: Hannes Tschofenig Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9 X-Enigmail-Draft-Status: N1110 Message-ID: <56349AA7.8080309@gmx.net> Date: Sat, 31 Oct 2015 11:40:39 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <56326D0D.9020309@tzi.org> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="D5QSh6DmKv1kf17Ob0W4uMNSI8jrUdXKk" X-Provags-ID: V03:K0:rwil3ls5qKkl0JULq0EeAZaRoskGThJlAh31h+/3TeSVUldMapd o2w843hNZx1ROGFUtGEVg7Lb5a32PDHURp5loX1id3ZaRQsVP1+MR4yAt3QcG8/dXuskP2U afu9N2Mwa68otlDcJg6XlS/oP3zmnPMVfUDxOQkUHlFhofnIkIvLS1v89iyEOsAlIZPSPFg baBGpYqm3B//6p9MsRoqQ== X-UI-Out-Filterresults: notjunk:1;V01:K0:02E73I4jQiU=:hfi+Mzf0CoH6wOXDV74lga 1U1td3AS2I3lqAlswTnPeJRXL3UINTAT82pFN5AzxKIYxomHIAAQttg3Uzkdb61cOUyCBQzS+ tSwi1ytY2+opuMwFYLP1FpRzYvd4M9QtnSt7YUovabmflAwTDChuYy2OuChXd45WkJuGfcGqf sugzGcDGD48ZXjanqMMo4IXORWGA3eD/bwFV7gwju4UyQOR/9JaIl0gJMxpmPN4jlet+Lgonw VzMlcRLiKIYcOdcPzmdyvO36IIUBr+IVHLIaWmCbBd3Mblc3JQWH9LJutRj248tQhkwInoVlQ umvNsb6HUrV+QNH7ThRA1cFNiLcjBJs6BHsPHTfke8inQRFrCtrQ7dDZ3dGFyjR4vjzvxuqvV /bqK5h0n5exSIXWlh8htE3Lg6EL+lfPi4qWOtedfn3LCGw0ZEfTX3dXLJJfh6BfBcis7V+2dt D4xfXX6/b4gcUBFyuU02jDEQN7tg+nWTRb2avRHra+FVJM1+Wxa26gMFlK28Cs38baL5/UWlZ s9Vnb2tqhp0EJmp9lQQVgPYxQi8DlCDaIsnFjTLr4IezJGCa8f0VvYuwh1SXZ1ns4bidwIpDi D6qP/LJEbxXVWRzB+jeuH55lF6gFBP4yhGH1FXJKfWUaT9e5w59T61VE/mDmsYgvBk+B1gSAn 0RHquSOqOp6yb7lhXcICvC1JeGAAFZho/2Bl0zO86WXBrH9LumgBCp0yvGeK8E5Yfm4U1jDxJ hVPnsTkC0UHucOvCcyITXt7FN3KS3kXSOm7YLqPDbt06T8OZ5jaVDWlFt5KyxaiympEDSeU0m SYI+7bqh+oDX8P03pv4Ligi1lCKSy1GgT03KqTM7eUJoz7GKytKtRKUbkmv++AnFQLm5RVI Archived-At: Cc: Olaf Bergmann , "Ace@ietf.org" Subject: Re: [Ace] Innovating X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 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, 31 Oct 2015 10:40:49 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --D5QSh6DmKv1kf17Ob0W4uMNSI8jrUdXKk Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Carsten, I fully understand your attitude. You are a researcher and you have to re-write everything from scratch because it attracts students, allows you to write more publications, and get some additional research funding. In the adhoc networking, ubiquitous computing, IoT space lots of researchers have re-created the world many times and most of it just end up in a trashcan. They got their PhD, received research grants, and everyone is happy. Working in a company the story is a bit different. We have things running and deployed already. We also have a different starting point -- we don't start with a clean slate every 6 months. Just re-writing everything without a lot of improvement does not find a lot of excitement. I need to explain to my co-workers (with a straight face) why I want them to rip out everything. We want to solve problems and so we spent most of our time understanding the problem domain. All I am asking for is to a) understand the state of the art, and b) try to understand the problems we are solving. It appears to me too often that in the end the redesign is more at the level of terminology rather than content. The picture you point us to is an interesting one because it shows the conflict between the clean slate research community and the real world. It turns out that there are more requirements in product design than just technical requirements. I am not sure what the examples below are really supposed to tell us. They could tell us that we made the mistake to re-create things from scratch several times now instead of re-using the existing work and we still haven't learned anything from it. Ciao Hannes PS: Here is a good presentation from Henning about the lack of engineering in the research community: http://www.ubioulu.fi/node/296 On 10/29/2015 08:01 PM, Carsten Bormann wrote: > Much of the IETF work in the constrained space has been about taking a > fresh look instead of succumbing to "because its there" (BIT) arguments= =2E >=20 > 6LoWPAN did not take ROHC, but invented a new header compression > (twice, throwing out the first one after four years). It dared to > make multi-link subnets its standard approach. It did not just take > ND, but modified it into 6LoWPAN-ND. >=20 > ROLL did not take OSPF or IS-IS, but standardized RPL (and can let a > thousand flowers bloom there, as e.g. Thread is using RIP). >=20 > We didn't take HTTP in CoRE, but designed CoAP, using many of the same > principles. >=20 > But of course many other things were taken as is, because: >=20 > -- they do solve the actual problem > -- they don't bring prohibitive baggage/drawbacks > and/or > -- there are substantial network effects from BIT. >=20 > You can read more about this approach in > https://www.iab.org/wp-content/IAB-uploads/2011/04/Bormann.pdf >=20 > A nice illustration of where we were if we weren't doing that is > in http://j.mp/gsD4r7 >=20 > Each time the constrained work entered a new domain (INT, RTG, APP), > there are these heated arguments about not always using the existing > hammers. In Security, BIT arguments are often quite compelling, so > the threshold is probably higher (I'm sure RTG people will disagree). >=20 > Oh, and in the development of both 6LoWPAN-ND and CoAP, we have thrown > out things that had been in the WG document (or even standardized!) > for over a year or longer when better alternatives came along. This > sometimes has been painful, when the old way of doing things already > had been well-accepted and implemented interoperably. I hope we can > do that here, as well. >=20 > Gr=C3=BC=C3=9Fe, Carsten >=20 > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace >=20 --D5QSh6DmKv1kf17Ob0W4uMNSI8jrUdXKk Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJWNJqoAAoJEGhJURNOOiAtv+0H/A5puZVAN0qoxHIViRYdgd1b YH3g/7QJIO5St7olOvXbfzt3QiG3KVFQiXakpPidCFPFELb889Wo1gi4e2fnqrS5 fnt0BIRTvFdc+uc1C8EJgefO9m8TIy52wSChHgl8cEB3ZQ9s1wO0AszrOPRqcQsY gH5zrWlLQa86/MFLo+oq0YTQX3wngyj2oXhul3Qklskl/Ebon4KinJUACq6Vg684 qYrZMS5wGBmcELybWEu8fC+77/FclOa+DmCzr7JSbppqvlxkwGfA3N8XddSLgco/ jDAp7ekCxRBw8iSKswxPaZbXX4KaRzKnkMSE8Dxg3A6Kk/9ANzkVQBM5VgczdVo= =mKob -----END PGP SIGNATURE----- --D5QSh6DmKv1kf17Ob0W4uMNSI8jrUdXKk-- From nobody Sat Oct 31 04:26:08 2015 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73E711B37B3 for ; Sat, 31 Oct 2015 04:26:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.309 X-Spam-Level: X-Spam-Status: No, score=-2.309 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3DWIraKYb_RU for ; Sat, 31 Oct 2015 04:26:03 -0700 (PDT) Received: from smtp.nexusgroup.com (smtp.nexusgroup.com [83.241.133.121]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0D1CA1B37B1 for ; Sat, 31 Oct 2015 04:26:02 -0700 (PDT) Received: from NG-EX01.ad.nexusgroup.com (10.75.28.40) by NG-EX02.ad.nexusgroup.com (10.75.28.43) with Microsoft SMTP Server (TLS) id 15.0.995.29; Sat, 31 Oct 2015 12:26:00 +0100 Received: from NG-EX01.ad.nexusgroup.com ([fe80::1d3d:b319:f020:2bab]) by NG-EX01.ad.nexusgroup.com ([fe80::1d3d:b319:f020:2bab%12]) with mapi id 15.00.0995.032; Sat, 31 Oct 2015 12:26:00 +0100 From: =?Windows-1252?Q?Erik_Wahlstr=F6m_neXus?= To: Rafa Marin Lopez Thread-Topic: [Ace] My comments about draft-seitz-ace-oauth-authz-00 Thread-Index: AQHRExlWwiV4Y/YeDEeI5nTnZK5w/J6Fd6J8 Date: Sat, 31 Oct 2015 11:25:59 +0000 Message-ID: <2D596355-C89B-4162-943C-E049B301D83F@nexusgroup.com> References: <33297FDC-BAA8-402B-80B8-B9CE19991D02@um.es> In-Reply-To: <33297FDC-BAA8-402B-80B8-B9CE19991D02@um.es> Accept-Language: en-US, sv-SE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_2D596355C89B4162943CE049B301D83Fnexusgroupcom_" MIME-Version: 1.0 Archived-At: Cc: "ace@ietf.org" Subject: Re: [Ace] My comments about draft-seitz-ace-oauth-authz-00 X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 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, 31 Oct 2015 11:26:07 -0000 --_000_2D596355C89B4162943CE049B301D83Fnexusgroupcom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Thanks for the review. It's very valuable. See comments below. Sent from my iPhone On 30 Oct 2015, at 14:46, Rafa Marin Lopez > = wrote: Dear authors, all: Here you can find my review about draft-seitz-ace-oauth-authz-00. The document is very detailed, which helps to understand the proposal. In m= y opinion, using a well-known protocol such as OAuth 2.0 where many people = are working and have worked gives maturity and makes comprehensible the pro= posal to a broader audience. I also think it would be good to have some per= formance data (if available) such as message size, processing time , etc=85= . In any case, I believe the usage of OAuth 2.0 is a right and reasonable = path for achieving an ACE solution. Yes. I also thinks that would be valuable and we should add that going forw= ard. Here some more detail comments/questions: In page 3: "This memo describes how to re-use OAuth 2.0 [RFC6749] to extend authorization to Internet of Things devices with different kinds of constrainedness. At the time of writing OAuth 2.0 is already used with certain types of IoT devices and this document will provide..." [Rafa] What types of IoT devices already use OAuth 2.0? A reference with t= his usage of OAuth 2.0 would be helpful. I personally have been working on two but can't show them yet. Hope to be a= ble to show more in 2 weeks. You could also argue for that the API economy = is also good examples where machines talks to machines where I would say th= at oauth2 have become the standard way to protect the communication. "Figure 1: Overview of the basic protocol flow Requesting an Access Token (A):=94 [Rafa] Is there any assumption for the client authentication here? Vanilla Oauth2 supports many types of grant flows. The draft uses client cr= edentials (could be pre provisioned either manually or using something like= dynamic client registration specs from oauth wg). There is no reason for n= ot using other types of credentials for authentication against the AS. "The /token resource (called "endpoint" in OAuth 2.0), defined in Section 3.2 of [RFC6749], is used by the client to obtain an access token. Requests sent to the /token resource use the HTTP POST method=85" [Rafa] Mmmmm=85 if client is constrained =85 will it use HTTP POST? No. It's just bad wordings. Good catch. If the client would not be constrai= ned then http post would do, but otherwise there are coap examples of it in= Figure 2. =936.1 Client and Resource Server are Offline" [Rafa] I realize that offline is sometimes confusing. client and resource s= erver can communicate each other. The AS is offline since it is not reachab= le. But anyway, this is a minor thing. Yes I see the point. We tried our a couple of namings of the examples of di= fferent deployment models using the oauth framework but I guess it still ca= n be worked on a bit more. "A: The client first generates a public-private key pair used for communication security with the RS." [Rafa] In the same section 6.1, you describe the case where client and reso= urce server cannot contact the AS. However you describe the communication w= ith the AS. This might result confusing is shown. Perhaps the interaction w= ith the AS should be placed out of this section. We state in the intro text that it's done priori of the real access request= s. It's still a mandatory step to initialize C and RS. "This access procedure involves steps A, B, C, and F of Figure 1, but assumes that step A and B have been carried out during a phase when the client had connectivity to AS." That could be done in factory, installation or one minute or a lot of years= before depending on the scenario. Page 16 "Figure 5: Access Token including Public Key of the Client. Messages C and F are shown in Figure 6 - Figure 7. C: The client then sends the PoP token to the /authz-info resource at the RS. This is a plain CoAP request, i.e. no DTLS/OSCOAP between client and RS, since the token is integrity protected between AS and RS." [Rafa] I think I am missing something here. A PoP token proves that the cli= ent knows a key (key confirmation). But the reason you give for not using D= TLS/OSCOAP is that the token is integrity protected AS and RS. The client s= hould prove that it owns the key anyway, no? That's done later when the real GET request is sent. In the first request t= he access token is sent to the RS. The token is, as stated, integrity prote= cted by the AS and then verified and stored by the RS. In the later get req= uest the pop key is used by the client to prove to the RS that the client r= eally have access to the key. "The RS verifies that the PoP token was created by a known and trusted AS, is valid, and responds to the client. The RS caches the security context together with authorization information about this client contained in the PoP token." [Rafa] This is related to my previous comment. Is it possible for an attack= er to reply the PoP token? It should not due to PoP token nature but nothin= g is mentioned about it, just the verification that it was created by a tru= sted AS. Maybe my understanding of PoP token is wrong. The token could include a "cti" claim defined in appendix D that talks abou= t cbor web tokens (CWT). That could be used to prevent replays but there ar= e also features in the object security drafts for he same. We should add mo= re details about replays in the security considerations section. "6.3. Token Introspection with an Offline Client" [Rafa] Although token introspection may be an interesting feature, I am thi= nking that sending additional messages from the RS to the AS is not good wh= en RS is constrained. I understand it is a tradeoff between =93authorizatio= n freshness=94 vs additional signaling. Yes. There will be different needs for different deployments. Page 25: "In case 2., the RS does not need to receive any message from the client," [Rafa] I do not understand why the RS does not need to receive any message = from the client=85 could you clarify? "Messages" is actually tokens in this scenario. Hope this helps. It did. Thanks! / Erik Best Regards. ------------------------------------------------------- Rafael Marin Lopez, PhD Dept. Information and Communications Engineering (DIIC) Faculty of Computer Science-University of Murcia 30100 Murcia - Spain Telf: +34868888501 Fax: +34868884151 e-mail: rafa@um.es ------------------------------------------------------- _______________________________________________ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace --_000_2D596355C89B4162943CE049B301D83Fnexusgroupcom_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Thanks for the review. It's very valuable.

See comments below.

Sent from my iPhone

On 30 Oct 2015, at 14:46, Rafa Marin Lopez <rafa@um.es> wrote:

Dear authors, all:

Here you can find my review about draft-seitz-ace-oauth-authz-00.

The document is very detailed, which helps to understand the proposal= . In my opinion, using a well-known protocol such as OAuth 2.0 where many p= eople are working and have worked gives maturity and makes comprehensible t= he proposal to a broader audience. I also think it would be good to have some performance data (if available)= such as message size, processing time , etc=85 . In any case, I believe th= e usage of OAuth 2.0 is a right and reasonable path for achieving an ACE so= lution.

Yes. I also thinks that would be valuable and we should add that going= forward.


Here some more detail comments/questions:

In page 3:

"This memo describes how to re-use OAuth 2.0 [RFC6749] to extend=
  authorization to Internet of Things devices with differen= t kinds of
  constrainedness.  At the time of writing OAuth 2.0 i= s already used
  with certain types of IoT devices and this document will = provide..."

[Rafa]  What types of IoT devices already use OAuth 2.0? A refer= ence with this usage of OAuth 2.0 would be helpful.

I personally have been working on two but can't show them yet. Hope to= be able to show more in 2 weeks. You could also argue for that the API eco= nomy is also good examples where machines talks to machines where I would s= ay that oauth2 have become the standard way to protect the communication.




"Figure 1: Overview of the basic protocol flow

  Requesting an Access Token (A):=94

[Rafa] Is there any assumption for the client authentication here?

Vanilla Oauth2 supports many types of grant flows. The draft uses client cr= edentials (could be pre provisioned either manually or using something like= dynamic client registration specs from oauth wg). There is no reason for n= ot using other types of credentials for authentication against the AS.



"The /token resource (called "endpoint" in OAuth 2.0),= defined in
  Section 3.2 of [RFC6749], is used by the client to obtain= an access
  token.  Requests sent to the /token resource use the= HTTP POST method=85"

[Rafa] Mmmmm=85 if client is constrained =85 will it use HTTP POST? <= /span>

No. It's just bad wordings. Good catch. If the client would not be con= strained then http post would do, but otherwise there are coap examples of = it in Figure 2.


=936.1 Client and Resource Server are Offline"

[Rafa] I realize that offline is sometimes confusing. client and reso= urce server can communicate each other. The AS is offline since it is not r= eachable. But anyway, this is a minor thing.

Yes I see the point. We tried our a couple of namings of the examples = of different deployment models using the oauth framework but I guess it sti= ll can be worked on a bit more.


"A: The client first generates a public-private key pair used fo= r
     communication security with the RS.&quo= t;

[Rafa] In the same section 6.1, you describe the case where client an= d resource server cannot contact the AS. However you describe the communica= tion with the AS. This might result confusing is shown. Perhaps the interac= tion with the AS should be placed out of this section.

We state in the intro text that it's done priori of the real access re= quests. It's still a mandatory step to initialize C and RS.

"This a= ccess procedure involves
   steps A, =
B, C, and F of Figure 1, but assumes that step A and B have
   been carried out during a phase when the client had connectivity to
   AS."


That could be done in factory, installation or one minute or a lot of years= before depending on the scenario.


Page 16

"Figure 5: Access Token including Public Key of the Client.

  Messages C and F are shown in Figure 6 - Figure 7.=

     C: The client then sends the PoP token = to the /authz-info resource
     at the RS.  This is a plain CoAP r= equest, i.e. no DTLS/OSCOAP
     between client and RS, since the token = is integrity protected
     between AS and RS."  <= br>
[Rafa] I think I am missing something here. A PoP token proves that t= he client knows a key (key confirmation). But the reason you give for not u= sing DTLS/OSCOAP is that the token is integrity protected AS and RS. The cl= ient should prove that it owns the key anyway, no?

That's done later when the real GET request is sent. In the first requ= est the access token is sent to the RS. The token is, as stated, integrity = protected by the AS and then verified and stored by the RS. In the later ge= t request the pop key is used by the client to prove to the RS that the client really have access to the ke= y.


"The RS verifies that the PoP token was created
     by a known and trusted AS, is valid, an= d responds to the client.
     The RS caches the security context toge= ther with authorization
     information about this client contained= in the PoP token."

[Rafa] This is related to my previous comment. Is it possible for an = attacker to reply the PoP token? It should not due to PoP token nature but = nothing is mentioned about it, just the verification that it was created by= a trusted AS. Maybe my understanding of PoP token is wrong.

The token could include a "cti" claim defined in appendix D = that talks about cbor web tokens (CWT). That could be used to prevent repla= ys but there are also features in the object security drafts for he same. W= e should add more details about replays in the security considerations section.



"6.3.  Token Introspection with an Offline Client"

[Rafa] Although token introspection may be an interesting feature, I = am thinking that sending additional messages from the RS to the AS is not g= ood when RS is constrained. I understand it is a tradeoff between =93author= ization freshness=94 vs additional signaling.

Yes. There will be different needs for different deployments.


Page 25: "In case 2., the RS does not need to receive any messag= e from the
  client,"

[Rafa] I do not understand why the RS does not need to receive any me= ssage from the client=85 could you clarify?

"Messages" is actually tokens in this scenario.

Hope this helps.

It did. Thanks!

/ Erik


Best Regards.

-------------------------------------------------------
Rafael Marin Lopez, PhD
Dept. Information and Communications Engineering (DIIC)
Faculty of Computer Science-University of Murcia
30100 Murcia - Spain
Telf: +34868888501 Fax: +34868884151 e-mail: rafa@um.es
-------------------------------------------------------




_______________________________________________
Ace mailing list
Ace@ietf.org
https://www.iet= f.org/mailman/listinfo/ace
--_000_2D596355C89B4162943CE049B301D83Fnexusgroupcom_-- From nobody Sat Oct 31 05:03:58 2015 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54F5C1A8AF7 for ; Sat, 31 Oct 2015 05:03:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6ttYsetd6RiO for ; Sat, 31 Oct 2015 05:03:54 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (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 9A8C71A8ACC for ; Sat, 31 Oct 2015 05:03:54 -0700 (PDT) Received: from [192.168.10.226] ([118.243.125.63]) by mail.gmx.com (mrgmx002) with ESMTPSA (Nemesis) id 0MQR3s-1a2Pzv1liG-00TpQY; Sat, 31 Oct 2015 13:03:44 +0100 To: Rafa Marin Lopez , ace@ietf.org References: <33297FDC-BAA8-402B-80B8-B9CE19991D02@um.es> From: Hannes Tschofenig Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9 X-Enigmail-Draft-Status: N1110 Message-ID: <5634AE1B.5010609@gmx.net> Date: Sat, 31 Oct 2015 13:03:39 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <33297FDC-BAA8-402B-80B8-B9CE19991D02@um.es> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="6lpjs4PrguOXJ0eAFqCo9jh7m6K5jro2v" X-Provags-ID: V03:K0:JNwmNnJykxER5gG95zaeEDtnswx3PD6Iij9681oLMxW5Rq4ie31 W0+fL2uy62ixw3StzJfeZo4cUaEKfSBM+IS5ceeNiUagoAaSvNeOvQ/BnaWDqpzl11ustH/ kHc5qCOwjKEG3C0vg3QCCLJZ+5gbCPHRuyA2+alVTDhPEv7S2A/8bXEYRMQ3hrvmlu9th+V pnVJEDKntUSq68RtksI9g== X-UI-Out-Filterresults: notjunk:1;V01:K0:1aaji0mCWZg=:OkIBp1S1K7LHDQ13HwHA1S r4lsJK4fNNjWbXv+81sJdtDgY3hVybk39WhdB0zJjyojE1tnKp46HZ44/6NtH/UGzwb3ELlli r/ZJjsw+wVWRCpYZAsnfBQahN4TStTTtPNuUImEqvlEQ8KM0h77h2CBx/jpS1fektV5WNZHL+ Y6Ydy64wPaOjotvga8nH9BK7LzyuoPVJGEsFp2PP2slqT6zEb8WR3bZfKqc4HTDOKyIKHMJh/ RXf/hu6g4t9Ph/9G/WKf9h6s0IwDN38apITT850UX40ZWZMjIzsg24PjKCPfCJlZ0USggkq93 g90e0LRw9tEeiNLfj00YvJopeTv3jglAXsXrWO/ok+yfp6/al/fIGC4QENCJGqw/vXg77LSrs D0nxwf88fo8LUFodiiHiH6D0TcyIa/dlVZQcFu3QpXefWAbKZ+ldUpZgV5aVdL4krkMmbXw05 5D/cdoQyXkQ92/FXj/2ysHsl2VdK/MudDKFSw0FdXG34MUF6ygOw4mHoIZiV1slB3Huh2dkZ3 9BOscl85VOAxEok1H4IXfjFhVR0ZpK9unM2tIeDCbZ43drVp92fD8DFwINQLJcRZrmLfbeGw8 Yl8GE1Bz35xupu337QPE6HxYYjWyDHQZAnBfYaE4Bh2J2xC1b4cMeltCJ/tgi6M5u7Rd12uWx /giRH5QjMnfZPzmAxnDKfsd7dT/wht4GBqSLzIl+q+26oQ8sFiALVSb6dXZhngm8nhkuOyD/o +mFPVUZbp956uMo1kWX1XL8Ul0sjnM1xi9HopjGnJnTgu1KSroKHImrYui4= Archived-At: Subject: Re: [Ace] My comments about draft-seitz-ace-oauth-authz-00 X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 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, 31 Oct 2015 12:03:57 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --6lpjs4PrguOXJ0eAFqCo9jh7m6K5jro2v Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Rafa, thanks for you review. Since you have contributed the EAP-based solution to the group I was obviously very interested to hear your opinion. Responses inline: On 10/30/2015 02:46 PM, Rafa Marin Lopez wrote: > Dear authors, all: >=20 > Here you can find my review about draft-seitz-ace-oauth-authz-00. >=20 > The document is very detailed, which helps to understand the > proposal. In my opinion, using a well-known protocol such as OAuth > 2.0 where many people are working and have worked gives maturity and > makes comprehensible the proposal to a broader audience. I also think > it would be good to have some performance data (if available) such as > message size, processing time , etc=E2=80=A6 . In any case, I believe t= he > usage of OAuth 2.0 is a right and reasonable path for achieving an > ACE solution. Thanks for the positive feedback. Regarding the performance data we can put some figures together based on what we have been playing with. In fact, we (Erik/Samuel from Nexus Technology and ARM) are going to show a demo of OAuth for a home automation scenario at the upcoming ARM TechCon event. Forgerock will also show OAuth-based scenarios at the same event. What is difficult with the performance data is that it depends a bit on the assumptions made for the scenario. For example, in our case we are using Bluetooth Smart with a custom BLE service for the communication between an Android phone and an IoT device. The custom BLE service uses JOSE, which is quite naturally more heavy than the COSE solution currently being developed. While we didn't see problems with the JOSE solution so far we could replace it with COSE reducing the number of bits on the wire. For the data exchanged between the phone and the authorization server it again depends what user experience is offered and what authentication mechanism is utilized. In a nutshell, there is more than just counting bits on the wire there. >=20 > Here some more detail comments/questions: >=20 > In page 3: >=20 > "This memo describes how to re-use OAuth 2.0 [RFC6749] to extend=20 > authorization to Internet of Things devices with different kinds of=20 > constrainedness. At the time of writing OAuth 2.0 is already used=20 > with certain types of IoT devices and this document will provide..." >=20 > [Rafa] What types of IoT devices already use OAuth 2.0? A reference > with this usage of OAuth 2.0 would be helpful. >=20 There are a number of different communication scenarios, as outlined in the recent ISOC publication: http://www.internetsociety.org/sites/default/files/ISOC-IoT-Overview-2015= 1022.pdf For the "Back-End Data-Sharing Model", described on page 16, OAuth is used quite frequently. This is also pretty reasonable since many companies seek to share data they collect from IoT devices (with the permission of the user). Here is an example from the vehicle environment:= https://developer.carvoyant.com/io-docs I have shared other examples from the fitness / wearable sector previousl= y. Also for devices that have a user interface but limited input capabilities OAuth has been used. Here are two examples: https://developers.facebook.com/docs/facebook-login/for-devices https://developers.google.com/youtube/v3/guides/auth/devices This "Device-to-Cloud Communications" scenario is described on page 14 in the ISOC paper. In general, in terms of deployment it is more common for IoT devices to communicate with some gateway or a cloud-based service rather than having IoT devices communicate directly with each other. >=20 > "Figure 1: Overview of the basic protocol flow >=20 > Requesting an Access Token (A):=E2=80=9D >=20 > [Rafa] Is there any assumption for the client authentication here? Yes, the client has to be authenticated prior to get an access token. There is also the consent aspect here, which may require authentication of a human. The client credentials are provisioned to the device either upfront (for example during manufacturing) or the client is registered dynamically (which is what we have the dynamic client registration for). When we wrote the UMA for IoT document there we also had spoke about the need to consider cases where the consent comes up-front. For this document we didn't want to go into that level of detail since these scenarios are a bit more sophisticated and we already have this other document available. For this write-up we have taken the approach that the reader knows very little about the OAuth landscape. >=20 > "The /token resource (called "endpoint" in OAuth 2.0), defined in=20 > Section 3.2 of [RFC6749], is used by the client to obtain an access=20 > token. Requests sent to the /token resource use the HTTP POST > method=E2=80=A6" >=20 > [Rafa] Mmmmm=E2=80=A6 if client is constrained =E2=80=A6 will it use HT= TP POST? In this document we offer the choice to either use HTTP or CoAP. We are exploring the use of HTTP/2 and QUIC. But keep in mind that in most scenarios not everything is constrained. For example, you might have a person in a smart home using his phone or table to control lights and other devices. Their phone can very well use HTTP without any problems. >=20 > =E2=80=9C6.1 Client and Resource Server are Offline" >=20 > [Rafa] I realize that offline is sometimes confusing. client and > resource server can communicate each other. The AS is offline since > it is not reachable. But anyway, this is a minor thing. That's a good point, which we may need to describe a bit more. With the requirements outlined in our group it is obviously not possible to have a scenario where everything is fully offline and we wouldn't really be talking about IoT then anyway (but rather about embedded devices). Here the distinction is whether the resource server is able to contact the authorization server at the time of the resource request. The client still has to be able to obtain the access token at some point in time. There is, of course, also a tradeoff between the ability to revoke granted permissions in real-time vs. being offline. >=20 > "A: The client first generates a public-private key pair used for=20 > communication security with the RS." >=20 > [Rafa] In the same section 6.1, you describe the case where client > and resource server cannot contact the AS. However you describe the > communication with the AS. This might result confusing is shown. > Perhaps the interaction with the AS should be placed out of this > section. I guess this is the same issue as with the previous comment. I believe we need to describe more clearly what we mean by offline. I think the qualification "offline during the time of the resource access" might describe it better. >=20 > Page 16 >=20 > "Figure 5: Access Token including Public Key of the Client. >=20 > Messages C and F are shown in Figure 6 - Figure 7. >=20 > C: The client then sends the PoP token to the /authz-info resource at > the RS. This is a plain CoAP request, i.e. no DTLS/OSCOAP between > client and RS, since the token is integrity protected between AS and > RS." >=20 > [Rafa] I think I am missing something here. A PoP token proves that > the client knows a key (key confirmation). But the reason you give > for not using DTLS/OSCOAP is that the token is integrity protected AS > and RS. The client should prove that it owns the key anyway, no? >=20 > "The RS verifies that the PoP token was created by a known and > trusted AS, is valid, and responds to the client. The RS caches the > security context together with authorization information about this > client contained in the PoP token." >=20 > [Rafa] This is related to my previous comment. Is it possible for an > attacker to reply the PoP token? It should not due to PoP token > nature but nothing is mentioned about it, just the verification that > it was created by a trusted AS. Maybe my understanding of PoP token > is wrong. >=20 This is a very good comment since I had to fight with this issue as well. Here is the issue. If you look at the way how things work in HTTP then you would include the token with the (initial) resource request. We ideally want to have the same pattern also in CoAP and CoAP is supposed to be designed like HTTP. However, as it turns out there are some issues in terms of size limitations. Hence, it may be necessary to send the token to a special authorization endpoint first before making the resource request. While I do not quite like that design I believe it is a side-effect of the CoAP design. >=20 > "6.3. Token Introspection with an Offline Client" >=20 > [Rafa] Although token introspection may be an interesting feature, I > am thinking that sending additional messages from the RS to the AS is > not good when RS is constrained. I understand it is a tradeoff > between =E2=80=9Cauthorization freshness=E2=80=9D vs additional signali= ng. Yes, there is a tradeoff here and we allow those who deploy the protocol to decide themselves about this tradeoff. >=20 > Page 25: "In case 2., the RS does not need to receive any message > from the client," >=20 > [Rafa] I do not understand why the RS does not need to receive any > message from the client=E2=80=A6 could you clarify? I let Goeran respond to this comment since it relates to the publish subscribe model. Ciao Hannes >=20 > Hope this helps. >=20 > Best Regards. >=20 > ------------------------------------------------------- Rafael Marin > Lopez, PhD Dept. Information and Communications Engineering (DIIC)=20 > Faculty of Computer Science-University of Murcia 30100 Murcia - > Spain Telf: +34868888501 Fax: +34868884151 e-mail: rafa@um.es=20 > ------------------------------------------------------- >=20 >=20 >=20 >=20 > _______________________________________________ Ace mailing list=20 > Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace >=20 --6lpjs4PrguOXJ0eAFqCo9jh7m6K5jro2v Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJWNK4bAAoJEGhJURNOOiAtKNAH/3NUTWbWEG1WpbeE3CG4xAQ7 EHMw1cK1X3Cql2S49e5ZMEyd1UTAmEx9asGEibKHRpoSb+tz1o3lLSvPDbryzhiU iO7OI1yPx4Rj3G3LPuHSbcjoyj2dYkzt314x3TuEKH+NGfxe9sGUoGF9fBL0oVfp VS+UJy4ABFSbfjHzJIDFvUX4IRbK+VcuTLRrBXJpnpP7DxGxmYwfLNBxXMq4PYUI 4AWgHJiK4i49B0qOetFzhvDUcEZzyPJeGw96oj21B4Hepu+VY4iin6zObijR3nIY AxAjHnJOVcR7qhwuJVJ4gt675Hpv47qw8JMbze0w23YCo9cw7YfIDIEqbBbRVY4= =+k7b -----END PGP SIGNATURE----- --6lpjs4PrguOXJ0eAFqCo9jh7m6K5jro2v-- From nobody Sat Oct 31 06:32:12 2015 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 918621B2BF5 for ; Sat, 31 Oct 2015 06:32:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VzeDzvMv3ZY7 for ; Sat, 31 Oct 2015 06:32:08 -0700 (PDT) Received: from out4133-34.mail.aliyun.com (out4133-34.mail.aliyun.com [42.120.133.34]) by ietfa.amsl.com (Postfix) with ESMTP id 5DAF11B2BBE for ; Sat, 31 Oct 2015 06:32:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alibaba-inc.com; s=default; t=1446298322; h=Date:Subject:From:To:Message-ID:Mime-version:Content-type; bh=fBqPgqlk/XVWnXh76Z81uerrTR+MwUHDTtySLAHLd80=; b=qigI3Ck24bhY4pBHRChO8zGLNIwXV76O0PhqL3A4TwuQ41/uDgW8oVyDFjj46N/gP/4NMJVN/eaGgEytnam54PwwTLN7Eezw9EGwdRDzvHurd8qgpYkz6Dl+cJ/PP1QDNF+KSmuqCk0Ml5pWRXemxRG0SM9GU5bgabe7ERLF1sM= X-Alimail-AntiSpam: AC=PASS; BC=-1|-1; BR=01201311R141e4; FP=0|-1|-1|-1|0|-1|-1|-1; HT=e02c03301; MF=kepeng.lkp@alibaba-inc.com; NM=1; PH=DS; RN=1; SR=0; Received: from 10.22.59.48(mailfrom:kepeng.lkp@alibaba-inc.com ip:42.120.73.208) by smtp.aliyun-inc.com(127.0.0.1); Sat, 31 Oct 2015 21:32:00 +0800 User-Agent: Microsoft-MacOutlook/14.4.8.150116 Date: Sat, 31 Oct 2015 22:31:52 +0800 From: "Kepeng Li" To: "Ace@ietf.org" Message-ID: Thread-Topic: ACE meeting agenda Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3529175520_10426188" Archived-At: Subject: [Ace] ACE meeting agenda X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 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, 31 Oct 2015 13:32:11 -0000 > ʼʹ MIME ʽʼĶʶ ˸ʽˣ޷ʶʼķֲ򲿷ݡ --B_3529175520_10426188 Content-type: text/plain; charset="GB2312" Content-transfer-encoding: quoted-printable Please have a look at the meeting agenda for our ACE meeting: https://www.ietf.org/proceedings/94/agenda/agenda-94-ace ----- ACE WG Meeting IETF 94 - Yokohama Monday, November 2, 2015, 9:00 - 11:30 CDT Chairs: Kepeng Li, Hannes Tschofenig * Agenda Bashing (Chairs, 5 min) * Actors (Carsten Bormann, 15 min) - http://datatracker.ietf.org/doc/draft-ietf-ace-actors/ * DCAF (Stefanie Gerdes, 20 mins) - https://tools.ietf.org/html/draft-gerdes-ace-dcaf-authorize-04 - https://tools.ietf.org/id/draft-gerdes-ace-dcaf-sitr-00.txt * ACE Solutions (Jorge Cuellar, 20 mins) - https://datatracker.ietf.org/doc/draft-cuellar-ace-solutions/ -=20 https://datatracker.ietf.org/doc/draft-cuellar-ace-pat-priv-enhanced-authz-= t okens/ * Authorization using OAuth 2.0 (Ludwig Seitz, 20 min) - https://datatracker.ietf.org/doc/draft-seitz-ace-oauth-authz/ * Discussion about the solution direction (all, 55 min) * DCAF COSE (Stefanie Gerdes, 10 mins) - https://datatracker.ietf.org/doc/draft-bergmann-ace-dcaf-cose/ * Wrap-up (Chairs, 5 min) ------ Our main goal is to make decision about the direction (e.g. DCAF, OAuth Profiling, DCAF and OAuth Profiling combinations, or others ) for the solution work.=20 If you have other solution proposals to be presented in the meeting, please let us know ASAP. About the DCAF COSE, we list it in the end to let the authors to introduce it briefly, to get some initial feedback, but we don=A1=AFt make any decision this time. Authors, please send your slides to Hannes and me ASAP. Our meeting starts at 9:00 AM on Monday. We don=A1=AFt have too much time left. Thanks! Ciao Kepeng & Hannes --B_3529175520_10426188 Content-type: text/html; charset="GB2312" Content-transfer-encoding: quoted-printable
Please have a look at the meeting = agenda for our ACE meeting:
<= font face=3D"Courier">
-----
ACE WG Meeting
IETF 94 - Yokohama
Monday, November 2, 2015, 9:00 - 11:30 CDT
Chairs: Kepeng Li, Hannes Tschofenig

* Agenda Bashing (Chairs, 5 min)

* Actors (Carsten Bormann, 15 min)
- http://datatracker.ietf.org/doc/draft-ietf-ace-actors/

* DCAF (Stefanie Gerdes, 20 mins)
- https://tools.ietf.org/html/draft-gerdes-ace-dcaf-authorize-04
- https://tools.ietf.org/id/draft-gerdes-ace-dcaf-sitr-00.txt

* ACE Solutions (Jorge Cuellar, 20 mins)
- https://datatracker.ietf.org/doc/draft-cuellar-ace-solutions/
- https://datatracker.ietf.org/doc/draft-cuellar-ace-pat-priv-enhanced-auth=
z-tokens/

* Authorization using OAuth 2.0 (Ludwig Seitz, 20 min)
- https://datatracker.ietf.org/doc/draft-seitz-ace-oauth-authz/

* Discussion about the solution direction (all, 55 min)

* DCAF COSE (Stefanie Gerdes, 10 mins)
- https://datatracker.ietf.org/doc/draft-bergmann-ace-dcaf-cose/

* Wrap-up (Chairs, 5 min)
------

Our main goal is to make decision about the direction= (e.g. DCAF, OAuth Profiling, DCAF and OAuth Profiling combinations, or= others ) for the solution work. 

If you have othe= r solution proposals to be presented in the meeting, please let us know ASAP= .

About the DCAF COSE, we list it in the end to let the= authors to introduce it briefly, to get some initial feedback, but we don&#= 8217;t make any decision this time.

Authors, please send your slides to Hannes and me ASAP. Our meeti= ng starts at 9:00 AM on Monday. We don’t have too much time left.

Thanks!

Ciao
Kepeng & Hann= es
--B_3529175520_10426188-- From nobody Sat Oct 31 14:38:02 2015 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8747E1B38F2 for ; Sat, 31 Oct 2015 14:38:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.911 X-Spam-Level: X-Spam-Status: No, score=-6.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yD9qiUboFfQT for ; Sat, 31 Oct 2015 14:38:00 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpgre-esg-01.alcatel-lucent.com [135.245.210.22]) (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 5592B1B3890 for ; Sat, 31 Oct 2015 14:38:00 -0700 (PDT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (unknown [135.239.2.122]) by Websense Email Security Gateway with ESMTPS id 5F6772BF358B6 for ; Sat, 31 Oct 2015 21:37:54 +0000 (GMT) Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id t9VLbv57024756 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Sat, 31 Oct 2015 22:37:58 +0100 Received: from FR711WXCHMBA08.zeu.alcatel-lucent.com ([169.254.4.234]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.03.0195.001; Sat, 31 Oct 2015 22:37:57 +0100 From: "FOSSATI, Thomas (Thomas)" To: "ace@ietf.org" Thread-Topic: Review of draft-seitz-ace-oauth-authz-00 Thread-Index: AQHRFCRodxe034Q+Sk6DI1vakws4lg== Date: Sat, 31 Oct 2015 21:37:57 +0000 Message-ID: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.7.151005 x-originating-ip: [135.239.27.39] Content-Type: text/plain; charset="us-ascii" Content-ID: <035E3A6A8661FB4C906AB0B2420F79C8@exchange.lucent.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [Ace] Review of draft-seitz-ace-oauth-authz-00 X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 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, 31 Oct 2015 21:38:01 -0000 Hi all, We reviewed draft-seitz-ace-oauth-authz-00 and sent our editorial comments to the authors off-list already. Our main concern was to make sure that the proposal were compatible with the LWM2M architecture. In fact, this seems to be the case, although it would require a bit of work to the LWM2M specification to integrate it. Our suggestion to the authors is to add an appendix detailing a LWM2M integration. Overall the draft looks very nice; thank you all for the good work. Cheers, Thomas and Tim. From nobody Sat Oct 31 15:34:02 2015 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 ABDBF1A899D; Wed, 21 Oct 2015 11:23:33 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Ben Campbell" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.6.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151021182333.7911.40602.idtracker@ietfa.amsl.com> Date: Wed, 21 Oct 2015 11:23:33 -0700 Archived-At: X-Mailman-Approved-At: Sat, 31 Oct 2015 15:33:59 -0700 Cc: Hannes.Tschofenig@gmx.net, ace-chairs@ietf.org, ace@ietf.org, draft-ietf-ace-usecases@ietf.org Subject: [Ace] Ben Campbell's Yes on draft-ietf-ace-usecases-09: (with COMMENT) X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Oct 2015 18:23:37 -0000 Ben Campbell has entered the following ballot position for draft-ietf-ace-usecases-09: Yes When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-ace-usecases/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- While I'm not ordinarily a big fan of publishing use cases as RFCs, I think this one has value. Otherwise, I have only a few minor comments: -Please expand ACE in the title, abstract, and body. - 2.6.1: Is it reasonable to expect wearable devices to have what sound like multi-user-profile capabilities? - 2.7: An informational reference for stuxnet might be helpful. From nobody Sat Oct 31 15:34:03 2015 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84C841A8A52; Wed, 21 Oct 2015 11:36:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qjrHvpWFOvY0; Wed, 21 Oct 2015 11:36:43 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 CEA8A1A8A58; Wed, 21 Oct 2015 11:36:43 -0700 (PDT) Received: from [10.0.1.9] (cpe-70-119-203-4.tx.res.rr.com [70.119.203.4]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id t9LIaZgV018327 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 21 Oct 2015 13:36:35 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-70-119-203-4.tx.res.rr.com [70.119.203.4] claimed to be [10.0.1.9] From: "Ben Campbell" To: "Kathleen Moriarty" Date: Wed, 21 Oct 2015 13:36:35 -0500 Message-ID: In-Reply-To: References: <20151021182333.7911.40602.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.2r5141) Archived-At: X-Mailman-Approved-At: Sat, 31 Oct 2015 15:33:59 -0700 Cc: ace-chairs@ietf.org, Hannes Tschofenig , draft-ietf-ace-usecases@ietf.org, The IESG , "ace@ietf.org" Subject: Re: [Ace] Ben Campbell's Yes on draft-ietf-ace-usecases-09: (with COMMENT) X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 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, 21 Oct 2015 18:36:46 -0000 On 21 Oct 2015, at 13:34, Kathleen Moriarty wrote: >> - 2.7: An informational reference for stuxnet might be helpful. > > > Agreed, this would be helpful for some readers. Can you queue up the > addition so we have a version ready to go with the changes needed from > reviews? Hi, Does the "you" in that sentence refer to the authors, or to me? (perhaps to propose a reference?) Ben. From nobody Sat Oct 31 15:34:05 2015 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 BAFD81B2C4A for ; Fri, 30 Oct 2015 06:23:08 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: X-Test-IDTracker: no X-IETF-IDTracker: 6.7.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151030132308.13611.67709.idtracker@ietfa.amsl.com> Date: Fri, 30 Oct 2015 06:23:08 -0700 From: IETF Secretariat Archived-At: X-Mailman-Approved-At: Sat, 31 Oct 2015 15:33:59 -0700 Subject: [Ace] Milestones changed for ace WG X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Oct 2015 13:23:08 -0000 Changed milestone "Submit "An Architecture for Authorization in Constrained Environments" as a WG item.", set state to active from review, accepting new milestone. Changed milestone "Submit "An Architecture for Authorization in Constrained Environments" to the IESG for publication as a Informational RFC.", set state to active from review, accepting new milestone. Changed milestone "Submit "Authentication and Authorization for ACE" specification as a WG item.", set state to active from review, accepting new milestone. URL: https://datatracker.ietf.org/wg/ace/charter/ From nobody Sat Oct 31 19:41:26 2015 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CC931B3260 for ; Sat, 31 Oct 2015 19:41:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JYdwh1OyRmai for ; Sat, 31 Oct 2015 19:41:23 -0700 (PDT) Received: from out4133-114.mail.aliyun.com (out4133-114.mail.aliyun.com [42.120.133.114]) by ietfa.amsl.com (Postfix) with ESMTP id 6BCE91B325F for ; Sat, 31 Oct 2015 19:41:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alibaba-inc.com; s=default; t=1446345682; h=Date:Subject:From:To:Message-ID:Mime-version:Content-type; bh=olrDS5lpQ6+SwVPJVaa6N9kiA1/mLQ9E0vcGvVFdX3Q=; b=venUAo01A+mDDl3Ak6QI5bQ3WLLi/Nos1ZBmAyShmEBodnenjGmYd1fUfz3x8u85QkbbFIZY9s5UXuTMpZKpmjKVaM1z3osCZ6IA8OEme6Ye9oELQGJqGovpW0lGrdzfyw/+Gtp1rFqGPFu+f4BglUC4CF2G3G5VJgRSYOuJU9I= X-Alimail-AntiSpam: AC=PASS; BC=-1|-1; BR=01201311R111e4; FP=0|-1|-1|-1|0|-1|-1|-1; HT=e02c03311; MF=kepeng.lkp@alibaba-inc.com; NM=1; PH=DS; RN=1; SR=0; Received: from 10.22.55.22(mailfrom:kepeng.lkp@alibaba-inc.com ip:42.120.73.208) by smtp.aliyun-inc.com(127.0.0.1); Sun, 01 Nov 2015 10:41:20 +0800 User-Agent: Microsoft-MacOutlook/14.4.8.150116 Date: Sun, 01 Nov 2015 11:41:16 +0800 From: "Kepeng Li" To: "Ace@ietf.org" Message-ID: Thread-Topic: Solution comparison Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3529222880_10997365" Archived-At: Subject: [Ace] Solution comparison X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 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: Sun, 01 Nov 2015 02:41:25 -0000 > ʼʹ MIME ʽʼĶʶ ˸ʽˣ޷ʶʼķֲ򲿷ݡ --B_3529222880_10997365 Content-type: text/plain; charset="GB2312" Content-transfer-encoding: quoted-printable I uploaded the chairs slides for the ACE session tomorrow morning. The last slide is the solution comparison table: https://www.ietf.org/proceedings/94/slides/slides-94-ace-0.pdf The purpose is to help people to get the high level view of the solution comparison and facilitate the discussion. Note that I did this in a quite short time. This is an initial version, and I didn=A1=AFt discuss the details with Hannes yet. Please feel free to provide your corrections / suggestions / improvements. Thanks, Kind Regards Kepeng --B_3529222880_10997365 Content-type: text/html; charset="GB2312" Content-transfer-encoding: quoted-printable
I uploaded the chairs slides for= the ACE session tomorrow morning.

The last slide i= s the solution comparison table:

The purpose is = to help people to get the high level view of the solution comparison and fac= ilitate the discussion.

Note that I did this = in a quite short time. This is an initial version, and I didn’t discus= s the details with Hannes yet.

Please feel free to = provide your corrections / suggestions / improvements.

<= div>Thanks,

Kind Regards
Kepeng
--B_3529222880_10997365--