From nobody Tue Sep 1 06:16: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 79B501B52B1; Tue, 1 Sep 2015 06:16:42 -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 zHYxfD9uqPFl; Tue, 1 Sep 2015 06:16:40 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2AD371B5201; Tue, 1 Sep 2015 06:16:40 -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: <20150901131640.16277.2871.idtracker@ietfa.amsl.com> Date: Tue, 01 Sep 2015 06:16:40 -0700 Archived-At: Cc: ace@ietf.org Subject: [Ace] I-D Action: draft-ietf-ace-usecases-05.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: Tue, 01 Sep 2015 13:16:42 -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-05.txt Pages : 27 Date : 2015-09-01 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 comprises a collection of representative use cases for the application of authentication and authorization in constrained environments. These use cases aim at identifying authorization problems that arise during the lifecylce 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-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ace-usecases-05 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 Tue Sep 1 06:19: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 89FAE1B387E for ; Tue, 1 Sep 2015 06:18:59 -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 G21_yBAnVAMo for ; Tue, 1 Sep 2015 06:18:57 -0700 (PDT) Received: from mail-la0-f46.google.com (mail-la0-f46.google.com [209.85.215.46]) (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 2361D1B2FCE for ; Tue, 1 Sep 2015 06:18:57 -0700 (PDT) Received: by laba3 with SMTP id a3so92248574lab.1 for ; Tue, 01 Sep 2015 06:18:55 -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=hJrwTZj5uS6Pi7pFMLTUU0b/yw2UwO+kXGGw4WfrIjI=; b=nHeVtsv9bNXYShZfsOCQeYXjumHHWOzEoHYX1cpmDHjm6XT2U3+Mg3mzJOGtwekXtw rVSVZw3WjmdNuwr5gbxN8ou2dHqxTCdf3G6srTx4biunkcsdlgzRejIJP+D4XjEyI+ai WFi/F9o+9uSFsKZxnxxsmsekOvCpX9i3ZNBRk3tSJeTcwmDoyPDUk7muPQdnTLsueugb XJycE1NLzn1t8SsWYQ+rs3yRswbXXhTpXORNEfRvxrVImz4aXQpCa7U+Rvjgywf3MI3h FZlSSX/27n/MHFdhO41Y+qS+j+BAcYVjl7Adhr9xItJcOcU0wgQ5wsp/QY0X1KAV8kXW 05MQ== X-Gm-Message-State: ALoCoQkiCZjG4lfwza7LoCXzNN7NVUS49T9lB2R5+8+6J9L0knEusnN7CrBY6+1rSxzsNPzQl4VV X-Received: by 10.152.23.103 with SMTP id l7mr13490624laf.50.1441113535363; Tue, 01 Sep 2015 06:18:55 -0700 (PDT) Received: from [192.168.0.108] ([85.235.11.178]) by smtp.gmail.com with ESMTPSA id n6sm4786669laf.18.2015.09.01.06.18.54 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 01 Sep 2015 06:18:54 -0700 (PDT) References: <20150901131640.16277.84774.idtracker@ietfa.amsl.com> To: "ace@ietf.org" From: Ludwig Seitz X-Forwarded-Message-Id: <20150901131640.16277.84774.idtracker@ietfa.amsl.com> Message-ID: <55E5A5BE.4040007@sics.se> Date: Tue, 1 Sep 2015 15:18:54 +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: <20150901131640.16277.84774.idtracker@ietfa.amsl.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms030800010702040002040205" Archived-At: Subject: [Ace] Fwd: New Version Notification for draft-ietf-ace-usecases-05.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, 01 Sep 2015 13:18:59 -0000 This is a cryptographically signed message in MIME format. --------------ms030800010702040002040205 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Hello ACE, We have submitted a new version of the use-cases draft. This version=20 addresses comments by Kepeng Li and Jim Schaad. It also includes the=20 public safety use case provided by Rahman Akbar. Regards, Ludwig Seitz -------- Forwarded Message -------- Subject: New Version Notification for draft-ietf-ace-usecases-05.txt Date: Tue, 01 Sep 2015 06:16:40 -0700 From: internet-drafts@ietf.org To: Mehdi Mani , Sandeep Kumar=20 , Goeran Selander=20 , Sandeep S. Kumar=20 , Ludwig Seitz , Goran=20 Selander , Stefanie Gerdes=20 , Stefanie Gerdes , Ludwig Seitz=20 , Mehdi Mani A new version of I-D, draft-ietf-ace-usecases-05.txt has been successfully submitted by Ludwig Seitz and posted to the IETF repository. Name: draft-ietf-ace-usecases Revision: 05 Title: ACE use cases Document date: 2015-09-01 Group: ace Pages: 27 URL:=20 https://www.ietf.org/internet-drafts/draft-ietf-ace-usecases-05.txt Status: https://datatracker.ietf.org/doc/draft-ietf-ace-usecases/= Htmlized: https://tools.ietf.org/html/draft-ietf-ace-usecases-05 Diff: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ace-usecas= es-05 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 comprises a collection of representative use cases for the application of authentication and authorization in constrained environments. These use cases aim at identifying authorization problems that arise during the lifecylce 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 --------------ms030800010702040002040205 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 DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE1MDkwMTEzMTg1NFowLwYJKoZI hvcNAQkEMSIEINFT/bfWJ48bAnIY0CWO6dMEmRQkG8HVdK3OPyHd9PZXMGwGCSqGSIb3DQEJ DzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0D AgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgaUGCSsGAQQB gjcQBDGBlzCBlDCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzAp BgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0 YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgMMhpgwgacG CyqGSIb3DQEJEAILMYGXoIGUMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20g THRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG A1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EC AwyGmDANBgkqhkiG9w0BAQEFAASCAQBL5TJ0x+A9PZUxXU/r6IAQdLOu87+IM3R+wqN9lHJ3 bvzvDmrPfTHkt/k9YStbYreD8E6/6mYNaQ51rUJZ8T8LcBrERdQWRG9/bjxF8SxEtKhlKjWi Wm+HyMEP/lohlBq9w8gBb1w13/l8yXZ5KzT6+M0gb+DZ9+aP3NhTsHNWQ/VpRuffnL9t2Vp+ tJVQKYxeZSAM1BSNW+ixhIEo8jytufqUR1fYYe8Qe9zhC6+CaUInXF2bQcfmYhmW8TNTggdj YAaEyk93L73sKphTipA6o5NxZ1Uv/YQ5kd8wmVMgcU4xBW1vTgicmCHqtHDsgZdKBkZZGxdg /U1S2Rta9Hz8AAAAAAAA --------------ms030800010702040002040205-- From nobody Wed Sep 2 16:54: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 172F91B542E for ; Wed, 2 Sep 2015 16:54:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.099 X-Spam-Level: X-Spam-Status: No, score=-0.099 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, 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 q7D4TjGjqBti for ; Wed, 2 Sep 2015 16:54:27 -0700 (PDT) Received: from out4133-18.mail.aliyun.com (out4133-18.mail.aliyun.com [42.120.133.18]) by ietfa.amsl.com (Postfix) with ESMTP id DE6751B5432 for ; Wed, 2 Sep 2015 16:54:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alibaba-inc.com; s=default; t=1441238065; h=Date:Subject:From:To:Message-ID:Mime-version:Content-type; bh=QYPH1QKKlRQWQs7gWWsGqQ06cRTR/g9AKP36hIPb/Ak=; b=H6FQyAxGfc5dBiX514Hf3Zr/tq4dYjcBr7UL+rfEii2ndf2mq+GeGcJ3mMGpXfUUPqm4C+F8fbDQ81k2keDVPoL/ZMAdNeB+euUzvn0b7/W2NIBeOCv9PDhPOymws8pbgt9bwbUWbg2Q07KDrrd7C/lA1mmOU1bwLy70R8y4lLM= X-Alimail-AntiSpam: AC=PASS; BC=-1|-1; BR=01201311R161e4; FP=0|-1|-1|-1|0|-1|-1|-1; HT=e02c03282; MF=kepeng.lkp@alibaba-inc.com; NM=1; PH=DS; RN=1; SR=0; Received: from 10.22.58.15(mailfrom:kepeng.lkp@alibaba-inc.com ip:42.120.73.208) by smtp.aliyun-inc.com(127.0.0.1); Thu, 03 Sep 2015 07:54:23 +0800 User-Agent: Microsoft-MacOutlook/14.4.8.150116 Date: Thu, 03 Sep 2015 07:54:19 +0800 From: "Kepeng Li" To: "ace@ietf.org" Message-ID: Thread-Topic: Second WGLC for draft-ietf-ace-usecases-05 Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3524111665_13074300" Archived-At: Subject: [Ace] Second WGLC for draft-ietf-ace-usecases-05 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, 02 Sep 2015 23:54:29 -0000 > 此邮件使用 MIME 格式。由于邮件阅读程序不能识别 此格式，因此，可能无法识别该邮件的分部或部分内容。 --B_3524111665_13074300 Content-type: text/plain; charset="GB2312" Content-transfer-encoding: 7bit Hi all, We would like to start a second WGLC on draft-ietf-ace-usecases-05. https://datatracker.ietf.org/doc/draft-ietf-ace-usecases/ This will be a 2-week last call, so it will end on Friday, September 18. Please send comments to the list. Thanks! Ciao Hannes & Kepeng --B_3524111665_13074300 Content-type: text/html; charset="GB2312" Content-transfer-encoding: quoted-printable
Hi al= l,

We would like to start a second WGLC on draft-ietf-ace-usecases-05.

This will be a 2-week last call, so it will end on Friday, S= eptember 18.

Please send comments to the list.

Thanks!

Ciao
Hannes & Kepeng
--B_3524111665_13074300-- From nobody Wed Sep 2 21:29: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 413191B2D8E for ; Wed, 2 Sep 2015 21:29:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.513 X-Spam-Level: X-Spam-Status: No, score=0.513 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_HOST_EQ_D_D_D_D=0.765, HTML_MESSAGE=0.001, RDNS_DYNAMIC=0.982, SPF_SOFTFAIL=0.665] 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 UZ7FHQBSS_ll for ; Wed, 2 Sep 2015 21:29:01 -0700 (PDT) Received: from smtp-in1.interdigital.com (host-64-47-120-121.masergy.com [64.47.120.121]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4FAAD1A8F3E for ; Wed, 2 Sep 2015 21:29:01 -0700 (PDT) X-ASG-Debug-ID: 1441254539-06daaa5cf11320f0001-Yzt3Th Received: from NALENITE.InterDigital.com (nalenite.interdigital.com [10.2.64.253]) by smtp-in1.interdigital.com with ESMTP id MxFaBQCBngChZz4u (version=TLSv1 cipher=AES128-SHA bits=128 verify=NO); Thu, 03 Sep 2015 00:28:59 -0400 (EDT) X-Barracuda-Envelope-From: Akbar.Rahman@InterDigital.com Received: from NABESITE.InterDigital.com ([fe80::4d8a:a889:67c2:f009]) by NALENITE.InterDigital.com ([::1]) with mapi id 14.03.0248.002; Thu, 3 Sep 2015 00:28:55 -0400 From: "Rahman, Akbar" To: Kepeng Li , "ace@ietf.org" Thread-Topic: Second WGLC for draft-ietf-ace-usecases-05 X-ASG-Orig-Subj: RE: Second WGLC for draft-ietf-ace-usecases-05 Thread-Index: AQHQ5dq1roDhBNC/6EexBwuqnfnx9J4qNe8Q Date: Thu, 3 Sep 2015 04:28:54 +0000 Message-ID: <36F5869FE31AB24485E5E3222C288E1F347ADBCD@NABESITE.InterDigital.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.3.247.108] x-exclaimer-md-config: bb79a19d-f711-475c-a0f9-4d93b71c94dd Content-Type: multipart/alternative; boundary="_000_36F5869FE31AB24485E5E3222C288E1F347ADBCDNABESITEInterDi_" MIME-Version: 1.0 X-Barracuda-Connect: nalenite.interdigital.com[10.2.64.253] X-Barracuda-Start-Time: 1441254539 X-Barracuda-Encrypted: AES128-SHA X-Barracuda-URL: https://10.1.245.3:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at interdigital.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests=HTML_MESSAGE X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.22181 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 HTML_MESSAGE BODY: HTML included in message Archived-At: Subject: Re: [Ace] Second WGLC for draft-ietf-ace-usecases-05 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, 03 Sep 2015 04:29:03 -0000 --_000_36F5869FE31AB24485E5E3222C288E1F347ADBCDNABESITEInterDi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Looks good. Thanks to the authors for addressing all the comments that I h= ad given them. I don't have any further comments. Therefore, I support pr= ogressing the draft. Best Regards, Akbar From: Ace [mailto:ace-bounces@ietf.org] On Behalf Of Kepeng Li Sent: Wednesday, September 02, 2015 7:54 PM To: ace@ietf.org Subject: [Ace] Second WGLC for draft-ietf-ace-usecases-05 Hi all, We would like to start a second WGLC on draft-ietf-ace-usecases-05. https://datatracker.ietf.org/doc/draft-ietf-ace-usecases/ This will be a 2-week last call, so it will end on Friday, September 18. Please send comments to the list. Thanks! Ciao Hannes & Kepeng --_000_36F5869FE31AB24485E5E3222C288E1F347ADBCDNABESITEInterDi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Looks good= .  Thanks to the authors for addressing all the comments that I had gi= ven them.  I don’t have any further comments.  Therefore, I support progressing the draft.

 = ;

 = ;

Best Regar= ds,

 = ;

 = ;

Akbar

 = ;

From: Ace [mailto:ace-bounces@ietf.o= rg] On Behalf Of Kepeng Li
Sent: Wednesday, September 02, 2015 7:54 PM
To: ace@ietf.org
Subject: [Ace] Second WGLC for draft-ietf-ace-usecases-05=

 

Hi all,=

&n= bsp;

We woul= d like to start a second WGLC on draft-ietf-ace-usecases-05.

&n= bsp;

This wi= ll be a 2-week last call, so it will end on Friday, September 18.

&n= bsp;

Please = send comments to the list.

&n= bsp;

Thanks!=

&n= bsp;

Ciao

Hannes = & Kepeng

--_000_36F5869FE31AB24485E5E3222C288E1F347ADBCDNABESITEInterDi_-- From nobody Tue Sep 8 02:17:14 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 56C561A8AD1 for ; Tue, 8 Sep 2015 02:17:13 -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 t_SuSrn9kpjo for ; Tue, 8 Sep 2015 02:17:11 -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 203EF1B2D25 for ; Tue, 8 Sep 2015 02:17:11 -0700 (PDT) Received: from [192.168.10.168] ([80.92.114.87]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0MLNeQ-1ZYgnH06C2-000dcN for ; Tue, 08 Sep 2015 11:17:09 +0200 To: "Ace@ietf.org" From: Hannes Tschofenig Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9 Message-ID: <55EEA78C.9020308@gmx.net> Date: Tue, 8 Sep 2015 11:17:00 +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="ue7PHwi7VNxnmfr9qarbDHnAkoBG5FP8i" X-Provags-ID: V03:K0:p9g6/MQw1DOAGOHIxmN0B/SABauVy4MhUF2TY1VbVq7eTc5pMsE 3TO492b09BS0ZRBp7nz69gjPwtyM/sY6FV11Wmhh02SDV3Eb1BspRem9jwQh9EE258q1eSd 1dUOUY7tthlGBr9N9oPw9mucigr8SZ89mTpn8MeUmOlvq/63J5MGkICarl2r64bhiiFINRE 9dMAuPoOUybg0IzRQ+uWA== X-UI-Out-Filterresults: notjunk:1;V01:K0:lHm9Jvrmx5M=:ahl8Eb7H/jNK7Y/mV9tU23 RzjIaXiWoVHTX3oXigVMoyt4keCdxsjflpS7hd+XHh6PC+gkhj26LY6gU2c/4OXyc5aKLSRlm 3kji//cjjZ71RSvjXuJ62kchms8kO5Iq2VGNsrjyBDmbRpCy0BqQKm3zkYNrJjx3qDD++vY4Y /LRL2TA/N495invW8ijgT7bA/SizkynWQnisWRgb9fMxbLI1UpAe7ux5UG//bKdV1IVeKR7ih X1jI8Na3qPUxmOAJVNbU8ijOnZjuWdPy+V8kOXR4F4v9KyUBtafc+jz/VAlqyRy6pKoI+GKiJ 2ENtit+b2P36QnGeTOp4MlUt9v5ZbthZRj9GDzSDpeKlSme/MaPdJu4MmJP6EOcRwAUq7GzaS fY8XHvomYYEEiSkPC2Zd55A+5VNQgvjBimDNY3oEtDm1CumPK2DnThhe798xFzWNze/Bx+kER 6CnbPGG+JZ1tBnyj8Q2ZEI8xDfZ400gkUnEQJYuZ6m7MWt5uKXVH8BmkjtaKCQFTm3kGkP8L/ i11ylmzucB79qT/wotNxyudYijs42981lusLmHCfO9VI8r5VTBXB4wo4C1BWdoaOH7CTb8Ilz HVh3qw3rnrA86z06HGR/xrmAd5++CAah5UFVijNaY+Jh7HINhntBcvHulsAWsKyUAHuI3/rwz dS6rFwy03Rra2v2hA+/bZ1c4VNGDCD7f7nCBELl3YOYXFEGw3jShMf8kjtHhFOtiUOJ//mSVd d4+KOOzTwH0e44Af Archived-At: Subject: [Ace] ACE Virtual Interim Meeting: 30 September 2015 (9am EDT -- 11am EDT) 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, 08 Sep 2015 09:17:13 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --ue7PHwi7VNxnmfr9qarbDHnAkoBG5FP8i Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable The Authentication and Authorization for Constrained Environments (ACE) Working Group will hold a virtual interim meeting on Wednesday, 30 September 2015, between 9am EDT and 11am EDT. The agenda and dial-in information will follow on the ACE mailing list: https://mailarchive.ietf.org/arch/browse/ace/ --ue7PHwi7VNxnmfr9qarbDHnAkoBG5FP8i 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 iQEcBAEBCgAGBQJV7qeMAAoJEGhJURNOOiAt1VQH/22naaA51xqNlR2LwDrL8Tty IhQUIeV3plAVJdYZkYWZXwl5yS4jmUogycF7foEI2HslvyrTvxZldlszCu7MJFJK gJ4eFaTJTkwO8K3TIWLh+gxNeOCdajcHr55bS7UoaQzdItL4LdejYwiW+eoS0zG8 jveaGXlOukYcZ1c5tuiRCvyRcK1Q+T9i4E0ngvqsvWfS6EtO0KdzqeAfev1ZPPl9 mvoPIAEjvmItXEPYU6SykCXsJrKrbp+V7RKEVvjCrWHbraKBuo5+NRMi7jkbEsoP SZkaU5hyW8I1jOXZUKesz/5Xt3PgI2ImRFSOpVv490HEMLt6rPllrHle1AqeAoI= =zQ9f -----END PGP SIGNATURE----- --ue7PHwi7VNxnmfr9qarbDHnAkoBG5FP8i-- From nobody Tue Sep 8 16:20: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 84FFF1B4DC0; Tue, 8 Sep 2015 08:12:12 -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 ixnoYFaoSU2o; Tue, 8 Sep 2015 08:12:11 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 44FBE1B4DBF; Tue, 8 Sep 2015 08:12:10 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IESG Secretary To: "IETF Announcement List" X-Test-IDTracker: no X-IETF-IDTracker: 6.4.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150908151210.27949.59916.idtracker@ietfa.amsl.com> Date: Tue, 08 Sep 2015 08:12:10 -0700 Archived-At: X-Mailman-Approved-At: Tue, 08 Sep 2015 16:19:59 -0700 Subject: [Ace] ACE WG Virtual Interim Meeting: 30 September 2015 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: Tue, 08 Sep 2015 15:12:12 -0000 The Authentication and Authorization for Constrained Environments (ACE) Working Group will hold a virtual interim meeting on Wednesday, 30 September 2015, between 9am EDT and 11am EDT. The agenda and dial-in information will follow on the ACE mailing list: https://mailarchive.ietf.org/arch/browse/ace/ From nobody Wed Sep 9 06:12: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 E68201B359E for ; Wed, 9 Sep 2015 06:12:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.112 X-Spam-Level: X-Spam-Status: No, score=-5.112 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 gL3KnmMtROlM for ; Wed, 9 Sep 2015 06:12:12 -0700 (PDT) Received: from ausxipps301.us.dell.com (ausxipps301.us.dell.com [143.166.148.223]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EA0CD1B2EA6 for ; Wed, 9 Sep 2015 06:12:11 -0700 (PDT) DomainKey-Signature: s=smtpout; d=dell.com; c=nofws; q=dns; h=X-LoopCount0:X-IronPort-AV:From:To:Subject:Thread-Topic: Thread-Index:Date:Message-ID:Accept-Language: Content-Language:X-MS-Has-Attach:X-MS-TNEF-Correlator: x-tituslabs-classifications-30:x-titusconfig: x-titus-version:x-tituslabs-classificationhash-30: x-originating-ip:Content-Type:Content-Transfer-Encoding: MIME-Version:Return-Path; b=vx05OYhWGG378rYH2H3RDzniWgD1eOz9bL6z6yix204TWkcGO3Sdhs6b xWcQpzF84m9d2DpZfXtMCneZ8nsCm28cRH4kjQMp0mytx5lZjg6el5JfU lLHfLRgtm/hbSFVNIBljvoDHNoHWub1j3h5WVV5getvDOfbx/pIq7Nq7K U=; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dell.com; i=@dell.com; q=dns/txt; s=smtpout; t=1441804333; x=1473340333; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=2PaikRLvb2qyZTTHebLF1jGLMmxh261Li/uJmb49VHA=; b=u1+lbCLbCB1SweGUBzy+T3Hq6oqTy1QvC+U0ywpMHxXaYLR1VKVAZXeI ndeNRAykI/KbQod6JS8RUgfhRPknZyfyNYbOH+xmhqoiEzJT27HcpX7R+ iFrZ9q5musvW6Ap2SyNR2Isrj7UO3XHme3QPNSkD0s+IaQtJ3plQ6oZlq A=; X-LoopCount0: from 10.175.216.249 X-IronPort-AV: E=Sophos;i="5.17,496,1437454800"; d="scan'208";a="702133054" From: To: Thread-Topic: Re: [Ace] Second WGLC for draft-ietf-ace-usecases-05 Thread-Index: AdDq/cy4fM4glODYRmCKO4dQ9ge/zQ== Date: Wed, 9 Sep 2015 13:12:06 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-tituslabs-classifications-30: TLPropertyRoot=Dell;Classification=Internal Use;External=No;Sublabels=; x-titusconfig: 1.4AMER x-titus-version: 3.5.29.3 x-tituslabs-classificationhash-30: VgNFIFU9Hx+/nZJb9Kg7IoF8le54DB/enoY9opxUHldMBuJ5mb7PTbLRsiMsBNEUqMQQ6ojHKYTLOg4YQd4zHhj0K6y/4TE3pG9o0aOIc5f3rAhsb4zvbY0kZjJZuNvw3xBFQwycURiKpk15pJBSI4ERhBUXYdaDZuS85Kh1Kq9FGkV5hNuN7+wBZ3Ca4/GwZraFF1REIjSfrp//ptk3NppXu/0cn+TRCVN5uxNRIAL4ZjGNNY1do/fdOa8XGEw8huwkZz946XnVfKNS3ijJDw== x-originating-ip: [10.132.140.245] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Ace] Second WGLC for draft-ietf-ace-usecases-05 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, 09 Sep 2015 13:12:17 -0000 Dell - Internal Use - Confidential=20 Hi all,=20 Hope I am not very late to the party. Very nicely articulated usecases, ha= ve few queries:=20 - Typo "lifecylce" in the beginning of the draft - Section 2.2.5. - U2.5 - "The smart home devices need to be able to commun= icate with different control devices"=20 Q: can we also mention IoT-GW or Device Gateways as well besides individual= control devices ? - Section 2.3.1.-John and the heart rate monitor - " In case of a cardiac a= rrest it automatically sends an alarm to an emergency service, transmitting= John's current location (U3.1). This requires the device to be close to a= wireless access point, in order to be able to get an Internet connection (= e.g. John's smartphone)."=20 Q: Can we recommend or suggest that the device MAY (if not should) have an = alternate means of communication in the absence of AP, like SMS during emer= gency situations ? Q: If yes, then do need to have any special security mechanism in place for= SMS ? - Regards, Prashant Jhingran "Life gives you both positive & negative. Focus on the good & move ahead wi= th commitment" - Sri Sri www.artofliving.org =3D=3D=3D=3D=3D=3D=3D=3D [Ace] Second WGLC for draft-ietf-ace-usecases-05 "Kepeng Li" Wed, 02 September 2015 23:54 UTCSh= ow header Hi all, We would like to start a second WGLC on draft-ietf-ace-usecases-05. https://datatracker.ietf.org/doc/draft-ietf-ace-usecases/ This will be a 2-week last call, so it will end on Friday, September 18. Please send comments to the list. Thanks! Ciao Hannes & Kepeng From nobody Sun Sep 13 21:19: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 214BF1B49A0 for ; Sun, 13 Sep 2015 21:18:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.8 X-Spam-Level: X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 tEnFkABhUESa for ; Sun, 13 Sep 2015 21:18:56 -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 D6CE91B3EEE for ; Sun, 13 Sep 2015 21:18:56 -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 E96F338EF1 for ; Sun, 13 Sep 2015 21:18:55 -0700 (PDT) From: "Jim Schaad" To: Date: Sun, 13 Sep 2015 21:16:36 -0700 Message-ID: <007901d0eea4$25989bf0$70c9d3d0$@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: AdDuo/sorjKxXnJSQaGX5o+dQpuhBg== Archived-At: Subject: [Ace] Looking at COSE based unicast and multicast 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, 14 Sep 2015 04:18:59 -0000 I have been looking at some of the issues that have come up with COSE and the question of how messaging could do the same type of thing as what the multi-cast DTLS solutions are looking at. In order to do this I am going to do a fast review of what happens for "real" DTLS and then start looking at the equivalent of DTLS using the same model as what the ACE DTLS solutions are looking at - specifically that the key management is done externally. For "real" DTLS, the context is always identified by the set of . This set of 4 values may not be the same on both the client and the server due to NATs being on the path between the two ends. All of the NAT mapping is taken care of correctly since the key setup is done using DTLS so that the mapping can be created in all intervening routers and will be kept for the duration of the DTLS session. Looking at UDP for CoAP, in a "clean" system with no NAT translation it might be possible to using the same 4-tuple of values at each end to know what the cryptographic context is. Looking at the source and destination values (which would be the same) it will be fine independent of how the contexts are created. The biggest issue that I can see is that the use of something like DHCP might cause problems if addresses are changed when devices go to sleep. Looking at UDP for CoAP in the case of a NAT doing address translations gives a different set of cases. The problem here is that the introduction function would need to know what the routing is going to be in order to give the correct set of endpoints to each of the entities. Additionally, that would need to be locked down for the duration of the security context. This is not really a viable option. It is more viable for dealing with CoAP proxy agents as they are going to have a better idea of both which ones exist, also the proxies would have a better idea of how long a mapping would need to be maintained. As with "real" DTLS, changing the routing would cause a break in the mapping and thus lead to communication failures. Depending on how things are setup, this might be more of an issue for a CoAP world than the normal UDP world. >From this, it seems to me that does support the position that some information about context needs to be passed on the initial message. Depending on how this is presented I would expect this to be done with the current COSE encrypted message structure. It is potentially different in the case where the client is being used to relay information to the server about the authorization information. The response does not appear to need a context identifier as there is already information in the CoAP message that can be used for determining the context. Specifically the Token and Message ID fields can be used to associate requests and responses. This means that a client can use this to determine what context was used by the server to encrypt the message that was returned. (Specifically, the same context and the client used to encrypt the request.) This means that we can say that there is an implicit context for encrypted messages in this case the new encryption structure w/o recipients would make sense. This analysis would apply to the observe dialog structure as well, the token can be used to associate all items in the same context. For a subscription model to a third party, there are a couple of different ways to look at how it can be setup. The big question is if the context is going to be unique to the originator, or it is unique to the subscription. In either case, the client is going to end up using two different contexts in this situation. The first case is for setting up the original subscription. In that case a context associated with the data storage server is going to be needed. However, once information starts flowing back to the client from the data storage service, the context associated with the origination server is going to be used. It is not clear that the action of doing the subscription would need to be encrypted, this simplified things as only one encryption context is now needed. Otherwise either two contexts need to be tried, or the type of message needs to be known so that the client understand where the encrypted content originates. For the case of multicast, it appears to me that the context can be inferred in most cases. I would assume that a context is going to be signed to each multicast address, port pair. I would also assume that this would be a unique assignment in that multiple contexts would not be assigned. This does allow for any node which has the context to send out a multicast message without a problem. The more interesting question is what to do with the unicast responses to a multicast message. Should they be encrypted with the multicast group context, in which case the message id/token on the message is sufficient to identify the context. Or should they be encrypted with a unicast key pair between the replier and the original message sender? This implies that such a key context needs to be setup for each such link which may or may not be the case. In this event it might be necessary to identify the context that was used to encrypt the unicast message. I have not managed to think this through far enough. In any event, there appear to be enough cases where the encryption context can be inferred from the message to make it reasonable to have a version of COSE messages which do not have any recipient information attached to them. In the case of pure unicast, it would be used for at least 50% of the messages (a higher percentage for observing state). And for multicast it might be used either for 50% or all of the messages depending on how responses are handled. I am interested in people looking at my analysis and tell me if I am right, wrong or unclear. Jim From nobody Mon Sep 14 00: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 4CFD81B2FAD for ; Mon, 14 Sep 2015 00:42:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.1 X-Spam-Level: X-Spam-Status: No, score=0.1 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 jrQaC_i7o1so for ; Mon, 14 Sep 2015 00:42:10 -0700 (PDT) Received: from mail-la0-f54.google.com (mail-la0-f54.google.com [209.85.215.54]) (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 CC45C1B2DBB for ; Mon, 14 Sep 2015 00:42:09 -0700 (PDT) Received: by lanb10 with SMTP id b10so80913166lan.3 for ; Mon, 14 Sep 2015 00:42:08 -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=gB0q6fcIloRzds7y7zIeJ2Li36hTJxAzx231HqKxopU=; b=K6mxdFfTf91UMpuER3w3b6CsRLO5v+SmLSSnXr8ZxBBi9gC0dDFlEhKNdRrHr4gNer wFsUNRx9Jifeh/5wpPkn1+z/RHbsIN4WH6RZmBvAkDiS6BGkoDZaS6H7YQsN5sjzmnD6 ghe3p7YwKy7CT14+xFBtUdbNfhSwn3kC40WaUeHu7pqqAzp2sOLR6FhKuq+8P9oIdS2i 74xST/fqoVQ0q4G66CnAV386jfnHGCqke1307CLUUsTXcgviDNByXOCbjJDX7Lv2Trrt 7dh/yxmOg2e8JpZ01yutsguwutFh8XNGZYoyC5KJUA9ivFt5PEjYiv5hScRaBBgcC6Du 0/Hw== X-Gm-Message-State: ALoCoQn6hTQTg/cq/tFp4k6gfoOLEl3CIBJiaNMROs3hDVuwgV9fUbDcDTaztpGLNOE3ThEutDjU X-Received: by 10.112.160.98 with SMTP id xj2mr12396059lbb.124.1442216528042; Mon, 14 Sep 2015 00:42:08 -0700 (PDT) Received: from [192.168.0.108] ([85.235.11.178]) by smtp.gmail.com with ESMTPSA id p8sm2154301laf.12.2015.09.14.00.42.07 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 14 Sep 2015 00:42:07 -0700 (PDT) To: ace@ietf.org References: From: Ludwig Seitz Message-ID: <55F67A4E.3000402@sics.se> Date: Mon, 14 Sep 2015 09:42:06 +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="------------ms000505000305010700090402" Archived-At: Subject: Re: [Ace] Second WGLC for draft-ietf-ace-usecases-05 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, 14 Sep 2015 07:42:12 -0000 This is a cryptographically signed message in MIME format. --------------ms000505000305010700090402 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable On 2015-09-09 15:12, Prashant_Jhingran@Dell.com wrote: > Dell - Internal Use - Confidential > > Hi all, > > Hope I am not very late to the party. Very nicely articulated usecases= , have few queries: > > - Typo "lifecylce" in the beginning of the draft > Thank you, how did my spellchecker miss that? > - Section 2.2.5. - U2.5 - "The smart home devices need to be able to co= mmunicate with different control devices" > Q: can we also mention IoT-GW or Device Gateways as well besides indivi= dual control devices ? I was (perhaps naively) assuming that gateways were subsumed by "control = devices". We could add a clarification in the style of " ... such as=20 IoT-Gateways, ..." > > - Section 2.3.1.-John and the heart rate monitor - " In case of a cardi= ac arrest it automatically sends an alarm to an emergency service, transm= itting John's current location (U3.1). This requires the device to be clo= se to a wireless access point, in order to be able to get an Internet co= nnection (e.g. John's smartphone)." > Q: Can we recommend or suggest that the device MAY (if not should) have= an alternate means of communication in the absence of AP, like SMS durin= g emergency situations ? > Q: If yes, then do need to have any special security mechanism in place= for SMS ? If the device would be able to send SMS on itself, this would imply that = it has a SIM card and is able to connect to the mobile network. The=20 (fictitious) device I had in mind has just short-range wireless=20 connectivity. Perhaps "access point" is misleading because it makes people think of=20 WiFi, where I actually meant "anything that connects it to the outside=20 world". I'll look for a better phrasing. Thank you for your comments! 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 --------------ms000505000305010700090402 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 DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE1MDkxNDA3NDIwNlowLwYJKoZI hvcNAQkEMSIEIH3MqkJ+WIItMVsW++ATsgRq50iCQA+9poV7wrwxkJsoMGwGCSqGSIb3DQEJ DzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0D AgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgaUGCSsGAQQB gjcQBDGBlzCBlDCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzAp BgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0 YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgMMhpgwgacG CyqGSIb3DQEJEAILMYGXoIGUMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20g THRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG A1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EC AwyGmDANBgkqhkiG9w0BAQEFAASCAQCaqZqNpzvT5nk6cIk/lShYxZhDz4i+ddTnShPp5OHE m2K/xpHPnjTXEE41y3Nd4rGea0caOqAQkA34z8IAPQWR28gLAVe8iy7zPVeGsEAfzrN36ACN o29N4HqTsS4tI+fFD3KYlEl1HN3ldIvSow7JiQVTQgrLadcBOG89gz0/cBfEmF8q8o+4iSWR byeJNvLXPrVdSIT7JBaQOolV8XiyzLgey17FzuUGWUpGQqFMRSZ6cVsoiTRWixSDESz5AGfk 4Utbl8q7SSY/AljtdRX0H2SvRLixeRhChEP7j210t1CoosSWPFi/B428HpWErlsJ7GhzoYLF sadXfI1ytft+AAAAAAAA --------------ms000505000305010700090402-- From nobody Mon Sep 14 02:48:14 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 9D4CB1A1B79 for ; Mon, 14 Sep 2015 02:48:13 -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 qq9eH5bdNTUG for ; Mon, 14 Sep 2015 02:48:11 -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 4BE171B4173 for ; Mon, 14 Sep 2015 02:48:10 -0700 (PDT) X-AuditID: c1b4fb3a-f79136d0000071e2-fa-55f697d86f1a Received: from ESESSHC023.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 9D.3F.29154.8D796F55; Mon, 14 Sep 2015 11:48:08 +0200 (CEST) Received: from ESESSMB303.ericsson.se ([169.254.3.214]) by ESESSHC023.ericsson.se ([153.88.183.87]) with mapi id 14.03.0248.002; Mon, 14 Sep 2015 11:48:07 +0200 From: =?utf-8?B?R8O2cmFuIFNlbGFuZGVy?= To: Jim Schaad , "ace@ietf.org" Thread-Topic: [Ace] Looking at COSE based unicast and multicast Thread-Index: AdDuo/sorjKxXnJSQaGX5o+dQpuhBgALnjSA Date: Mon, 14 Sep 2015 09:48:07 +0000 Message-ID: References: <007901d0eea4$25989bf0$70c9d3d0$@augustcellars.com> In-Reply-To: <007901d0eea4$25989bf0$70c9d3d0$@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.150] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpikeLIzCtJLcpLzFFi42KZGfG3RvfG9G+hBhvPKFl8/9bDbLF6+nc2 ByaPjXOms3ksWfKTKYApissmJTUnsyy1SN8ugStj09sr7AVdcRVn511kaWC8Et3FyMkhIWAi sWHRORYIW0ziwr31bF2MXBxCAkcZJU4+nMgEkhASWMIo8epNOojNJuAi8aDhEVhcRMBN4uzk ZWDNwgJ2Erc+32KBiNtL/D3QD2UbSWydeA2snkVAVeLpiSmsIDavgIXE/K75zF2MHEDz7SU+ tDqAhDkFHCSObbrBBmIzAt3z/dQasFZmAXGJW0/mM0HcKSCxZM95ZghbVOLl439gI0UF9CRW Xm9ig4grSazYfokRZDyzgKbE+l36EGOsJd7O3M0OYStKTOl+yA5xjaDEyZlPWCYwis9Csm0W QvcsJN2zkHTPQtK9gJF1FaNocWpxcW66kZFealFmcnFxfp5eXmrJJkZgpB3c8ttqB+PB546H GAU4GJV4eB98/BoqxJpYVlyZe4hRmoNFSZy3melBqJBAemJJanZqakFqUXxRaU5q8SFGJg5O qQZG378hSVfmOjeUfmpl8Xg8cfHEQoWk9ikd97jmsvJryiQKhK0Wsypy17pzLIXVb8OcSuM9 i32M8+09RBXTb4S8/5j7T+L/a7VSx2NqyfrG/2T/5q42Yj7+O015ldgstYt1Be6fbgT3mG1p yLy75lvGi0vWWlIJBeezOsUEu/6x3Hvr9e1n/CUlluKMREMt5qLiRACHPMTElQIAAA== Archived-At: Subject: Re: [Ace] Looking at COSE based unicast and multicast 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, 14 Sep 2015 09:48:13 -0000 DQoNCk9uIDIwMTUtMDktMTQgMDY6MTYsICJKaW0gU2NoYWFkIiA8aWV0ZkBhdWd1c3RjZWxsYXJz LmNvbT4gd3JvdGU6DQoNCj5JIGhhdmUgYmVlbiBsb29raW5nIGF0IHNvbWUgb2YgdGhlIGlzc3Vl cyB0aGF0IGhhdmUgY29tZSB1cCB3aXRoIENPU0UgYW5kDQo+dGhlIHF1ZXN0aW9uIG9mIGhvdyBt ZXNzYWdpbmcgY291bGQgZG8gdGhlIHNhbWUgdHlwZSBvZiB0aGluZyBhcyB3aGF0IHRoZQ0KPm11 bHRpLWNhc3QgRFRMUyBzb2x1dGlvbnMgYXJlIGxvb2tpbmcgYXQuICBJbiBvcmRlciB0byBkbyB0 aGlzIEkgYW0gZ29pbmcNCj50bw0KPmRvIGEgZmFzdCByZXZpZXcgb2Ygd2hhdCBoYXBwZW5zIGZv ciAicmVhbCIgRFRMUyBhbmQgdGhlbiBzdGFydCBsb29raW5nIGF0DQo+dGhlIGVxdWl2YWxlbnQg b2YgRFRMUyB1c2luZyB0aGUgc2FtZSBtb2RlbCBhcyB3aGF0IHRoZSBBQ0UgRFRMUyBzb2x1dGlv bnMNCj5hcmUgbG9va2luZyBhdCAtIHNwZWNpZmljYWxseSB0aGF0IHRoZSBrZXkgbWFuYWdlbWVu dCBpcyBkb25lIGV4dGVybmFsbHkuDQo+DQo+Rm9yICJyZWFsIiBEVExTLCB0aGUgY29udGV4dCBp cyBhbHdheXMgaWRlbnRpZmllZCBieSB0aGUgc2V0IG9mIDxzb3VyY2UNCj5JUCwNCj5zb3VyY2Ug cG9ydCwgZGVzdGluYXRpb24gSVAsIGRlc3RpbmF0aW9uIHBvcnQ+LiAgVGhpcyBzZXQgb2YgNCB2 YWx1ZXMgbWF5DQo+bm90IGJlIHRoZSBzYW1lIG9uIGJvdGggdGhlIGNsaWVudCBhbmQgdGhlIHNl cnZlciBkdWUgdG8gTkFUcyBiZWluZyBvbiB0aGUNCj5wYXRoIGJldHdlZW4gdGhlIHR3byBlbmRz LiAgQWxsIG9mIHRoZSBOQVQgbWFwcGluZyBpcyB0YWtlbiBjYXJlIG9mDQo+Y29ycmVjdGx5IHNp bmNlIHRoZSBrZXkgc2V0dXAgaXMgZG9uZSB1c2luZyBEVExTIHNvIHRoYXQgdGhlIG1hcHBpbmcg Y2FuDQo+YmUNCj5jcmVhdGVkIGluIGFsbCBpbnRlcnZlbmluZyByb3V0ZXJzIGFuZCB3aWxsIGJl IGtlcHQgZm9yIHRoZSBkdXJhdGlvbiBvZg0KPnRoZQ0KPkRUTFMgc2Vzc2lvbi4NCj4NCj5Mb29r aW5nIGF0IFVEUCBmb3IgQ29BUCwgaW4gYSAiY2xlYW4iIHN5c3RlbSB3aXRoIG5vIE5BVCB0cmFu c2xhdGlvbiBpdA0KPm1pZ2h0IGJlIHBvc3NpYmxlIHRvIHVzaW5nIHRoZSBzYW1lIDQtdHVwbGUg b2YgdmFsdWVzIGF0IGVhY2ggZW5kIHRvIGtub3cNCj53aGF0IHRoZSBjcnlwdG9ncmFwaGljIGNv bnRleHQgaXMuICBMb29raW5nIGF0IHRoZSBzb3VyY2UgYW5kIGRlc3RpbmF0aW9uDQo+dmFsdWVz ICh3aGljaCB3b3VsZCBiZSB0aGUgc2FtZSkgaXQgd2lsbCBiZSBmaW5lIGluZGVwZW5kZW50IG9m IGhvdyB0aGUNCj5jb250ZXh0cyBhcmUgY3JlYXRlZC4gIFRoZSBiaWdnZXN0IGlzc3VlIHRoYXQg SSBjYW4gc2VlIGlzIHRoYXQgdGhlIHVzZSBvZg0KPnNvbWV0aGluZyBsaWtlIERIQ1AgbWlnaHQg Y2F1c2UgcHJvYmxlbXMgaWYgYWRkcmVzc2VzIGFyZSBjaGFuZ2VkIHdoZW4NCj5kZXZpY2VzIGdv IHRvIHNsZWVwLg0KPg0KPkxvb2tpbmcgYXQgVURQIGZvciBDb0FQIGluIHRoZSBjYXNlIG9mIGEg TkFUIGRvaW5nIGFkZHJlc3MgdHJhbnNsYXRpb25zDQo+Z2l2ZXMgYSBkaWZmZXJlbnQgc2V0IG9m IGNhc2VzLiAgVGhlIHByb2JsZW0gaGVyZSBpcyB0aGF0IHRoZSBpbnRyb2R1Y3Rpb24NCj5mdW5j dGlvbiB3b3VsZCBuZWVkIHRvIGtub3cgd2hhdCB0aGUgcm91dGluZyBpcyBnb2luZyB0byBiZSBp biBvcmRlciB0bw0KPmdpdmUNCj50aGUgY29ycmVjdCBzZXQgb2YgZW5kcG9pbnRzIHRvIGVhY2gg b2YgdGhlIGVudGl0aWVzLiAgQWRkaXRpb25hbGx5LCB0aGF0DQo+d291bGQgbmVlZCB0byBiZSBs b2NrZWQgZG93biBmb3IgdGhlIGR1cmF0aW9uIG9mIHRoZSBzZWN1cml0eSBjb250ZXh0Lg0KPlRo aXMNCj5pcyBub3QgcmVhbGx5IGEgdmlhYmxlIG9wdGlvbi4gIEl0IGlzIG1vcmUgdmlhYmxlIGZv ciBkZWFsaW5nIHdpdGggQ29BUA0KPnByb3h5IGFnZW50cyBhcyB0aGV5IGFyZSBnb2luZyB0byBo YXZlIGEgYmV0dGVyIGlkZWEgb2YgYm90aCB3aGljaCBvbmVzDQo+ZXhpc3QsIGFsc28gdGhlIHBy b3hpZXMgd291bGQgaGF2ZSBhIGJldHRlciBpZGVhIG9mIGhvdyBsb25nIGEgbWFwcGluZw0KPndv dWxkDQo+bmVlZCB0byBiZSBtYWludGFpbmVkLiAgQXMgd2l0aCAicmVhbCIgRFRMUywgY2hhbmdp bmcgdGhlIHJvdXRpbmcgd291bGQNCj5jYXVzZSBhIGJyZWFrIGluIHRoZSBtYXBwaW5nIGFuZCB0 aHVzIGxlYWQgdG8gY29tbXVuaWNhdGlvbiBmYWlsdXJlcy4NCj5EZXBlbmRpbmcgb24gaG93IHRo aW5ncyBhcmUgc2V0dXAsIHRoaXMgbWlnaHQgYmUgbW9yZSBvZiBhbiBpc3N1ZSBmb3IgYQ0KPkNv QVANCj53b3JsZCB0aGFuIHRoZSBub3JtYWwgVURQIHdvcmxkLg0KPg0KPj5Gcm9tIHRoaXMsIGl0 IHNlZW1zIHRvIG1lIHRoYXQgZG9lcyBzdXBwb3J0IHRoZSBwb3NpdGlvbiB0aGF0IHNvbWUNCj5p bmZvcm1hdGlvbiBhYm91dCBjb250ZXh0IG5lZWRzIHRvIGJlIHBhc3NlZCBvbiB0aGUgaW5pdGlh bCBtZXNzYWdlLg0KPkRlcGVuZGluZyBvbiBob3cgdGhpcyBpcyBwcmVzZW50ZWQgSSB3b3VsZCBl eHBlY3QgdGhpcyB0byBiZSBkb25lIHdpdGggdGhlDQo+Y3VycmVudCBDT1NFIGVuY3J5cHRlZCBt ZXNzYWdlIHN0cnVjdHVyZS4gIEl0IGlzIHBvdGVudGlhbGx5IGRpZmZlcmVudCBpbg0KPnRoZSBj YXNlIHdoZXJlIHRoZSBjbGllbnQgaXMgYmVpbmcgdXNlZCB0byByZWxheSBpbmZvcm1hdGlvbiB0 byB0aGUgc2VydmVyDQo+YWJvdXQgdGhlIGF1dGhvcml6YXRpb24gaW5mb3JtYXRpb24uDQoNClVz aW5nIHRoZSBjdXJyZW50IENPU0UgZW5jcnlwdGVkIG1lc3NhZ2Ugc3RydWN0dXJlIGlzIG5vdCBh ZGRyZXNzaW5nIHRoZQ0KY29uY2VybnMgYWJvdXQgbWVzc2FnZSBzaXplIGFzIGhhcyBiZWVuIGRp c2N1c3NlZCBwcmV2aW91c2x5LiBGcm9tIHRoZQ0KcHJvcG9zZWQgQUNFIGFyY2hpdGVjdHVyZSBJ IGNhbiByZWZlcmVuY2UgdHdvIGNhdGVnb3JpZXMgb2YgZm9ybWF0czoNCg0KMS4gT25lIGNhdGVn b3J5IHdoaWNoIGFzc3VtZXMgdGhhdCB0aGVyZSBpcyBlc3NlbnRpYWxseSBvbmx5IGEg4oCcYmFz ZSBrZXnigJ0NCmVzdGFibGlzaGVkIGJldHdlZW4gc2VuZGVyIGFuZCByZWNlaXZlciwgYW5kIHdo ZXJlIHRoZSBtZXNzYWdlIHByb3ZpZGVzDQptZWFucyB0byBkZXJpdmUgdGhlIHNlY3VyaXR5IGNv bnRleHQgdG8gdXNlIHdpdGggdGhlIG1lc3NhZ2UuDQoNCjIuIEFub3RoZXIgY2F0ZWdvcnkgd2hp Y2ggaXMgaGlnaGx5IG9wdGltaXplZCBmb3IgdGhlIHNldHRpbmcgdGhhdCB0aGUNCnNlY3VyaXR5 IGNvbnRleHQgaXMgYXZhaWxhYmxlIGF0IHRoZSByZWNlaXZlci4NCg0KDQpJIHRoaW5rIHRoZSBk aXN0aW5jdGlvbiBiZXR3ZWVuIENPU0VfRW52ZWxvcGVkIGFuZCBDT1NFX0VuY3J5cHRlZA0Kc3Ry dWN0dXJlIGlzIGEgZ29vZCBzdGVwIGluIHRoZSByaWdodCBkaXJlY3Rpb24sIGJ1dCB0aGUgbGF0 dGVyIHNob3VsZA0KYWxsb3cgZm9yIHRoZSBkZXNpcmVkIGlkZW50aWZpY2F0aW9uIGFuZCBvcHRp bWl6YXRpb24gZm9yIHRoZSBtb3N0IGNvbW1vbg0Kc2V0dGluZ3MuIFNvbWV0aGluZyBsaWtlOg0K DQpbIG1lc3NhZ2UgdHlwZSwgcHJvdGVjdGVkIGhlYWRlcnMsIGNpcGhlciB0ZXh0LCB0YWcgXQ0K DQoNCndoZXJlIHByb3RlY3RlZCBoZWFkZXJzIGNhbiBpZGVudGlmeSB0aGUgc2VjdXJpdHkgY29u dGV4dCBhbmQgdGhlDQpub25jZS9zZXF1ZW5jZSBudW1iZXIuDQoNCkluIGZhY3QsIHRvIGdldCBy ZXBsYXkgcHJvdGVjdGlvbiBvZiByZXF1ZXN0LCBhbmQgb2YgcmVzcG9uc2UgaWYgbm8gcHJpb3IN CnJlcXVlc3QgYm91bmQgdG8gdGhlIHJlc3BvbnNlLCBvbmUgb2YgdGhlIGZpZWxkcyBpbiB0aGUg cHJvdGVjdGVkIGhlYWRlcg0KbXVzdCBiZSBub25jZS9zZXF1ZW5jZSBudW1iZXIvdGltZXN0YW1w LCByaWdodD8gIFRodXMgdGhlIGZvcm1hdCB3b3VsZA0KYW55d2F5IGNhcnJ5IHNvbWUgaW5mb3Jt YXRpb24gYWJvdXQgc2VjdXJpdHkgY29udGV4dC4gSXQgc2VlbXMgb2RkIHRvIG5vdA0KYWxsb3cg YW4gaWRlbnRpZmllciBvZiB3aGF0IGNvbnRleHQgdGhpcyBub25jZS9ldGMuIHJlZmVycyB0by4N Cg0KDQo+DQo+VGhlIHJlc3BvbnNlIGRvZXMgbm90IGFwcGVhciB0byBuZWVkIGEgY29udGV4dCBp ZGVudGlmaWVyIGFzIHRoZXJlIGlzDQo+YWxyZWFkeSBpbmZvcm1hdGlvbiBpbiB0aGUgQ29BUCBt ZXNzYWdlIHRoYXQgY2FuIGJlIHVzZWQgZm9yIGRldGVybWluaW5nDQo+dGhlDQo+Y29udGV4dC4g IA0KDQo+U3BlY2lmaWNhbGx5IHRoZSBUb2tlbiBhbmQgTWVzc2FnZSBJRCBmaWVsZHMgY2FuIGJl IHVzZWQgdG8NCj5hc3NvY2lhdGUgcmVxdWVzdHMgYW5kIHJlc3BvbnNlcy4NCg0KTWVzc2FnZSBJ RCBpcyBub3QgYSByZWxpYWJsZSBpZGVudGlmaWVyIGZvciBhc3NvY2lhdGluZyByZXF1ZXN0IHRv DQpyZXNwb25zZS4NCg0KPiAgVGhpcyBtZWFucyB0aGF0IGEgY2xpZW50IGNhbiB1c2UgdGhpcyB0 bw0KPmRldGVybWluZSB3aGF0IGNvbnRleHQgd2FzIHVzZWQgYnkgdGhlIHNlcnZlciB0byBlbmNy eXB0IHRoZSBtZXNzYWdlIHRoYXQNCj53YXMgcmV0dXJuZWQuICAoU3BlY2lmaWNhbGx5LCB0aGUg c2FtZSBjb250ZXh0IGFuZCB0aGUgY2xpZW50IHVzZWQgdG8NCj5lbmNyeXB0IHRoZSByZXF1ZXN0 LikNCg0KVGhlIGNvbnRleHQgbWF5IGJlIGRpZmZlcmVudCBmb3IgcmVxdWVzdCBhbmQgcmVzcG9u c2UsIGFuZCBhbHdheXMgaXMgaW4NCk9TQ09BUC4NCg0KDQo+IFRoaXMgbWVhbnMgdGhhdCB3ZSBj YW4gc2F5IHRoYXQgdGhlcmUgaXMgYW4gaW1wbGljaXQNCj5jb250ZXh0IGZvciBlbmNyeXB0ZWQg bWVzc2FnZXMgaW4gdGhpcyBjYXNlIHRoZSBuZXcgZW5jcnlwdGlvbiBzdHJ1Y3R1cmUNCj53L28N Cj5yZWNpcGllbnRzIHdvdWxkIG1ha2Ugc2Vuc2UuICBUaGlzIGFuYWx5c2lzIHdvdWxkIGFwcGx5 IHRvIHRoZSBvYnNlcnZlDQo+ZGlhbG9nIHN0cnVjdHVyZSBhcyB3ZWxsLCB0aGUgdG9rZW4gY2Fu IGJlIHVzZWQgdG8gYXNzb2NpYXRlIGFsbCBpdGVtcyBpbg0KPnRoZSBzYW1lIGNvbnRleHQuDQoN CkV2ZW4gaWYgdGhlcmUgYXJlIGNhc2VzIHdoZXJlIGxlYXZpbmcgb3V0IGNvbnRleHQgaW4gcmVz cG9uc2UgY291bGQgYmUNCnBlcmZvcm1lZCwgSSB0aGluayBpdCBzaG91bGQgYmUgYWxsb3dlZCB0 byBzcGVjaWZ5IGNvbnRleHQgYXMgYW4gb3B0aW9uLg0KVGhpcyB3b3VsZCBhbHNvIHJlbGlldmUg dGhlIHNldHRpbmdzIHdoZXJlIG11bHRpcGxlIGNvbnRleHRzIG5lZWRzIHRvIGJlDQp0cmllZC4N Cg0KPg0KPkZvciBhIHN1YnNjcmlwdGlvbiBtb2RlbCB0byBhIHRoaXJkIHBhcnR5LCB0aGVyZSBh cmUgYSBjb3VwbGUgb2YgZGlmZmVyZW50DQo+d2F5cyB0byBsb29rIGF0IGhvdyBpdCBjYW4gYmUg c2V0dXAuICBUaGUgYmlnIHF1ZXN0aW9uIGlzIGlmIHRoZSBjb250ZXh0DQo+aXMNCj5nb2luZyB0 byBiZSB1bmlxdWUgdG8gdGhlIG9yaWdpbmF0b3IsIG9yIGl0IGlzIHVuaXF1ZSB0byB0aGUgc3Vi c2NyaXB0aW9uLg0KPkluIGVpdGhlciBjYXNlLCB0aGUgY2xpZW50IGlzIGdvaW5nIHRvIGVuZCB1 cCB1c2luZyB0d28gZGlmZmVyZW50IGNvbnRleHRzDQo+aW4gdGhpcyBzaXR1YXRpb24uICBUaGUg Zmlyc3QgY2FzZSBpcyBmb3Igc2V0dGluZyB1cCB0aGUgb3JpZ2luYWwNCj5zdWJzY3JpcHRpb24u ICBJbiB0aGF0IGNhc2UgYSBjb250ZXh0IGFzc29jaWF0ZWQgd2l0aCB0aGUgZGF0YSBzdG9yYWdl DQo+c2VydmVyIGlzIGdvaW5nIHRvIGJlIG5lZWRlZC4gIEhvd2V2ZXIsIG9uY2UgaW5mb3JtYXRp b24gc3RhcnRzIGZsb3dpbmcNCj5iYWNrDQo+dG8gdGhlIGNsaWVudCBmcm9tIHRoZSBkYXRhIHN0 b3JhZ2Ugc2VydmljZSwgdGhlIGNvbnRleHQgYXNzb2NpYXRlZCB3aXRoDQo+dGhlDQo+b3JpZ2lu YXRpb24gc2VydmVyIGlzIGdvaW5nIHRvIGJlIHVzZWQuICBJdCBpcyBub3QgY2xlYXIgdGhhdCB0 aGUgYWN0aW9uDQo+b2YNCj5kb2luZyB0aGUgc3Vic2NyaXB0aW9uIHdvdWxkIG5lZWQgdG8gYmUg ZW5jcnlwdGVkLCAgdGhpcyBzaW1wbGlmaWVkIHRoaW5ncw0KPmFzIG9ubHkgb25lIGVuY3J5cHRp b24gY29udGV4dCBpcyBub3cgbmVlZGVkLiAgT3RoZXJ3aXNlIGVpdGhlciB0d28NCj5jb250ZXh0 cw0KPm5lZWQgdG8gYmUgdHJpZWQsIG9yIHRoZSB0eXBlIG9mIG1lc3NhZ2UgbmVlZHMgdG8gYmUg a25vd24gc28gdGhhdCB0aGUNCj5jbGllbnQgdW5kZXJzdGFuZCB3aGVyZSB0aGUgZW5jcnlwdGVk IGNvbnRlbnQgb3JpZ2luYXRlcy4NCg0KVGhlIGRhdGEgc3RvcmUgbmVlZCBub3QgYmUgdHJ1c3Rl ZC4gSW5mb3JtYXRpb24gYWJvdXQgYmluZGluZyBiZXR3ZWVuDQpkaWZmZXJlbnQgY29udGV4dHMg bmVlZHMgdG8gYmUgb2J0YWluZWQgZnJvbSBhIHRydXN0ZWQgcGFydHksIHN1Y2ggYXMgdGhlDQph dXRob3JpemF0aW9uIHNlcnZlci4gSSBiZWxpZXZlIHRoZSBwcmVzZW5jZSBvZiBhIGNvbnRleHQg aWRlbnRpZmllciB3b3VsZA0Kc2ltcGxpZnkgdGhlIHByb2Nlc3Npbmcgd2hlcmUgdGhpcyB0eXBl IG9mIGJpbmRpbmcgbmVlZHMgdG8gYmUgZXN0YWJsaXNoZWQNCmFmdGVyIHRoZSBtZXNzYWdlIGhh cyBiZWVuIHJlY2VpdmVkLCBjb21wYXJlZCB0byB0aGUgY2FzZSBvZiByZWNlaXZpbmcgYW4NCmVu Y3J5cHRlZCBzdHJ1Y3R1cmUgd2l0aG91dCBhbnkgaGFuZGxlIHdoYXRzb2V2ZXIuDQoNCj4NCj5G b3IgdGhlIGNhc2Ugb2YgbXVsdGljYXN0LCBpdCBhcHBlYXJzIHRvIG1lIHRoYXQgdGhlIGNvbnRl eHQgY2FuIGJlDQo+aW5mZXJyZWQNCj5pbiBtb3N0IGNhc2VzLiAgSSB3b3VsZCBhc3N1bWUgdGhh dCBhIGNvbnRleHQgaXMgZ29pbmcgdG8gYmUgc2lnbmVkIHRvDQo+ZWFjaA0KPm11bHRpY2FzdCBh ZGRyZXNzLCBwb3J0IHBhaXIuICBJIHdvdWxkIGFsc28gYXNzdW1lIHRoYXQgdGhpcyB3b3VsZCBi ZSBhDQo+dW5pcXVlIGFzc2lnbm1lbnQgaW4gdGhhdCBtdWx0aXBsZSBjb250ZXh0cyB3b3VsZCBu b3QgYmUgYXNzaWduZWQuICBUaGlzDQo+ZG9lcyBhbGxvdyBmb3IgYW55IG5vZGUgd2hpY2ggaGFz IHRoZSBjb250ZXh0IHRvIHNlbmQgb3V0IGEgbXVsdGljYXN0DQo+bWVzc2FnZSB3aXRob3V0IGEg cHJvYmxlbS4gIFRoZSBtb3JlIGludGVyZXN0aW5nIHF1ZXN0aW9uIGlzIHdoYXQgdG8gZG8NCj53 aXRoDQo+dGhlIHVuaWNhc3QgcmVzcG9uc2VzIHRvIGEgbXVsdGljYXN0IG1lc3NhZ2UuICBTaG91 bGQgdGhleSBiZSBlbmNyeXB0ZWQNCj53aXRoDQo+dGhlIG11bHRpY2FzdCBncm91cCBjb250ZXh0 LCBpbiB3aGljaCBjYXNlIHRoZSBtZXNzYWdlIGlkL3Rva2VuIG9uIHRoZQ0KPm1lc3NhZ2UgaXMg c3VmZmljaWVudCB0byBpZGVudGlmeSB0aGUgY29udGV4dC4gIE9yIHNob3VsZCB0aGV5IGJlDQo+ ZW5jcnlwdGVkDQo+d2l0aCBhIHVuaWNhc3Qga2V5IHBhaXIgYmV0d2VlbiB0aGUgcmVwbGllciBh bmQgdGhlIG9yaWdpbmFsIG1lc3NhZ2UNCj5zZW5kZXI/DQo+VGhpcyBpbXBsaWVzIHRoYXQgc3Vj aCBhIGtleSBjb250ZXh0IG5lZWRzIHRvIGJlIHNldHVwIGZvciBlYWNoIHN1Y2ggbGluaw0KPndo aWNoIG1heSBvciBtYXkgbm90IGJlIHRoZSBjYXNlLiAgSW4gdGhpcyBldmVudCBpdCBtaWdodCBi ZSBuZWNlc3NhcnkgdG8NCj5pZGVudGlmeSB0aGUgY29udGV4dCB0aGF0IHdhcyB1c2VkIHRvIGVu Y3J5cHQgdGhlIHVuaWNhc3QgbWVzc2FnZS4gIEkgaGF2ZQ0KPm5vdCBtYW5hZ2VkIHRvIHRoaW5r IHRoaXMgdGhyb3VnaCBmYXIgZW5vdWdoLg0KPg0KPkluIGFueSBldmVudCwgdGhlcmUgYXBwZWFy IHRvIGJlIGVub3VnaCBjYXNlcyB3aGVyZSB0aGUgZW5jcnlwdGlvbiBjb250ZXh0DQo+Y2FuIGJl IGluZmVycmVkIGZyb20gdGhlIG1lc3NhZ2UgdG8gbWFrZSBpdCByZWFzb25hYmxlIHRvIGhhdmUg YSB2ZXJzaW9uDQo+b2YNCj5DT1NFIG1lc3NhZ2VzIHdoaWNoIGRvIG5vdCBoYXZlIGFueSByZWNp cGllbnQgaW5mb3JtYXRpb24gYXR0YWNoZWQgdG8NCj50aGVtLg0KPkluIHRoZSBjYXNlIG9mIHB1 cmUgdW5pY2FzdCwgaXQgd291bGQgYmUgdXNlZCBmb3IgYXQgbGVhc3QgNTAlIG9mIHRoZQ0KPm1l c3NhZ2VzIChhIGhpZ2hlciBwZXJjZW50YWdlIGZvciBvYnNlcnZpbmcgc3RhdGUpLiAgQW5kIGZv ciBtdWx0aWNhc3QgaXQNCj5taWdodCBiZSB1c2VkIGVpdGhlciBmb3IgNTAlIG9yIGFsbCBvZiB0 aGUgbWVzc2FnZXMgZGVwZW5kaW5nIG9uIGhvdw0KPnJlc3BvbnNlcyBhcmUgaGFuZGxlZC4NCj4N Cj5JIGFtIGludGVyZXN0ZWQgaW4gcGVvcGxlIGxvb2tpbmcgYXQgbXkgYW5hbHlzaXMgYW5kIHRl bGwgbWUgaWYgSSBhbQ0KPnJpZ2h0LA0KPndyb25nIG9yIHVuY2xlYXIuDQoNCg0KVGhlcmUgYXJl IGNhc2VzIHdoZXJlIG9wdGltaXplZCBtZXNzYWdlIGFuZCBjb250ZXh0IGlkZW50aWZpY2F0aW9u IGFyZQ0KbmVlZGVkLCBvciB3aGVyZSBhIGNvbnRleHQgaWRlbnRpZmllciBjb3VsZCBzaW1wbGlm eSB0aGUgcHJvY2Vzc2luZy4gSW4NCmJvdGggY2FzZXMgYWxsb3dpbmcgb3B0aW9uYWwgaGVhZGVy IGluIHRoZSBDT1NFX2VuY3J5cHRlZCBmb3JtYXQgd291bGQNCnNvbHZlIHRoZSBwcm9ibGVtLiBG b3IgcmVwbGF5IHByb3RlY3Rpb24sIHNvbWUgY29udGV4dCBpbmZvcm1hdGlvbiBzdWNoIGFzDQpz ZXF1ZW5jZSBudW1iZXIvbm9uY2UgbmVlZHMgYW55d2F5IHRvIGJlIHRyYW5zZmVycmVkLCBzbyBJ IHdvdWxkIHNheSB0aGF0DQp0aGUgY29udGV4dCBjYW5ub3QgYmUgY29tcGxldGVseSBpbXBsaWNp dC4NCg0KDQpHw7ZyYW4NCg0KDQo= From nobody Mon Sep 14 06:01:48 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 A3EA01B5F42 for ; Mon, 14 Sep 2015 06:01:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.7 X-Spam-Level: X-Spam-Status: No, score=0.7 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 ZN3-NTqzANXk for ; Mon, 14 Sep 2015 06:01:44 -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 B9BF21B5F07 for ; Mon, 14 Sep 2015 06:01:43 -0700 (PDT) Received: by qkfq186 with SMTP id q186so57384062qkf.1 for ; Mon, 14 Sep 2015 06:01:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type :content-transfer-encoding; bh=enFIHPwpAHdjAWgb/WccMqQDNp3cUsH1UnmD83WD4SI=; b=qcl6N6HLfFS+d8EzQn7Ufhvm755jtLyG1OrsTO2J81KOR1+I5w0jDlLgbJjLfoVAWU Z2TcoCYBhO6ytDZRVVNKtN+sZRrgtgxfyPql4QP7Mw7VbY652UFy/I82zayEkipbOnxG 9uMajkItM4EwVi7bzrWHS5Pv9iU3+OCl6TvZI94PPe6odx6hFriil+EXaPGFiu2KkM2+ AyJ9+cuzatMjKHEW4g444v4kKeQWhZJCFdRNeJpw+ljYA6Olq5BWdYDrkri26RREXqgC ocZV0bH+OfSy2PebinbGA4Pt2/nSdQRxzBYOLHSD/YfeILWirFOaSKA3p18b1zytu3xp ITcQ== X-Received: by 10.55.197.69 with SMTP id p66mr20867360qki.59.1442235699457; Mon, 14 Sep 2015 06:01:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.55.33.134 with HTTP; Mon, 14 Sep 2015 06:01:19 -0700 (PDT) From: Renzo Navas Date: Mon, 14 Sep 2015 15:01:19 +0200 Message-ID: To: ace Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: [Ace] DCAF Review (draft-gerdes-ace-dcaf-authorize) 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, 14 Sep 2015 13:01:46 -0000 Good Afternoon ACE ML, I send here a review of DCAF https://tools.ietf.org/html/draft-gerdes-ace-dcaf-authorize-02 version 02, though most of comments applies for -recent- 03. I want to publicly thank to the authors of DCAF (Steffi, Olaf, Carsten), I found it a very useful document (very detailed), I found it one of the most 'mature' ACE architectures, and with a lot of pointers to take it to reality from an implementation point of view. In fact at my everyday-work we want some AA Architecture for IoT, and are trying to push something like DCAF, though I'm interested on trying to offer COSE security instead of DTLS. This is my first review ever, so sorry in advance for my inexperience. I have a software development background, so I believe most of my comments come from an implementation point of view. In the last months I've been trying to get more on the AA and security world. I've been following the ACE working group for some months now, and I really appreciate the effort of all of you. I hope to start contributing more, and these are my two cents for now. Have a good start of the week Renzo -------------------------------------- DCAF Review >1.2.1 Actors Harmonize definitions with draft-ietf-ace-actors-00: S -- RS ; SAM -- AS ; CAM -- CAS ; AM -- ?? (how to map AM concept into actors draft, needs discussion?) ; COP -- RqP; ROP -- RO >1.2.2. Other Terms "Verifier" (can be clarifying to mention on parentheses an example of a verifier?, for instance adding : Verifier e.g: information representing a 128-bit PSK) Should not be useful to define CAI , SAI? They are defined on Section 5. but before the formal definition they are used a lot. >3. Protocol > 2 . transfer of access request and respective ticket grants Change =E2=80=9Cticket grants=E2=80=9D for "ticket transfer" (C and CAM tra= nsfer what's been defined as Ticket Transfer)? > 3 . transfer of access request and respective ticket grants Change =E2=80=9Caccess request=E2=80=9D for "ticket requests" (SAM and CAM = transfer what's been defined as Ticket Requests)? > 3.2 =E2=80=9Cinsecure channel=E2=80=9D ('insecure' or 'unsecured' -or 'no= n-secured'-? I could not find any formal definition on RFCs. rfc4949 mentions =E2=80=9Cunsecured networks=E2=80=9D, I found this discussion http://english.stackexchange.com/questions/19653/insecure-or-unsecure-when-= dealing-with-security I point this to raise the discussion, does RFC4949 suffice or we need more -rfc- security glossary? > 3.5 Ticket Request, Should not 4.03 be sent only if ALL of the requested actions are forbidden? Stated otherwise, if at least one action is not forbidden then CAM attempts a ticket Request. (if this is the case, should this be stated clearer on the text?) The ticket request will be for all actions C specified (even the ones not allowed) or CAM will change the SAI according to COP=E2=80=99s policies= ? About the Label for client: =E2=80=9C5. A label that describes the Client is added to the payload=E2=80= =9D see comment on 10.1, what role plays this label (for my understanding does not play any role), what is the format of the label (on the examples is missing)? OK, I think this point is here from previous versions of document, should be removed? >3.6 Ticket Grant Message "When access is granted, the data structure contains the Ticket Face, th= e Client Information, which at this point only consists of the Verifier and the Session Key Generation Method." Access Ticket, does contain Face and Client Info. If I understood correctly here is stated that the Client Information consist of Verifier and the Session Key Gen? Why the CI has the Session key gen method (should not be this part of the Face that is destined to the RServer)? On the example the Gen method is part of the Face, so maybe can this sentence be rephrased to let clear that the session key gen is part of the ticket face? > 3.7 Ticket Transfer Message =E2=80=9CThe Ticket Transfer message is (...) and includes any access information from SAM contained on the Ticket Grant message=E2=80=9D, What does this =E2=80=9Cany=E2=80=9D mean? (explicitly the documents later = says that CAM MUST NOT include any CAI information provided by SAM), so this =E2=80=9Cany=E2=80=9D means =E2=80=9Csome=E2=80=9D (Face and Verifier? but = not CAI)? I think =E2=80=9Cany=E2=80=9D is a confusing term. Can we have an example of CAI info from from SAM ? (the CAI will be included on the Face or is stand alone? OK, as the Face cannot be changed, because the same face must be possessed by C and S for a successful DTLS session handshake, so I assume is stand alone) why would a SAM add a CAI? (and not restrict the Token on SAI directly?) maybe to force CAM to enforce that CAI? if a CAI coming from SAM its with that purpose, then when specification when says =E2=80=9CCAM MUST NOT include any CAI info from SAM= =E2=80=9D means that the CAM does not care -or on the contrary, it takes it in account but adds its own policies also respecting COP=E2=80=99s enforced CA= I-? > 3.9 Authorized Resource Request Message =E2=80=9Cmust check T=E2=80=9D -meaning- TS? ( T is not defined later) How does RS distinguish two different clients if they have the same Face (face must be unique then)? what identifies a client? must be on the face? OK, after reading the whole document the TS on the Face is the thing that can uniquely identifies a ticket (and will be sent by CAM to one and only one C, so one ticket with a unique TS can be possessed by only one client).. So I think it needs to be stressed the importance of the TS field, It must be unique per ticket (must be a precise clock on SAM), if the TS of two Tickets repeats/is the same we are in problems. (comment after reading 4.1) If S generates the timestamp.. due to its constrained nature does not this pose a problem because we can have TS collisions? Can we really guarantee that S will not generate two times the same TS? (e.g: if it resets..) > 4. Ticket The CI plus the Face goes to the Client will not be more accurate? The client without the Face cannot start the DTLS session (so in a way the Face is also destined to the Client) Only Face is needed No additional information is needed to ID the client? (so the unique way the client id can be seen as the TS?)). OK -seems to be that way, the TS is the id of the ticket- > 5. Payload Format and Encoding TS: time stamp; =E2=80=9CAn optional timestamp that indicates =E2=80=A6 whe= n the access ticket request=E2=80=9D , For the access request may be optional, but for the ticket grant/ticket transfer is needed as a part of the Face (on Face description 4.1 is marked as a MUST) should not this distinction be clear(er)? The TS for the Ticket Face is not optional is a MUST, without it a client cannot be uniquely associated with a Ticket Face (it is the only unique id, field, possible to distinguish one Ticket Face of another), this is marked down when the field =E2=80=9CF=E2=80=9D is explain= ed. however it was confusing to me to be defined as optional. Maybe can be clarified that is optional when is not a part of Face. > 5.1 Examples * text It says that the Face contains a =E2=80=9Cclient descriptor=E2=80=9D= is missing? . Ok now I read version 00 of the document and client descriptor is there. So on the current version no more Client Descriptor is needed/present, this =E2=80=9Cclient descriptor=E2=80=9D has = to be erased * Encrypted face uses the shared S/SAM key and the TS as nonce. The TS of the Face was put by SAM not by S -if Im not mistaken the SAM put the TS when it generates the ticket) ? (why says =E2=80=9CS=E2=80=99s times= tamp=E2=80=9D?), also for S to decrypt the Encrypted face, it will need the nonce (TS), but if he only receives E K V he will not have the appropriate nonce to decrypt E. Am I mistaken or the nonce should be passed to S also? After reading carefully the document also allows to S to generate the Timestamp (I mentioned that this could lead to problems). But how would S know what timestamp to use as nonce (he cannot associate an Encrypted face with an unauthorised old request? . The problem of what nonce to use is still true if SAM is the generator of TS. solution: send the nonce aside the encrypted face (E ,K, nonce, V)? OK. This nonce problem seems to be adressed on version 03 of the document > 8. Trust Relationships "1. SAM has means to authenticate CAM (e.g. it has a certificate of CAM or a PKI in which CAM is included) and vice versa" worth mentioning the =E2=80=9Cmutual authentication=E2=80=9D concept? "2. As far as SAM needs to rely on the different clients of CAM to receive different permissions, it can be sure that CAM correctly identifies these clients towards SAM and does not leak tickets" what does =E2=80=9Ctowards SAM=E2=80=9D means/adds? is it needed to add tha= t (would not work the phrase/protocol the same without that)? (CAM does not send any client information to SAM -nothing to id a particular client-) > FIGURE Figure missing number? > 10 Examples > 10.1CAM-->SAM Ticket Request, on section 3.5 is specified that Token Request messages contains =E2=80=9C5= . A label that describes the client is added to the payload=E2=80=9D On the example is not present. What purpose serves that label? (also on dcaf field identifiers seems not the be a =E2=80=9Clabel=E2=80=9D), shou= ld this point 5 on section 3.5 be erased or marked as optional? Ok now that I read older version of drafts seems that label that describes client is no longer used, so on section 3.5 should be erased? Should be useful to see the message exchange between SAM and S? From nobody Mon Sep 14 09:11: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 366E31B452B for ; Mon, 14 Sep 2015 09:11:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.9 X-Spam-Level: X-Spam-Status: No, score=-0.9 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, MIME_8BIT_HEADER=0.3, 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 SrmVKvsgNgjx for ; Mon, 14 Sep 2015 09:11:24 -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 B12341B458D for ; Mon, 14 Sep 2015 09:11: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 smtp2.pacifier.net (Postfix) with ESMTPSA id 011412CA09; Mon, 14 Sep 2015 09:11:23 -0700 (PDT) From: "Jim Schaad" To: =?UTF-8?Q?'G=C3=B6ran_Selander'?= , References: <007901d0eea4$25989bf0$70c9d3d0$@augustcellars.com> In-Reply-To: Date: Mon, 14 Sep 2015 09:09:03 -0700 Message-ID: <002b01d0ef07$aced5970$06c80c50$@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: AQGGfwiYLGVnvC1rumdUoUJ+HdJvIQI0bA87nr9oCYA= Archived-At: Subject: Re: [Ace] Looking at COSE based unicast and multicast 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, 14 Sep 2015 16:11:27 -0000 > -----Original Message----- > From: G=C3=B6ran Selander [mailto:goran.selander@ericsson.com] > Sent: Monday, September 14, 2015 2:48 AM > To: Jim Schaad ; ace@ietf.org > Subject: Re: [Ace] Looking at COSE based unicast and multicast >=20 >=20 >=20 > On 2015-09-14 06:16, "Jim Schaad" wrote: >=20 > > > >>From this, it seems to me that does support the position that some > >information about context needs to be passed on the initial message. > >Depending on how this is presented I would expect this to be done = with > >the current COSE encrypted message structure. It is potentially > >different in the case where the client is being used to relay > >information to the server about the authorization information. >=20 > Using the current COSE encrypted message structure is not addressing = the > concerns about message size as has been discussed previously. From the > proposed ACE architecture I can reference two categories of formats: >=20 > 1. One category which assumes that there is essentially only a = =E2=80=9Cbase key=E2=80=9D > established between sender and receiver, and where the message = provides > means to derive the security context to use with the message. >=20 > 2. Another category which is highly optimized for the setting that the = security > context is available at the receiver. >=20 >=20 > I think the distinction between COSE_Enveloped and COSE_Encrypted = structure > is a good step in the right direction, but the latter should allow for = the desired > identification and optimization for the most common settings. = Something like: >=20 > [ message type, protected headers, cipher text, tag ] >=20 >=20 > where protected headers can identify the security context and the > nonce/sequence number. >=20 > In fact, to get replay protection of request, and of response if no = prior request > bound to the response, one of the fields in the protected header must = be > nonce/sequence number/timestamp, right? Thus the format would anyway > carry some information about security context. It seems odd to not = allow an > identifier of what context this nonce/etc. refers to. >=20 >=20 > > > >The response does not appear to need a context identifier as there is > >already information in the CoAP message that can be used for > >determining the context. >=20 > >Specifically the Token and Message ID fields can be used to associate > >requests and responses. >=20 > Message ID is not a reliable identifier for associating request to = response. First, please note that I said both Token and Message ID. Are there = cases that between these two fields the request and the response cannot = be associated? >=20 > > This means that a client can use this to determine what context was > >used by the server to encrypt the message that was returned. > >(Specifically, the same context and the client used to encrypt the > >request.) >=20 > The context may be different for request and response, and always is = in > OSCOAP. Please note that I am using context in the same way that TLS uses this = term. This means that the information is going to be different for the = two directions, but the context identifies a single set of information. = =20 I don't see anything called OSCOAP in either core or ace. >=20 >=20 > > This means that we can say that there is an implicit context for > >encrypted messages in this case the new encryption structure w/o > >recipients would make sense. This analysis would apply to the = observe > >dialog structure as well, the token can be used to associate all = items > >in the same context. >=20 > Even if there are cases where leaving out context in response could be > performed, I think it should be allowed to specify context as an = option. > This would also relieve the settings where multiple contexts needs to = be tried. Please identify situations where multiple contexts would need to be = tried. I have only come up with one so far, assuming that one is going = to use distinct address/port pairs for the multi-cast case. That would = be the case of subscribing. >=20 > > > >For a subscription model to a third party, there are a couple of > >different ways to look at how it can be setup. The big question is = if > >the context is going to be unique to the originator, or it is unique = to > >the subscription. > >In either case, the client is going to end up using two different > >contexts in this situation. The first case is for setting up the > >original subscription. In that case a context associated with the = data > >storage server is going to be needed. However, once information = starts > >flowing back to the client from the data storage service, the context > >associated with the origination server is going to be used. It is = not > >clear that the action of doing the subscription would need to be > >encrypted, this simplified things as only one encryption context is > >now needed. Otherwise either two contexts need to be tried, or the > >type of message needs to be known so that the client understand where > >the encrypted content originates. >=20 > The data store need not be trusted. Information about binding between > different contexts needs to be obtained from a trusted party, such as = the > authorization server. I believe the presence of a context identifier = would simplify > the processing where this type of binding needs to be established = after the > message has been received, compared to the case of receiving an = encrypted > structure without any handle whatsoever. In my analysis I did not make any assumptions that the data store was = trusted to do anything more than its assigned job. I did not make any = assumptions that it would do cryptography except for messages sent = directly to it. =20 I do not see any difference in needing to obtain the keys/context = information either before or after receiving the first message. = However, since we do not have a sketched protocol for getting keys yet = it is hard to be sure. Even if you have current keys you will still = need to be able to get updated keys when the epoch rolls over to the = next value. This means that the two cases are going to be very similar. >=20 > > > >For the case of multicast, it appears to me that the context can be > >inferred in most cases. I would assume that a context is going to be > >signed to each multicast address, port pair. I would also assume = that > >this would be a unique assignment in that multiple contexts would not > >be assigned. This does allow for any node which has the context to > >send out a multicast message without a problem. The more interesting > >question is what to do with the unicast responses to a multicast > >message. Should they be encrypted with the multicast group context, = in > >which case the message id/token on the message is sufficient to > >identify the context. Or should they be encrypted with a unicast key > >pair between the replier and the original message sender? > >This implies that such a key context needs to be setup for each such > >link which may or may not be the case. In this event it might be > >necessary to identify the context that was used to encrypt the = unicast > >message. I have not managed to think this through far enough. > > > >In any event, there appear to be enough cases where the encryption > >context can be inferred from the message to make it reasonable to = have > >a version of COSE messages which do not have any recipient = information > >attached to them. > >In the case of pure unicast, it would be used for at least 50% of the > >messages (a higher percentage for observing state). And for = multicast > >it might be used either for 50% or all of the messages depending on = how > >responses are handled. > > > >I am interested in people looking at my analysis and tell me if I am > >right, wrong or unclear. >=20 >=20 > There are cases where optimized message and context identification are > needed, or where a context identifier could simplify the processing. = In both > cases allowing optional header in the COSE_encrypted format would = solve the > problem. For replay protection, some context information such as = sequence > number/nonce needs anyway to be transferred, so I would say that the = context > cannot be completely implicit. Yes, some input into an IV needs to be transferred, but I would not = consider that to be part of the saved context. This is not needed for = replay protection as much as it is needed for making sure that IVs are = not re-used. This could potentially be different from the sequence = number used for replay protection but generally would not be. I would expect that you would never want to send information you do not = have to since it only adds size. But still trying to figure out where = it is and is not needed to have a context identifier to begin with. = Then we can figure out where and if it makes sense to include it. But = at that point you are already talking about taking size hits. Jim >=20 >=20 > G=C3=B6ran >=20 From nobody Mon Sep 14 23:20: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 6776A1A8879 for ; Mon, 14 Sep 2015 23:20:32 -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 2a0fyGN0H5ce for ; Mon, 14 Sep 2015 23:20:27 -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 82CC51A6FC9 for ; Mon, 14 Sep 2015 23:20:26 -0700 (PDT) X-AuditID: c1b4fb3a-f79136d0000071e2-3b-55f7b8a8f7df Received: from ESESSHC005.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 13.9F.29154.8A8B7F55; Tue, 15 Sep 2015 08:20:24 +0200 (CEST) Received: from ESESSMB303.ericsson.se ([169.254.3.214]) by ESESSHC005.ericsson.se ([153.88.183.33]) with mapi id 14.03.0248.002; Tue, 15 Sep 2015 08:20:23 +0200 From: =?utf-8?B?R8O2cmFuIFNlbGFuZGVy?= To: Jim Schaad , "ace@ietf.org" Thread-Topic: [Ace] Looking at COSE based unicast and multicast Thread-Index: AdDuo/sorjKxXnJSQaGX5o+dQpuhBgALnjSAAAkdOYAAIeyMAA== Date: Tue, 15 Sep 2015 06:20:23 +0000 Message-ID: References: <007901d0eea4$25989bf0$70c9d3d0$@augustcellars.com> <002b01d0ef07$aced5970$06c80c50$@augustcellars.com> In-Reply-To: <002b01d0ef07$aced5970$06c80c50$@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.149] Content-Type: text/plain; charset="utf-8" Content-ID: <442AD1D3EDC7404893F7CEBAFF4409EE@ericsson.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpnkeLIzCtJLcpLzFFi42KZGfG3RnfFju+hBvdOyFh8/9bDbLF6+nc2 ByaPjXOms3ksWfKTKYApissmJTUnsyy1SN8ugStj9om9zAXzWhkrpk17z97A+KKRsYuRk0NC wETi3LnbULaYxIV769m6GLk4hASOMkr8793GCuEsYZRYe2cTM0gVm4CLxIOGR0wgtoiAm8TZ yctYQGxhATuJW59vsUDE7SX+HuiHsp0kpnzoBrNZBFQllp1uA9vGK2AhsfzxKUa4BScWLWMF SXAKOEhMPLIBbBkj0EnfT60BW8YsIC5x68l8JohTBSSW7DnPDGGLSrx8/A+sV1RAT2Ll9SY2 iLiSxNrD24EWcwD1akqs36UPMcZaYsfHJWwQtqLElO6H7BD3CEqcnPmEZQKj+Cwk22YhdM9C 0j0LSfcsJN0LGFlXMYoWpxYX56YbGemlFmUmFxfn5+nlpZZsYgTG3MEtv612MB587niIUYCD UYmH98Hm76FCrIllxZW5hxilOViUxHmbmR6ECgmkJ5akZqemFqQWxReV5qQWH2Jk4uCUamBU /tqxuvDqk333mM2WXWkKYLLcvTH0sZLRg33fA3fc/2e40zzn+7KAhwcVD157bW92Orvj693q nHkPugSZffJr2ts2T7gt8nbvVZXo7ysP/+EX3/TG5M+SXrVTpyYI2Ua8Xtp4Q07hmzDzqv37 e9ma//TOFVimfvTQj5tMyi63J0+f+fZh4qGdM5VYijMSDbWYi4oTAczgSe6aAgAA Archived-At: Subject: Re: [Ace] Looking at COSE based unicast and multicast 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, 15 Sep 2015 06:20:32 -0000 Q29tbWVudHMgaW5saW5lLg0KDQpNeSBzdW1tYXJ5OiANCg0KVGhlIHJlcXVlc3QgaW4gZ2VuZXJh bCBuZWVkcyBhIGNvbnRleHQgaWRlbnRpZmllci4gWW91ciBwcm9wb3NhbCBpcyB0byB1c2UNCnRo ZSBDT1NFX2VudmVsb3BlZCBmb3JtYXQsIG15IHByb3Bvc2FsIGlzIHRvIGFsbG93IGFuIG9wdGlv bmFsIGNvbnRleHQNCmlkZW50aWZpZXIgaW4gdGhlIENPU0VfZW5jcnlwdGVkIGZvcm1hdCwgd2hp Y2ggaXMgbW9yZSBjb21wYWN0Lg0KDQpJZiB5b3UgYXNzb2NpYXRlIHRoZSBDb0FQIFRva2VuIG9m IGEgcmVxdWVzdCB0byB0aGUgY29udGV4dCB0aGVuIHlvdSBjYW4NCnVzZSB0aGF0IGFzIGFuIGlu ZGV4IGZvciBjb250ZXh0IGlkZW50aWZpZXIgaW4gdGhlIHJlc3BvbnNlIGFuZCBoZW5jZSB1c2UN CkNPU0VfZW5jcnlwdGVkLiBCdXQgbm93IHlvdSBoYXZlIHR3byBwYXJhbWV0ZXJzIHRoYXQgcGVy Zm9ybSBhIHNpbWlsYXINCnRhc2s6IFRva2VuIGFuZCBDb250ZXh0IElkZW50aWZpZXIsIGFuZCB3 aGljaCBib3RoIGhhcyB0byBiZSB0cmFuc2ZlcnJlZA0KaW4gYSByZXF1ZXN0LiBUaGUgVG9rZW4g ZmllbGQgaXMgdmFyaWFibGUgbGVuZ3RoIDAtOCBieXRlcy4gU2luY2Ugd2UNCmNhbm5vdCBhdHRy aWJ1dGUgYW55IGVuZC10by1lbmQgc2VjdXJpdHkgcHJvcGVydGllcyBvZiBUb2tlbiwgdGhlIG9i amVjdA0Kc2VjdXJpdHkgc2NoZW1lIGlzIG1hZGUgaW5kZXBlbmRlbnQgb2YgaG93IHRoZSBUb2tl biBpcyBzZXQsIGFuYWxvZ291c2x5DQp0byB0aGUgY2FzZSBpbiBEVExTLiBCeSBpbnN0ZWFkIHJl bHlpbmcgb24gVG9rZW4gdG8gYXZvaWQgY29sbGlzaW9ucyB3ZQ0KbWF5IG5lZWQgYSBsYXJnZXIg VG9rZW4uDQoNCknigJltIG5vdCBjb252aW5jZWQgd2l0aCB0aGUgZGlmZmVyZW5jZSBiZXR3ZWVu IGhvdyB0aGUgbWVzc2FnZSBpcyBmb3JtYXR0ZWQNCmRlcGVuZGluZyBvbiB3aGV0aGVyIGl0IGlz IGEgcmVxdWVzdCBvciByZXNwb25zZS4gQSBnaXZlbiBub2RlIG1heSBzZW5kDQp0aGUgc2FtZSBy ZXNvdXJjZSByZXByZXNlbnRhdGlvbiBhcyBQVVQgcmVxdWVzdCBvciBHRVQgcmVzcG9uc2UgYW5k IHRodXMNCndvdWxkIHVzZSBkaWZmZXJlbnQgQ09TRSBtZXNzYWdlIGZvcm1hdHMuDQoNCg0KSXQg aXMgYWxzbyBhIG1hdHRlciBvZiBob3cgdGhlIHJlY2VpdmVkIENPU0Ugb2JqZWN0IHdpbGwgYmUg c3Vic2VxdWVudGx5DQp1c2VkLiBGb3IgZXhhbXBsZSwgaW4gSW5mb3JtYXRpb24tQ2VudHJpYyBO ZXR3b3JraW5nLCBpZiBJ4oCZbSBub3QgbWlzdGFrZW4sDQpvbmUgb2YgdGhlIHJlcXVpcmVtZW50 cyBpcyB0aGF0IGVhY2ggcHJvdGVjdGVkIG9iamVjdCBoYXMgYSBnbG9iYWxseQ0KdW5pcXVlIG5h bWUuIEJ5IHNoaWZ0aW5nIGZvY3VzIGZyb20gYSBjb250ZXh0IGlkZW50aWZpZXIgd2l0aGluIHRo ZSBDT1NFDQpvYmplY3QgdG8gVG9rZW4gd2hpY2ggaXMgZXBoZW1lcmFsIGRhdGEgb3V0c2lkZSB0 aGUgQ09TRSBvYmplY3QsIElDTg0KYXBwbGljYXRpb25zIHdvdWxkIGFsd2F5cyBoYXZlIHRvIHVz ZSB0aGUgbGVzcyBjb21wYWN0IGZvcm1hdC4NCg0KSSB0aGluayB3ZSBhZ3JlZSB0aGF0IHNvbWUg cGFyYW1ldGVyKHMpIGZvciByZXBsYXkgcHJvdGVjdGlvbi9JVg0KdW5pcXVlbmVzcyBpcyBuZWVk ZWQgaW4gcmVxdWVzdCBhbmQgcmVzcG9uc2UsIHNvIHdvdWxkIGJlIGluIHRoZSBoZWFkZXIgb2YN CmJvdGggQ09TRV9lbnZlbG9wZWQgYW5kIENPU0VfZW5jcnlwdGVkLg0KDQoNCkfDtnJhbg0KDQoN Cg0KT24gMjAxNS0wOS0xNCAxODowOSwgIkppbSBTY2hhYWQiIDxpZXRmQGF1Z3VzdGNlbGxhcnMu Y29tPiB3cm90ZToNCg0KPg0KPg0KPj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+IEZy b206IEfDtnJhbiBTZWxhbmRlciBbbWFpbHRvOmdvcmFuLnNlbGFuZGVyQGVyaWNzc29uLmNvbV0N Cj4+IFNlbnQ6IE1vbmRheSwgU2VwdGVtYmVyIDE0LCAyMDE1IDI6NDggQU0NCj4+IFRvOiBKaW0g U2NoYWFkIDxpZXRmQGF1Z3VzdGNlbGxhcnMuY29tPjsgYWNlQGlldGYub3JnDQo+PiBTdWJqZWN0 OiBSZTogW0FjZV0gTG9va2luZyBhdCBDT1NFIGJhc2VkIHVuaWNhc3QgYW5kIG11bHRpY2FzdA0K Pj4gDQo+PiANCj4+IA0KPj4gT24gMjAxNS0wOS0xNCAwNjoxNiwgIkppbSBTY2hhYWQiIDxpZXRm QGF1Z3VzdGNlbGxhcnMuY29tPiB3cm90ZToNCj4+IA0KPg0KPg0KPj4gPg0KPj4gPj5Gcm9tIHRo aXMsIGl0IHNlZW1zIHRvIG1lIHRoYXQgZG9lcyBzdXBwb3J0IHRoZSBwb3NpdGlvbiB0aGF0IHNv bWUNCj4+ID5pbmZvcm1hdGlvbiBhYm91dCBjb250ZXh0IG5lZWRzIHRvIGJlIHBhc3NlZCBvbiB0 aGUgaW5pdGlhbCBtZXNzYWdlLg0KPj4gPkRlcGVuZGluZyBvbiBob3cgdGhpcyBpcyBwcmVzZW50 ZWQgSSB3b3VsZCBleHBlY3QgdGhpcyB0byBiZSBkb25lIHdpdGgNCj4+ID50aGUgY3VycmVudCBD T1NFIGVuY3J5cHRlZCBtZXNzYWdlIHN0cnVjdHVyZS4gIEl0IGlzIHBvdGVudGlhbGx5DQo+PiA+ ZGlmZmVyZW50IGluIHRoZSBjYXNlIHdoZXJlIHRoZSBjbGllbnQgaXMgYmVpbmcgdXNlZCB0byBy ZWxheQ0KPj4gPmluZm9ybWF0aW9uIHRvIHRoZSBzZXJ2ZXIgYWJvdXQgdGhlIGF1dGhvcml6YXRp b24gaW5mb3JtYXRpb24uDQo+PiANCj4+IFVzaW5nIHRoZSBjdXJyZW50IENPU0UgZW5jcnlwdGVk IG1lc3NhZ2Ugc3RydWN0dXJlIGlzIG5vdCBhZGRyZXNzaW5nIHRoZQ0KPj4gY29uY2VybnMgYWJv dXQgbWVzc2FnZSBzaXplIGFzIGhhcyBiZWVuIGRpc2N1c3NlZCBwcmV2aW91c2x5LiBGcm9tIHRo ZQ0KPj4gcHJvcG9zZWQgQUNFIGFyY2hpdGVjdHVyZSBJIGNhbiByZWZlcmVuY2UgdHdvIGNhdGVn b3JpZXMgb2YgZm9ybWF0czoNCj4+IA0KPj4gMS4gT25lIGNhdGVnb3J5IHdoaWNoIGFzc3VtZXMg dGhhdCB0aGVyZSBpcyBlc3NlbnRpYWxseSBvbmx5IGEg4oCcYmFzZQ0KPj5rZXnigJ0NCj4+IGVz dGFibGlzaGVkIGJldHdlZW4gc2VuZGVyIGFuZCByZWNlaXZlciwgYW5kIHdoZXJlIHRoZSBtZXNz YWdlIHByb3ZpZGVzDQo+PiBtZWFucyB0byBkZXJpdmUgdGhlIHNlY3VyaXR5IGNvbnRleHQgdG8g dXNlIHdpdGggdGhlIG1lc3NhZ2UuDQo+PiANCj4+IDIuIEFub3RoZXIgY2F0ZWdvcnkgd2hpY2gg aXMgaGlnaGx5IG9wdGltaXplZCBmb3IgdGhlIHNldHRpbmcgdGhhdCB0aGUNCj4+c2VjdXJpdHkN Cj4+IGNvbnRleHQgaXMgYXZhaWxhYmxlIGF0IHRoZSByZWNlaXZlci4NCj4+IA0KPj4gDQo+PiBJ IHRoaW5rIHRoZSBkaXN0aW5jdGlvbiBiZXR3ZWVuIENPU0VfRW52ZWxvcGVkIGFuZCBDT1NFX0Vu Y3J5cHRlZA0KPj5zdHJ1Y3R1cmUNCj4+IGlzIGEgZ29vZCBzdGVwIGluIHRoZSByaWdodCBkaXJl Y3Rpb24sIGJ1dCB0aGUgbGF0dGVyIHNob3VsZCBhbGxvdyBmb3INCj4+dGhlIGRlc2lyZWQNCj4+ IGlkZW50aWZpY2F0aW9uIGFuZCBvcHRpbWl6YXRpb24gZm9yIHRoZSBtb3N0IGNvbW1vbiBzZXR0 aW5ncy4gU29tZXRoaW5nDQo+Pmxpa2U6DQo+PiANCj4+IFsgbWVzc2FnZSB0eXBlLCBwcm90ZWN0 ZWQgaGVhZGVycywgY2lwaGVyIHRleHQsIHRhZyBdDQo+PiANCj4+IA0KPj4gd2hlcmUgcHJvdGVj dGVkIGhlYWRlcnMgY2FuIGlkZW50aWZ5IHRoZSBzZWN1cml0eSBjb250ZXh0IGFuZCB0aGUNCj4+ IG5vbmNlL3NlcXVlbmNlIG51bWJlci4NCj4+IA0KPj4gSW4gZmFjdCwgdG8gZ2V0IHJlcGxheSBw cm90ZWN0aW9uIG9mIHJlcXVlc3QsIGFuZCBvZiByZXNwb25zZSBpZiBubw0KPj5wcmlvciByZXF1 ZXN0DQo+PiBib3VuZCB0byB0aGUgcmVzcG9uc2UsIG9uZSBvZiB0aGUgZmllbGRzIGluIHRoZSBw cm90ZWN0ZWQgaGVhZGVyIG11c3QgYmUNCj4+IG5vbmNlL3NlcXVlbmNlIG51bWJlci90aW1lc3Rh bXAsIHJpZ2h0PyAgVGh1cyB0aGUgZm9ybWF0IHdvdWxkIGFueXdheQ0KPj4gY2Fycnkgc29tZSBp bmZvcm1hdGlvbiBhYm91dCBzZWN1cml0eSBjb250ZXh0LiBJdCBzZWVtcyBvZGQgdG8gbm90DQo+ PmFsbG93IGFuDQo+PiBpZGVudGlmaWVyIG9mIHdoYXQgY29udGV4dCB0aGlzIG5vbmNlL2V0Yy4g cmVmZXJzIHRvLg0KPj4gDQo+PiANCj4+ID4NCj4+ID5UaGUgcmVzcG9uc2UgZG9lcyBub3QgYXBw ZWFyIHRvIG5lZWQgYSBjb250ZXh0IGlkZW50aWZpZXIgYXMgdGhlcmUgaXMNCj4+ID5hbHJlYWR5 IGluZm9ybWF0aW9uIGluIHRoZSBDb0FQIG1lc3NhZ2UgdGhhdCBjYW4gYmUgdXNlZCBmb3INCj4+ ID5kZXRlcm1pbmluZyB0aGUgY29udGV4dC4NCj4+IA0KPj4gPlNwZWNpZmljYWxseSB0aGUgVG9r ZW4gYW5kIE1lc3NhZ2UgSUQgZmllbGRzIGNhbiBiZSB1c2VkIHRvIGFzc29jaWF0ZQ0KPj4gPnJl cXVlc3RzIGFuZCByZXNwb25zZXMuDQo+PiANCj4+IE1lc3NhZ2UgSUQgaXMgbm90IGEgcmVsaWFi bGUgaWRlbnRpZmllciBmb3IgYXNzb2NpYXRpbmcgcmVxdWVzdCB0bw0KPj5yZXNwb25zZS4NCj4N Cj5GaXJzdCwgcGxlYXNlIG5vdGUgdGhhdCBJIHNhaWQgYm90aCBUb2tlbiBhbmQgTWVzc2FnZSBJ RC4gIEFyZSB0aGVyZQ0KPmNhc2VzIHRoYXQgYmV0d2VlbiB0aGVzZSB0d28gZmllbGRzIHRoZSBy ZXF1ZXN0IGFuZCB0aGUgcmVzcG9uc2UgY2Fubm90DQo+YmUgYXNzb2NpYXRlZD8NCg0KSSBkb27i gJl0IHNlZSBob3cgTWVzc2FnZSBJRCBhZGRzIGFueXRoaW5nLiBDb21wYXJlIGZpZ3VyZXMgNSBh bmQgNiBvZg0KUkZDNzI1Mi4gSSBiZWxpZXZlIG1hdGNoaW5nIENvQVAgVG9rZW4gaW4gcmVxdWVz dCBhbmQgcmVzcG9uc2Ugd291bGQgYmUNCnN1ZmZpY2llbnQsIGFsdGhvdWdoIHRoZSBUb2tlbiBp biBpdHNlbGYgY2Fu4oCZdCBiZSBpbnRlZ3JpdHkgcHJvdGVjdGVkIGluDQp0cmFuc2ZlciBzaW5j ZSBpdCBtYXkgYmUgY2hhbmdlZCBieSBhIHByb3h5Lg0KDQo+DQo+PiANCj4+ID4gIFRoaXMgbWVh bnMgdGhhdCBhIGNsaWVudCBjYW4gdXNlIHRoaXMgdG8gZGV0ZXJtaW5lIHdoYXQgY29udGV4dCB3 YXMNCj4+ID51c2VkIGJ5IHRoZSBzZXJ2ZXIgdG8gZW5jcnlwdCB0aGUgbWVzc2FnZSB0aGF0IHdh cyByZXR1cm5lZC4NCj4+ID4oU3BlY2lmaWNhbGx5LCB0aGUgc2FtZSBjb250ZXh0IGFuZCB0aGUg Y2xpZW50IHVzZWQgdG8gZW5jcnlwdCB0aGUNCj4+ID5yZXF1ZXN0LikNCj4+IA0KPj4gVGhlIGNv bnRleHQgbWF5IGJlIGRpZmZlcmVudCBmb3IgcmVxdWVzdCBhbmQgcmVzcG9uc2UsIGFuZCBhbHdh eXMgaXMgaW4NCj4+IE9TQ09BUC4NCj4NCj5QbGVhc2Ugbm90ZSB0aGF0IEkgYW0gdXNpbmcgY29u dGV4dCBpbiB0aGUgc2FtZSB3YXkgdGhhdCBUTFMgdXNlcyB0aGlzDQo+dGVybS4gIFRoaXMgbWVh bnMgdGhhdCB0aGUgaW5mb3JtYXRpb24gaXMgZ29pbmcgdG8gYmUgZGlmZmVyZW50IGZvciB0aGUN Cj50d28gZGlyZWN0aW9ucywgYnV0IHRoZSBjb250ZXh0IGlkZW50aWZpZXMgYSBzaW5nbGUgc2V0 IG9mIGluZm9ybWF0aW9uLg0KPg0KPkkgZG9uJ3Qgc2VlIGFueXRoaW5nIGNhbGxlZCBPU0NPQVAg aW4gZWl0aGVyIGNvcmUgb3IgYWNlLg0KDQpTb3JyeSwgYWJicmV2aWF0aW9uIGZvciB0aGUgQUNF IGRyYWZ0ICJPYmplY3QgU2VjdXJpdHkgZm9yIENvQVAiDQoNCj4NCj4+IA0KPj4gDQo+PiA+IFRo aXMgbWVhbnMgdGhhdCB3ZSBjYW4gc2F5IHRoYXQgdGhlcmUgaXMgYW4gaW1wbGljaXQgY29udGV4 dCBmb3INCj4+ID5lbmNyeXB0ZWQgbWVzc2FnZXMgaW4gdGhpcyBjYXNlIHRoZSBuZXcgZW5jcnlw dGlvbiBzdHJ1Y3R1cmUgdy9vDQo+PiA+cmVjaXBpZW50cyB3b3VsZCBtYWtlIHNlbnNlLiAgVGhp cyBhbmFseXNpcyB3b3VsZCBhcHBseSB0byB0aGUgb2JzZXJ2ZQ0KPj4gPmRpYWxvZyBzdHJ1Y3R1 cmUgYXMgd2VsbCwgdGhlIHRva2VuIGNhbiBiZSB1c2VkIHRvIGFzc29jaWF0ZSBhbGwgaXRlbXMN Cj4+ID5pbiB0aGUgc2FtZSBjb250ZXh0Lg0KPj4gDQo+PiBFdmVuIGlmIHRoZXJlIGFyZSBjYXNl cyB3aGVyZSBsZWF2aW5nIG91dCBjb250ZXh0IGluIHJlc3BvbnNlIGNvdWxkIGJlDQo+PiBwZXJm b3JtZWQsIEkgdGhpbmsgaXQgc2hvdWxkIGJlIGFsbG93ZWQgdG8gc3BlY2lmeSBjb250ZXh0IGFz IGFuIG9wdGlvbi4NCj4+IFRoaXMgd291bGQgYWxzbyByZWxpZXZlIHRoZSBzZXR0aW5ncyB3aGVy ZSBtdWx0aXBsZSBjb250ZXh0cyBuZWVkcyB0bw0KPj5iZSB0cmllZC4NCj4NCj5QbGVhc2UgaWRl bnRpZnkgc2l0dWF0aW9ucyB3aGVyZSBtdWx0aXBsZSBjb250ZXh0cyB3b3VsZCBuZWVkIHRvIGJl DQo+dHJpZWQuICBJIGhhdmUgb25seSBjb21lIHVwIHdpdGggb25lIHNvIGZhciwgYXNzdW1pbmcg dGhhdCBvbmUgaXMgZ29pbmcNCj50byB1c2UgZGlzdGluY3QgYWRkcmVzcy9wb3J0IHBhaXJzIGZv ciB0aGUgbXVsdGktY2FzdCBjYXNlLiAgVGhhdCB3b3VsZA0KPmJlIHRoZSBjYXNlIG9mIHN1YnNj cmliaW5nLg0KDQpBbm90aGVyIGNhc2UgaXMgVG9rZW4gY29sbGlzaW9ucy4NCg0KPg0KPj4gDQo+ PiA+DQo+PiA+Rm9yIGEgc3Vic2NyaXB0aW9uIG1vZGVsIHRvIGEgdGhpcmQgcGFydHksIHRoZXJl IGFyZSBhIGNvdXBsZSBvZg0KPj4gPmRpZmZlcmVudCB3YXlzIHRvIGxvb2sgYXQgaG93IGl0IGNh biBiZSBzZXR1cC4gIFRoZSBiaWcgcXVlc3Rpb24gaXMgaWYNCj4+ID50aGUgY29udGV4dCBpcyBn b2luZyB0byBiZSB1bmlxdWUgdG8gdGhlIG9yaWdpbmF0b3IsIG9yIGl0IGlzIHVuaXF1ZSB0bw0K Pj4gPnRoZSBzdWJzY3JpcHRpb24uDQo+PiA+SW4gZWl0aGVyIGNhc2UsIHRoZSBjbGllbnQgaXMg Z29pbmcgdG8gZW5kIHVwIHVzaW5nIHR3byBkaWZmZXJlbnQNCj4+ID5jb250ZXh0cyBpbiB0aGlz IHNpdHVhdGlvbi4gIFRoZSBmaXJzdCBjYXNlIGlzIGZvciBzZXR0aW5nIHVwIHRoZQ0KPj4gPm9y aWdpbmFsIHN1YnNjcmlwdGlvbi4gIEluIHRoYXQgY2FzZSBhIGNvbnRleHQgYXNzb2NpYXRlZCB3 aXRoIHRoZSBkYXRhDQo+PiA+c3RvcmFnZSBzZXJ2ZXIgaXMgZ29pbmcgdG8gYmUgbmVlZGVkLiAg SG93ZXZlciwgb25jZSBpbmZvcm1hdGlvbiBzdGFydHMNCj4+ID5mbG93aW5nIGJhY2sgdG8gdGhl IGNsaWVudCBmcm9tIHRoZSBkYXRhIHN0b3JhZ2Ugc2VydmljZSwgdGhlIGNvbnRleHQNCj4+ID5h c3NvY2lhdGVkIHdpdGggdGhlIG9yaWdpbmF0aW9uIHNlcnZlciBpcyBnb2luZyB0byBiZSB1c2Vk LiAgSXQgaXMgbm90DQo+PiA+Y2xlYXIgdGhhdCB0aGUgYWN0aW9uIG9mIGRvaW5nIHRoZSBzdWJz Y3JpcHRpb24gd291bGQgbmVlZCB0byBiZQ0KPj4gPmVuY3J5cHRlZCwgIHRoaXMgc2ltcGxpZmll ZCB0aGluZ3MgYXMgb25seSBvbmUgZW5jcnlwdGlvbiBjb250ZXh0IGlzDQo+PiA+bm93IG5lZWRl ZC4gIE90aGVyd2lzZSBlaXRoZXIgdHdvIGNvbnRleHRzIG5lZWQgdG8gYmUgdHJpZWQsIG9yIHRo ZQ0KPj4gPnR5cGUgb2YgbWVzc2FnZSBuZWVkcyB0byBiZSBrbm93biBzbyB0aGF0IHRoZSBjbGll bnQgdW5kZXJzdGFuZCB3aGVyZQ0KPj4gPnRoZSBlbmNyeXB0ZWQgY29udGVudCBvcmlnaW5hdGVz Lg0KPj4gDQo+PiBUaGUgZGF0YSBzdG9yZSBuZWVkIG5vdCBiZSB0cnVzdGVkLiBJbmZvcm1hdGlv biBhYm91dCBiaW5kaW5nIGJldHdlZW4NCj4+IGRpZmZlcmVudCBjb250ZXh0cyBuZWVkcyB0byBi ZSBvYnRhaW5lZCBmcm9tIGEgdHJ1c3RlZCBwYXJ0eSwgc3VjaCBhcw0KPj50aGUNCj4+IGF1dGhv cml6YXRpb24gc2VydmVyLiBJIGJlbGlldmUgdGhlIHByZXNlbmNlIG9mIGEgY29udGV4dCBpZGVu dGlmaWVyDQo+PndvdWxkIHNpbXBsaWZ5DQo+PiB0aGUgcHJvY2Vzc2luZyB3aGVyZSB0aGlzIHR5 cGUgb2YgYmluZGluZyBuZWVkcyB0byBiZSBlc3RhYmxpc2hlZCBhZnRlcg0KPj50aGUNCj4+IG1l c3NhZ2UgaGFzIGJlZW4gcmVjZWl2ZWQsIGNvbXBhcmVkIHRvIHRoZSBjYXNlIG9mIHJlY2Vpdmlu ZyBhbg0KPj5lbmNyeXB0ZWQNCj4+IHN0cnVjdHVyZSB3aXRob3V0IGFueSBoYW5kbGUgd2hhdHNv ZXZlci4NCj4NCj5JbiBteSBhbmFseXNpcyBJIGRpZCBub3QgbWFrZSBhbnkgYXNzdW1wdGlvbnMg dGhhdCB0aGUgZGF0YSBzdG9yZSB3YXMNCj50cnVzdGVkIHRvIGRvIGFueXRoaW5nIG1vcmUgdGhh biBpdHMgYXNzaWduZWQgam9iLiAgSSBkaWQgbm90IG1ha2UgYW55DQo+YXNzdW1wdGlvbnMgdGhh dCBpdCB3b3VsZCBkbyBjcnlwdG9ncmFwaHkgZXhjZXB0IGZvciBtZXNzYWdlcyBzZW50DQo+ZGly ZWN0bHkgdG8gaXQuICANCg0KRmFpciBlbm91Z2guIEkgdHJpZ2dlcmVkIG9uICJ0aGUgY2xpZW50 IGlzIGdvaW5nIHRvIGVuZCB1cCB1c2luZyB0d28NCmRpZmZlcmVudCBjb250ZXh0cyBpbiB0aGlz IHNpdHVhdGlvbuKAnSwgIGJ1dCBhcyB5b3Ugc2F5IHRoZXJlIGFyZSBubw0KZ3VhcmFudGVlcyB0 byB3aGF0IHRoZXNlIGNvbnRleHQgcHJvdmlkZS4NCg0KDQo+SSBkbyBub3Qgc2VlIGFueSBkaWZm ZXJlbmNlIGluIG5lZWRpbmcgdG8gb2J0YWluIHRoZSBrZXlzL2NvbnRleHQNCj5pbmZvcm1hdGlv biBlaXRoZXIgYmVmb3JlIG9yIGFmdGVyIHJlY2VpdmluZyB0aGUgZmlyc3QgbWVzc2FnZS4gIEhv d2V2ZXIsDQo+c2luY2Ugd2UgZG8gbm90IGhhdmUgYSBza2V0Y2hlZCBwcm90b2NvbCBmb3IgZ2V0 dGluZyBrZXlzIHlldCBpdCBpcyBoYXJkDQo+dG8gYmUgc3VyZS4gIEV2ZW4gaWYgeW91IGhhdmUg Y3VycmVudCBrZXlzIHlvdSB3aWxsIHN0aWxsIG5lZWQgdG8gYmUgYWJsZQ0KPnRvIGdldCB1cGRh dGVkIGtleXMgd2hlbiB0aGUgZXBvY2ggcm9sbHMgb3ZlciB0byB0aGUgbmV4dCB2YWx1ZS4gIFRo aXMNCj5tZWFucyB0aGF0IHRoZSB0d28gY2FzZXMgYXJlIGdvaW5nIHRvIGJlIHZlcnkgc2ltaWxh ci4NCg0KSSB3YXMgdGhpbmtpbmcgb2YgYSBjYXNlIHdoZW4gdGhlIHJlY2VpdmluZyBub2RlIGFj dHVhbGx5IGhhcyB0aGUgcmVsZXZhbnQNCmNvbnRleHQsIGJ1dCBzaW5jZSB0aGVyZSBpcyBubyBj b250ZXh0IGlkZW50aWZpZXIgY2Fubm90IGRldGVybWluZSB0aGlzIGlzDQp0aGUgY2FzZSBiZWZv cmUgZG9pbmcgYSBsb29rLXVwIG9mIHdoYXQgY29udGV4dCBpcyB2YWxpZCBmb3IgdGhpcyByZXNv dXJjZS4NCg0KPg0KPj4gDQo+PiA+DQo+PiA+Rm9yIHRoZSBjYXNlIG9mIG11bHRpY2FzdCwgaXQg YXBwZWFycyB0byBtZSB0aGF0IHRoZSBjb250ZXh0IGNhbiBiZQ0KPj4gPmluZmVycmVkIGluIG1v c3QgY2FzZXMuICBJIHdvdWxkIGFzc3VtZSB0aGF0IGEgY29udGV4dCBpcyBnb2luZyB0byBiZQ0K Pj4gPnNpZ25lZCB0byBlYWNoIG11bHRpY2FzdCBhZGRyZXNzLCBwb3J0IHBhaXIuICBJIHdvdWxk IGFsc28gYXNzdW1lIHRoYXQNCj4+ID50aGlzIHdvdWxkIGJlIGEgdW5pcXVlIGFzc2lnbm1lbnQg aW4gdGhhdCBtdWx0aXBsZSBjb250ZXh0cyB3b3VsZCBub3QNCj4+ID5iZSBhc3NpZ25lZC4gIFRo aXMgZG9lcyBhbGxvdyBmb3IgYW55IG5vZGUgd2hpY2ggaGFzIHRoZSBjb250ZXh0IHRvDQo+PiA+ c2VuZCBvdXQgYSBtdWx0aWNhc3QgbWVzc2FnZSB3aXRob3V0IGEgcHJvYmxlbS4gIFRoZSBtb3Jl IGludGVyZXN0aW5nDQo+PiA+cXVlc3Rpb24gaXMgd2hhdCB0byBkbyB3aXRoIHRoZSB1bmljYXN0 IHJlc3BvbnNlcyB0byBhIG11bHRpY2FzdA0KPj4gPm1lc3NhZ2UuICBTaG91bGQgdGhleSBiZSBl bmNyeXB0ZWQgd2l0aCB0aGUgbXVsdGljYXN0IGdyb3VwIGNvbnRleHQsIGluDQo+PiA+d2hpY2gg Y2FzZSB0aGUgbWVzc2FnZSBpZC90b2tlbiBvbiB0aGUgbWVzc2FnZSBpcyBzdWZmaWNpZW50IHRv DQo+PiA+aWRlbnRpZnkgdGhlIGNvbnRleHQuICBPciBzaG91bGQgdGhleSBiZSBlbmNyeXB0ZWQg d2l0aCBhIHVuaWNhc3Qga2V5DQo+PiA+cGFpciBiZXR3ZWVuIHRoZSByZXBsaWVyIGFuZCB0aGUg b3JpZ2luYWwgbWVzc2FnZSBzZW5kZXI/DQo+PiA+VGhpcyBpbXBsaWVzIHRoYXQgc3VjaCBhIGtl eSBjb250ZXh0IG5lZWRzIHRvIGJlIHNldHVwIGZvciBlYWNoIHN1Y2gNCj4+ID5saW5rIHdoaWNo IG1heSBvciBtYXkgbm90IGJlIHRoZSBjYXNlLiAgSW4gdGhpcyBldmVudCBpdCBtaWdodCBiZQ0K Pj4gPm5lY2Vzc2FyeSB0byBpZGVudGlmeSB0aGUgY29udGV4dCB0aGF0IHdhcyB1c2VkIHRvIGVu Y3J5cHQgdGhlIHVuaWNhc3QNCj4+ID5tZXNzYWdlLiAgSSBoYXZlIG5vdCBtYW5hZ2VkIHRvIHRo aW5rIHRoaXMgdGhyb3VnaCBmYXIgZW5vdWdoLg0KPj4gPg0KPj4gPkluIGFueSBldmVudCwgdGhl cmUgYXBwZWFyIHRvIGJlIGVub3VnaCBjYXNlcyB3aGVyZSB0aGUgZW5jcnlwdGlvbg0KPj4gPmNv bnRleHQgY2FuIGJlIGluZmVycmVkIGZyb20gdGhlIG1lc3NhZ2UgdG8gbWFrZSBpdCByZWFzb25h YmxlIHRvIGhhdmUNCj4+ID5hIHZlcnNpb24gb2YgQ09TRSBtZXNzYWdlcyB3aGljaCBkbyBub3Qg aGF2ZSBhbnkgcmVjaXBpZW50IGluZm9ybWF0aW9uDQo+PiA+YXR0YWNoZWQgdG8gdGhlbS4NCj4+ ID5JbiB0aGUgY2FzZSBvZiBwdXJlIHVuaWNhc3QsIGl0IHdvdWxkIGJlIHVzZWQgZm9yIGF0IGxl YXN0IDUwJSBvZiB0aGUNCj4+ID5tZXNzYWdlcyAoYSBoaWdoZXIgcGVyY2VudGFnZSBmb3Igb2Jz ZXJ2aW5nIHN0YXRlKS4gIEFuZCBmb3IgbXVsdGljYXN0DQo+PiA+aXQgbWlnaHQgYmUgdXNlZCBl aXRoZXIgZm9yIDUwJSBvciBhbGwgb2YgdGhlIG1lc3NhZ2VzIGRlcGVuZGluZyBvbiBob3cNCj4+ ID5yZXNwb25zZXMgYXJlIGhhbmRsZWQuDQo+PiA+DQo+PiA+SSBhbSBpbnRlcmVzdGVkIGluIHBl b3BsZSBsb29raW5nIGF0IG15IGFuYWx5c2lzIGFuZCB0ZWxsIG1lIGlmIEkgYW0NCj4+ID5yaWdo dCwgd3Jvbmcgb3IgdW5jbGVhci4NCj4+IA0KPj4gDQo+PiBUaGVyZSBhcmUgY2FzZXMgd2hlcmUg b3B0aW1pemVkIG1lc3NhZ2UgYW5kIGNvbnRleHQgaWRlbnRpZmljYXRpb24gYXJlDQo+PiBuZWVk ZWQsIG9yIHdoZXJlIGEgY29udGV4dCBpZGVudGlmaWVyIGNvdWxkIHNpbXBsaWZ5IHRoZSBwcm9j ZXNzaW5nLiBJbg0KPj5ib3RoDQo+PiBjYXNlcyBhbGxvd2luZyBvcHRpb25hbCBoZWFkZXIgaW4g dGhlIENPU0VfZW5jcnlwdGVkIGZvcm1hdCB3b3VsZCBzb2x2ZQ0KPj50aGUNCj4+IHByb2JsZW0u IEZvciByZXBsYXkgcHJvdGVjdGlvbiwgc29tZSBjb250ZXh0IGluZm9ybWF0aW9uIHN1Y2ggYXMN Cj4+c2VxdWVuY2UNCj4+IG51bWJlci9ub25jZSBuZWVkcyBhbnl3YXkgdG8gYmUgdHJhbnNmZXJy ZWQsIHNvIEkgd291bGQgc2F5IHRoYXQgdGhlDQo+PmNvbnRleHQNCj4+IGNhbm5vdCBiZSBjb21w bGV0ZWx5IGltcGxpY2l0Lg0KPg0KPlllcywgc29tZSBpbnB1dCBpbnRvIGFuIElWIG5lZWRzIHRv IGJlIHRyYW5zZmVycmVkLCBidXQgSSB3b3VsZCBub3QNCj5jb25zaWRlciB0aGF0IHRvIGJlIHBh cnQgb2YgdGhlIHNhdmVkIGNvbnRleHQuICAgVGhpcyBpcyBub3QgbmVlZGVkIGZvcg0KPnJlcGxh eSBwcm90ZWN0aW9uIGFzIG11Y2ggYXMgaXQgaXMgbmVlZGVkIGZvciBtYWtpbmcgc3VyZSB0aGF0 IElWcyBhcmUNCj5ub3QgcmUtdXNlZC4gIFRoaXMgY291bGQgcG90ZW50aWFsbHkgYmUgZGlmZmVy ZW50IGZyb20gdGhlIHNlcXVlbmNlDQo+bnVtYmVyIHVzZWQgZm9yIHJlcGxheSBwcm90ZWN0aW9u IGJ1dCBnZW5lcmFsbHkgd291bGQgbm90IGJlLg0KDQpBZ3JlZS4NCg0KPg0KPkkgd291bGQgZXhw ZWN0IHRoYXQgeW91IHdvdWxkIG5ldmVyIHdhbnQgdG8gc2VuZCBpbmZvcm1hdGlvbiB5b3UgZG8g bm90DQo+aGF2ZSB0byBzaW5jZSBpdCBvbmx5IGFkZHMgc2l6ZS4gIEJ1dCBzdGlsbCB0cnlpbmcg dG8gZmlndXJlIG91dCB3aGVyZSBpdA0KPmlzIGFuZCBpcyBub3QgbmVlZGVkIHRvIGhhdmUgYSBj b250ZXh0IGlkZW50aWZpZXIgdG8gYmVnaW4gd2l0aC4gIFRoZW4gd2UNCj5jYW4gZmlndXJlIG91 dCB3aGVyZSBhbmQgaWYgaXQgbWFrZXMgc2Vuc2UgdG8gaW5jbHVkZSBpdC4gIEJ1dCBhdCB0aGF0 DQo+cG9pbnQgeW91IGFyZSBhbHJlYWR5IHRhbGtpbmcgYWJvdXQgdGFraW5nIHNpemUgaGl0cy4N Cg0KVG9rZW4gY291bGQgZG91YmxlIHBsYXkgYXMgaW5kaWNhdGlvbiBvZiBjb250ZXh0IGlkZW50 aWZpZXIsIGJ1dCBub3QNCmFsd2F5cywgbm90IGZvciBmcmVlLCBhbmQgYWxzbyBtYXkgbGVhZCB0 byBzb21lIElNSE8gY29uZnVzaW5nIGNvbnN0cmFpbnRzDQpzdWNoIGFzIGRpZmZlcmVudCBtZXNz YWdlIGZvcm1hdHMgZm9yIHJlcXVlc3QgYW5kIHJlc3BvbnNlLg0KDQpBcyBJIHVuZGVyc3Rvb2Qg b25lIHJlYXNvbiB3aHkgQ09TRV9lbmNyeXB0ZWQgd2FzIGludHJvZHVjZWQgd2FzIHRvIG1lZXQg YQ0KcmVxdWVzdCBmb3IgYSBtb3JlIGNvbXBhY3QgZm9ybWF0IGluIHNldHRpbmdzIHdoZXJlIGNv bnRleHQgaXMgYWxyZWFkeQ0KZXN0YWJsaXNoZWQuIE5vdCBzZW5kaW5nIGNvbnRleHQgaWRlbnRp ZmllciBtYXkgYmUgYW4gb3B0aW1pemF0aW9uIGluIHNvbWUNCnNldHRpbmdzLCBidXQgdGhhdCBm b3JtYXQgd291bGQgYmUgb2YgbXVjaCBsZXNzIHVzZSBpZiBhIGNvbnRleHQNCmlkZW50aWZpZXIg Y2Fubm90IGJlIGluY2x1ZGVkLg0KDQoNCkfDtnJhbg0KDQo= From nobody Tue Sep 15 12:12: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 DA7CB1AC3F4 for ; Tue, 15 Sep 2015 12:12:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.15 X-Spam-Level: * X-Spam-Status: No, score=1.15 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 MkjlSA1T8W5o for ; Tue, 15 Sep 2015 12:12: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 1669F1AC3D4 for ; Tue, 15 Sep 2015 12:12: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 [134.102.201.11]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id t8FJCdm0014281; Tue, 15 Sep 2015 21:12:39 +0200 (CEST) Received: from [192.168.1.109] (p57A63B54.dip0.t-ipconnect.de [87.166.59.84]) (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 3nFvMW1hrwz1jFF; Tue, 15 Sep 2015 21:12:39 +0200 (CEST) From: Stefanie Gerdes To: Renzo Navas , ace References: X-Enigmail-Draft-Status: N1110 Message-ID: <55F86DA1.4060809@tzi.de> Date: Tue, 15 Sep 2015 21:12:33 +0200 User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Ace] DCAF Review (draft-gerdes-ace-dcaf-authorize) 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, 15 Sep 2015 19:12:54 -0000 Hi Renzo, Thank you very much for your thorough feedback! On 09/14/2015 03:01 PM, Renzo Navas wrote: > Good Afternoon ACE ML, > > I send here a review of DCAF > https://tools.ietf.org/html/draft-gerdes-ace-dcaf-authorize-02 > version 02, though most of comments applies for -recent- 03. > > I want to publicly thank to the authors of DCAF (Steffi, Olaf, Carsten), > I found it a very useful document (very detailed), I found it one of > the most 'mature' ACE architectures, and with a lot of pointers to > take it to reality from an implementation point of view. In fact at my > everyday-work we want some AA Architecture for IoT, and are trying to > push something like DCAF, though I'm interested on trying to offer > COSE security instead of DTLS. We started integrating COSE into DCAF. Section 3.3 of the 03 version describes how COSE content can be transported in DCAF. > > This is my first review ever, so sorry in advance for my inexperience. > I have a software development background, so I believe most of my > comments come from an implementation point of view. In the last months > I've been trying to get more on the AA and security world. > > I've been following the ACE working group for some months now, and I > really appreciate the effort of all of you. > I hope to start contributing more, and these are my two cents for now. Thank you! > > Have a good start of the week > > Renzo > > > -------------------------------------- > > DCAF Review > >> 1.2.1 Actors > Harmonize definitions with draft-ietf-ace-actors-00: > S -- RS ; SAM -- AS ; CAM -- CAS ; AM -- ?? (how to map AM concept > into actors draft, needs discussion?) ; > COP -- RqP; ROP -- RO The Authorization Manager must perform very distinct tasks. They present user interfaces and displays to the user, have enough memory, storage space and processing power to store complex authorization policies and keying material and they are able to use unmodified security protocols such as OAuth and Kerberos. They simplify the principals' authorization decisions and perform the authentication of the opposite party. Constrained nodes depend on their Authorization Managers and will not be able to communicate securely without them. We are worried that people will not understand the special role of the Authorization Managers and will confuse them with OAuth authorization servers. Especially when writing up examples for interactions between constrained level protocols such as DCAF and less constrained level protocols such as OAuth (see https://tools.ietf.org/pdf/draft-gerdes-ace-dcaf-examples-00.pdf), we noticed that it is very confusing if we are not able to distinguish Authorization Server and Authorization Manager. The OAuth model does include a Client Authorization Manager. The current approach is to call it Client Authorization Server (CAS). The Authorization Server on the server side is called AS, which is kind of confusing. We cannot even write something general about authorization servers since it is unclear whether this includes client authorization servers or not. (Our experience from teaching is also that the OAuth terminology is generally confusing to new learners, so a more regular terminology may help adoption outside the circles of hardcore OAuth experts.) > >> 1.2.2. Other Terms > > "Verifier" (can be clarifying to mention on parentheses an example of > a verifier?, for instance adding : Verifier e.g: information > representing a 128-bit PSK) Ok. > > > Should not be useful to define CAI , SAI? > They are defined on Section 5. but before the formal definition they > are used a lot. True. We will add definitions for them. > > >> 3. Protocol >> 2 . transfer of access request and respective ticket grants > Change 鈥渢icket grants鈥 for "ticket transfer" (C and CAM transfer > what's been defined as Ticket Transfer)? > >> 3 . transfer of access request and respective ticket grants > Change 鈥渁ccess request鈥 for "ticket requests" (SAM and CAM transfer > what's been defined as Ticket Requests)? Good catch, thanks. > >> 3.2 鈥渋nsecure channel鈥 ('insecure' or 'unsecured' -or 'non-secured'-? > I could not find any formal definition on RFCs. rfc4949 mentions > 鈥渦nsecured networks鈥, > I found this discussion > http://english.stackexchange.com/questions/19653/insecure-or-unsecure-when-dealing-with-security We can change "insecure" to "unprotected" in 3.2. and 4.2. > I point this to raise the discussion, does RFC4949 suffice or we need > more -rfc- security glossary? > > > >> 3.5 Ticket Request, > > Should not 4.03 be sent only if ALL of the requested actions are forbidden? > Stated otherwise, if at least one action is not forbidden then CAM > attempts a ticket Request. (if this is the case, should this be stated > clearer on the text?) True. We should clarify that. > > The ticket request will be for all actions C specified (even the ones > not allowed) or CAM will change the SAI according to COP鈥檚 policies? CAM informs C about COP's policies using the CAI in the Ticket Transfer message. CAM needs to specify the CAI anyway in the Ticket Transfer message if COP specified authorization policies for the client. > About the Label for client: > > 鈥5. A label that describes the Client is added to the payload鈥 see > comment on 10.1, what role plays this label (for my understanding does > not play any role), what is the format of the label (on the examples > is missing)? > OK, I think this point is here from previous versions of document, > should be removed? Yes, this is a relic from a previous version and somehow slipped through. We will remove it. > > >> 3.6 Ticket Grant Message > "When access is granted, the data structure contains the Ticket Face, the > Client Information, which at this point only consists of the Verifier > and the Session Key Generation Method." > > Access Ticket, does contain Face and Client Info. If I understood > correctly here is stated that the Client Information consist of > Verifier and the Session Key Gen? Why the CI has the Session key gen > method (should not be this part of the Face that is destined to the > RServer)? On the example the Gen method is part of the Face, so maybe > can this sentence be rephrased to let clear that the session key gen > is part of the ticket face? Yes, there is at least a comma missing in the sentence. The ticket consists of the face and the client information. The client information consists of the verifier. The face contains among other stuff the session key generation method. We will clarify that. > > >> 3.7 Ticket Transfer Message > 鈥淭he Ticket Transfer message is (...) and includes any access > information from SAM contained on the Ticket Grant message鈥, > What does this 鈥渁ny鈥 mean? (explicitly the documents later says that > CAM MUST NOT include any CAI information provided by SAM), so this > 鈥渁ny鈥 means 鈥渟ome鈥 (Face and Verifier? but not CAI)? I think 鈥渁ny鈥 is > a confusing term. The Ticket Transfer Message contains the SAI that SAM sent in the Ticket Grant message. We will clarify that. > > Can we have an example of CAI info from from SAM ? (the CAI will be > included on the Face or is stand alone? OK, as the Face cannot be > changed, because the same face must be possessed by C and S for a > successful DTLS session handshake, so I assume is stand alone) DCAF tickets comprise of two parts, the face and the client information. The client information and the face. CAI is part of the client information. We will try to make this more clear. > > why would a SAM add a CAI? (and not restrict the Token on SAI directly?) > > maybe to force CAM to enforce that CAI? > if a CAI coming from SAM its with that purpose, then when > specification when says 鈥淐AM MUST NOT include any CAI info from SAM鈥 > means that the CAM does not care -or on the contrary, it takes it in > account but adds its own policies also respecting COP鈥檚 enforced CAI-? SAM is not supposed to add a CAI. A malicious (or misconfigured) SAM might add CAI and thereby mislead C to believe that it reflects the COP's authorization policies. > >> 3.9 Authorized Resource Request Message > 鈥渕ust check T鈥 -meaning- TS? ( T is not defined later) Good catch. Yes, TS. > > > How does RS distinguish two different clients if they have the same > Face (face must be unique then)? what identifies a client? must be on > the face? > > OK, after reading the whole document the TS on the Face is the thing > that can uniquely identifies a ticket (and will be sent by CAM to one > and only one C, so one ticket with a unique TS can be possessed by > only one client).. > So I think it needs to be stressed the importance of the TS field, It > must be unique per ticket (must be a precise clock on SAM), if the TS > of two Tickets repeats/is the same we are in problems. > > > (comment after reading 4.1) If S generates the timestamp.. due to its > constrained nature does not this pose a problem because we can have TS > collisions? Can we really guarantee that S will not generate two times > the same TS? (e.g: if it resets..) Yes, true. We will need to point out more clearly what the requirements for the TS in the Face are, including a discussion whether it can/should be a nonce or a timestamp. > >> 4. Ticket > The CI plus the Face goes to the Client will not be more accurate? The > client without the Face cannot start the DTLS session (so in a way the > Face is also destined to the Client) Sure, but we wanted to point out that the Client keeps the CI part of the ticket while the Face is destined for the Server. We will rephrase the paragraph to make this more clear. > > > Only Face is needed No additional information is needed to ID the > client? (so the unique way the client id can be seen as the TS?)). OK > -seems to be that way, the TS is the id of the ticket- Yes. Identifying the Client is not that important for the Server. It only needs to make sure that the Client is authorized. However, it might be necessary to identify the ticket to be able to revoke it. > > >> 5. Payload Format and Encoding > TS: time stamp; 鈥淎n optional timestamp that indicates 鈥 when the > access ticket request鈥 , > > For the access request may be optional, but for the ticket > grant/ticket transfer is needed as a part of the Face (on Face > description 4.1 is marked as a MUST) > > > should not this distinction be clear(er)? > > The TS for the Ticket Face is not optional is a MUST, without it a > client cannot be uniquely associated with a Ticket Face (it is the > only unique id, field, possible to distinguish one Ticket Face of > another), this is marked down when the field 鈥淔鈥 is explained. however > it was confusing to me to be defined as optional. Maybe can be > clarified that is optional when is not a part of Face. We will look into this more closely when we define the requirements for TS (see above). > > >> 5.1 Examples > * text It says that the Face contains a 鈥渃lient descriptor鈥 is > missing? . Ok now I read version 00 of the document and client > descriptor is there. So on the current version no more Client > Descriptor is needed/present, this 鈥渃lient descriptor鈥 has to be > erased Yes, will be deleted. > * Encrypted face uses the shared S/SAM key and the TS as nonce. The TS > of the Face was put by SAM not by S -if Im not mistaken the SAM put > the TS when it generates the ticket) ? (why says 鈥淪鈥檚 timestamp鈥?), > also for S to decrypt the Encrypted face, it will need the nonce (TS), > but if he only receives E K V he will not have the appropriate nonce > to decrypt E. Am I mistaken or the nonce should be passed to S also? > > After reading carefully the document also allows to S to generate the > Timestamp (I mentioned that this could lead to problems). But how > would S know what timestamp to use as nonce (he cannot associate an > Encrypted face with an unauthorised old request? . The problem of what > nonce to use is still true if SAM is the generator of TS. solution: > send the nonce aside the encrypted face (E ,K, nonce, V)? > > OK. This nonce problem seems to be adressed on version 03 of the document > > > >> 8. Trust Relationships > > "1. SAM has means to authenticate CAM (e.g. it has a certificate of > CAM or a PKI in which CAM is included) and vice versa" > > worth mentioning the 鈥渕utual authentication鈥 concept? Ok. > > "2. As far as SAM needs to rely on the different clients of CAM to > receive different permissions, it can be sure that CAM correctly > identifies these clients towards SAM and does not leak tickets" > > what does 鈥渢owards SAM鈥 means/adds? is it needed to add that (would > not work the phrase/protocol the same without that)? > (CAM does not send any client information to SAM -nothing to id a > particular client-) For some use cases, CAM might need to provide information concerning the client to SAM, e.g., if SAM only wants to authorize certain types of devices. In this case, CAM must provide correct information about the client to SAM. We will make this more clear. > >> FIGURE > > Figure missing number? I can't find this in the draft, maybe it is fixed in the 03-version? > > > >> 10 Examples >> 10.1CAM-->SAM Ticket Request, > > on section 3.5 is specified that Token Request messages contains 鈥5. A > label that describes the client is added to the payload鈥 > On the example is not present. What purpose serves that label? (also > on dcaf field identifiers seems not the be a 鈥渓abel鈥), should this > point 5 on section 3.5 be erased or marked as optional? > Ok now that I read older version of drafts seems that label that > describes client is no longer used, so on section 3.5 should be > erased? Yes, will be deleted. > > Should be useful to see the message exchange between SAM and S? DCAF only considers the exchange of information between SAM and S that is included in the Ticket Face. It might be necessary for SAM and S to exchange additional information for time synchronization or other administrational stuff, but that is not in scope of the document. Do you miss something in particular? Thank you very much again for your thorough feedback! It is very helpful for us! Viele Gr眉脽e Steffi From nobody Tue Sep 15 13:09: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 5468E1ACE39 for ; Tue, 15 Sep 2015 13:09:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.6 X-Spam-Level: X-Spam-Status: No, score=-1.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 x14K-s54JYas for ; Tue, 15 Sep 2015 13:09:17 -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 AC8B91ACE40 for ; Tue, 15 Sep 2015 13:09:17 -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 5482838EA7; Tue, 15 Sep 2015 13:09:16 -0700 (PDT) From: "Jim Schaad" To: =?UTF-8?Q?'G=C3=B6ran_Selander'?= , References: <007901d0eea4$25989bf0$70c9d3d0$@augustcellars.com> <002b01d0ef07$aced5970$06c80c50$@augustcellars.com> In-Reply-To: Date: Tue, 15 Sep 2015 13:06:50 -0700 Message-ID: <01b601d0eff2$120843c0$3618cb40$@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: AQGGfwiYLGVnvC1rumdUoUJ+HdJvIQI0bA87AfbgWScBfoJsq56lYoOQ Archived-At: Subject: Re: [Ace] Looking at COSE based unicast and multicast 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, 15 Sep 2015 20:09:20 -0000 > -----Original Message----- > From: G=C3=B6ran Selander [mailto:goran.selander@ericsson.com] > Sent: Monday, September 14, 2015 11:20 PM > To: Jim Schaad ; ace@ietf.org > Subject: Re: [Ace] Looking at COSE based unicast and multicast >=20 > Comments inline. >=20 > My summary: >=20 > The request in general needs a context identifier. Your proposal is to = use the > COSE_enveloped format, my proposal is to allow an optional context = identifier > in the COSE_encrypted format, which is more compact. >=20 > If you associate the CoAP Token of a request to the context then you = can use > that as an index for context identifier in the response and hence use > COSE_encrypted. But now you have two parameters that perform a similar > task: Token and Context Identifier, and which both has to be = transferred in a > request. The Token field is variable length 0-8 bytes. Since we cannot = attribute > any end-to-end security properties of Token, the object security = scheme is made > independent of how the Token is set, analogously to the case in DTLS. = By instead > relying on Token to avoid collisions we may need a larger Token. There is no need to explicitly protect the context identifier. It is = implicitly protected as the message will fail to validate if you use the = wrong context. This means that it is protected even if it is not part = of the message properties. Having the context identified by the token = is totally legitimate and totally secure. In the case of unicast DTLS, = there is no explicit context identifier anywhere. It is totally based = on the four-tuple of addresses and ports. This has zero cryptographic = security applied to these values, the security is totally implicit.=20 >=20 > I=E2=80=99m not convinced with the difference between how the message = is formatted > depending on whether it is a request or response. A given node may = send the > same resource representation as PUT request or GET response and thus = would > use different COSE message formats. Given that the COSE message representation is going to have to be built = uniquely for each message sent, I don't know that this is a problem. = How the COSE is created is based on the http-like operation that is = being used. This will be well understood when it occurs and when it = does not occur. =20 >=20 >=20 > It is also a matter of how the received COSE object will be = subsequently used. > For example, in Information-Centric Networking, if I=E2=80=99m not = mistaken, one of the > requirements is that each protected object has a globally unique name. = By > shifting focus from a context identifier within the COSE object to = Token which is > ephemeral data outside the COSE object, ICN applications would always = have to > use the less compact format. If you are correct, and the unique name is always known to both parties, = then it is quite possible that you have a situation where the context = information can always be implicit and would not need to be carried at = all. >=20 > I think we agree that some parameter(s) for replay protection/IV = uniqueness is > needed in request and response, so would be in the header of both > COSE_enveloped and COSE_encrypted. I have already said this is true, and it is content related so it fits = the current COSE model. However, there is an interesting question if = you want this in the COSE world or in the CoAP world and just protect it = in COSE. Having two different replay protection systems in place may be = overkill. >=20 >=20 > G=C3=B6ran >=20 >=20 >=20 > On 2015-09-14 18:09, "Jim Schaad" wrote: >=20 > > > > > >> -----Original Message----- > >> From: G=C3=B6ran Selander [mailto:goran.selander@ericsson.com] > >> Sent: Monday, September 14, 2015 2:48 AM > >> To: Jim Schaad ; ace@ietf.org > >> Subject: Re: [Ace] Looking at COSE based unicast and multicast > >> > >> > >> > >> On 2015-09-14 06:16, "Jim Schaad" wrote: > >> > > > > > >> > > >> >>From this, it seems to me that does support the position that = some > >> >information about context needs to be passed on the initial = message. > >> >Depending on how this is presented I would expect this to be done > >> >with the current COSE encrypted message structure. It is > >> >potentially different in the case where the client is being used = to > >> >relay information to the server about the authorization = information. > >> > >> Using the current COSE encrypted message structure is not = addressing > >> the concerns about message size as has been discussed previously. > >> From the proposed ACE architecture I can reference two categories = of > formats: > >> > >> 1. One category which assumes that there is essentially only a = =E2=80=9Cbase > >>key=E2=80=9D > >> established between sender and receiver, and where the message > >>provides means to derive the security context to use with the = message. > >> > >> 2. Another category which is highly optimized for the setting that > >>the security context is available at the receiver. > >> > >> > >> I think the distinction between COSE_Enveloped and COSE_Encrypted > >>structure is a good step in the right direction, but the latter > >>should allow for the desired identification and optimization for = the > >>most common settings. Something > >>like: > >> > >> [ message type, protected headers, cipher text, tag ] > >> > >> > >> where protected headers can identify the security context and the > >> nonce/sequence number. > >> > >> In fact, to get replay protection of request, and of response if no > >>prior request bound to the response, one of the fields in the > >>protected header must be nonce/sequence number/timestamp, right? > >>Thus the format would anyway carry some information about security > >>context. It seems odd to not allow an identifier of what context = this > >>nonce/etc. refers to. > >> > >> > >> > > >> >The response does not appear to need a context identifier as there > >> >is already information in the CoAP message that can be used for > >> >determining the context. > >> > >> >Specifically the Token and Message ID fields can be used to > >> >associate requests and responses. > >> > >> Message ID is not a reliable identifier for associating request to > >>response. > > > >First, please note that I said both Token and Message ID. Are there > >cases that between these two fields the request and the response = cannot > >be associated? >=20 > I don=E2=80=99t see how Message ID adds anything. Compare figures 5 = and 6 of RFC7252. > I believe matching CoAP Token in request and response would be = sufficient, > although the Token in itself can=E2=80=99t be integrity protected in = transfer since it may > be changed by a proxy. >=20 > > > >> > >> > This means that a client can use this to determine what context > >> >was used by the server to encrypt the message that was returned. > >> >(Specifically, the same context and the client used to encrypt the > >> >request.) > >> > >> The context may be different for request and response, and always = is > >> in OSCOAP. > > > >Please note that I am using context in the same way that TLS uses = this > >term. This means that the information is going to be different for = the > >two directions, but the context identifies a single set of = information. > > > >I don't see anything called OSCOAP in either core or ace. >=20 > Sorry, abbreviation for the ACE draft "Object Security for CoAP" >=20 > > > >> > >> > >> > This means that we can say that there is an implicit context for > >> >encrypted messages in this case the new encryption structure w/o > >> >recipients would make sense. This analysis would apply to the > >> >observe dialog structure as well, the token can be used to = associate > >> >all items in the same context. > >> > >> Even if there are cases where leaving out context in response could > >>be performed, I think it should be allowed to specify context as an = option. > >> This would also relieve the settings where multiple contexts needs = to > >>be tried. > > > >Please identify situations where multiple contexts would need to be > >tried. I have only come up with one so far, assuming that one is = going > >to use distinct address/port pairs for the multi-cast case. That = would > >be the case of subscribing. >=20 > Another case is Token collisions. >=20 > > > >> > >> > > >> >For a subscription model to a third party, there are a couple of > >> >different ways to look at how it can be setup. The big question = is > >> >if the context is going to be unique to the originator, or it is > >> >unique to the subscription. > >> >In either case, the client is going to end up using two different > >> >contexts in this situation. The first case is for setting up the > >> >original subscription. In that case a context associated with the > >> >data storage server is going to be needed. However, once > >> >information starts flowing back to the client from the data = storage > >> >service, the context associated with the origination server is = going > >> >to be used. It is not clear that the action of doing the > >> >subscription would need to be encrypted, this simplified things = as > >> >only one encryption context is now needed. Otherwise either two > >> >contexts need to be tried, or the type of message needs to be = known > >> >so that the client understand where the encrypted content = originates. > >> > >> The data store need not be trusted. Information about binding = between > >>different contexts needs to be obtained from a trusted party, such = as > >>the authorization server. I believe the presence of a context > >>identifier would simplify the processing where this type of binding > >>needs to be established after the message has been received, = compared > >>to the case of receiving an encrypted structure without any handle > >>whatsoever. > > > >In my analysis I did not make any assumptions that the data store was > >trusted to do anything more than its assigned job. I did not make = any > >assumptions that it would do cryptography except for messages sent > >directly to it. >=20 > Fair enough. I triggered on "the client is going to end up using two = different > contexts in this situation=E2=80=9D, but as you say there are no = guarantees to what these > context provide. >=20 >=20 > >I do not see any difference in needing to obtain the keys/context > >information either before or after receiving the first message. > >However, since we do not have a sketched protocol for getting keys = yet > >it is hard to be sure. Even if you have current keys you will still > >need to be able to get updated keys when the epoch rolls over to the > >next value. This means that the two cases are going to be very = similar. >=20 > I was thinking of a case when the receiving node actually has the = relevant > context, but since there is no context identifier cannot determine = this is the case > before doing a look-up of what context is valid for this resource. >=20 > > > >> > >> > > >> >For the case of multicast, it appears to me that the context can = be > >> >inferred in most cases. I would assume that a context is going to > >> >be signed to each multicast address, port pair. I would also = assume > >> >that this would be a unique assignment in that multiple contexts > >> >would not be assigned. This does allow for any node which has the > >> >context to send out a multicast message without a problem. The = more > >> >interesting question is what to do with the unicast responses to a > >> >multicast message. Should they be encrypted with the multicast > >> >group context, in which case the message id/token on the message = is > >> >sufficient to identify the context. Or should they be encrypted > >> >with a unicast key pair between the replier and the original = message sender? > >> >This implies that such a key context needs to be setup for each = such > >> >link which may or may not be the case. In this event it might be > >> >necessary to identify the context that was used to encrypt the > >> >unicast message. I have not managed to think this through far = enough. > >> > > >> >In any event, there appear to be enough cases where the encryption > >> >context can be inferred from the message to make it reasonable to > >> >have a version of COSE messages which do not have any recipient > >> >information attached to them. > >> >In the case of pure unicast, it would be used for at least 50% of > >> >the messages (a higher percentage for observing state). And for > >> >multicast it might be used either for 50% or all of the messages > >> >depending on how responses are handled. > >> > > >> >I am interested in people looking at my analysis and tell me if I = am > >> >right, wrong or unclear. > >> > >> > >> There are cases where optimized message and context identification > >>are needed, or where a context identifier could simplify the > >>processing. In both cases allowing optional header in the > >>COSE_encrypted format would solve the problem. For replay = protection, > >>some context information such as sequence number/nonce needs anyway > >>to be transferred, so I would say that the context cannot be > >>completely implicit. > > > >Yes, some input into an IV needs to be transferred, but I would not > >consider that to be part of the saved context. This is not needed = for > >replay protection as much as it is needed for making sure that IVs = are > >not re-used. This could potentially be different from the sequence > >number used for replay protection but generally would not be. >=20 > Agree. >=20 > > > >I would expect that you would never want to send information you do = not > >have to since it only adds size. But still trying to figure out = where > >it is and is not needed to have a context identifier to begin with. > >Then we can figure out where and if it makes sense to include it. = But > >at that point you are already talking about taking size hits. >=20 > Token could double play as indication of context identifier, but not = always, not > for free, and also may lead to some IMHO confusing constraints such as > different message formats for request and response. >=20 > As I understood one reason why COSE_encrypted was introduced was to = meet a > request for a more compact format in settings where context is already > established. Not sending context identifier may be an optimization in = some > settings, but that format would be of much less use if a context = identifier cannot > be included. >=20 >=20 > G=C3=B6ran From nobody Tue Sep 15 13:45:41 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 F376A1AD0B4 for ; Tue, 15 Sep 2015 13:45:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.801 X-Spam-Level: X-Spam-Status: No, score=0.801 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, 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 JOQsbtPhXT6j for ; Tue, 15 Sep 2015 13:45:38 -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 1ED921AD0B2 for ; Tue, 15 Sep 2015 13:45:38 -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 smtp4.pacifier.net (Postfix) with ESMTPSA id 4130A38F28; Tue, 15 Sep 2015 13:45:37 -0700 (PDT) From: "Jim Schaad" To: , References: In-Reply-To: Date: Tue, 15 Sep 2015 13:43:15 -0700 Message-ID: <01ca01d0eff7$25ed1780$71c74680$@augustcellars.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_01CB_01D0EFBC.798EDBC0" X-Mailer: Microsoft Outlook 15.0 Content-Language: en-us Thread-Index: AQKFA89gBb6aoX3EmWa0b9j8R0cG6ZzM4/dQ Archived-At: Subject: Re: [Ace] Second WGLC for draft-ietf-ace-usecases-05 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, 15 Sep 2015 20:45:40 -0000 This is a multipart message in MIME format. ------=_NextPart_000_01CB_01D0EFBC.798EDBC0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit The document look reasonable for progression. Comments Section 2.1 - paragraph 4 - is the last sentence supposed to be a new paragraph or is there just a return problem on the line. (I would suggest looking where the markdown is producing vspace elements and fix all of those locations.) Section 2.1.2 - U1.1 - I do not see anything that requires 'transloading personnel' grant authorizations. May want to remove this. Section 2.7.2 - U7.5 - You might want to add that the failure to execute an authorized command is also an issue, so knowing if a command has or has not been executed is significant. s/BMLS/BLMS/ jim From: Ace [mailto:ace-bounces@ietf.org] On Behalf Of Kepeng Li Sent: Wednesday, September 02, 2015 4:54 PM To: ace@ietf.org Subject: [Ace] Second WGLC for draft-ietf-ace-usecases-05 Hi all, We would like to start a second WGLC on draft-ietf-ace-usecases-05. https://datatracker.ietf.org/doc/draft-ietf-ace-usecases/ This will be a 2-week last call, so it will end on Friday, September 18. Please send comments to the list. Thanks! Ciao Hannes & Kepeng ------=_NextPart_000_01CB_01D0EFBC.798EDBC0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The document look reasonable for = progression.

 

Comments

 

Section 2.1 – paragraph 4 – is = the last sentence supposed to be a new paragraph or is there just a = return problem on the line.

(I would suggest looking where the markdown = is producing vspace elements and fix all of those = locations.)

 

Section 2.1.2 – U1.1 – I do not = see anything that requires ‘transloading personnel’ grant = authorizations.  May want to remove this.

 

Section 2.7.2 – U7.5 – You might = want to add that the failure to execute an authorized command is also an = issue, so knowing if a command has or has not been executed is = significant.

 

s/BMLS/BLMS/

 

 

jim

 

 

From:<= /b> = Ace [mailto:ace-bounces@ietf.org] On Behalf Of Kepeng = Li
Sent: Wednesday, September 02, 2015 4:54 PM
To: = ace@ietf.org
Subject: [Ace] Second WGLC for = draft-ietf-ace-usecases-05

 

Hi = all,

 

=

We would like to start a second = WGLC on draft-ietf-ace-usecases-05.

<= p class=3DMsoNormal> 

=

This will be a 2-week last call, = so it will end on Friday, September = 18.

 

=

Please send comments to the = list.

 

=

Thanks!

 

=

Ciao

Hannes & = Kepeng

------=_NextPart_000_01CB_01D0EFBC.798EDBC0-- From nobody Tue Sep 15 23:42: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 7F5841B379C for ; Tue, 15 Sep 2015 23:42: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 G0rbrdAzSihz for ; Tue, 15 Sep 2015 23:42:49 -0700 (PDT) Received: from mail-la0-f41.google.com (mail-la0-f41.google.com [209.85.215.41]) (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 284E01B379B for ; Tue, 15 Sep 2015 23:42:49 -0700 (PDT) Received: by lamp12 with SMTP id p12so120999031lam.0 for ; Tue, 15 Sep 2015 23:42: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:from:message-id:date :user-agent:mime-version:in-reply-to:content-type; bh=++PaL2dqsDq29EOreoLtvNz0e/bsVFzGo2qrz34yGnc=; b=H8P68DUHos6KzUT/fXk2AqhapwJmVaDqv/1Gn/oJv4q+jD7n3c/dVD3isGHKZLTgPv a3YoEBnBmT8QWDOt1r6vHIV/AWv3/0YYCiKn44Ol3yOexpgcBYkdHclLHavS1/S7hC0b tpVIE5xE/KgulS8HNOcidHkWwScREkcbmKUEiTvaSJcn6mCyQVUkAkSSgkAwM6jwsYyw CHiLEr57imzYLhgn/zUYP7gdwIoLWExnoMg9sA6KVWvXGNuc9dw3raCjQ14ZtLCptc6O 5z7gQEFKwuqM8/1gaTbO0sVus1ZgAw1n/1O0r6KrpzS/GStiQCyddMWwUAsHml3jbwVS 4EAg== X-Gm-Message-State: ALoCoQn45lwTsPnbi0qN22cdOK61oBdegRqqzhvmccdELHi3MJLGoVtng9LmqVmOfSXd1E9M2aeE X-Received: by 10.112.199.230 with SMTP id jn6mr27655849lbc.12.1442385767329; Tue, 15 Sep 2015 23:42:47 -0700 (PDT) Received: from [192.168.0.108] ([85.235.11.178]) by smtp.gmail.com with ESMTPSA id rp6sm3823800lbb.44.2015.09.15.23.42.46 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 15 Sep 2015 23:42:46 -0700 (PDT) To: ace@ietf.org References: <01ca01d0eff7$25ed1780$71c74680$@augustcellars.com> From: Ludwig Seitz Message-ID: <55F90F65.8050707@sics.se> Date: Wed, 16 Sep 2015 08:42: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: <01ca01d0eff7$25ed1780$71c74680$@augustcellars.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms000101050401000202050508" Archived-At: Subject: Re: [Ace] Second WGLC for draft-ietf-ace-usecases-05 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, 16 Sep 2015 06:42:51 -0000 This is a cryptographically signed message in MIME format. --------------ms000101050401000202050508 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable On 2015-09-15 22:43, Jim Schaad wrote: > The document look reasonable for progression. > > Comments > > Section 2.1 =96 paragraph 4 =96 is the last sentence supposed to be a n= ew > paragraph or is there just a return problem on the line. > > (I would suggest looking where the markdown is producing vspace element= s > and fix all of those locations.) > > Section 2.1.2 =96 U1.1 =96 I do not see anything that requires =91trans= loading > personnel=92 grant authorizations. May want to remove this. > > Section 2.7.2 =96 U7.5 =96 You might want to add that the failure to ex= ecute > an authorized command is also an issue, so knowing if a command has or > has not been executed is significant. > > s/BMLS/BLMS/ > > jim > Thanks Jim, we'll fix these as soon as we have collected all the comments from the WG= LC. /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 --------------ms000101050401000202050508 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 DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE1MDkxNjA2NDI0NVowLwYJKoZI hvcNAQkEMSIEIGvwjrFVvgNAAwteWld1gKcB9+YGvsRnxdRjezkP7PxUMGwGCSqGSIb3DQEJ DzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0D AgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgaUGCSsGAQQB gjcQBDGBlzCBlDCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzAp BgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0 YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgMMhpgwgacG CyqGSIb3DQEJEAILMYGXoIGUMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20g THRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG A1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EC AwyGmDANBgkqhkiG9w0BAQEFAASCAQBhU/uXkL7hSr8/DgvXbaQ3r7OTD1FDLiJYIFlaDLDg qOSqvNm8+B99MMZpsUDC+WLtNGTBRY3HUByJ6hZcD8Ce754OaRc7i4Kgf3bZM0Drt09+L6qz T2MpalJHa0j3dEQYvIt8/nzt1tlrej7ivGbiadkPjCg5Rtw7kICFAv9AlObvyG3jo5rE0Nd1 c0ot+ITes1EQ4LPcQ/FcxjbOQSCg5MVkBeYlmdjJjAPU0Rj3rn/QdxSxZe3brKvBAgE38Ved trX/lHz2NMnB6lrkhjxOy1T/BDADm7BISRa0xT7TpXtxLEM/ouYMPvtul8IOCfSAaTcCgyMy Lz2MixSF9hYPAAAAAAAA --------------ms000101050401000202050508-- From nobody Thu Sep 17 00:54: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 91FA31AD066 for ; Thu, 17 Sep 2015 00:54:47 -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 A8sHg08j1S3w for ; Thu, 17 Sep 2015 00:54:44 -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 312181AD062 for ; Thu, 17 Sep 2015 00:54:43 -0700 (PDT) X-AuditID: c1b4fb2d-f79626d000004282-e2-55fa71c010ba Received: from ESESSHC014.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id CE.F5.17026.0C17AF55; Thu, 17 Sep 2015 09:54:40 +0200 (CEST) Received: from ESESSMB303.ericsson.se ([169.254.3.214]) by ESESSHC014.ericsson.se ([153.88.183.60]) with mapi id 14.03.0248.002; Thu, 17 Sep 2015 09:54:40 +0200 From: =?utf-8?B?R8O2cmFuIFNlbGFuZGVy?= To: Jim Schaad , "ace@ietf.org" Thread-Topic: [Ace] Looking at COSE based unicast and multicast Thread-Index: AdDuo/sorjKxXnJSQaGX5o+dQpuhBgALnjSAAAkdOYAAIeyMAAAYrAEAAE80AwA= Date: Thu, 17 Sep 2015 07:54:39 +0000 Message-ID: References: <007901d0eea4$25989bf0$70c9d3d0$@augustcellars.com> <002b01d0ef07$aced5970$06c80c50$@augustcellars.com> <01b601d0eff2$120843c0$3618cb40$@augustcellars.com> In-Reply-To: <01b601d0eff2$120843c0$3618cb40$@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.150] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmphkeLIzCtJLcpLzFFi42KZGfG3RvdA4a9Qg+0NFhbfv/UwW6ye/p3N gclj45zpbB5LlvxkCmCK4rJJSc3JLEst0rdL4MqYvO8FY8GGXYwVz15MYmlgPLOVsYuRg0NC wETiTpdVFyMnkCkmceHeerYuRi4OIYGjjBJPT/VAOUsYJRZPPcUCUsUm4CLxoOERE4gtIuAm cXbyMrC4sICdxK3Pt1gg4vYSfw/0Q9l+Euf/TGYDsVkEVCXmz9jKDmLzClhITD50EWpBJ5PE p7mdYEM5BRwkDs+bxwpiMwKd9P3UGrA4s4C4xK0n85kgThWQWLLnPDOELSrx8vE/sHpRAT2J ldeb2CDiShIrtl8C+5JZQFNi/S59CNNa4so8LoiJihJTuh9CnSMocXLmE5YJjOKzkCybhdA8 C6F5FpLmWUiaFzCyrmIULU4tLs5NNzLWSy3KTC4uzs/Ty0st2cQIjLaDW37r7mBc/drxEKMA B6MSD++DsF+hQqyJZcWVuYcYpTlYlMR5W5gehAoJpCeWpGanphakFsUXleakFh9iZOLglGpg VNj55dmPIhXjvBXWNgtY9l82ajpmK2h+9lDsp6sTGA49+uOQ7DWXR0Yr527t9mu/Qqo1Ch99 mLSxbn1pyq6NRhtCI5L9Zog6MMXdakzas/3BL7vVwe881lTsm3fimfjH8xK2ezO8n3QkfCjY ueLWukCR2Meuq1Tu6EccnMJxPUnBPHlTpv2zXUosxRmJhlrMRcWJAL06kwWXAgAA Archived-At: Subject: Re: [Ace] Looking at COSE based unicast and multicast 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, 17 Sep 2015 07:54:47 -0000 SmltLCANCg0KSSB0aGluayB3ZSBhcmUgYXJndWluZyBmcm9tIGZpeGVkIHBvc2l0aW9ucy4NCg0K Q09TRV9FbmNyeXB0ZWQgZm9ybWF0LCB3aXRob3V0IG1hbmRhdG9yeSByZWNpcGllbnQgc3RydWN0 dXJlLCBpcyBhIGdvb2QNCnN0ZXAgdG93YXJkcyBhIG1vcmUgb3B0aW1pemVkIGZvcm1hdC4gVGhl IG1haW4gZGlzYWdyZWVtZW50IHNlZW1zIHRvIGJlIG9uDQp0aGUgb3B0aW9uIHRvIHVzZSBhIGNv bnRleHQgaWRlbnRpZmllciBpbiB0aGUgaGVhZGVyLg0KDQpXZSB3b3VsZCBsaWtlIHRvIGFwcGx5 IHRoaXMgb3B0aW1pemVkIGZvcm1hdCBhbHNvIHRvIHN5bW1ldHJpYyBlbmNyeXB0aW9uDQorIGFz eW1tZXRyaWMgc2lnbmF0dXJlLCBhcyB3ZWxsIGFzIGludGVncml0eSBwcm90ZWN0aW9uIG9ubHkg KG9ubHkgb25lDQpzaWduYXR1cmUvTUFDKS4gQWxsIHRoZXNlIGNvdWxkIGJlIG9uZSBjb21tb24g Zm9ybWF0Lg0KDQoNCkNvbW1lbnRzIGlubGluZS4NCg0KIA0KDQpPbiAyMDE1LTA5LTE1IDIyOjA2 LCAiSmltIFNjaGFhZCIgPGlldGZAYXVndXN0Y2VsbGFycy5jb20+IHdyb3RlOg0KDQo+DQo+DQo+ PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4gRnJvbTogR8O2cmFuIFNlbGFuZGVyIFtt YWlsdG86Z29yYW4uc2VsYW5kZXJAZXJpY3Nzb24uY29tXQ0KPj4gU2VudDogTW9uZGF5LCBTZXB0 ZW1iZXIgMTQsIDIwMTUgMTE6MjAgUE0NCj4+IFRvOiBKaW0gU2NoYWFkIDxpZXRmQGF1Z3VzdGNl bGxhcnMuY29tPjsgYWNlQGlldGYub3JnDQo+PiBTdWJqZWN0OiBSZTogW0FjZV0gTG9va2luZyBh dCBDT1NFIGJhc2VkIHVuaWNhc3QgYW5kIG11bHRpY2FzdA0KPj4gDQo+PiBDb21tZW50cyBpbmxp bmUuDQo+PiANCj4+IE15IHN1bW1hcnk6DQo+PiANCj4+IFRoZSByZXF1ZXN0IGluIGdlbmVyYWwg bmVlZHMgYSBjb250ZXh0IGlkZW50aWZpZXIuIFlvdXIgcHJvcG9zYWwgaXMgdG8NCj4+dXNlIHRo ZQ0KPj4gQ09TRV9lbnZlbG9wZWQgZm9ybWF0LCBteSBwcm9wb3NhbCBpcyB0byBhbGxvdyBhbiBv cHRpb25hbCBjb250ZXh0DQo+PmlkZW50aWZpZXINCj4+IGluIHRoZSBDT1NFX2VuY3J5cHRlZCBm b3JtYXQsIHdoaWNoIGlzIG1vcmUgY29tcGFjdC4NCj4+IA0KPj4gSWYgeW91IGFzc29jaWF0ZSB0 aGUgQ29BUCBUb2tlbiBvZiBhIHJlcXVlc3QgdG8gdGhlIGNvbnRleHQgdGhlbiB5b3UNCj4+Y2Fu IHVzZQ0KPj4gdGhhdCBhcyBhbiBpbmRleCBmb3IgY29udGV4dCBpZGVudGlmaWVyIGluIHRoZSBy ZXNwb25zZSBhbmQgaGVuY2UgdXNlDQo+PiBDT1NFX2VuY3J5cHRlZC4gQnV0IG5vdyB5b3UgaGF2 ZSB0d28gcGFyYW1ldGVycyB0aGF0IHBlcmZvcm0gYSBzaW1pbGFyDQo+PiB0YXNrOiBUb2tlbiBh bmQgQ29udGV4dCBJZGVudGlmaWVyLCBhbmQgd2hpY2ggYm90aCBoYXMgdG8gYmUNCj4+dHJhbnNm ZXJyZWQgaW4gYQ0KPj4gcmVxdWVzdC4gVGhlIFRva2VuIGZpZWxkIGlzIHZhcmlhYmxlIGxlbmd0 aCAwLTggYnl0ZXMuIFNpbmNlIHdlIGNhbm5vdA0KPj5hdHRyaWJ1dGUNCj4+IGFueSBlbmQtdG8t ZW5kIHNlY3VyaXR5IHByb3BlcnRpZXMgb2YgVG9rZW4sIHRoZSBvYmplY3Qgc2VjdXJpdHkgc2No ZW1lDQo+PmlzIG1hZGUNCj4+IGluZGVwZW5kZW50IG9mIGhvdyB0aGUgVG9rZW4gaXMgc2V0LCBh bmFsb2dvdXNseSB0byB0aGUgY2FzZSBpbiBEVExTLg0KPj5CeSBpbnN0ZWFkDQo+PiByZWx5aW5n IG9uIFRva2VuIHRvIGF2b2lkIGNvbGxpc2lvbnMgd2UgbWF5IG5lZWQgYSBsYXJnZXIgVG9rZW4u DQo+DQo+VGhlcmUgaXMgbm8gbmVlZCB0byBleHBsaWNpdGx5IHByb3RlY3QgdGhlIGNvbnRleHQg aWRlbnRpZmllci4gIEl0IGlzDQo+aW1wbGljaXRseSBwcm90ZWN0ZWQgYXMgdGhlIG1lc3NhZ2Ug d2lsbCBmYWlsIHRvIHZhbGlkYXRlIGlmIHlvdSB1c2UgdGhlDQo+d3JvbmcgY29udGV4dC4gIFRo aXMgbWVhbnMgdGhhdCBpdCBpcyBwcm90ZWN0ZWQgZXZlbiBpZiBpdCBpcyBub3QgcGFydCBvZg0K PnRoZSBtZXNzYWdlIHByb3BlcnRpZXMuICBIYXZpbmcgdGhlIGNvbnRleHQgaWRlbnRpZmllZCBi eSB0aGUgdG9rZW4gaXMNCj50b3RhbGx5IGxlZ2l0aW1hdGUgYW5kIHRvdGFsbHkgc2VjdXJlLiAg IEluIHRoZSBjYXNlIG9mIHVuaWNhc3QgRFRMUywNCj50aGVyZSBpcyBubyBleHBsaWNpdCBjb250 ZXh0IGlkZW50aWZpZXIgYW55d2hlcmUuICBJdCBpcyB0b3RhbGx5IGJhc2VkIG9uDQo+dGhlIGZv dXItdHVwbGUgb2YgYWRkcmVzc2VzIGFuZCBwb3J0cy4gIFRoaXMgaGFzIHplcm8gY3J5cHRvZ3Jh cGhpYw0KPnNlY3VyaXR5IGFwcGxpZWQgdG8gdGhlc2UgdmFsdWVzLCB0aGUgc2VjdXJpdHkgaXMg dG90YWxseSBpbXBsaWNpdC4NCg0KSSBkb27igJl0IGNsYWltIHRoYXQgb21pdHRpbmcgdGhlIGNv bnRleHQgaWRlbnRpZmllciBpcyBpbnNlY3VyZS4gQnV0IGl0IGlzDQpub3QgYWx3YXlzIGZlYXNp YmxlIGUuZy4gaW4gcmVxdWVzdHMsIGFuZCBpdCBoYXMgaW1wYWN0IG9uIHByb2Nlc3NpbmcgYW5k DQpzaXplIG9mIG90aGVyIHBhcmFtZXRlcnMgc3VjaCBhcyBDb0FQIFRva2VuLg0KDQoNCj4NCj4+ IA0KPj4gSeKAmW0gbm90IGNvbnZpbmNlZCB3aXRoIHRoZSBkaWZmZXJlbmNlIGJldHdlZW4gaG93 IHRoZSBtZXNzYWdlIGlzDQo+PmZvcm1hdHRlZA0KPj4gZGVwZW5kaW5nIG9uIHdoZXRoZXIgaXQg aXMgYSByZXF1ZXN0IG9yIHJlc3BvbnNlLiBBIGdpdmVuIG5vZGUgbWF5IHNlbmQNCj4+dGhlDQo+ PiBzYW1lIHJlc291cmNlIHJlcHJlc2VudGF0aW9uIGFzIFBVVCByZXF1ZXN0IG9yIEdFVCByZXNw b25zZSBhbmQgdGh1cw0KPj53b3VsZA0KPj4gdXNlIGRpZmZlcmVudCBDT1NFIG1lc3NhZ2UgZm9y bWF0cy4NCj4NCj5HaXZlbiB0aGF0IHRoZSBDT1NFIG1lc3NhZ2UgcmVwcmVzZW50YXRpb24gaXMg Z29pbmcgdG8gaGF2ZSB0byBiZSBidWlsdA0KPnVuaXF1ZWx5IGZvciBlYWNoIG1lc3NhZ2Ugc2Vu dCwgSSBkb24ndCBrbm93IHRoYXQgdGhpcyBpcyBhIHByb2JsZW0uICBIb3cNCj50aGUgQ09TRSBp cyBjcmVhdGVkIGlzIGJhc2VkIG9uIHRoZSBodHRwLWxpa2Ugb3BlcmF0aW9uIHRoYXQgaXMgYmVp bmcNCj51c2VkLiAgVGhpcyB3aWxsIGJlIHdlbGwgdW5kZXJzdG9vZCB3aGVuIGl0IG9jY3VycyBh bmQgd2hlbiBpdCBkb2VzIG5vdA0KPm9jY3VyLiAgDQoNCkl0IGlzIHBvc3NpYmxlIHRvIHVzZSBk aWZmZXJlbnQgQ09TRSBmb3JtYXRzIGZvciByZXF1ZXN0IGFuZCByZXNwb25zZSBidXQNCmluIHRo ZSBjYXNlIEkgbWVudGlvbmVkIHdoZW4gdGhlIHNhbWUgcmVzb3VyY2UgcmVwcmVzZW50YXRpb24g Zm9yDQpwb3RlbnRpYWxseSB0aGUgc2FtZSBjb21zdW1lciBpcyB1c2luZyBhIGRpZmZlcmVudCBm b3JtYXQgYW5kIG9mIGRpZmZlcmVudA0Kc2l6ZSBkZXBlbmRpbmcgb24gd2hldGhlciBpdCBpcyBQ VVQgcmVxdWVzdCBvciBHRVQgcmVzcG9uc2UsIHRoYXQganVzdA0KZG9lc27igJl0IHNvdW5kIGxp a2UgYSBnb29kIGlkZWEuDQoNCj4NCj4+IA0KPj4gDQo+PiBJdCBpcyBhbHNvIGEgbWF0dGVyIG9m IGhvdyB0aGUgcmVjZWl2ZWQgQ09TRSBvYmplY3Qgd2lsbCBiZQ0KPj5zdWJzZXF1ZW50bHkgdXNl ZC4NCj4+IEZvciBleGFtcGxlLCBpbiBJbmZvcm1hdGlvbi1DZW50cmljIE5ldHdvcmtpbmcsIGlm IEnigJltIG5vdCBtaXN0YWtlbiwNCj4+b25lIG9mIHRoZQ0KPj4gcmVxdWlyZW1lbnRzIGlzIHRo YXQgZWFjaCBwcm90ZWN0ZWQgb2JqZWN0IGhhcyBhIGdsb2JhbGx5IHVuaXF1ZSBuYW1lLg0KPj5C eQ0KPj4gc2hpZnRpbmcgZm9jdXMgZnJvbSBhIGNvbnRleHQgaWRlbnRpZmllciB3aXRoaW4gdGhl IENPU0Ugb2JqZWN0IHRvDQo+PlRva2VuIHdoaWNoIGlzDQo+PiBlcGhlbWVyYWwgZGF0YSBvdXRz aWRlIHRoZSBDT1NFIG9iamVjdCwgSUNOIGFwcGxpY2F0aW9ucyB3b3VsZCBhbHdheXMNCj4+aGF2 ZSB0bw0KPj4gdXNlIHRoZSBsZXNzIGNvbXBhY3QgZm9ybWF0Lg0KPg0KPklmIHlvdSBhcmUgY29y cmVjdCwgYW5kIHRoZSB1bmlxdWUgbmFtZSBpcyBhbHdheXMga25vd24gdG8gYm90aCBwYXJ0aWVz LA0KPnRoZW4gaXQgaXMgcXVpdGUgcG9zc2libGUgdGhhdCB5b3UgaGF2ZSBhIHNpdHVhdGlvbiB3 aGVyZSB0aGUgY29udGV4dA0KPmluZm9ybWF0aW9uIGNhbiBhbHdheXMgYmUgaW1wbGljaXQgYW5k IHdvdWxkIG5vdCBuZWVkIHRvIGJlIGNhcnJpZWQgYXQNCj5hbGwuDQoNCkFzIGZhciBhcyBJIHVu ZGVyc3RhbmQgSUNOIEkgYmVsaWV2ZSB0aGUgbmFtZSBzaG91bGQgYmUgYm91bmQgLyBwb3NzaWJs ZQ0KdG8gZGVyaXZlIGZyb20gdGhlIGluZm9ybWF0aW9uIG9iamVjdC4gQnV0IHdlIGNvdWxkIGxl YXZlIHRoaXMgdG8gdGhlIElDTg0KZXhwZXJ0cyB0byBjb21tZW50IG9uLiBJIGp1c3Qgbm90ZSB0 aGF0IHRoZXJlIG1heSBiZSBhIHNpZ25pZmljYW5jZQ0Kd2hldGhlciBpZGVudGlmaWNhdGlvbiBp cyBwcm92aWRlZCBieSB0aGUgb2JqZWN0IGl0c2VsZiBvciBpZiBpdCByZXF1aXJlcw0KYWRkaXRp b25hbCBkYXRhIChzdWNoIGFzIFRva2VuIGFuZCBVUkkpLg0KDQo+DQo+PiANCj4+IEkgdGhpbmsg d2UgYWdyZWUgdGhhdCBzb21lIHBhcmFtZXRlcihzKSBmb3IgcmVwbGF5IHByb3RlY3Rpb24vSVYN Cj4+dW5pcXVlbmVzcyBpcw0KPj4gbmVlZGVkIGluIHJlcXVlc3QgYW5kIHJlc3BvbnNlLCBzbyB3 b3VsZCBiZSBpbiB0aGUgaGVhZGVyIG9mIGJvdGgNCj4+IENPU0VfZW52ZWxvcGVkIGFuZCBDT1NF X2VuY3J5cHRlZC4NCj4NCj5JIGhhdmUgYWxyZWFkeSBzYWlkIHRoaXMgaXMgdHJ1ZSwgYW5kIGl0 IGlzIGNvbnRlbnQgcmVsYXRlZCBzbyBpdCBmaXRzDQo+dGhlIGN1cnJlbnQgQ09TRSBtb2RlbC4N Cg0KSWYgSSB1bmRlcnN0YW5kIHJpZ2h0LCB0aGlzIGlzIGFib3V0IHRoZSBjb250ZW50IC8gcmVj aXBpZW50IHBhcmFkaWdtLg0KDQpBbm90aGVyIHdheSB0byB0aGluayBvZiB0aGlzIGlzIGluIHRl cm1zIG9mIHNlbmRlciwgd2hpY2ggaXMgd2hhdCB3ZSB1c2UNCmNvbnRleHQgaWRlbnRpZmllciBm b3IuDQpJZiB0aGUgc2VuZGVyIGNvbnRleHQgaXMgaWRlbnRpZmllZCwgZWFjaCByZWNpcGllbnQg Y2FuIGZpbmQgb3V0IGZvcg0KaXRzZWxmIGlmIGFuZCBob3cgdG8gbWFrZSB1c2Ugb2YgdGhlIG9i amVjdC4gT25lIGltcG9ydGFudCBhc3N1bXB0aW9uIGlzDQp0aGF0IHRoZSBzZW5kZXIgZG9lcyBu b3QgaGF2ZSB0byBrbm93IGFueXRoaW5nIGFib3V0IHRoZSByZWNpcGllbnQuIFRoZQ0Kc2VuZGVy IGNvdWxkIHJlbHkgb24gYSB0cnVzdGVkIHRoaXJkIHBhcnR5LCB0byBwcm92aWRlIGl0IHdpdGgg dGhlIHJpZ2h0DQpzZWN1cml0eSBjb250ZXh0IGl0IHdpbGwgdXNlLCBhbmQgd2hpY2ggYWxzbyB3 aWxsIGludGVyYWN0IHdpdGggdGhlDQpyZWNpcGllbnQuDQoNCg0KPkhvd2V2ZXIsIHRoZXJlIGlz IGFuIGludGVyZXN0aW5nIHF1ZXN0aW9uIGlmIHlvdQ0KPndhbnQgdGhpcyBpbiB0aGUgQ09TRSB3 b3JsZCBvciBpbiB0aGUgQ29BUCB3b3JsZCBhbmQganVzdCBwcm90ZWN0IGl0IGluDQo+Q09TRS4g IEhhdmluZyB0d28gZGlmZmVyZW50IHJlcGxheSBwcm90ZWN0aW9uIHN5c3RlbXMgaW4gcGxhY2Ug bWF5IGJlDQo+b3ZlcmtpbGwuDQoNClRoZSBzZXF1ZW5jZSBudW1iZXIgZXRjLiBzaG91bGQgYmUg cHJvdGVjdGVkIGluIENPU0UuIEFzIGZhciBhcyBJDQp1bmRlcnN0YW5kLCB0aGUgb25seSBwbGFj ZSB0byBmb3Igc2VxdWVuY2UgbnVtYmVyIGV0Yy4gaW4gQ09TRV9lbmNyeXB0ZWQNCmlzIGluIHRo ZSBoZWFkZXIuIEJ1dCB0aGUgdmVyaWZpY2F0aW9uIG9mIHJlcGxheSBwcm90ZWN0aW9uIGJlbG9u Z3MgdG8gdGhlDQphcHBsaWNhdGlvbi4gRGlmZmVyZW50IHJlcGxheSBwcm90ZWN0aW9uIG1lY2hh bmlzbXMgbWF5IGJlIHVzZWQgZGVwZW5kaW5nDQpvbiBhcHBsaWNhdGlvbiwgZS5nLiBzbGlkaW5n IHdpbmRvdyBvciBzdHJpY3Qgb3JkZXIuDQoNCldhcyB0aGlzIHdoYXQgeW91IHdlcmUgcmVmZXJy aW5nIHRvPw0KDQoNCkfDtnJhbg0KDQoNCj4NCj4+IA0KPj4gDQo+PiBHw7ZyYW4NCj4+IA0KPj4g DQo+PiANCj4+IE9uIDIwMTUtMDktMTQgMTg6MDksICJKaW0gU2NoYWFkIiA8aWV0ZkBhdWd1c3Rj ZWxsYXJzLmNvbT4gd3JvdGU6DQo+PiANCj4+ID4NCj4+ID4NCj4+ID4+IC0tLS0tT3JpZ2luYWwg TWVzc2FnZS0tLS0tDQo+PiA+PiBGcm9tOiBHw7ZyYW4gU2VsYW5kZXIgW21haWx0bzpnb3Jhbi5z ZWxhbmRlckBlcmljc3Nvbi5jb21dDQo+PiA+PiBTZW50OiBNb25kYXksIFNlcHRlbWJlciAxNCwg MjAxNSAyOjQ4IEFNDQo+PiA+PiBUbzogSmltIFNjaGFhZCA8aWV0ZkBhdWd1c3RjZWxsYXJzLmNv bT47IGFjZUBpZXRmLm9yZw0KPj4gPj4gU3ViamVjdDogUmU6IFtBY2VdIExvb2tpbmcgYXQgQ09T RSBiYXNlZCB1bmljYXN0IGFuZCBtdWx0aWNhc3QNCj4+ID4+DQo+PiA+Pg0KPj4gPj4NCj4+ID4+ IE9uIDIwMTUtMDktMTQgMDY6MTYsICJKaW0gU2NoYWFkIiA8aWV0ZkBhdWd1c3RjZWxsYXJzLmNv bT4gd3JvdGU6DQo+PiA+Pg0KPj4gPg0KPj4gPg0KPj4gPj4gPg0KPj4gPj4gPj5Gcm9tIHRoaXMs IGl0IHNlZW1zIHRvIG1lIHRoYXQgZG9lcyBzdXBwb3J0IHRoZSBwb3NpdGlvbiB0aGF0IHNvbWUN Cj4+ID4+ID5pbmZvcm1hdGlvbiBhYm91dCBjb250ZXh0IG5lZWRzIHRvIGJlIHBhc3NlZCBvbiB0 aGUgaW5pdGlhbCBtZXNzYWdlLg0KPj4gPj4gPkRlcGVuZGluZyBvbiBob3cgdGhpcyBpcyBwcmVz ZW50ZWQgSSB3b3VsZCBleHBlY3QgdGhpcyB0byBiZSBkb25lDQo+PiA+PiA+d2l0aCB0aGUgY3Vy cmVudCBDT1NFIGVuY3J5cHRlZCBtZXNzYWdlIHN0cnVjdHVyZS4gIEl0IGlzDQo+PiA+PiA+cG90 ZW50aWFsbHkgZGlmZmVyZW50IGluIHRoZSBjYXNlIHdoZXJlIHRoZSBjbGllbnQgaXMgYmVpbmcg dXNlZCB0bw0KPj4gPj4gPnJlbGF5IGluZm9ybWF0aW9uIHRvIHRoZSBzZXJ2ZXIgYWJvdXQgdGhl IGF1dGhvcml6YXRpb24gaW5mb3JtYXRpb24uDQo+PiA+Pg0KPj4gPj4gVXNpbmcgdGhlIGN1cnJl bnQgQ09TRSBlbmNyeXB0ZWQgbWVzc2FnZSBzdHJ1Y3R1cmUgaXMgbm90IGFkZHJlc3NpbmcNCj4+ ID4+IHRoZSBjb25jZXJucyBhYm91dCBtZXNzYWdlIHNpemUgYXMgaGFzIGJlZW4gZGlzY3Vzc2Vk IHByZXZpb3VzbHkuDQo+PiA+PiBGcm9tIHRoZSBwcm9wb3NlZCBBQ0UgYXJjaGl0ZWN0dXJlIEkg Y2FuIHJlZmVyZW5jZSB0d28gY2F0ZWdvcmllcyBvZg0KPj4gZm9ybWF0czoNCj4+ID4+DQo+PiA+ PiAxLiBPbmUgY2F0ZWdvcnkgd2hpY2ggYXNzdW1lcyB0aGF0IHRoZXJlIGlzIGVzc2VudGlhbGx5 IG9ubHkgYSDigJxiYXNlDQo+PiA+PmtleeKAnQ0KPj4gPj4gZXN0YWJsaXNoZWQgYmV0d2VlbiBz ZW5kZXIgYW5kIHJlY2VpdmVyLCBhbmQgd2hlcmUgdGhlIG1lc3NhZ2UNCj4+ID4+cHJvdmlkZXMg IG1lYW5zIHRvIGRlcml2ZSB0aGUgc2VjdXJpdHkgY29udGV4dCB0byB1c2Ugd2l0aCB0aGUNCj4+ bWVzc2FnZS4NCj4+ID4+DQo+PiA+PiAyLiBBbm90aGVyIGNhdGVnb3J5IHdoaWNoIGlzIGhpZ2hs eSBvcHRpbWl6ZWQgZm9yIHRoZSBzZXR0aW5nIHRoYXQNCj4+ID4+dGhlIHNlY3VyaXR5ICBjb250 ZXh0IGlzIGF2YWlsYWJsZSBhdCB0aGUgcmVjZWl2ZXIuDQo+PiA+Pg0KPj4gPj4NCj4+ID4+IEkg dGhpbmsgdGhlIGRpc3RpbmN0aW9uIGJldHdlZW4gQ09TRV9FbnZlbG9wZWQgYW5kIENPU0VfRW5j cnlwdGVkDQo+PiA+PnN0cnVjdHVyZSAgaXMgYSBnb29kIHN0ZXAgaW4gdGhlIHJpZ2h0IGRpcmVj dGlvbiwgYnV0IHRoZSBsYXR0ZXINCj4+ID4+c2hvdWxkIGFsbG93IGZvciB0aGUgZGVzaXJlZCAg aWRlbnRpZmljYXRpb24gYW5kIG9wdGltaXphdGlvbiBmb3IgdGhlDQo+PiA+Pm1vc3QgY29tbW9u IHNldHRpbmdzLiBTb21ldGhpbmcNCj4+ID4+bGlrZToNCj4+ID4+DQo+PiA+PiBbIG1lc3NhZ2Ug dHlwZSwgcHJvdGVjdGVkIGhlYWRlcnMsIGNpcGhlciB0ZXh0LCB0YWcgXQ0KPj4gPj4NCj4+ID4+ DQo+PiA+PiB3aGVyZSBwcm90ZWN0ZWQgaGVhZGVycyBjYW4gaWRlbnRpZnkgdGhlIHNlY3VyaXR5 IGNvbnRleHQgYW5kIHRoZQ0KPj4gPj4gbm9uY2Uvc2VxdWVuY2UgbnVtYmVyLg0KPj4gPj4NCj4+ ID4+IEluIGZhY3QsIHRvIGdldCByZXBsYXkgcHJvdGVjdGlvbiBvZiByZXF1ZXN0LCBhbmQgb2Yg cmVzcG9uc2UgaWYgbm8NCj4+ID4+cHJpb3IgcmVxdWVzdCAgYm91bmQgdG8gdGhlIHJlc3BvbnNl LCBvbmUgb2YgdGhlIGZpZWxkcyBpbiB0aGUNCj4+ID4+cHJvdGVjdGVkIGhlYWRlciBtdXN0IGJl ICBub25jZS9zZXF1ZW5jZSBudW1iZXIvdGltZXN0YW1wLCByaWdodD8NCj4+ID4+VGh1cyB0aGUg Zm9ybWF0IHdvdWxkIGFueXdheSAgY2Fycnkgc29tZSBpbmZvcm1hdGlvbiBhYm91dCBzZWN1cml0 eQ0KPj4gPj5jb250ZXh0LiBJdCBzZWVtcyBvZGQgdG8gbm90IGFsbG93IGFuICBpZGVudGlmaWVy IG9mIHdoYXQgY29udGV4dCB0aGlzDQo+PiA+Pm5vbmNlL2V0Yy4gcmVmZXJzIHRvLg0KPj4gPj4N Cj4+ID4+DQo+PiA+PiA+DQo+PiA+PiA+VGhlIHJlc3BvbnNlIGRvZXMgbm90IGFwcGVhciB0byBu ZWVkIGEgY29udGV4dCBpZGVudGlmaWVyIGFzIHRoZXJlDQo+PiA+PiA+aXMgYWxyZWFkeSBpbmZv cm1hdGlvbiBpbiB0aGUgQ29BUCBtZXNzYWdlIHRoYXQgY2FuIGJlIHVzZWQgZm9yDQo+PiA+PiA+ ZGV0ZXJtaW5pbmcgdGhlIGNvbnRleHQuDQo+PiA+Pg0KPj4gPj4gPlNwZWNpZmljYWxseSB0aGUg VG9rZW4gYW5kIE1lc3NhZ2UgSUQgZmllbGRzIGNhbiBiZSB1c2VkIHRvDQo+PiA+PiA+YXNzb2Np YXRlIHJlcXVlc3RzIGFuZCByZXNwb25zZXMuDQo+PiA+Pg0KPj4gPj4gTWVzc2FnZSBJRCBpcyBu b3QgYSByZWxpYWJsZSBpZGVudGlmaWVyIGZvciBhc3NvY2lhdGluZyByZXF1ZXN0IHRvDQo+PiA+ PnJlc3BvbnNlLg0KPj4gPg0KPj4gPkZpcnN0LCBwbGVhc2Ugbm90ZSB0aGF0IEkgc2FpZCBib3Ro IFRva2VuIGFuZCBNZXNzYWdlIElELiAgQXJlIHRoZXJlDQo+PiA+Y2FzZXMgdGhhdCBiZXR3ZWVu IHRoZXNlIHR3byBmaWVsZHMgdGhlIHJlcXVlc3QgYW5kIHRoZSByZXNwb25zZSBjYW5ub3QNCj4+ ID5iZSBhc3NvY2lhdGVkPw0KPj4gDQo+PiBJIGRvbuKAmXQgc2VlIGhvdyBNZXNzYWdlIElEIGFk ZHMgYW55dGhpbmcuIENvbXBhcmUgZmlndXJlcyA1IGFuZCA2IG9mDQo+PlJGQzcyNTIuDQo+PiBJ IGJlbGlldmUgbWF0Y2hpbmcgQ29BUCBUb2tlbiBpbiByZXF1ZXN0IGFuZCByZXNwb25zZSB3b3Vs ZCBiZQ0KPj5zdWZmaWNpZW50LA0KPj4gYWx0aG91Z2ggdGhlIFRva2VuIGluIGl0c2VsZiBjYW7i gJl0IGJlIGludGVncml0eSBwcm90ZWN0ZWQgaW4gdHJhbnNmZXINCj4+c2luY2UgaXQgbWF5DQo+ PiBiZSBjaGFuZ2VkIGJ5IGEgcHJveHkuDQo+PiANCj4+ID4NCj4+ID4+DQo+PiA+PiA+ICBUaGlz IG1lYW5zIHRoYXQgYSBjbGllbnQgY2FuIHVzZSB0aGlzIHRvIGRldGVybWluZSB3aGF0IGNvbnRl eHQNCj4+ID4+ID53YXMgdXNlZCBieSB0aGUgc2VydmVyIHRvIGVuY3J5cHQgdGhlIG1lc3NhZ2Ug dGhhdCB3YXMgcmV0dXJuZWQuDQo+PiA+PiA+KFNwZWNpZmljYWxseSwgdGhlIHNhbWUgY29udGV4 dCBhbmQgdGhlIGNsaWVudCB1c2VkIHRvIGVuY3J5cHQgdGhlDQo+PiA+PiA+cmVxdWVzdC4pDQo+ PiA+Pg0KPj4gPj4gVGhlIGNvbnRleHQgbWF5IGJlIGRpZmZlcmVudCBmb3IgcmVxdWVzdCBhbmQg cmVzcG9uc2UsIGFuZCBhbHdheXMgaXMNCj4+ID4+IGluIE9TQ09BUC4NCj4+ID4NCj4+ID5QbGVh c2Ugbm90ZSB0aGF0IEkgYW0gdXNpbmcgY29udGV4dCBpbiB0aGUgc2FtZSB3YXkgdGhhdCBUTFMg dXNlcyB0aGlzDQo+PiA+dGVybS4gIFRoaXMgbWVhbnMgdGhhdCB0aGUgaW5mb3JtYXRpb24gaXMg Z29pbmcgdG8gYmUgZGlmZmVyZW50IGZvciB0aGUNCj4+ID50d28gZGlyZWN0aW9ucywgYnV0IHRo ZSBjb250ZXh0IGlkZW50aWZpZXMgYSBzaW5nbGUgc2V0IG9mIGluZm9ybWF0aW9uLg0KPj4gPg0K Pj4gPkkgZG9uJ3Qgc2VlIGFueXRoaW5nIGNhbGxlZCBPU0NPQVAgaW4gZWl0aGVyIGNvcmUgb3Ig YWNlLg0KPj4gDQo+PiBTb3JyeSwgYWJicmV2aWF0aW9uIGZvciB0aGUgQUNFIGRyYWZ0ICJPYmpl Y3QgU2VjdXJpdHkgZm9yIENvQVAiDQo+PiANCj4+ID4NCj4+ID4+DQo+PiA+Pg0KPj4gPj4gPiBU aGlzIG1lYW5zIHRoYXQgd2UgY2FuIHNheSB0aGF0IHRoZXJlIGlzIGFuIGltcGxpY2l0IGNvbnRl eHQgZm9yDQo+PiA+PiA+ZW5jcnlwdGVkIG1lc3NhZ2VzIGluIHRoaXMgY2FzZSB0aGUgbmV3IGVu Y3J5cHRpb24gc3RydWN0dXJlIHcvbw0KPj4gPj4gPnJlY2lwaWVudHMgd291bGQgbWFrZSBzZW5z ZS4gIFRoaXMgYW5hbHlzaXMgd291bGQgYXBwbHkgdG8gdGhlDQo+PiA+PiA+b2JzZXJ2ZSBkaWFs b2cgc3RydWN0dXJlIGFzIHdlbGwsIHRoZSB0b2tlbiBjYW4gYmUgdXNlZCB0byBhc3NvY2lhdGUN Cj4+ID4+ID5hbGwgaXRlbXMgaW4gdGhlIHNhbWUgY29udGV4dC4NCj4+ID4+DQo+PiA+PiBFdmVu IGlmIHRoZXJlIGFyZSBjYXNlcyB3aGVyZSBsZWF2aW5nIG91dCBjb250ZXh0IGluIHJlc3BvbnNl IGNvdWxkDQo+PiA+PmJlICBwZXJmb3JtZWQsIEkgdGhpbmsgaXQgc2hvdWxkIGJlIGFsbG93ZWQg dG8gc3BlY2lmeSBjb250ZXh0IGFzIGFuDQo+Pm9wdGlvbi4NCj4+ID4+IFRoaXMgd291bGQgYWxz byByZWxpZXZlIHRoZSBzZXR0aW5ncyB3aGVyZSBtdWx0aXBsZSBjb250ZXh0cyBuZWVkcyB0bw0K Pj4gPj5iZSB0cmllZC4NCj4+ID4NCj4+ID5QbGVhc2UgaWRlbnRpZnkgc2l0dWF0aW9ucyB3aGVy ZSBtdWx0aXBsZSBjb250ZXh0cyB3b3VsZCBuZWVkIHRvIGJlDQo+PiA+dHJpZWQuICBJIGhhdmUg b25seSBjb21lIHVwIHdpdGggb25lIHNvIGZhciwgYXNzdW1pbmcgdGhhdCBvbmUgaXMgZ29pbmcN Cj4+ID50byB1c2UgZGlzdGluY3QgYWRkcmVzcy9wb3J0IHBhaXJzIGZvciB0aGUgbXVsdGktY2Fz dCBjYXNlLiAgVGhhdCB3b3VsZA0KPj4gPmJlIHRoZSBjYXNlIG9mIHN1YnNjcmliaW5nLg0KPj4g DQo+PiBBbm90aGVyIGNhc2UgaXMgVG9rZW4gY29sbGlzaW9ucy4NCj4+IA0KPj4gPg0KPj4gPj4N Cj4+ID4+ID4NCj4+ID4+ID5Gb3IgYSBzdWJzY3JpcHRpb24gbW9kZWwgdG8gYSB0aGlyZCBwYXJ0 eSwgdGhlcmUgYXJlIGEgY291cGxlIG9mDQo+PiA+PiA+ZGlmZmVyZW50IHdheXMgdG8gbG9vayBh dCBob3cgaXQgY2FuIGJlIHNldHVwLiAgVGhlIGJpZyBxdWVzdGlvbiBpcw0KPj4gPj4gPmlmIHRo ZSBjb250ZXh0IGlzIGdvaW5nIHRvIGJlIHVuaXF1ZSB0byB0aGUgb3JpZ2luYXRvciwgb3IgaXQg aXMNCj4+ID4+ID51bmlxdWUgdG8gdGhlIHN1YnNjcmlwdGlvbi4NCj4+ID4+ID5JbiBlaXRoZXIg Y2FzZSwgdGhlIGNsaWVudCBpcyBnb2luZyB0byBlbmQgdXAgdXNpbmcgdHdvIGRpZmZlcmVudA0K Pj4gPj4gPmNvbnRleHRzIGluIHRoaXMgc2l0dWF0aW9uLiAgVGhlIGZpcnN0IGNhc2UgaXMgZm9y IHNldHRpbmcgdXAgdGhlDQo+PiA+PiA+b3JpZ2luYWwgc3Vic2NyaXB0aW9uLiAgSW4gdGhhdCBj YXNlIGEgY29udGV4dCBhc3NvY2lhdGVkIHdpdGggdGhlDQo+PiA+PiA+ZGF0YSBzdG9yYWdlIHNl cnZlciBpcyBnb2luZyB0byBiZSBuZWVkZWQuICBIb3dldmVyLCBvbmNlDQo+PiA+PiA+aW5mb3Jt YXRpb24gc3RhcnRzIGZsb3dpbmcgYmFjayB0byB0aGUgY2xpZW50IGZyb20gdGhlIGRhdGEgc3Rv cmFnZQ0KPj4gPj4gPnNlcnZpY2UsIHRoZSBjb250ZXh0IGFzc29jaWF0ZWQgd2l0aCB0aGUgb3Jp Z2luYXRpb24gc2VydmVyIGlzIGdvaW5nDQo+PiA+PiA+dG8gYmUgdXNlZC4gIEl0IGlzIG5vdCBj bGVhciB0aGF0IHRoZSBhY3Rpb24gb2YgZG9pbmcgdGhlDQo+PiA+PiA+c3Vic2NyaXB0aW9uIHdv dWxkIG5lZWQgdG8gYmUgZW5jcnlwdGVkLCAgdGhpcyBzaW1wbGlmaWVkIHRoaW5ncyBhcw0KPj4g Pj4gPm9ubHkgb25lIGVuY3J5cHRpb24gY29udGV4dCBpcyBub3cgbmVlZGVkLiAgT3RoZXJ3aXNl IGVpdGhlciB0d28NCj4+ID4+ID5jb250ZXh0cyBuZWVkIHRvIGJlIHRyaWVkLCBvciB0aGUgdHlw ZSBvZiBtZXNzYWdlIG5lZWRzIHRvIGJlIGtub3duDQo+PiA+PiA+c28gdGhhdCB0aGUgY2xpZW50 IHVuZGVyc3RhbmQgd2hlcmUgdGhlIGVuY3J5cHRlZCBjb250ZW50DQo+Pm9yaWdpbmF0ZXMuDQo+ PiA+Pg0KPj4gPj4gVGhlIGRhdGEgc3RvcmUgbmVlZCBub3QgYmUgdHJ1c3RlZC4gSW5mb3JtYXRp b24gYWJvdXQgYmluZGluZyBiZXR3ZWVuDQo+PiA+PmRpZmZlcmVudCBjb250ZXh0cyBuZWVkcyB0 byBiZSBvYnRhaW5lZCBmcm9tIGEgdHJ1c3RlZCBwYXJ0eSwgc3VjaCBhcw0KPj4gPj50aGUgIGF1 dGhvcml6YXRpb24gc2VydmVyLiBJIGJlbGlldmUgdGhlIHByZXNlbmNlIG9mIGEgY29udGV4dA0K Pj4gPj5pZGVudGlmaWVyIHdvdWxkIHNpbXBsaWZ5ICB0aGUgcHJvY2Vzc2luZyB3aGVyZSB0aGlz IHR5cGUgb2YgYmluZGluZw0KPj4gPj5uZWVkcyB0byBiZSBlc3RhYmxpc2hlZCBhZnRlciB0aGUg IG1lc3NhZ2UgaGFzIGJlZW4gcmVjZWl2ZWQsIGNvbXBhcmVkDQo+PiA+PnRvIHRoZSBjYXNlIG9m IHJlY2VpdmluZyBhbiBlbmNyeXB0ZWQgIHN0cnVjdHVyZSB3aXRob3V0IGFueSBoYW5kbGUNCj4+ ID4+d2hhdHNvZXZlci4NCj4+ID4NCj4+ID5JbiBteSBhbmFseXNpcyBJIGRpZCBub3QgbWFrZSBh bnkgYXNzdW1wdGlvbnMgdGhhdCB0aGUgZGF0YSBzdG9yZSB3YXMNCj4+ID50cnVzdGVkIHRvIGRv IGFueXRoaW5nIG1vcmUgdGhhbiBpdHMgYXNzaWduZWQgam9iLiAgSSBkaWQgbm90IG1ha2UgYW55 DQo+PiA+YXNzdW1wdGlvbnMgdGhhdCBpdCB3b3VsZCBkbyBjcnlwdG9ncmFwaHkgZXhjZXB0IGZv ciBtZXNzYWdlcyBzZW50DQo+PiA+ZGlyZWN0bHkgdG8gaXQuDQo+PiANCj4+IEZhaXIgZW5vdWdo LiBJIHRyaWdnZXJlZCBvbiAidGhlIGNsaWVudCBpcyBnb2luZyB0byBlbmQgdXAgdXNpbmcgdHdv DQo+PmRpZmZlcmVudA0KPj4gY29udGV4dHMgaW4gdGhpcyBzaXR1YXRpb27igJ0sICBidXQgYXMg eW91IHNheSB0aGVyZSBhcmUgbm8gZ3VhcmFudGVlcyB0bw0KPj53aGF0IHRoZXNlDQo+PiBjb250 ZXh0IHByb3ZpZGUuDQo+PiANCj4+IA0KPj4gPkkgZG8gbm90IHNlZSBhbnkgZGlmZmVyZW5jZSBp biBuZWVkaW5nIHRvIG9idGFpbiB0aGUga2V5cy9jb250ZXh0DQo+PiA+aW5mb3JtYXRpb24gZWl0 aGVyIGJlZm9yZSBvciBhZnRlciByZWNlaXZpbmcgdGhlIGZpcnN0IG1lc3NhZ2UuDQo+PiA+SG93 ZXZlciwgc2luY2Ugd2UgZG8gbm90IGhhdmUgYSBza2V0Y2hlZCBwcm90b2NvbCBmb3IgZ2V0dGlu ZyBrZXlzIHlldA0KPj4gPml0IGlzIGhhcmQgdG8gYmUgc3VyZS4gIEV2ZW4gaWYgeW91IGhhdmUg Y3VycmVudCBrZXlzIHlvdSB3aWxsIHN0aWxsDQo+PiA+bmVlZCB0byBiZSBhYmxlIHRvIGdldCB1 cGRhdGVkIGtleXMgd2hlbiB0aGUgZXBvY2ggcm9sbHMgb3ZlciB0byB0aGUNCj4+ID5uZXh0IHZh bHVlLiAgVGhpcyBtZWFucyB0aGF0IHRoZSB0d28gY2FzZXMgYXJlIGdvaW5nIHRvIGJlIHZlcnkN Cj4+c2ltaWxhci4NCj4+IA0KPj4gSSB3YXMgdGhpbmtpbmcgb2YgYSBjYXNlIHdoZW4gdGhlIHJl Y2VpdmluZyBub2RlIGFjdHVhbGx5IGhhcyB0aGUNCj4+cmVsZXZhbnQNCj4+IGNvbnRleHQsIGJ1 dCBzaW5jZSB0aGVyZSBpcyBubyBjb250ZXh0IGlkZW50aWZpZXIgY2Fubm90IGRldGVybWluZSB0 aGlzDQo+PmlzIHRoZSBjYXNlDQo+PiBiZWZvcmUgZG9pbmcgYSBsb29rLXVwIG9mIHdoYXQgY29u dGV4dCBpcyB2YWxpZCBmb3IgdGhpcyByZXNvdXJjZS4NCj4+IA0KPj4gPg0KPj4gPj4NCj4+ID4+ ID4NCj4+ID4+ID5Gb3IgdGhlIGNhc2Ugb2YgbXVsdGljYXN0LCBpdCBhcHBlYXJzIHRvIG1lIHRo YXQgdGhlIGNvbnRleHQgY2FuIGJlDQo+PiA+PiA+aW5mZXJyZWQgaW4gbW9zdCBjYXNlcy4gIEkg d291bGQgYXNzdW1lIHRoYXQgYSBjb250ZXh0IGlzIGdvaW5nIHRvDQo+PiA+PiA+YmUgc2lnbmVk IHRvIGVhY2ggbXVsdGljYXN0IGFkZHJlc3MsIHBvcnQgcGFpci4gIEkgd291bGQgYWxzbyBhc3N1 bWUNCj4+ID4+ID50aGF0IHRoaXMgd291bGQgYmUgYSB1bmlxdWUgYXNzaWdubWVudCBpbiB0aGF0 IG11bHRpcGxlIGNvbnRleHRzDQo+PiA+PiA+d291bGQgbm90IGJlIGFzc2lnbmVkLiAgVGhpcyBk b2VzIGFsbG93IGZvciBhbnkgbm9kZSB3aGljaCBoYXMgdGhlDQo+PiA+PiA+Y29udGV4dCB0byBz ZW5kIG91dCBhIG11bHRpY2FzdCBtZXNzYWdlIHdpdGhvdXQgYSBwcm9ibGVtLiAgVGhlIG1vcmUN Cj4+ID4+ID5pbnRlcmVzdGluZyBxdWVzdGlvbiBpcyB3aGF0IHRvIGRvIHdpdGggdGhlIHVuaWNh c3QgcmVzcG9uc2VzIHRvIGENCj4+ID4+ID5tdWx0aWNhc3QgbWVzc2FnZS4gIFNob3VsZCB0aGV5 IGJlIGVuY3J5cHRlZCB3aXRoIHRoZSBtdWx0aWNhc3QNCj4+ID4+ID5ncm91cCBjb250ZXh0LCBp biB3aGljaCBjYXNlIHRoZSBtZXNzYWdlIGlkL3Rva2VuIG9uIHRoZSBtZXNzYWdlIGlzDQo+PiA+ PiA+c3VmZmljaWVudCB0byBpZGVudGlmeSB0aGUgY29udGV4dC4gIE9yIHNob3VsZCB0aGV5IGJl IGVuY3J5cHRlZA0KPj4gPj4gPndpdGggYSB1bmljYXN0IGtleSBwYWlyIGJldHdlZW4gdGhlIHJl cGxpZXIgYW5kIHRoZSBvcmlnaW5hbA0KPj5tZXNzYWdlIHNlbmRlcj8NCj4+ID4+ID5UaGlzIGlt cGxpZXMgdGhhdCBzdWNoIGEga2V5IGNvbnRleHQgbmVlZHMgdG8gYmUgc2V0dXAgZm9yIGVhY2gg c3VjaA0KPj4gPj4gPmxpbmsgd2hpY2ggbWF5IG9yIG1heSBub3QgYmUgdGhlIGNhc2UuICBJbiB0 aGlzIGV2ZW50IGl0IG1pZ2h0IGJlDQo+PiA+PiA+bmVjZXNzYXJ5IHRvIGlkZW50aWZ5IHRoZSBj b250ZXh0IHRoYXQgd2FzIHVzZWQgdG8gZW5jcnlwdCB0aGUNCj4+ID4+ID51bmljYXN0IG1lc3Nh Z2UuICBJIGhhdmUgbm90IG1hbmFnZWQgdG8gdGhpbmsgdGhpcyB0aHJvdWdoIGZhcg0KPj5lbm91 Z2guDQo+PiA+PiA+DQo+PiA+PiA+SW4gYW55IGV2ZW50LCB0aGVyZSBhcHBlYXIgdG8gYmUgZW5v dWdoIGNhc2VzIHdoZXJlIHRoZSBlbmNyeXB0aW9uDQo+PiA+PiA+Y29udGV4dCBjYW4gYmUgaW5m ZXJyZWQgZnJvbSB0aGUgbWVzc2FnZSB0byBtYWtlIGl0IHJlYXNvbmFibGUgdG8NCj4+ID4+ID5o YXZlIGEgdmVyc2lvbiBvZiBDT1NFIG1lc3NhZ2VzIHdoaWNoIGRvIG5vdCBoYXZlIGFueSByZWNp cGllbnQNCj4+ID4+ID5pbmZvcm1hdGlvbiBhdHRhY2hlZCB0byB0aGVtLg0KPj4gPj4gPkluIHRo ZSBjYXNlIG9mIHB1cmUgdW5pY2FzdCwgaXQgd291bGQgYmUgdXNlZCBmb3IgYXQgbGVhc3QgNTAl IG9mDQo+PiA+PiA+dGhlIG1lc3NhZ2VzIChhIGhpZ2hlciBwZXJjZW50YWdlIGZvciBvYnNlcnZp bmcgc3RhdGUpLiAgQW5kIGZvcg0KPj4gPj4gPm11bHRpY2FzdCBpdCBtaWdodCBiZSB1c2VkIGVp dGhlciBmb3IgNTAlIG9yIGFsbCBvZiB0aGUgbWVzc2FnZXMNCj4+ID4+ID5kZXBlbmRpbmcgb24g aG93IHJlc3BvbnNlcyBhcmUgaGFuZGxlZC4NCj4+ID4+ID4NCj4+ID4+ID5JIGFtIGludGVyZXN0 ZWQgaW4gcGVvcGxlIGxvb2tpbmcgYXQgbXkgYW5hbHlzaXMgYW5kIHRlbGwgbWUgaWYgSSBhbQ0K Pj4gPj4gPnJpZ2h0LCB3cm9uZyBvciB1bmNsZWFyLg0KPj4gPj4NCj4+ID4+DQo+PiA+PiBUaGVy ZSBhcmUgY2FzZXMgd2hlcmUgb3B0aW1pemVkIG1lc3NhZ2UgYW5kIGNvbnRleHQgaWRlbnRpZmlj YXRpb24NCj4+ID4+YXJlICBuZWVkZWQsIG9yIHdoZXJlIGEgY29udGV4dCBpZGVudGlmaWVyIGNv dWxkIHNpbXBsaWZ5IHRoZQ0KPj4gPj5wcm9jZXNzaW5nLiBJbiBib3RoICBjYXNlcyBhbGxvd2lu ZyBvcHRpb25hbCBoZWFkZXIgaW4gdGhlDQo+PiA+PkNPU0VfZW5jcnlwdGVkIGZvcm1hdCB3b3Vs ZCBzb2x2ZSB0aGUgIHByb2JsZW0uIEZvciByZXBsYXkgcHJvdGVjdGlvbiwNCj4+ID4+c29tZSBj b250ZXh0IGluZm9ybWF0aW9uIHN1Y2ggYXMgc2VxdWVuY2UgIG51bWJlci9ub25jZSBuZWVkcyBh bnl3YXkNCj4+ID4+dG8gYmUgdHJhbnNmZXJyZWQsIHNvIEkgd291bGQgc2F5IHRoYXQgdGhlIGNv bnRleHQgIGNhbm5vdCBiZQ0KPj4gPj5jb21wbGV0ZWx5IGltcGxpY2l0Lg0KPj4gPg0KPj4gPlll cywgc29tZSBpbnB1dCBpbnRvIGFuIElWIG5lZWRzIHRvIGJlIHRyYW5zZmVycmVkLCBidXQgSSB3 b3VsZCBub3QNCj4+ID5jb25zaWRlciB0aGF0IHRvIGJlIHBhcnQgb2YgdGhlIHNhdmVkIGNvbnRl eHQuICAgVGhpcyBpcyBub3QgbmVlZGVkIGZvcg0KPj4gPnJlcGxheSBwcm90ZWN0aW9uIGFzIG11 Y2ggYXMgaXQgaXMgbmVlZGVkIGZvciBtYWtpbmcgc3VyZSB0aGF0IElWcyBhcmUNCj4+ID5ub3Qg cmUtdXNlZC4gIFRoaXMgY291bGQgcG90ZW50aWFsbHkgYmUgZGlmZmVyZW50IGZyb20gdGhlIHNl cXVlbmNlDQo+PiA+bnVtYmVyIHVzZWQgZm9yIHJlcGxheSBwcm90ZWN0aW9uIGJ1dCBnZW5lcmFs bHkgd291bGQgbm90IGJlLg0KPj4gDQo+PiBBZ3JlZS4NCj4+IA0KPj4gPg0KPj4gPkkgd291bGQg ZXhwZWN0IHRoYXQgeW91IHdvdWxkIG5ldmVyIHdhbnQgdG8gc2VuZCBpbmZvcm1hdGlvbiB5b3Ug ZG8gbm90DQo+PiA+aGF2ZSB0byBzaW5jZSBpdCBvbmx5IGFkZHMgc2l6ZS4gIEJ1dCBzdGlsbCB0 cnlpbmcgdG8gZmlndXJlIG91dCB3aGVyZQ0KPj4gPml0IGlzIGFuZCBpcyBub3QgbmVlZGVkIHRv IGhhdmUgYSBjb250ZXh0IGlkZW50aWZpZXIgdG8gYmVnaW4gd2l0aC4NCj4+ID5UaGVuIHdlIGNh biBmaWd1cmUgb3V0IHdoZXJlIGFuZCBpZiBpdCBtYWtlcyBzZW5zZSB0byBpbmNsdWRlIGl0LiAg QnV0DQo+PiA+YXQgdGhhdCBwb2ludCB5b3UgYXJlIGFscmVhZHkgdGFsa2luZyBhYm91dCB0YWtp bmcgc2l6ZSBoaXRzLg0KPj4gDQo+PiBUb2tlbiBjb3VsZCBkb3VibGUgcGxheSBhcyBpbmRpY2F0 aW9uIG9mIGNvbnRleHQgaWRlbnRpZmllciwgYnV0IG5vdA0KPj5hbHdheXMsIG5vdA0KPj4gZm9y IGZyZWUsIGFuZCBhbHNvIG1heSBsZWFkIHRvIHNvbWUgSU1ITyBjb25mdXNpbmcgY29uc3RyYWlu dHMgc3VjaCBhcw0KPj4gZGlmZmVyZW50IG1lc3NhZ2UgZm9ybWF0cyBmb3IgcmVxdWVzdCBhbmQg cmVzcG9uc2UuDQo+PiANCj4+IEFzIEkgdW5kZXJzdG9vZCBvbmUgcmVhc29uIHdoeSBDT1NFX2Vu Y3J5cHRlZCB3YXMgaW50cm9kdWNlZCB3YXMgdG8NCj4+bWVldCBhDQo+PiByZXF1ZXN0IGZvciBh IG1vcmUgY29tcGFjdCBmb3JtYXQgaW4gc2V0dGluZ3Mgd2hlcmUgY29udGV4dCBpcyBhbHJlYWR5 DQo+PiBlc3RhYmxpc2hlZC4gTm90IHNlbmRpbmcgY29udGV4dCBpZGVudGlmaWVyIG1heSBiZSBh biBvcHRpbWl6YXRpb24gaW4NCj4+c29tZQ0KPj4gc2V0dGluZ3MsIGJ1dCB0aGF0IGZvcm1hdCB3 b3VsZCBiZSBvZiBtdWNoIGxlc3MgdXNlIGlmIGEgY29udGV4dA0KPj5pZGVudGlmaWVyIGNhbm5v dA0KPj4gYmUgaW5jbHVkZWQuDQo+PiANCj4+IA0KPj4gR8O2cmFuDQo+DQoNCg== From nobody Thu Sep 17 04:19: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 4FD5A1B2D1B for ; Thu, 17 Sep 2015 04:19:32 -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 CcKkMHebnSMu for ; Thu, 17 Sep 2015 04:19: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 8FCCE1B2CE5 for ; Thu, 17 Sep 2015 04:19: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 t8HBJHBi013877; Thu, 17 Sep 2015 13:19:17 +0200 (CEST) Received: from [192.168.1.109] (p57A63B54.dip0.t-ipconnect.de [87.166.59.84]) (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 3nGwmP2Kv2z26Pg; Thu, 17 Sep 2015 13:19:17 +0200 (CEST) To: =?UTF-8?Q?G=c3=b6ran_Selander?= , Jim Schaad , "ace@ietf.org" References: <007901d0eea4$25989bf0$70c9d3d0$@augustcellars.com> <002b01d0ef07$aced5970$06c80c50$@augustcellars.com> <01b601d0eff2$120843c0$3618cb40$@augustcellars.com> From: Stefanie Gerdes X-Enigmail-Draft-Status: N1110 Message-ID: <55FAA1B1.5020004@tzi.de> Date: Thu, 17 Sep 2015 13:19:13 +0200 User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Ace] Looking at COSE based unicast and multicast 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, 17 Sep 2015 11:19:32 -0000 Hi Jim and G枚ran, I'm still trying to understand which problems you are trying to solve with a context identifier. Here are some problems I can think of: Security association: 1. The client must know if a received message is a response to its request. 2. If the client sends a new request it might want to use the same session keys etc, thus the server must be able to identify if the request belongs to a certain "session". 3. The server needs to know if a received request belongs to an existing context and use the respective keying material etc for its answer. Other: 4. Client and server must be able to identify replayed messages. 5. Revocation of authorization information I don't think we need the context identifier for 1 since CoAP already provides for that. DTLS provides for 2,3 and 4 within a session. I don't think we need more context identifiers for that. For 5 it should be possible to identify the authorization information so that they can be revoked. For DCAF we are planning to include this information in the ticket. In the object security case, an identifier for the "ticket" containing the authorization information might work to address 2, 3 and 5. We might additionally need something to prevent 4. Best regards, Steffi From nobody Thu Sep 17 07:47: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 AB1261A6FA6 for ; Thu, 17 Sep 2015 07:46:59 -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] 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 3M07GhQTOqaB for ; Thu, 17 Sep 2015 07:46:54 -0700 (PDT) Received: from mail2.ihtfp.org (mail2.ihtfp.org [IPv6:2001:4830:143:1::3a11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B69D01A6F99 for ; Thu, 17 Sep 2015 07:46:53 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id BDD92E2035; Thu, 17 Sep 2015 10:46:48 -0400 (EDT) Received: from mail2.ihtfp.org ([127.0.0.1]) by localhost (mail2.ihtfp.org [127.0.0.1]) (amavisd-maia, port 10024) with ESMTP id 22216-03; Thu, 17 Sep 2015 10:46:46 -0400 (EDT) Received: from securerf.ihtfp.org (unknown [128.221.224.68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mocana.ihtfp.org", Issuer "IHTFP Consulting Certification Authority" (verified OK)) by mail2.ihtfp.org (Postfix) with ESMTPS id DA944E2034; Thu, 17 Sep 2015 10:46:45 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ihtfp.com; s=default; t=1442501206; bh=iuNm14nMz2YyDNRf3ZyVZnQg7TsO7vaNkme0/vdHCws=; h=From:To:Cc:Subject:References:Date:In-Reply-To; b=EDkQ7X4iZ2pJyPPo0sJR3YK9aIzB7puSro0RK4/9eCD/Af6cusZNgGSMZx+wTyQdM gJr+oo0IhGC1xnS1feTvSsRV96NdU3KysFgfze7d8SH2VoCf1TAMRw7vJFJWLjOZTo Rsd3uS5kmG+KFre0pmqrIUMDFr44fxUXPR0A3AWI= Received: (from warlord@localhost) by securerf.ihtfp.org (8.14.8/8.14.8/Submit) id t8HEkZND019806; Thu, 17 Sep 2015 10:46:35 -0400 From: Derek Atkins To: Stefanie Gerdes References: <007901d0eea4$25989bf0$70c9d3d0$@augustcellars.com> <002b01d0ef07$aced5970$06c80c50$@augustcellars.com> <01b601d0eff2$120843c0$3618cb40$@augustcellars.com> <55FAA1B1.5020004@tzi.de> Date: Thu, 17 Sep 2015 10:46:34 -0400 In-Reply-To: <55FAA1B1.5020004@tzi.de> (Stefanie Gerdes's message of "Thu, 17 Sep 2015 13:19:13 +0200") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Virus-Scanned: Maia Mailguard 1.0.2a Archived-At: Cc: Jim Schaad , =?utf-8?Q?G=C3=B6ran?= Selander , "ace@ietf.org" Subject: Re: [Ace] Looking at COSE based unicast and multicast 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, 17 Sep 2015 14:46:59 -0000 If you really NEED a context you could just insert one into one of the headers, protected or unprotected depending. You could, for example, use the Key ID (kid) header. -derek Stefanie Gerdes writes: > Hi Jim and G=C3=B6ran, > > I'm still trying to understand which problems you are trying to solve > with a context identifier. Here are some problems I can think of: > > Security association: > 1. The client must know if a received message is a response to its reques= t. > 2. If the client sends a new request it might want to use the same > session keys etc, thus the server must be able to identify if the > request belongs to a certain "session". > 3. The server needs to know if a received request belongs to an existing > context and use the respective keying material etc for its answer. > Other: > 4. Client and server must be able to identify replayed messages. > 5. Revocation of authorization information > > I don't think we need the context identifier for 1 since CoAP already > provides for that. DTLS provides for 2,3 and 4 within a session. I don't > think we need more context identifiers for that. > > For 5 it should be possible to identify the authorization information so > that they can be revoked. For DCAF we are planning to include this > information in the ticket. > > In the object security case, an identifier for the "ticket" containing > the authorization information might work to address 2, 3 and 5. We might > additionally need something to prevent 4. > > Best regards, > Steffi > > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace --=20 Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From nobody Thu Sep 17 08: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 3C09A1A87BA for ; Thu, 17 Sep 2015 08:03:14 -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 Eg8LzxVhMEzm for ; Thu, 17 Sep 2015 08:03:12 -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 A86F81A8838 for ; Thu, 17 Sep 2015 08:03:10 -0700 (PDT) Received: from [192.168.10.183] ([134.76.0.127]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0LaKaw-1YsqN12dH4-00m1oI; Thu, 17 Sep 2015 17:02:53 +0200 To: Derek Atkins , Stefanie Gerdes References: <007901d0eea4$25989bf0$70c9d3d0$@augustcellars.com> <002b01d0ef07$aced5970$06c80c50$@augustcellars.com> <01b601d0eff2$120843c0$3618cb40$@augustcellars.com> <55FAA1B1.5020004@tzi.de> From: Hannes Tschofenig Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9 Message-ID: <55FAD618.8080304@gmx.net> Date: Thu, 17 Sep 2015 17:02:48 +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="vETHlTWERljMNEWhWAtt9B9f1j76vFSF8" X-Provags-ID: V03:K0:9r56TRBxRj2b49YCbgzO9sYfSuk4oSuho95KJ/D5/Pz7nMpNFgS y9SRtr2Kj2BY3RRh04iySdm7eM0g2ExT68F+Ti/GWDlyYn4EZbOT48H0xDY0Xz+2XJVpoud huEBIrqHpfLeuPqmt6BCiIi01sAqz5MrNCZXdqSZkbjd9EhhwWoHrIvPRWmoKw7JP2/mxz/ fAUkTjMOjfeDYu59s4giQ== X-UI-Out-Filterresults: notjunk:1;V01:K0:5saWa4pWXv8=:VVjR6zV6srf+QisI1Kki4z tvgUNFPukLaunjArpmdFQ7DBo8WmhSIPau9jX1gNR5ZkKRqnKSNm3qfNBAz3f1HxvkLlaTcWM g+G0sA8kA0/v4rWbSrCGN+NUQka7PrbbRHzIwU0O1dSURkWHuDaqOCzKeIROSK1U8XFmwz7+x ZZlSpK4AauiNQCSmRwQO4Ddp78gUfmWgDdgmoynGhdXjL2Z017ivA2p81MPucb30sxsb/hcbI Ds9laC+b5Bum44lhWaRXwql0ZrCQ2vXZDf1Kn+wZUUB1KBTdmrqNQFKdOf+apG6QQMTV0tRw7 qg4EfJz08nKULmTzT4YSv9wrTNh2ZqiSK4s6So4pav6v3O5UFOR9okR3sExjvTOtdAcjw7E/0 5jDpMsNbe0QJ8qFFGaeVGw/mgkYemCFpYNC7HsO3Fm9AL+/nfnNU2rs/bLyGQQAzl9bNX/X2t R+T4kllA0gUwfTiV2hGLBZ6TLeVCwOFAOvRNr5Hw6fUra9N8ODSJ4KnPeacsoM7R2zWN60z59 JYBznmYMZfmPoDMoYCt3xQIqLIYBNMsCcXNrufTVVXP2VrSNJz8aKqTc24GhywoqmpKj1o45x YUpv2jhpOSCewtdmqAZONVCMQ79y+thEjWJvs0tQDVYJ/il0r/cYpnI2X9mHj7izXPopghePq rSvWxUvOAOriSPrPu9I6lcXnUrVtNowtPht+oFni5aq5X+VEjoLNCIBhQmyUx3aZ4Mp5Da+WL ExBd9FbXumYI5gxs Archived-At: Cc: Jim Schaad , =?UTF-8?Q?G=c3=b6ran_Selander?= , "ace@ietf.org" Subject: Re: [Ace] Looking at COSE based unicast and multicast 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, 17 Sep 2015 15:03:14 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --vETHlTWERljMNEWhWAtt9B9f1j76vFSF8 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Correct. This is what is typically done. Example: With IKEv2 the security context is established and in IPsec AH/ESP packets you find this key id in the form of an SPI. On 09/17/2015 04:46 PM, Derek Atkins wrote: > If you really NEED a context you could just insert one into one of the > headers, protected or unprotected depending. You could, for example, > use the Key ID (kid) header. >=20 > -derek --vETHlTWERljMNEWhWAtt9B9f1j76vFSF8 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 iQEcBAEBCgAGBQJV+tYYAAoJEGhJURNOOiAtRc4IAI1HlNMkuoXOeG/u65B+fDTm nZtL9RQbdMHZvEJJ+2FH616vcV8JTJzvq/1XZ1C3Sx/t4WQayh6qLCY8PtKMmpgR aU9kPIKZRB0XvuPyhYbp9cqjuyVMqzZ4giXmwzHwbsBtOEhGt9LbeXhN3l81cuty THOv/0a+cO5mXzBoASUPS8Imoj+luH5WBib/mK4B8ze6+sInEVMwrY+YSD9wuvzM 0aTYgGeryKleBZcfWP3XJ76yyt/BYpgHWZlojYhPHp/a/OnY9O9JhGyhDmSjhnc4 36oIcl1VKcEp1txSb70J5Ia2uHrxrV4PK5lNwylyuWMjqBQ97n9b1LjupWQMpQw= =tAjC -----END PGP SIGNATURE----- --vETHlTWERljMNEWhWAtt9B9f1j76vFSF8-- From nobody Thu Sep 17 10:42: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 6EB251B2EFD for ; Thu, 17 Sep 2015 10:42:52 -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 s5EvVsLH7xxd for ; Thu, 17 Sep 2015 10:42:51 -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 7BB971B2EE7 for ; Thu, 17 Sep 2015 10:42:50 -0700 (PDT) X-AuditID: c1b4fb25-f79a26d00000149a-32-55fafb98696a Received: from ESESSHC016.ericsson.se (Unknown_Domain [153.88.183.66]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id F3.61.05274.89BFAF55; Thu, 17 Sep 2015 19:42:48 +0200 (CEST) Received: from ESESSMB303.ericsson.se ([169.254.3.214]) by ESESSHC016.ericsson.se ([153.88.183.66]) with mapi id 14.03.0248.002; Thu, 17 Sep 2015 19:42:37 +0200 From: =?utf-8?B?R8O2cmFuIFNlbGFuZGVy?= To: Hannes Tschofenig , Derek Atkins , Stefanie Gerdes Thread-Topic: [Ace] Looking at COSE based unicast and multicast Thread-Index: AdDuo/sorjKxXnJSQaGX5o+dQpuhBgALnjSAAAkdOYAAIeyMAAAYrAEAAE80AwAAAvPwgAALciOU///i5gCAAE4tAA== Date: Thu, 17 Sep 2015 17:42:36 +0000 Message-ID: References: <007901d0eea4$25989bf0$70c9d3d0$@augustcellars.com> <002b01d0ef07$aced5970$06c80c50$@augustcellars.com> <01b601d0eff2$120843c0$3618cb40$@augustcellars.com> <55FAA1B1.5020004@tzi.de> <55FAD618.8080304@gmx.net> In-Reply-To: <55FAD618.8080304@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.150] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrLIsWRmVeSWpSXmKPExsUyM2K7k+6M379CDZ4f1LD4/q2H2WLlpB3s Fhsv3mW0WLrzHqvF6unf2RxYPTbOmc7msXjTfjaPJUt+Mnks//qAxWPb26/MAaxRXDYpqTmZ ZalF+nYJXBmrf91nKjjEVtH+oIG9gXENWxcjJ4eEgInE8+6tULaYxIV764FsLg4hgSOMErdP NrFCOEsYJRasvcEOUsUm4CLxoOERE4gtIlAi8fPnarBuZgE3iUMTF4HFhQXsJG59vsUCUWMv 8fdAP5SdJTGr5QpQPQcHi4CqRPsdsJG8AhYSLy/cY4HYNYVZ4vbZ+WA1nALqEl+m24LUMAId 9/3UGiaIVeISt57MZ4I4WkBiyZ7zzBC2qMTLx/9YQWxRAT2JldeboB5Tklix/RIjyEhmAU2J 9bv0IcZYSzTvnwt1vaLElO6HUOcISpyc+YRlAqPELCTbZiF0z0LSPQtJ9ywk3QsYWVcxihan FiflphsZ66UWZSYXF+fn6eWllmxiBMbvwS2/VXcwXn7jeIhRgINRiYf3QdivUCHWxLLiytxD jNIcLErivM1MD0KFBNITS1KzU1MLUovii0pzUosPMTJxcEo1MFb9PPj91L6fRR4z7kYnr9rT 7K+Y8v7yRaaXiXIMh/l/HZ6l8pzpRt0e43ncAgsPPn77eOVs/a+N/nMXhTorP52+z9cwT6Iu 0XV6yMNE56rWpMtsQbKT93/mXVSqasin/dpoj37X26mnc3g99068t0aXlePfdoG5D+b9z1gk +/GD+dL5kQb7T3IqsRRnJBpqMRcVJwIANfKqfcACAAA= Archived-At: Cc: Jim Schaad , "ace@ietf.org" Subject: Re: [Ace] Looking at COSE based unicast and multicast 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, 17 Sep 2015 17:42:52 -0000 UmlnaHQuIEFuZCB0aGF04oCZcyBleGFjdGx5IHdoYXQgSSB3YW50IHRvIGRvIGluIHRoZSBtb3Jl IGNvbXBhY3QNCkNPU0VfZW5jcnlwdGVkIG1lc3NhZ2UgZm9ybWF0Lg0KDQpPbiAyMDE1LTA5LTE3 IDE3OjAyLCAiSGFubmVzIFRzY2hvZmVuaWciIDxoYW5uZXMudHNjaG9mZW5pZ0BnbXgubmV0PiB3 cm90ZToNCg0KPkNvcnJlY3QuIFRoaXMgaXMgd2hhdCBpcyB0eXBpY2FsbHkgZG9uZS4gRXhhbXBs ZTogV2l0aCBJS0V2MiB0aGUNCj5zZWN1cml0eSBjb250ZXh0IGlzIGVzdGFibGlzaGVkIGFuZCBp biBJUHNlYyBBSC9FU1AgcGFja2V0cyB5b3UgZmluZA0KPnRoaXMga2V5IGlkIGluIHRoZSBmb3Jt IG9mIGFuIFNQSS4NCj4NCj5PbiAwOS8xNy8yMDE1IDA0OjQ2IFBNLCBEZXJlayBBdGtpbnMgd3Jv dGU6DQo+PiBJZiB5b3UgcmVhbGx5IE5FRUQgYSBjb250ZXh0IHlvdSBjb3VsZCBqdXN0IGluc2Vy dCBvbmUgaW50byBvbmUgb2YgdGhlDQo+PiBoZWFkZXJzLCBwcm90ZWN0ZWQgb3IgdW5wcm90ZWN0 ZWQgZGVwZW5kaW5nLiAgWW91IGNvdWxkLCBmb3IgZXhhbXBsZSwNCj4+IHVzZSB0aGUgS2V5IElE IChraWQpIGhlYWRlci4NCj4+IA0KPj4gLWRlcmVrDQo+DQoNCg== From nobody Thu Sep 17 10:55: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 1CA711B300F for ; Thu, 17 Sep 2015 10:55:32 -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 4I1bGRjSGyEW for ; Thu, 17 Sep 2015 10:55:30 -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 3E0041B2FE6 for ; Thu, 17 Sep 2015 10:55:30 -0700 (PDT) X-AuditID: c1b4fb30-f79626d000006adf-f8-55fafe90bfc4 Received: from ESESSHC023.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 02.17.27359.09EFAF55; Thu, 17 Sep 2015 19:55:28 +0200 (CEST) Received: from ESESSMB303.ericsson.se ([169.254.3.214]) by ESESSHC023.ericsson.se ([153.88.183.87]) with mapi id 14.03.0248.002; Thu, 17 Sep 2015 19:55:27 +0200 From: =?utf-8?B?R8O2cmFuIFNlbGFuZGVy?= To: Stefanie Gerdes , Jim Schaad , "ace@ietf.org" Thread-Topic: [Ace] Looking at COSE based unicast and multicast Thread-Index: AdDuo/sorjKxXnJSQaGX5o+dQpuhBgALnjSAAAkdOYAAIeyMAAAYrAEAAE80AwAAAvPwgAASB3yA Date: Thu, 17 Sep 2015 17:55:27 +0000 Message-ID: References: <007901d0eea4$25989bf0$70c9d3d0$@augustcellars.com> <002b01d0ef07$aced5970$06c80c50$@augustcellars.com> <01b601d0eff2$120843c0$3618cb40$@augustcellars.com> <55FAA1B1.5020004@tzi.de> In-Reply-To: <55FAA1B1.5020004@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: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupmkeLIzCtJLcpLzFFi42KZGfG3RnfCv1+hBmuOyFl8/9bDbLHx4l1G i9XTv7M5MHtsnDOdzWPJkp9MHtvefmUOYI7isklJzcksSy3St0vgyuh/H1fwR6iiYd4i9gbG PUJdjJwcEgImEkdeL2GBsMUkLtxbzwZiCwkcZZQ4vD8Dwl7CKPEaIs4m4CLxoOERE4gtIpAp 8fHeTrC4sICdxK3Pt1gg4vYSfw/0Q9lREl2LZwLVcHCwCKhKvL+kCRLmFbCQuLLhCmMXIxfQ +EtMEq++bmQFSXAKqEkcm34bzGYEuuf7qTVgu5gFxCVuPZnPBHGngMSSPeeZIWxRiZeP/4HV iwroSay83sQGEVeSWHt4OwvIXmYBTYn1u/QhxlhLzF28lR3CVpSY0v2QHeIeQYmTM5+wTGAU n4Vk2yyE7llIumch6Z6FpHsBI+sqRtHi1OKk3HQjI73Uoszk4uL8PL281JJNjMDYO7jlt8EO xpfPHQ8xCnAwKvHwPgj7FSrEmlhWXJl7iFGag0VJnLeZ6UGokEB6YklqdmpqQWpRfFFpTmrx IUYmDk6pBkaOxnoxE5k7Eu6v/f81xBxdlpLgq6Gt8tVI8MisB21fmi6xv/mUeCNscsjmY41f 37zpyL3G/nr7hZefnHftz+e9O9fip/L6+acmeu+pjkjne18VOvPYkVYdZ64F940/T3vsm7it yf7DqgknepKXeFkd+3Pu5iknfsY/sR7afTeM5q/aF3MgbtlrJZbijERDLeai4kQAXI1Clp4C AAA= Archived-At: Subject: Re: [Ace] Looking at COSE based unicast and multicast 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, 17 Sep 2015 17:55:32 -0000 SGkgU3RlZmZpLCANCg0KSGVyZSBpcyBvbmUgZXhhbXBsZTogQ29BUCBzZXJ2ZXIgc2VydmluZyBt dWx0aXBsZSBjbGllbnRzLCAoZm9yd2FyZCkgcHJveHkNCmJldHdlZW4gY2xpZW50cyBhbmQgc2Vy dmVyLiBEVExTIGRvZXNu4oCZdCBnaXZlIGVuZC10by1lbmQgc2VjdXJpdHksIHNvIHdlDQp1c2Ug b2JqZWN0IHNlY3VyaXR5LiBIb3cgZG9lcyB0aGUgc2VydmVyIGtub3cgZnJvbSB3aGljaCBjbGll bnQgdGhlDQpyZXF1ZXN0IGNvbWVzIGZyb20/IE9uZSB3YXkgaXMgdG8gaGF2ZSBhbiBpZGVudGlm aWVyIGlkZW50aWZ5aW5nIHNvbWV0aGluZw0KbGlrZSBjbGllbnQva2V5L2NvbnRleHQvdG9rZW4v dGlja2V0L2V0Yy4NCg0KSG9wZSB0aGF0IGhlbHBzLA0KR8O2cmFuDQoNCg0KDQoNCk9uIDIwMTUt MDktMTcgMTM6MTksICJTdGVmYW5pZSBHZXJkZXMiIDxnZXJkZXNAdHppLmRlPiB3cm90ZToNCg0K PkhpIEppbSBhbmQgR8O2cmFuLA0KPg0KPkknbSBzdGlsbCB0cnlpbmcgdG8gdW5kZXJzdGFuZCB3 aGljaCBwcm9ibGVtcyB5b3UgYXJlIHRyeWluZyB0byBzb2x2ZQ0KPndpdGggYSBjb250ZXh0IGlk ZW50aWZpZXIuIEhlcmUgYXJlIHNvbWUgcHJvYmxlbXMgSSBjYW4gdGhpbmsgb2Y6DQo+DQo+U2Vj dXJpdHkgYXNzb2NpYXRpb246DQo+MS4gVGhlIGNsaWVudCBtdXN0IGtub3cgaWYgYSByZWNlaXZl ZCBtZXNzYWdlIGlzIGEgcmVzcG9uc2UgdG8gaXRzDQo+cmVxdWVzdC4NCj4yLiBJZiB0aGUgY2xp ZW50IHNlbmRzIGEgbmV3IHJlcXVlc3QgaXQgbWlnaHQgd2FudCB0byB1c2UgdGhlIHNhbWUNCj5z ZXNzaW9uIGtleXMgZXRjLCB0aHVzIHRoZSBzZXJ2ZXIgbXVzdCBiZSBhYmxlIHRvIGlkZW50aWZ5 IGlmIHRoZQ0KPnJlcXVlc3QgYmVsb25ncyB0byBhIGNlcnRhaW4gInNlc3Npb24iLg0KPjMuIFRo ZSBzZXJ2ZXIgbmVlZHMgdG8ga25vdyBpZiBhIHJlY2VpdmVkIHJlcXVlc3QgYmVsb25ncyB0byBh biBleGlzdGluZw0KPmNvbnRleHQgYW5kIHVzZSB0aGUgcmVzcGVjdGl2ZSBrZXlpbmcgbWF0ZXJp YWwgZXRjIGZvciBpdHMgYW5zd2VyLg0KPk90aGVyOg0KPjQuIENsaWVudCBhbmQgc2VydmVyIG11 c3QgYmUgYWJsZSB0byBpZGVudGlmeSByZXBsYXllZCBtZXNzYWdlcy4NCj41LiBSZXZvY2F0aW9u IG9mIGF1dGhvcml6YXRpb24gaW5mb3JtYXRpb24NCj4NCj5JIGRvbid0IHRoaW5rIHdlIG5lZWQg dGhlIGNvbnRleHQgaWRlbnRpZmllciBmb3IgMSBzaW5jZSBDb0FQIGFscmVhZHkNCj5wcm92aWRl cyBmb3IgdGhhdC4gRFRMUyBwcm92aWRlcyBmb3IgMiwzIGFuZCA0IHdpdGhpbiBhIHNlc3Npb24u IEkgZG9uJ3QNCj50aGluayB3ZSBuZWVkIG1vcmUgY29udGV4dCBpZGVudGlmaWVycyBmb3IgdGhh dC4NCj4NCj5Gb3IgNSBpdCBzaG91bGQgYmUgcG9zc2libGUgdG8gaWRlbnRpZnkgdGhlIGF1dGhv cml6YXRpb24gaW5mb3JtYXRpb24gc28NCj50aGF0IHRoZXkgY2FuIGJlIHJldm9rZWQuIEZvciBE Q0FGIHdlIGFyZSBwbGFubmluZyB0byBpbmNsdWRlIHRoaXMNCj5pbmZvcm1hdGlvbiBpbiB0aGUg dGlja2V0Lg0KPg0KPkluIHRoZSBvYmplY3Qgc2VjdXJpdHkgY2FzZSwgYW4gaWRlbnRpZmllciBm b3IgdGhlICJ0aWNrZXQiIGNvbnRhaW5pbmcNCj50aGUgYXV0aG9yaXphdGlvbiBpbmZvcm1hdGlv biBtaWdodCB3b3JrIHRvIGFkZHJlc3MgMiwgMyBhbmQgNS4gV2UgbWlnaHQNCj5hZGRpdGlvbmFs bHkgbmVlZCBzb21ldGhpbmcgdG8gcHJldmVudCA0Lg0KPg0KPkJlc3QgcmVnYXJkcywNCj5TdGVm ZmkNCg0K From nobody Thu Sep 17 11:07: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 B457F1B2FE6 for ; Thu, 17 Sep 2015 11:07:07 -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 XAUTge-tYZKH for ; Thu, 17 Sep 2015 11:07:06 -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 22CC81B2D52 for ; Thu, 17 Sep 2015 11:07:05 -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 t8HI6x52003679; Thu, 17 Sep 2015 20:06:59 +0200 (CEST) Received: from [192.168.1.109] (p57A63B54.dip0.t-ipconnect.de [87.166.59.84]) (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 3nH5pq0N27z1wtx; Thu, 17 Sep 2015 20:06:58 +0200 (CEST) To: =?UTF-8?Q?G=c3=b6ran_Selander?= , Jim Schaad , "ace@ietf.org" References: <007901d0eea4$25989bf0$70c9d3d0$@augustcellars.com> <002b01d0ef07$aced5970$06c80c50$@augustcellars.com> <01b601d0eff2$120843c0$3618cb40$@augustcellars.com> <55FAA1B1.5020004@tzi.de> From: Stefanie Gerdes X-Enigmail-Draft-Status: N1110 Message-ID: <55FB0142.5030303@tzi.de> Date: Thu, 17 Sep 2015 20:06:58 +0200 User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Ace] Looking at COSE based unicast and multicast 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, 17 Sep 2015 18:07:07 -0000 Hi G枚ran, On 09/17/2015 07:55 PM, G枚ran Selander wrote: > Hi Steffi, > > Here is one example: CoAP server serving multiple clients, (forward) proxy > between clients and server. DTLS doesn鈥檛 give end-to-end security, so we > use object security. How does the server know from which client the > request comes from? One way is to have an identifier identifying something > like client/key/context/token/ticket/etc. Thank you for the example. Okay, so you are only discussing the object security solution part. I guess your example refers to item 3 in the list I send: The server needs to know if a received request belongs to an existing context and use the respective keying material etc for its answer? Sounds reasonable to me that we would need some kind of identifier for that. Is that what you were discussing about? Best regards, Steffi From nobody Thu Sep 17 14:40: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 85B311A1B2C for ; Thu, 17 Sep 2015 14:40:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.3 X-Spam-Level: X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, 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 9ZYhgvJ_-M4e for ; Thu, 17 Sep 2015 14:40:21 -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 557F21A1A6E for ; Thu, 17 Sep 2015 14:40:21 -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 57ADA2C9EF; Thu, 17 Sep 2015 14:40:20 -0700 (PDT) From: "Jim Schaad" To: =?utf-8?Q?'G=C3=B6ran_Selander'?= , References: <007901d0eea4$25989bf0$70c9d3d0$@augustcellars.com> <002b01d0ef07$aced5970$06c80c50$@augustcellars.com> <01b601d0eff2$120843c0$3618cb40$@augustcellars.com> In-Reply-To: Date: Thu, 17 Sep 2015 14:37:57 -0700 Message-ID: <011601d0f191$20058910$60109b30$@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: AQGGfwiYLGVnvC1rumdUoUJ+HdJvIQI0bA87AfbgWScBfoJsqwHO/VvxAgmfnt6eigrfEA== Archived-At: Subject: Re: [Ace] Looking at COSE based unicast and multicast 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, 17 Sep 2015 21:40:25 -0000 > -----Original Message----- > From: G=C3=B6ran Selander [mailto:goran.selander@ericsson.com] > Sent: Thursday, September 17, 2015 12:55 AM > To: Jim Schaad ; ace@ietf.org > Subject: Re: [Ace] Looking at COSE based unicast and multicast >=20 > Jim, >=20 > I think we are arguing from fixed positions. I must be slipping - normally I argue from about 5 or 6 positions at the = same time. >=20 > COSE_Encrypted format, without mandatory recipient structure, is a = good step > towards a more optimized format. The main disagreement seems to be on = the > option to use a context identifier in the header. That is not really the focus of what I am trying to do right now. I am = mostly responding to your comments about this saying it is not fixed = yet. I want to try and figure out what information is already = available, what information has to be transmitted in what messages, what = are the scenarios that I don't understand at this point in time that = change the information that is running around already. This means that = I have outlined why I don't think that context identification is = required on a number of places. A response of - but it would be nice to = have - is not helping me understand the real problem of when it is = required and when it can be inferred. This is part of why I am trying to see a solid, and complete, = architecture document that covers as much as possible. Understanding = what needs to be done and who is going to talk to whom is difficult if = it is not in a single (or very small number) of documents that can read. >=20 > We would like to apply this optimized format also to symmetric = encryption > + asymmetric signature, as well as integrity protection only (only one > signature/MAC). All these could be one common format. Being only slightly snarky - it sounds as though you should write a = competing COSE proposal that can be thoroughly discussed since you = apparently do not like the one that I have put forward. =20 >=20 >=20 > Comments inline. >=20 >=20 >=20 > On 2015-09-15 22:06, "Jim Schaad" wrote: >=20 > > > > > >> -----Original Message----- > >> From: G=C3=B6ran Selander [mailto:goran.selander@ericsson.com] > >> Sent: Monday, September 14, 2015 11:20 PM > >> To: Jim Schaad ; ace@ietf.org > >> Subject: Re: [Ace] Looking at COSE based unicast and multicast > >> > >> Comments inline. > >> > >> My summary: > >> > >> The request in general needs a context identifier. Your proposal is > >>to use the COSE_enveloped format, my proposal is to allow an = optional > >>context identifier in the COSE_encrypted format, which is more > >>compact. > >> > >> If you associate the CoAP Token of a request to the context then = you > >>can use that as an index for context identifier in the response and > >>hence use COSE_encrypted. But now you have two parameters that > >>perform a similar > >> task: Token and Context Identifier, and which both has to be > >>transferred in a request. The Token field is variable length 0-8 > >>bytes. Since we cannot attribute any end-to-end security properties > >>of Token, the object security scheme is made independent of how the > >>Token is set, analogously to the case in DTLS. > >>By instead > >> relying on Token to avoid collisions we may need a larger Token. > > > >There is no need to explicitly protect the context identifier. It is > >implicitly protected as the message will fail to validate if you use > >the wrong context. This means that it is protected even if it is not > >part of the message properties. Having the context identified by the = token is > >totally legitimate and totally secure. In the case of unicast DTLS, > >there is no explicit context identifier anywhere. It is totally = based > >on the four-tuple of addresses and ports. This has zero = cryptographic > >security applied to these values, the security is totally implicit. >=20 > I don=E2=80=99t claim that omitting the context identifier is = insecure. But it is not always > feasible e.g. in requests, and it has impact on processing and size of = other > parameters such as CoAP Token. I don't understand what you are trying to say. It does not make any = sense to me. >=20 >=20 > > > >> > >> I=E2=80=99m not convinced with the difference between how the = message is > >>formatted depending on whether it is a request or response. A given > >>node may send the same resource representation as PUT request or = GET > >>response and thus would use different COSE message formats. > > > >Given that the COSE message representation is going to have to be = built > >uniquely for each message sent, I don't know that this is a problem. > >How the COSE is created is based on the http-like operation that is > >being used. This will be well understood when it occurs and when it > >does not occur. >=20 > It is possible to use different COSE formats for request and response = but in the > case I mentioned when the same resource representation for potentially = the > same comsumer is using a different format and of different size = depending on > whether it is PUT request or GET response, that just doesn=E2=80=99t = sound like a good > idea. Are you planning to build these at the same time? Are you not going to = have any other differences in the data than just the content of the = encrypted message. I don't understand why you think this is a big = argument. I don't know how much you are planning to keep this = information around on the system and send it under different operations. = I just don't understand why this is a problem >=20 > > > >> > >> > >> It is also a matter of how the received COSE object will be > >>subsequently used. > >> For example, in Information-Centric Networking, if I=E2=80=99m not = mistaken, > >>one of the requirements is that each protected object has a = globally > >>unique name. > >>By > >> shifting focus from a context identifier within the COSE object to > >>Token which is ephemeral data outside the COSE object, ICN > >>applications would always have to use the less compact format. > > > >If you are correct, and the unique name is always known to both > >parties, then it is quite possible that you have a situation where = the > >context information can always be implicit and would not need to be > >carried at all. >=20 > As far as I understand ICN I believe the name should be bound / = possible to > derive from the information object. But we could leave this to the ICN = experts to > comment on. I just note that there may be a significance whether = identification > is provided by the object itself or if it requires additional data = (such as Token and > URI). >=20 Yes - but understanding what can and cannot be relied on will affect our = discussions and thus needs to be determined. Are there ICN experts on = this list? > > > >> > >> I think we agree that some parameter(s) for replay protection/IV > >>uniqueness is needed in request and response, so would be in the > >>header of both COSE_enveloped and COSE_encrypted. > > > >I have already said this is true, and it is content related so it = fits > >the current COSE model. >=20 > If I understand right, this is about the content / recipient paradigm. >=20 > Another way to think of this is in terms of sender, which is what we = use context > identifier for. > If the sender context is identified, each recipient can find out for = itself if and > how to make use of the object. One important assumption is that the = sender > does not have to know anything about the recipient. The sender could = rely on a > trusted third party, to provide it with the right security context it = will use, and > which also will interact with the recipient. Yes from my point of view this is a purity discussion - it is also not = one that needs to be made yet. >=20 >=20 > >However, there is an interesting question if you want this in the = COSE > >world or in the CoAP world and just protect it in COSE. Having two > >different replay protection systems in place may be overkill. >=20 > The sequence number etc. should be protected in COSE. As far as I = understand, > the only place to for sequence number etc. in COSE_encrypted is in the = header. > But the verification of replay protection belongs to the application. = Different > replay protection mechanisms may be used depending on application, = e.g. > sliding window or strict order. No - please look at the externally suppled data in the COSE spec. >=20 > Was this what you were referring to? >=20 >=20 > G=C3=B6ran >=20 >=20 > > > >> > >> > >> G=C3=B6ran > >> > >> > >> > >> On 2015-09-14 18:09, "Jim Schaad" wrote: > >> > >> > > >> > > >> >> -----Original Message----- > >> >> From: G=C3=B6ran Selander [mailto:goran.selander@ericsson.com] > >> >> Sent: Monday, September 14, 2015 2:48 AM > >> >> To: Jim Schaad ; ace@ietf.org > >> >> Subject: Re: [Ace] Looking at COSE based unicast and multicast > >> >> > >> >> > >> >> > >> >> On 2015-09-14 06:16, "Jim Schaad" = wrote: > >> >> > >> > > >> > > >> >> > > >> >> >>From this, it seems to me that does support the position that > >> >> >>some > >> >> >information about context needs to be passed on the initial = message. > >> >> >Depending on how this is presented I would expect this to be = done > >> >> >with the current COSE encrypted message structure. It is > >> >> >potentially different in the case where the client is being = used > >> >> >to relay information to the server about the authorization = information. > >> >> > >> >> Using the current COSE encrypted message structure is not > >> >> addressing the concerns about message size as has been discussed > previously. > >> >> From the proposed ACE architecture I can reference two = categories > >> >> of > >> formats: > >> >> > >> >> 1. One category which assumes that there is essentially only a > >> >>=E2=80=9Cbase key=E2=80=9D > >> >> established between sender and receiver, and where the message > >> >>provides means to derive the security context to use with the > >>message. > >> >> > >> >> 2. Another category which is highly optimized for the setting = that > >> >>the security context is available at the receiver. > >> >> > >> >> > >> >> I think the distinction between COSE_Enveloped and = COSE_Encrypted > >> >>structure is a good step in the right direction, but the latter > >> >>should allow for the desired identification and optimization for > >> >>the most common settings. Something > >> >>like: > >> >> > >> >> [ message type, protected headers, cipher text, tag ] > >> >> > >> >> > >> >> where protected headers can identify the security context and = the > >> >> nonce/sequence number. > >> >> > >> >> In fact, to get replay protection of request, and of response if > >> >>no prior request bound to the response, one of the fields in the > >> >>protected header must be nonce/sequence number/timestamp, right? > >> >>Thus the format would anyway carry some information about = security > >> >>context. It seems odd to not allow an identifier of what context > >> >>this nonce/etc. refers to. > >> >> > >> >> > >> >> > > >> >> >The response does not appear to need a context identifier as > >> >> >there is already information in the CoAP message that can be = used > >> >> >for determining the context. > >> >> > >> >> >Specifically the Token and Message ID fields can be used to > >> >> >associate requests and responses. > >> >> > >> >> Message ID is not a reliable identifier for associating request = to > >> >>response. > >> > > >> >First, please note that I said both Token and Message ID. Are = there > >> >cases that between these two fields the request and the response > >> >cannot be associated? > >> > >> I don=E2=80=99t see how Message ID adds anything. Compare figures 5 = and 6 of > >>RFC7252. > >> I believe matching CoAP Token in request and response would be > >>sufficient, although the Token in itself can=E2=80=99t be integrity = protected > >>in transfer since it may be changed by a proxy. > >> > >> > > >> >> > >> >> > This means that a client can use this to determine what = context > >> >> >was used by the server to encrypt the message that was = returned. > >> >> >(Specifically, the same context and the client used to encrypt > >> >> >the > >> >> >request.) > >> >> > >> >> The context may be different for request and response, and = always > >> >> is in OSCOAP. > >> > > >> >Please note that I am using context in the same way that TLS uses > >> >this term. This means that the information is going to be = different > >> >for the two directions, but the context identifies a single set of = information. > >> > > >> >I don't see anything called OSCOAP in either core or ace. > >> > >> Sorry, abbreviation for the ACE draft "Object Security for CoAP" > >> > >> > > >> >> > >> >> > >> >> > This means that we can say that there is an implicit context = for > >> >> >encrypted messages in this case the new encryption structure = w/o > >> >> >recipients would make sense. This analysis would apply to the > >> >> >observe dialog structure as well, the token can be used to > >> >> >associate all items in the same context. > >> >> > >> >> Even if there are cases where leaving out context in response > >> >>could be performed, I think it should be allowed to specify > >> >>context as an > >>option. > >> >> This would also relieve the settings where multiple contexts = needs > >> >>to be tried. > >> > > >> >Please identify situations where multiple contexts would need to = be > >> >tried. I have only come up with one so far, assuming that one is > >> >going to use distinct address/port pairs for the multi-cast case. > >> >That would be the case of subscribing. > >> > >> Another case is Token collisions. > >> > >> > > >> >> > >> >> > > >> >> >For a subscription model to a third party, there are a couple = of > >> >> >different ways to look at how it can be setup. The big = question > >> >> >is if the context is going to be unique to the originator, or = it > >> >> >is unique to the subscription. > >> >> >In either case, the client is going to end up using two = different > >> >> >contexts in this situation. The first case is for setting up = the > >> >> >original subscription. In that case a context associated with > >> >> >the data storage server is going to be needed. However, once > >> >> >information starts flowing back to the client from the data > >> >> >storage service, the context associated with the origination > >> >> >server is going to be used. It is not clear that the action of > >> >> >doing the subscription would need to be encrypted, this > >> >> >simplified things as only one encryption context is now needed. > >> >> >Otherwise either two contexts need to be tried, or the type of > >> >> >message needs to be known so that the client understand where = the > >> >> >encrypted content > >>originates. > >> >> > >> >> The data store need not be trusted. Information about binding > >> >>between different contexts needs to be obtained from a trusted > >> >>party, such as the authorization server. I believe the presence = of > >> >>a context identifier would simplify the processing where this = type > >> >>of binding needs to be established after the message has been > >> >>received, compared to the case of receiving an encrypted = structure > >> >>without any handle whatsoever. > >> > > >> >In my analysis I did not make any assumptions that the data store > >> >was trusted to do anything more than its assigned job. I did not > >> >make any assumptions that it would do cryptography except for > >> >messages sent directly to it. > >> > >> Fair enough. I triggered on "the client is going to end up using = two > >>different contexts in this situation=E2=80=9D, but as you say = there are no > >>guarantees to what these context provide. > >> > >> > >> >I do not see any difference in needing to obtain the keys/context > >> >information either before or after receiving the first message. > >> >However, since we do not have a sketched protocol for getting keys > >> >yet it is hard to be sure. Even if you have current keys you will > >> >still need to be able to get updated keys when the epoch rolls = over > >> >to the next value. This means that the two cases are going to be > >> >very > >>similar. > >> > >> I was thinking of a case when the receiving node actually has the > >>relevant context, but since there is no context identifier cannot > >>determine this is the case before doing a look-up of what context = is > >>valid for this resource. > >> > >> > > >> >> > >> >> > > >> >> >For the case of multicast, it appears to me that the context = can > >> >> >be inferred in most cases. I would assume that a context is > >> >> >going to be signed to each multicast address, port pair. I = would > >> >> >also assume that this would be a unique assignment in that > >> >> >multiple contexts would not be assigned. This does allow for = any > >> >> >node which has the context to send out a multicast message > >> >> >without a problem. The more interesting question is what to do > >> >> >with the unicast responses to a multicast message. Should they > >> >> >be encrypted with the multicast group context, in which case = the > >> >> >message id/token on the message is sufficient to identify the > >> >> >context. Or should they be encrypted with a unicast key pair > >> >> >between the replier and the original > >>message sender? > >> >> >This implies that such a key context needs to be setup for each > >> >> >such link which may or may not be the case. In this event it > >> >> >might be necessary to identify the context that was used to > >> >> >encrypt the unicast message. I have not managed to think this > >> >> >through far > >>enough. > >> >> > > >> >> >In any event, there appear to be enough cases where the > >> >> >encryption context can be inferred from the message to make it > >> >> >reasonable to have a version of COSE messages which do not have > >> >> >any recipient information attached to them. > >> >> >In the case of pure unicast, it would be used for at least 50% = of > >> >> >the messages (a higher percentage for observing state). And = for > >> >> >multicast it might be used either for 50% or all of the = messages > >> >> >depending on how responses are handled. > >> >> > > >> >> >I am interested in people looking at my analysis and tell me if = I > >> >> >am right, wrong or unclear. > >> >> > >> >> > >> >> There are cases where optimized message and context = identification > >> >>are needed, or where a context identifier could simplify the > >> >>processing. In both cases allowing optional header in the > >> >>COSE_encrypted format would solve the problem. For replay > >> >>protection, some context information such as sequence = number/nonce > >> >>needs anyway to be transferred, so I would say that the context > >> >>cannot be completely implicit. > >> > > >> >Yes, some input into an IV needs to be transferred, but I would = not > >> >consider that to be part of the saved context. This is not = needed for > >> >replay protection as much as it is needed for making sure that IVs > >> >are not re-used. This could potentially be different from the > >> >sequence number used for replay protection but generally would not = be. > >> > >> Agree. > >> > >> > > >> >I would expect that you would never want to send information you = do > >> >not have to since it only adds size. But still trying to figure = out > >> >where it is and is not needed to have a context identifier to = begin with. > >> >Then we can figure out where and if it makes sense to include it. > >> >But at that point you are already talking about taking size hits. > >> > >> Token could double play as indication of context identifier, but = not > >>always, not for free, and also may lead to some IMHO confusing > >>constraints such as different message formats for request and > >>response. > >> > >> As I understood one reason why COSE_encrypted was introduced was to > >>meet a request for a more compact format in settings where context = is > >>already established. Not sending context identifier may be an > >>optimization in some settings, but that format would be of much = less > >>use if a context identifier cannot be included. > >> > >> > >> G=C3=B6ran > > From nobody Thu Sep 17 14:42: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 D8BAB1A6FDA for ; Thu, 17 Sep 2015 14:42:55 -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 BIcrsLRgtsoy for ; Thu, 17 Sep 2015 14:42:53 -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 BF13C1A21A4 for ; Thu, 17 Sep 2015 14:42:53 -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 4E54D38F04; Thu, 17 Sep 2015 14:42:53 -0700 (PDT) From: "Jim Schaad" To: "'Derek Atkins'" References: <007901d0eea4$25989bf0$70c9d3d0$@augustcellars.com> <002b01d0ef07$aced5970$06c80c50$@augustcellars.com> <01b601d0eff2$120843c0$3618cb40$@augustcellars.com> <55FAA1B1.5020004@tzi.de> In-Reply-To: Date: Thu, 17 Sep 2015 14:40:32 -0700 Message-ID: <011701d0f191$7b324b70$7196e250$@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: AQGGfwiYLGVnvC1rumdUoUJ+HdJvIQI0bA87AfbgWScBfoJsqwHO/VvxAgmfnt4CHsjyLwEVrdasnnBtJNA= Archived-At: Cc: ace@ietf.org Subject: Re: [Ace] Looking at COSE based unicast and multicast 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, 17 Sep 2015 21:42:56 -0000 Derek, Yes you can, but it needs to be checked how much this will change the = security analysis by doing thing which might be unexpected. I cannot prevent them from doing this, I can only say that it is not the = way that I designed the system. I am far more worried about the fact = that I am not sure that they currently understand the problem that is = being solved, what the needed security properties are and what the = required, as oppose to nice to have, information is in all cases. I.e. = what can be inferred as oppose to being explicit. Hopefully the solution space will be easier to fill in once the actual = set of use cases and architecture is understood.=20 Jim > -----Original Message----- > From: Derek Atkins [mailto:derek@ihtfp.com] > Sent: Thursday, September 17, 2015 7:47 AM > To: Stefanie Gerdes > Cc: G=C3=B6ran Selander ; Jim Schaad > ; ace@ietf.org > Subject: Re: [Ace] Looking at COSE based unicast and multicast >=20 > If you really NEED a context you could just insert one into one of the = headers, > protected or unprotected depending. You could, for example, use the = Key ID > (kid) header. >=20 > -derek >=20 > Stefanie Gerdes writes: >=20 > > Hi Jim and G=C3=B6ran, > > > > I'm still trying to understand which problems you are trying to = solve > > with a context identifier. Here are some problems I can think of: > > > > Security association: > > 1. The client must know if a received message is a response to its = request. > > 2. If the client sends a new request it might want to use the same > > session keys etc, thus the server must be able to identify if the > > request belongs to a certain "session". > > 3. The server needs to know if a received request belongs to an > > existing context and use the respective keying material etc for its = answer. > > Other: > > 4. Client and server must be able to identify replayed messages. > > 5. Revocation of authorization information > > > > I don't think we need the context identifier for 1 since CoAP = already > > provides for that. DTLS provides for 2,3 and 4 within a session. I > > don't think we need more context identifiers for that. > > > > For 5 it should be possible to identify the authorization = information > > so that they can be revoked. For DCAF we are planning to include = this > > information in the ticket. > > > > In the object security case, an identifier for the "ticket" = containing > > the authorization information might work to address 2, 3 and 5. We > > might additionally need something to prevent 4. > > > > Best regards, > > Steffi > > > > _______________________________________________ > > Ace mailing list > > Ace@ietf.org > > https://www.ietf.org/mailman/listinfo/ace >=20 > -- > Derek Atkins 617-623-3745 > derek@ihtfp.com www.ihtfp.com > Computer and Internet Security Consultant From nobody Thu Sep 17 14:44: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 D77911A6FE7 for ; Thu, 17 Sep 2015 14:44:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.3 X-Spam-Level: X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, 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 AltZgAOW9GRX for ; Thu, 17 Sep 2015 14:44:15 -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 D00A01A6FDA for ; Thu, 17 Sep 2015 14:44:15 -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 50FCC2C9FE; Thu, 17 Sep 2015 14:44:15 -0700 (PDT) From: "Jim Schaad" To: "'Stefanie Gerdes'" , =?utf-8?Q?'G=C3=B6ran_Selander'?= , References: <007901d0eea4$25989bf0$70c9d3d0$@augustcellars.com> <002b01d0ef07$aced5970$06c80c50$@augustcellars.com> <01b601d0eff2$120843c0$3618cb40$@augustcellars.com> <55FAA1B1.5020004@tzi.de> <55FB0142.5030303@tzi.de> In-Reply-To: <55FB0142.5030303@tzi.de> Date: Thu, 17 Sep 2015 14:41:54 -0700 Message-ID: <011e01d0f191$ac1edc80$045c9580$@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: AQGGfwiYLGVnvC1rumdUoUJ+HdJvIQI0bA87AfbgWScBfoJsqwHO/VvxAgmfnt4CHsjyLwGmOitNAkJcSi2eWdaxEA== Archived-At: Subject: Re: [Ace] Looking at COSE based unicast and multicast 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, 17 Sep 2015 21:44:17 -0000 > -----Original Message----- > From: Stefanie Gerdes [mailto:gerdes@tzi.de] > Sent: Thursday, September 17, 2015 11:07 AM > To: G=C3=B6ran Selander ; Jim Schaad > ; ace@ietf.org > Subject: Re: [Ace] Looking at COSE based unicast and multicast >=20 > Hi G=C3=B6ran, >=20 > On 09/17/2015 07:55 PM, G=C3=B6ran Selander wrote: > > Hi Steffi, > > > > Here is one example: CoAP server serving multiple clients, (forward) > > proxy between clients and server. DTLS doesn=E2=80=99t give = end-to-end > > security, so we use object security. How does the server know from > > which client the request comes from? One way is to have an = identifier > > identifying something like client/key/context/token/ticket/etc. >=20 > Thank you for the example. Okay, so you are only discussing the object = security > solution part. >=20 > I guess your example refers to item 3 in the list I send: The server = needs to know > if a received request belongs to an existing context and use the = respective > keying material etc for its answer? Sounds reasonable to me that we = would need > some kind of identifier for that. Is that what you were discussing = about? This is part of the discussion. You are current in the original = analysis that DTLS has this implicitly known. I believe that in many = cases this will also be true for the object version as well. =20 Jim >=20 > Best regards, > Steffi From nobody Fri Sep 18 00:50:41 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 E10571A913F for ; Fri, 18 Sep 2015 00:50:39 -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_47=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 O0fe98wcv-lX for ; Fri, 18 Sep 2015 00:50:35 -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 8BF0A1A9128 for ; Fri, 18 Sep 2015 00:50:34 -0700 (PDT) X-AuditID: c1b4fb25-f79a26d00000149a-e4-55fbc248c4c6 Received: from ESESSHC014.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 11.40.05274.842CBF55; Fri, 18 Sep 2015 09:50:32 +0200 (CEST) Received: from ESESSMB303.ericsson.se ([169.254.3.214]) by ESESSHC014.ericsson.se ([153.88.183.60]) with mapi id 14.03.0248.002; Fri, 18 Sep 2015 09:50:32 +0200 From: =?utf-8?B?R8O2cmFuIFNlbGFuZGVy?= To: Jim Schaad , "ace@ietf.org" Thread-Topic: [Ace] Looking at COSE based unicast and multicast Thread-Index: AdDuo/sorjKxXnJSQaGX5o+dQpuhBgALnjSAAAkdOYAAIeyMAAAYrAEAAE80AwAAGI/YgAAZlhoA Date: Fri, 18 Sep 2015 07:50:31 +0000 Message-ID: References: <007901d0eea4$25989bf0$70c9d3d0$@augustcellars.com> <002b01d0ef07$aced5970$06c80c50$@augustcellars.com> <01b601d0eff2$120843c0$3618cb40$@augustcellars.com> <011601d0f191$20058910$60109b30$@augustcellars.com> In-Reply-To: <011601d0f191$20058910$60109b30$@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.148] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpnkeLIzCtJLcpLzFFi42KZGfG3Rtfj0O9Qg5u7tS2+f+thtlg9/Tub A5PHxjnT2TyWLPnJFMAUxWWTkpqTWZZapG+XwJXRNHMyY8Gxv4wVkz9eZW1gbPnO2MXIySEh YCJx+dF0dghbTOLCvfVsXYxcHEICRxklLn/cwQThLGGUuNW9jwmkik3AReJBwyMwW0TATeLs 5GUsILawgJ3Erc+3WCDi9hJ/D/RD2VES/Uv+M4PYLAKqEg8XPQXbzCtgIfHv1gWobe+YJM6u eA5WxCngIHH2wFo2EJsR6KTvp9aALWMWEJe49WQ+E8SpAhJL9pxnhrBFJV4+/scKYosK6Ems vN7EBhFXkmhc8gQozgHUqymxfpc+xBhriRf/X7FD2IoSU7ofskPcIyhxcuYTlgmM4rOQbJuF 0D0LSfcsJN2zkHQvYGRdxShanFqclJtuZKyXWpSZXFycn6eXl1qyiREYcwe3/FbdwXj5jeMh RgEORiUeXoWC36FCrIllxZW5hxilOViUxHmbmR6ECgmkJ5akZqemFqQWxReV5qQWH2Jk4uCU amBk1NOaoCqSovrO5InSr7qZkX92nyjY8j6hVFFplmTypk/yz8M+8sWcSA38+vpO6q53UhPd OvVUNojk3N3K+HJFr45g+/rCE25eagnXLVtmnY9JNm64sePA6pkX09luLdgfXjthl4yuTQvn pc3z2b5p+F21+3l0vwYbj0D094JcFf0D8oeElU2VWIozEg21mIuKEwGQ4+PDmgIAAA== Archived-At: Subject: Re: [Ace] Looking at COSE based unicast and multicast 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, 18 Sep 2015 07:50:40 -0000 DQoNCk9uIDIwMTUtMDktMTcgMjM6MzcsICJKaW0gU2NoYWFkIiA8aWV0ZkBhdWd1c3RjZWxsYXJz LmNvbT4gd3JvdGU6DQoNCj4NCj4NCj4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+PiBG cm9tOiBHw7ZyYW4gU2VsYW5kZXIgW21haWx0bzpnb3Jhbi5zZWxhbmRlckBlcmljc3Nvbi5jb21d DQo+PiBTZW50OiBUaHVyc2RheSwgU2VwdGVtYmVyIDE3LCAyMDE1IDEyOjU1IEFNDQo+PiBUbzog SmltIFNjaGFhZCA8aWV0ZkBhdWd1c3RjZWxsYXJzLmNvbT47IGFjZUBpZXRmLm9yZw0KPj4gU3Vi amVjdDogUmU6IFtBY2VdIExvb2tpbmcgYXQgQ09TRSBiYXNlZCB1bmljYXN0IGFuZCBtdWx0aWNh c3QNCj4+IA0KPj4gSmltLA0KPj4gDQo+PiBJIHRoaW5rIHdlIGFyZSBhcmd1aW5nIGZyb20gZml4 ZWQgcG9zaXRpb25zLg0KPg0KPkkgbXVzdCBiZSBzbGlwcGluZyAtIG5vcm1hbGx5IEkgYXJndWUg ZnJvbSBhYm91dCA1IG9yIDYgcG9zaXRpb25zIGF0IHRoZQ0KPnNhbWUgdGltZS4NCg0KOi0pDQoN Cj4NCj4+IA0KPj4gQ09TRV9FbmNyeXB0ZWQgZm9ybWF0LCB3aXRob3V0IG1hbmRhdG9yeSByZWNp cGllbnQgc3RydWN0dXJlLCBpcyBhIGdvb2QNCj4+c3RlcA0KPj4gdG93YXJkcyBhIG1vcmUgb3B0 aW1pemVkIGZvcm1hdC4gVGhlIG1haW4gZGlzYWdyZWVtZW50IHNlZW1zIHRvIGJlIG9uDQo+PnRo ZQ0KPj4gb3B0aW9uIHRvIHVzZSBhIGNvbnRleHQgaWRlbnRpZmllciBpbiB0aGUgaGVhZGVyLg0K Pg0KPlRoYXQgaXMgbm90IHJlYWxseSB0aGUgZm9jdXMgb2Ygd2hhdCBJIGFtIHRyeWluZyB0byBk byByaWdodCBub3cuICBJIGFtDQo+bW9zdGx5IHJlc3BvbmRpbmcgdG8geW91ciBjb21tZW50cyBh Ym91dCB0aGlzIHNheWluZyBpdCBpcyBub3QgZml4ZWQgeWV0Lg0KPiBJIHdhbnQgdG8gdHJ5IGFu ZCBmaWd1cmUgb3V0IHdoYXQgaW5mb3JtYXRpb24gaXMgYWxyZWFkeSBhdmFpbGFibGUsIHdoYXQN Cj5pbmZvcm1hdGlvbiBoYXMgdG8gYmUgdHJhbnNtaXR0ZWQgaW4gd2hhdCBtZXNzYWdlcywgd2hh dCBhcmUgdGhlDQo+c2NlbmFyaW9zIHRoYXQgSSBkb24ndCB1bmRlcnN0YW5kIGF0IHRoaXMgcG9p bnQgaW4gdGltZSB0aGF0IGNoYW5nZSB0aGUNCj5pbmZvcm1hdGlvbiB0aGF0IGlzIHJ1bm5pbmcg YXJvdW5kIGFscmVhZHkuICBUaGlzIG1lYW5zIHRoYXQgSSBoYXZlDQo+b3V0bGluZWQgd2h5IEkg ZG9uJ3QgdGhpbmsgdGhhdCBjb250ZXh0IGlkZW50aWZpY2F0aW9uIGlzIHJlcXVpcmVkIG9uIGEN Cj5udW1iZXIgb2YgcGxhY2VzLiAgQSByZXNwb25zZSBvZiAtIGJ1dCBpdCB3b3VsZCBiZSBuaWNl IHRvIGhhdmUgLSBpcyBub3QNCj5oZWxwaW5nIG1lIHVuZGVyc3RhbmQgdGhlIHJlYWwgcHJvYmxl bSBvZiB3aGVuIGl0IGlzIHJlcXVpcmVkIGFuZCB3aGVuIGl0DQo+Y2FuIGJlIGluZmVycmVkLg0K DQpTYXkgd2UgYXJlIGdvaW5nIHRvIGltcGxlbWVudCBhIHNlY3VyaXR5IHByb3RvY29sIGZvciBh IHNlbnNvcg0KZGV2aWNlL3Jlc291cmNlIHNlcnZlci4gU2hvdWxkIHdlIHJlc3RyaWN0IHRvIGEg cGFydGljdWxhciBkZXBsb3ltZW50PyBPcg0Kd291bGQgd2UgbGlrZSB0aGUgY29kZSB0byB3b3Jr IGV2ZW4gaWYgdGhlcmUgaXMgbW9yZSB0aGFuIG9uZSBjbGllbnQgYW5kDQpwb3RlbnRpYWwgaW50 ZXJtZWRpYXRlIG5vZGVzIChhcyBpbiB0aGUgZXhhbXBsZSBqdXN0IG1lbnRpb25lZCk/IEkgdGhp bmsNCmJvdGggdGhlc2UgY2FzZXMgYXJlIHZhbGlkLiBJZiB3ZSBnbyBmb3IgdGhlIGxhdHRlciwg dGhlbiBmb2xsb3dpbmcgeW91cg0KcmVhc29uaW5nIHdlIGNhbm5vdCB1c2UgdGhlIGNvbXBhY3Qg Q09TRV9lbmNyeXB0ZWQgZm9ybWF0IGluIHRoZSByZXF1ZXN0cy4NCg0KSXMgdGhpcyBhIHJlYWwg cHJvYmxlbT8gSSB0aGluayBpdCBpcyBhIHByb2JsZW0gaWYgd2UgZGVzaWduIGEgY29tcGFjdA0K Zm9ybWF0IHN1Y2ggdGhhdCBpcyBub3Qgc3VwcG9zZWQgdG8gYmUgdXNlZCBpbiBhIHJlYXNvbmFi bGUgc2V0IG9mIHVzZQ0KY2FzZXMuDQoNCg0KPg0KPlRoaXMgaXMgcGFydCBvZiB3aHkgSSBhbSB0 cnlpbmcgdG8gc2VlIGEgc29saWQsIGFuZCBjb21wbGV0ZSwNCj5hcmNoaXRlY3R1cmUgZG9jdW1l bnQgdGhhdCBjb3ZlcnMgYXMgbXVjaCBhcyBwb3NzaWJsZS4gIFVuZGVyc3RhbmRpbmcNCj53aGF0 IG5lZWRzIHRvIGJlIGRvbmUgYW5kIHdobyBpcyBnb2luZyB0byB0YWxrIHRvIHdob20gaXMgZGlm ZmljdWx0IGlmIGl0DQo+aXMgbm90IGluIGEgc2luZ2xlIChvciB2ZXJ5IHNtYWxsIG51bWJlcikg b2YgZG9jdW1lbnRzIHRoYXQgY2FuIHJlYWQuDQo+DQo+PiANCj4+IFdlIHdvdWxkIGxpa2UgdG8g YXBwbHkgdGhpcyBvcHRpbWl6ZWQgZm9ybWF0IGFsc28gdG8gc3ltbWV0cmljDQo+PmVuY3J5cHRp b24NCj4+ICsgYXN5bW1ldHJpYyBzaWduYXR1cmUsIGFzIHdlbGwgYXMgaW50ZWdyaXR5IHByb3Rl Y3Rpb24gb25seSAob25seSBvbmUNCj4+IHNpZ25hdHVyZS9NQUMpLiBBbGwgdGhlc2UgY291bGQg YmUgb25lIGNvbW1vbiBmb3JtYXQuDQo+DQo+QmVpbmcgb25seSBzbGlnaHRseSBzbmFya3kgLSBp dCBzb3VuZHMgYXMgdGhvdWdoIHlvdSBzaG91bGQgd3JpdGUgYQ0KPmNvbXBldGluZyBDT1NFIHBy b3Bvc2FsIHRoYXQgY2FuIGJlIHRob3JvdWdobHkgZGlzY3Vzc2VkIHNpbmNlIHlvdQ0KPmFwcGFy ZW50bHkgZG8gbm90IGxpa2UgdGhlIG9uZSB0aGF0IEkgaGF2ZSBwdXQgZm9yd2FyZC4NCg0KV2Vs bCwgSSB0aGluayBJIHNhaWQgc2V2ZXJhbCB0aW1lcyB0aGF0IEkgZG8gbGlrZSB0aGUgbWVzc2Fn ZSBmb3JtYXRzLiBJ4oCZbQ0Kbm90IGFyZ3VpbmcgYWdhaW5zdCBDT1NFX2VudmVsb3BlZCBhcyB0 aGUgZ2VuZXJpYyBwcm90b2NvbC4gSeKAmW0gY29tbWVudGluZw0KYWJvdXQgZGV0YWlscyBvZiB0 aGUgb3B0aW1pemVkIGZvcm1hdC4gQW5kIEkgdGhpbmsgYSBzaW1pbGFyIGZvcm1hdCBhcw0KQ09T RV9lbmNyeXB0ZWQgY291bGQgbW9yZSBvciBsZXNzIGRpcmVjdGx5IGFwcGx5IHRvIHRoZSBvdGhl ciBzZXR0aW5ncywNCnN1Y2ggYXMgaW50ZWdyaXR5LW9ubHkuIEFzc3VtaW5nIHRoZSBjb21wYWN0 IGZvcm1hdCBpcyBzb21ldGhpbmcgbGlrZToNCg0KWyBtZXNzYWdlX3R5cGUsIGhlYWRlciwgYm9k eSwgdGFnIF0NCg0KdGhlbiBib2R5PWNpcGhlcnRleHQgd291bGQgY292ZXIgdGhlIGNhc2Ugb2Yg ZW5jcnlwdGlvbiArIGludGVncml0eQ0KcHJvdGVjdGlvbiwgYXMgaW4gQ09TRV9lbmNyeXB0ZWQs IHdoZXJlYXMgYm9keT1wYXlsb2FkIHdvdWxkIGNvdmVyIHRoZQ0KY2FzZSBvZiBpbnRlZ3JpdHkg cHJvdGVjdGlvbiBvbmx5LiBPciBtYWtpbmcgdGhlc2UgdHdvIHNlcGFyYXRlIG1lc3NhZ2UNCnR5 cGVzIHRvIGFsbG93IGEgcHJveHkgdG8gdW5kZXJzdGFuZCBmcm9tIG1lc3NhZ2UgdHlwZSBpZiBp dCBjYW4gcmVhZCB0aGUNCmJvZHkuDQoNCg0KDQo+DQo+PiANCj4+IA0KPj4gQ29tbWVudHMgaW5s aW5lLg0KPj4gDQo+PiANCj4+IA0KPj4gT24gMjAxNS0wOS0xNSAyMjowNiwgIkppbSBTY2hhYWQi IDxpZXRmQGF1Z3VzdGNlbGxhcnMuY29tPiB3cm90ZToNCj4+IA0KPj4gPg0KPj4gPg0KPj4gPj4g LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+ID4+IEZyb206IEfDtnJhbiBTZWxhbmRlciBb bWFpbHRvOmdvcmFuLnNlbGFuZGVyQGVyaWNzc29uLmNvbV0NCj4+ID4+IFNlbnQ6IE1vbmRheSwg U2VwdGVtYmVyIDE0LCAyMDE1IDExOjIwIFBNDQo+PiA+PiBUbzogSmltIFNjaGFhZCA8aWV0ZkBh dWd1c3RjZWxsYXJzLmNvbT47IGFjZUBpZXRmLm9yZw0KPj4gPj4gU3ViamVjdDogUmU6IFtBY2Vd IExvb2tpbmcgYXQgQ09TRSBiYXNlZCB1bmljYXN0IGFuZCBtdWx0aWNhc3QNCj4+ID4+DQo+PiA+ PiBDb21tZW50cyBpbmxpbmUuDQo+PiA+Pg0KPj4gPj4gTXkgc3VtbWFyeToNCj4+ID4+DQo+PiA+ PiBUaGUgcmVxdWVzdCBpbiBnZW5lcmFsIG5lZWRzIGEgY29udGV4dCBpZGVudGlmaWVyLiBZb3Vy IHByb3Bvc2FsIGlzDQo+PiA+PnRvIHVzZSB0aGUgIENPU0VfZW52ZWxvcGVkIGZvcm1hdCwgbXkg cHJvcG9zYWwgaXMgdG8gYWxsb3cgYW4gb3B0aW9uYWwNCj4+ID4+Y29udGV4dCBpZGVudGlmaWVy ICBpbiB0aGUgQ09TRV9lbmNyeXB0ZWQgZm9ybWF0LCB3aGljaCBpcyBtb3JlDQo+PiA+PmNvbXBh Y3QuDQo+PiA+Pg0KPj4gPj4gSWYgeW91IGFzc29jaWF0ZSB0aGUgQ29BUCBUb2tlbiBvZiBhIHJl cXVlc3QgdG8gdGhlIGNvbnRleHQgdGhlbiB5b3UNCj4+ID4+Y2FuIHVzZSAgdGhhdCBhcyBhbiBp bmRleCBmb3IgY29udGV4dCBpZGVudGlmaWVyIGluIHRoZSByZXNwb25zZSBhbmQNCj4+ID4+aGVu Y2UgdXNlICBDT1NFX2VuY3J5cHRlZC4gQnV0IG5vdyB5b3UgaGF2ZSB0d28gcGFyYW1ldGVycyB0 aGF0DQo+PiA+PnBlcmZvcm0gYSBzaW1pbGFyDQo+PiA+PiB0YXNrOiBUb2tlbiBhbmQgQ29udGV4 dCBJZGVudGlmaWVyLCBhbmQgd2hpY2ggYm90aCBoYXMgdG8gYmUNCj4+ID4+dHJhbnNmZXJyZWQg aW4gYSAgcmVxdWVzdC4gVGhlIFRva2VuIGZpZWxkIGlzIHZhcmlhYmxlIGxlbmd0aCAwLTgNCj4+ ID4+Ynl0ZXMuIFNpbmNlIHdlIGNhbm5vdCBhdHRyaWJ1dGUgIGFueSBlbmQtdG8tZW5kIHNlY3Vy aXR5IHByb3BlcnRpZXMNCj4+ID4+b2YgVG9rZW4sIHRoZSBvYmplY3Qgc2VjdXJpdHkgc2NoZW1l IGlzIG1hZGUgIGluZGVwZW5kZW50IG9mIGhvdyB0aGUNCj4+ID4+VG9rZW4gaXMgc2V0LCBhbmFs b2dvdXNseSB0byB0aGUgY2FzZSBpbiBEVExTLg0KPj4gPj5CeSBpbnN0ZWFkDQo+PiA+PiByZWx5 aW5nIG9uIFRva2VuIHRvIGF2b2lkIGNvbGxpc2lvbnMgd2UgbWF5IG5lZWQgYSBsYXJnZXIgVG9r ZW4uDQo+PiA+DQo+PiA+VGhlcmUgaXMgbm8gbmVlZCB0byBleHBsaWNpdGx5IHByb3RlY3QgdGhl IGNvbnRleHQgaWRlbnRpZmllci4gIEl0IGlzDQo+PiA+aW1wbGljaXRseSBwcm90ZWN0ZWQgYXMg dGhlIG1lc3NhZ2Ugd2lsbCBmYWlsIHRvIHZhbGlkYXRlIGlmIHlvdSB1c2UNCj4+ID50aGUgd3Jv bmcgY29udGV4dC4gIFRoaXMgbWVhbnMgdGhhdCBpdCBpcyBwcm90ZWN0ZWQgZXZlbiBpZiBpdCBp cyBub3QNCj4+ID5wYXJ0IG9mIHRoZSBtZXNzYWdlIHByb3BlcnRpZXMuICBIYXZpbmcgdGhlIGNv bnRleHQgaWRlbnRpZmllZCBieSB0aGUNCj4+dG9rZW4gaXMNCj4+ID50b3RhbGx5IGxlZ2l0aW1h dGUgYW5kIHRvdGFsbHkgc2VjdXJlLiAgIEluIHRoZSBjYXNlIG9mIHVuaWNhc3QgRFRMUywNCj4+ ID50aGVyZSBpcyBubyBleHBsaWNpdCBjb250ZXh0IGlkZW50aWZpZXIgYW55d2hlcmUuICBJdCBp cyB0b3RhbGx5IGJhc2VkDQo+PiA+b24gdGhlIGZvdXItdHVwbGUgb2YgYWRkcmVzc2VzIGFuZCBw b3J0cy4gIFRoaXMgaGFzIHplcm8gY3J5cHRvZ3JhcGhpYw0KPj4gPnNlY3VyaXR5IGFwcGxpZWQg dG8gdGhlc2UgdmFsdWVzLCB0aGUgc2VjdXJpdHkgaXMgdG90YWxseSBpbXBsaWNpdC4NCj4+IA0K Pj4gSSBkb27igJl0IGNsYWltIHRoYXQgb21pdHRpbmcgdGhlIGNvbnRleHQgaWRlbnRpZmllciBp cyBpbnNlY3VyZS4gQnV0IGl0DQo+PmlzIG5vdCBhbHdheXMNCj4+IGZlYXNpYmxlIGUuZy4gaW4g cmVxdWVzdHMsIGFuZCBpdCBoYXMgaW1wYWN0IG9uIHByb2Nlc3NpbmcgYW5kIHNpemUgb2YNCj4+ b3RoZXINCj4+IHBhcmFtZXRlcnMgc3VjaCBhcyBDb0FQIFRva2VuLg0KPg0KPkkgZG9uJ3QgdW5k ZXJzdGFuZCB3aGF0IHlvdSBhcmUgdHJ5aW5nIHRvIHNheS4gIEl0IGRvZXMgbm90IG1ha2UgYW55 DQo+c2Vuc2UgdG8gbWUuDQoNCkkgd2FzIHRyeWluZyB0byBzdW1tYXJpemUgdGhlIGV4cGxhbmF0 aW9uIGFib3ZlLCB0aGF0IHJlbHlpbmcgb24gVG9rZW4gYXMNCmFuIGluZGljYXRpb24gb2YgY29u dGV4dCB0YWtlcyBhd2F5IHNvbWUgb2YgdGhlIGVmZmVjdHMgb2Ygb3B0aW1pemF0aW9uDQpnaXZl biBieSB0aGUgY29tcGFjdCBmb3JtYXQgb2YgQ09TRV9lbmNyeXB0ZWQuIEJ1dCB5b3UgY2FuIGRp c3JlZ2FyZCB0aGF0DQppZiB5b3UgbGlrZS4NCg0KPg0KPj4gDQo+PiANCj4+ID4NCj4+ID4+DQo+ PiA+PiBJ4oCZbSBub3QgY29udmluY2VkIHdpdGggdGhlIGRpZmZlcmVuY2UgYmV0d2VlbiBob3cg dGhlIG1lc3NhZ2UgaXMNCj4+ID4+Zm9ybWF0dGVkICBkZXBlbmRpbmcgb24gd2hldGhlciBpdCBp cyBhIHJlcXVlc3Qgb3IgcmVzcG9uc2UuIEEgZ2l2ZW4NCj4+ID4+bm9kZSBtYXkgc2VuZCB0aGUg IHNhbWUgcmVzb3VyY2UgcmVwcmVzZW50YXRpb24gYXMgUFVUIHJlcXVlc3Qgb3IgR0VUDQo+PiA+ PnJlc3BvbnNlIGFuZCB0aHVzIHdvdWxkICB1c2UgZGlmZmVyZW50IENPU0UgbWVzc2FnZSBmb3Jt YXRzLg0KPj4gPg0KPj4gPkdpdmVuIHRoYXQgdGhlIENPU0UgbWVzc2FnZSByZXByZXNlbnRhdGlv biBpcyBnb2luZyB0byBoYXZlIHRvIGJlIGJ1aWx0DQo+PiA+dW5pcXVlbHkgZm9yIGVhY2ggbWVz c2FnZSBzZW50LCBJIGRvbid0IGtub3cgdGhhdCB0aGlzIGlzIGEgcHJvYmxlbS4NCj4+ID5Ib3cg dGhlIENPU0UgaXMgY3JlYXRlZCBpcyBiYXNlZCBvbiB0aGUgaHR0cC1saWtlIG9wZXJhdGlvbiB0 aGF0IGlzDQo+PiA+YmVpbmcgdXNlZC4gIFRoaXMgd2lsbCBiZSB3ZWxsIHVuZGVyc3Rvb2Qgd2hl biBpdCBvY2N1cnMgYW5kIHdoZW4gaXQNCj4+ID5kb2VzIG5vdCBvY2N1ci4NCj4+IA0KPj4gSXQg aXMgcG9zc2libGUgdG8gdXNlIGRpZmZlcmVudCBDT1NFIGZvcm1hdHMgZm9yIHJlcXVlc3QgYW5k IHJlc3BvbnNlDQo+PmJ1dCBpbiB0aGUNCj4+IGNhc2UgSSBtZW50aW9uZWQgd2hlbiB0aGUgc2Ft ZSByZXNvdXJjZSByZXByZXNlbnRhdGlvbiBmb3IgcG90ZW50aWFsbHkNCj4+dGhlDQo+PiBzYW1l IGNvbXN1bWVyIGlzIHVzaW5nIGEgZGlmZmVyZW50IGZvcm1hdCBhbmQgb2YgZGlmZmVyZW50IHNp emUNCj4+ZGVwZW5kaW5nIG9uDQo+PiB3aGV0aGVyIGl0IGlzIFBVVCByZXF1ZXN0IG9yIEdFVCBy ZXNwb25zZSwgdGhhdCBqdXN0IGRvZXNu4oCZdCBzb3VuZCBsaWtlDQo+PmEgZ29vZA0KPj4gaWRl YS4NCj4NCj5BcmUgeW91IHBsYW5uaW5nIHRvIGJ1aWxkIHRoZXNlIGF0IHRoZSBzYW1lIHRpbWU/ ICBBcmUgeW91IG5vdCBnb2luZyB0bw0KPmhhdmUgYW55IG90aGVyIGRpZmZlcmVuY2VzIGluIHRo ZSBkYXRhIHRoYW4ganVzdCB0aGUgY29udGVudCBvZiB0aGUNCj5lbmNyeXB0ZWQgbWVzc2FnZS4g IEkgZG9uJ3QgdW5kZXJzdGFuZCB3aHkgeW91IHRoaW5rIHRoaXMgaXMgYSBiaWcNCj5hcmd1bWVu dC4gIEkgZG9uJ3Qga25vdyBob3cgbXVjaCB5b3UgYXJlIHBsYW5uaW5nIHRvIGtlZXAgdGhpcw0K PmluZm9ybWF0aW9uIGFyb3VuZCBvbiB0aGUgc3lzdGVtIGFuZCBzZW5kIGl0IHVuZGVyIGRpZmZl cmVudCBvcGVyYXRpb25zLg0KPiBJIGp1c3QgZG9uJ3QgdW5kZXJzdGFuZCB3aHkgdGhpcyBpcyBh IHByb2JsZW0NCg0KQW4gZW5kcG9pbnQgY291bGQgY2hhbmdlIGJldHdlZW4gcHVibGlzaGluZyB2 YWx1ZXMgYW5kIHJlc3BvbmQgdG8gc3BlY2lmaWMNCmFjY2VzcyByZXF1ZXN0cy4gSXQgd291bGQg dGh1cyBoYXZlIHRvIHVzZSB1c2UgZGlmZmVyZW50IG1lc3NhZ2UgZm9ybWF0cy4NCklzIHRoaXMg YSByZWFsIHByb2JsZW0/IEkgdGhpbmsgdGhpcyBkaWZmZXJlbmNlIGluIG1lc3NhZ2UgZm9ybWF0 cyB0aGF0DQphcmUgYWxsb3dlZCB0byB1c2UgZm9yIHJlcXVlc3QgYW5kIHJlc3BvbnNlIGNyZWF0 ZXMgdW5uZWNlc3NhcnkgY29tcGxleGl0eS4NCg0KPg0KPj4gDQo+PiA+DQo+PiA+Pg0KPj4gPj4N Cj4+ID4+IEl0IGlzIGFsc28gYSBtYXR0ZXIgb2YgaG93IHRoZSByZWNlaXZlZCBDT1NFIG9iamVj dCB3aWxsIGJlDQo+PiA+PnN1YnNlcXVlbnRseSB1c2VkLg0KPj4gPj4gRm9yIGV4YW1wbGUsIGlu IEluZm9ybWF0aW9uLUNlbnRyaWMgTmV0d29ya2luZywgaWYgSeKAmW0gbm90IG1pc3Rha2VuLA0K Pj4gPj5vbmUgb2YgdGhlICByZXF1aXJlbWVudHMgaXMgdGhhdCBlYWNoIHByb3RlY3RlZCBvYmpl Y3QgaGFzIGEgZ2xvYmFsbHkNCj4+ID4+dW5pcXVlIG5hbWUuDQo+PiA+PkJ5DQo+PiA+PiBzaGlm dGluZyBmb2N1cyBmcm9tIGEgY29udGV4dCBpZGVudGlmaWVyIHdpdGhpbiB0aGUgQ09TRSBvYmpl Y3QgdG8NCj4+ID4+VG9rZW4gd2hpY2ggaXMgIGVwaGVtZXJhbCBkYXRhIG91dHNpZGUgdGhlIENP U0Ugb2JqZWN0LCBJQ04NCj4+ID4+YXBwbGljYXRpb25zIHdvdWxkIGFsd2F5cyBoYXZlIHRvICB1 c2UgdGhlIGxlc3MgY29tcGFjdCBmb3JtYXQuDQo+PiA+DQo+PiA+SWYgeW91IGFyZSBjb3JyZWN0 LCBhbmQgdGhlIHVuaXF1ZSBuYW1lIGlzIGFsd2F5cyBrbm93biB0byBib3RoDQo+PiA+cGFydGll cywgdGhlbiBpdCBpcyBxdWl0ZSBwb3NzaWJsZSB0aGF0IHlvdSBoYXZlIGEgc2l0dWF0aW9uIHdo ZXJlIHRoZQ0KPj4gPmNvbnRleHQgaW5mb3JtYXRpb24gY2FuIGFsd2F5cyBiZSBpbXBsaWNpdCBh bmQgd291bGQgbm90IG5lZWQgdG8gYmUNCj4+ID5jYXJyaWVkIGF0IGFsbC4NCj4+IA0KPj4gQXMg ZmFyIGFzIEkgdW5kZXJzdGFuZCBJQ04gSSBiZWxpZXZlIHRoZSBuYW1lIHNob3VsZCBiZSBib3Vu ZCAvDQo+PnBvc3NpYmxlIHRvDQo+PiBkZXJpdmUgZnJvbSB0aGUgaW5mb3JtYXRpb24gb2JqZWN0 LiBCdXQgd2UgY291bGQgbGVhdmUgdGhpcyB0byB0aGUgSUNODQo+PmV4cGVydHMgdG8NCj4+IGNv bW1lbnQgb24uIEkganVzdCBub3RlIHRoYXQgdGhlcmUgbWF5IGJlIGEgc2lnbmlmaWNhbmNlIHdo ZXRoZXINCj4+aWRlbnRpZmljYXRpb24NCj4+IGlzIHByb3ZpZGVkIGJ5IHRoZSBvYmplY3QgaXRz ZWxmIG9yIGlmIGl0IHJlcXVpcmVzIGFkZGl0aW9uYWwgZGF0YQ0KPj4oc3VjaCBhcyBUb2tlbiBh bmQNCj4+IFVSSSkuDQo+PiANCj4NCj5ZZXMgLSBidXQgdW5kZXJzdGFuZGluZyB3aGF0IGNhbiBh bmQgY2Fubm90IGJlIHJlbGllZCBvbiB3aWxsIGFmZmVjdCBvdXINCj5kaXNjdXNzaW9ucyBhbmQg dGh1cyBuZWVkcyB0byBiZSBkZXRlcm1pbmVkLiAgQXJlIHRoZXJlIElDTiBleHBlcnRzIG9uDQo+ dGhpcyBsaXN0Pw0KPg0KPg0KPj4gPg0KPj4gPj4NCj4+ID4+IEkgdGhpbmsgd2UgYWdyZWUgdGhh dCBzb21lIHBhcmFtZXRlcihzKSBmb3IgcmVwbGF5IHByb3RlY3Rpb24vSVYNCj4+ID4+dW5pcXVl bmVzcyBpcyAgbmVlZGVkIGluIHJlcXVlc3QgYW5kIHJlc3BvbnNlLCBzbyB3b3VsZCBiZSBpbiB0 aGUNCj4+ID4+aGVhZGVyIG9mIGJvdGggIENPU0VfZW52ZWxvcGVkIGFuZCBDT1NFX2VuY3J5cHRl ZC4NCj4+ID4NCj4+ID5JIGhhdmUgYWxyZWFkeSBzYWlkIHRoaXMgaXMgdHJ1ZSwgYW5kIGl0IGlz IGNvbnRlbnQgcmVsYXRlZCBzbyBpdCBmaXRzDQo+PiA+dGhlIGN1cnJlbnQgQ09TRSBtb2RlbC4N Cj4+IA0KPj4gSWYgSSB1bmRlcnN0YW5kIHJpZ2h0LCB0aGlzIGlzIGFib3V0IHRoZSBjb250ZW50 IC8gcmVjaXBpZW50IHBhcmFkaWdtLg0KPj4gDQo+PiBBbm90aGVyIHdheSB0byB0aGluayBvZiB0 aGlzIGlzIGluIHRlcm1zIG9mIHNlbmRlciwgd2hpY2ggaXMgd2hhdCB3ZQ0KPj51c2UgY29udGV4 dA0KPj4gaWRlbnRpZmllciBmb3IuDQo+PiBJZiB0aGUgc2VuZGVyIGNvbnRleHQgaXMgaWRlbnRp ZmllZCwgZWFjaCByZWNpcGllbnQgY2FuIGZpbmQgb3V0IGZvcg0KPj5pdHNlbGYgaWYgYW5kDQo+ PiBob3cgdG8gbWFrZSB1c2Ugb2YgdGhlIG9iamVjdC4gT25lIGltcG9ydGFudCBhc3N1bXB0aW9u IGlzIHRoYXQgdGhlDQo+PnNlbmRlcg0KPj4gZG9lcyBub3QgaGF2ZSB0byBrbm93IGFueXRoaW5n IGFib3V0IHRoZSByZWNpcGllbnQuIFRoZSBzZW5kZXIgY291bGQNCj4+cmVseSBvbiBhDQo+PiB0 cnVzdGVkIHRoaXJkIHBhcnR5LCB0byBwcm92aWRlIGl0IHdpdGggdGhlIHJpZ2h0IHNlY3VyaXR5 IGNvbnRleHQgaXQNCj4+d2lsbCB1c2UsIGFuZA0KPj4gd2hpY2ggYWxzbyB3aWxsIGludGVyYWN0 IHdpdGggdGhlIHJlY2lwaWVudC4NCj4NCj5ZZXMgZnJvbSBteSBwb2ludCBvZiB2aWV3IHRoaXMg aXMgYSBwdXJpdHkgZGlzY3Vzc2lvbiAtIGl0IGlzIGFsc28gbm90DQo+b25lIHRoYXQgbmVlZHMg dG8gYmUgbWFkZSB5ZXQuDQo+DQo+PiANCj4+IA0KPj4gPkhvd2V2ZXIsIHRoZXJlIGlzIGFuIGlu dGVyZXN0aW5nIHF1ZXN0aW9uIGlmIHlvdSB3YW50IHRoaXMgaW4gdGhlIENPU0UNCj4+ID53b3Js ZCBvciBpbiB0aGUgQ29BUCB3b3JsZCBhbmQganVzdCBwcm90ZWN0IGl0IGluIENPU0UuICBIYXZp bmcgdHdvDQo+PiA+ZGlmZmVyZW50IHJlcGxheSBwcm90ZWN0aW9uIHN5c3RlbXMgaW4gcGxhY2Ug bWF5IGJlIG92ZXJraWxsLg0KPj4gDQo+PiBUaGUgc2VxdWVuY2UgbnVtYmVyIGV0Yy4gc2hvdWxk IGJlIHByb3RlY3RlZCBpbiBDT1NFLiBBcyBmYXIgYXMgSQ0KPj51bmRlcnN0YW5kLA0KPj4gdGhl IG9ubHkgcGxhY2UgdG8gZm9yIHNlcXVlbmNlIG51bWJlciBldGMuIGluIENPU0VfZW5jcnlwdGVk IGlzIGluIHRoZQ0KPj5oZWFkZXIuDQo+PiBCdXQgdGhlIHZlcmlmaWNhdGlvbiBvZiByZXBsYXkg cHJvdGVjdGlvbiBiZWxvbmdzIHRvIHRoZSBhcHBsaWNhdGlvbi4NCj4+RGlmZmVyZW50DQo+PiBy ZXBsYXkgcHJvdGVjdGlvbiBtZWNoYW5pc21zIG1heSBiZSB1c2VkIGRlcGVuZGluZyBvbiBhcHBs aWNhdGlvbiwgZS5nLg0KPj4gc2xpZGluZyB3aW5kb3cgb3Igc3RyaWN0IG9yZGVyLg0KPg0KPk5v IC0gcGxlYXNlIGxvb2sgYXQgdGhlIGV4dGVybmFsbHkgc3VwcGxlZCBkYXRhIGluIHRoZSBDT1NF IHNwZWMuDQoNCkkgd2FzIGFjdHVhbGx5IGdvaW5nIHRvIGNvbW1lbnQgb24gdGhhdCBmaXJzdCBw YXJhZ3JhcGggb2Ygc2VjdGlvbiA0LjEuDQpZb3UgYXJlIHJpZ2h0IHRoYXQgaW50ZWdyaXR5IHBy b3RlY3Rpbmcgc29tZSB1bmVuY3J5cHRlZCBDb0FQIG9wdGlvbnMgd2FzDQp0aGUgcmVhc29uIGZv ciB1c2luZyBkZXRhY2hlZCBjb250ZW50LiBCdXQgdGhlcmUgYXJlIG5vIGV4aXN0aW5nIG9yDQpw cm9wb3NlZCBDb0FQIG9wdGlvbnMgY29udGFpbmluZyB0cmFuc2FjdGlvbiBpZGVudGlmaWVycyBv ciBub25jZXMuIFRoaXMNCmRhdGEgaXMgcHJvcG9zZWQgKGluIHRoZSBvYmplY3Qgc2VjdXJpdHkg ZHJhZnQpIHRvIGdvIGludG8gdGhlIENPU0UNCnByb3RlY3RlZCBoZWFkZXIuIA0KDQpXaGF0IG1p Z2h0IGhhdmUgY29uZnVzZWQgeW91IGlzIHRoYXQgdGhlIHRyYW5zYWN0aW9uIGlkZW50aWZpZXIg b2YgdGhlDQoqQ29BUCByZXF1ZXN0KiBpcyBleHRlcm5hbGx5IHN1cHBsaWVkIGRhdGEgKG5vdCBz ZW50KSBvZg0KdGhlIENvQVAgcmVzcG9uc2UsIHRvIGFjaGlldmUgdGhlIHNlY3VyZSBiaW5kaW5n IGJldHdlZW4gcmVxdWVzdCBhbmQNCnJlc3BvbnNlLiAgQnV0IHRoZSByZXNwb25zZSBjb250YWlu cyBpdHMgb3duIHRyYW5zYWN0aW9uIGlkZW50aWZpZXIgaW4gdGhlDQpDT1NFIHByb3RlY3RlZCBo ZWFkZXIuDQoNCj4NCj4+IA0KPj4gV2FzIHRoaXMgd2hhdCB5b3Ugd2VyZSByZWZlcnJpbmcgdG8/ DQo+PiANCj4+IA0KPj4gR8O2cmFuDQo+PiANCj4+IA0KPj4gPg0KPj4gPj4NCj4+ID4+DQo+PiA+ PiBHw7ZyYW4NCj4+ID4+DQo+PiA+Pg0KPj4gPj4NCj4+ID4+IE9uIDIwMTUtMDktMTQgMTg6MDks ICJKaW0gU2NoYWFkIiA8aWV0ZkBhdWd1c3RjZWxsYXJzLmNvbT4gd3JvdGU6DQo+PiA+Pg0KPj4g Pj4gPg0KPj4gPj4gPg0KPj4gPj4gPj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+ID4+ ID4+IEZyb206IEfDtnJhbiBTZWxhbmRlciBbbWFpbHRvOmdvcmFuLnNlbGFuZGVyQGVyaWNzc29u LmNvbV0NCj4+ID4+ID4+IFNlbnQ6IE1vbmRheSwgU2VwdGVtYmVyIDE0LCAyMDE1IDI6NDggQU0N Cj4+ID4+ID4+IFRvOiBKaW0gU2NoYWFkIDxpZXRmQGF1Z3VzdGNlbGxhcnMuY29tPjsgYWNlQGll dGYub3JnDQo+PiA+PiA+PiBTdWJqZWN0OiBSZTogW0FjZV0gTG9va2luZyBhdCBDT1NFIGJhc2Vk IHVuaWNhc3QgYW5kIG11bHRpY2FzdA0KPj4gPj4gPj4NCj4+ID4+ID4+DQo+PiA+PiA+Pg0KPj4g Pj4gPj4gT24gMjAxNS0wOS0xNCAwNjoxNiwgIkppbSBTY2hhYWQiIDxpZXRmQGF1Z3VzdGNlbGxh cnMuY29tPiB3cm90ZToNCj4+ID4+ID4+DQo+PiA+PiA+DQo+PiA+PiA+DQo+PiA+PiA+PiA+DQo+ PiA+PiA+PiA+PkZyb20gdGhpcywgaXQgc2VlbXMgdG8gbWUgdGhhdCBkb2VzIHN1cHBvcnQgdGhl IHBvc2l0aW9uIHRoYXQNCj4+ID4+ID4+ID4+c29tZQ0KPj4gPj4gPj4gPmluZm9ybWF0aW9uIGFi b3V0IGNvbnRleHQgbmVlZHMgdG8gYmUgcGFzc2VkIG9uIHRoZSBpbml0aWFsDQo+Pm1lc3NhZ2Uu DQo+PiA+PiA+PiA+RGVwZW5kaW5nIG9uIGhvdyB0aGlzIGlzIHByZXNlbnRlZCBJIHdvdWxkIGV4 cGVjdCB0aGlzIHRvIGJlIGRvbmUNCj4+ID4+ID4+ID53aXRoIHRoZSBjdXJyZW50IENPU0UgZW5j cnlwdGVkIG1lc3NhZ2Ugc3RydWN0dXJlLiAgSXQgaXMNCj4+ID4+ID4+ID5wb3RlbnRpYWxseSBk aWZmZXJlbnQgaW4gdGhlIGNhc2Ugd2hlcmUgdGhlIGNsaWVudCBpcyBiZWluZyB1c2VkDQo+PiA+ PiA+PiA+dG8gcmVsYXkgaW5mb3JtYXRpb24gdG8gdGhlIHNlcnZlciBhYm91dCB0aGUgYXV0aG9y aXphdGlvbg0KPj5pbmZvcm1hdGlvbi4NCj4+ID4+ID4+DQo+PiA+PiA+PiBVc2luZyB0aGUgY3Vy cmVudCBDT1NFIGVuY3J5cHRlZCBtZXNzYWdlIHN0cnVjdHVyZSBpcyBub3QNCj4+ID4+ID4+IGFk ZHJlc3NpbmcgdGhlIGNvbmNlcm5zIGFib3V0IG1lc3NhZ2Ugc2l6ZSBhcyBoYXMgYmVlbiBkaXNj dXNzZWQNCj4+IHByZXZpb3VzbHkuDQo+PiA+PiA+PiBGcm9tIHRoZSBwcm9wb3NlZCBBQ0UgYXJj aGl0ZWN0dXJlIEkgY2FuIHJlZmVyZW5jZSB0d28gY2F0ZWdvcmllcw0KPj4gPj4gPj4gb2YNCj4+ ID4+IGZvcm1hdHM6DQo+PiA+PiA+Pg0KPj4gPj4gPj4gMS4gT25lIGNhdGVnb3J5IHdoaWNoIGFz c3VtZXMgdGhhdCB0aGVyZSBpcyBlc3NlbnRpYWxseSBvbmx5IGENCj4+ID4+ID4+4oCcYmFzZSBr ZXnigJ0NCj4+ID4+ID4+IGVzdGFibGlzaGVkIGJldHdlZW4gc2VuZGVyIGFuZCByZWNlaXZlciwg YW5kIHdoZXJlIHRoZSBtZXNzYWdlDQo+PiA+PiA+PnByb3ZpZGVzICBtZWFucyB0byBkZXJpdmUg dGhlIHNlY3VyaXR5IGNvbnRleHQgdG8gdXNlIHdpdGggdGhlDQo+PiA+Pm1lc3NhZ2UuDQo+PiA+ PiA+Pg0KPj4gPj4gPj4gMi4gQW5vdGhlciBjYXRlZ29yeSB3aGljaCBpcyBoaWdobHkgb3B0aW1p emVkIGZvciB0aGUgc2V0dGluZyB0aGF0DQo+PiA+PiA+PnRoZSBzZWN1cml0eSAgY29udGV4dCBp cyBhdmFpbGFibGUgYXQgdGhlIHJlY2VpdmVyLg0KPj4gPj4gPj4NCj4+ID4+ID4+DQo+PiA+PiA+ PiBJIHRoaW5rIHRoZSBkaXN0aW5jdGlvbiBiZXR3ZWVuIENPU0VfRW52ZWxvcGVkIGFuZCBDT1NF X0VuY3J5cHRlZA0KPj4gPj4gPj5zdHJ1Y3R1cmUgIGlzIGEgZ29vZCBzdGVwIGluIHRoZSByaWdo dCBkaXJlY3Rpb24sIGJ1dCB0aGUgbGF0dGVyDQo+PiA+PiA+PnNob3VsZCBhbGxvdyBmb3IgdGhl IGRlc2lyZWQgIGlkZW50aWZpY2F0aW9uIGFuZCBvcHRpbWl6YXRpb24gZm9yDQo+PiA+PiA+PnRo ZSBtb3N0IGNvbW1vbiBzZXR0aW5ncy4gU29tZXRoaW5nDQo+PiA+PiA+Pmxpa2U6DQo+PiA+PiA+ Pg0KPj4gPj4gPj4gWyBtZXNzYWdlIHR5cGUsIHByb3RlY3RlZCBoZWFkZXJzLCBjaXBoZXIgdGV4 dCwgdGFnIF0NCj4+ID4+ID4+DQo+PiA+PiA+Pg0KPj4gPj4gPj4gd2hlcmUgcHJvdGVjdGVkIGhl YWRlcnMgY2FuIGlkZW50aWZ5IHRoZSBzZWN1cml0eSBjb250ZXh0IGFuZCB0aGUNCj4+ID4+ID4+ IG5vbmNlL3NlcXVlbmNlIG51bWJlci4NCj4+ID4+ID4+DQo+PiA+PiA+PiBJbiBmYWN0LCB0byBn ZXQgcmVwbGF5IHByb3RlY3Rpb24gb2YgcmVxdWVzdCwgYW5kIG9mIHJlc3BvbnNlIGlmDQo+PiA+ PiA+Pm5vIHByaW9yIHJlcXVlc3QgIGJvdW5kIHRvIHRoZSByZXNwb25zZSwgb25lIG9mIHRoZSBm aWVsZHMgaW4gdGhlDQo+PiA+PiA+PnByb3RlY3RlZCBoZWFkZXIgbXVzdCBiZSAgbm9uY2Uvc2Vx dWVuY2UgbnVtYmVyL3RpbWVzdGFtcCwgcmlnaHQ/DQo+PiA+PiA+PlRodXMgdGhlIGZvcm1hdCB3 b3VsZCBhbnl3YXkgIGNhcnJ5IHNvbWUgaW5mb3JtYXRpb24gYWJvdXQgc2VjdXJpdHkNCj4+ID4+ ID4+Y29udGV4dC4gSXQgc2VlbXMgb2RkIHRvIG5vdCBhbGxvdyBhbiAgaWRlbnRpZmllciBvZiB3 aGF0IGNvbnRleHQNCj4+ID4+ID4+dGhpcyBub25jZS9ldGMuIHJlZmVycyB0by4NCj4+ID4+ID4+ DQo+PiA+PiA+Pg0KPj4gPj4gPj4gPg0KPj4gPj4gPj4gPlRoZSByZXNwb25zZSBkb2VzIG5vdCBh cHBlYXIgdG8gbmVlZCBhIGNvbnRleHQgaWRlbnRpZmllciBhcw0KPj4gPj4gPj4gPnRoZXJlIGlz IGFscmVhZHkgaW5mb3JtYXRpb24gaW4gdGhlIENvQVAgbWVzc2FnZSB0aGF0IGNhbiBiZSB1c2Vk DQo+PiA+PiA+PiA+Zm9yIGRldGVybWluaW5nIHRoZSBjb250ZXh0Lg0KPj4gPj4gPj4NCj4+ID4+ ID4+ID5TcGVjaWZpY2FsbHkgdGhlIFRva2VuIGFuZCBNZXNzYWdlIElEIGZpZWxkcyBjYW4gYmUg dXNlZCB0bw0KPj4gPj4gPj4gPmFzc29jaWF0ZSByZXF1ZXN0cyBhbmQgcmVzcG9uc2VzLg0KPj4g Pj4gPj4NCj4+ID4+ID4+IE1lc3NhZ2UgSUQgaXMgbm90IGEgcmVsaWFibGUgaWRlbnRpZmllciBm b3IgYXNzb2NpYXRpbmcgcmVxdWVzdCB0bw0KPj4gPj4gPj5yZXNwb25zZS4NCj4+ID4+ID4NCj4+ ID4+ID5GaXJzdCwgcGxlYXNlIG5vdGUgdGhhdCBJIHNhaWQgYm90aCBUb2tlbiBhbmQgTWVzc2Fn ZSBJRC4gIEFyZSB0aGVyZQ0KPj4gPj4gPmNhc2VzIHRoYXQgYmV0d2VlbiB0aGVzZSB0d28gZmll bGRzIHRoZSByZXF1ZXN0IGFuZCB0aGUgcmVzcG9uc2UNCj4+ID4+ID5jYW5ub3QgYmUgYXNzb2Np YXRlZD8NCj4+ID4+DQo+PiA+PiBJIGRvbuKAmXQgc2VlIGhvdyBNZXNzYWdlIElEIGFkZHMgYW55 dGhpbmcuIENvbXBhcmUgZmlndXJlcyA1IGFuZCA2IG9mDQo+PiA+PlJGQzcyNTIuDQo+PiA+PiBJ IGJlbGlldmUgbWF0Y2hpbmcgQ29BUCBUb2tlbiBpbiByZXF1ZXN0IGFuZCByZXNwb25zZSB3b3Vs ZCBiZQ0KPj4gPj5zdWZmaWNpZW50LCAgYWx0aG91Z2ggdGhlIFRva2VuIGluIGl0c2VsZiBjYW7i gJl0IGJlIGludGVncml0eSBwcm90ZWN0ZWQNCj4+ID4+aW4gdHJhbnNmZXIgc2luY2UgaXQgbWF5 ICBiZSBjaGFuZ2VkIGJ5IGEgcHJveHkuDQo+PiA+Pg0KPj4gPj4gPg0KPj4gPj4gPj4NCj4+ID4+ ID4+ID4gIFRoaXMgbWVhbnMgdGhhdCBhIGNsaWVudCBjYW4gdXNlIHRoaXMgdG8gZGV0ZXJtaW5l IHdoYXQgY29udGV4dA0KPj4gPj4gPj4gPndhcyB1c2VkIGJ5IHRoZSBzZXJ2ZXIgdG8gZW5jcnlw dCB0aGUgbWVzc2FnZSB0aGF0IHdhcyByZXR1cm5lZC4NCj4+ID4+ID4+ID4oU3BlY2lmaWNhbGx5 LCB0aGUgc2FtZSBjb250ZXh0IGFuZCB0aGUgY2xpZW50IHVzZWQgdG8gZW5jcnlwdA0KPj4gPj4g Pj4gPnRoZQ0KPj4gPj4gPj4gPnJlcXVlc3QuKQ0KPj4gPj4gPj4NCj4+ID4+ID4+IFRoZSBjb250 ZXh0IG1heSBiZSBkaWZmZXJlbnQgZm9yIHJlcXVlc3QgYW5kIHJlc3BvbnNlLCBhbmQgYWx3YXlz DQo+PiA+PiA+PiBpcyBpbiBPU0NPQVAuDQo+PiA+PiA+DQo+PiA+PiA+UGxlYXNlIG5vdGUgdGhh dCBJIGFtIHVzaW5nIGNvbnRleHQgaW4gdGhlIHNhbWUgd2F5IHRoYXQgVExTIHVzZXMNCj4+ID4+ ID50aGlzIHRlcm0uICBUaGlzIG1lYW5zIHRoYXQgdGhlIGluZm9ybWF0aW9uIGlzIGdvaW5nIHRv IGJlIGRpZmZlcmVudA0KPj4gPj4gPmZvciB0aGUgdHdvIGRpcmVjdGlvbnMsIGJ1dCB0aGUgY29u dGV4dCBpZGVudGlmaWVzIGEgc2luZ2xlIHNldCBvZg0KPj5pbmZvcm1hdGlvbi4NCj4+ID4+ID4N Cj4+ID4+ID5JIGRvbid0IHNlZSBhbnl0aGluZyBjYWxsZWQgT1NDT0FQIGluIGVpdGhlciBjb3Jl IG9yIGFjZS4NCj4+ID4+DQo+PiA+PiBTb3JyeSwgYWJicmV2aWF0aW9uIGZvciB0aGUgQUNFIGRy YWZ0ICJPYmplY3QgU2VjdXJpdHkgZm9yIENvQVAiDQo+PiA+Pg0KPj4gPj4gPg0KPj4gPj4gPj4N Cj4+ID4+ID4+DQo+PiA+PiA+PiA+IFRoaXMgbWVhbnMgdGhhdCB3ZSBjYW4gc2F5IHRoYXQgdGhl cmUgaXMgYW4gaW1wbGljaXQgY29udGV4dCBmb3INCj4+ID4+ID4+ID5lbmNyeXB0ZWQgbWVzc2Fn ZXMgaW4gdGhpcyBjYXNlIHRoZSBuZXcgZW5jcnlwdGlvbiBzdHJ1Y3R1cmUgdy9vDQo+PiA+PiA+ PiA+cmVjaXBpZW50cyB3b3VsZCBtYWtlIHNlbnNlLiAgVGhpcyBhbmFseXNpcyB3b3VsZCBhcHBs eSB0byB0aGUNCj4+ID4+ID4+ID5vYnNlcnZlIGRpYWxvZyBzdHJ1Y3R1cmUgYXMgd2VsbCwgdGhl IHRva2VuIGNhbiBiZSB1c2VkIHRvDQo+PiA+PiA+PiA+YXNzb2NpYXRlIGFsbCBpdGVtcyBpbiB0 aGUgc2FtZSBjb250ZXh0Lg0KPj4gPj4gPj4NCj4+ID4+ID4+IEV2ZW4gaWYgdGhlcmUgYXJlIGNh c2VzIHdoZXJlIGxlYXZpbmcgb3V0IGNvbnRleHQgaW4gcmVzcG9uc2UNCj4+ID4+ID4+Y291bGQg YmUgIHBlcmZvcm1lZCwgSSB0aGluayBpdCBzaG91bGQgYmUgYWxsb3dlZCB0byBzcGVjaWZ5DQo+ PiA+PiA+PmNvbnRleHQgYXMgYW4NCj4+ID4+b3B0aW9uLg0KPj4gPj4gPj4gVGhpcyB3b3VsZCBh bHNvIHJlbGlldmUgdGhlIHNldHRpbmdzIHdoZXJlIG11bHRpcGxlIGNvbnRleHRzIG5lZWRzDQo+ PiA+PiA+PnRvIGJlIHRyaWVkLg0KPj4gPj4gPg0KPj4gPj4gPlBsZWFzZSBpZGVudGlmeSBzaXR1 YXRpb25zIHdoZXJlIG11bHRpcGxlIGNvbnRleHRzIHdvdWxkIG5lZWQgdG8gYmUNCj4+ID4+ID50 cmllZC4gIEkgaGF2ZSBvbmx5IGNvbWUgdXAgd2l0aCBvbmUgc28gZmFyLCBhc3N1bWluZyB0aGF0 IG9uZSBpcw0KPj4gPj4gPmdvaW5nIHRvIHVzZSBkaXN0aW5jdCBhZGRyZXNzL3BvcnQgcGFpcnMg Zm9yIHRoZSBtdWx0aS1jYXN0IGNhc2UuDQo+PiA+PiA+VGhhdCB3b3VsZCBiZSB0aGUgY2FzZSBv ZiBzdWJzY3JpYmluZy4NCj4+ID4+DQo+PiA+PiBBbm90aGVyIGNhc2UgaXMgVG9rZW4gY29sbGlz aW9ucy4NCj4+ID4+DQo+PiA+PiA+DQo+PiA+PiA+Pg0KPj4gPj4gPj4gPg0KPj4gPj4gPj4gPkZv ciBhIHN1YnNjcmlwdGlvbiBtb2RlbCB0byBhIHRoaXJkIHBhcnR5LCB0aGVyZSBhcmUgYSBjb3Vw bGUgb2YNCj4+ID4+ID4+ID5kaWZmZXJlbnQgd2F5cyB0byBsb29rIGF0IGhvdyBpdCBjYW4gYmUg c2V0dXAuICBUaGUgYmlnIHF1ZXN0aW9uDQo+PiA+PiA+PiA+aXMgaWYgdGhlIGNvbnRleHQgaXMg Z29pbmcgdG8gYmUgdW5pcXVlIHRvIHRoZSBvcmlnaW5hdG9yLCBvciBpdA0KPj4gPj4gPj4gPmlz IHVuaXF1ZSB0byB0aGUgc3Vic2NyaXB0aW9uLg0KPj4gPj4gPj4gPkluIGVpdGhlciBjYXNlLCB0 aGUgY2xpZW50IGlzIGdvaW5nIHRvIGVuZCB1cCB1c2luZyB0d28gZGlmZmVyZW50DQo+PiA+PiA+ PiA+Y29udGV4dHMgaW4gdGhpcyBzaXR1YXRpb24uICBUaGUgZmlyc3QgY2FzZSBpcyBmb3Igc2V0 dGluZyB1cCB0aGUNCj4+ID4+ID4+ID5vcmlnaW5hbCBzdWJzY3JpcHRpb24uICBJbiB0aGF0IGNh c2UgYSBjb250ZXh0IGFzc29jaWF0ZWQgd2l0aA0KPj4gPj4gPj4gPnRoZSBkYXRhIHN0b3JhZ2Ug c2VydmVyIGlzIGdvaW5nIHRvIGJlIG5lZWRlZC4gIEhvd2V2ZXIsIG9uY2UNCj4+ID4+ID4+ID5p bmZvcm1hdGlvbiBzdGFydHMgZmxvd2luZyBiYWNrIHRvIHRoZSBjbGllbnQgZnJvbSB0aGUgZGF0 YQ0KPj4gPj4gPj4gPnN0b3JhZ2Ugc2VydmljZSwgdGhlIGNvbnRleHQgYXNzb2NpYXRlZCB3aXRo IHRoZSBvcmlnaW5hdGlvbg0KPj4gPj4gPj4gPnNlcnZlciBpcyBnb2luZyB0byBiZSB1c2VkLiAg SXQgaXMgbm90IGNsZWFyIHRoYXQgdGhlIGFjdGlvbiBvZg0KPj4gPj4gPj4gPmRvaW5nIHRoZSBz dWJzY3JpcHRpb24gd291bGQgbmVlZCB0byBiZSBlbmNyeXB0ZWQsICB0aGlzDQo+PiA+PiA+PiA+ c2ltcGxpZmllZCB0aGluZ3MgYXMgb25seSBvbmUgZW5jcnlwdGlvbiBjb250ZXh0IGlzIG5vdyBu ZWVkZWQuDQo+PiA+PiA+PiA+T3RoZXJ3aXNlIGVpdGhlciB0d28gY29udGV4dHMgbmVlZCB0byBi ZSB0cmllZCwgb3IgdGhlIHR5cGUgb2YNCj4+ID4+ID4+ID5tZXNzYWdlIG5lZWRzIHRvIGJlIGtu b3duIHNvIHRoYXQgdGhlIGNsaWVudCB1bmRlcnN0YW5kIHdoZXJlIHRoZQ0KPj4gPj4gPj4gPmVu Y3J5cHRlZCBjb250ZW50DQo+PiA+Pm9yaWdpbmF0ZXMuDQo+PiA+PiA+Pg0KPj4gPj4gPj4gVGhl IGRhdGEgc3RvcmUgbmVlZCBub3QgYmUgdHJ1c3RlZC4gSW5mb3JtYXRpb24gYWJvdXQgYmluZGlu Zw0KPj4gPj4gPj5iZXR3ZWVuIGRpZmZlcmVudCBjb250ZXh0cyBuZWVkcyB0byBiZSBvYnRhaW5l ZCBmcm9tIGEgdHJ1c3RlZA0KPj4gPj4gPj5wYXJ0eSwgc3VjaCBhcyB0aGUgIGF1dGhvcml6YXRp b24gc2VydmVyLiBJIGJlbGlldmUgdGhlIHByZXNlbmNlIG9mDQo+PiA+PiA+PmEgY29udGV4dCBp ZGVudGlmaWVyIHdvdWxkIHNpbXBsaWZ5ICB0aGUgcHJvY2Vzc2luZyB3aGVyZSB0aGlzIHR5cGUN Cj4+ID4+ID4+b2YgYmluZGluZyBuZWVkcyB0byBiZSBlc3RhYmxpc2hlZCBhZnRlciB0aGUgIG1l c3NhZ2UgaGFzIGJlZW4NCj4+ID4+ID4+cmVjZWl2ZWQsIGNvbXBhcmVkIHRvIHRoZSBjYXNlIG9m IHJlY2VpdmluZyBhbiBlbmNyeXB0ZWQgIHN0cnVjdHVyZQ0KPj4gPj4gPj53aXRob3V0IGFueSBo YW5kbGUgd2hhdHNvZXZlci4NCj4+ID4+ID4NCj4+ID4+ID5JbiBteSBhbmFseXNpcyBJIGRpZCBu b3QgbWFrZSBhbnkgYXNzdW1wdGlvbnMgdGhhdCB0aGUgZGF0YSBzdG9yZQ0KPj4gPj4gPndhcyB0 cnVzdGVkIHRvIGRvIGFueXRoaW5nIG1vcmUgdGhhbiBpdHMgYXNzaWduZWQgam9iLiAgSSBkaWQg bm90DQo+PiA+PiA+bWFrZSBhbnkgYXNzdW1wdGlvbnMgdGhhdCBpdCB3b3VsZCBkbyBjcnlwdG9n cmFwaHkgZXhjZXB0IGZvcg0KPj4gPj4gPm1lc3NhZ2VzIHNlbnQgZGlyZWN0bHkgdG8gaXQuDQo+ PiA+Pg0KPj4gPj4gRmFpciBlbm91Z2guIEkgdHJpZ2dlcmVkIG9uICJ0aGUgY2xpZW50IGlzIGdv aW5nIHRvIGVuZCB1cCB1c2luZyB0d28NCj4+ID4+ZGlmZmVyZW50ICBjb250ZXh0cyBpbiB0aGlz IHNpdHVhdGlvbuKAnSwgIGJ1dCBhcyB5b3Ugc2F5IHRoZXJlIGFyZSBubw0KPj4gPj5ndWFyYW50 ZWVzIHRvIHdoYXQgdGhlc2UgIGNvbnRleHQgcHJvdmlkZS4NCj4+ID4+DQo+PiA+Pg0KPj4gPj4g PkkgZG8gbm90IHNlZSBhbnkgZGlmZmVyZW5jZSBpbiBuZWVkaW5nIHRvIG9idGFpbiB0aGUga2V5 cy9jb250ZXh0DQo+PiA+PiA+aW5mb3JtYXRpb24gZWl0aGVyIGJlZm9yZSBvciBhZnRlciByZWNl aXZpbmcgdGhlIGZpcnN0IG1lc3NhZ2UuDQo+PiA+PiA+SG93ZXZlciwgc2luY2Ugd2UgZG8gbm90 IGhhdmUgYSBza2V0Y2hlZCBwcm90b2NvbCBmb3IgZ2V0dGluZyBrZXlzDQo+PiA+PiA+eWV0IGl0 IGlzIGhhcmQgdG8gYmUgc3VyZS4gIEV2ZW4gaWYgeW91IGhhdmUgY3VycmVudCBrZXlzIHlvdSB3 aWxsDQo+PiA+PiA+c3RpbGwgbmVlZCB0byBiZSBhYmxlIHRvIGdldCB1cGRhdGVkIGtleXMgd2hl biB0aGUgZXBvY2ggcm9sbHMgb3Zlcg0KPj4gPj4gPnRvIHRoZSBuZXh0IHZhbHVlLiAgVGhpcyBt ZWFucyB0aGF0IHRoZSB0d28gY2FzZXMgYXJlIGdvaW5nIHRvIGJlDQo+PiA+PiA+dmVyeQ0KPj4g Pj5zaW1pbGFyLg0KPj4gPj4NCj4+ID4+IEkgd2FzIHRoaW5raW5nIG9mIGEgY2FzZSB3aGVuIHRo ZSByZWNlaXZpbmcgbm9kZSBhY3R1YWxseSBoYXMgdGhlDQo+PiA+PnJlbGV2YW50ICBjb250ZXh0 LCBidXQgc2luY2UgdGhlcmUgaXMgbm8gY29udGV4dCBpZGVudGlmaWVyIGNhbm5vdA0KPj4gPj5k ZXRlcm1pbmUgdGhpcyBpcyB0aGUgY2FzZSAgYmVmb3JlIGRvaW5nIGEgbG9vay11cCBvZiB3aGF0 IGNvbnRleHQgaXMNCj4+ID4+dmFsaWQgZm9yIHRoaXMgcmVzb3VyY2UuDQo+PiA+Pg0KPj4gPj4g Pg0KPj4gPj4gPj4NCj4+ID4+ID4+ID4NCj4+ID4+ID4+ID5Gb3IgdGhlIGNhc2Ugb2YgbXVsdGlj YXN0LCBpdCBhcHBlYXJzIHRvIG1lIHRoYXQgdGhlIGNvbnRleHQgY2FuDQo+PiA+PiA+PiA+YmUg aW5mZXJyZWQgaW4gbW9zdCBjYXNlcy4gIEkgd291bGQgYXNzdW1lIHRoYXQgYSBjb250ZXh0IGlz DQo+PiA+PiA+PiA+Z29pbmcgdG8gYmUgc2lnbmVkIHRvIGVhY2ggbXVsdGljYXN0IGFkZHJlc3Ms IHBvcnQgcGFpci4gIEkgd291bGQNCj4+ID4+ID4+ID5hbHNvIGFzc3VtZSB0aGF0IHRoaXMgd291 bGQgYmUgYSB1bmlxdWUgYXNzaWdubWVudCBpbiB0aGF0DQo+PiA+PiA+PiA+bXVsdGlwbGUgY29u dGV4dHMgd291bGQgbm90IGJlIGFzc2lnbmVkLiAgVGhpcyBkb2VzIGFsbG93IGZvciBhbnkNCj4+ ID4+ID4+ID5ub2RlIHdoaWNoIGhhcyB0aGUgY29udGV4dCB0byBzZW5kIG91dCBhIG11bHRpY2Fz dCBtZXNzYWdlDQo+PiA+PiA+PiA+d2l0aG91dCBhIHByb2JsZW0uICBUaGUgbW9yZSBpbnRlcmVz dGluZyBxdWVzdGlvbiBpcyB3aGF0IHRvIGRvDQo+PiA+PiA+PiA+d2l0aCB0aGUgdW5pY2FzdCBy ZXNwb25zZXMgdG8gYSBtdWx0aWNhc3QgbWVzc2FnZS4gIFNob3VsZCB0aGV5DQo+PiA+PiA+PiA+ YmUgZW5jcnlwdGVkIHdpdGggdGhlIG11bHRpY2FzdCBncm91cCBjb250ZXh0LCBpbiB3aGljaCBj YXNlIHRoZQ0KPj4gPj4gPj4gPm1lc3NhZ2UgaWQvdG9rZW4gb24gdGhlIG1lc3NhZ2UgaXMgc3Vm ZmljaWVudCB0byBpZGVudGlmeSB0aGUNCj4+ID4+ID4+ID5jb250ZXh0LiAgT3Igc2hvdWxkIHRo ZXkgYmUgZW5jcnlwdGVkIHdpdGggYSB1bmljYXN0IGtleSBwYWlyDQo+PiA+PiA+PiA+YmV0d2Vl biB0aGUgcmVwbGllciBhbmQgdGhlIG9yaWdpbmFsDQo+PiA+Pm1lc3NhZ2Ugc2VuZGVyPw0KPj4g Pj4gPj4gPlRoaXMgaW1wbGllcyB0aGF0IHN1Y2ggYSBrZXkgY29udGV4dCBuZWVkcyB0byBiZSBz ZXR1cCBmb3IgZWFjaA0KPj4gPj4gPj4gPnN1Y2ggbGluayB3aGljaCBtYXkgb3IgbWF5IG5vdCBi ZSB0aGUgY2FzZS4gIEluIHRoaXMgZXZlbnQgaXQNCj4+ID4+ID4+ID5taWdodCBiZSBuZWNlc3Nh cnkgdG8gaWRlbnRpZnkgdGhlIGNvbnRleHQgdGhhdCB3YXMgdXNlZCB0bw0KPj4gPj4gPj4gPmVu Y3J5cHQgdGhlIHVuaWNhc3QgbWVzc2FnZS4gIEkgaGF2ZSBub3QgbWFuYWdlZCB0byB0aGluayB0 aGlzDQo+PiA+PiA+PiA+dGhyb3VnaCBmYXINCj4+ID4+ZW5vdWdoLg0KPj4gPj4gPj4gPg0KPj4g Pj4gPj4gPkluIGFueSBldmVudCwgdGhlcmUgYXBwZWFyIHRvIGJlIGVub3VnaCBjYXNlcyB3aGVy ZSB0aGUNCj4+ID4+ID4+ID5lbmNyeXB0aW9uIGNvbnRleHQgY2FuIGJlIGluZmVycmVkIGZyb20g dGhlIG1lc3NhZ2UgdG8gbWFrZSBpdA0KPj4gPj4gPj4gPnJlYXNvbmFibGUgdG8gaGF2ZSBhIHZl cnNpb24gb2YgQ09TRSBtZXNzYWdlcyB3aGljaCBkbyBub3QgaGF2ZQ0KPj4gPj4gPj4gPmFueSBy ZWNpcGllbnQgaW5mb3JtYXRpb24gYXR0YWNoZWQgdG8gdGhlbS4NCj4+ID4+ID4+ID5JbiB0aGUg Y2FzZSBvZiBwdXJlIHVuaWNhc3QsIGl0IHdvdWxkIGJlIHVzZWQgZm9yIGF0IGxlYXN0IDUwJSBv Zg0KPj4gPj4gPj4gPnRoZSBtZXNzYWdlcyAoYSBoaWdoZXIgcGVyY2VudGFnZSBmb3Igb2JzZXJ2 aW5nIHN0YXRlKS4gIEFuZCBmb3INCj4+ID4+ID4+ID5tdWx0aWNhc3QgaXQgbWlnaHQgYmUgdXNl ZCBlaXRoZXIgZm9yIDUwJSBvciBhbGwgb2YgdGhlIG1lc3NhZ2VzDQo+PiA+PiA+PiA+ZGVwZW5k aW5nIG9uIGhvdyByZXNwb25zZXMgYXJlIGhhbmRsZWQuDQo+PiA+PiA+PiA+DQo+PiA+PiA+PiA+ SSBhbSBpbnRlcmVzdGVkIGluIHBlb3BsZSBsb29raW5nIGF0IG15IGFuYWx5c2lzIGFuZCB0ZWxs IG1lIGlmIEkNCj4+ID4+ID4+ID5hbSByaWdodCwgd3Jvbmcgb3IgdW5jbGVhci4NCj4+ID4+ID4+ DQo+PiA+PiA+Pg0KPj4gPj4gPj4gVGhlcmUgYXJlIGNhc2VzIHdoZXJlIG9wdGltaXplZCBtZXNz YWdlIGFuZCBjb250ZXh0IGlkZW50aWZpY2F0aW9uDQo+PiA+PiA+PmFyZSAgbmVlZGVkLCBvciB3 aGVyZSBhIGNvbnRleHQgaWRlbnRpZmllciBjb3VsZCBzaW1wbGlmeSB0aGUNCj4+ID4+ID4+cHJv Y2Vzc2luZy4gSW4gYm90aCAgY2FzZXMgYWxsb3dpbmcgb3B0aW9uYWwgaGVhZGVyIGluIHRoZQ0K Pj4gPj4gPj5DT1NFX2VuY3J5cHRlZCBmb3JtYXQgd291bGQgc29sdmUgdGhlICBwcm9ibGVtLiBG b3IgcmVwbGF5DQo+PiA+PiA+PnByb3RlY3Rpb24sIHNvbWUgY29udGV4dCBpbmZvcm1hdGlvbiBz dWNoIGFzIHNlcXVlbmNlICBudW1iZXIvbm9uY2UNCj4+ID4+ID4+bmVlZHMgYW55d2F5IHRvIGJl IHRyYW5zZmVycmVkLCBzbyBJIHdvdWxkIHNheSB0aGF0IHRoZSBjb250ZXh0DQo+PiA+PiA+PmNh bm5vdCBiZSBjb21wbGV0ZWx5IGltcGxpY2l0Lg0KPj4gPj4gPg0KPj4gPj4gPlllcywgc29tZSBp bnB1dCBpbnRvIGFuIElWIG5lZWRzIHRvIGJlIHRyYW5zZmVycmVkLCBidXQgSSB3b3VsZCBub3QN Cj4+ID4+ID5jb25zaWRlciB0aGF0IHRvIGJlIHBhcnQgb2YgdGhlIHNhdmVkIGNvbnRleHQuICAg VGhpcyBpcyBub3QgbmVlZGVkDQo+PmZvcg0KPj4gPj4gPnJlcGxheSBwcm90ZWN0aW9uIGFzIG11 Y2ggYXMgaXQgaXMgbmVlZGVkIGZvciBtYWtpbmcgc3VyZSB0aGF0IElWcw0KPj4gPj4gPmFyZSBu b3QgcmUtdXNlZC4gIFRoaXMgY291bGQgcG90ZW50aWFsbHkgYmUgZGlmZmVyZW50IGZyb20gdGhl DQo+PiA+PiA+c2VxdWVuY2UgbnVtYmVyIHVzZWQgZm9yIHJlcGxheSBwcm90ZWN0aW9uIGJ1dCBn ZW5lcmFsbHkgd291bGQgbm90DQo+PmJlLg0KPj4gPj4NCj4+ID4+IEFncmVlLg0KPj4gPj4NCj4+ ID4+ID4NCj4+ID4+ID5JIHdvdWxkIGV4cGVjdCB0aGF0IHlvdSB3b3VsZCBuZXZlciB3YW50IHRv IHNlbmQgaW5mb3JtYXRpb24geW91IGRvDQo+PiA+PiA+bm90IGhhdmUgdG8gc2luY2UgaXQgb25s eSBhZGRzIHNpemUuICBCdXQgc3RpbGwgdHJ5aW5nIHRvIGZpZ3VyZSBvdXQNCj4+ID4+ID53aGVy ZSBpdCBpcyBhbmQgaXMgbm90IG5lZWRlZCB0byBoYXZlIGEgY29udGV4dCBpZGVudGlmaWVyIHRv IGJlZ2luDQo+PndpdGguDQo+PiA+PiA+VGhlbiB3ZSBjYW4gZmlndXJlIG91dCB3aGVyZSBhbmQg aWYgaXQgbWFrZXMgc2Vuc2UgdG8gaW5jbHVkZSBpdC4NCj4+ID4+ID5CdXQgYXQgdGhhdCBwb2lu dCB5b3UgYXJlIGFscmVhZHkgdGFsa2luZyBhYm91dCB0YWtpbmcgc2l6ZSBoaXRzLg0KPj4gPj4N Cj4+ID4+IFRva2VuIGNvdWxkIGRvdWJsZSBwbGF5IGFzIGluZGljYXRpb24gb2YgY29udGV4dCBp ZGVudGlmaWVyLCBidXQgbm90DQo+PiA+PmFsd2F5cywgbm90ICBmb3IgZnJlZSwgYW5kIGFsc28g bWF5IGxlYWQgdG8gc29tZSBJTUhPIGNvbmZ1c2luZw0KPj4gPj5jb25zdHJhaW50cyBzdWNoIGFz ICBkaWZmZXJlbnQgbWVzc2FnZSBmb3JtYXRzIGZvciByZXF1ZXN0IGFuZA0KPj4gPj5yZXNwb25z ZS4NCj4+ID4+DQo+PiA+PiBBcyBJIHVuZGVyc3Rvb2Qgb25lIHJlYXNvbiB3aHkgQ09TRV9lbmNy eXB0ZWQgd2FzIGludHJvZHVjZWQgd2FzIHRvDQo+PiA+Pm1lZXQgYSAgcmVxdWVzdCBmb3IgYSBt b3JlIGNvbXBhY3QgZm9ybWF0IGluIHNldHRpbmdzIHdoZXJlIGNvbnRleHQgaXMNCj4+ID4+YWxy ZWFkeSAgZXN0YWJsaXNoZWQuIE5vdCBzZW5kaW5nIGNvbnRleHQgaWRlbnRpZmllciBtYXkgYmUg YW4NCj4+ID4+b3B0aW1pemF0aW9uIGluIHNvbWUgIHNldHRpbmdzLCBidXQgdGhhdCBmb3JtYXQg d291bGQgYmUgb2YgbXVjaCBsZXNzDQo+PiA+PnVzZSBpZiBhIGNvbnRleHQgaWRlbnRpZmllciBj YW5ub3QgIGJlIGluY2x1ZGVkLg0KPj4gPj4NCj4+ID4+DQo+PiA+PiBHw7ZyYW4NCj4+ID4NCj4N Cg0K From nobody Fri Sep 18 07:25: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 EBBD91B2C99 for ; Fri, 18 Sep 2015 07:25:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.452 X-Spam-Level: X-Spam-Status: No, score=0.452 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_CHARSET_FARAWAY=2.45, 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 JVdd7hFa72BC for ; Fri, 18 Sep 2015 07:25:13 -0700 (PDT) Received: from out4133-50.mail.aliyun.com (out4133-50.mail.aliyun.com [42.120.133.50]) by ietfa.amsl.com (Postfix) with ESMTP id 1CA091B2CD4 for ; Fri, 18 Sep 2015 07:25:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alibaba-inc.com; s=default; t=1442586312; h=Date:Subject:From:To:Message-ID:Mime-version:Content-type; bh=F7aQfPc3m0ibnYdFZPrBbGQdk4naA5CDrDMVoVW54aE=; b=mcmjLSq8eQGd+OwPvtlo1yWkSEQFMvW9/h1mDuNBz/o3dayFYhw19hCRu8QmwK+axOH12HdhsGWJmzMW/GZeMxuqFzNm5XzL3JhqndM45OSwAO3eOxsQ/Jk6ZupSQ5RVyO8tW1kvJwyY9UCr7JSdGDEQ5o+IE8C8hKELJOEMfV4= X-Alimail-AntiSpam: AC=PASS; BC=-1|-1; BR=01201311R631e4; FP=0|-1|-1|-1|0|-1|-1|-1; HT=e02c03282; MF=kepeng.lkp@alibaba-inc.com; NM=1; PH=DS; RN=1; SR=0; Received: from 10.22.58.231(mailfrom:kepeng.lkp@alibaba-inc.com ip:42.120.73.208) by smtp.aliyun-inc.com(127.0.0.1); Fri, 18 Sep 2015 22:25:09 +0800 User-Agent: Microsoft-MacOutlook/14.4.8.150116 Date: Fri, 18 Sep 2015 22:25:05 +0800 From: "Kepeng Li" To: "ace@ietf.org" Message-ID: Thread-Topic: [Ace] Second WGLC for draft-ietf-ace-usecases-05 Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3525459909_37936179" Archived-At: Subject: Re: [Ace] Second WGLC for draft-ietf-ace-usecases-05 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, 18 Sep 2015 14:25:15 -0000 > 此邮件使用 MIME 格式。由于邮件阅读程序不能识别 此格式，因此，可能无法识别该邮件的分部或部分内容。 --B_3525459909_37936179 Content-type: text/plain; charset="GB2312" Content-transfer-encoding: quoted-printable Hello Ludwig and all, I notice that my comments to U5.5, U7.3, U7.4, U5.8 are not resolved. Please refer to:=20 https://mailarchive.ietf.org/arch/msg/ace/cAfYmCEbxkEky6VN05EEfSiBkRs https://mailarchive.ietf.org/arch/msg/ace/9-hUWdnUNLQh2p4BCozQrtg0Wvc Thanks, Kind Regards Kepeng =B7=A2=BC=FE=C8=CB: Li Kepeng =C8=D5=C6=DA: Thursday, 3 September, 2015 7:54 am =D6=C1: "ace@ietf.org" =D6=F7=CC=E2: [Ace] Second WGLC for draft-ietf-ace-usecases-05 Hi all, We would like to start a second WGLC on draft-ietf-ace-usecases-05. https://datatracker.ietf.org/doc/draft-ietf-ace-usecases/ This will be a 2-week last call, so it will end on Friday, September 18. Please send comments to the list. Thanks! Ciao Hannes & Kepeng _______________________________________________ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace --B_3525459909_37936179 Content-type: text/html; charset="GB2312" Content-transfer-encoding: quoted-printable
Hello Ludwig and all,
=
I notice that my comments to U5.5, U7.3, U7.4, U5.8 are not r= esolved.

Please refer to: 
https://mailarchive.ietf.org/arch/msg/ace/9-hUWdnUNLQh2p4BCozQrtg0Wvc=

Thanks,

Kind Regards<= /div>
Kepeng

=B7=A2=BC=FE=C8=CB: Li Kepeng <kepeng.lkp@al= ibaba-inc.com>
=C8=D5=C6=DA: Thursd= ay, 3 September, 2015 7:54 am
=D6=C1: = "ace@ietf.org" <ace@ietf.org>
=D6=F7=CC=E2: = [Ace] Second WGLC for draft-ietf-ace-usecases-05

Hi all,

We would like= to start a second WGLC on draft-ietf-ace-usecases-05.
<= div style=3D"font-family: =CB=CE=CC=E5;">
Thi= s will be a 2-week last call, so it will end on Friday, September 18.
<= div style=3D"font-family: =CB=CE=CC=E5;">
Ple= ase send comments to the list.

Thanks!

Ciao
Hannes & Kepeng
_______________________________________________ Ace mailing list Ace@ietf.org https://www.ietf.org/ma= ilman/listinfo/ace --B_3525459909_37936179-- From nobody Sat Sep 19 19:53: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 940B11B364A for ; Sat, 19 Sep 2015 19:53:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.1 X-Spam-Level: X-Spam-Status: No, score=0.1 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 zEkfnRL0Mum6 for ; Sat, 19 Sep 2015 19:53:50 -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 0ADA91B2D06 for ; Sat, 19 Sep 2015 19:53:50 -0700 (PDT) Received: from hebrews (173-12-183-193-oregon.hfc.comcastbusiness.net [173.12.183.193]) (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 7A6292CA17 for ; Sat, 19 Sep 2015 19:53:49 -0700 (PDT) From: "Jim Schaad" To: Date: Sat, 19 Sep 2015 19:51:27 -0700 Message-ID: <021b01d0f34f$3ef676d0$bce36470$@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: AdDzTJuCqeOcgZ3iQWWV4hFj3veTUQ== Archived-At: Subject: [Ace] End-to-End Scenarios 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, 20 Sep 2015 02:53:51 -0000 The previous discussion got sidetracked from where it really needed to go. So I want to do a restart and focus on a different aspect. In order to evaluate a solution, one needs to have as comprehensive list of the unique scenarios where the solution needs to function. I want to try and get some help in building this list. The list will also need to include some security constructs that may be included. I am assuming that there has been something that created the security context and that the security context is distributed to the correct entities. (I understand that one variation for doing so assumes that the context may be relayed to the server via the client.) I think the list starts as follows: 1. One way command: This covers Put, Delete and so forth. C1 sends a command to S1. S1 can 1) not reply, 2) reply success, 3) reply failure 2. Query/Response: This covers Get C1 requests R1 from S1. S1 can 1) reply with data, 2) reply with failure. 3. Observation: C1 observes R1 on S1. S1 can 1) reply with data, 2) reply with failure, 3) reply success but no data (?) C1 cancels observe of R1 on S1 S1 can 1) reply with success, 2) reply with failure S1 sends data on R1 to C1 4. Observation with data server: C1 observes R1 from S1 on S2 S2 can 1) reply with data, 2) reply with failure, 3) reply success but no data C1 cancels observing R1 S2 can 1) reply with success, 2) reply with failure S2 send data about R1 to C1 ** S2 may not have access to data about R1 ** Security context to communicate with S1 and S2 from C1 may be different and not overlap ** S2 may be required to verify data came from S1, but not be able to access R1. 5. Use of a Proxy Server All of cases 1 through 4 need to be repeated but with a proxy server P1 between C1 and the entity it is talking to. What operations and data flows am I still missing? Jim From nobody Sun Sep 20 02:44: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 90D911B45F6 for ; Sun, 20 Sep 2015 02:44:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.15 X-Spam-Level: X-Spam-Status: No, score=-0.15 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, 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 VMAut6qq2sa5 for ; Sun, 20 Sep 2015 02:44:47 -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 BEEAA1B45F5 for ; Sun, 20 Sep 2015 02:44:46 -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 t8K9idVT009332; Sun, 20 Sep 2015 11:44:39 +0200 (CEST) Received: from aung.tzi.org (p57A63B54.dip0.t-ipconnect.de [87.166.59.84]) (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 3nJkWq3xhQz1xPb; Sun, 20 Sep 2015 11:44:39 +0200 (CEST) From: Olaf Bergmann To: "Jim Schaad" References: <007901d0eea4$25989bf0$70c9d3d0$@augustcellars.com> <002b01d0ef07$aced5970$06c80c50$@augustcellars.com> <01b601d0eff2$120843c0$3618cb40$@augustcellars.com> <55FAA1B1.5020004@tzi.de> <55FB0142.5030303@tzi.de> <011e01d0f191$ac1edc80$045c9580$@augustcellars.com> Date: Sun, 20 Sep 2015 11:44:38 +0200 In-Reply-To: <011e01d0f191$ac1edc80$045c9580$@augustcellars.com> (Jim Schaad's message of "Thu, 17 Sep 2015 14:41:54 -0700") Message-ID: <87wpvla0hl.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] Looking at COSE based unicast and multicast 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, 20 Sep 2015 09:44:48 -0000 "Jim Schaad" writes: >> -----Original Message----- >> From: Stefanie Gerdes [mailto:gerdes@tzi.de] >> Sent: Thursday, September 17, 2015 11:07 AM >> To: G=C3=B6ran Selander ; Jim Schaad >> ; ace@ietf.org >> Subject: Re: [Ace] Looking at COSE based unicast and multicast [...] >> I guess your example refers to item 3 in the list I send: The server >> needs to know >> if a received request belongs to an existing context and use the respect= ive >> keying material etc for its answer? Sounds reasonable to me that we >> would need >> some kind of identifier for that. Is that what you were discussing about? > > This is part of the discussion. You are current in the original > analysis that DTLS has this implicitly known. I believe that in many > cases this will also be true for the object version as well. This would also be my goal as a COSE user as it not only saves precious bandwidth but also helps minimizing complexity. Gr=C3=BC=C3=9Fe Olaf From nobody Mon Sep 21 02:04: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 B0BA21A8F45 for ; Mon, 21 Sep 2015 02:04:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.1 X-Spam-Level: X-Spam-Status: No, score=0.1 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 1fplGczSDX9i for ; Mon, 21 Sep 2015 02:04:55 -0700 (PDT) Received: from mail-la0-f45.google.com (mail-la0-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 7D7031A8F3D for ; Mon, 21 Sep 2015 02:04:55 -0700 (PDT) Received: by lamp12 with SMTP id p12so62722620lam.0 for ; Mon, 21 Sep 2015 02:04:53 -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=NJeWRFgG2PnXUZB0Qd5JA5BITr1uXbIsIZ419NkPfFk=; b=IyFSpPpyRIgSQ99dnxTu4sFT6/IP2Ez02+JOjmRAzqIDIQQfhVwj6RrGc5ZvmkQt/X fuddInGIiSv9WWHXuhtEe7Ve9E1bu7ARdlUL2xpx7zvFT4cyw6t+KCS/U7Sm5z79vGRE lQ/z9x5OAgWN+PIzK14TGBvJtT071uH0nb2IQcipID9cBCmh73ZqqznCcsjQyKRRjmUU nGJ2kJYFSGx59tpOFtkP5wkUeZ2Cn/6XzaDEolV5mFvKh/waSeuqVwMhvF6hbqb/4jCD //obeWU+1mtYMCks+5O5KvuDEipEOy758lv0ysecFifBdL587vmLEgbI3VwEE1WdTQ6p BZrw== X-Gm-Message-State: ALoCoQlpwh6FwGGm3BTbeOcoUmWW92i8856M7bqXoyKT/UAN5Qy8JWNp6Dj1AY2341EF1OEHHHoP X-Received: by 10.152.23.167 with SMTP id n7mr7103364laf.18.1442826293330; Mon, 21 Sep 2015 02:04:53 -0700 (PDT) Received: from [192.168.0.108] ([85.235.11.178]) by smtp.gmail.com with ESMTPSA id v10sm3408658lbo.25.2015.09.21.02.04.52 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 21 Sep 2015 02:04:52 -0700 (PDT) To: ace@ietf.org, Stefanie Gerdes References: From: Ludwig Seitz Message-ID: <55FFC833.7080102@sics.se> Date: Mon, 21 Sep 2015 11:04:51 +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="------------ms030700050708010300090603" Archived-At: Subject: Re: [Ace] Second WGLC for draft-ietf-ace-usecases-05 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, 21 Sep 2015 09:04:57 -0000 This is a cryptographically signed message in MIME format. --------------ms030700050708010300090603 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable On 2015-09-18 16:25, Kepeng Li wrote: > Hello Ludwig and all, > > I notice that my comments to U5.5, U7.3, U7.4, U5.8 are not resolved. > > Please refer to: > https://mailarchive.ietf.org/arch/msg/ace/cAfYmCEbxkEky6VN05EEfSiBkRs > https://mailarchive.ietf.org/arch/msg/ace/9-hUWdnUNLQh2p4BCozQrtg0Wvc > > Thanks, > > Kind Regards > Kepeng > Hello Kepeng, I had misunderstood Steffi thinking she already addressed all your=20 comments. I'll take these into account as well when I do the revision. /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 --------------ms030700050708010300090603 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 DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE1MDkyMTA5MDQ1MVowLwYJKoZI hvcNAQkEMSIEIPkNNfJxsNo8zOUynKsj94EJkFHw4AkLgxnb1zKYGm1IMGwGCSqGSIb3DQEJ DzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0D AgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgaUGCSsGAQQB gjcQBDGBlzCBlDCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzAp BgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0 YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgMMhpgwgacG CyqGSIb3DQEJEAILMYGXoIGUMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20g THRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG A1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EC AwyGmDANBgkqhkiG9w0BAQEFAASCAQCNRH16Bq68H1YvU5ol4svkBChwdm8F7vKIBN/FU2q4 WlAAjtdMgf5DY29SXxY2IuyFG/znf8XaYbyf0kUT0baBNGhpGBhwkdqWeWIRVoGtu2k84kwo XqhJTVelPd5ZhZ17uOiZ9kdTLJs4bT72eov6WkMTnvOrRB1d4+VScL6HuHWDAADiJcPcVmsH DGWJ/Q7p/YeNBrSl6CiGXqG3gebkMnLLl3l++bHlu2rb6D42ricWs6tfRcwmomijdnjZWWIv T8RHT7Ozae6S1MDlwSxgi4n2WQY5/yRwDupvLNIQjr9c6EsGc7eacKp2VR2Jl26BjEtMeox8 h+duCi9AU2kxAAAAAAAA --------------ms030700050708010300090603-- From nobody Mon Sep 21 06:30: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 45DC41B318E for ; Mon, 21 Sep 2015 06:30:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.349 X-Spam-Level: X-Spam-Status: No, score=0.349 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, 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 65QPNv642U6z for ; Mon, 21 Sep 2015 06:30:03 -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 C5EA91B318D for ; Mon, 21 Sep 2015 06:30:02 -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 t8LDTQxf016761; Mon, 21 Sep 2015 15:29:27 +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 3nKRSk5NwQz2Qn5; Mon, 21 Sep 2015 15:29:26 +0200 (CEST) From: Olaf Bergmann To: "Jim Schaad" References: <021b01d0f34f$3ef676d0$bce36470$@augustcellars.com> Date: Mon, 21 Sep 2015 15:29:26 +0200 In-Reply-To: <021b01d0f34f$3ef676d0$bce36470$@augustcellars.com> (Jim Schaad's message of "Sat, 19 Sep 2015 19:51:27 -0700") Message-ID: <874minlx3d.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] End-to-End Scenarios 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, 21 Sep 2015 13:30:05 -0000 Jim, "Jim Schaad" writes: > comprehensive list of the unique scenarios where the solution needs to > function Thank you for getting the focus back to the problem that is to be solved. I think that your list pretty much covers the scenarios that have been discussed in ACE so far. Two comments follow inline: > 1. One way command: This covers Put, Delete and so forth. > C1 sends a command to S1. S1 can 1) not reply, 2) reply success, > 3) reply failure A REST-style protocol does not allow "not reply" per se but it might be important to keep in mind that an implementation might choose to send no reply, and for CoAP, the client even may suggest this by sending the No-Response option. But then, this also holds for the other top-level list items and observation cancellation (although it does not make sense for all of them.) In short: I do not think that we need to list the "not reply" scenario but keep in mind that S always may decide to send no response. > 2. Query/Response: This covers Get > C1 requests R1 from S1. S1 can 1) reply with data, 2) reply with > failure. > > 3. Observation: > C1 observes R1 on S1. > S1 can 1) reply with data, 2) reply with failure, 3) reply > success but no data (?) Yes -- it's in the discretion of S1 to put any data into its response, i.e. it could be empty as well. This makes 3) a valid subset of 1). (And it may be useful to list this explicitely as done here.) > C1 cancels observe of R1 on S1=20 > S1 can 1) reply with success, 2) reply with failure > S1 sends data on R1 to C1 > > 4. Observation with data server: > C1 observes R1 from S1 on S2 > S2 can 1) reply with data, 2) reply with failure, 3) reply > success but no data > C1 cancels observing R1 > S2 can 1) reply with success, 2) reply with failure > S2 send data about R1 to C1 > ** S2 may not have access to data about R1 > ** Security context to communicate with S1 and S2 from C1 may be > different and not overlap > ** S2 may be required to verify data came from S1, but not be able > to access R1. > > 5. Use of a Proxy Server > All of cases 1 through 4 need to be repeated but with a proxy server > P1 between C1 and the entity it is talking to. > > What operations and data flows am I still missing? Gr=C3=BC=C3=9Fe Olaf From nobody Mon Sep 21 19:56: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 AE72B1A86DF for ; Mon, 21 Sep 2015 19:56:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.8 X-Spam-Level: X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 wRPrW7Zj9xv4 for ; Mon, 21 Sep 2015 19:56:13 -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 D01BB1A70FE for ; Mon, 21 Sep 2015 19:56:13 -0700 (PDT) Received: from hebrews (173-8-216-38-Oregon.hfc.comcastbusiness.net [173.8.216.38]) (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 07B4C38EE9; Mon, 21 Sep 2015 19:56:12 -0700 (PDT) From: "Jim Schaad" To: "'Olaf Bergmann'" References: <021b01d0f34f$3ef676d0$bce36470$@augustcellars.com> <874minlx3d.fsf@aung.informatik.uni-bremen.de> In-Reply-To: <874minlx3d.fsf@aung.informatik.uni-bremen.de> Date: Mon, 21 Sep 2015 19:53:47 -0700 Message-ID: <048001d0f4e1$e7604790$b620d6b0$@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: AQIWMh3Pv5gwExSgDndbS6D7wY2CTAGWoHHenbCogwA= Archived-At: Cc: ace@ietf.org Subject: Re: [Ace] End-to-End Scenarios 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, 22 Sep 2015 02:56:16 -0000 > -----Original Message----- > From: Olaf Bergmann [mailto:bergmann@tzi.org] > Sent: Monday, September 21, 2015 6:29 AM > To: Jim Schaad > Cc: ace@ietf.org > Subject: Re: [Ace] End-to-End Scenarios >=20 > Jim, >=20 > "Jim Schaad" writes: >=20 > > comprehensive list of the unique scenarios where the solution needs = to > > function >=20 > Thank you for getting the focus back to the problem that is to be = solved. I think > that your list pretty much covers the scenarios that have been = discussed in ACE > so far. >=20 > Two comments follow inline: >=20 > > 1. One way command: This covers Put, Delete and so forth. > > C1 sends a command to S1. S1 can 1) not reply, 2) reply success, > > 3) reply failure >=20 > A REST-style protocol does not allow "not reply" per se but it might = be important > to keep in mind that an implementation might choose to send no reply, = and for > CoAP, the client even may suggest this by sending the No-Response = option. But > then, this also holds for the other top-level list items and = observation > cancellation (although it does not make sense for all of them.) >=20 > In short: I do not think that we need to list the "not reply" scenario = but keep in > mind that S always may decide to send no response. I had not been thinking in terms of what S1 chose to do when I wrote = that, but in terms of fact that CoAP provides for a confirmable version = of operations. However, the main reason was to be exhaustive. It may = be that we need to think about different implications of S1 replying or = not replying in terms of security properties. I have no idea if this is = going to be true however. >=20 > > 2. Query/Response: This covers Get > > C1 requests R1 from S1. S1 can 1) reply with data, 2) reply with > > failure. > > > > 3. Observation: > > C1 observes R1 on S1. > > S1 can 1) reply with data, 2) reply with failure, 3) reply success > > but no data (?) >=20 > Yes -- it's in the discretion of S1 to put any data into its response, = i.e. it could be > empty as well. This makes 3) a valid subset of 1). (And it may be = useful to list this > explicitely as done here.) Good to know. I wasn't sure if that was the case without the proxy. >=20 > > C1 cancels observe of R1 on S1 > > S1 can 1) reply with success, 2) reply with failure > > S1 sends data on R1 to C1 > > > > 4. Observation with data server: > > C1 observes R1 from S1 on S2 > > S2 can 1) reply with data, 2) reply with failure, 3) reply success > > but no data > > C1 cancels observing R1 > > S2 can 1) reply with success, 2) reply with failure > > S2 send data about R1 to C1 > > ** S2 may not have access to data about R1 > > ** Security context to communicate with S1 and S2 from C1 may be > > different and not overlap > > ** S2 may be required to verify data came from S1, but not be able = to > > access R1. > > > > 5. Use of a Proxy Server > > All of cases 1 through 4 need to be repeated but with a proxy = server > > P1 between C1 and the entity it is talking to. > > > > What operations and data flows am I still missing? >=20 >=20 > Gr=C3=BC=C3=9Fe > Olaf From nobody Mon Sep 21 21:44: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 4D6231A8A10 for ; Mon, 21 Sep 2015 21:44:55 -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 NOuTJzDw9UGF for ; Mon, 21 Sep 2015 21:44:53 -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 108FC1A8A0D for ; Mon, 21 Sep 2015 21:44:52 -0700 (PDT) X-AuditID: c1b4fb3a-f79136d0000071e2-1c-5600dcc2d708 Received: from ESESSHC021.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 11.8C.29154.2CCD0065; Tue, 22 Sep 2015 06:44:50 +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; Tue, 22 Sep 2015 06:44:50 +0200 From: =?utf-8?B?R8O2cmFuIFNlbGFuZGVy?= To: Jim Schaad , "ace@ietf.org" Thread-Topic: [Ace] End-to-End Scenarios Thread-Index: AdDzTJuCqeOcgZ3iQWWV4hFj3veTUQBpM2AA Date: Tue, 22 Sep 2015 04:44:50 +0000 Message-ID: References: <021b01d0f34f$3ef676d0$bce36470$@augustcellars.com> In-Reply-To: <021b01d0f34f$3ef676d0$bce36470$@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.150] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpmkeLIzCtJLcpLzFFi42KZGfG3RvfQHYYwg7fNthbfv/UwW6ye/p3N gclj45zpbB5LlvxkCmCK4rJJSc3JLEst0rdL4Mp48Ogte8ErlYqex0tZGhg/KHcxcnJICJhI HN99nBXCFpO4cG89WxcjF4eQwFFGidvde9hBEkICSxgl9myyBbHZBFwkHjQ8YgKxRQTcJM5O XsYCYgsLqEtsOP0VKq4hMWXOO2YI20hi1v3nbCA2i4CqxO8nj8DqeQUsJNadnc0CMd9e4tGM Z2C9nAIOEl+//GYEsRmBDvp+ag1YnFlAXOLWk/lMEIcKSCzZc54ZwhaVePn4H9gDogJ6Eiuv N7FBxJUkVmy/BDSHA6hXU2L9Ln2IMdYS6363QI1UlJjS/ZAd4hxBiZMzn7BMYBSfhWTbLITu WUi6ZyHpnoWkewEj6ypG0eLU4uLcdCMjvdSizOTi4vw8vbzUkk2MwFg7uOW31Q7Gg88dDzEK cDAq8fAqbGMIE2JNLCuuzD3EKM3BoiTO28z0IFRIID2xJDU7NbUgtSi+qDQntfgQIxMHp1QD 4zL3bWa9F06XvvJOUlaM8VJ/nsb41dmzeMHLwOk+n4xynu197LvjamfaxsRWMcGfDAEsZry2 PFNObzV+G8zzgiXCYiGHz54UzafaQks3Cle/Tly87pHq6QV7pl6ctF0vfJPZ8heLmRqdeC5L 2y2+MocxRbb8zJ70A0Ublqx8F/UhULis9qlgpRJLcUaioRZzUXEiAK6d9HiWAgAA Archived-At: Subject: Re: [Ace] End-to-End Scenarios 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, 22 Sep 2015 04:44:55 -0000 DQoNCk9uIDIwMTUtMDktMjAgMDQ6NTEsICJKaW0gU2NoYWFkIiA8aWV0ZkBhdWd1c3RjZWxsYXJz LmNvbT4gd3JvdGU6DQoNCj5UaGUgcHJldmlvdXMgZGlzY3Vzc2lvbiBnb3Qgc2lkZXRyYWNrZWQg ZnJvbSB3aGVyZSBpdCByZWFsbHkgbmVlZGVkIHRvIGdvLg0KPlNvIEkgd2FudCB0byBkbyBhIHJl c3RhcnQgYW5kIGZvY3VzIG9uIGEgZGlmZmVyZW50IGFzcGVjdC4gIEluIG9yZGVyIHRvDQo+ZXZh bHVhdGUgYSBzb2x1dGlvbiwgb25lIG5lZWRzIHRvIGhhdmUgYXMgY29tcHJlaGVuc2l2ZSBsaXN0 IG9mIHRoZSB1bmlxdWUNCj5zY2VuYXJpb3Mgd2hlcmUgdGhlIHNvbHV0aW9uIG5lZWRzIHRvIGZ1 bmN0aW9uLiAgSSB3YW50IHRvIHRyeSBhbmQgZ2V0DQo+c29tZQ0KPmhlbHAgaW4gYnVpbGRpbmcg dGhpcyBsaXN0LiAgVGhlIGxpc3Qgd2lsbCBhbHNvIG5lZWQgdG8gaW5jbHVkZSBzb21lDQo+c2Vj dXJpdHkgY29uc3RydWN0cyB0aGF0IG1heSBiZSBpbmNsdWRlZC4gICBJIGFtIGFzc3VtaW5nIHRo YXQgdGhlcmUgaGFzDQo+YmVlbiBzb21ldGhpbmcgdGhhdCBjcmVhdGVkIHRoZSBzZWN1cml0eSBj b250ZXh0IGFuZCB0aGF0IHRoZSBzZWN1cml0eQ0KPmNvbnRleHQgaXMgZGlzdHJpYnV0ZWQgdG8g dGhlIGNvcnJlY3QgZW50aXRpZXMuICAoSSB1bmRlcnN0YW5kIHRoYXQgb25lDQo+dmFyaWF0aW9u IGZvciBkb2luZyBzbyBhc3N1bWVzIHRoYXQgdGhlIGNvbnRleHQgbWF5IGJlIHJlbGF5ZWQgdG8g dGhlDQo+c2VydmVyDQo+dmlhIHRoZSBjbGllbnQuKQ0KDQpKdXN0IHRvIGJlIGNsZWFyLCB0aGVy ZSBhcmUgQUNFIHVzZSBjYXNlcyB3aGVyZSBhIGNsaWVudCBhbmQgYSBzZXJ2ZXIgZG9lcw0Kbm90 IGhhdmUgY29udGV4dCB3aXRoIGVhY2ggb3RoZXIsIGFuZCB3ZSBuZWVkIHN1cHBvcnQgZnJvbSBD T1NFIHRvDQplc3RhYmxpc2ggdGhhdCB1c2luZyBhIFRUUCwgYnV0IEkgdW5kZXJzdGFuZCBpZiB5 b3UgZG9u4oCZdCB3YW50IHRvIGRpc2N1c3MNCnRoYXQgaW4gdGhpcyBtYWlsIHRocmVhZC4NCg0K Pg0KPkkgdGhpbmsgdGhlIGxpc3Qgc3RhcnRzIGFzIGZvbGxvd3M6DQo+DQo+MS4gIE9uZSB3YXkg Y29tbWFuZDogVGhpcyBjb3ZlcnMgUHV0LCBEZWxldGUgYW5kIHNvIGZvcnRoLg0KPglDMSBzZW5k cyBhIGNvbW1hbmQgdG8gUzEuICAgUzEgY2FuIDEpIG5vdCByZXBseSwgMikgcmVwbHkgc3VjY2Vz cywNCj4zKSByZXBseSBmYWlsdXJlDQo+DQo+Mi4gIFF1ZXJ5L1Jlc3BvbnNlOiAgVGhpcyBjb3Zl cnMgR2V0DQo+CUMxIHJlcXVlc3RzIFIxIGZyb20gUzEuICBTMSBjYW4gMSkgcmVwbHkgd2l0aCBk YXRhLCAyKSByZXBseSB3aXRoDQo+ZmFpbHVyZS4NCg0KDQpJIGRvbuKAmXQgdW5kZXJzdGFuZCB0 aGUgZGlzdGluY3Rpb24gYmV0d2VlbiAiY29tbWFuZCB3aXRoIHJlcGx54oCdIGluIDEuIGFuZA0K IlF1ZXJ5L1Jlc3BvbnNl4oCdIGluIDIuDQoNCkRvIHlvdSBjb25zaWRlciBQT1NUIGJlIG9mIHR5 cGUgMS4gb3IgdHlwZSAyLiwgb3IgZG9lc27igJl0IGl0IG1hdHRlcj8NCg0KDQpJbiB0ZXJtcyBv ZiBzZWN1cml0eSBjb25zdHJ1Y3RzLCB0aGVyZSBpcyBhIG5lZWQgZm9yIGEgMi1wYXNzIFBVVA0K UXVlcnkvUmVzcG9uc2UgKGUuZy4gIkxvY2sgYSBkb29yIikgLCB3aGVyZWFzIEdFVCBSZXNwb25z ZSBjb3VsZCBiZSBhDQoxLXBhc3Mgc2VjdXJlIG1lc3NhZ2UgKHByb3Blcmx5IGlkZW50aWZpZWQg YW5kIHZlcnNpb25lZCkgcHJlY2VkZWQgYnkgYW4NCnVucHJvdGVjdGVkIEdFVCBSZXF1ZXN0LiBC dXQgbWF5YmUgdGhpcyBjb21lcyBsYXRlcj8gKFRoZXJlIGlzIGFsc28gYQ0KNC1wYXNzIOKAnFVu bG9jayBhIGRvb3IiLCBidXQgSSBkb27igJl0IHRoaW5rIHRoYXQgc2hvdWxkIGJlIHNvbHZlZCBi eSBDT1NFLikNCg0KDQo+DQo+My4gIE9ic2VydmF0aW9uOg0KPglDMSBvYnNlcnZlcyBSMSBvbiBT MS4NCj4JCVMxIGNhbiAxKSByZXBseSB3aXRoIGRhdGEsIDIpIHJlcGx5IHdpdGggZmFpbHVyZSwg MykgcmVwbHkNCj5zdWNjZXNzIGJ1dCBubyBkYXRhICg/KQ0KPglDMSBjYW5jZWxzIG9ic2VydmUg b2YgUjEgb24gUzENCj4JCVMxIGNhbiAxKSByZXBseSB3aXRoIHN1Y2Nlc3MsIDIpIHJlcGx5IHdp dGggZmFpbHVyZQ0KPglTMSBzZW5kcyBkYXRhIG9uIFIxIHRvIEMxDQo+DQo+NC4gIE9ic2VydmF0 aW9uIHdpdGggZGF0YSBzZXJ2ZXI6DQo+CUMxIG9ic2VydmVzIFIxIGZyb20gUzEgb24gUzINCj4J CVMyIGNhbiAxKSByZXBseSB3aXRoIGRhdGEsIDIpIHJlcGx5IHdpdGggZmFpbHVyZSwgMykgcmVw bHkNCj5zdWNjZXNzIGJ1dCBubyBkYXRhDQo+CUMxIGNhbmNlbHMgb2JzZXJ2aW5nIFIxDQo+CQlT MiBjYW4gMSkgcmVwbHkgd2l0aCBzdWNjZXNzLCAyKSByZXBseSB3aXRoIGZhaWx1cmUNCj4JUzIg c2VuZCBkYXRhIGFib3V0IFIxIHRvIEMxDQo+CSoqIFMyIG1heSBub3QgaGF2ZSBhY2Nlc3MgdG8g ZGF0YSBhYm91dCBSMQ0KPgkqKiBTZWN1cml0eSBjb250ZXh0IHRvIGNvbW11bmljYXRlIHdpdGgg UzEgYW5kIFMyIGZyb20gQzEgbWF5IGJlDQo+ZGlmZmVyZW50IGFuZCBub3Qgb3ZlcmxhcA0KPgkq KiBTMiBtYXkgYmUgcmVxdWlyZWQgdG8gdmVyaWZ5IGRhdGEgY2FtZSBmcm9tIFMxLCBidXQgbm90 IGJlIGFibGUNCj50byBhY2Nlc3MgUjEuDQoNCg0KU2luY2UgeW91IHdhbnQgdG8gYmUgZXhoYXVz dGl2ZSwgdGhlcmUgYXJlIG9wZXJhdGlvbnMgYmV0d2VlbiBSZXNvdXJjZQ0KU2VydmVyIChTMSkg YW5kIERhdGEgU2VydmVyIChTMikuDQpNYXBwaW5nIGJldHdlZW4geW91ciBub3RhdGlvbiBhbmQg bm90YXRpb24gb2YgZHJhZnQtaWV0Zi1hY2UtYWN0b3JzOg0KDQpDMSBpbiBBQ0UgQzsgDQoNClMx IGluIEFDRSBSUzsgDQoNClMyIGluIERhdGEgU2VydmVyOyANCg0KDQpBbHRlcm5hdGl2ZSBkYXRh IGZsb3dzOg0KDQpDMiBpbiBEYXRhIFNlcnZlciByZXF1ZXN0cyB3aXRoIEdFVCAob3B0aW9uYWxs eSBPYnNlcnZlKSB0byBTMSBpbiBBQ0UgUlM7DQoNCkMzIGluIEFDRSBSUyByZXF1ZXN0cyB3aXRo IFBVVC9QT1NUIHRvIFMzIChwb3RlbnRpYWxseSBTMikgaW4gRGF0YSBTZXJ2ZXI7DQoNCg0KDQpH w7ZyYW4NCg0KDQoNCj4NCj41LiAgVXNlIG9mIGEgUHJveHkgU2VydmVyDQo+CUFsbCBvZiBjYXNl cyAxIHRocm91Z2ggNCBuZWVkIHRvIGJlIHJlcGVhdGVkIGJ1dCB3aXRoIGEgcHJveHkgc2VydmVy DQo+UDEgYmV0d2VlbiBDMSBhbmQgdGhlIGVudGl0eSBpdCBpcyB0YWxraW5nIHRvLg0KPg0KPldo YXQgb3BlcmF0aW9ucyBhbmQgZGF0YSBmbG93cyBhbSBJIHN0aWxsIG1pc3Npbmc/DQo+DQo+Smlt DQo+DQo+DQo+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N Cj5BY2UgbWFpbGluZyBsaXN0DQo+QWNlQGlldGYub3JnDQo+aHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9hY2UNCg0K From nobody Mon Sep 21 22:40: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 588781A8BB0 for ; Mon, 21 Sep 2015 22:40:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.6 X-Spam-Level: X-Spam-Status: No, score=-1.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 gR7m5BdvvmFm for ; Mon, 21 Sep 2015 22:40:18 -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 DEB8D1A8AFA for ; Mon, 21 Sep 2015 22:40:18 -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 56B4238EF3; Mon, 21 Sep 2015 22:40:18 -0700 (PDT) From: "Jim Schaad" To: =?utf-8?Q?'G=C3=B6ran_Selander'?= , References: <021b01d0f34f$3ef676d0$bce36470$@augustcellars.com> In-Reply-To: Date: Mon, 21 Sep 2015 22:37:53 -0700 Message-ID: <049601d0f4f8$d40e7b50$7c2b71f0$@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: AQIWMh3Pv5gwExSgDndbS6D7wY2CTAHjakphna5u8OA= Archived-At: Subject: Re: [Ace] End-to-End Scenarios 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, 22 Sep 2015 05:40:20 -0000 > -----Original Message----- > From: G=C3=B6ran Selander [mailto:goran.selander@ericsson.com] > Sent: Monday, September 21, 2015 9:45 PM > To: Jim Schaad ; ace@ietf.org > Subject: Re: [Ace] End-to-End Scenarios >=20 >=20 >=20 > On 2015-09-20 04:51, "Jim Schaad" wrote: >=20 > >The previous discussion got sidetracked from where it really needed = to go. > >So I want to do a restart and focus on a different aspect. In order = to > >evaluate a solution, one needs to have as comprehensive list of the > >unique scenarios where the solution needs to function. I want to try > >and get some help in building this list. The list will also need to > >include some > >security constructs that may be included. I am assuming that there = has > >been something that created the security context and that the = security > >context is distributed to the correct entities. (I understand that = one > >variation for doing so assumes that the context may be relayed to the > >server via the client.) >=20 > Just to be clear, there are ACE use cases where a client and a server = does not > have context with each other, and we need support from COSE to = establish that > using a TTP, but I understand if you don=E2=80=99t want to discuss = that in this mail thread. I understand that this is needed. This is going to be true for the = multi-cast DTLS as well. I am assuming that this protocol is going to = be written using the REST principles so that this conversation is = relevant. What would still need to be discussed at a later date is the = internal message structure. How much do we believe that the = requirements of this are currently documented? >=20 > > > >I think the list starts as follows: > > > >1. One way command: This covers Put, Delete and so forth. > > C1 sends a command to S1. S1 can 1) not reply, 2) reply success, > >3) reply failure > > > >2. Query/Response: This covers Get > > C1 requests R1 from S1. S1 can 1) reply with data, 2) reply with > >failure. >=20 >=20 > I don=E2=80=99t understand the distinction between "command with = reply=E2=80=9D in 1. and > "Query/Response=E2=80=9D in 2. >=20 > Do you consider POST be of type 1. or type 2., or doesn=E2=80=99t it = matter? I would think of POST as being of type 1. The difference for me between = type 1 and type 2 is the question - does this operation require a = response or is the response just necessary if the CoAP message is marked = confirmable. The concept of a Get for which there is no response makes = no sense. This is not true for a POST. >=20 >=20 > In terms of security constructs, there is a need for a 2-pass PUT = Query/Response > (e.g. "Lock a door") , whereas GET Response could be a 1-pass secure = message > (properly identified and versioned) preceded by an unprotected GET = Request. > But maybe this comes later? (There is also a 4-pass =E2=80=9CUnlock a = door", but I don=E2=80=99t > think that should be solved by COSE.) Please explain. I don't understand what you are saying. A couple of = flow diagrams may be helpful. >=20 >=20 > > > >3. Observation: > > C1 observes R1 on S1. > > S1 can 1) reply with data, 2) reply with failure, 3) reply success > >but no data (?) > > C1 cancels observe of R1 on S1 > > S1 can 1) reply with success, 2) reply with failure > > S1 sends data on R1 to C1 > > > >4. Observation with data server: > > C1 observes R1 from S1 on S2 > > S2 can 1) reply with data, 2) reply with failure, 3) reply success > >but no data > > C1 cancels observing R1 > > S2 can 1) reply with success, 2) reply with failure > > S2 send data about R1 to C1 > > ** S2 may not have access to data about R1 > > ** Security context to communicate with S1 and S2 from C1 may be > >different and not overlap > > ** S2 may be required to verify data came from S1, but not be able = to > >access R1. >=20 >=20 > Since you want to be exhaustive, there are operations between Resource = Server > (S1) and Data Server (S2). I don't believe that these need to be dealt with separately, but I could = be wrong. Are these not just the same operations with either the = Resource Server or the Data Server as the C1 and the other as S1? = Unless there are three parties I don't believe that this introduces any = new wrinkles. Do you have any ones in mind where there might be = differences? > Mapping between your notation and notation of draft-ietf-ace-actors: >=20 > C1 in ACE C; >=20 > S1 in ACE RS; >=20 > S2 in Data Server; >=20 >=20 > Alternative data flows: >=20 > C2 in Data Server requests with GET (optionally Observe) to S1 in ACE = RS; This would be case #2 or #3 above. >=20 > C3 in ACE RS requests with PUT/POST to S3 (potentially S2) in Data = Server; This would be case #1 above. Jim >=20 >=20 >=20 > G=C3=B6ran >=20 >=20 >=20 > > > >5. Use of a Proxy Server > > All of cases 1 through 4 need to be repeated but with a proxy server > >P1 between C1 and the entity it is talking to. > > > >What operations and data flows am I still missing? > > > >Jim > > > > > >_______________________________________________ > >Ace mailing list > >Ace@ietf.org > >https://www.ietf.org/mailman/listinfo/ace From nobody Tue Sep 22 00:02: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 426FD1B2AF9 for ; Tue, 22 Sep 2015 00:02:25 -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 TMOUwlIteEqg for ; Tue, 22 Sep 2015 00:02:23 -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 655971A92F0 for ; Tue, 22 Sep 2015 00:02:22 -0700 (PDT) X-AuditID: c1b4fb25-f79a26d00000149a-ac-5600fcfcbecb Received: from ESESSHC016.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id CD.3F.05274.CFCF0065; Tue, 22 Sep 2015 09:02:20 +0200 (CEST) Received: from ESESSMB303.ericsson.se ([169.254.3.186]) by ESESSHC016.ericsson.se ([153.88.183.66]) with mapi id 14.03.0248.002; Tue, 22 Sep 2015 09:02:19 +0200 From: =?utf-8?B?R8O2cmFuIFNlbGFuZGVy?= To: Jim Schaad , "ace@ietf.org" Thread-Topic: [Ace] End-to-End Scenarios Thread-Index: AdDzTJuCqeOcgZ3iQWWV4hFj3veTUQBpM2AA///tTYCAADkdAA== Date: Tue, 22 Sep 2015 07:02:18 +0000 Message-ID: References: <021b01d0f34f$3ef676d0$bce36470$@augustcellars.com> <049601d0f4f8$d40e7b50$7c2b71f0$@augustcellars.com> In-Reply-To: <049601d0f4f8$d40e7b50$7c2b71f0$@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.149] Content-Type: text/plain; charset="utf-8" Content-ID: <9E408A7145503B40A95A4ED014B6166A@ericsson.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmphkeLIzCtJLcpLzFFi42KZGfG3RvfPH4Ywg61PJSy+f+thtlg9/Tub A5PHxjnT2TyWLPnJFMAUxWWTkpqTWZZapG+XwJXRu/g9e0GbR0Vfv1YD4wy3LkZODgkBE4mF /U1sELaYxIV764FsLg4hgaOMEn3rJjFCOEsYJV4tf8sOUsUm4CLxoOERE4gtIuAmcXbyMhYQ W1hAXWLD6a9QcQ2JKXPeMUPYThINnS/BNrAIqEq8WjKREcTmFbCQmLtmJhPcgtsPDoA1cwo4 SHz5shhsGSPQSd9PrQGLMwuIS9x6Mp8J4lQBiSV7zjND2KISLx//YwWxRQX0JFZeh3lHSWLt 4e1Ax3EA9WpKrN+lDzHGWuLan1usELaixJTuh+wQ9whKnJz5hGUCo/gsJNtmIXTPQtI9C0n3 LCTdCxhZVzGKFqcWJ+WmGxnrpRZlJhcX5+fp5aWWbGIERtvBLb9VdzBefuN4iFGAg1GJh1dh G0OYEGtiWXFl7iFGaQ4WJXHeZqYHoUIC6YklqdmpqQWpRfFFpTmpxYcYmTg4pRoYi+3Pv7jL du2LxqSzYkefmF+YtPz91PaiN0vrpRhviRx5bzNzzoMDgblvVrXdDn1UJd7J9JVl2d1XqjcP Ku3u3+2nptK9mm3Jf+5fLwUf92rv/7oneFrLHVepe5k25xOfb3b5diFc+8rssNYdTd7+/62e SO69Jyk2OezaZ/Us8333dJziz32vWqHEUpyRaKjFXFScCAA/60GblwIAAA== Archived-At: Subject: Re: [Ace] End-to-End Scenarios 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, 22 Sep 2015 07:02:25 -0000 DQoNCk9uIDIwMTUtMDktMjIgMDc6MzcsICJKaW0gU2NoYWFkIiA8aWV0ZkBhdWd1c3RjZWxsYXJz LmNvbT4gd3JvdGU6DQoNCj4NCj4NCj4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+PiBG cm9tOiBHw7ZyYW4gU2VsYW5kZXIgW21haWx0bzpnb3Jhbi5zZWxhbmRlckBlcmljc3Nvbi5jb21d DQo+PiBTZW50OiBNb25kYXksIFNlcHRlbWJlciAyMSwgMjAxNSA5OjQ1IFBNDQo+PiBUbzogSmlt IFNjaGFhZCA8aWV0ZkBhdWd1c3RjZWxsYXJzLmNvbT47IGFjZUBpZXRmLm9yZw0KPj4gU3ViamVj dDogUmU6IFtBY2VdIEVuZC10by1FbmQgU2NlbmFyaW9zDQo+PiANCj4+IA0KPj4gDQo+PiBPbiAy MDE1LTA5LTIwIDA0OjUxLCAiSmltIFNjaGFhZCIgPGlldGZAYXVndXN0Y2VsbGFycy5jb20+IHdy b3RlOg0KPj4gDQo+PiA+VGhlIHByZXZpb3VzIGRpc2N1c3Npb24gZ290IHNpZGV0cmFja2VkIGZy b20gd2hlcmUgaXQgcmVhbGx5IG5lZWRlZCB0bw0KPj5nby4NCj4+ID5TbyBJIHdhbnQgdG8gZG8g YSByZXN0YXJ0IGFuZCBmb2N1cyBvbiBhIGRpZmZlcmVudCBhc3BlY3QuICBJbiBvcmRlciB0bw0K Pj4gPmV2YWx1YXRlIGEgc29sdXRpb24sIG9uZSBuZWVkcyB0byBoYXZlIGFzIGNvbXByZWhlbnNp dmUgbGlzdCBvZiB0aGUNCj4+ID51bmlxdWUgc2NlbmFyaW9zIHdoZXJlIHRoZSBzb2x1dGlvbiBu ZWVkcyB0byBmdW5jdGlvbi4gIEkgd2FudCB0byB0cnkNCj4+ID5hbmQgZ2V0IHNvbWUgaGVscCBp biBidWlsZGluZyB0aGlzIGxpc3QuICBUaGUgbGlzdCB3aWxsIGFsc28gbmVlZCB0bw0KPj4gPmlu Y2x1ZGUgc29tZQ0KPj4gPnNlY3VyaXR5IGNvbnN0cnVjdHMgdGhhdCBtYXkgYmUgaW5jbHVkZWQu ICAgSSBhbSBhc3N1bWluZyB0aGF0IHRoZXJlDQo+Pmhhcw0KPj4gPmJlZW4gc29tZXRoaW5nIHRo YXQgY3JlYXRlZCB0aGUgc2VjdXJpdHkgY29udGV4dCBhbmQgdGhhdCB0aGUgc2VjdXJpdHkNCj4+ ID5jb250ZXh0IGlzIGRpc3RyaWJ1dGVkIHRvIHRoZSBjb3JyZWN0IGVudGl0aWVzLiAgKEkgdW5k ZXJzdGFuZCB0aGF0IG9uZQ0KPj4gPnZhcmlhdGlvbiBmb3IgZG9pbmcgc28gYXNzdW1lcyB0aGF0 IHRoZSBjb250ZXh0IG1heSBiZSByZWxheWVkIHRvIHRoZQ0KPj4gPnNlcnZlciB2aWEgdGhlIGNs aWVudC4pDQo+PiANCj4+IEp1c3QgdG8gYmUgY2xlYXIsIHRoZXJlIGFyZSBBQ0UgdXNlIGNhc2Vz IHdoZXJlIGEgY2xpZW50IGFuZCBhIHNlcnZlcg0KPj5kb2VzIG5vdA0KPj4gaGF2ZSBjb250ZXh0 IHdpdGggZWFjaCBvdGhlciwgYW5kIHdlIG5lZWQgc3VwcG9ydCBmcm9tIENPU0UgdG8NCj4+ZXN0 YWJsaXNoIHRoYXQNCj4+IHVzaW5nIGEgVFRQLCBidXQgSSB1bmRlcnN0YW5kIGlmIHlvdSBkb27i gJl0IHdhbnQgdG8gZGlzY3VzcyB0aGF0IGluIHRoaXMNCj4+bWFpbCB0aHJlYWQuDQo+DQo+SSB1 bmRlcnN0YW5kIHRoYXQgdGhpcyBpcyBuZWVkZWQuICBUaGlzIGlzIGdvaW5nIHRvIGJlIHRydWUg Zm9yIHRoZQ0KPm11bHRpLWNhc3QgRFRMUyBhcyB3ZWxsLiAgSSBhbSBhc3N1bWluZyB0aGF0IHRo aXMgcHJvdG9jb2wgaXMgZ29pbmcgdG8gYmUNCj53cml0dGVuIHVzaW5nIHRoZSBSRVNUIHByaW5j aXBsZXMgc28gdGhhdCB0aGlzIGNvbnZlcnNhdGlvbiBpcyByZWxldmFudC4NCj5XaGF0IHdvdWxk IHN0aWxsIG5lZWQgdG8gYmUgZGlzY3Vzc2VkIGF0IGEgbGF0ZXIgZGF0ZSBpcyB0aGUgaW50ZXJu YWwNCj5tZXNzYWdlIHN0cnVjdHVyZS4gIEhvdyBtdWNoIGRvIHdlIGJlbGlldmUgdGhhdCB0aGUg cmVxdWlyZW1lbnRzIG9mIHRoaXMNCj5hcmUgY3VycmVudGx5IGRvY3VtZW50ZWQ/DQoNCkZvciBl eGFtcGxlLCBBQ1JFIChkcmFmdC1zZWl0ei1hY2UtY29yZS1hdXRoei0wMCkgY29udGFpbnMgdGhl IGJhc2ljDQpjYXNlcy4gQW5kLCB5ZXMsIG9uZSBvZiB0aGUgcHJpbmNpcGxlcyBvZiBBQ1JFIGlz IHRvIGVzdGFibGlzaCBjb250ZXh0DQp1c2luZyBSRVNUZnVsIHJlc291cmNlcy4gQnV0IHRoZXJl IGlzIG5vIGxpc3Qgb2YgcmVxdWlyZW1lbnRzLiBJbiB0aGUgbmV4dA0KdmVyc2lvbiB0aGlzIHdp bGwgcHJvYmFibHkgYmUgbW9yZSBjbGVhci4NCg0KPg0KPj4gDQo+PiA+DQo+PiA+SSB0aGluayB0 aGUgbGlzdCBzdGFydHMgYXMgZm9sbG93czoNCj4+ID4NCj4+ID4xLiAgT25lIHdheSBjb21tYW5k OiBUaGlzIGNvdmVycyBQdXQsIERlbGV0ZSBhbmQgc28gZm9ydGguDQo+PiA+CUMxIHNlbmRzIGEg Y29tbWFuZCB0byBTMS4gICBTMSBjYW4gMSkgbm90IHJlcGx5LCAyKSByZXBseSBzdWNjZXNzLA0K Pj4gPjMpIHJlcGx5IGZhaWx1cmUNCj4+ID4NCj4+ID4yLiAgUXVlcnkvUmVzcG9uc2U6ICBUaGlz IGNvdmVycyBHZXQNCj4+ID4JQzEgcmVxdWVzdHMgUjEgZnJvbSBTMS4gIFMxIGNhbiAxKSByZXBs eSB3aXRoIGRhdGEsIDIpIHJlcGx5IHdpdGgNCj4+ID5mYWlsdXJlLg0KPj4gDQo+PiANCj4+IEkg ZG9u4oCZdCB1bmRlcnN0YW5kIHRoZSBkaXN0aW5jdGlvbiBiZXR3ZWVuICJjb21tYW5kIHdpdGgg cmVwbHnigJ0gaW4gMS4NCj4+YW5kDQo+PiAiUXVlcnkvUmVzcG9uc2XigJ0gaW4gMi4NCj4+IA0K Pj4gRG8geW91IGNvbnNpZGVyIFBPU1QgYmUgb2YgdHlwZSAxLiBvciB0eXBlIDIuLCBvciBkb2Vz buKAmXQgaXQgbWF0dGVyPw0KPg0KPkkgd291bGQgdGhpbmsgb2YgUE9TVCBhcyBiZWluZyBvZiB0 eXBlIDEuICBUaGUgZGlmZmVyZW5jZSBmb3IgbWUgYmV0d2Vlbg0KPnR5cGUgMSBhbmQgdHlwZSAy IGlzIHRoZSBxdWVzdGlvbiAgLSBkb2VzIHRoaXMgb3BlcmF0aW9uIHJlcXVpcmUgYQ0KPnJlc3Bv bnNlIG9yIGlzIHRoZSByZXNwb25zZSBqdXN0IG5lY2Vzc2FyeSBpZiB0aGUgQ29BUCBtZXNzYWdl IGlzIG1hcmtlZA0KPmNvbmZpcm1hYmxlLiAgIFRoZSBjb25jZXB0IG9mIGEgR2V0IGZvciB3aGlj aCB0aGVyZSBpcyBubyByZXNwb25zZSBtYWtlcw0KPm5vIHNlbnNlLiAgVGhpcyBpcyBub3QgdHJ1 ZSBmb3IgYSBQT1NULg0KPg0KPj4gDQo+PiANCj4+IEluIHRlcm1zIG9mIHNlY3VyaXR5IGNvbnN0 cnVjdHMsIHRoZXJlIGlzIGEgbmVlZCBmb3IgYSAyLXBhc3MgUFVUDQo+PlF1ZXJ5L1Jlc3BvbnNl DQo+PiAoZS5nLiAiTG9jayBhIGRvb3IiKSAsIHdoZXJlYXMgR0VUIFJlc3BvbnNlIGNvdWxkIGJl IGEgMS1wYXNzIHNlY3VyZQ0KPj5tZXNzYWdlDQo+PiAocHJvcGVybHkgaWRlbnRpZmllZCBhbmQg dmVyc2lvbmVkKSBwcmVjZWRlZCBieSBhbiB1bnByb3RlY3RlZCBHRVQNCj4+UmVxdWVzdC4NCj4+ IEJ1dCBtYXliZSB0aGlzIGNvbWVzIGxhdGVyPyAoVGhlcmUgaXMgYWxzbyBhIDQtcGFzcyDigJxV bmxvY2sgYSBkb29yIiwNCj4+YnV0IEkgZG9u4oCZdA0KPj4gdGhpbmsgdGhhdCBzaG91bGQgYmUg c29sdmVkIGJ5IENPU0UuKQ0KPg0KPlBsZWFzZSBleHBsYWluLiAgSSBkb24ndCB1bmRlcnN0YW5k IHdoYXQgeW91IGFyZSBzYXlpbmcuICAgQSBjb3VwbGUgb2YNCj5mbG93IGRpYWdyYW1zIG1heSBi ZSBoZWxwZnVsLg0KDQoNClB1Ymxpc2gtc3Vic2NyaWJlIGlzIG9uZSBleGFtcGxlIG9mIDEtcGFz cyBHRVQgUmVzcG9uc2UgKGJldHdlZW4gUzEgYW5kIFMyDQppbiA0LiBiZWxvdykuDQoNCg0KRm9y IDItcGFzcyBQVVQgKHNob3VsZCBwcm9iYWJseSBiZSBQT1NUKSBRdWVyeS9SZXNwb25zZSDigJxs b2NrIGEgZG9vcuKAnQ0KdGhpbmsgZS5nLiBhYm91dDoNCg0KaHR0cDovL3d3dy50aGVndWFyZGlh bi5jb20vdGVjaG5vbG9neS8yMDE1L21heS8yNi9oaWdoLXRlY2gtdGhpZXZlcy1qYW1taW5nDQot dGVjaG5vbG9neS1zdGVhbC1jYXINCg0KDQpUaGUgY3VycmVudCBwcm90b2NvbCBpcyBiYXNlZCBv biB0aGUgdXNlciB3YXRjaGluZyB0aGUgYmxpbmtpbmcgbGlnaHRzIG9mDQp0aGUgY2FyIGNvbmZp cm1pbmcgaXQgYmVpbmcgbG9ja2VkLiBCZXR0ZXIgaWYgdGhlIGtleSBkZXZpY2UgdmVyaWZpZWQg dGhhdA0KdGhlIGxvY2sgcmVxdWVzdCB3YXMgcmVjZWl2ZWQsIGFuZCBpZiBub3QgYWxlcnRlZCB0 aGUgdXNlci4NCg0KRm9yICJVbmxvY2sgYSBkb29y4oCdIHRoaW5rIG9mIHRoZSBzYW1lIHNjZW5h cmlvIHdoZXJlIHRoZSBQVVQvUE9TVCB1bmxvY2sNCnJlcXVlc3QgZnJvbSB0aGUga2V5IGRldmlj ZSBpcyByZWNvcmRlZCBieSB0aGUgYWR2ZXJzYXJ5LiBUaGVuIGl0IHdhaXRzDQpmb3IgdGhlIHVz ZXIgdG8gZ2l2ZSB1cCBhbmQgbGVhdmUuIFRoZW4gaXQgcGxheXMgYmFjayB0aGUgcmVjb3JkZWQg cmVxdWVzdA0KKG5vdGUsIHRoaXMgaXMgbm90IGEgcmVwbGF5KS4gVGhpcyBjYW4gYmUgbWl0aWdh dGVkIGJ5IG1vcmUgcm91bmQgdHJpcHMsDQphY3R1YWxseSAzLXBhc3MgaXMgc3VmZmljaWVudC4g QnV0IGFnYWluLCB0aGlzIHNob3VsZCBwcm9iYWJseSBiZSBpbiB0aGUNCmFwcGxpY2F0aW9uIG9m IENPU0UuDQoNCg0KU29ycnkgbm8gZmxvdyBjaGFydHMsIGJ1dCBwZXJoYXBzIHBvc3NpYmxlIHRv IHVuZGVyc3RhbmQgYW55d2F5Pw0KDQo+DQo+PiANCj4+IA0KPj4gPg0KPj4gPjMuICBPYnNlcnZh dGlvbjoNCj4+ID4JQzEgb2JzZXJ2ZXMgUjEgb24gUzEuDQo+PiA+CQlTMSBjYW4gMSkgcmVwbHkg d2l0aCBkYXRhLCAyKSByZXBseSB3aXRoIGZhaWx1cmUsIDMpIHJlcGx5IHN1Y2Nlc3MNCj4+ID5i dXQgbm8gZGF0YSAoPykNCj4+ID4JQzEgY2FuY2VscyBvYnNlcnZlIG9mIFIxIG9uIFMxDQo+PiA+ CQlTMSBjYW4gMSkgcmVwbHkgd2l0aCBzdWNjZXNzLCAyKSByZXBseSB3aXRoIGZhaWx1cmUNCj4+ ID4JUzEgc2VuZHMgZGF0YSBvbiBSMSB0byBDMQ0KPj4gPg0KPj4gPjQuICBPYnNlcnZhdGlvbiB3 aXRoIGRhdGEgc2VydmVyOg0KPj4gPglDMSBvYnNlcnZlcyBSMSBmcm9tIFMxIG9uIFMyDQo+PiA+ CQlTMiBjYW4gMSkgcmVwbHkgd2l0aCBkYXRhLCAyKSByZXBseSB3aXRoIGZhaWx1cmUsIDMpIHJl cGx5IHN1Y2Nlc3MNCj4+ID5idXQgbm8gZGF0YQ0KPj4gPglDMSBjYW5jZWxzIG9ic2VydmluZyBS MQ0KPj4gPgkJUzIgY2FuIDEpIHJlcGx5IHdpdGggc3VjY2VzcywgMikgcmVwbHkgd2l0aCBmYWls dXJlDQo+PiA+CVMyIHNlbmQgZGF0YSBhYm91dCBSMSB0byBDMQ0KPj4gPgkqKiBTMiBtYXkgbm90 IGhhdmUgYWNjZXNzIHRvIGRhdGEgYWJvdXQgUjENCj4+ID4JKiogU2VjdXJpdHkgY29udGV4dCB0 byBjb21tdW5pY2F0ZSB3aXRoIFMxIGFuZCBTMiBmcm9tIEMxIG1heSBiZQ0KPj4gPmRpZmZlcmVu dCBhbmQgbm90IG92ZXJsYXANCj4+ID4JKiogUzIgbWF5IGJlIHJlcXVpcmVkIHRvIHZlcmlmeSBk YXRhIGNhbWUgZnJvbSBTMSwgYnV0IG5vdCBiZSBhYmxlIHRvDQo+PiA+YWNjZXNzIFIxLg0KPj4g DQo+PiANCj4+IFNpbmNlIHlvdSB3YW50IHRvIGJlIGV4aGF1c3RpdmUsIHRoZXJlIGFyZSBvcGVy YXRpb25zIGJldHdlZW4gUmVzb3VyY2UNCj4+U2VydmVyDQo+PiAoUzEpIGFuZCBEYXRhIFNlcnZl ciAoUzIpLg0KPg0KPkkgZG9uJ3QgYmVsaWV2ZSB0aGF0IHRoZXNlIG5lZWQgdG8gYmUgZGVhbHQg d2l0aCBzZXBhcmF0ZWx5LCBidXQgSSBjb3VsZA0KPmJlIHdyb25nLiAgQXJlIHRoZXNlIG5vdCBq dXN0IHRoZSBzYW1lIG9wZXJhdGlvbnMgd2l0aCBlaXRoZXIgdGhlDQo+UmVzb3VyY2UgU2VydmVy IG9yIHRoZSBEYXRhIFNlcnZlciBhcyB0aGUgQzEgYW5kIHRoZSBvdGhlciBhcyBTMT8gIFVubGVz cw0KPnRoZXJlIGFyZSB0aHJlZSBwYXJ0aWVzIEkgZG9uJ3QgYmVsaWV2ZSB0aGF0IHRoaXMgaW50 cm9kdWNlcyBhbnkgbmV3DQo+d3JpbmtsZXMuICBEbyB5b3UgaGF2ZSBhbnkgb25lcyBpbiBtaW5k IHdoZXJlIHRoZXJlIG1pZ2h0IGJlIGRpZmZlcmVuY2VzPw0KPg0KPj4gTWFwcGluZyBiZXR3ZWVu IHlvdXIgbm90YXRpb24gYW5kIG5vdGF0aW9uIG9mIGRyYWZ0LWlldGYtYWNlLWFjdG9yczoNCj4+ IA0KPj4gQzEgaW4gQUNFIEM7DQo+PiANCj4+IFMxIGluIEFDRSBSUzsNCj4+IA0KPj4gUzIgaW4g RGF0YSBTZXJ2ZXI7DQo+PiANCj4+IA0KPj4gQWx0ZXJuYXRpdmUgZGF0YSBmbG93czoNCj4+IA0K Pj4gQzIgaW4gRGF0YSBTZXJ2ZXIgcmVxdWVzdHMgd2l0aCBHRVQgKG9wdGlvbmFsbHkgT2JzZXJ2 ZSkgdG8gUzEgaW4gQUNFDQo+PlJTOw0KPg0KPlRoaXMgd291bGQgYmUgY2FzZSAjMiBvciAjMyBh Ym92ZS4NCj4NCj4+IA0KPj4gQzMgaW4gQUNFIFJTIHJlcXVlc3RzIHdpdGggUFVUL1BPU1QgdG8g UzMgKHBvdGVudGlhbGx5IFMyKSBpbiBEYXRhDQo+PlNlcnZlcjsNCj4NCj5UaGlzIHdvdWxkIGJl IGNhc2UgIzEgYWJvdmUuDQoNCg0KQWdyZWUsIGp1c3Qgd2FudGVkIHRvIGJlIGV4cGxpY2l0Lg0K DQpHw7ZyYW4NCg0KDQo+DQo+SmltDQo+DQo+PiANCj4+IA0KPj4gDQo+PiBHw7ZyYW4NCj4+IA0K Pj4gDQo+PiANCj4+ID4NCj4+ID41LiAgVXNlIG9mIGEgUHJveHkgU2VydmVyDQo+PiA+CUFsbCBv ZiBjYXNlcyAxIHRocm91Z2ggNCBuZWVkIHRvIGJlIHJlcGVhdGVkIGJ1dCB3aXRoIGEgcHJveHkg c2VydmVyDQo+PiA+UDEgYmV0d2VlbiBDMSBhbmQgdGhlIGVudGl0eSBpdCBpcyB0YWxraW5nIHRv Lg0KPj4gPg0KPj4gPldoYXQgb3BlcmF0aW9ucyBhbmQgZGF0YSBmbG93cyBhbSBJIHN0aWxsIG1p c3Npbmc/DQo+PiA+DQo+PiA+SmltDQo+PiA+DQo+PiA+DQo+PiA+X19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+ID5BY2UgbWFpbGluZyBsaXN0DQo+PiA+ QWNlQGlldGYub3JnDQo+PiA+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9h Y2UNCj4NCj4NCg0K From nobody Tue Sep 22 04:55: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 AFD341A6F01 for ; Tue, 22 Sep 2015 04:55:29 -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 HYEmj7vZU_OG for ; Tue, 22 Sep 2015 04:55:28 -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 EA6251A6EF9 for ; Tue, 22 Sep 2015 04:55:27 -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 t8MBtMjm023010; Tue, 22 Sep 2015 13:55:22 +0200 (CEST) Received: from aung.tzi.org (eduroam-0687.wlan.uni-bremen.de [134.102.18.175]) (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 3nL1Kk1Gmdz4mSy; Tue, 22 Sep 2015 13:55:22 +0200 (CEST) From: Olaf Bergmann To: "Jim Schaad" References: <021b01d0f34f$3ef676d0$bce36470$@augustcellars.com> <874minlx3d.fsf@aung.informatik.uni-bremen.de> <048001d0f4e1$e7604790$b620d6b0$@augustcellars.com> Date: Tue, 22 Sep 2015 13:55:21 +0200 Message-ID: <87r3lqis7q.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] End-to-End Scenarios 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, 22 Sep 2015 11:55:29 -0000 "Jim Schaad" writes: >> -----Original Message----- >> From: Olaf Bergmann [mailto:bergmann@tzi.org] [...] >> In short: I do not think that we need to list the "not reply" >> scenario but keep in >> mind that S always may decide to send no response. > > I had not been thinking in terms of what S1 chose to do when I wrote > that, but in terms of fact that CoAP provides for a confirmable > version of operations. Okay. So, CoAP requires an acknowledgement on the message layer to be sent for confirmable messages which then stops retransmission. A correct server will send that. On the request/response layer (where the response may be separate from the acknowledgement message), the server could defer the response to a request indefinitely, if it sees reason to do so. Thus I completely agree with your split between GET and PUT/DELETE/PATCH in that a GET request without a response usually does not make much sense. POST is somewhat special in that one possible effect of POST is to create a new resource whose URI is returned in the response. > However, the main reason was to be exhaustive. It may be that we need > to think about different implications of S1 replying or not replying > in terms of security properties. I have no idea if this is going to > be true however. Same here. It just came to my mind that for scenario 3, there is an additional cancellation mechanism: S1 can send a notification, C can respond with a reset message to remove the observation relationship at the server. Usually, this happens when C lost state but nothing stops C from using that same mechanism to tell S1 that it should stop sending notifications. Gr=C3=BC=C3=9Fe Olaf From nobody Tue Sep 22 10:15: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 3F9921B2C4A for ; Tue, 22 Sep 2015 10:15:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.801 X-Spam-Level: X-Spam-Status: No, score=-0.801 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 shWaMJOeDXA9 for ; Tue, 22 Sep 2015 10:15:26 -0700 (PDT) Received: from elasmtp-kukur.atl.sa.earthlink.net (elasmtp-kukur.atl.sa.earthlink.net [209.86.89.65]) by ietfa.amsl.com (Postfix) with ESMTP id 46CB11B2C4D for ; Tue, 22 Sep 2015 10:15:25 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=oPFXNm6LAFdwsDhwFUhSEwA2A+96tupdnLAlLB18yyGdNkLd+c2bZCOKDE/Qm2Rq; h=Message-ID:Date:From:Reply-To:To:Subject:Mime-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:X-ELNK-Trace:X-Originating-IP; Received: from [209.86.224.36] (helo=elwamui-hybrid.atl.sa.earthlink.net) by elasmtp-kukur.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1ZeRA0-0007vl-9z for ace@ietf.org; Tue, 22 Sep 2015 13:15:20 -0400 Received: from 76.254.54.248 by webmail.earthlink.net with HTTP; Tue, 22 Sep 2015 13:15:19 -0400 Message-ID: <13695229.1442942120385.JavaMail.root@elwamui-hybrid.atl.sa.earthlink.net> Date: Tue, 22 Sep 2015 10:15:19 -0700 (GMT-07:00) From: Randy Presuhn To: ace@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Mailer: EarthLink Zoo Mail 1.0 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d88874d3f0892ff6d3ed97fbcf374706e94c95dc274cdcebfcb3350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 209.86.224.36 Archived-At: Subject: Re: [Ace] End-to-End Scenarios X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Randy Presuhn List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Sep 2015 17:15:28 -0000 Hi - >From: Olaf Bergmann >Sent: Sep 22, 2015 4:55 AM >To: Jim Schaad >Cc: ace@ietf.org >Subject: Re: [Ace] End-to-End Scenarios ... >Thus I completely agree with your split between GET and PUT/DELETE/PATCH >in that a GET request without a response usually does not make much >sense. POST is somewhat special in that one possible effect of POST is >to create a new resource whose URI is returned in the response. I've been watching this thread for a while, trying to make sense of it, and would like someone to enlighten me. In every management protocol I know of, the operations corresponding to PUT/DELETE/PATCH are confirmed operations for several important reasons: 1) the invoker needs to know whether the operation was accepted (request not lost or destroyed by some interloper, request deemed well-formed by the recipient, the object of the operation existed, not blocked by access control or other concerns, etc.) 2) the invoker needs to know whether the operation was completed (things like delete and patch in particular may take a long time to bring to completion, depending on their side-effects, and the invoker may want to defer initiating another operation until the target is in a known state, or may need to coordinate the state transitions of multiple target systems) 3) particularly on low-end systems, command-processing queues may be subject to seemingly arbitrary constraints, and sending too many (where the value of "too many" is generally not advertised) operations back-to-back will cause some of them to be lost or worse, necessitating a sort of "processing flow control" So you can see why, coming from a management protocol background, I'm having difficulty making sense of this discussion. Please clue me in to whatever it is that I'm missing. Randy From nobody Tue Sep 22 10:45: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 717931A9125 for ; Tue, 22 Sep 2015 10:45:16 -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 E_5U7C0XBEVb for ; Tue, 22 Sep 2015 10:45: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 A3FC61A911B for ; Tue, 22 Sep 2015 10:45:13 -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 t8MHj9ri019958; Tue, 22 Sep 2015 19:45:09 +0200 (CEST) Received: from aung.tzi.org (p57A63B54.dip0.t-ipconnect.de [87.166.59.84]) (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 3nL95K1PtDz4nWh; Tue, 22 Sep 2015 19:45:09 +0200 (CEST) From: Olaf Bergmann To: Randy Presuhn References: <13695229.1442942120385.JavaMail.root@elwamui-hybrid.atl.sa.earthlink.net> Date: Tue, 22 Sep 2015 19:45:08 +0200 In-Reply-To: <13695229.1442942120385.JavaMail.root@elwamui-hybrid.atl.sa.earthlink.net> (Randy Presuhn's message of "Tue, 22 Sep 2015 10:15:19 -0700 (GMT-07:00)") Message-ID: <87y4fygxgb.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] End-to-End Scenarios 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, 22 Sep 2015 17:45:16 -0000 Hi Randy, Randy Presuhn writes: > In every management protocol I know of, the operations corresponding > to PUT/DELETE/PATCH are confirmed operations for several important > reasons: You are correct from a management protocol perspective. However, there are (specifically in the IoT world) usage scenarios where the sender of that message is not interested in the response for some reasons. One example are sensors that sleep for most of the time, wake up to take a measurement, PUT it onto some information broker and then go to sleep without waiting for the response (under the optimistic assumption that a large number of messages will reach their goal and is handled appropriately). If a sender wants to ensure that the message was received it can send it as a confirmable message and wait for the acknowledgement which may or may not be combined with the response for the request (in CoAP -- other protocols may work differently, of course). Gr=C3=BC=C3=9Fe Olaf From nobody Tue Sep 22 10:49: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 1618B1A9154 for ; Tue, 22 Sep 2015 10:49: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 4VW0P5d40mMj for ; Tue, 22 Sep 2015 10:49:57 -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 2DF211A9152 for ; Tue, 22 Sep 2015 10:49:57 -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 t8MHns9Q029673; Tue, 22 Sep 2015 19:49:54 +0200 (CEST) Received: from alma.local (p5DCCDB06.dip0.t-ipconnect.de [93.204.219.6]) (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 3nL9Bn6DSrz4nYR; Tue, 22 Sep 2015 19:49:53 +0200 (CEST) Message-ID: <560194BD.3090606@tzi.org> Date: Tue, 22 Sep 2015 19:49:49 +0200 From: Carsten Bormann User-Agent: Postbox 4.0.4 (Macintosh/20150825) MIME-Version: 1.0 To: Randy Presuhn References: <13695229.1442942120385.JavaMail.root@elwamui-hybrid.atl.sa.earthlink.net> In-Reply-To: <13695229.1442942120385.JavaMail.root@elwamui-hybrid.atl.sa.earthlink.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] End-to-End Scenarios 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, 22 Sep 2015 17:49:58 -0000 Randy Presuhn wrote: > In every management protocol I know of Right, but this is not a discussion of the management use-case. In CoAP, we have non-confirmable messages, and now with Option 284, we even have a way to suppress responses such as a PUT response. This is mainly useful for cases where the client knows it will be PUTting another update soon (as in, the next minute), and it doesn't really care whether any single one made it (or whether they arrive in the right order, because an old PUT overwriting a new one will soon be rectified by the next one, as well). Look for LoRa applications for some typical use cases. Gr眉脽e, Carsten From nobody Tue Sep 22 22:45: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 F01CD1A010C for ; Tue, 22 Sep 2015 22:45:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.3 X-Spam-Level: X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, 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 oyzrnEfGasEK for ; Tue, 22 Sep 2015 22:45:49 -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 629A81A00FF for ; Tue, 22 Sep 2015 22:45:49 -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 smtp1.pacifier.net (Postfix) with ESMTPSA id C73122CA06; Tue, 22 Sep 2015 22:45:48 -0700 (PDT) From: "Jim Schaad" To: =?UTF-8?Q?'G=C3=B6ran_Selander'?= , References: <021b01d0f34f$3ef676d0$bce36470$@augustcellars.com> <049601d0f4f8$d40e7b50$7c2b71f0$@augustcellars.com> In-Reply-To: Date: Tue, 22 Sep 2015 22:43:21 -0700 Message-ID: <006901d0f5c2$c32de5d0$4989b170$@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: AQIWMh3Pv5gwExSgDndbS6D7wY2CTAHjakphAVlh2dYCj3bwNZ2QvZHw Archived-At: Subject: Re: [Ace] End-to-End Scenarios 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, 23 Sep 2015 05:45:52 -0000 > -----Original Message----- > From: G=C3=B6ran Selander [mailto:goran.selander@ericsson.com] > Sent: Tuesday, September 22, 2015 12:02 AM > To: Jim Schaad ; ace@ietf.org > Subject: Re: [Ace] End-to-End Scenarios >=20 >=20 >=20 > On 2015-09-22 07:37, "Jim Schaad" wrote: >=20 > > > > > >> -----Original Message----- > >> From: G=C3=B6ran Selander [mailto:goran.selander@ericsson.com] > >> Sent: Monday, September 21, 2015 9:45 PM > >> To: Jim Schaad ; ace@ietf.org > >> Subject: Re: [Ace] End-to-End Scenarios > >> > >> > >> > >> On 2015-09-20 04:51, "Jim Schaad" wrote: > >> > >> >The previous discussion got sidetracked from where it really = needed > >> >to > >>go. > >> >So I want to do a restart and focus on a different aspect. In = order > >> >to evaluate a solution, one needs to have as comprehensive list of > >> >the unique scenarios where the solution needs to function. I want > >> >to try and get some help in building this list. The list will = also > >> >need to include some > >> >security constructs that may be included. I am assuming that = there > >>has > >> >been something that created the security context and that the > >> >security context is distributed to the correct entities. (I > >> >understand that one variation for doing so assumes that the = context > >> >may be relayed to the server via the client.) > >> > >> Just to be clear, there are ACE use cases where a client and a = server > >>does not have context with each other, and we need support from = COSE > >>to establish that using a TTP, but I understand if you = don=E2=80=99t want to > >>discuss that in this mail thread. > > > >I understand that this is needed. This is going to be true for the > >multi-cast DTLS as well. I am assuming that this protocol is going = to > >be written using the REST principles so that this conversation is = relevant. > >What would still need to be discussed at a later date is the internal > >message structure. How much do we believe that the requirements of > >this are currently documented? >=20 > For example, ACRE (draft-seitz-ace-core-authz-00) contains the basic = cases. > And, yes, one of the principles of ACRE is to establish context using = RESTful > resources. But there is no list of requirements. In the next version = this will > probably be more clear. >=20 > > > >> > >> > > >> >I think the list starts as follows: > >> > > >> >1. One way command: This covers Put, Delete and so forth. > >> > C1 sends a command to S1. S1 can 1) not reply, 2) reply = success, > >> >3) reply failure > >> > > >> >2. Query/Response: This covers Get > >> > C1 requests R1 from S1. S1 can 1) reply with data, 2) reply with > >> >failure. > >> > >> > >> I don=E2=80=99t understand the distinction between "command with = reply=E2=80=9D in 1. > >>and > >> "Query/Response=E2=80=9D in 2. > >> > >> Do you consider POST be of type 1. or type 2., or doesn=E2=80=99t = it matter? > > > >I would think of POST as being of type 1. The difference for me > >between type 1 and type 2 is the question - does this operation > >require a response or is the response just necessary if the CoAP = message is > marked > >confirmable. The concept of a Get for which there is no response = makes > >no sense. This is not true for a POST. > > > >> > >> > >> In terms of security constructs, there is a need for a 2-pass PUT > >>Query/Response (e.g. "Lock a door") , whereas GET Response could be = a > >>1-pass secure message (properly identified and versioned) preceded = by > >>an unprotected GET Request. > >> But maybe this comes later? (There is also a 4-pass =E2=80=9CUnlock = a door", > >>but I don=E2=80=99t think that should be solved by COSE.) > > > >Please explain. I don't understand what you are saying. A couple = of > >flow diagrams may be helpful. >=20 >=20 > Publish-subscribe is one example of 1-pass GET Response (between S1 = and S2 in > 4. below). >=20 >=20 > For 2-pass PUT (should probably be POST) Query/Response =E2=80=9Clock = a door=E2=80=9D > think e.g. about: >=20 > http://www.theguardian.com/technology/2015/may/26/high-tech-thieves- > jamming > -technology-steal-car >=20 >=20 > The current protocol is based on the user watching the blinking lights = of the car > confirming it being locked. Better if the key device verified that the = lock request > was received, and if not alerted the user. >=20 > For "Unlock a door=E2=80=9D think of the same scenario where the = PUT/POST unlock > request from the key device is recorded by the adversary. Then it = waits for the > user to give up and leave. Then it plays back the recorded request = (note, this is > not a replay). This can be mitigated by more round trips, actually = 3-pass is > sufficient. But again, this should probably be in the application of = COSE. >=20 So if I understand correctly, you are talking about the fact that there = might be some special circumstances that might be applied to a series = of related messages where each message will have different content and = might be different operations (i.e. a Put followed by a Get). Side note: I have always called that a replay attack since the message = was intercepted and replayed, it is just a specialized version of one = where the message is prevented from arriving at the destination. These = show up all of the time in terms of resets or out of order replays that = need to be looked at. Jim >=20 > Sorry no flow charts, but perhaps possible to understand anyway? >=20 > > > >> > >> > >> > > >> >3. Observation: > >> > C1 observes R1 on S1. > >> > S1 can 1) reply with data, 2) reply with failure, 3) reply = success > >> >but no data (?) > >> > C1 cancels observe of R1 on S1 > >> > S1 can 1) reply with success, 2) reply with failure > >> > S1 sends data on R1 to C1 > >> > > >> >4. Observation with data server: > >> > C1 observes R1 from S1 on S2 > >> > S2 can 1) reply with data, 2) reply with failure, 3) reply = success > >> >but no data > >> > C1 cancels observing R1 > >> > S2 can 1) reply with success, 2) reply with failure > >> > S2 send data about R1 to C1 > >> > ** S2 may not have access to data about R1 > >> > ** Security context to communicate with S1 and S2 from C1 may be > >> >different and not overlap > >> > ** S2 may be required to verify data came from S1, but not be = able > >> >to access R1. > >> > >> > >> Since you want to be exhaustive, there are operations between > >>Resource Server > >> (S1) and Data Server (S2). > > > >I don't believe that these need to be dealt with separately, but I > >could be wrong. Are these not just the same operations with either = the > >Resource Server or the Data Server as the C1 and the other as S1? > >Unless there are three parties I don't believe that this introduces = any > >new wrinkles. Do you have any ones in mind where there might be > differences? > > > >> Mapping between your notation and notation of = draft-ietf-ace-actors: > >> > >> C1 in ACE C; > >> > >> S1 in ACE RS; > >> > >> S2 in Data Server; > >> > >> > >> Alternative data flows: > >> > >> C2 in Data Server requests with GET (optionally Observe) to S1 in = ACE > >>RS; > > > >This would be case #2 or #3 above. > > > >> > >> C3 in ACE RS requests with PUT/POST to S3 (potentially S2) in Data > >>Server; > > > >This would be case #1 above. >=20 >=20 > Agree, just wanted to be explicit. >=20 > G=C3=B6ran >=20 >=20 > > > >Jim > > > >> > >> > >> > >> G=C3=B6ran > >> > >> > >> > >> > > >> >5. Use of a Proxy Server > >> > All of cases 1 through 4 need to be repeated but with a proxy > >> >server > >> >P1 between C1 and the entity it is talking to. > >> > > >> >What operations and data flows am I still missing? > >> > > >> >Jim > >> > > >> > > >> >_______________________________________________ > >> >Ace mailing list > >> >Ace@ietf.org > >> >https://www.ietf.org/mailman/listinfo/ace > > > > From nobody Tue Sep 22 23:12: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 CE5AF1A0276 for ; Tue, 22 Sep 2015 23:12:17 -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 SPHfdyYEohnK for ; Tue, 22 Sep 2015 23:12:15 -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 096571A02BE for ; Tue, 22 Sep 2015 23:12:13 -0700 (PDT) X-AuditID: c1b4fb2d-f79626d000004282-3d-560242bb59a8 Received: from ESESSHC014.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id BF.FC.17026.BB242065; Wed, 23 Sep 2015 08:12:12 +0200 (CEST) Received: from ESESSMB303.ericsson.se ([169.254.3.186]) by ESESSHC014.ericsson.se ([153.88.183.60]) with mapi id 14.03.0248.002; Wed, 23 Sep 2015 08:12:11 +0200 From: =?utf-8?B?R8O2cmFuIFNlbGFuZGVy?= To: Jim Schaad , "ace@ietf.org" Thread-Topic: [Ace] End-to-End Scenarios Thread-Index: AdDzTJuCqeOcgZ3iQWWV4hFj3veTUQBpM2AA///tTYCAADkdAIABWr+AgAApmQA= Date: Wed, 23 Sep 2015 06:12:11 +0000 Message-ID: References: <021b01d0f34f$3ef676d0$bce36470$@augustcellars.com> <049601d0f4f8$d40e7b50$7c2b71f0$@augustcellars.com> <006901d0f5c2$c32de5d0$4989b170$@augustcellars.com> In-Reply-To: <006901d0f5c2$c32de5d0$4989b170$@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.154] Content-Type: text/plain; charset="utf-8" Content-ID: <77885BC2F1FF87408D87B1F724962358@ericsson.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmplkeLIzCtJLcpLzFFi42KZGfG3RnePE1OYwakFzBbfv/UwW6ye/p3N gclj45zpbB5LlvxkCmCK4rJJSc3JLEst0rdL4MqYvGopc8GXqIrTs6+xNzCeiOhi5OSQEDCR mDf3DyuELSZx4d56ti5GLg4hgaOMEr1T7jBDOEuAnLszWECq2ARcJB40PGICsUUE3CTOTl4G FhcWUJfYcPorVFxDYsqcd8wQtp9E380bbCA2i4CqRMfMeYwgNq+AhcSanV9ZIRZ0Mkk82TSf HSTBKeAgsf3tebChjEAnfT+1Bmwos4C4xK0n85kgThWQWLLnPDOELSrx8vE/sBdEBfQkVl5v YoOIK0ksuv0ZqJ4DqFdTYv0ufYgx1hJL/x1jhbAVJaZ0P2SHuEdQ4uTMJywTGMVnIdk2C6F7 FpLuWUi6ZyHpXsDIuopRtDi1uDg33chYL7UoM7m4OD9PLy+1ZBMjMN4Obvmtu4Nx9WvHQ4wC HIxKPLwL2JnChFgTy4orcw8xSnOwKInztjA9CBUSSE8sSc1OTS1ILYovKs1JLT7EyMTBKdXA yJLx1ipFa9ruExJuxf0XuDzPmr85OP350Zeb5VIs/DZdvfrna2HQn/v7/7tOW/Vxa1rYrzt3 RD6eTa0T+drjcq/p3cqFM5Ms5KPFhTYaZF530ypKOWkfv5/haMHUtfcPTmqxK2pxCgs59Cmj duaDOI6pXxdee3Ym7NLVAJlZTkFM/YUv1utfyVJiKc5INNRiLipOBAAv0ctgmAIAAA== Archived-At: Subject: Re: [Ace] End-to-End Scenarios 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, 23 Sep 2015 06:12:18 -0000 DQoNCk9uIDIwMTUtMDktMjMgMDc6NDMsICJKaW0gU2NoYWFkIiA8aWV0ZkBhdWd1c3RjZWxsYXJz LmNvbT4gd3JvdGU6DQoNCj4NCj4NCj4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+PiBG cm9tOiBHw7ZyYW4gU2VsYW5kZXIgW21haWx0bzpnb3Jhbi5zZWxhbmRlckBlcmljc3Nvbi5jb21d DQo+PiBTZW50OiBUdWVzZGF5LCBTZXB0ZW1iZXIgMjIsIDIwMTUgMTI6MDIgQU0NCj4+IFRvOiBK aW0gU2NoYWFkIDxpZXRmQGF1Z3VzdGNlbGxhcnMuY29tPjsgYWNlQGlldGYub3JnDQo+PiBTdWJq ZWN0OiBSZTogW0FjZV0gRW5kLXRvLUVuZCBTY2VuYXJpb3MNCj4+IA0KPj4gDQo+PiANCj4+IE9u IDIwMTUtMDktMjIgMDc6MzcsICJKaW0gU2NoYWFkIiA8aWV0ZkBhdWd1c3RjZWxsYXJzLmNvbT4g d3JvdGU6DQo+PiANCj4+ID4NCj4+ID4NCj4+ID4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0t DQo+PiA+PiBGcm9tOiBHw7ZyYW4gU2VsYW5kZXIgW21haWx0bzpnb3Jhbi5zZWxhbmRlckBlcmlj c3Nvbi5jb21dDQo+PiA+PiBTZW50OiBNb25kYXksIFNlcHRlbWJlciAyMSwgMjAxNSA5OjQ1IFBN DQo+PiA+PiBUbzogSmltIFNjaGFhZCA8aWV0ZkBhdWd1c3RjZWxsYXJzLmNvbT47IGFjZUBpZXRm Lm9yZw0KPj4gPj4gU3ViamVjdDogUmU6IFtBY2VdIEVuZC10by1FbmQgU2NlbmFyaW9zDQo+PiA+ Pg0KPj4gPj4NCj4+ID4+DQo+PiA+PiBPbiAyMDE1LTA5LTIwIDA0OjUxLCAiSmltIFNjaGFhZCIg PGlldGZAYXVndXN0Y2VsbGFycy5jb20+IHdyb3RlOg0KPj4gPj4NCj4+ID4+ID5UaGUgcHJldmlv dXMgZGlzY3Vzc2lvbiBnb3Qgc2lkZXRyYWNrZWQgZnJvbSB3aGVyZSBpdCByZWFsbHkgbmVlZGVk DQo+PiA+PiA+dG8NCj4+ID4+Z28uDQo+PiA+PiA+U28gSSB3YW50IHRvIGRvIGEgcmVzdGFydCBh bmQgZm9jdXMgb24gYSBkaWZmZXJlbnQgYXNwZWN0LiAgSW4gb3JkZXINCj4+ID4+ID50byBldmFs dWF0ZSBhIHNvbHV0aW9uLCBvbmUgbmVlZHMgdG8gaGF2ZSBhcyBjb21wcmVoZW5zaXZlIGxpc3Qg b2YNCj4+ID4+ID50aGUgdW5pcXVlIHNjZW5hcmlvcyB3aGVyZSB0aGUgc29sdXRpb24gbmVlZHMg dG8gZnVuY3Rpb24uICBJIHdhbnQNCj4+ID4+ID50byB0cnkgYW5kIGdldCBzb21lIGhlbHAgaW4g YnVpbGRpbmcgdGhpcyBsaXN0LiAgVGhlIGxpc3Qgd2lsbCBhbHNvDQo+PiA+PiA+bmVlZCB0byBp bmNsdWRlIHNvbWUNCj4+ID4+ID5zZWN1cml0eSBjb25zdHJ1Y3RzIHRoYXQgbWF5IGJlIGluY2x1 ZGVkLiAgIEkgYW0gYXNzdW1pbmcgdGhhdCB0aGVyZQ0KPj4gPj5oYXMNCj4+ID4+ID5iZWVuIHNv bWV0aGluZyB0aGF0IGNyZWF0ZWQgdGhlIHNlY3VyaXR5IGNvbnRleHQgYW5kIHRoYXQgdGhlDQo+ PiA+PiA+c2VjdXJpdHkgY29udGV4dCBpcyBkaXN0cmlidXRlZCB0byB0aGUgY29ycmVjdCBlbnRp dGllcy4gIChJDQo+PiA+PiA+dW5kZXJzdGFuZCB0aGF0IG9uZSB2YXJpYXRpb24gZm9yIGRvaW5n IHNvIGFzc3VtZXMgdGhhdCB0aGUgY29udGV4dA0KPj4gPj4gPm1heSBiZSByZWxheWVkIHRvIHRo ZSBzZXJ2ZXIgdmlhIHRoZSBjbGllbnQuKQ0KPj4gPj4NCj4+ID4+IEp1c3QgdG8gYmUgY2xlYXIs IHRoZXJlIGFyZSBBQ0UgdXNlIGNhc2VzIHdoZXJlIGEgY2xpZW50IGFuZCBhIHNlcnZlcg0KPj4g Pj5kb2VzIG5vdCAgaGF2ZSBjb250ZXh0IHdpdGggZWFjaCBvdGhlciwgYW5kIHdlIG5lZWQgc3Vw cG9ydCBmcm9tIENPU0UNCj4+ID4+dG8gZXN0YWJsaXNoIHRoYXQgIHVzaW5nIGEgVFRQLCBidXQg SSB1bmRlcnN0YW5kIGlmIHlvdSBkb27igJl0IHdhbnQgdG8NCj4+ID4+ZGlzY3VzcyB0aGF0IGlu IHRoaXMgbWFpbCB0aHJlYWQuDQo+PiA+DQo+PiA+SSB1bmRlcnN0YW5kIHRoYXQgdGhpcyBpcyBu ZWVkZWQuICBUaGlzIGlzIGdvaW5nIHRvIGJlIHRydWUgZm9yIHRoZQ0KPj4gPm11bHRpLWNhc3Qg RFRMUyBhcyB3ZWxsLiAgSSBhbSBhc3N1bWluZyB0aGF0IHRoaXMgcHJvdG9jb2wgaXMgZ29pbmcg dG8NCj4+ID5iZSB3cml0dGVuIHVzaW5nIHRoZSBSRVNUIHByaW5jaXBsZXMgc28gdGhhdCB0aGlz IGNvbnZlcnNhdGlvbiBpcw0KPj5yZWxldmFudC4NCj4+ID5XaGF0IHdvdWxkIHN0aWxsIG5lZWQg dG8gYmUgZGlzY3Vzc2VkIGF0IGEgbGF0ZXIgZGF0ZSBpcyB0aGUgaW50ZXJuYWwNCj4+ID5tZXNz YWdlIHN0cnVjdHVyZS4gIEhvdyBtdWNoIGRvIHdlIGJlbGlldmUgdGhhdCB0aGUgcmVxdWlyZW1l bnRzIG9mDQo+PiA+dGhpcyBhcmUgY3VycmVudGx5IGRvY3VtZW50ZWQ/DQo+PiANCj4+IEZvciBl eGFtcGxlLCBBQ1JFIChkcmFmdC1zZWl0ei1hY2UtY29yZS1hdXRoei0wMCkgY29udGFpbnMgdGhl IGJhc2ljDQo+PmNhc2VzLg0KPj4gQW5kLCB5ZXMsIG9uZSBvZiB0aGUgcHJpbmNpcGxlcyBvZiBB Q1JFIGlzIHRvIGVzdGFibGlzaCBjb250ZXh0IHVzaW5nDQo+PlJFU1RmdWwNCj4+IHJlc291cmNl cy4gQnV0IHRoZXJlIGlzIG5vIGxpc3Qgb2YgcmVxdWlyZW1lbnRzLiBJbiB0aGUgbmV4dCB2ZXJz aW9uDQo+PnRoaXMgd2lsbA0KPj4gcHJvYmFibHkgYmUgbW9yZSBjbGVhci4NCj4+IA0KPj4gPg0K Pj4gPj4NCj4+ID4+ID4NCj4+ID4+ID5JIHRoaW5rIHRoZSBsaXN0IHN0YXJ0cyBhcyBmb2xsb3dz Og0KPj4gPj4gPg0KPj4gPj4gPjEuICBPbmUgd2F5IGNvbW1hbmQ6IFRoaXMgY292ZXJzIFB1dCwg RGVsZXRlIGFuZCBzbyBmb3J0aC4NCj4+ID4+ID4JQzEgc2VuZHMgYSBjb21tYW5kIHRvIFMxLiAg IFMxIGNhbiAxKSBub3QgcmVwbHksIDIpIHJlcGx5IHN1Y2Nlc3MsDQo+PiA+PiA+MykgcmVwbHkg ZmFpbHVyZQ0KPj4gPj4gPg0KPj4gPj4gPjIuICBRdWVyeS9SZXNwb25zZTogIFRoaXMgY292ZXJz IEdldA0KPj4gPj4gPglDMSByZXF1ZXN0cyBSMSBmcm9tIFMxLiAgUzEgY2FuIDEpIHJlcGx5IHdp dGggZGF0YSwgMikgcmVwbHkgd2l0aA0KPj4gPj4gPmZhaWx1cmUuDQo+PiA+Pg0KPj4gPj4NCj4+ ID4+IEkgZG9u4oCZdCB1bmRlcnN0YW5kIHRoZSBkaXN0aW5jdGlvbiBiZXR3ZWVuICJjb21tYW5k IHdpdGggcmVwbHnigJ0gaW4gMS4NCj4+ID4+YW5kDQo+PiA+PiAiUXVlcnkvUmVzcG9uc2XigJ0g aW4gMi4NCj4+ID4+DQo+PiA+PiBEbyB5b3UgY29uc2lkZXIgUE9TVCBiZSBvZiB0eXBlIDEuIG9y IHR5cGUgMi4sIG9yIGRvZXNu4oCZdCBpdCBtYXR0ZXI/DQo+PiA+DQo+PiA+SSB3b3VsZCB0aGlu ayBvZiBQT1NUIGFzIGJlaW5nIG9mIHR5cGUgMS4gIFRoZSBkaWZmZXJlbmNlIGZvciBtZQ0KPj4g PmJldHdlZW4gdHlwZSAxIGFuZCB0eXBlIDIgaXMgdGhlIHF1ZXN0aW9uICAtIGRvZXMgdGhpcyBv cGVyYXRpb24NCj4+ID5yZXF1aXJlIGEgcmVzcG9uc2Ugb3IgaXMgdGhlIHJlc3BvbnNlIGp1c3Qg bmVjZXNzYXJ5IGlmIHRoZSBDb0FQDQo+Pm1lc3NhZ2UgaXMNCj4+IG1hcmtlZA0KPj4gPmNvbmZp cm1hYmxlLiAgIFRoZSBjb25jZXB0IG9mIGEgR2V0IGZvciB3aGljaCB0aGVyZSBpcyBubyByZXNw b25zZQ0KPj5tYWtlcw0KPj4gPm5vIHNlbnNlLiAgVGhpcyBpcyBub3QgdHJ1ZSBmb3IgYSBQT1NU Lg0KPj4gPg0KPj4gPj4NCj4+ID4+DQo+PiA+PiBJbiB0ZXJtcyBvZiBzZWN1cml0eSBjb25zdHJ1 Y3RzLCB0aGVyZSBpcyBhIG5lZWQgZm9yIGEgMi1wYXNzIFBVVA0KPj4gPj5RdWVyeS9SZXNwb25z ZSAgKGUuZy4gIkxvY2sgYSBkb29yIikgLCB3aGVyZWFzIEdFVCBSZXNwb25zZSBjb3VsZCBiZSBh DQo+PiA+PjEtcGFzcyBzZWN1cmUgbWVzc2FnZSAgKHByb3Blcmx5IGlkZW50aWZpZWQgYW5kIHZl cnNpb25lZCkgcHJlY2VkZWQgYnkNCj4+ID4+YW4gdW5wcm90ZWN0ZWQgR0VUIFJlcXVlc3QuDQo+ PiA+PiBCdXQgbWF5YmUgdGhpcyBjb21lcyBsYXRlcj8gKFRoZXJlIGlzIGFsc28gYSA0LXBhc3Mg 4oCcVW5sb2NrIGEgZG9vciIsDQo+PiA+PmJ1dCBJIGRvbuKAmXQgIHRoaW5rIHRoYXQgc2hvdWxk IGJlIHNvbHZlZCBieSBDT1NFLikNCj4+ID4NCj4+ID5QbGVhc2UgZXhwbGFpbi4gIEkgZG9uJ3Qg dW5kZXJzdGFuZCB3aGF0IHlvdSBhcmUgc2F5aW5nLiAgIEEgY291cGxlIG9mDQo+PiA+ZmxvdyBk aWFncmFtcyBtYXkgYmUgaGVscGZ1bC4NCj4+IA0KPj4gDQo+PiBQdWJsaXNoLXN1YnNjcmliZSBp cyBvbmUgZXhhbXBsZSBvZiAxLXBhc3MgR0VUIFJlc3BvbnNlIChiZXR3ZWVuIFMxIGFuZA0KPj5T MiBpbg0KPj4gNC4gYmVsb3cpLg0KPj4gDQo+PiANCj4+IEZvciAyLXBhc3MgUFVUIChzaG91bGQg cHJvYmFibHkgYmUgUE9TVCkgUXVlcnkvUmVzcG9uc2Ug4oCcbG9jayBhIGRvb3LigJ0NCj4+IHRo aW5rIGUuZy4gYWJvdXQ6DQo+PiANCj4+IGh0dHA6Ly93d3cudGhlZ3VhcmRpYW4uY29tL3RlY2hu b2xvZ3kvMjAxNS9tYXkvMjYvaGlnaC10ZWNoLXRoaWV2ZXMtDQo+PiBqYW1taW5nDQo+PiAtdGVj aG5vbG9neS1zdGVhbC1jYXINCj4+IA0KPj4gDQo+PiBUaGUgY3VycmVudCBwcm90b2NvbCBpcyBi YXNlZCBvbiB0aGUgdXNlciB3YXRjaGluZyB0aGUgYmxpbmtpbmcgbGlnaHRzDQo+Pm9mIHRoZSBj YXINCj4+IGNvbmZpcm1pbmcgaXQgYmVpbmcgbG9ja2VkLiBCZXR0ZXIgaWYgdGhlIGtleSBkZXZp Y2UgdmVyaWZpZWQgdGhhdCB0aGUNCj4+bG9jayByZXF1ZXN0DQo+PiB3YXMgcmVjZWl2ZWQsIGFu ZCBpZiBub3QgYWxlcnRlZCB0aGUgdXNlci4NCj4+IA0KPj4gRm9yICJVbmxvY2sgYSBkb29y4oCd IHRoaW5rIG9mIHRoZSBzYW1lIHNjZW5hcmlvIHdoZXJlIHRoZSBQVVQvUE9TVCB1bmxvY2sNCj4+ IHJlcXVlc3QgZnJvbSB0aGUga2V5IGRldmljZSBpcyByZWNvcmRlZCBieSB0aGUgYWR2ZXJzYXJ5 LiBUaGVuIGl0IHdhaXRzDQo+PmZvciB0aGUNCj4+IHVzZXIgdG8gZ2l2ZSB1cCBhbmQgbGVhdmUu IFRoZW4gaXQgcGxheXMgYmFjayB0aGUgcmVjb3JkZWQgcmVxdWVzdA0KPj4obm90ZSwgdGhpcyBp cw0KPj4gbm90IGEgcmVwbGF5KS4gVGhpcyBjYW4gYmUgbWl0aWdhdGVkIGJ5IG1vcmUgcm91bmQg dHJpcHMsIGFjdHVhbGx5DQo+PjMtcGFzcyBpcw0KPj4gc3VmZmljaWVudC4gQnV0IGFnYWluLCB0 aGlzIHNob3VsZCBwcm9iYWJseSBiZSBpbiB0aGUgYXBwbGljYXRpb24gb2YNCj4+Q09TRS4NCj4+ IA0KPg0KPlNvIGlmIEkgdW5kZXJzdGFuZCBjb3JyZWN0bHksIHlvdSBhcmUgdGFsa2luZyBhYm91 dCB0aGUgZmFjdCB0aGF0IHRoZXJlDQo+bWlnaHQgYmUgc29tZSBzcGVjaWFsIGNpcmN1bXN0YW5j ZXMgIHRoYXQgbWlnaHQgYmUgYXBwbGllZCB0byBhIHNlcmllcyBvZg0KPnJlbGF0ZWQgbWVzc2Fn ZXMgd2hlcmUgZWFjaCBtZXNzYWdlIHdpbGwgaGF2ZSBkaWZmZXJlbnQgY29udGVudCBhbmQgbWln aHQNCj5iZSBkaWZmZXJlbnQgb3BlcmF0aW9ucyAoaS5lLiBhIFB1dCBmb2xsb3dlZCBieSBhIEdl dCkuDQoNClRoaXMgaXMgYSB2ZXJ5IGdlbmVyYWwgc3RhdGVtZW50IGJ1dCB3aGF0IEkgaGFkIGlu IG1pbmQgZml0cyBpbnRvIHRoZQ0KZGVzY3JpcHRpb24uICBXZSB3aWxsIHByb2JhYmx5IGhhdmUg YSBzcGVjaWZpYyBwcm9wb3NhbCBmb3IgaG93IHRvIGhhbmRsZQ0KdGhpcyB0eXBlIG9mIHByb2Js ZW1zLg0KDQpHw7ZyYW4NCg0KPg0KPlNpZGUgbm90ZTogIEkgaGF2ZSBhbHdheXMgY2FsbGVkIHRo YXQgYSByZXBsYXkgYXR0YWNrIHNpbmNlIHRoZSBtZXNzYWdlDQo+d2FzIGludGVyY2VwdGVkIGFu ZCByZXBsYXllZCwgaXQgaXMganVzdCBhIHNwZWNpYWxpemVkIHZlcnNpb24gb2Ygb25lDQo+d2hl cmUgdGhlIG1lc3NhZ2UgaXMgcHJldmVudGVkIGZyb20gYXJyaXZpbmcgYXQgdGhlIGRlc3RpbmF0 aW9uLiAgVGhlc2UNCj5zaG93IHVwIGFsbCBvZiB0aGUgdGltZSBpbiB0ZXJtcyBvZiByZXNldHMg b3Igb3V0IG9mIG9yZGVyIHJlcGxheXMgdGhhdA0KPm5lZWQgdG8gYmUgbG9va2VkIGF0Lg0KPg0K PkppbQ0KPg0KPg0KPj4gDQo+PiBTb3JyeSBubyBmbG93IGNoYXJ0cywgYnV0IHBlcmhhcHMgcG9z c2libGUgdG8gdW5kZXJzdGFuZCBhbnl3YXk/DQo+PiANCj4+ID4NCj4+ID4+DQo+PiA+Pg0KPj4g Pj4gPg0KPj4gPj4gPjMuICBPYnNlcnZhdGlvbjoNCj4+ID4+ID4JQzEgb2JzZXJ2ZXMgUjEgb24g UzEuDQo+PiA+PiA+CQlTMSBjYW4gMSkgcmVwbHkgd2l0aCBkYXRhLCAyKSByZXBseSB3aXRoIGZh aWx1cmUsIDMpIHJlcGx5IHN1Y2Nlc3MNCj4+ID4+ID5idXQgbm8gZGF0YSAoPykNCj4+ID4+ID4J QzEgY2FuY2VscyBvYnNlcnZlIG9mIFIxIG9uIFMxDQo+PiA+PiA+CQlTMSBjYW4gMSkgcmVwbHkg d2l0aCBzdWNjZXNzLCAyKSByZXBseSB3aXRoIGZhaWx1cmUNCj4+ID4+ID4JUzEgc2VuZHMgZGF0 YSBvbiBSMSB0byBDMQ0KPj4gPj4gPg0KPj4gPj4gPjQuICBPYnNlcnZhdGlvbiB3aXRoIGRhdGEg c2VydmVyOg0KPj4gPj4gPglDMSBvYnNlcnZlcyBSMSBmcm9tIFMxIG9uIFMyDQo+PiA+PiA+CQlT MiBjYW4gMSkgcmVwbHkgd2l0aCBkYXRhLCAyKSByZXBseSB3aXRoIGZhaWx1cmUsIDMpIHJlcGx5 IHN1Y2Nlc3MNCj4+ID4+ID5idXQgbm8gZGF0YQ0KPj4gPj4gPglDMSBjYW5jZWxzIG9ic2Vydmlu ZyBSMQ0KPj4gPj4gPgkJUzIgY2FuIDEpIHJlcGx5IHdpdGggc3VjY2VzcywgMikgcmVwbHkgd2l0 aCBmYWlsdXJlDQo+PiA+PiA+CVMyIHNlbmQgZGF0YSBhYm91dCBSMSB0byBDMQ0KPj4gPj4gPgkq KiBTMiBtYXkgbm90IGhhdmUgYWNjZXNzIHRvIGRhdGEgYWJvdXQgUjENCj4+ID4+ID4JKiogU2Vj dXJpdHkgY29udGV4dCB0byBjb21tdW5pY2F0ZSB3aXRoIFMxIGFuZCBTMiBmcm9tIEMxIG1heSBi ZQ0KPj4gPj4gPmRpZmZlcmVudCBhbmQgbm90IG92ZXJsYXANCj4+ID4+ID4JKiogUzIgbWF5IGJl IHJlcXVpcmVkIHRvIHZlcmlmeSBkYXRhIGNhbWUgZnJvbSBTMSwgYnV0IG5vdCBiZSBhYmxlDQo+ PiA+PiA+dG8gYWNjZXNzIFIxLg0KPj4gPj4NCj4+ID4+DQo+PiA+PiBTaW5jZSB5b3Ugd2FudCB0 byBiZSBleGhhdXN0aXZlLCB0aGVyZSBhcmUgb3BlcmF0aW9ucyBiZXR3ZWVuDQo+PiA+PlJlc291 cmNlIFNlcnZlcg0KPj4gPj4gKFMxKSBhbmQgRGF0YSBTZXJ2ZXIgKFMyKS4NCj4+ID4NCj4+ID5J IGRvbid0IGJlbGlldmUgdGhhdCB0aGVzZSBuZWVkIHRvIGJlIGRlYWx0IHdpdGggc2VwYXJhdGVs eSwgYnV0IEkNCj4+ID5jb3VsZCBiZSB3cm9uZy4gIEFyZSB0aGVzZSBub3QganVzdCB0aGUgc2Ft ZSBvcGVyYXRpb25zIHdpdGggZWl0aGVyIHRoZQ0KPj4gPlJlc291cmNlIFNlcnZlciBvciB0aGUg RGF0YSBTZXJ2ZXIgYXMgdGhlIEMxIGFuZCB0aGUgb3RoZXIgYXMgUzE/DQo+PiA+VW5sZXNzIHRo ZXJlIGFyZSB0aHJlZSBwYXJ0aWVzIEkgZG9uJ3QgYmVsaWV2ZSB0aGF0IHRoaXMgaW50cm9kdWNl cyBhbnkNCj4+ID5uZXcgd3JpbmtsZXMuICBEbyB5b3UgaGF2ZSBhbnkgb25lcyBpbiBtaW5kIHdo ZXJlIHRoZXJlIG1pZ2h0IGJlDQo+PiBkaWZmZXJlbmNlcz8NCj4+ID4NCj4+ID4+IE1hcHBpbmcg YmV0d2VlbiB5b3VyIG5vdGF0aW9uIGFuZCBub3RhdGlvbiBvZiBkcmFmdC1pZXRmLWFjZS1hY3Rv cnM6DQo+PiA+Pg0KPj4gPj4gQzEgaW4gQUNFIEM7DQo+PiA+Pg0KPj4gPj4gUzEgaW4gQUNFIFJT Ow0KPj4gPj4NCj4+ID4+IFMyIGluIERhdGEgU2VydmVyOw0KPj4gPj4NCj4+ID4+DQo+PiA+PiBB bHRlcm5hdGl2ZSBkYXRhIGZsb3dzOg0KPj4gPj4NCj4+ID4+IEMyIGluIERhdGEgU2VydmVyIHJl cXVlc3RzIHdpdGggR0VUIChvcHRpb25hbGx5IE9ic2VydmUpIHRvIFMxIGluIEFDRQ0KPj4gPj5S UzsNCj4+ID4NCj4+ID5UaGlzIHdvdWxkIGJlIGNhc2UgIzIgb3IgIzMgYWJvdmUuDQo+PiA+DQo+ PiA+Pg0KPj4gPj4gQzMgaW4gQUNFIFJTIHJlcXVlc3RzIHdpdGggUFVUL1BPU1QgdG8gUzMgKHBv dGVudGlhbGx5IFMyKSBpbiBEYXRhDQo+PiA+PlNlcnZlcjsNCj4+ID4NCj4+ID5UaGlzIHdvdWxk IGJlIGNhc2UgIzEgYWJvdmUuDQo+PiANCj4+IA0KPj4gQWdyZWUsIGp1c3Qgd2FudGVkIHRvIGJl IGV4cGxpY2l0Lg0KPj4gDQo+PiBHw7ZyYW4NCj4+IA0KPj4gDQo+PiA+DQo+PiA+SmltDQo+PiA+ DQo+PiA+Pg0KPj4gPj4NCj4+ID4+DQo+PiA+PiBHw7ZyYW4NCj4+ID4+DQo+PiA+Pg0KPj4gPj4N Cj4+ID4+ID4NCj4+ID4+ID41LiAgVXNlIG9mIGEgUHJveHkgU2VydmVyDQo+PiA+PiA+CUFsbCBv ZiBjYXNlcyAxIHRocm91Z2ggNCBuZWVkIHRvIGJlIHJlcGVhdGVkIGJ1dCB3aXRoIGEgcHJveHkN Cj4+ID4+ID5zZXJ2ZXINCj4+ID4+ID5QMSBiZXR3ZWVuIEMxIGFuZCB0aGUgZW50aXR5IGl0IGlz IHRhbGtpbmcgdG8uDQo+PiA+PiA+DQo+PiA+PiA+V2hhdCBvcGVyYXRpb25zIGFuZCBkYXRhIGZs b3dzIGFtIEkgc3RpbGwgbWlzc2luZz8NCj4+ID4+ID4NCj4+ID4+ID5KaW0NCj4+ID4+ID4NCj4+ ID4+ID4NCj4+ID4+ID5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0KPj4gPj4gPkFjZSBtYWlsaW5nIGxpc3QNCj4+ID4+ID5BY2VAaWV0Zi5vcmcNCj4+ID4+ ID5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2FjZQ0KPj4gPg0KPj4gPg0K Pg0KPg0KDQo= From nobody Wed Sep 23 04:09: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 EA9AD1ACE94; Wed, 23 Sep 2015 04:09:48 -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 xEA6CjbsdHtv; Wed, 23 Sep 2015 04:09:47 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B2FD01A1B5E; Wed, 23 Sep 2015 04:09:47 -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: <20150923110947.975.27071.idtracker@ietfa.amsl.com> Date: Wed, 23 Sep 2015 04:09:47 -0700 Archived-At: Cc: ace@ietf.org Subject: [Ace] I-D Action: draft-ietf-ace-usecases-06.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, 23 Sep 2015 11:09:49 -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-06.txt Pages : 26 Date : 2015-09-23 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 comprises a collection of representative use cases for the application of 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-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ace-usecases-06 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 Sep 23 04:12: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 60C311ACE92 for ; Wed, 23 Sep 2015 04:12:22 -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 q_ssec_MAW3G for ; Wed, 23 Sep 2015 04:12:20 -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 CF8191ACE90 for ; Wed, 23 Sep 2015 04:12:19 -0700 (PDT) Received: by lagj9 with SMTP id j9so46009422lag.2 for ; Wed, 23 Sep 2015 04:12:17 -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=TQy0dkv+Typt61HNnVjglx2fGzrbcRq6iPz3tR9Xxs8=; b=JL1bEASovPcv2mbucIt+P3mxCFKVlXIJ1lsk9YzenMa7ozdvbQCTTRpcWUmd1eFHVU uv8h8t8yTVVQsR9dW03mdWoLZxpRjxnqGdow7kclM7vo13BSAPJ+LIQCBfQb8TcI0ra4 tQtbBO+F0G3AWEupVt6YGCT3Oe6K8KLNhSaPtjocBCv8PGpjaqQN47Zm6y9ObKUUVVh2 gdKeEADyYMZMV04QQW/oyvL4xJ1IlXxZu0MsVNXzZ0/rWYhJgFhAewwkbB8z2SfMgWgN +OLCHSiwhGgx7A3umIe2h2j4W92eoSfJKyjmMMg4GteCyVa21ydpivKcFX4gryh9Ey5c 59kw== X-Gm-Message-State: ALoCoQnTzvwB4Ge0e04je+jd3k9Tsjyd7qj/TumJCJhUgHAc64scihe/79UHQ+fs6wYrV1k/tWGy X-Received: by 10.152.6.100 with SMTP id z4mr11238062laz.69.1443006737549; Wed, 23 Sep 2015 04:12:17 -0700 (PDT) Received: from [192.168.0.108] ([85.235.11.178]) by smtp.gmail.com with ESMTPSA id k19sm545126lfg.8.2015.09.23.04.12.16 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 23 Sep 2015 04:12:16 -0700 (PDT) References: <20150923110948.975.82548.idtracker@ietfa.amsl.com> To: "ace@ietf.org" From: Ludwig Seitz X-Forwarded-Message-Id: <20150923110948.975.82548.idtracker@ietfa.amsl.com> Message-ID: <56028910.7030104@sics.se> Date: Wed, 23 Sep 2015 13:12:16 +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: <20150923110948.975.82548.idtracker@ietfa.amsl.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms020207000006090408070104" Archived-At: Subject: [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: Wed, 23 Sep 2015 11:12:22 -0000 This is a cryptographically signed message in MIME format. --------------ms020207000006090408070104 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Hello ACE, we have submitted a new version of the usecases draft addressing the=20 comments of the second WGLC, especially those made by: Kepeng Li Prashant Jhingran Jim Schaad Regards, Ludwig -------- Forwarded Message -------- Subject: New Version Notification for draft-ietf-ace-usecases-06.txt A new version of I-D, draft-ietf-ace-usecases-06.txt has been successfully submitted by Ludwig Seitz and posted to the IETF repository. Name: draft-ietf-ace-usecases Revision: 06 Title: ACE use cases Document date: 2015-09-23 Group: ace Pages: 26 URL:=20 https://www.ietf.org/internet-drafts/draft-ietf-ace-usecases-06.txt Status: https://datatracker.ietf.org/doc/draft-ietf-ace-usecases/= Htmlized: https://tools.ietf.org/html/draft-ietf-ace-usecases-06 Diff: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ace-usecas= es-06 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 comprises a collection of representative use cases for the application of 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 --------------ms020207000006090408070104 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 DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE1MDkyMzExMTIxNlowLwYJKoZI hvcNAQkEMSIEIMbe5CU993XUxNYL10KtUftjrkXZ2faIn5Vt68C4JEQrMGwGCSqGSIb3DQEJ DzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0D AgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgaUGCSsGAQQB gjcQBDGBlzCBlDCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzAp BgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0 YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgMMhpgwgacG CyqGSIb3DQEJEAILMYGXoIGUMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20g THRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG A1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EC AwyGmDANBgkqhkiG9w0BAQEFAASCAQABhiC42rSqcmFaLoBNE5U0T2Po+i1YuEYQ7dJpYXBM iVRSd/9rLRjznnIPZEj6ZYSZ6vjD7+K+h+sSlp9BrF7ez1O4hwbCaWYRc4dVetA+iVExuk6r FcRfn2R0q3J/AynaLSTBgdUUUdbdRMlpdEcCQ7g6jvcqPxkj7o3PeAFhr74l7Ju6mIU3+0L3 ymljgpyt2SqvyBqr8C/zXRdyw5KBVQCz3p0YQOtixDp/3SuMSTY7cLt28GGvy1ha6ly0lrg6 5ziDDOjbs3cwuE1cHfMlehERWay6GBvZg7GNPlN8zvFcYSkw3pkn3vJOVLaCF012YdPqxpcy o2Av6r2hO1B/AAAAAAAA --------------ms020207000006090408070104-- From nobody Wed Sep 23 13:32: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 DE9D71B2C64 for ; Wed, 23 Sep 2015 13:32:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.6 X-Spam-Level: X-Spam-Status: No, score=-1.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 xjRs0OXWqffy for ; Wed, 23 Sep 2015 13:32:20 -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 89A671B2C56 for ; Wed, 23 Sep 2015 13:32:18 -0700 (PDT) Received: from hebrews (173-8-216-38-Oregon.hfc.comcastbusiness.net [173.8.216.38]) (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 CB3A838F16; Wed, 23 Sep 2015 13:32:17 -0700 (PDT) From: "Jim Schaad" To: =?UTF-8?Q?'G=C3=B6ran_Selander'?= , References: <021b01d0f34f$3ef676d0$bce36470$@augustcellars.com> <049601d0f4f8$d40e7b50$7c2b71f0$@augustcellars.com> <006901d0f5c2$c32de5d0$4989b170$@augustcellars.com> In-Reply-To: Date: Wed, 23 Sep 2015 13:29:52 -0700 Message-ID: <014e01d0f63e$9ac6cef0$d0546cd0$@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: AQIWMh3Pv5gwExSgDndbS6D7wY2CTAHjakphAVlh2dYCj3bwNQN4gNNtAkiTVnWdY63YEA== Archived-At: Subject: Re: [Ace] End-to-End Scenarios 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, 23 Sep 2015 20:32:22 -0000 > -----Original Message----- > From: G=C3=B6ran Selander [mailto:goran.selander@ericsson.com] > Sent: Tuesday, September 22, 2015 11:12 PM > To: Jim Schaad ; ace@ietf.org > Subject: Re: [Ace] End-to-End Scenarios >=20 >=20 >=20 > On 2015-09-23 07:43, "Jim Schaad" wrote: >=20 > >> >> In terms of security constructs, there is a need for a 2-pass = PUT > >> >>Query/Response (e.g. "Lock a door") , whereas GET Response could > >> >>be a 1-pass secure message (properly identified and versioned) > >> >>preceded by an unprotected GET Request. > >> >> But maybe this comes later? (There is also a 4-pass = =E2=80=9CUnlock a > >> >>door", but I don=E2=80=99t think that should be solved by COSE.) > >> > > >> >Please explain. I don't understand what you are saying. A = couple of > >> >flow diagrams may be helpful. > >> > >> > >> Publish-subscribe is one example of 1-pass GET Response (between S1 > >>and > >>S2 in > >> 4. below). > >> > >> > >> For 2-pass PUT (should probably be POST) Query/Response = =E2=80=9Clock a door=E2=80=9D > >> think e.g. about: > >> > >> = http://www.theguardian.com/technology/2015/may/26/high-tech-thieves- > >> jamming > >> -technology-steal-car > >> > >> > >> The current protocol is based on the user watching the blinking > >>lights of the car confirming it being locked. Better if the key > >>device verified that the lock request was received, and if not > >>alerted the user. > >> > >> For "Unlock a door=E2=80=9D think of the same scenario where the = PUT/POST > >>unlock request from the key device is recorded by the adversary. = Then > >>it waits for the user to give up and leave. Then it plays back the > >>recorded request (note, this is not a replay). This can be = mitigated > >>by more round trips, actually 3-pass is sufficient. But again, this > >>should probably be in the application of COSE. > >> > > > >So if I understand correctly, you are talking about the fact that = there > >might be some special circumstances that might be applied to a = series > >of related messages where each message will have different content = and > >might be different operations (i.e. a Put followed by a Get). >=20 > This is a very general statement but what I had in mind fits into the = description. > We will probably have a specific proposal for how to handle this type = of > problems. Would you characterize all of these n-pass situations as being part of a = single "transaction" or do you not believe that to be the case? Jim >=20 > G=C3=B6ran >=20 > > From nobody Wed Sep 23 18:04: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 2EF881B2FCA for ; Wed, 23 Sep 2015 18:04:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.7 X-Spam-Level: X-Spam-Status: No, score=0.7 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 ISm-rg6Ex9iD for ; Wed, 23 Sep 2015 18:04:34 -0700 (PDT) Received: from mail-wi0-x22b.google.com (mail-wi0-x22b.google.com [IPv6:2a00:1450:400c:c05::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 6876E1B2FC6 for ; Wed, 23 Sep 2015 18:04:34 -0700 (PDT) Received: by wicfx3 with SMTP id fx3so7351224wic.1 for ; Wed, 23 Sep 2015 18:04:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=xwLqtFhTiEHei/PyiVM1j0Kpg7ldTYMgoKkwOGQlbxY=; b=GPyThqMtSJXGzN+nTOl0CmLrxcpC7v1iG3YvC766mA5L16o0wiGFFTdSSg7XKufXIq ZKnt432PFbxNS4fXCJuQEaMBPBiIniIWD+qkU81Dp9ntAKy06sCj+F7MfrW8jgb9uSei IelnkVhTz63FspSAPT5NBI8rmpaaSE2fXgkvwNFCZ7bi3cE9gMMFJC6HomYkYi6ANqi6 tzvljtnzkOnF8fV/C0Lh5OHVZhT6AAla3r1s8mAKqE7vzvV/BnBKHb2r1B82DckxkEvJ aI/eHccpBOd0ZKYnnD4iIKYHRHlQ+nDuElTF5yLzTUzW/jrJu/T4dxce/L3U0u3oY3lp miXw== MIME-Version: 1.0 X-Received: by 10.180.186.74 with SMTP id fi10mr6461130wic.61.1443056672957; Wed, 23 Sep 2015 18:04:32 -0700 (PDT) Received: by 10.28.214.213 with HTTP; Wed, 23 Sep 2015 18:04:32 -0700 (PDT) Date: Wed, 23 Sep 2015 21:04:32 -0400 Message-ID: From: Kathleen Moriarty To: "ace@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [Ace] AD review of draft-ietf-ace-usecases-05 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, 24 Sep 2015 01:04:36 -0000 Hello, Thanks for the quick turn around in an update after this WG last call. I did my review a little early in hopes that we could progress this to IETF last call soon. The shepherd report will check all comments from the WG last call as well, but we can start this in parallel. ACE Use Case Draft review: It seems the "Authorization problem summary" lists contain a mix of desired capabilities/requirements and problems. Is this the right heading for this section? Section 2.2.5 - new homeowner would want to control the list of all authorized users at any given time to the house or connected devices (in the case where device management may have separate permissions from house access). At time of transfer of the house, they will want to make sure the previous owners and any contractors no longer have access. Nanny/cleaners/plumbers might have access to the house, but not to configure or access the camera monitors. Section 2.3 line 4 s/lead/led/ between products has lead to initiatives such as Continua Alliance Section 2.5.4 - Wouldn't the user want access to the usage information, while preventing "others" (might include neighbors or attackers - already covered in U5.9) from accessing the system? The consumer is not included in the list is why I ask. Section 2.6.1 Do such shoes exist? The watch example is a common one in use today. Section 2.6.2 Other sections are more explicit on problems, so shouldn't this section list out that When Jody connects the watch to upload her data to her fitness account, no other data is uploaded? I'm not sure how realistic it is to have multiple profiles with access rights on a sports watch. Is this a feasible example? Are there watches that do this today or smart phone apps for running that allow for multiple profiles? Section 2.7.2 Are different levels of access required? Is that an authorization challenge that needs to be considered for let's say operators vs. auditors of the platform? I see you have that in section 3.2, but should it be here too? Section 3.1 Usage information in transit should also be protected. In addition to privacy, there could be opportunities for fraud. In the case of utilities, in some cases with renewable energy, money is given to the home owner for generating x amount of energy on top of the usage being covered. With this, there are opportunities for fraud on usage as well as with payment for generation. I can explain more if needed on this example. There is no need to include my example, more that we should consider this a security problem too because of the possibility of fraud, not just privacy. Thank you! -- Best regards, Kathleen From nobody Wed Sep 23 21:32: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 8D5D41B301F for ; Wed, 23 Sep 2015 21:32:03 -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 cmbzc3Ceq5v7 for ; Wed, 23 Sep 2015 21:32:01 -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 571FC1B2D56 for ; Wed, 23 Sep 2015 21:32:01 -0700 (PDT) X-AuditID: c1b4fb25-f79a26d00000149a-6d-56037cbfe717 Received: from ESESSHC011.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id A0.6F.05274.FBC73065; Thu, 24 Sep 2015 06:31:59 +0200 (CEST) Received: from ESESSMB303.ericsson.se ([169.254.3.186]) by ESESSHC011.ericsson.se ([153.88.183.51]) with mapi id 14.03.0248.002; Thu, 24 Sep 2015 06:31:58 +0200 From: =?utf-8?B?R8O2cmFuIFNlbGFuZGVy?= To: Jim Schaad , "ace@ietf.org" Thread-Topic: [Ace] End-to-End Scenarios Thread-Index: AdDzTJuCqeOcgZ3iQWWV4hFj3veTUQBpM2AA///tTYCAADkdAIABWr+AgAApmQCAAM4YAIAAqDqA Date: Thu, 24 Sep 2015 04:31:57 +0000 Message-ID: References: <021b01d0f34f$3ef676d0$bce36470$@augustcellars.com> <049601d0f4f8$d40e7b50$7c2b71f0$@augustcellars.com> <006901d0f5c2$c32de5d0$4989b170$@augustcellars.com> <014e01d0f63e$9ac6cef0$d0546cd0$@augustcellars.com> In-Reply-To: <014e01d0f63e$9ac6cef0$d0546cd0$@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.149] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpikeLIzCtJLcpLzFFi42KZGfG3Rnd/DXOYwatDohbfv/UwW6ye/p3N gclj45zpbB5LlvxkCmCK4rJJSc3JLEst0rdL4Mq40tXIUrBEpWLNzenMDYxrlLsYOTkkBEwk Pqy+xQhhi0lcuLeerYuRi0NI4CijxLy/GxghnCWMEr++XwWrYhNwkXjQ8IgJxBYRcJM4O3kZ C4gtLKAuseH0V6i4hsSUOe+YIewoicv/J4PVsAioSiw7+hxsDq+AhcTvfxBzhATeMUmc7xEC sTkFHCTmrFwPVsMIdNH3U2vAapgFxCVuPZnPBHGpgMSSPeeZIWxRiZeP/7GC2KICehIrrzex QcSVJNYe3g60lwOoV1Ni/S59CNNa4tysKoiJihJTuh+yQ1wjKHFy5hOWCYzis5Asm4XQPAuh eRaS5llImhcwsq5iFC1OLU7KTTcy1kstykwuLs7P08tLLdnECIy0g1t+q+5gvPzG8RCjAAej Eg+vQiRzmBBrYllxZe4hRmkOFiVx3mamB6FCAumJJanZqakFqUXxRaU5qcWHGJk4OKUaGF1O eC06o1DyzWZ5Jr/yismp+4N6fpnapvw690jLbMWhhb4n965qa43e0/cy+GBvJc+h5MNZW0zP Pt4z2zBqcdrrTo5vjkaRhZkvPh/nuPs8S92mcIdpxhTZRRlbeqeu3XBB+u7c735ch3RzbFi+ z3d4UWa771xB49+QqaV77/mW7+8x2LP9bKYSS3FGoqEWc1FxIgCZ5JpflQIAAA== Archived-At: Subject: Re: [Ace] End-to-End Scenarios 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, 24 Sep 2015 04:32:03 -0000 DQoNCk9uIDIwMTUtMDktMjMgMjI6MjksICJKaW0gU2NoYWFkIiA8aWV0ZkBhdWd1c3RjZWxsYXJz LmNvbT4gd3JvdGU6DQoNCj4NCj4NCj4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+PiBG cm9tOiBHw7ZyYW4gU2VsYW5kZXIgW21haWx0bzpnb3Jhbi5zZWxhbmRlckBlcmljc3Nvbi5jb21d DQo+PiBTZW50OiBUdWVzZGF5LCBTZXB0ZW1iZXIgMjIsIDIwMTUgMTE6MTIgUE0NCj4+IFRvOiBK aW0gU2NoYWFkIDxpZXRmQGF1Z3VzdGNlbGxhcnMuY29tPjsgYWNlQGlldGYub3JnDQo+PiBTdWJq ZWN0OiBSZTogW0FjZV0gRW5kLXRvLUVuZCBTY2VuYXJpb3MNCj4+IA0KPj4gDQo+PiANCj4+IE9u IDIwMTUtMDktMjMgMDc6NDMsICJKaW0gU2NoYWFkIiA8aWV0ZkBhdWd1c3RjZWxsYXJzLmNvbT4g d3JvdGU6DQo+PiANCj4+ID4+ID4+IEluIHRlcm1zIG9mIHNlY3VyaXR5IGNvbnN0cnVjdHMsIHRo ZXJlIGlzIGEgbmVlZCBmb3IgYSAyLXBhc3MgUFVUDQo+PiA+PiA+PlF1ZXJ5L1Jlc3BvbnNlICAo ZS5nLiAiTG9jayBhIGRvb3IiKSAsIHdoZXJlYXMgR0VUIFJlc3BvbnNlIGNvdWxkDQo+PiA+PiA+ PmJlIGEgMS1wYXNzIHNlY3VyZSBtZXNzYWdlICAocHJvcGVybHkgaWRlbnRpZmllZCBhbmQgdmVy c2lvbmVkKQ0KPj4gPj4gPj5wcmVjZWRlZCBieSBhbiB1bnByb3RlY3RlZCBHRVQgUmVxdWVzdC4N Cj4+ID4+ID4+IEJ1dCBtYXliZSB0aGlzIGNvbWVzIGxhdGVyPyAoVGhlcmUgaXMgYWxzbyBhIDQt cGFzcyDigJxVbmxvY2sgYQ0KPj4gPj4gPj5kb29yIiwgYnV0IEkgZG9u4oCZdCAgdGhpbmsgdGhh dCBzaG91bGQgYmUgc29sdmVkIGJ5IENPU0UuKQ0KPj4gPj4gPg0KPj4gPj4gPlBsZWFzZSBleHBs YWluLiAgSSBkb24ndCB1bmRlcnN0YW5kIHdoYXQgeW91IGFyZSBzYXlpbmcuICAgQSBjb3VwbGUN Cj4+b2YNCj4+ID4+ID5mbG93IGRpYWdyYW1zIG1heSBiZSBoZWxwZnVsLg0KPj4gPj4NCj4+ID4+ DQo+PiA+PiBQdWJsaXNoLXN1YnNjcmliZSBpcyBvbmUgZXhhbXBsZSBvZiAxLXBhc3MgR0VUIFJl c3BvbnNlIChiZXR3ZWVuIFMxDQo+PiA+PmFuZA0KPj4gPj5TMiBpbg0KPj4gPj4gNC4gYmVsb3cp Lg0KPj4gPj4NCj4+ID4+DQo+PiA+PiBGb3IgMi1wYXNzIFBVVCAoc2hvdWxkIHByb2JhYmx5IGJl IFBPU1QpIFF1ZXJ5L1Jlc3BvbnNlIOKAnGxvY2sgYSBkb29y4oCdDQo+PiA+PiB0aGluayBlLmcu IGFib3V0Og0KPj4gPj4NCj4+ID4+IGh0dHA6Ly93d3cudGhlZ3VhcmRpYW4uY29tL3RlY2hub2xv Z3kvMjAxNS9tYXkvMjYvaGlnaC10ZWNoLXRoaWV2ZXMtDQo+PiA+PiBqYW1taW5nDQo+PiA+PiAt dGVjaG5vbG9neS1zdGVhbC1jYXINCj4+ID4+DQo+PiA+Pg0KPj4gPj4gVGhlIGN1cnJlbnQgcHJv dG9jb2wgaXMgYmFzZWQgb24gdGhlIHVzZXIgd2F0Y2hpbmcgdGhlIGJsaW5raW5nDQo+PiA+Pmxp Z2h0cyBvZiB0aGUgY2FyICBjb25maXJtaW5nIGl0IGJlaW5nIGxvY2tlZC4gQmV0dGVyIGlmIHRo ZSBrZXkNCj4+ID4+ZGV2aWNlIHZlcmlmaWVkIHRoYXQgdGhlIGxvY2sgcmVxdWVzdCAgd2FzIHJl Y2VpdmVkLCBhbmQgaWYgbm90DQo+PiA+PmFsZXJ0ZWQgdGhlIHVzZXIuDQo+PiA+Pg0KPj4gPj4g Rm9yICJVbmxvY2sgYSBkb29y4oCdIHRoaW5rIG9mIHRoZSBzYW1lIHNjZW5hcmlvIHdoZXJlIHRo ZSBQVVQvUE9TVA0KPj4gPj51bmxvY2sgIHJlcXVlc3QgZnJvbSB0aGUga2V5IGRldmljZSBpcyBy ZWNvcmRlZCBieSB0aGUgYWR2ZXJzYXJ5LiBUaGVuDQo+PiA+Pml0IHdhaXRzIGZvciB0aGUgIHVz ZXIgdG8gZ2l2ZSB1cCBhbmQgbGVhdmUuIFRoZW4gaXQgcGxheXMgYmFjayB0aGUNCj4+ID4+cmVj b3JkZWQgcmVxdWVzdCAobm90ZSwgdGhpcyBpcyAgbm90IGEgcmVwbGF5KS4gVGhpcyBjYW4gYmUg bWl0aWdhdGVkDQo+PiA+PmJ5IG1vcmUgcm91bmQgdHJpcHMsIGFjdHVhbGx5IDMtcGFzcyBpcyAg c3VmZmljaWVudC4gQnV0IGFnYWluLCB0aGlzDQo+PiA+PnNob3VsZCBwcm9iYWJseSBiZSBpbiB0 aGUgYXBwbGljYXRpb24gb2YgQ09TRS4NCj4+ID4+DQo+PiA+DQo+PiA+U28gaWYgSSB1bmRlcnN0 YW5kIGNvcnJlY3RseSwgeW91IGFyZSB0YWxraW5nIGFib3V0IHRoZSBmYWN0IHRoYXQgdGhlcmUN Cj4+ID5taWdodCBiZSBzb21lIHNwZWNpYWwgY2lyY3Vtc3RhbmNlcyAgdGhhdCBtaWdodCBiZSBh cHBsaWVkIHRvIGEgc2VyaWVzDQo+PiA+b2YgcmVsYXRlZCBtZXNzYWdlcyB3aGVyZSBlYWNoIG1l c3NhZ2Ugd2lsbCBoYXZlIGRpZmZlcmVudCBjb250ZW50IGFuZA0KPj4gPm1pZ2h0IGJlIGRpZmZl cmVudCBvcGVyYXRpb25zIChpLmUuIGEgUHV0IGZvbGxvd2VkIGJ5IGEgR2V0KS4NCj4+IA0KPj4g VGhpcyBpcyBhIHZlcnkgZ2VuZXJhbCBzdGF0ZW1lbnQgYnV0IHdoYXQgSSBoYWQgaW4gbWluZCBm aXRzIGludG8gdGhlDQo+PmRlc2NyaXB0aW9uLg0KPj4gV2Ugd2lsbCBwcm9iYWJseSBoYXZlIGEg c3BlY2lmaWMgcHJvcG9zYWwgZm9yIGhvdyB0byBoYW5kbGUgdGhpcyB0eXBlIG9mDQo+PiBwcm9i bGVtcy4NCj4NCj5Xb3VsZCB5b3UgY2hhcmFjdGVyaXplIGFsbCBvZiB0aGVzZSBuLXBhc3Mgc2l0 dWF0aW9ucyBhcyBiZWluZyBwYXJ0IG9mIGENCj5zaW5nbGUgInRyYW5zYWN0aW9uIiBvciBkbyB5 b3Ugbm90IGJlbGlldmUgdGhhdCB0byBiZSB0aGUgY2FzZT8NCg0KVGhlIHR3byBtb3JlLXRoYW4t MS1wYXNzIOKAnHNpdHVhdGlvbnPigJ0gbWVudGlvbmVkIGhlcmUgYXJlIGFib3V0IHByb3RlY3Rp bmcNCmFjdHVhdGlvbnMgb2YgdGhlIGtpbmQg4oCcdHVybiBvbuKAnSAvICJ0dXJuIG9mZuKAnSBm cm9tIGNlcnRhaW4gdGhyZWF0cyBvZiBEb1MNCmFuZC9vciByZXBsYXkuIElmIHlvdSBjb25zaWRl ciDigJx0dXJuIG9u4oCdIGFuZCDigJx0dXJuIG9mZuKAnSB0byBiZSAic2luZ2xlDQp0cmFuc2Fj dGlvbnPigJ0gdGhlbiB5ZXMuDQoNCkkgY2Fu4oCZdCBzYXkgaG93IHRoaXMgd291bGQgbG9vayBp biBnZW5lcmFsLCBidXQgSSB3b3VsZCB0aGluayB0aGVyZSBpcw0Kb25seSBhIGZldyB2YXJpYW50 cyBkZXBlbmRpbmcgb24gd2hpY2ggcGFydHkvcGFydGllcyByZXF1aXJlIGZyZXNobmVzcyBhbmQN CndoaWNoIHBhcnR5IGluaXRpYXRlcyBvciByZXF1aXJlcyBjb25maXJtYXRpb24gdGhhdCB0aGUg dHJhbnNhY3Rpb24gaXMNCmZpbmlzaGVkLg0KDQpOb3RlIHRoYXQgdGhlIGlzc3VlIGlzIG5vdCBv YmplY3Qgc2VjdXJpdHkgcmVsYXRlZCwgdGhlIGF0dGFjayBhcHBsaWVzDQplcXVhbGx5IHdlbGwg dG8gVExTIHJlY29yZCBsYXllci4gU28gaXQgc2hvdWxkIG5vdCBiZSBzaG91bGQgbm90IGJlIHNv bHZlZA0KaW4gQ09TRSBvciBPU0NPQVAuDQoNCkfDtnJhbg0KDQo+DQo+SmltDQo+DQo+PiANCj4+ IEfDtnJhbg0KPj4gDQo+PiA+DQo+DQo+DQoNCg== From nobody Thu Sep 24 00:42: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 804531A212D for ; Thu, 24 Sep 2015 00:42:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.2 X-Spam-Level: X-Spam-Status: No, score=-1.2 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, 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 OYPimRGNOdnY for ; Thu, 24 Sep 2015 00:42:34 -0700 (PDT) Received: from mail-la0-f54.google.com (mail-la0-f54.google.com [209.85.215.54]) (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 1F7531A01FA for ; Thu, 24 Sep 2015 00:42:33 -0700 (PDT) Received: by lahh2 with SMTP id h2so53113153lah.0 for ; Thu, 24 Sep 2015 00:42:30 -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=pBlyrWu6F7Cw4Y3L29h+/AtW3i4dh9l03vqZ8DyVa5U=; b=mMKnWYN5R1ClCCAae4CNSdf4fF/qo0l+tvJxqBfMV1GAkmo2ugcKzCKQnz84qwMwH9 /QDME2M0BrX3Z9qzlo/BTQU7DG20SygXXq0oQR+Owl8stNutDxQF08IuVp7YBvcZCLpD 0VVIvUVTY+cF738Land07QQuaNsPHtQ8Q9eUahcfxce6khctKbuu9AwTLMlXbEaua/8G 0HFHA33Nimf/z7/XHUtMz1kYCD+UuOAlW57Evne6fXp9vTZMNfcm6TpXWYdHa2FYYCtR dP2ACVzu4jAyemwQcN0XjYUOS4vuCbwKRGOQqZwb8bvdLSUrfJseDm1XuAZ/dxC8nMyp sQzA== X-Gm-Message-State: ALoCoQmHiugYtNQEpY5YpKOFnv5ZxSxfOTki0E0jyDAwKxehBBlru3iKyXpNHLG8NQShq3iI1+27 X-Received: by 10.152.5.133 with SMTP id s5mr12960729las.19.1443080550640; Thu, 24 Sep 2015 00:42:30 -0700 (PDT) Received: from [192.168.0.108] ([85.235.11.178]) by smtp.gmail.com with ESMTPSA id w9sm1230952lad.41.2015.09.24.00.42.29 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 24 Sep 2015 00:42:29 -0700 (PDT) To: ace@ietf.org References: From: Ludwig Seitz Message-ID: <5603A964.6040100@sics.se> Date: Thu, 24 Sep 2015 09:42:28 +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="------------ms010304040206060406050806" Archived-At: Subject: Re: [Ace] AD review of draft-ietf-ace-usecases-05 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, 24 Sep 2015 07:42:37 -0000 This is a cryptographically signed message in MIME format. --------------ms010304040206060406050806 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable Kathleen, thank you for your review. I don't think the changes from 05 to 06=20 affect you comments, so I'll just apply them to 06. Comments inline Regards, Ludwig On 2015-09-24 03:04, Kathleen Moriarty wrote: > Hello, > > Thanks for the quick turn around in an update after this WG last call. > I did my review a little early in hopes that we could progress this to > IETF last call soon. The shepherd report will check all comments from > the WG last call as well, but we can start this in parallel. > > ACE Use Case Draft review: > > It seems the "Authorization problem summary" lists contain a mix of > desired capabilities/requirements and problems. Is this the right > heading for this section? We have tried to steer away from specific requirements in order to=20 reduce the tendency towards requirements engineering. It is clear that many of the problems could be easily reinterpreted as=20 generic desired capabilities and generic requirements. The point we are trying to make is this: Various entities have requirements and desired capabilities in the=20 different use cases, some of these lead to authorization problems=20 involving constrained devices, which ACE has the ambition to solve. We=20 tried to capture the latter in the sections called "Authorization=20 problems summary". I've no problem changing the section headers, as long as the indention=20 of the document remains clear. I'm grateful for suggestions on how to=20 proceed here. > Section 2.2.5 > - new homeowner would want to control the list of all authorized users > at any given time to the house or connected devices (in the case where > device management may have separate permissions from house access). > At time of transfer of the house, they will want to make sure the > previous owners and any contractors no longer have access. > I guess this is best addressed by adding a sentence or two in section=20 2.2.4 (which might lead to new points in 2.2.5). > Nanny/cleaners/plumbers might have access to the house, but not to > configure or access the camera monitors. > This is kind of similar to 2.2.3 (the visitor scenario), where someone=20 is given restricted access. I think the cleanest solution would be to=20 extend section 2.2.3 to avoid duplication. > > Section 2.3 line 4 > s/lead/led/ > between products has lead to initiatives such as Continua Alliance > ok > Section 2.5.4 > > - Wouldn't the user want access to the usage information, while > preventing "others" (might include neighbors or attackers - already > covered in U5.9) from accessing the system? The consumer is not > included in the list is why I ask. > Right, I'll formulate a point to cover this more clearly > Section 2.6.1 > Do such shoes exist? The watch example is a common one in use today. > No idea, Steffi? > Section 2.6.2 > Other sections are more explicit on problems, so shouldn't this > section list out that When Jody connects the watch to upload her data > to her fitness account, no other data is uploaded? We'll add that explicitly. > > I'm not sure how realistic it is to have multiple profiles with access > rights on a sports watch. Is this a feasible example? Are there > watches that do this today or smart phone apps for running that allow > for multiple profiles? > Not sure, Steffi you wrote that one, could you investigate? > Section 2.7.2 > Are different levels of access required? Is that an authorization > challenge that needs to be considered for let's say operators vs. > auditors of the platform? I see you have that in section 3.2, but > should it be here too? > Yes it should, I'll add such an item > Section 3.1 > Usage information in transit should also be protected. In addition to > privacy, there could be opportunities for fraud. In the case of > utilities, in some cases with renewable energy, money is given to the > home owner for generating x amount of energy on top of the usage being > covered. With this, there are opportunities for fraud on usage as > well as with payment for generation. I can explain more if needed on > this example. There is no need to include my example, more that we > should consider this a security problem too because of the possibility > of fraud, not just privacy. > Just to make sure I get your point correctly: You are missing a=20 paragraph on protection of information in transit in the security=20 considerations? My gut feeling is that it would fit in conjunction with the paragraph on = pervasive monitoring, since there is some overlap in the protection=20 measures. --=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 --------------ms010304040206060406050806 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 DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE1MDkyNDA3NDIyOFowLwYJKoZI hvcNAQkEMSIEIHGZ/CkWv36ktpvR2971WL963FG5RLXH5fP+zBWUukevMGwGCSqGSIb3DQEJ DzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0D AgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgaUGCSsGAQQB gjcQBDGBlzCBlDCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzAp BgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0 YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgMMhpgwgacG CyqGSIb3DQEJEAILMYGXoIGUMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20g THRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG A1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EC AwyGmDANBgkqhkiG9w0BAQEFAASCAQAMn1JIRt+6tJz2z7Y0lAaXbNA0HysTgLL4KuSkYfDZ cULWYSWjblFsV2eEmuB9lIfJBns2fVfE+v0R3vPnbW8Vc/rwfMIH+1GzCS37pAh9KzUrrhj4 XbCjEWoLyaYNmKtCwbkgojSEkhlr+uIVZ7CkK6R6U31FSdvoOYnHhpvPGA4RDqIjlRgpFgJE kGIsvBLB/3p1r6N5Ac+zWGVjyZp5OkhLpzIi6QJGM3g8Pb29ztwl3T1sy3wFV++O7IeyfCck G5/DyaTf/RNuht7KzqNkYFUKlWq0TyCIZdyHN9BlL3YFsRCbVuUpCeMbbfkoU1YuGlorQ/c+ g1VAaaHRdY7OAAAAAAAA --------------ms010304040206060406050806-- From nobody Fri Sep 25 02:30: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 01E561A0031 for ; Fri, 25 Sep 2015 02:30:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.15 X-Spam-Level: * X-Spam-Status: No, score=1.15 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 WbjafsE2bY2e for ; Fri, 25 Sep 2015 02:30:45 -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 6DA921A0367 for ; Fri, 25 Sep 2015 02:30:45 -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 t8P9Ufvq024079; Fri, 25 Sep 2015 11:30:41 +0200 (CEST) Received: from [192.168.1.109] (p57A63B54.dip0.t-ipconnect.de [87.166.59.84]) (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 3nMnzP1Ld1z4p5N; Fri, 25 Sep 2015 11:30:41 +0200 (CEST) From: Stefanie Gerdes To: Kathleen Moriarty , "ace@ietf.org" References: X-Enigmail-Draft-Status: N1110 Message-ID: <5605143C.4010804@tzi.de> Date: Fri, 25 Sep 2015 11:30:36 +0200 User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Ace] AD review of draft-ietf-ace-usecases-05 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, 25 Sep 2015 09:30:49 -0000 Hi Kathleen, Thank you for your review. Some comments regarding the Sports and Entertainment use case inline. On 09/24/2015 03:04 AM, Kathleen Moriarty wrote: > > Section 2.6.1 > Do such shoes exist? The watch example is a common one in use today. Nike+ shoes have a wireless chip with a sensor [1]. There are two different models of sensor enabled shoes, the normal nike+ shoe has a pocket in the left shoe for a single sensor, the basketball shoe [2] is equipped with several sensors that can be used to measure, e.g, jump height and quickness. Other than Nike, there is e.g. runScribe [3] that also has a sensor in one shoe. There are other approaches where sensors are integrated in socks [4]. This is only one example for sensors in sportswear that are designed to improve the training. Another example is sensors to improve the swing or stroke [5]. > > Section 2.6.2 > Other sections are more explicit on problems, so shouldn't this > section list out that When Jody connects the watch to upload her data > to her fitness account, no other data is uploaded? > > I'm not sure how realistic it is to have multiple profiles with access > rights on a sports watch. Is this a feasible example? Are there > watches that do this today or smart phone apps for running that allow > for multiple profiles? The technology is still very new, so it is difficult to say in which direction they will be heading. However, runScribe claims that their product can be shared with family and friends and that it will be possible to create different user profiles [6]. Is there something I can add to the section to address your questions? Thanks, Steffi [1] https://secure-nikeplus.nike.com/plus/products/basketball [2] http://news.nike.com/news/nike-unveils-revolutionary-nike-experience-for-basketball-and-training-athletes [3] http://www.runscribe.com/ [4] http://www.sensoriafitness.com/ [5] http://www.zepp.com/ [6] http://www.runscribe.com/faq/ -- Stefanie Gerdes Tel: +49 421 218 63906 TZI Universit鋞 Bremen E-Mail: gerdes@tzi.de Bibliothekstr. 1, MZH 5150 28359 Bremen, Germany From nobody Fri Sep 25 03:48: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 E03E51A8A9C for ; Fri, 25 Sep 2015 03:48:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.7 X-Spam-Level: X-Spam-Status: No, score=0.7 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 voLAGK5WQ7gm for ; Fri, 25 Sep 2015 03:48:16 -0700 (PDT) Received: from mail-yk0-x229.google.com (mail-yk0-x229.google.com [IPv6:2607:f8b0:4002:c07::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 1E0BD1A8A99 for ; Fri, 25 Sep 2015 03:48:16 -0700 (PDT) Received: by ykdg206 with SMTP id g206so109368359ykd.1 for ; Fri, 25 Sep 2015 03:48:15 -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=nuqy6Gg3nSfK78nouPPi1cwTgAaYBHl2+jSaX+bFFrI=; b=AQt+HC80R5hbkjiT4+cn1+LspARYUzjXbNdmhSTRRhVUaiB/7s39LSiZP479UzI025 uB/5hOHt43VmrnepMWIM/KSdX443YGf6YdFiOVlBv7m1KQ3UbjQHUNRcFoPFIkCYLmWr 5p4o2dgDmNn0l0doAa3qp31H0JFsjZNVgxntjrvWp0j/Kk4/DwLQ9BR2bRzM7NDfnH21 FwKuQAl7jFcf69bvVVWt+MW3Lni0IywBQuEqyOFwdLi8KqsRIQy/gVnYbV38XxilV0pp JhauAhMdEY8VJYS0bkHlDrFm8mawZNePVhyEPlIb1/+1J/Gr50wWxEPC4MG1I1w7aNXI qyRQ== X-Received: by 10.170.136.67 with SMTP id d64mr4002566ykc.103.1443178095447; Fri, 25 Sep 2015 03:48:15 -0700 (PDT) Received: from [172.20.5.79] ([12.202.56.227]) by smtp.gmail.com with ESMTPSA id n5sm2270993ywd.1.2015.09.25.03.48.13 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 25 Sep 2015 03:48:14 -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: <5605143C.4010804@tzi.de> Date: Fri, 25 Sep 2015 06:48:13 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <993B4117-FAF9-4702-A49E-4A460CF93595@gmail.com> References: <5605143C.4010804@tzi.de> To: Stefanie Gerdes Archived-At: Cc: "ace@ietf.org" Subject: Re: [Ace] AD review of draft-ietf-ace-usecases-05 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, 25 Sep 2015 10:48:19 -0000 Thank you, Steffi. It's helpful to know the use case is realistic. I'll tr= y to respond to the other responses today. I'm at the MARNEW workshop. Thank you, Kathleen=20 Sent from my iPhone > On Sep 25, 2015, at 5:30 AM, Stefanie Gerdes wrote: >=20 > Hi Kathleen, >=20 > Thank you for your review. Some comments regarding the Sports and > Entertainment use case inline. >=20 >> On 09/24/2015 03:04 AM, Kathleen Moriarty wrote: >>=20 >>=20 >> Section 2.6.1 >> Do such shoes exist? The watch example is a common one in use today. >=20 > Nike+ shoes have a wireless chip with a sensor [1]. There are two > different models of sensor enabled shoes, the normal nike+ shoe has a > pocket in the left shoe for a single sensor, the basketball shoe [2] is > equipped with several sensors that can be used to measure, e.g, jump > height and quickness. Other than Nike, there is e.g. runScribe [3] that > also has a sensor in one shoe. There are other approaches where sensors > are integrated in socks [4]. >=20 > This is only one example for sensors in sportswear that are designed to > improve the training. Another example is sensors to improve the swing > or stroke [5]. >=20 >>=20 >> Section 2.6.2 >> Other sections are more explicit on problems, so shouldn't this >> section list out that When Jody connects the watch to upload her data >> to her fitness account, no other data is uploaded? >>=20 >> I'm not sure how realistic it is to have multiple profiles with access >> rights on a sports watch. Is this a feasible example? Are there >> watches that do this today or smart phone apps for running that allow >> for multiple profiles? >=20 > The technology is still very new, so it is difficult to say in which > direction they will be heading. However, runScribe claims that their > product can be shared with family and friends and that it will be > possible to create different user profiles [6]. >=20 > Is there something I can add to the section to address your questions? >=20 > Thanks, > Steffi >=20 >=20 > [1] https://secure-nikeplus.nike.com/plus/products/basketball > [2] > http://news.nike.com/news/nike-unveils-revolutionary-nike-experience-for-b= asketball-and-training-athletes > [3] http://www.runscribe.com/ > [4] http://www.sensoriafitness.com/ > [5] http://www.zepp.com/ > [6] http://www.runscribe.com/faq/ >=20 > --=20 > Stefanie Gerdes Tel: +49 421 218 63906 > TZI Universit=C3=A4t Bremen E-Mail: gerdes@tzi.de > Bibliothekstr. 1, MZH 5150 > 28359 Bremen, Germany From nobody Fri Sep 25 06:05: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 14D7C1A01A5 for ; Fri, 25 Sep 2015 06:05:45 -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 XIv5v7taPxNY for ; Fri, 25 Sep 2015 06:05:43 -0700 (PDT) Received: from mail-wi0-x22e.google.com (mail-wi0-x22e.google.com [IPv6:2a00:1450:400c:c05::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 97E021A01A8 for ; Fri, 25 Sep 2015 06:05:42 -0700 (PDT) Received: by wicfx3 with SMTP id fx3so21024731wic.1 for ; Fri, 25 Sep 2015 06:05:41 -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=eRqwMzow69oEf2GqDnnWYtAg32G929GB6IE4AKBEIbk=; b=wllEYDJuawaVT3qRbek+Kt5Q5nYL2TzYDwXK0XYn+reheXnjeKgDknp1sovjVStghQ 9Vx+o+16Kjf1sRhC597bj2F+OVeFUU2+lQADhPb86VvdVesNXsH5Ks8WmCpdYpyoI/UZ zlHIc64CbSpliV1Sca61mDjcxo4eP8Yum5F9EfWVVaKKByGyIukoaHB85fWqIjkOLZx9 g/iBD9tVhM9huUT3hh6AWS/a/8nil+nHK91OXI1quvPk1b5DsGnjDaRteKMA6oRFE+fM sC62P3BM0GseuP0xk1sjul5e5u58iig8URzJ5Xzg6csvOFANZ2hQpKlmFDz07FnL/MHf +Hgw== MIME-Version: 1.0 X-Received: by 10.180.105.33 with SMTP id gj1mr3213168wib.90.1443186340967; Fri, 25 Sep 2015 06:05:40 -0700 (PDT) Received: by 10.28.214.213 with HTTP; Fri, 25 Sep 2015 06:05:40 -0700 (PDT) In-Reply-To: <5603A964.6040100@sics.se> References: <5603A964.6040100@sics.se> Date: Fri, 25 Sep 2015 09:05:40 -0400 Message-ID: From: Kathleen Moriarty To: Ludwig Seitz Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "ace@ietf.org" Subject: Re: [Ace] AD review of draft-ietf-ace-usecases-05 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, 25 Sep 2015 13:05:45 -0000 Hello Ludwig, Thanks for the quick response, a few comments inline. On Thu, Sep 24, 2015 at 3:42 AM, Ludwig Seitz wrote: > Kathleen, > > thank you for your review. I don't think the changes from 05 to 06 affect > you comments, so I'll just apply them to 06. Great, thanks, > > Comments inline > > Regards, > Ludwig > > On 2015-09-24 03:04, Kathleen Moriarty wrote: >> >> Hello, >> >> Thanks for the quick turn around in an update after this WG last call. >> I did my review a little early in hopes that we could progress this to >> IETF last call soon. The shepherd report will check all comments from >> the WG last call as well, but we can start this in parallel. >> >> ACE Use Case Draft review: >> >> It seems the "Authorization problem summary" lists contain a mix of >> desired capabilities/requirements and problems. Is this the right >> heading for this section? > > > We have tried to steer away from specific requirements in order to reduce > the tendency towards requirements engineering. > It is clear that many of the problems could be easily reinterpreted as > generic desired capabilities and generic requirements. > > The point we are trying to make is this: > > Various entities have requirements and desired capabilities in the differ= ent > use cases, some of these lead to authorization problems involving > constrained devices, which ACE has the ambition to solve. We tried to > capture the latter in the sections called "Authorization problems summary= ". > > I've no problem changing the section headers, as long as the indention of > the document remains clear. I'm grateful for suggestions on how to procee= d > here. Hmm, maybe if you read through them again with this comment in mind, some editing that makes the purpose clear might be good. > > >> Section 2.2.5 >> - new homeowner would want to control the list of all authorized users >> at any given time to the house or connected devices (in the case where >> device management may have separate permissions from house access). >> At time of transfer of the house, they will want to make sure the >> previous owners and any contractors no longer have access. >> > > I guess this is best addressed by adding a sentence or two in section 2.2= .4 > (which might lead to new points in 2.2.5). Great, thanks. > >> Nanny/cleaners/plumbers might have access to the house, but not to >> configure or access the camera monitors. >> > This is kind of similar to 2.2.3 (the visitor scenario), where someone is > given restricted access. I think the cleanest solution would be to extend > section 2.2.3 to avoid duplication. That sounds good, thanks. > >> >> Section 2.3 line 4 >> s/lead/led/ >> between products has lead to initiatives such as Continua Alliance >> > ok > > >> Section 2.5.4 >> >> - Wouldn't the user want access to the usage information, while >> preventing "others" (might include neighbors or attackers - already >> covered in U5.9) from accessing the system? The consumer is not >> included in the list is why I ask. >> > Right, I'll formulate a point to cover this more clearly Thanks. > >> Section 2.6.1 >> Do such shoes exist? The watch example is a common one in use today. >> > No idea, Steffi? Steffi provided an answer, thanks! > >> Section 2.6.2 >> Other sections are more explicit on problems, so shouldn't this >> section list out that When Jody connects the watch to upload her data >> to her fitness account, no other data is uploaded? > > We'll add that explicitly. Great, thanks. > >> >> I'm not sure how realistic it is to have multiple profiles with access >> rights on a sports watch. Is this a feasible example? Are there >> watches that do this today or smart phone apps for running that allow >> for multiple profiles? >> > Not sure, Steffi you wrote that one, could you investigate? Done, thanks. > >> Section 2.7.2 >> Are different levels of access required? Is that an authorization >> challenge that needs to be considered for let's say operators vs. >> auditors of the platform? I see you have that in section 3.2, but >> should it be here too? >> > Yes it should, I'll add such an item Great, thanks! > > >> Section 3.1 >> Usage information in transit should also be protected. In addition to >> privacy, there could be opportunities for fraud. In the case of >> utilities, in some cases with renewable energy, money is given to the >> home owner for generating x amount of energy on top of the usage being >> covered. With this, there are opportunities for fraud on usage as >> well as with payment for generation. I can explain more if needed on >> this example. There is no need to include my example, more that we >> should consider this a security problem too because of the possibility >> of fraud, not just privacy. >> > Just to make sure I get your point correctly: You are missing a paragraph= on > protection of information in transit in the security considerations? Yes, but specific to fraud, which normally involves active attacks. It might be done passively, but to avoid detection, it most likely involves active attacks that could alter data. If the homeowner is not aware of the fraud, then the attacker may be more successful for a longer period of time - skimming money for example if a homeowner generates renewable energy for instance. > > My gut feeling is that it would fit in conjunction with the paragraph on > pervasive monitoring, since there is some overlap in the protection > measures. I'd separate it out to make it clear that these are different attack types with different consequences. Thank you, Kathleen > > > -- > 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 > > > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace > --=20 Best regards, Kathleen From nobody Sun Sep 27 10:22:47 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 378261B2C69 for ; Sun, 27 Sep 2015 10:22:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.41 X-Spam-Level: X-Spam-Status: No, score=-1.41 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, 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 yruV9It9mWCx for ; Sun, 27 Sep 2015 10:22:43 -0700 (PDT) Received: from ausxipps310.us.dell.com (AUSXIPPS310.us.dell.com [143.166.148.211]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F194D1B2C68 for ; Sun, 27 Sep 2015 10:22:42 -0700 (PDT) DomainKey-Signature: s=smtpout; d=dell.com; c=nofws; q=dns; h=X-LoopCount0:X-IronPort-AV:From:To:Subject:Thread-Topic: Thread-Index:Date:Message-ID:References:In-Reply-To: Accept-Language:Content-Language:X-MS-Has-Attach: X-MS-TNEF-Correlator:x-tituslabs-classifications-30: x-titusconfig:x-titus-version: x-tituslabs-classificationhash-30:x-originating-ip: Content-Type:MIME-Version:Return-Path; b=qw0iqEwS92h0E+GX37iwIzK0JhDn0qVcCZtvIptHO78D6j2DoWSQzDDD TCUpd0G5NOzwnHcodGHnr7fzMABfJ3Vg5dRHxNWaDT56vPs82krigzcWx ikcEdTQL3DPJIe+/Y/GmIlRmHrzGKE2X2aIvAfkiyqniqH9oc/Q40Pq3P U=; X-LoopCount0: from 10.170.28.40 X-IronPort-AV: E=Sophos;i="5.17,598,1437454800"; d="scan'208,217";a="233806512" From: To: , Thread-Topic: [Ace] Fwd: New Version Notification for draft-ietf-ace-usecases-06.txt Thread-Index: AQHQ9fC++xmmN9reG0uWpydTSNV8kJ5QpfAg Date: Sun, 27 Sep 2015 17:22:37 +0000 Message-ID: References: <20150923110948.975.82548.idtracker@ietfa.amsl.com> <56028910.7030104@sics.se> In-Reply-To: <56028910.7030104@sics.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-tituslabs-classifications-30: TLPropertyRoot=Dell;Classification=Internal Use;External=No;Sublabels=; x-titusconfig: 1.4AMER x-titus-version: 3.5.29.3 x-tituslabs-classificationhash-30: VgNFIFU9Hx+/nZJb9Kg7ImgoQkH/xTHqCTbyaDXN+/7+eqYVdYRQ7JmSSRvTX3CUS1Do3nEHObCSlNWzgW8EKXCxHjLjpxHu5qKG75wE5BvOwj4NBcTuIhdoDH3u4iCoI5RM3vy6qf8XgtcFt4kNiQIXLfZczhkG1IVopOWcM+s8CokUbbuZIQBBJv7+A1STm2U9qxmKZUPkyYfTsEE5A5DQroNxzRIVxTGfZ4t4NI1Y75s5Ue0rhSu3CgqdT0jMhaew+rD3vcv95UnQB4Omi8smvz9J2EBKUUcN/5txWMU= x-originating-ip: [10.133.237.160] Content-Type: multipart/alternative; boundary="_000_B638E70A97DAF44AA086BB9C8EC3FE3A1862ACblrx10hmban01amer_" MIME-Version: 1.0 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: Sun, 27 Sep 2015 17:22:46 -0000 --_000_B638E70A97DAF44AA086BB9C8EC3FE3A1862ACblrx10hmban01amer_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dell - Internal Use - Confidential Hi Ludwig, Thanks for incorporating my comments, the document diff looks good to me. - Regards, Prashant Jhingran Product Marketing Consultant "Smile at everything & smile through everything" - http://www.artofliving.o= rg/ -----Original Message----- From: Ace [mailto:ace-bounces@ietf.org] On Behalf Of Ludwig Seitz Sent: Wednesday, September 23, 2015 4:42 PM To: ace@ietf.org Subject: [Ace] Fwd: New Version Notification for draft-ietf-ace-usecases-06= .txt Hello ACE, we have submitted a new version of the usecases draft addressing the commen= ts of the second WGLC, especially those made by: Kepeng Li Prashant Jhingran Jim Schaad Regards, Ludwig -------- Forwarded Message -------- Subject: New Version Notification for draft-ietf-ace-usecases-06.txt A new version of I-D, draft-ietf-ace-usecases-06.txt has been successfully = submitted by Ludwig Seitz and posted to the IETF repository. Name: draft-ietf-ace-usecases Revision: 06 Title: ACE use cases Document date: 2015-09-23 Group: ace Pages: 26 URL: https://www.ietf.org/internet-drafts/draft-ietf-ace-usecases-06.txt Status: https://datatracker.ietf.org/doc/draft-ietf-ace-usecases/ Htmlized: https://tools.ietf.org/html/draft-ietf-ace-usecases-06 Diff: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ace-usecases-06 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 comprises a collection of representative use cases for the application of 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 submissio= n until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat --_000_B638E70A97DAF44AA086BB9C8EC3FE3A1862ACblrx10hmban01amer_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dell - Internal Use - Confidential

Hi Ludwig,

 

Thanks for incorporating my comments, the document d= iff looks good to me.

-
Regards,
Prashant Jhingran
Product Marketing Consultant

“Smile at everything & smile through everything= 221; – http://www.artofliving.org/

-----Original Message-----
From: Ace [mailto:ace-bounces@ietf.org] On Behalf Of Ludwig Seitz
Sent: Wednesday, September 23, 2015 4:42 PM
To: ace@ietf.org
Subject: [Ace] Fwd: New Version Notification for draft-ietf-ace-usecases-06= .txt

Hello ACE,

we have submitted a new version of the usecases draft addressing the commen= ts of the second WGLC, especially those made by:

Kepeng Li
Prashant Jhingran
Jim Schaad

Regards,

Ludwig

-------- Forwarded Message --------
Subject: New Version Notification for draft-ietf-ace-usecases-06.txt

A new version of I-D, draft-ietf-ace-usecases-06.txt has been successfully = submitted by Ludwig Seitz and posted to the IETF repository.

Name: draft-ietf-ace-usecases
Revision: 06
Title: ACE use cases
Document date: 2015-09-23
Group: ace
Pages: 26
URL:
https://www.ietf.org/internet-drafts/draft-ietf-ace-usecases-06.txt
Status: https://datatracker.ietf.org/doc/draft-ietf-ace-usecases/
Htmlized: https://tools.ietf.org/html/draft-ietf-ace-usecases-06
Diff: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ace-usecases-06

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 comprises a collection of representative use cases for
the application of 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 submissio= n until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat


--_000_B638E70A97DAF44AA086BB9C8EC3FE3A1862ACblrx10hmban01amer_-- From nobody Sun Sep 27 10:59: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 87A5F1A002C for ; Sun, 27 Sep 2015 10:59:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.01 X-Spam-Level: X-Spam-Status: No, score=-7.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, 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 95N8KtXcFOVG for ; Sun, 27 Sep 2015 10:59:25 -0700 (PDT) Received: from ausxipps301.us.dell.com (ausxipps301.us.dell.com [143.166.148.223]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2523A1A002A for ; Sun, 27 Sep 2015 10:59:24 -0700 (PDT) DomainKey-Signature: s=smtpout; d=dell.com; c=nofws; q=dns; h=X-LoopCount0:X-IronPort-AV:From:To:Subject:Thread-Topic: Thread-Index:Date:Message-ID:References:In-Reply-To: Accept-Language:Content-Language:X-MS-Has-Attach: X-MS-TNEF-Correlator:x-tituslabs-classifications-30: x-titusconfig:x-titus-version: x-tituslabs-classificationhash-30:x-originating-ip: Content-Type:MIME-Version:Return-Path; b=ZnTddT+uD/dTYkt80kBLqX9f/k1rBRqp018gPDMUgz49sgc15Cn+BdXx VoURlupxANN68In9WjWkLJHi39hPgjV/gbi0t1/sIXSDjTUqAM36CCEs6 vvKcf09aYC0agKQbRAke/LSCH/UaQYl4NLHVGv2Kk57OaUNVHH96qJbHY w=; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dell.com; i=@dell.com; q=dns/txt; s=smtpout; t=1443376765; x=1474912765; h=from:to:subject:date:message-id:references:in-reply-to: mime-version:content-transfer-encoding; bh=NUdMQiV2wPaMEY9ghgaippO1Hx7cuYzV+nOqkuJ0jc0=; b=glUbbkrOqLbekALtgZP6mhfZ26VJkixKT+vw5mKE7CoQrztCkYdOPza0 3wsmCltjPu/4Z0vff3oXQXk9LzghFTWDdO9CwN4hvn94ud2H4PxasFUj7 P2Cr/LPbg0pyuyVTykbEFOHTUL/j12tkFiwuWqul/tHjYoW6WtFMMM3qT A=; X-LoopCount0: from 10.170.28.40 X-IronPort-AV: E=Sophos;i="5.17,598,1437454800"; d="scan'208,217";a="710612270" From: To: , Thread-Topic: [Ace] Fwd: New Version Notification for draft-ietf-ace-usecases-06.txt Thread-Index: AQHQ+U0DB2c1lkY7bE64e0FQEQzTag== Date: Sun, 27 Sep 2015 17:50:36 +0000 Message-ID: References: <20150923110948.975.82548.idtracker@ietfa.amsl.com> <56028910.7030104@sics.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-tituslabs-classifications-30: TLPropertyRoot=Dell;Classification=Internal Use;External=No;Sublabels=; x-titusconfig: 1.4AMER x-titus-version: 3.5.29.3 x-tituslabs-classificationhash-30: VgNFIFU9Hx+/nZJb9Kg7ImgoQkH/xTHqCTbyaDXN+/7+eqYVdYRQ7JmSSRvTX3CURsv8QFSj9o5HmHc5CnzrTJOIkW7Hcj96h3ZmnCYVtyFljpHTvya+uOWQHtXuICS5yuiIyqAx8LaoUMKH0lwSZrciyZEtMiF2lwetRwLNnqa6Lm/j72YgfOdzbfmbbVNMmzPLUxbuJ8B+H/3aPHCpI1pCsC2cw1yqoPv1AOj8TOD92DQv0rT7Wsm0fd8/gKIjYkfs/PUA+qkl5lH3yKgpVlbHf762ePDWbIE/xvLQUbk= x-originating-ip: [10.133.237.160] Content-Type: multipart/alternative; boundary="_000_B638E70A97DAF44AA086BB9C8EC3FE3A1862D0blrx10hmban01amer_" MIME-Version: 1.0 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: Sun, 27 Sep 2015 17:59:29 -0000 --_000_B638E70A97DAF44AA086BB9C8EC3FE3A1862D0blrx10hmban01amer_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dell - Internal Use - Confidential Hi Ludwig, Could not capture the below mentioned point earlier, besides this the docum= ent 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 easies= t attack can be caused by forcing the device to send continuous or abnormal= ly higher number of monitoring, troubleshooting or heartbeat messages to th= e GW or somewhere, thus forcing more number of transactions than expected, = this may eventually lead to faster exhaustion of device resources like batt= ery etc. Hence we should also add "Number of message exchanges required during monit= oring or troubleshooting" besides the existing limitations, like "Number of= message exchanges required by security measures". - Regards, Prashant Jhingran Product Marketing Consultant "Smile at everything & smile through everything" - http://www.artofliving.= org/ From: Ace [mailto:ace-bounces@ietf.org] On Behalf Of Jhingran, Prashant Sent: Sunday, September 27, 2015 10:53 PM To: ludwig@sics.se; ace@ietf.org Subject: Re: [Ace] Fwd: New Version Notification for draft-ietf-ace-usecase= s-06.txt Dell - Internal Use - Confidential Hi Ludwig, Thanks for incorporating my comments, the document diff looks good to me. - Regards, Prashant Jhingran Product Marketing Consultant "Smile at everything & smile through everything" - http://www.artofliving.o= rg/ -----Original Message----- From: Ace [mailto:ace-bounces@ietf.org] On Behalf Of Ludwig Seitz Sent: Wednesday, September 23, 2015 4:42 PM To: ace@ietf.org Subject: [Ace] Fwd: New Version Notification for draft-ietf-ace-usecases-06= .txt Hello ACE, we have submitted a new version of the usecases draft addressing the commen= ts of the second WGLC, especially those made by: Kepeng Li Prashant Jhingran Jim Schaad Regards, Ludwig -------- Forwarded Message -------- Subject: New Version Notification for draft-ietf-ace-usecases-06.txt A new version of I-D, draft-ietf-ace-usecases-06.txt has been successfully = submitted by Ludwig Seitz and posted to the IETF repository. Name: draft-ietf-ace-usecases Revision: 06 Title: ACE use cases Document date: 2015-09-23 Group: ace Pages: 26 URL: https://www.ietf.org/internet-drafts/draft-ietf-ace-usecases-06.txt Status: https://datatracker.ietf.org/doc/draft-ietf-ace-usecases/ Htmlized: https://tools.ietf.org/html/draft-ietf-ace-usecases-06 Diff: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ace-usecases-06 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 comprises a collection of representative use cases for the application of 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 submissio= n until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat --_000_B638E70A97DAF44AA086BB9C8EC3FE3A1862D0blrx10hmban01amer_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dell - Internal Use - Confidential 

Hi Ludwig, 
 
Could not capture the below mentioned=
 point earlier, besides this the document looks very comprehensive to me. <=
o:p>

 

Section 3.1 talks about the DoS=
 attacks. 
 
An attacker can potentially cause a D=
oS attack by various means, the easiest attack can be caused by forcing the=
 device to send continuous or abnormally higher number of monitoring, troub=
leshooting or heartbeat messages to the GW or somewhere, thus forcing more =
number of transactions than expected, this may eventually lead to faster ex=
haustion of device resources like battery etc.  

 


Hence we should also add “Number of message exchanges required during m=
onitoring or troubleshooting” besides the existing limitations, =
like “Number of message exchanges =
required by security measures”.


 




-


Regards,


Prashant Jhingran


Product Marketing Consultant=



 


“Smile at everything &=
amp; smile through everything”  –
http://www.artofliving.org/



 






From: Ace=
 [mailto:ace-bounces@ietf.org]
On Behalf Of Jhingran, Prashant

Sent: Sunday, September 27, 2015 10:53 PM

To: ludwig@sics.se; ace@ietf.org

Subject: Re: [Ace] Fwd: New Version Notification for draft-ietf-ace-=
usecases-06.txt






 


Dell - Internal Use - Confidential



Hi Ludwig, 


 


Thanks for incorporating my comments, the document d=
iff looks good to me.



-

Regards,

Prashant Jhingran

Product Marketing Consultant



“Smile at everything & smile through everything=
221; – 
http://www.artofliving.org/



-----Original Message-----

From: Ace [mailto:ace-bounces@ietf.=
org] On Behalf Of Ludwig Seitz

Sent: Wednesday, September 23, 2015 4:42 PM

To: ace@ietf.org

Subject: [Ace] Fwd: New Version Notification for draft-ietf-ace-usecases-06=
.txt



Hello ACE,



we have submitted a new version of the usecases draft addressing the commen=
ts of the second WGLC, especially those made by:



Kepeng Li

Prashant Jhingran

Jim Schaad



Regards,



Ludwig



-------- Forwarded Message --------

Subject: New Version Notification for draft-ietf-ace-usecases-06.txt



A new version of I-D, draft-ietf-ace-usecases-06.txt has been successfully =
submitted by Ludwig Seitz and posted to the IETF repository.



Name: draft-ietf-ace-usecases

Revision: 06

Title: ACE use cases

Document date: 2015-09-23

Group: ace

Pages: 26

URL: 

https://www.ietf.org/internet-drafts/draft-ietf-ace-usecases-06.txt

Status: https://datatracker.ietf.org/doc/draft-ietf-ace-usecases/

Htmlized: https://tools.ietf.org/html/draft-ietf-ace-usecases-06

Diff: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ace-usecases-06


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 comprises a collection of representative use cases for

the application of 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 submissio=
n until the htmlized version and diff are available at tools.ietf.org.



The IETF Secretariat
--_000_B638E70A97DAF44AA086BB9C8EC3FE3A1862D0blrx10hmban01amer_-- From nobody Mon Sep 28 05:14: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 B617A1A8AB4 for ; Mon, 28 Sep 2015 05:14:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.398 X-Spam-Level: X-Spam-Status: No, score=-1.398 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, J_CHICKENPOX_66=0.6, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, 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 rqdRNFGR2WeD for ; Mon, 28 Sep 2015 05:14:06 -0700 (PDT) Received: from out4133-82.mail.aliyun.com (out4133-82.mail.aliyun.com [42.120.133.82]) by ietfa.amsl.com (Postfix) with ESMTP id 23B0A1A8AAF for ; Mon, 28 Sep 2015 05:14:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alibaba-inc.com; s=default; t=1443442443; h=Date:Subject:From:To:Message-ID:Mime-version:Content-type; bh=yASfEJnGGjoaNtJlMYL6kJjWvaeXfdW8t/0X3HBlX6M=; b=l/iX7qfJAkG4dE6TG3kupCNIL1XB1qtO9Pp6I2k10/qoL9VZr0xVCwA10rJDtDtbn/xj4YFIqBU7bD825avQ1SMW/m624kvZKBHdVMVFxJYc5LStrYzGqy/2ittJu6VkyGnYEGSohOvFeq5KT0J1BLLPmhlqBhhn90igATV5j8c= X-Alimail-AntiSpam: AC=PASS; BC=-1|-1; BR=01201311R191e4; FP=0|-1|-1|-1|0|-1|-1|-1; HT=e02c03311; MF=kepeng.lkp@alibaba-inc.com; NM=1; PH=DS; RN=2; SR=0; Received: from 10.1.153.174(mailfrom:kepeng.lkp@alibaba-inc.com ip:42.120.74.184) by smtp.aliyun-inc.com(127.0.0.1); Mon, 28 Sep 2015 20:14:00 +0800 User-Agent: Microsoft-MacOutlook/14.4.8.150116 Date: Mon, 28 Sep 2015 20:13:53 +0800 From: "Kepeng Li" To: "ace@ietf.org" Message-ID: Thread-Topic: WebEx meeting: ACE Virtual Interim Meeting Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3526316040_4506388" Archived-At: Cc: Hannes Tschofenig Subject: [Ace] FW: WebEx meeting: ACE Virtual Interim Meeting 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, 28 Sep 2015 12:14:07 -0000 > 此邮件使用 MIME 格式。由于邮件阅读程序不能识别 此格式，因此，可能无法识别该邮件的分部或部分内容。 --B_3526316040_4506388 Content-type: text/plain; charset="GB2312" Content-transfer-encoding: 7bit Hello all, The Authentication and Authorization for Constrained Environments (ACE) Working Group will hold a virtual interim meeting on Wednesday, 30 September 2015, between 9am EDT and 11am EDT. The intial agenda is: 1. Re-charter; 2. Use cases; 3. Actors; 4. AOB. Below is the meeting info: ACE Virtual Interim Meeting Wednesday, September 30, 2015 9:00 am | Eastern Daylight Time (New York, GMT-04:00) | 2 hrs Join WebEx meeting Meeting number: 642 579 330 Meeting password: iot-rocks Join by phone 1-877-668-4493 Call-in toll free number (US/Canada) 1-650-479-3208 Call-in toll number (US/Canada) Access code: 642 579 330 Toll-free calling restrictions Add this meeting to your calendar. Kind Regards Kepeng&Hannes --B_3526316040_4506388 Content-type: text/html; charset="GB2312" Content-transfer-encoding: quoted-printable
Hello all,

<= div>The Authentication and Authorization fo= r Constrained Environments (ACE)
Working Group will hold a virtual interim meeting on Wednesday, 30
September 2015, between 9am EDT and 11am EDT.

The intial agenda is:
  1. Re-charter;
    2. <= li>Use cases;
  2. Actors;
  3. AOB. 
Below is the = meeting info: 
 
ACE Virtual Interim Meeting
Wednesday, September 30, 2015
9:00 am  |  Eastern Daylight Time (New York= , GMT-04:00)  |  2 hrs
 
Join WebEx meeting
Meeting number: 642 579 330
Meeting password: iot-rocks
 <= /td>
Joi= n by phone
1-877-668-4493&nbs= p;Call-in toll free number (US/Canada)
<= b>1-650-479-3208 Call-in toll number (US/Canada)
Access code: 642 579 330
Toll-free calling restri= ctions
&nb= sp;
Add this mee= ting to your calendar.
Kind Regards  
 















=





<= div>


=
Kepeng&Hannes
--B_3526316040_4506388-- From nobody Mon Sep 28 06:03:48 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 8567A1A8BBF for ; Mon, 28 Sep 2015 06:03:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.35 X-Spam-Level: X-Spam-Status: No, score=0.35 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HELO_EQ_DE=0.35, MSGID_FROM_MTA_HEADER=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 IYrZRNukpDtj for ; Mon, 28 Sep 2015 06:03:46 -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 A28CC1A8BB2 for ; Mon, 28 Sep 2015 06:03:45 -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 t8SD3b9B011395; Mon, 28 Sep 2015 15:03:37 +0200 (CEST) Message-Id: <201509281303.t8SD3b9B011395@mailhost.informatik.uni-bremen.de> Received: from [10.96.202.70] (ip-109-47-1-68.web.vodafone.de [109.47.1.68]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3nPkYh69cSz4p02; Mon, 28 Sep 2015 15:03:36 +0200 (CEST) Date: Mon, 28 Sep 2015 14:57:34 +0200 From: Stefanie Gerdes To: Kathleen Moriarty MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 Archived-At: Cc: Ludwig Seitz , "ace@ietf.org" Subject: Re: [Ace] AD review of draft-ietf-ace-usecases-05 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, 28 Sep 2015 13:03:47 -0000 SGkgS2F0aGxlZW4sCgpNYXliZSB5b3UgY2FuIGhlbHAgbWUgd2l0aCB5b3VyIGNvbW1lbnQgY29u Y2VybmluZyB0aGUgcHJvYmxlbXMgc3VtbWFyeSBzZWN0aW9ucyAoc2VlIGJlbG93KS4KCkFtIDI1 LjA5LjIwMTUgMTU6MDUgc2NocmllYiBLYXRobGVlbiBNb3JpYXJ0eSA8a2F0aGxlZW4ubW9yaWFy dHkuaWV0ZkBnbWFpbC5jb20+OgoKPiBPbiBUaHUsIFNlcCAyNCwgMjAxNSBhdCAzOjQyIEFNLCBM dWR3aWcgU2VpdHogPGx1ZHdpZ0BzaWNzLnNlPiB3cm90ZTogCgo+ID4gCj4gPiBPbiAyMDE1LTA5 LTI0IDAzOjA0LCBLYXRobGVlbiBNb3JpYXJ0eSB3cm90ZToKCj4gPj4gQUNFIFVzZSBDYXNlIERy YWZ0IHJldmlldzogCj4gPj4gCj4gPj4gSXQgc2VlbXMgdGhlICJBdXRob3JpemF0aW9uIHByb2Js ZW0gc3VtbWFyeSIgbGlzdHMgY29udGFpbiBhIG1peCBvZiAKPiA+PiBkZXNpcmVkIGNhcGFiaWxp dGllcy9yZXF1aXJlbWVudHMgYW5kIHByb2JsZW1zLsKgIElzIHRoaXMgdGhlIHJpZ2h0IAo+ID4+ IGhlYWRpbmcgZm9yIHRoaXMgc2VjdGlvbj8gCj4gPiAKPiA+IAo+ID4gV2UgaGF2ZSB0cmllZCB0 byBzdGVlciBhd2F5IGZyb20gc3BlY2lmaWMgcmVxdWlyZW1lbnRzIGluIG9yZGVyIHRvIHJlZHVj ZSAKPiA+IHRoZSB0ZW5kZW5jeSB0b3dhcmRzIHJlcXVpcmVtZW50cyBlbmdpbmVlcmluZy4gCj4g PiBJdCBpcyBjbGVhciB0aGF0IG1hbnkgb2YgdGhlIHByb2JsZW1zIGNvdWxkIGJlIGVhc2lseSBy ZWludGVycHJldGVkIGFzIAo+ID4gZ2VuZXJpYyBkZXNpcmVkIGNhcGFiaWxpdGllcyBhbmQgZ2Vu ZXJpYyByZXF1aXJlbWVudHMuIAo+ID4gCj4gPiBUaGUgcG9pbnQgd2UgYXJlIHRyeWluZyB0byBt YWtlIGlzIHRoaXM6IAo+ID4gCj4gPiBWYXJpb3VzIGVudGl0aWVzIGhhdmUgcmVxdWlyZW1lbnRz IGFuZCBkZXNpcmVkIGNhcGFiaWxpdGllcyBpbiB0aGUgZGlmZmVyZW50IAo+ID4gdXNlIGNhc2Vz LCBzb21lIG9mIHRoZXNlIGxlYWQgdG8gYXV0aG9yaXphdGlvbiBwcm9ibGVtcyBpbnZvbHZpbmcg Cj4gPiBjb25zdHJhaW5lZCBkZXZpY2VzLCB3aGljaCBBQ0UgaGFzIHRoZSBhbWJpdGlvbiB0byBz b2x2ZS4gV2UgdHJpZWQgdG8gCj4gPiBjYXB0dXJlIHRoZSBsYXR0ZXIgaW4gdGhlIHNlY3Rpb25z IGNhbGxlZCAiQXV0aG9yaXphdGlvbiBwcm9ibGVtcyBzdW1tYXJ5Ii4gCj4gPiAKPiA+IEkndmUg bm8gcHJvYmxlbSBjaGFuZ2luZyB0aGUgc2VjdGlvbiBoZWFkZXJzLCBhcyBsb25nIGFzIHRoZSBp bmRlbnRpb24gb2YgCj4gPiB0aGUgZG9jdW1lbnQgcmVtYWlucyBjbGVhci4gSSdtIGdyYXRlZnVs IGZvciBzdWdnZXN0aW9ucyBvbiBob3cgdG8gcHJvY2VlZCAKPiA+IGhlcmUuIAo+Cj4gSG1tLCBt YXliZSBpZiB5b3UgcmVhZCB0aHJvdWdoIHRoZW0gYWdhaW4gd2l0aCB0aGlzIGNvbW1lbnQgaW4g bWluZCwgCj4gc29tZSBlZGl0aW5nIHRoYXQgbWFrZXMgdGhlIHB1cnBvc2UgY2xlYXIgbWlnaHQg YmUgZ29vZC4gCj4KClRoZSBwdXJwb3NlIG9mIHRoZSBwcm9ibGVtcyBzdW1tYXJ5IHNlY3Rpb25z IGlzIHRvIGxpc3Qgd2hhdCBwcmljaXBhbHMgbmVlZCBmcm9tIGFuIGF1dGhvcml6YXRpb24gc29s dXRpb24gYW5kIHdoaWNoIHNwZWNpYWwgY2hhcmFjdGVyaXN0aWNzIG9mIHRoZSBhcHBsaWNhdGlv biBzY2VuYXJpbyBuZWVkIHRvIGJlIGNvbnNpZGVyZWQuIEkgcmVhZCB0aHJvdWdoIHRoZSBwcm9i bGVtIHN1bW1hcnkgc2VjdGlvbnMgYWdhaW4gYW5kIGZpbmQgdGhlIGl0ZW1zIGxpc3RlZCB0aGVy ZWluIHF1aXRlIHVzZWZ1bC4gSXMgdGhlcmUgc29tZXRoaW5nIHRoYXQgeW91IGVzcGVjaWFsbHkg ZGlzbGlrZSBhYm91dCB0aGUgc2VjdGlvbnMgb3Igd291bGQgaXQgaGVscCBpZiB3ZSB3b3VsZCBy ZW5hbWUgdGhlbSwgbWF5YmUgdG8gc29tZXRoaW5nIGxpa2UgImF1dGhvcml6YXRpb24gY2hhcmFj dGVyaXN0aWNzIHN1bW1hcnkiPwoKVGhhbmtzLApTdGVmZmk= From nobody Mon Sep 28 06:08: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 40F011A9007 for ; Mon, 28 Sep 2015 06:08: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 FEksDBK0_wD0 for ; Mon, 28 Sep 2015 06:08:52 -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 E83221A8F3B for ; Mon, 28 Sep 2015 06:08:51 -0700 (PDT) Received: by wicgb1 with SMTP id gb1so103335901wic.1 for ; Mon, 28 Sep 2015 06:08:50 -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=n7LeQ1x5MivYjMOJh8BIHcCfQ6spJfJXXIOzGIPz63U=; b=TWPIM7zKWqhlVNsYyDMLuOJ9YkWhHLLGhmKj4o2M1MBdkWWHmcPd9SyKCfbg+bMcCB Ylf0bIEToYEj7szdRQa+rUemjOkZ4xe3WzdROoetQlZqWH4eEWTOsefRg3ukeHNA+/xT GkbBk662ZGQClQHTj2MWE7dwsizGA1mGwGI5U6hvXQPzuIGgP9vkMwfGq0si2B3yhlRQ bXCc6nLPevrBwTMrKi93SMRZpaUR/cYjRAQTPdiBMuEqsie+6mzW9NQpgKsqJOAcKde/ UTqizYVsLuDtBAoIllWf3LZZ9zmgk/GDvV6acw+OmRWgpnRt40gKQLPSh4WiBUjNV1nU T+wg== MIME-Version: 1.0 X-Received: by 10.180.75.38 with SMTP id z6mr17537894wiv.36.1443445730507; Mon, 28 Sep 2015 06:08:50 -0700 (PDT) Received: by 10.28.214.213 with HTTP; Mon, 28 Sep 2015 06:08:50 -0700 (PDT) In-Reply-To: <201509281303.t8SD3b9B011395@mailhost.informatik.uni-bremen.de> References: <201509281303.t8SD3b9B011395@mailhost.informatik.uni-bremen.de> Date: Mon, 28 Sep 2015 09:08:50 -0400 Message-ID: From: Kathleen Moriarty To: Stefanie Gerdes Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: Ludwig Seitz , "ace@ietf.org" Subject: Re: [Ace] AD review of draft-ietf-ace-usecases-05 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, 28 Sep 2015 13:08:55 -0000 Hi Steffi, On Mon, Sep 28, 2015 at 8:57 AM, Stefanie Gerdes wrote: > Hi Kathleen, > > Maybe you can help me with your comment concerning the problems summary s= ections (see below). > > Am 25.09.2015 15:05 schrieb Kathleen Moriarty : > >> On Thu, Sep 24, 2015 at 3:42 AM, Ludwig Seitz wrote: > >> > >> > On 2015-09-24 03:04, Kathleen Moriarty wrote: > >> >> ACE Use Case Draft review: >> >> >> >> It seems the "Authorization problem summary" lists contain a mix of >> >> desired capabilities/requirements and problems. Is this the right >> >> heading for this section? >> > >> > >> > We have tried to steer away from specific requirements in order to red= uce >> > the tendency towards requirements engineering. >> > It is clear that many of the problems could be easily reinterpreted as >> > generic desired capabilities and generic requirements. >> > >> > The point we are trying to make is this: >> > >> > Various entities have requirements and desired capabilities in the dif= ferent >> > use cases, some of these lead to authorization problems involving >> > constrained devices, which ACE has the ambition to solve. We tried to >> > capture the latter in the sections called "Authorization problems summ= ary". >> > >> > I've no problem changing the section headers, as long as the indention= of >> > the document remains clear. I'm grateful for suggestions on how to pro= ceed >> > here. >> >> Hmm, maybe if you read through them again with this comment in mind, >> some editing that makes the purpose clear might be good. >> > > The purpose of the problems summary sections is to list what pricipals ne= ed from an authorization solution and which special characteristics of the = application scenario need to be considered. I read through the problem summ= ary sections again and find the items listed therein quite useful. Is there= something that you especially dislike about the sections or would it help = if we would rename them, maybe to something like "authorization characteris= tics summary"? I do agree that the items are all useful, WHat I was referring to was how they read, not necessarily as problems, but in some cases a list of requirements. If the problem was pointed out, then the section heading would make more sense. Thanks! > > Thanks, > Steffi --=20 Best regards, Kathleen From nobody Mon Sep 28 08:37: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 5727A1ACD11 for ; Mon, 28 Sep 2015 08:37: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 lhE7dnqf-Rte for ; Mon, 28 Sep 2015 08:37:05 -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 4D4FB1AC44B for ; Mon, 28 Sep 2015 08:37:05 -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 t8SFb1j7001485; Mon, 28 Sep 2015 17:37:01 +0200 (CEST) Received: from [192.168.1.109] (p57A63B54.dip0.t-ipconnect.de [87.166.59.84]) (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 3nPnyj0y5xz4p8B; Mon, 28 Sep 2015 17:37:01 +0200 (CEST) To: Kathleen Moriarty References: <201509281303.t8SD3b9B011395@mailhost.informatik.uni-bremen.de> From: Stefanie Gerdes Message-ID: <56095E98.7050505@tzi.de> Date: Mon, 28 Sep 2015 17:36:56 +0200 User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: Cc: Ludwig Seitz , "ace@ietf.org" Subject: Re: [Ace] AD review of draft-ietf-ace-usecases-05 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, 28 Sep 2015 15:37:11 -0000 Hi Kathleen, Thank you for the clarification. I think I understand now what you are aiming at. Thanks, Steffi On 09/28/2015 03:08 PM, Kathleen Moriarty wrote: > Hi Steffi, > > On Mon, Sep 28, 2015 at 8:57 AM, Stefanie Gerdes wrote: >> Hi Kathleen, >> >> Maybe you can help me with your comment concerning the problems summary sections (see below). >> >> Am 25.09.2015 15:05 schrieb Kathleen Moriarty : >> >>> On Thu, Sep 24, 2015 at 3:42 AM, Ludwig Seitz wrote: >> >>>> >>>> On 2015-09-24 03:04, Kathleen Moriarty wrote: >> >>>>> ACE Use Case Draft review: >>>>> >>>>> It seems the "Authorization problem summary" lists contain a mix of >>>>> desired capabilities/requirements and problems. Is this the right >>>>> heading for this section? >>>> >>>> >>>> We have tried to steer away from specific requirements in order to reduce >>>> the tendency towards requirements engineering. >>>> It is clear that many of the problems could be easily reinterpreted as >>>> generic desired capabilities and generic requirements. >>>> >>>> The point we are trying to make is this: >>>> >>>> Various entities have requirements and desired capabilities in the different >>>> use cases, some of these lead to authorization problems involving >>>> constrained devices, which ACE has the ambition to solve. We tried to >>>> capture the latter in the sections called "Authorization problems summary". >>>> >>>> I've no problem changing the section headers, as long as the indention of >>>> the document remains clear. I'm grateful for suggestions on how to proceed >>>> here. >>> >>> Hmm, maybe if you read through them again with this comment in mind, >>> some editing that makes the purpose clear might be good. >>> >> >> The purpose of the problems summary sections is to list what pricipals need from an authorization solution and which special characteristics of the application scenario need to be considered. I read through the problem summary sections again and find the items listed therein quite useful. Is there something that you especially dislike about the sections or would it help if we would rename them, maybe to something like "authorization characteristics summary"? > > I do agree that the items are all useful, WHat I was referring to was > how they read, not necessarily as problems, but in some cases a list > of requirements. If the problem was pointed out, then the section > heading would make more sense. > > Thanks! > >> >> Thanks, >> Steffi > > > -- Stefanie Gerdes Tel: +49 421 218 63906 TZI Universit鋞 Bremen E-Mail: gerdes@tzi.de Bibliothekstr. 1, MZH 5150 28359 Bremen, Germany From nobody Tue Sep 29 01:45: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 0B4901A6EF1 for ; Tue, 29 Sep 2015 01:45:50 -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 Kew9EjbZ-TOL for ; Tue, 29 Sep 2015 01:45:48 -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 E6F7C1A6F04 for ; Tue, 29 Sep 2015 01:45:47 -0700 (PDT) Received: from [192.168.131.140] ([80.92.119.87]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0M3ARX-1aYWrO2obP-00szRg for ; Tue, 29 Sep 2015 10:45:45 +0200 To: "Ace@ietf.org" From: Hannes Tschofenig Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9 X-Enigmail-Draft-Status: N1110 Message-ID: <560A4F84.4030806@gmx.net> Date: Tue, 29 Sep 2015 10:44:52 +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="ubkvAiGmDDCkQD65Ms0ITVaBnWrXpBFus" X-Provags-ID: V03:K0:HaklmvMlkzVsZ39H7JTbiL1BUWxF7w06+VkbjEvIMqJuUJgjFO2 4Q2wZYpXZOIxx0WqQXHy4Zqy7bmrCQZv0aRNiR47aDYDA46nE55E1KO+yx1rHcwSAnkn+V0 dIhNwpC/4ywXFPrVBjbnz69iyRY5oiDN0FdghuXF9WOc6VQnxH91FWMFtwQ/02o8VDJrZgI 3OQWSH/+ttED71mKAhMhw== X-UI-Out-Filterresults: notjunk:1;V01:K0:miF9w3NKCAY=:zh9/JTJUaOT0skrIIhCDvw hRdCTzzhjT4odJWpT+lYEm6dAJfA+JMexSG6feCbqI+KGTITCcvJHlXR+4DNMu/tA6s+U4xCb 5O/Gu4PqJS+rOKlFmcGPdtRhdHNum36pbhDUwzbUZjYRA0EoXk6bNeJt7IEpv6W+zJ0mg7F/k 6MTuavo6qWUlMhjupxtimOMSvf5XzDNOJ6xq220fYTdQY3iCOmADb4oZpTsN6wsA7FBbdh304 M1MorpvjIsX9nUT1uHINV4yurZzrJUy8NfoOamgq5d7brqVwUjJjxt86E6O4tj977pfJZ0Q03 OQpzDQnbljdD0rcGC7UUWNLR2AyKKFZlIg2LQEQZLzkiWmnEB3Otssc5635r2qruhwcy29he7 4vum/Ki9AZmUY94tX+FdO7yc++jp3qNqRpQQ/sefE3c0jmAIRyLDNJoixRycVMi+MXaiJHvLc aE+HkNkytjJUwjqHjcnqZg++3A1ifrd3T7swK5OXD2JU/8WhsFIq9t4NLrDN7YigIGxFOZyM+ dOen/CuE7WY/gruIUXD3LqSrGdK1zTnG18PEp1lnE4+DFFFqw8K5CfCD3yzddPedThh2Zw2X0 z87YsEpeGmK1wxL+X3FizhtyBXMRtNm4FrfRgELKhROc+l0oOsO3QEUCMFaqaqj/loRAsKnE4 2eCtZ/uG1CEorfWmH5uVrmvNiLJ4nrUP2/nbHV3VXTokSvXbqqI3qnCG9U+L7fg4zXVDAKH7+ 4jFiBB70oew2d1Le Archived-At: Subject: [Ace] COSE and multicast: Discussion Summary? 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, 29 Sep 2015 08:45:50 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --ubkvAiGmDDCkQD65Ms0ITVaBnWrXpBFus Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi all, I re-read the email messages on the discussion thread Jim posted (see http://www.ietf.org/mail-archive/web/ace/current/msg01285.html) in an attempt to find out why version -05 of the COSE draft does not have the 'alg' parameter optional. I see agreement that in certain use cases a context identifier is needed (such as a key id, or whatever you want to call it). But I also notice a lot of unrelated discussions that make it difficult to find out what was the outcome of the debate. While a security context identifier is not new concept I would like to explain it again. In many security protocols a more sophisticated protocol exchange is executed first and then keys are derived and form a security association. The security association consists of keys (typically different keys in different directions), agreed algorithms, sequence number counters, and a label. Different protocols utilize the label differently but that label is used to reference the security association. Different protocols also use a different term for the established context information. (Engineers like to invent new terms.) When this initial phase is completed data traffic can be encrypted/integrity/replay protected. Why is this two-step approach used? You do the heavy lifting once and then you can go full speed with symmetric crypto. If you know get the impression that you have heard about that concept before then you are absolutely right. Example: IKEv2 and IPsec ESP. (This time I picked a different example so that nobody gets hung up on the DTLS story.) The heavy lifting in this case is the IKEv2 exchange that establishes (in this case) the IPsec SAs. IPsec ESP then only uses the previously established security context and uses symmetric cryptography. When you look at the IPsec header then you will see that the message doesn't carry an algorithm field in there. How come is that? Well. It has been established already with the earlier IKEv2 exchange. Both parties know the algorithm and all the other information already. All that is needed at this point is a way to select the correct security association when receiving a message in order to decrypt the payload. There needs to be some information in the packet itself to do that (in the unencrypted part, of course). Let us call it a label. There is no need to carry redundant information around with every IPsec packet. What label is used in IPsec? A quick look at https://tools.ietf.org/html/rfc4303 reveals that the authors have called it Security Parameter Index (SPI). In case of unicast IPsec the SPI itself is not unique and has to be combined with other information (namely protocol - ESP or AH, and the destination address). Not a big deal. There are also specs for the use of multicast IPsec. Is it so far fetched to re-use the same concepts that others have introduced in the IETF already before? Ciao Hannes --ubkvAiGmDDCkQD65Ms0ITVaBnWrXpBFus 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 iQEcBAEBCgAGBQJWCk+FAAoJEGhJURNOOiAtERIH/2DisLldN7rqDnOOWvOZn8zF u6dfaYC5dI/FLjpOYWELx5tAsIKZ4umNo4AqglyTT77Ajeo5h0V4sxVl+D1Wmpjn ueX1ZDOAuUXAodUJhuDSTgGadSfTQiX6jsPXxxKLZ66aQd8aB6Ul6dPRc2uutBeR vO8/VF3/x4jCJDW5jyI10VxU3fG+CY/RIdikKN1tPuWeymDVzRVQoTg1uzEJWsuq dktMXkTtCN2DjLZSaUa9x10R0PGRgni+GgNYNCxTGonBit7HlTWlE2drNSLiuqCZ ekiSQq8Et1bc9M0TbFEzQgNF01pBkPuL9KV6OTSzu1lhcSNmma2LRj7rO+rj34M= =WXau -----END PGP SIGNATURE----- --ubkvAiGmDDCkQD65Ms0ITVaBnWrXpBFus-- From nobody Tue Sep 29 05:58: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 F27B61B3BDF for ; Tue, 29 Sep 2015 05:58:22 -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 MPXsdypZZTVS for ; Tue, 29 Sep 2015 05:58:20 -0700 (PDT) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0743.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::743]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 62BC51B3BD8 for ; Tue, 29 Sep 2015 05:58:18 -0700 (PDT) Received: from VI1PR06CA0045.eurprd06.prod.outlook.com (10.163.160.13) by AM4PR06MB1474.eurprd06.prod.outlook.com (10.164.80.28) with Microsoft SMTP Server (TLS) id 15.1.280.20; Tue, 29 Sep 2015 12:57:59 +0000 Received: from AM1FFO11FD047.protection.gbl (2a01:111:f400:7e00::104) by VI1PR06CA0045.outlook.office365.com (2a01:111:e400:533c::13) with Microsoft SMTP Server (TLS) id 15.1.280.20 via Frontend Transport; Tue, 29 Sep 2015 12:57:59 +0000 Authentication-Results: spf=fail (sender IP is 146.108.200.10) smtp.mailfrom=tridonic.com; gmx.net; dkim=none (message not signed) header.d=none;gmx.net; 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 AM1FFO11FD047.mail.protection.outlook.com (10.174.65.210) with Microsoft SMTP Server (TLS) id 15.1.274.4 via Frontend Transport; Tue, 29 Sep 2015 12:57:59 +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; Tue, 29 Sep 2015 14:57:58 +0200 From: Somaraju Abhinav To: Hannes Tschofenig , "Ace@ietf.org" Thread-Topic: [Ace] COSE and multicast: Discussion Summary? Thread-Index: AQHQ+pNBs5zKRWSQbUO6oqSVhwHRsJ5TbgDQ Date: Tue, 29 Sep 2015 12:57:57 +0000 Message-ID: <0E9A48AB39AF3547ACD28A6DE3E2906A0A9D2C@ATBRAGMSX02.itiso.net> References: <560A4F84.4030806@gmx.net> In-Reply-To: <560A4F84.4030806@gmx.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: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Microsoft-Exchange-Diagnostics: 1; AM1FFO11FD047; 1:RebEj+B49Uap2w7RrPgOUxZz8VVqv3TvPfWNP95e1Ikzym1bqyzPoeFkBx2HSSG0WOCqLZHdZ848gRR11xErotJVW36SCKhQUmrDBaLA7H+Nvdh4XCJVT/saKgiqPTR8fYfkGPCsJgmABQBCmThCr6rGAdsBwAObshfViISyfaOnIsd+boIrJiWywptq7RYpyYIhz6Rv9uulxRUFjOTVSjJSwdLgH0DVXAbgKWI5TFnx82NnefWBnXlyxSFnVgneGhmus0xD27O59VZhL06Mw62RkfpIS5rTxT0rcd99RucLxOv2Sdo0GuHuzbdHYeQDJ97DL8H0S14YCSsMz5+91VUrdYxKw++Dv5Lx1HD6qvQ= 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)(189002)(199003)(13464003)(53754006)(66066001)(85426001)(6806005)(2920100001)(62966003)(4001540100001)(2900100001)(2501003)(46102003)(2950100001)(5001960100002)(102836002)(15975445007)(107886002)(23676002)(5003600100002)(33656002)(11100500001)(189998001)(19580395003)(86362001)(19580405001)(105606002)(69596002)(92566002)(106116001)(64706001)(106466001)(50466002)(76176999)(5890100001)(87936001)(77156002)(50986999)(55846006)(47776003)(54356999)(5001770100001)(5001860100001)(5001830100001)(53416004)(81156007)(5007970100001)(104016004)(26826002)(5004730100002); DIR:OUT; SFP:1102; SCL:1; SRVR:AM4PR06MB1474; H:ATBRAGMSX01.itiso.net; FPR:; SPF:Fail; PTR:unknown.zgrp.net; MX:1; A:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; AM4PR06MB1474; 2:7sFmvaHcNhcJ4qBT3ysEq9xkz1Ux7OYpdjlSnkyQQbLGRaR8pE/dcC3sSuAkED0yNX0rqT2XstFxXoMPgnHlyB/peYh5VjlrmK1hWsM0B+P3P7WQ4M+I+rNEYtJWxSylK++vhgAX2+xGCRdLGY2hubV/rpRkK+1dzECRUW7NOIo=; 3:tGZled5kDkM0jUTyh5lZT8yuCijQnnd3wnmTpmzg/Bnys/V/nIsv3NHenZe9dm3L3QThXw4NuwmVAApbt9Vl/oL9z+ACUvu43UrCAoqePWQFUGP8wje0QQGrUtU6Dgdf2ChCnhHYIYeXiU3bE0Khue4HqFGZ53pnOXPHg29e0MYKnd7RyRY7HSOyyYbsnmKrO0EZ86FFA8zQJ0Kix03hau1P3WUy0/DWXwdu6bvmbbahIjT/tOcY3iTMoELI8P6T; 25:4efxy3fAaBmjjrPKpzyml6QXxKsykBP+otSxZEFtkDlj3EyTujQgEW4fUaP1N9b8+tbglTqGrwZ3Q5ftHbG4AmFgpNTdZjBr10zm8WTmsYSfpdNa2iCDn8MYvRMjvApLpbQSeBHhUDKwoC9iHMMWDqcwZAeTXTpoOnuPmI0izt90sv/iR1TVAILUm1ikq5i5BrIp+OdppQR1r/2u47S842/gR5zad1aHk2CqhEgphaI8GUI4tpTZFKIQbeynSZ1kidL2aLUuaONZOylwGyPl/A== X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:AM4PR06MB1474; X-Microsoft-Exchange-Diagnostics: 1; AM4PR06MB1474; 20:NI6MTx4t772TIpn08LceZBUxKyTKzuNBQrlNBs2gi7jblHnKJRb2e1JsAnCFVmRYJ2Ljj71D40SxCbws2wQwrEEg1bF6zB/F8OFgzEfcyFDnbKS5vKWb1ZOs8Pn0deNiFZvm2rvgfB+jDRzCOUTOMgPVTU6qiBfW3C4fMYH0ekcWxeAJrUUIz1B2oaYEPVMdM032mEiRiOniIU788p2Yzc/e9ZubBfHuJYJydzc8WiBwB7eYH3Hfi4ibjv4fofmlvUi9d/TQBBMeQ1lV4D+nmXN/Hyi+ah43PKg2ixoBQAPwOyOUNpxDFJbtPFkibPJ6uK2kGsE/BNRltiegockm+qm759Fakt83vWm27l6TDdqEyuzxdo9BiZUWTJS6TI3ahpHrOD2di3Jx78hX6OS/BBobGG0MtMxWs6XWaagT0kCvzoB9dqICLGMVHZAyA+TLrjgxd1rRn0jzlyDzq207jXltWJw3GmA6/JbsojkRLsWqyAuzbcIc7n04hzy4TLGi; 4:jnjM0o/t9wggsOB6XxP/j3bOnhTDImxNUHcfjJW3moInK/AUyZMIsBpuMCxGw+TPKn8a9NsbawxQOxHIEZN7PAjkEsnOTi+TT413vUITD0pR7fQNZHKgJLUx1A7X0yci6TImbL+NIQaGV5P8irqgHfaigYEwAa8USyaQcDcm+57jTOQS24oNmajkOw12G4kyquoLXNWc5w0v35SQUkeTt+kx4FP5o3h9Hp/I4pIKTOhhUo+Go0jua0EHReE+gVS/q4+LixTn0Amc00pQvtBLBjog8qTjQQ84n7SRhP1V3lW9lZ9Cp7ImVobgD3bPGGfPlK8Cw5qUJLozvNAVurchIoxJ9JtCJpsqFmGUuRkrpV8= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(520078)(5005006)(3002001); SRVR:AM4PR06MB1474; BCL:0; PCL:0; RULEID:; SRVR:AM4PR06MB1474; X-Forefront-PRVS: 0714841678 X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtBTTRQUjA2TUIxNDc0OzIzOk1wbHdTKy9lY2xJVTdKUzVLV0p2K3EzcW1U?= =?utf-8?B?enVFN2d5a0J0LzFXY0lZK21WZnF5YXhpVXlwcXlGcUJDRDFYM1ZPVjN3UEUw?= =?utf-8?B?MG5DQjBtM0tRUHZXSC9hUVQrb1BkbGVTYmVXTVd4dlpMK3hRUmJmZW41SWg4?= =?utf-8?B?YUV0TnJLRi8wa3dNTGJ1SDZ0Vi90eGR3WGVBZDJsNFNQV04zREdxUUVpV29X?= =?utf-8?B?elNselcwRmxkbVpKeks2UmNpR3BVbUtHMWZsRERlS0RXN3B6Umt3bGlyM3JO?= =?utf-8?B?U2wxS1IrRzRQVEY4ZHo5SkRlSFFFSGRqa1p1ZVVyNGdtdkN1U3ZPZTJxYVZ3?= =?utf-8?B?TklGbmJLb0dCQVBaMEZOSVJIR1JFQ3M2NTRpK25zb3A1c2tXSVM2d0RGN0Ny?= =?utf-8?B?T1hSMGM4cHI1dWgwWHpYL1dJcDRCaExYcG12ekIxNmxsUWFXZFVWRWFOSmF0?= =?utf-8?B?WUxnTE9FSzlxOHB3YW5weklEM0pDZnQxMDBndmgybFlORmlheEh0U3cyeW9j?= =?utf-8?B?L3dNZlE0V0lwanNqTVhpY1ZDRTJpemVTS1k3Nk5OMGV3VmRCMmZmODdKdXJs?= =?utf-8?B?NmZSdy95azYwZThOZ1lUSkxoZFdHeThqMkltb1B5N1VXSTNRTUQzUElDLzFJ?= =?utf-8?B?SUZGZDdQZ3RJdVE2QlpXTXdMckgvYTdyZ3Vid2NrQ1FTeHNMQk93cnkwMkhN?= =?utf-8?B?WXN3UCthcHZZaXgwZDM5ekZ0ekFHYkNhSTBxUnFja0ZZV3ZibE9zbzhBelR5?= =?utf-8?B?S1B1U1B4eTg4cDJJeG8rZEN4L20razVsWGlSTlZwbGlrSDYvTmJCRG9lM3d1?= =?utf-8?B?YkFHYmdrNHV1d0JHQmV6YmNNL0J0TlV6L3dMZjVIK1h0cDZRMkFLZ1JzOHBU?= =?utf-8?B?UjgrOFpoQnJ5UkRlcHdWUTZVd2F6Sml4VUFyQmlxSTQ5QWx6M28zU2hySVA4?= =?utf-8?B?NUpVWlRINEVPVUNqS091aEQ2Y1puNkE1bTJHUHJMU1dhWFVoRDlBSE9uN3li?= =?utf-8?B?Q0p4cGN1c2dJU3hoNHdtaERPYXhqcVU4VHB2UFdDYlh0bnBaTnlPVTFLd2Jh?= =?utf-8?B?eFBpMmJaZ2gxOEUwZ21ReW9GVHovTFdjT1U1VFE3cERUMndxZjNkc0lRNHBB?= =?utf-8?B?RklLUzRKRHVyL3Y0SURKY2J4WUZiUG8rQmFHOTYyZjBkejloWDE0Q2hUd2tL?= =?utf-8?B?SDBMNG1DTlEyMGxQYnhpWUNBMnNzM0xsT3R3dDZCS3VNWk5CV3kvRlRqQ2VJ?= =?utf-8?B?TE51Q0tvY3NWbDh0L0hhVldGclh4L3I2SVN1UDAzMDZnQzB2WWdHTDVHUXZH?= =?utf-8?B?Rkg3QXB5OVQzT3lEM28wcHZ0QzFvMTFwLzZHRmNPampneUtYdUtHM3BMaHZY?= =?utf-8?B?clZha3MxTVJLakR0TTFpZExrSjNzMmNKZjdqd21BZGxFUHhsd3F3eUI5dVRM?= =?utf-8?B?T3FhSjYvR0hnMGRHdjVza2R1TVd2N0F2RWJ0OEIrZkJNa1FuUW9NRHh6RUVF?= =?utf-8?B?L0diR2JKdytDZ0tWeHIwcDlybUhXS01zb1dGQnNsRDlaY1d4V1lveXRZMVQx?= =?utf-8?B?dG9iSHJCV2g5MkFoWHRBbzkrS2tQY2xXNjVnQVhmbFpvcXFBRk1BNzM3Wkoy?= =?utf-8?B?RHp3Yi9paElFa2xqKzQ5eWt1YUc1M1RSbWN1YzFIUDJzdTAvVFNYMk0yV3pJ?= =?utf-8?B?Szh3N3RuVFd1VlVmVUtLYTdjUDBOK0MxU3RCaFNwVjBQTjZaeXYwa01IU051?= =?utf-8?B?WU54ODFva0lBTlFWeGNxN2MxVy9rc2xWMTdObWVOeDlrRnRhVTJWcHpmR2pL?= =?utf-8?B?VG5DZG1pZFMvKy9icXNJS3RyMGxKM3ZyMEpMUzFFNDg3MzlMSTN5RTJTemUr?= =?utf-8?B?NGRqd1Q2dkhObVlENGp6WFI3OUtQczdiTXpOelNjc3ZXUURhblhEc29MdkZ5?= =?utf-8?B?Y3RXL2theGc2cElZeDNIRTluTy8wcjduaUg0K1VsOTZ2TnZWZjQ0STJOYngw?= =?utf-8?Q?scoa8p?= X-Microsoft-Exchange-Diagnostics: 1; AM4PR06MB1474; 5:pl1CIaWr66L/VA45Bukneul5NEvtWLi0hL2Zk/l46ArNwSWwpzKUcCL09GQel8zIKXX6FXaq1YtMDfYgoJgCCtw6yMcfYKOUN52Kja6fAM5YDHF4pHkTbpbm127SPbQGocFfu9pxyyUWsEBvmCWiew==; 24:HzTUcWR745/Og2XoOdt8RGUMdd8PLsoNbxhrMftg6cBQqK2XZWVmPXwUxjmw01GI5MGmubzmGqctL6tLcPEQHtioD0MKLiODOzzrpDzoZPk=; 20:bsgRIQHmYA0vWTkmz4L8agchQYTDYg3cnwH0Tz3wALvwH4H1WQ4qZAioDQUPaFtCh/deX9mXiIiKZx/a2fNWNQ== SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: tridonic.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 29 Sep 2015 12:57:59.1965 (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: AM4PR06MB1474 Archived-At: Subject: Re: [Ace] COSE and multicast: Discussion Summary? 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, 29 Sep 2015 12:58:23 -0000 SGkgSGFubmVzLA0KVGhhbmsgeW91IGZvciB0aGUgc3VtbWFyeS4gSSBhZ3JlZSB3aXRoIHdoYXQg eW91IGFyZSBzYXlpbmcgLSBJIGRpZCBub3QgdW5kZXJzdGFuZCBmdWxseSB0aGUgb3V0Y29tZSBv ZiB0aGlzIGRlYmF0ZSB3aXRoIHJlZ2FyZHMgdG8gbWFraW5nIHRoZSAnYWxnJyBwYXJhbWV0ZXIg b3B0aW9uYWwuDQoNCkl0IHdvdWxkIGhlbHAgYSBsb3QgaWYgdGhlIGF1dGhvcnMgb2YgdGhlIENv U0UgZHJhZnQgY2xhcmlmeSBpZiB0aGV5IHRoaW5rIHRoYXQgQ29TRSB3aWxsIGJlIHVzZWQgaW4g c3VjaCBhIHR3by1zdGVwIHByb2Nlc3MuDQoNCkkgYXNzdW1lZCB0aGF0IGZvciBtdWx0aWNhc3Qg Y29tbXVuaWNhdGlvbiB3ZSB3aWxsIGZvbGxvdyBzdWNoIGEgdHdvLXN0ZXAgcHJvY2VzczogMSkg SW4gdGhlIGZpcnN0IHN0ZXAgc29tZSBtZXRob2QgKHlldCB0byBiZSBmaXhlZCkgaXMgdXNlZCB0 byBkaXN0cmlidXRlIHRoZSBrZXlzIHRvIG1lbWJlcnMgb2YgdGhlIGdyb3VwLCBlc3RhYmxpc2gg YSBjb250ZXh0LCBkZXRlcm1pbmUgdGhlIGFsZ29yaXRobSB0aGF0IHdpbGwgYmUgdXNlZCBldGMu IGFuZCAyKSBVc2UgT2JqZWN0IHNlY3VyaXR5IGZvciB0aGUgc2Vjb25kLXN0ZXAgc28gdGhhdCAi d2UgY2FuIGdvIGZ1bGwgc3BlZWQgd2l0aCBzeW1tZXRyaWMgY3J5cHRvIi4gVGhpcyBtb3RpdmF0 ZWQgdGhlIHJlcXVlc3QgdG8gbWFrZSB0aGUgJ2FsZycgcGFyYW1ldGVyIG9wdGlvbmFsIGluIHRo ZSBoZWFkZXIgc28gdGhhdCB3ZSBjYW4gdXNlIENvU0UgYmFzZWQgb2JqZWN0IHNlY3VyaXR5IGZv ciBtdWx0aWNhc3QgbWVzc2FnZXMgaW4gc3RlcCAyLg0KDQpSZWdhcmRzLA0KQWJoaW5hdg0KDQot LS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogQWNlIFttYWlsdG86YWNlLWJvdW5jZXNA aWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBIYW5uZXMgVHNjaG9mZW5pZw0KU2VudDogRGllbnN0YWcs IDI5LiBTZXB0ZW1iZXIgMjAxNSAxMDo0NQ0KVG86IEFjZUBpZXRmLm9yZw0KU3ViamVjdDogW0Fj ZV0gQ09TRSBhbmQgbXVsdGljYXN0OiBEaXNjdXNzaW9uIFN1bW1hcnk/DQoNCkhpIGFsbCwNCg0K SSByZS1yZWFkIHRoZSBlbWFpbCBtZXNzYWdlcyBvbiB0aGUgZGlzY3Vzc2lvbiB0aHJlYWQgSmlt IHBvc3RlZCAoc2VlDQpodHRwOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvYWNlL2N1 cnJlbnQvbXNnMDEyODUuaHRtbCkgaW4gYW4gYXR0ZW1wdCB0byBmaW5kIG91dCB3aHkgdmVyc2lv biAtMDUgb2YgdGhlIENPU0UgZHJhZnQgZG9lcyBub3QgaGF2ZSB0aGUgJ2FsZycgcGFyYW1ldGVy IG9wdGlvbmFsLg0KDQpJIHNlZSBhZ3JlZW1lbnQgdGhhdCBpbiBjZXJ0YWluIHVzZSBjYXNlcyBh IGNvbnRleHQgaWRlbnRpZmllciBpcyBuZWVkZWQgKHN1Y2ggYXMgYSBrZXkgaWQsIG9yIHdoYXRl dmVyIHlvdSB3YW50IHRvIGNhbGwgaXQpLiBCdXQgSSBhbHNvIG5vdGljZSBhIGxvdCBvZiB1bnJl bGF0ZWQgZGlzY3Vzc2lvbnMgdGhhdCBtYWtlIGl0IGRpZmZpY3VsdCB0byBmaW5kIG91dCB3aGF0 IHdhcyB0aGUgb3V0Y29tZSBvZiB0aGUgZGViYXRlLg0KDQpXaGlsZSBhIHNlY3VyaXR5IGNvbnRl eHQgaWRlbnRpZmllciBpcyBub3QgbmV3IGNvbmNlcHQgSSB3b3VsZCBsaWtlIHRvIGV4cGxhaW4g aXQgYWdhaW4uDQoNCkluIG1hbnkgc2VjdXJpdHkgcHJvdG9jb2xzIGEgbW9yZSBzb3BoaXN0aWNh dGVkIHByb3RvY29sIGV4Y2hhbmdlIGlzIGV4ZWN1dGVkIGZpcnN0IGFuZCB0aGVuIGtleXMgYXJl IGRlcml2ZWQgYW5kIGZvcm0gYSBzZWN1cml0eSBhc3NvY2lhdGlvbi4gVGhlIHNlY3VyaXR5IGFz c29jaWF0aW9uIGNvbnNpc3RzIG9mIGtleXMgKHR5cGljYWxseSBkaWZmZXJlbnQga2V5cyBpbiBk aWZmZXJlbnQgZGlyZWN0aW9ucyksIGFncmVlZCBhbGdvcml0aG1zLCBzZXF1ZW5jZSBudW1iZXIg Y291bnRlcnMsIGFuZCBhIGxhYmVsLiBEaWZmZXJlbnQgcHJvdG9jb2xzIHV0aWxpemUgdGhlIGxh YmVsIGRpZmZlcmVudGx5IGJ1dCB0aGF0IGxhYmVsIGlzIHVzZWQgdG8gcmVmZXJlbmNlIHRoZSBz ZWN1cml0eSBhc3NvY2lhdGlvbi4gRGlmZmVyZW50IHByb3RvY29scyBhbHNvIHVzZSBhIGRpZmZl cmVudCB0ZXJtIGZvciB0aGUgZXN0YWJsaXNoZWQgY29udGV4dCBpbmZvcm1hdGlvbi4gKEVuZ2lu ZWVycyBsaWtlIHRvIGludmVudCBuZXcgdGVybXMuKQ0KDQpXaGVuIHRoaXMgaW5pdGlhbCBwaGFz ZSBpcyBjb21wbGV0ZWQgZGF0YSB0cmFmZmljIGNhbiBiZSBlbmNyeXB0ZWQvaW50ZWdyaXR5L3Jl cGxheSBwcm90ZWN0ZWQuDQoNCldoeSBpcyB0aGlzIHR3by1zdGVwIGFwcHJvYWNoIHVzZWQ/IFlv dSBkbyB0aGUgaGVhdnkgbGlmdGluZyBvbmNlIGFuZCB0aGVuIHlvdSBjYW4gZ28gZnVsbCBzcGVl ZCB3aXRoIHN5bW1ldHJpYyBjcnlwdG8uDQoNCklmIHlvdSBrbm93IGdldCB0aGUgaW1wcmVzc2lv biB0aGF0IHlvdSBoYXZlIGhlYXJkIGFib3V0IHRoYXQgY29uY2VwdCBiZWZvcmUgdGhlbiB5b3Ug YXJlIGFic29sdXRlbHkgcmlnaHQuDQoNCkV4YW1wbGU6IElLRXYyIGFuZCBJUHNlYyBFU1AuIChU aGlzIHRpbWUgSSBwaWNrZWQgYSBkaWZmZXJlbnQgZXhhbXBsZSBzbyB0aGF0IG5vYm9keSBnZXRz IGh1bmcgdXAgb24gdGhlIERUTFMgc3RvcnkuKQ0KDQpUaGUgaGVhdnkgbGlmdGluZyBpbiB0aGlz IGNhc2UgaXMgdGhlIElLRXYyIGV4Y2hhbmdlIHRoYXQgZXN0YWJsaXNoZXMgKGluIHRoaXMgY2Fz ZSkgdGhlIElQc2VjIFNBcy4gSVBzZWMgRVNQIHRoZW4gb25seSB1c2VzIHRoZSBwcmV2aW91c2x5 IGVzdGFibGlzaGVkIHNlY3VyaXR5IGNvbnRleHQgYW5kIHVzZXMgc3ltbWV0cmljIGNyeXB0b2dy YXBoeS4NCg0KV2hlbiB5b3UgbG9vayBhdCB0aGUgSVBzZWMgaGVhZGVyIHRoZW4geW91IHdpbGwg c2VlIHRoYXQgdGhlIG1lc3NhZ2UgZG9lc24ndCBjYXJyeSBhbiBhbGdvcml0aG0gZmllbGQgaW4g dGhlcmUuDQoNCkhvdyBjb21lIGlzIHRoYXQ/IFdlbGwuIEl0IGhhcyBiZWVuIGVzdGFibGlzaGVk IGFscmVhZHkgd2l0aCB0aGUgZWFybGllcg0KSUtFdjIgZXhjaGFuZ2UuIEJvdGggcGFydGllcyBr bm93IHRoZSBhbGdvcml0aG0gYW5kIGFsbCB0aGUgb3RoZXIgaW5mb3JtYXRpb24gYWxyZWFkeS4g QWxsIHRoYXQgaXMgbmVlZGVkIGF0IHRoaXMgcG9pbnQgaXMgYSB3YXkgdG8gc2VsZWN0IHRoZSBj b3JyZWN0IHNlY3VyaXR5IGFzc29jaWF0aW9uIHdoZW4gcmVjZWl2aW5nIGEgbWVzc2FnZSBpbiBv cmRlciB0byBkZWNyeXB0IHRoZSBwYXlsb2FkLiBUaGVyZSBuZWVkcyB0byBiZSBzb21lIGluZm9y bWF0aW9uIGluIHRoZSBwYWNrZXQgaXRzZWxmIHRvIGRvIHRoYXQgKGluIHRoZSB1bmVuY3J5cHRl ZCBwYXJ0LCBvZiBjb3Vyc2UpLiBMZXQgdXMgY2FsbCBpdCBhIGxhYmVsLiBUaGVyZSBpcyBubyBu ZWVkIHRvIGNhcnJ5IHJlZHVuZGFudCBpbmZvcm1hdGlvbiBhcm91bmQgd2l0aCBldmVyeSBJUHNl YyBwYWNrZXQuDQoNCldoYXQgbGFiZWwgaXMgdXNlZCBpbiBJUHNlYz8gQSBxdWljayBsb29rIGF0 DQpodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNDMwMyByZXZlYWxzIHRoYXQgdGhlIGF1 dGhvcnMgaGF2ZSBjYWxsZWQgaXQgU2VjdXJpdHkgUGFyYW1ldGVyIEluZGV4IChTUEkpLiBJbiBj YXNlIG9mIHVuaWNhc3QgSVBzZWMgdGhlIFNQSSBpdHNlbGYgaXMgbm90IHVuaXF1ZSBhbmQgaGFz IHRvIGJlIGNvbWJpbmVkIHdpdGggb3RoZXIgaW5mb3JtYXRpb24gKG5hbWVseSBwcm90b2NvbCAt IEVTUCBvciBBSCwgYW5kIHRoZSBkZXN0aW5hdGlvbiBhZGRyZXNzKS4gTm90IGEgYmlnIGRlYWwu IFRoZXJlIGFyZSBhbHNvIHNwZWNzIGZvciB0aGUgdXNlIG9mIG11bHRpY2FzdCBJUHNlYy4NCg0K SXMgaXQgc28gZmFyIGZldGNoZWQgdG8gcmUtdXNlIHRoZSBzYW1lIGNvbmNlcHRzIHRoYXQgb3Ro ZXJzIGhhdmUgaW50cm9kdWNlZCBpbiB0aGUgSUVURiBhbHJlYWR5IGJlZm9yZT8NCg0KQ2lhbw0K SGFubmVzDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fIFRoZSBjb250ZW50cyBvZiB0aGlzIGUtbWFpbCBhbmQgYW55IGF0dGFjaG1lbnRz IGFyZSBjb25maWRlbnRpYWwgdG8gdGhlIGludGVuZGVkIHJlY2lwaWVudC4gVGhleSBtYXkgbm90 IGJlIGRpc2Nsb3NlZCB0byBvciB1c2VkIGJ5IG9yIGNvcGllZCBpbiBhbnkgd2F5IGJ5IGFueW9u ZSBvdGhlciB0aGFuIHRoZSBpbnRlbmRlZCByZWNpcGllbnQuIElmIHRoaXMgZS1tYWlsIGlzIHJl Y2VpdmVkIGluIGVycm9yLCBwbGVhc2UgaW1tZWRpYXRlbHkgbm90aWZ5IHRoZSBzZW5kZXIgYW5k IGRlbGV0ZSB0aGUgZS1tYWlsIGFuZCBhdHRhY2hlZCBkb2N1bWVudHMuIFBsZWFzZSBub3RlIHRo YXQgbmVpdGhlciB0aGUgc2VuZGVyIG5vciB0aGUgc2VuZGVyJ3MgY29tcGFueSBhY2NlcHQgYW55 IHJlc3BvbnNpYmlsaXR5IGZvciB2aXJ1c2VzIGFuZCBpdCBpcyB5b3VyIHJlc3BvbnNpYmlsaXR5 IHRvIHNjYW4gb3Igb3RoZXJ3aXNlIGNoZWNrIHRoaXMgZS1tYWlsIGFuZCBhbnkgYXR0YWNobWVu dHMuDQo= From nobody Tue Sep 29 06:04: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 BA8401B3C5C; Tue, 29 Sep 2015 06:04:33 -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 McfzB-UEkGfq; Tue, 29 Sep 2015 06:04:32 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A983A1B3C5A; Tue, 29 Sep 2015 06:04:30 -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: <20150929130430.27260.42.idtracker@ietfa.amsl.com> Date: Tue, 29 Sep 2015 06:04:30 -0700 Archived-At: Cc: ace@ietf.org Subject: [Ace] I-D Action: draft-ietf-ace-actors-01.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: Tue, 29 Sep 2015 13:04:33 -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-01.txt Pages : 31 Date : 2015-09-29 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-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ace-actors-01 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 Tue Sep 29 06:25: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 B488D1B3D81 for ; Tue, 29 Sep 2015 06:25:10 -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 SErfVa8IwjZz for ; Tue, 29 Sep 2015 06:25:09 -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 CA1BA1B3D80 for ; Tue, 29 Sep 2015 06:25: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 [IPv6:2001:638:708:30c9::b]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id t8TDP0Tg021916 for ; Tue, 29 Sep 2015 15:25:00 +0200 (CEST) Received: from [192.168.1.109] (p57A63B54.dip0.t-ipconnect.de [87.166.59.84]) (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 3nQLzw3MWfz4pGn for ; Tue, 29 Sep 2015 15:25:00 +0200 (CEST) References: <20150929131917.3219.71402.idtracker@ietfa.amsl.com> To: "Ace@ietf.org" From: Stefanie Gerdes X-Forwarded-Message-Id: <20150929131917.3219.71402.idtracker@ietfa.amsl.com> Message-ID: <560A912C.7040505@tzi.de> Date: Tue, 29 Sep 2015 15:25:00 +0200 User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <20150929131917.3219.71402.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: [Ace] Fwd: New Version Notification for draft-gerdes-ace-tasks-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, 29 Sep 2015 13:25:10 -0000 Hi all, I just submitted a new document containing the authentication- and authorization-related tasks that the actors in the ACE architecture need to perform. This document can be used as an accompanying document to the actors draft. The tasks were originally included in the actors draft but we decided to put them into a separate document when we merged the actors draft and the problem description draft. Comments are welcome! Best regards, Steffi -------- Forwarded Message -------- Subject: New Version Notification for draft-gerdes-ace-tasks-00.txt Date: Tue, 29 Sep 2015 06:19:17 -0700 From: internet-drafts@ietf.org To: Stefanie Gerdes , Stefanie Gerdes A new version of I-D, draft-gerdes-ace-tasks-00.txt has been successfully submitted by Stefanie Gerdes and posted to the IETF repository. Name: draft-gerdes-ace-tasks Revision: 00 Title: Authorization-Related Tasks in Constrained Environments Document date: 2015-09-29 Group: Individual Submission Pages: 20 URL: https://www.ietf.org/internet-drafts/draft-gerdes-ace-tasks-00.txt Status: https://datatracker.ietf.org/doc/draft-gerdes-ace-tasks/ Htmlized: https://tools.ietf.org/html/draft-gerdes-ace-tasks-00 Abstract: Constrained nodes are small devices which are limited in terms of processing power, memory, non-volatile storage and transmission capacity. Due to these constraints, commonly used security protocols are not easily applicable. Nevertheless, an authentication and authorization solution is needed to ensure the security of these devices. Due to the limitations of the constrained nodes it is especially important to develop a light-weight security solution which is adjusted to the relevant security objectives of each participating party in this environment. Necessary security measures must be identified and applied where needed. In this document, the required security related tasks are identified as guidance for the development of authentication and authorization solutions for constrained environments. 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 Tue Sep 29 06:27: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 707211B3DB2 for ; Tue, 29 Sep 2015 06:27:42 -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 Yf_3FExvhObU for ; Tue, 29 Sep 2015 06:27: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 7EA571B3DAF for ; Tue, 29 Sep 2015 06:27: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 [134.102.201.11]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id t8TDRWHj026719 for ; Tue, 29 Sep 2015 15:27:32 +0200 (CEST) Received: from alma.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 3nQM2r1hZwz4pZr; Tue, 29 Sep 2015 15:27:32 +0200 (CEST) Message-ID: <560A91C2.4030102@tzi.org> Date: Tue, 29 Sep 2015 15:27:30 +0200 From: Carsten Bormann User-Agent: Postbox 4.0.5 (Macintosh/20150923) MIME-Version: 1.0 To: ace@ietf.org References: <20150929130430.27260.42.idtracker@ietfa.amsl.com> In-Reply-To: <20150929130430.27260.42.idtracker@ietfa.amsl.com> X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Ace] I-D Action: draft-ietf-ace-actors-01.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, 29 Sep 2015 13:27:42 -0000 This is a small update of the actors draft, 24 h before tomorrow's interim. Note that the authors have had only very little time to review this respin; all errors are mine. We also have to do another round of checking which of the comments so far have been addressed. Definitely not yet addressed are: -- tasks (An earlier version of the draft had an extensive discussion of the tasks actors have in achieving specific security objectives, and we may want to relate to some of that. It may not be necessary to hold up the Actors document for completing this discourse, though.) -- maintain a clear separation between Actors and OAuth terminology In Hawaii, the in-room rough consensus was to replace some of the Actors terms with more or less equivalent OAuth terms, which has confused reviewers. With proposals on the table that use OAuth on the less-constrained level, this starts to be even more confusing. We can discuss the need for this separation some more tomorrow. -- discuss store and forward (intermediary actors) Probably to be added to section 2.3 based on Jim鈥檚 proposed changes. Details not clear yet. If you have read -00, the diff is at https://www.ietf.org/rfcdiff?url2=draft-ietf-ace-actors-01 Otherwise, you have 23.5 hours to read https://tools.ietf.org/html/draft-ietf-ace-actors-01 from scratch... Looking forward to hear you at the virtual (= Webex) interim: https://ietf.webex.com/ietf/j.php?MTID=m35831da47aeb861e92e275bbb13283b5 Meeting number: 642 579 330 Meeting password: iot-rocks 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-01.txt > Pages : 31 > Date : 2015-09-29 > > 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-01 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-ace-actors-01 > > > 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 Tue Sep 29 13: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 7EDB21B2B4E for ; Tue, 29 Sep 2015 13:54:59 -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 YEd2oincpjZc for ; Tue, 29 Sep 2015 13:54:57 -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 C4E521B2B4C for ; Tue, 29 Sep 2015 13:54:57 -0700 (PDT) Received: from hebrews (173-12-183-193-oregon.hfc.comcastbusiness.net [173.12.183.193]) (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 235212CA76; Tue, 29 Sep 2015 13:54:57 -0700 (PDT) From: "Jim Schaad" To: "'Hannes Tschofenig'" , References: <560A4F84.4030806@gmx.net> In-Reply-To: <560A4F84.4030806@gmx.net> Date: Tue, 29 Sep 2015 13:52:27 -0700 Message-ID: <067601d0faf8$c0dbfb60$4293f220$@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: AQKdBjYC3LJN9TwcbCQVZXrE3Ea1j5y74/xQ Archived-At: Subject: Re: [Ace] COSE and multicast: Discussion Summary? 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, 29 Sep 2015 20:54:59 -0000 > -----Original Message----- > From: Ace [mailto:ace-bounces@ietf.org] On Behalf Of Hannes Tschofenig > Sent: Tuesday, September 29, 2015 1:45 AM > To: Ace@ietf.org > Subject: [Ace] COSE and multicast: Discussion Summary? >=20 > Hi all, >=20 > I re-read the email messages on the discussion thread Jim posted (see > http://www.ietf.org/mail-archive/web/ace/current/msg01285.html) in an > attempt to find out why version -05 of the COSE draft does not have = the 'alg' > parameter optional. I would say that it is not done, at least in part, because it is not = currently a high priority for me. However, there is not really a solid = document on the table for ACE about what constitutes a protocol to do = key establishment, what is done in the key establishment, how COSE = messages are going to be constructed and sent. This being the case it = may be a matter of putting the cart before the horse to make the = algorithm optional. >=20 > I see agreement that in certain use cases a context identifier is = needed (such as a > key id, or whatever you want to call it). But I also notice a lot of = unrelated > discussions that make it difficult to find out what was the outcome of = the > debate. >=20 > While a security context identifier is not new concept I would like to = explain it > again. >=20 > In many security protocols a more sophisticated protocol exchange is = executed > first and then keys are derived and form a security association. The = security > association consists of keys (typically different keys in different = directions), > agreed algorithms, sequence number counters, and a label. Different = protocols > utilize the label differently but that label is used to reference the = security > association. Different protocols also use a different term for the = established > context information. (Engineers like to invent new terms.) >=20 > When this initial phase is completed data traffic can be > encrypted/integrity/replay protected. >=20 > Why is this two-step approach used? You do the heavy lifting once and = then you > can go full speed with symmetric crypto. >=20 > If you know get the impression that you have heard about that concept = before > then you are absolutely right. >=20 > Example: IKEv2 and IPsec ESP. (This time I picked a different example = so that > nobody gets hung up on the DTLS story.) >=20 > The heavy lifting in this case is the IKEv2 exchange that establishes = (in this case) > the IPsec SAs. IPsec ESP then only uses the previously established = security > context and uses symmetric cryptography. >=20 > When you look at the IPsec header then you will see that the message = doesn't > carry an algorithm field in there. >=20 > How come is that? Well. It has been established already with the = earlier > IKEv2 exchange. Both parties know the algorithm and all the other = information > already. All that is needed at this point is a way to select the = correct security > association when receiving a message in order to decrypt the payload. = There > needs to be some information in the packet itself to do that (in the = unencrypted > part, of course). Let us call it a label. There is no need to carry = redundant > information around with every IPsec packet. >=20 > What label is used in IPsec? A quick look at > https://tools.ietf.org/html/rfc4303 reveals that the authors have = called it > Security Parameter Index (SPI). In case of unicast IPsec the SPI = itself is not unique > and has to be combined with other information (namely protocol - ESP = or AH, > and the destination address). Not a big deal. There are also specs for = the use of > multicast IPsec. >=20 > Is it so far fetched to re-use the same concepts that others have = introduced in > the IETF already before? >=20 > Ciao > Hannes From nobody Tue Sep 29 15:19: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 58A2A1B5451 for ; Tue, 29 Sep 2015 15:19: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 Sut-9LUvW0Kh for ; Tue, 29 Sep 2015 15:19:43 -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 C11D71B5450 for ; Tue, 29 Sep 2015 15:19: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 t8TMJaeU000068; Wed, 30 Sep 2015 00:19:36 +0200 (CEST) Received: from alma.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 3nQZrm2qVNz4pWQ; Wed, 30 Sep 2015 00:19:36 +0200 (CEST) Message-ID: <560B0E76.4050107@tzi.org> Date: Wed, 30 Sep 2015 00:19:34 +0200 From: Carsten Bormann User-Agent: Postbox 4.0.5 (Macintosh/20150923) MIME-Version: 1.0 To: Jim Schaad References: <560A4F84.4030806@gmx.net> <067601d0faf8$c0dbfb60$4293f220$@augustcellars.com> In-Reply-To: <067601d0faf8$c0dbfb60$4293f220$@augustcellars.com> X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: 'Hannes Tschofenig' , Ace@ietf.org Subject: Re: [Ace] COSE and multicast: Discussion Summary? 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, 29 Sep 2015 22:19:44 -0000 Jim Schaad wrote: > However, there is not really a solid document on the table for ACE about what constitutes a protocol to do key establishment, what is done in the key establishment, how COSE messages are going to be constructed and sent. Right. But my assumption would be that all we need to know is that the context established by one of these protocols would go into the interpretation of the (then incomplete) COSE data. (Maybe I'm thinking this too much with a view to my old ROHC WG chair hat.) > being the case it may be a matter of putting the cart before the horse to make the algorithm optional. Right. We should have a model how the "needed" parameters are filled in into the COSE data structure from that context so they don't have to be "mandatory" in the transmitted version of that data structure. That model could be quite simple though. The important part is that anything that is not protected can be modified by an attacker anyway, so why send it with the message if you have it in the context? The handling of (integrity-)protected headers is much more interesting. (Over in the COSE WG I'll make the same case for msg-type, which we should get rid of summarily.) Gr眉脽e, Carsten From nobody Wed Sep 30 01:21: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 BCC4E1A1B1F for ; Wed, 30 Sep 2015 01:20:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.15 X-Spam-Level: * X-Spam-Status: No, score=1.15 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 SJBQ-pw5UzBk for ; Wed, 30 Sep 2015 01:20:59 -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 944A91A1B1E for ; Wed, 30 Sep 2015 01:20:58 -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 t8U8KtrS011787 for ; Wed, 30 Sep 2015 10:20:55 +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 3nQrBb309Fz4q0c; Wed, 30 Sep 2015 10:20:55 +0200 (CEST) Message-ID: <560B9B66.9030302@tzi.org> Date: Wed, 30 Sep 2015 10:20:54 +0200 From: Carsten Bormann User-Agent: Postbox 4.0.5 (Macintosh/20150923) MIME-Version: 1.0 To: "ace@ietf.org" References: <560A9F74.6050004@tzi.de> <560AACEA.3090102@tzi.org> <06C1350B-F3BA-4783-8E03-432059567D7E@gmail.com> In-Reply-To: X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Ace] Terminology (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: Wed, 30 Sep 2015 08:21:00 -0000 (Pulling the discussion out of a private exchange to the mailing list.) > I don鈥檛 think it is about the definitions not being clear. It is just the > names of the nodes, where in the current draft 5 out of 6 terms are > imported from the analogous setting in OAuth/UMA and the 6th, CAS, is > coined by Carsten. The definitions in the current WG Actors draft are clear enough for me. They are just using terms that mean something different in OAuth. RFC 6749 says: authorization server The server issuing access tokens to the client after successfully authenticating the resource owner and obtaining authorization. Nope, that's not at all the AS in the Actors draft. I have not yet heard a convincing reason why appropriating terms from a different domain is helping us here. What does this do? 1 -- People coming from the OAuth world will feel at home immediately. But that is a treacherous comfort: They'll expect things to be the same in the IoT world. They aren't.**) IoT authorization is almost, but not entirely, unlike Browser Web authorization. 2 -- People coming from the IoT world first have to learn the OAuth terminology. I teach this stuff, and I can tell you, that terminology is suboptimal for learners. When they are done with this, see 1. Choosing terms that are adapted to what we are actually trying to do has none of these problems, and it also allows to choose terms that are easy to remember and have the right connotations***). Also, where OAuth is then actually being employed at the less-constrained level, it leaves the OAuth terms free for the OAuth roles (which may be allocated quite differently), and does not cause confusion with the ACE roles. Gr眉脽e, Carsten **) I remember the fun period when SIP was forking off from HTTP, and (not only) the HTTP people had all those misconceptions for what SIP would do, just because HTTP did it as well. ***) If you don't like the original Actors terms: We still can change those. But we first have to unshackle ourselves from the OAuth terms. From nobody Wed Sep 30 01:32: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 F1A241A1B6E for ; Wed, 30 Sep 2015 01:32: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, 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 yplrlfG_JnLP for ; Wed, 30 Sep 2015 01:32:47 -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 46D9F1A1B5D for ; Wed, 30 Sep 2015 01:32:46 -0700 (PDT) Received: from NG-EX02.ad.nexusgroup.com (10.75.28.43) by NG-EX02.ad.nexusgroup.com (10.75.28.43) with Microsoft SMTP Server (TLS) id 15.0.995.29; Wed, 30 Sep 2015 10:32:44 +0200 Received: from NG-EX02.ad.nexusgroup.com ([fe80::2839:3494:59f1:44d]) by NG-EX02.ad.nexusgroup.com ([fe80::2839:3494:59f1:44d%12]) with mapi id 15.00.0995.032; Wed, 30 Sep 2015 10:32:44 +0200 From: =?utf-8?B?RXJpayBXYWhsc3Ryw7ZtIG5lWHVz?= To: Carsten Bormann Thread-Topic: [Ace] Terminology (again) Thread-Index: AQHQ+1j2v+HGsVFNyka0gvZNE/mDEZ5UnO2A Date: Wed, 30 Sep 2015 08:32:44 +0000 Message-ID: <7071283B-7F50-48E6-86C0-2C26B1F13D90@nexusgroup.com> References: <560A9F74.6050004@tzi.de> <560AACEA.3090102@tzi.org> <06C1350B-F3BA-4783-8E03-432059567D7E@gmail.com> <560B9B66.9030302@tzi.org> In-Reply-To: <560B9B66.9030302@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: [37.247.26.197] Content-Type: text/plain; charset="utf-8" Content-ID: <180F24D60B36F04ABDA55AFE2EE7214B@nexusgroup.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "ace@ietf.org" Subject: Re: [Ace] Terminology (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: Wed, 30 Sep 2015 08:32:50 -0000 SGkgQ2Fyc3RlbiwNCg0KU2VlIGJlbG93Lg0KDQo+IE9uIDMwIFNlcCAyMDE1LCBhdCAxMDoyMCwg Q2Fyc3RlbiBCb3JtYW5uIDxjYWJvQHR6aS5vcmc+IHdyb3RlOg0KPiANCj4gKFB1bGxpbmcgdGhl IGRpc2N1c3Npb24gb3V0IG9mIGEgcHJpdmF0ZSBleGNoYW5nZSB0byB0aGUgbWFpbGluZyBsaXN0 LikNCj4gDQo+PiBJIGRvbuKAmXQgdGhpbmsgaXQgaXMgYWJvdXQgdGhlIGRlZmluaXRpb25zIG5v dCBiZWluZyBjbGVhci4gSXQgaXMganVzdCB0aGUNCj4+IG5hbWVzIG9mIHRoZSBub2Rlcywgd2hl cmUgaW4gdGhlIGN1cnJlbnQgZHJhZnQgNSBvdXQgb2YgNiB0ZXJtcyBhcmUNCj4+IGltcG9ydGVk IGZyb20gdGhlIGFuYWxvZ291cyBzZXR0aW5nIGluIE9BdXRoL1VNQSBhbmQgdGhlIDZ0aCwgQ0FT LCBpcw0KPj4gY29pbmVkIGJ5IENhcnN0ZW4uIA0KPiANCj4gVGhlIGRlZmluaXRpb25zIGluIHRo ZSBjdXJyZW50IFdHIEFjdG9ycyBkcmFmdCBhcmUgY2xlYXIgZW5vdWdoIGZvciBtZS4NCj4gVGhl eSBhcmUganVzdCB1c2luZyB0ZXJtcyB0aGF0IG1lYW4gc29tZXRoaW5nIGRpZmZlcmVudCBpbiBP QXV0aC4NCj4gDQo+IFJGQyA2NzQ5IHNheXM6DQo+IA0KPiAgIGF1dGhvcml6YXRpb24gc2VydmVy DQo+ICAgICAgVGhlIHNlcnZlciBpc3N1aW5nIGFjY2VzcyB0b2tlbnMgdG8gdGhlIGNsaWVudCBh ZnRlciBzdWNjZXNzZnVsbHkNCj4gICAgICBhdXRoZW50aWNhdGluZyB0aGUgcmVzb3VyY2Ugb3du ZXIgYW5kIG9idGFpbmluZyBhdXRob3JpemF0aW9uLg0KPiANCj4gTm9wZSwgdGhhdCdzIG5vdCBh dCBhbGwgdGhlIEFTIGluIHRoZSBBY3RvcnMgZHJhZnQuDQo+IA0KPiBJIGhhdmUgbm90IHlldCBo ZWFyZCBhIGNvbnZpbmNpbmcgcmVhc29uIHdoeSBhcHByb3ByaWF0aW5nIHRlcm1zIGZyb20gYQ0K PiBkaWZmZXJlbnQgZG9tYWluIGlzIGhlbHBpbmcgdXMgaGVyZS4gIFdoYXQgZG9lcyB0aGlzIGRv Pw0KDQpEaWZmZXJlbnQgZG9tYWluPyBJdOKAmXMgYSBjb250aW51dW0gYmV0d2VlbiBjb25zdHJh aW5lZCBhbmQgbm9uLWNvbnN0cmFpbmVkIGRldmljZXMuIEl04oCZcyBhbHNvIG1ldGhvZG9sb2dp ZXMgdXNlZCBpbiBleGlzdGluZyBJQU0gaW5mcmFzdHJ1Y3R1cmVzLiBBbmQgdGhvc2UgYXJlIHRo ZSBleGFjdCBzYW1lIGluZnJhc3RydWN0dXJlcyB0aGF0IHdpbGwgbmVlZCB0byBzdXBwb3J0IGNv bnN0cmFpbmVkIGRldmljZXMuDQoNCj4gDQo+IDEgLS0gUGVvcGxlIGNvbWluZyBmcm9tIHRoZSBP QXV0aCB3b3JsZCB3aWxsIGZlZWwgYXQgaG9tZSBpbW1lZGlhdGVseS4NCj4gQnV0IHRoYXQgaXMg YSB0cmVhY2hlcm91cyBjb21mb3J0OiBUaGV5J2xsIGV4cGVjdCB0aGluZ3MgdG8gYmUgdGhlIHNh bWUNCj4gaW4gdGhlIElvVCB3b3JsZC4gIFRoZXkgYXJlbid0LioqKSAgSW9UIGF1dGhvcml6YXRp b24gaXMgYWxtb3N0LCBidXQgbm90DQo+IGVudGlyZWx5LCB1bmxpa2UgQnJvd3NlciBXZWIgYXV0 aG9yaXphdGlvbi4NCg0KQ29uY2VwdHMgYXJlIHRoZSBzYW1lLiBJdOKAmXMganVzdCBzb21lIHBy b2ZpbGluZyB0aGF04oCZcyBuZWVkZWQgdG8gb2F1dGggYW5kIHRoZSBwZW9wbGUgY29taW5nIGZy b20gb2F1dGggd29ybGQgaXMgdXNlZCB0byB0aGF0IChvcGVuZWQgY29ubmVjdCBhbmQgc28gZm9y dGgpLiANCg0KPiANCj4gMiAtLSBQZW9wbGUgY29taW5nIGZyb20gdGhlIElvVCB3b3JsZCBmaXJz dCBoYXZlIHRvIGxlYXJuIHRoZSBPQXV0aA0KPiB0ZXJtaW5vbG9neS4gIEkgdGVhY2ggdGhpcyBz dHVmZiwgYW5kIEkgY2FuIHRlbGwgeW91LCB0aGF0IHRlcm1pbm9sb2d5DQo+IGlzIHN1Ym9wdGlt YWwgZm9yIGxlYXJuZXJzLiAgV2hlbiB0aGV5IGFyZSBkb25lIHdpdGggdGhpcywgc2VlIDEuDQo+ IA0KPiBDaG9vc2luZyB0ZXJtcyB0aGF0IGFyZSBhZGFwdGVkIHRvIHdoYXQgd2UgYXJlIGFjdHVh bGx5IHRyeWluZyB0byBkbyBoYXMNCj4gbm9uZSBvZiB0aGVzZSBwcm9ibGVtcywgYW5kIGl0IGFs c28gYWxsb3dzIHRvIGNob29zZSB0ZXJtcyB0aGF0IGFyZSBlYXN5DQo+IHRvIHJlbWVtYmVyIGFu ZCBoYXZlIHRoZSByaWdodCBjb25ub3RhdGlvbnMqKiopLg0KPiANCj4gQWxzbywgd2hlcmUgT0F1 dGggaXMgdGhlbiBhY3R1YWxseSBiZWluZyBlbXBsb3llZCBhdCB0aGUNCj4gbGVzcy1jb25zdHJh aW5lZCBsZXZlbCwgaXQgbGVhdmVzIHRoZSBPQXV0aCB0ZXJtcyBmcmVlIGZvciB0aGUgT0F1dGgN Cj4gcm9sZXMgKHdoaWNoIG1heSBiZSBhbGxvY2F0ZWQgcXVpdGUgZGlmZmVyZW50bHkpLCBhbmQg ZG9lcyBub3QgY2F1c2UNCj4gY29uZnVzaW9uIHdpdGggdGhlIEFDRSByb2xlcy4NCj4gDQo+IEdy w7zDn2UsIENhcnN0ZW4NCj4gDQo+ICoqKSBJIHJlbWVtYmVyIHRoZSBmdW4gcGVyaW9kIHdoZW4g U0lQIHdhcyBmb3JraW5nIG9mZiBmcm9tIEhUVFAsIGFuZA0KPiAobm90IG9ubHkpIHRoZSBIVFRQ IHBlb3BsZSBoYWQgYWxsIHRob3NlIG1pc2NvbmNlcHRpb25zIGZvciB3aGF0IFNJUA0KPiB3b3Vs ZCBkbywganVzdCBiZWNhdXNlIEhUVFAgZGlkIGl0IGFzIHdlbGwuDQo+IA0KPiAqKiopIElmIHlv dSBkb24ndCBsaWtlIHRoZSBvcmlnaW5hbCBBY3RvcnMgdGVybXM6IFdlIHN0aWxsIGNhbiBjaGFu Z2UNCj4gdGhvc2UuICBCdXQgd2UgZmlyc3QgaGF2ZSB0byB1bnNoYWNrbGUgb3Vyc2VsdmVzIGZy b20gdGhlIE9BdXRoIHRlcm1zLg0KPiANCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCj4gQWNlIG1haWxpbmcgbGlzdA0KPiBBY2VAaWV0Zi5vcmcNCj4g aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9hY2UNCg0K From nobody Wed Sep 30 01:45: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 11A231A1EFE for ; Wed, 30 Sep 2015 01:45:33 -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 oyD8lzAbfbIq for ; Wed, 30 Sep 2015 01:45:31 -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 D79361A1EFF for ; Wed, 30 Sep 2015 01:45: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 t8U8jMv7007160; Wed, 30 Sep 2015 10:45:22 +0200 (CEST) Received: from [IPv6:2001:638:708:30da:98b5:c05d:9032:4f6e] (unknown [IPv6:2001:638:708:30da:98b5:c05d:9032:4f6e]) (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 3nQrkp5pnzz4nyG; Wed, 30 Sep 2015 10:45:22 +0200 (CEST) To: =?UTF-8?Q?Erik_Wahlstr=c3=b6m_neXus?= , Carsten Bormann References: <560A9F74.6050004@tzi.de> <560AACEA.3090102@tzi.org> <06C1350B-F3BA-4783-8E03-432059567D7E@gmail.com> <560B9B66.9030302@tzi.org> <7071283B-7F50-48E6-86C0-2C26B1F13D90@nexusgroup.com> From: Stefanie Gerdes X-Enigmail-Draft-Status: N1110 Message-ID: <560BA11C.1010907@tzi.de> Date: Wed, 30 Sep 2015 10:45:16 +0200 User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <7071283B-7F50-48E6-86C0-2C26B1F13D90@nexusgroup.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: "ace@ietf.org" Subject: Re: [Ace] Terminology (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: Wed, 30 Sep 2015 08:45:33 -0000 Hi Erik, Comments inline. On 09/30/2015 10:32 AM, Erik Wahlstr枚m neXus wrote: > Hi Carsten, > > See below. > >> On 30 Sep 2015, at 10:20, Carsten Bormann wrote: >> >> (Pulling the discussion out of a private exchange to the mailing list.) >> >>> I don鈥檛 think it is about the definitions not being clear. It is just the >>> names of the nodes, where in the current draft 5 out of 6 terms are >>> imported from the analogous setting in OAuth/UMA and the 6th, CAS, is >>> coined by Carsten. >> >> The definitions in the current WG Actors draft are clear enough for me. >> They are just using terms that mean something different in OAuth. >> >> RFC 6749 says: >> >> authorization server >> The server issuing access tokens to the client after successfully >> authenticating the resource owner and obtaining authorization. >> >> Nope, that's not at all the AS in the Actors draft. >> >> I have not yet heard a convincing reason why appropriating terms from a >> different domain is helping us here. What does this do? > > Different domain? It鈥檚 a continuum between constrained and non-constrained devices. It鈥檚 also methodologies used in existing IAM infrastructures. And those are the exact same infrastructures that will need to support constrained devices. Sure, we need constrained and less-constrained devices to talk to each other. What Carsten meant is that the characteristics of constrained devices and constrained environments are special. The less-constrained device that is responsible for the constrained device needs to perform specific tasks that the device cannot perform itself. That is different from the web world, where devices are capable of performing these tasks on their own. > >> >> 1 -- People coming from the OAuth world will feel at home immediately. >> But that is a treacherous comfort: They'll expect things to be the same >> in the IoT world. They aren't.**) IoT authorization is almost, but not >> entirely, unlike Browser Web authorization. > > Concepts are the same. It鈥檚 just some profiling that鈥檚 needed to oauth and the people coming from oauth world is used to that (opened connect and so forth). When we are using OAuth in the constrained world we will also need to consider the constrainedness of the devices. Best regards, Steffi From nobody Wed Sep 30 01:45: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 5CB731A1F16 for ; Wed, 30 Sep 2015 01:45:38 -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 XuzfUGDwjz0F for ; Wed, 30 Sep 2015 01:45:37 -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 172211A1EFE for ; Wed, 30 Sep 2015 01:45:36 -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 t8U8jXxP007791; Wed, 30 Sep 2015 10:45:33 +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 3nQrl13WdSz4nyH; Wed, 30 Sep 2015 10:45:33 +0200 (CEST) Message-ID: <560BA12C.2010705@tzi.org> Date: Wed, 30 Sep 2015 10:45:32 +0200 From: Carsten Bormann User-Agent: Postbox 4.0.5 (Macintosh/20150923) MIME-Version: 1.0 To: =?UTF-8?B?RXJpayBXYWhsc3Ryw7ZtIG5lWHVz?= References: <560A9F74.6050004@tzi.de> <560AACEA.3090102@tzi.org> <06C1350B-F3BA-4783-8E03-432059567D7E@gmail.com> <560B9B66.9030302@tzi.org> <7071283B-7F50-48E6-86C0-2C26B1F13D90@nexusgroup.com> In-Reply-To: <7071283B-7F50-48E6-86C0-2C26B1F13D90@nexusgroup.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] Terminology (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: Wed, 30 Sep 2015 08:45:38 -0000 Erik Wahlstr枚m neXus wrote: > Concepts are the same. It鈥檚 just some profiling that鈥檚 needed to oauth and the people coming from oauth world is used to that (opened connect and so forth). Hammer/Nail. I understand that there are solutions being proposed that take this approach, and I'm not opposed to having some of those solutions in the ACE toolkit, as long as we also do solutions for the domains I'm interested in. However, I'm not sure it is wise to shape the terminology to account just for this subset of the solutions. Gr眉脽e, Carsten From nobody Wed Sep 30 02:09: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 4EF211B2CE7 for ; Wed, 30 Sep 2015 02:09:21 -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 6AhbBuBjG-cW for ; Wed, 30 Sep 2015 02:09:19 -0700 (PDT) Received: from mail-la0-f46.google.com (mail-la0-f46.google.com [209.85.215.46]) (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 CF4481B2CA7 for ; Wed, 30 Sep 2015 02:09:18 -0700 (PDT) Received: by lahh2 with SMTP id h2so38292663lah.0 for ; Wed, 30 Sep 2015 02:09:16 -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=teDHXPODGJ27qzyNuMrWoiytUzb8ZAZlJDzM6rgW2js=; b=bRciMRBTS5mFcXt2AX31/CixmuIT78+t/hGKUSjmG3Gzt5+EX2LBp0DcnRv7syOPcB Epljb8DaASLSPh7DwTuNHMiADvrfppCIg9EGhVOnSeS+nPemDAvSupySdg5TdeLyYu2f 6pASQjQYdJpJcoWI952fzVVpKnELM1Bv+O3DtbdKfpA3AQyN/EA/gIIeECh5Canx3GNV RjfaJI+4k6eMrIKJfj3xw9StzKGOiv91gfCcCOZdd+w/EpDO+GyJBkst/QY9cuEYiBgP H8TwuXBsnFtW8+rElN+X0Xxx8t+yRQ4Mr55ZVbYyl5p+sdRdNSQM0YEY3dIcan0w/NiN fXug== X-Gm-Message-State: ALoCoQmqA25NtEQN+STezjw3lUz52xMj/kdJ4iuRCJ/gqx1g3zi3KS8nR908tVRVl2N+MCGG8y11 X-Received: by 10.152.30.3 with SMTP id o3mr759572lah.90.1443604156308; Wed, 30 Sep 2015 02:09:16 -0700 (PDT) Received: from [192.168.0.108] ([85.235.11.178]) by smtp.gmail.com with ESMTPSA id g7sm13898lbs.10.2015.09.30.02.09.15 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 30 Sep 2015 02:09:15 -0700 (PDT) To: ace@ietf.org References: <560A9F74.6050004@tzi.de> <560AACEA.3090102@tzi.org> <06C1350B-F3BA-4783-8E03-432059567D7E@gmail.com> <560B9B66.9030302@tzi.org> From: Ludwig Seitz Message-ID: <560BA6BA.6090805@sics.se> Date: Wed, 30 Sep 2015 11:09:14 +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: <560B9B66.9030302@tzi.org> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms010703040800010802000700" Archived-At: Subject: Re: [Ace] Terminology (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: Wed, 30 Sep 2015 09:09:21 -0000 This is a cryptographically signed message in MIME format. --------------ms010703040800010802000700 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable On 2015-09-30 10:20, Carsten Bormann wrote: > (Pulling the discussion out of a private exchange to the mailing list.)= > >> I don=E2=80=99t think it is about the definitions not being clear. It = is just the >> names of the nodes, where in the current draft 5 out of 6 terms are >> imported from the analogous setting in OAuth/UMA and the 6th, CAS, is >> coined by Carsten. > > The definitions in the current WG Actors draft are clear enough for me.= > They are just using terms that mean something different in OAuth. > > RFC 6749 says: > > authorization server > The server issuing access tokens to the client after successfull= y > authenticating the resource owner and obtaining authorization. > > Nope, that's not at all the AS in the Actors draft. > I believe you are making an academic distinction here. Of course there=20 are differences between how the AS is used in OAuth and how the=20 different proposals use it in ACE, but the similarities are still quite=20 striking. 1. The ACE AS issues access tokens to the client (via the CAS if there=20 is one). 2. The ACE AS at some point in time will authenticate the resource=20 owner, when he/she configures the authorization policies that govern how = authorization for that resource can be obtained. How is that fundamentally different from the OAuth AS? Also OAuth has usecases where the AS is used in a way that is even more=20 similar to the ACE proposals (cf. the client credentials grant). > I have not yet heard a convincing reason why appropriating terms from a= > different domain is helping us here. What does this do? > > 1 -- People coming from the OAuth world will feel at home immediately. > But that is a treacherous comfort: They'll expect things to be the same= > in the IoT world. They aren't.**) IoT authorization is almost, but no= t > entirely, unlike Browser Web authorization. I think you underestimate the OAuth people. I am sure those=20 participating in the ACE work are well aware that there are significant=20 differences (but also overlaps). > 2 -- People coming from the IoT world first have to learn the OAuth > terminology. I teach this stuff, and I can tell you, that terminology > is suboptimal for learners. When they are done with this, see 1. They will have to learn some authorization terminology, so why not use=20 an existing one instead of making up yet another? > Choosing terms that are adapted to what we are actually trying to do ha= s > none of these problems, and it also allows to choose terms that are eas= y > to remember and have the right connotations***). Instead we have the much bigger problem that we force people to learn=20 yet another set of (totally new) terminology which will lead to even=20 more confusion when the web world needs to interact with the IoT world=20 and the terminology is not aligned. We don't want to create a silo of IoT authorization terminology do we? /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 --------------ms010703040800010802000700 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 DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE1MDkzMDA5MDkxNFowLwYJKoZI hvcNAQkEMSIEIJkK0TIVcqdPozvtoWm+qkeoArO0waaoraiX29uZf/cAMGwGCSqGSIb3DQEJ DzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0D AgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgaUGCSsGAQQB gjcQBDGBlzCBlDCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzAp BgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0 YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgMMhpgwgacG CyqGSIb3DQEJEAILMYGXoIGUMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20g THRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG A1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EC AwyGmDANBgkqhkiG9w0BAQEFAASCAQCw3dUt+ZKF4oYQGbhXZgF6d870mnmIB9IAXRRIsmlX nuhXvPecja9Xa10vAu1m2voJ2lERyx66rUO55h4XaZgcXMfbvByH5/HArK4aXW0dQdWvuESq XXfg3gGrDvrcDMqls1AQA3L/u79AM0oMLFYLLtSJIo5J7XjijeQszTzR20/OxA8ERTr/hl3N CWT+1lM7qyet8mrfEniVhZCHbR96ZRQM8Dda3xzYwAOP/PePwp/adZH7NG66dQpXl/o3ijXm hd6wORgSRwkzdf19tH0Q6H/4oepAQyrgHCTebRGqaEIqJiEgiayorq+IaU+pEaBmcic2HUZk ZrDOj2ZrkW98AAAAAAAA --------------ms010703040800010802000700-- From nobody Wed Sep 30 02:22: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 AC41F1B2D46 for ; Wed, 30 Sep 2015 02:21:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.15 X-Spam-Level: ** X-Spam-Status: No, score=2.15 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HELO_EQ_DE=0.35, MANGLED_WHLSAL=2.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 G42PhyAQZraj for ; Wed, 30 Sep 2015 02:21:59 -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 9398F1B2D45 for ; Wed, 30 Sep 2015 02:21:58 -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 t8U9LtcS002733; Wed, 30 Sep 2015 11:21:55 +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 3nQsXz2vxGz4nmt; Wed, 30 Sep 2015 11:21:55 +0200 (CEST) Message-ID: <560BA9B2.4080102@tzi.org> Date: Wed, 30 Sep 2015 11:21:54 +0200 From: Carsten Bormann User-Agent: Postbox 4.0.5 (Macintosh/20150923) MIME-Version: 1.0 To: Ludwig Seitz References: <560A9F74.6050004@tzi.de> <560AACEA.3090102@tzi.org> <06C1350B-F3BA-4783-8E03-432059567D7E@gmail.com> <560B9B66.9030302@tzi.org> <560BA6BA.6090805@sics.se> In-Reply-To: <560BA6BA.6090805@sics.se> 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] Terminology (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: Wed, 30 Sep 2015 09:21:59 -0000 > How is that fundamentally different from the OAuth AS? They are not if you squint a lot. > I think you underestimate the OAuth people. I am sure those > participating in the ACE work are well aware that there are significant > differences (but also overlaps). I'm not always so sure about the level of awareness here. But, more importantly, we are not writing our documents so that just the elite IETFers can make use of them. >> 2 -- People coming from the IoT world first have to learn the OAuth >> terminology. I teach this stuff, and I can tell you, that terminology >> is suboptimal for learners. When they are done with this, see 1. > > They will have to learn some authorization terminology, so why not use > an existing one instead of making up yet another? I thought I answered that right above. (And it's not like the Actors draft has whole-sale made up new terminology; it still uses C and RS, and ROP vs. RO could be harmonized again without too much of a loss; that change was just a reaction to the observation that the term "owner" is misleading. Only where more differentiation is needed, is it worth to make specific terms.) >> Choosing terms that are adapted to what we are actually trying to do has >> none of these problems, and it also allows to choose terms that are easy >> to remember and have the right connotations***). > > Instead we have the much bigger problem that we force people to learn > yet another set of (totally new) terminology which will lead to even > more confusion when the web world needs to interact with the IoT world > and the terminology is not aligned. As long as you think the OAuth terms actually fit the actors, you can make this argument. But that also just serves to underline my argument number 1; you are letting those terms guide you to not take note of the differences. > We don't want to create a silo of IoT authorization terminology do we? I don't think a couple of better terms will silo ACE. Gr眉脽e, Carsten From nobody Wed Sep 30 02:23: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 857261B2D4E for ; Wed, 30 Sep 2015 02:23:51 -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 2I-A9r4Do0Yv for ; Wed, 30 Sep 2015 02:23:49 -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 4BAF51B2D4D for ; Wed, 30 Sep 2015 02:23:49 -0700 (PDT) X-AuditID: c1b4fb25-f79a26d00000149a-62-560baa2382f8 Received: from ESESSHC005.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id E0.4D.05274.32AAB065; Wed, 30 Sep 2015 11:23:47 +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; Wed, 30 Sep 2015 11:23:46 +0200 From: =?utf-8?B?R8O2cmFuIFNlbGFuZGVy?= To: Carsten Bormann , "ace@ietf.org" Thread-Topic: [Ace] I-D Action: draft-ietf-ace-actors-01.txt Thread-Index: AQHQ+rdmEIjxTgYNzEyYvEGszNnsjJ5TXjgAgAFvv4A= Date: Wed, 30 Sep 2015 09:23:45 +0000 Message-ID: References: <20150929130430.27260.42.idtracker@ietfa.amsl.com> <560A91C2.4030102@tzi.org> In-Reply-To: <560A91C2.4030102@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: <73F3232013CF3244B5040F212001DDBF@ericsson.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpikeLIzCtJLcpLzFFi42KZGfG3Rld5FXeYwf9mMYvv33qYLY5Mucvq wOSxZMlPJo9pizIDmKK4bFJSczLLUov07RK4Mlase8xUcEq24sPHc0wNjC9kuhg5OSQETCQm 7TnHBmGLSVy4tx7I5uIQEjjKKHHr6iYoZwmjxPtTMxlBqtgEXCQeNDxiArFFBBwlFl1eyw5i CwtYS7Rfm84KEbeReD1rPwuEbSUx9+4PoEEcHCwCqhJLGxRAwrwCFhIzTl4FGyMkEC3xe+oe sCM4BdQlXl5+D9bKCHTQ91NrwGqYBcQlbj2ZzwRxqIDEkj3nmSFsUYmXj/+BrRUV0JNYeb0J 6hkliRXbLzGCrGUW0JRYv0sfYoy1xLGlK6FGKkpM6X7IDnGOoMTJmU9YJjCKz0KybRZC9ywk 3bOQdM9C0r2AkXUVo2hxanFSbrqRsV5qUWZycXF+nl5easkmRmCkHdzyW3UH4+U3jocYBTgY lXh4FZy4w4RYE8uKK3MPMUpzsCiJ8zYzPQgVEkhPLEnNTk0tSC2KLyrNSS0+xMjEwSnVwMhm +CrqzFtzhX+XP87OKJbl2Wd1946NwqFCwXcx78xaPQ/PlHBp/rX1+SGdUynlfr2+jBO8X9nM ZPS7pj6X5Z5X8P9LGy70LOeVl3s1g2sJn14D38rrir9FH3WrN040Ob4ww5XxbFeYnfK9D490 dJa8DbbTz9fZz6x8p/L9hYL/MgsnHbY3rlViKc5INNRiLipOBACvyI66lQIAAA== Archived-At: Subject: Re: [Ace] I-D Action: draft-ietf-ace-actors-01.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, 30 Sep 2015 09:23:51 -0000 SGkgQ2Fyc3RlbiwNCg0KQ29taW5nIGJhY2sgdG8geW91ciBwcm9wb3NlZCBhZ2VuZGEgaXRlbS4N Cg0KT24gMjAxNS0wOS0yOSAxNToyNywgIkNhcnN0ZW4gQm9ybWFubiIgPGNhYm9AdHppLm9yZz4g d3JvdGU6DQoNCj4NCj4gICAgLS0gbWFpbnRhaW4gYSBjbGVhciBzZXBhcmF0aW9uIGJldHdlZW4g QWN0b3JzIGFuZCBPQXV0aCB0ZXJtaW5vbG9neQ0KPg0KPkluIEhhd2FpaSwgdGhlIGluLXJvb20g cm91Z2ggY29uc2Vuc3VzIHdhcyB0byByZXBsYWNlIHNvbWUgb2YgdGhlIEFjdG9ycw0KPnRlcm1z IHdpdGggbW9yZSBvciBsZXNzIGVxdWl2YWxlbnQgT0F1dGggdGVybXMsIHdoaWNoIGhhcyBjb25m dXNlZA0KPnJldmlld2Vycy4gIFdpdGggcHJvcG9zYWxzIG9uIHRoZSB0YWJsZSB0aGF0IHVzZSBP QXV0aCBvbiB0aGUNCj5sZXNzLWNvbnN0cmFpbmVkIGxldmVsLCB0aGlzIHN0YXJ0cyB0byBiZSBl dmVuIG1vcmUgY29uZnVzaW5nLiAgV2UgY2FuDQo+ZGlzY3VzcyB0aGUgbmVlZCBmb3IgdGhpcyBz ZXBhcmF0aW9uIHNvbWUgbW9yZSB0b21vcnJvdy4NCg0KDQpUaGVyZSBhcmUgbWFueSB0aGluZ3Mg Y29uZnVzaW5nIGhlcmUuDQoNCjEuIEkgdGhvdWdodCB3ZSB3ZXJlIGRvbmUgd2l0aCB0ZXJtaW5v bG9neSBkaXNjdXNzaW9uIHNpbmNlIDYgbW9udGhzIGFnby4NCg0KMi4gVGhlIGRpc2N1c3Npb24g d2FzIGluIERhbGxhcyBub3QgaW4gSGF3YWlpLiBUaGUgY3VycmVudCB0ZXJtaW5vbG9neSBoYXMN CmJlZW4gaW4gdXNlIHNpbmNlIDIwMTUtMDMtMjUNCmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5v cmcvZG9jL2RyYWZ0LWdlcmRlcy1hY2UtYWN0b3JzLzA0DQoNCkZvciB0aG9zZSB3aG8gd2VyZSBu b3QgcHJlc2VudCBvciBkb27igJl0IHRoZSBkaXNjdXNzaW9uOiBUaGlzIGlzIGFib3V0DQpuYW1l cyBvZiBub2RlcyBpbiB0aGUgYXJjaGl0ZWN0dXJlLiBUaGUgaXNzdWUgd2FzIGRpc2N1c3NlZCBh dCBsZW5ndGgNCmR1cmluZyB0aGUgZmlyc3QgdGhyZWUgbW9udGhzIHRoaXMgeWVhciBhbmQgcmVz b2x2ZWQgaW4gdGhlIERhbGxhcyBGMkYNCm1lZXRpbmcuIEhlcmUgYXJlIHRoZSBtaW51dGVzOg0K DQpodHRwczovL3d3dy5pZXRmLm9yZy9wcm9jZWVkaW5ncy85Mi9taW51dGVzL21pbnV0ZXMtOTIt YWNlDQoNCiogQWN0b3JzIChDYXJzdGVuIEJvcm1hbm4sIDIwIG1pbnMpDQotIFRoZXJlIHdhcyBw cmVmZXJlbmNlIHRvIHJldXNlIE9BdXRoIHRlcm1pbm9sb2dpZXMgKGUuZy4gUmVzb3VyY2UgU2Vy dmVyLA0KQXV0aG9yaXphdGlvbiBTZXJ2ZXIpLg0KLSBBY3Rpb246IERlc2lnbiB0ZWFtIGlzIHJl cXVlc3RlZCB0byBtZXJnZSBQcm9ibGVtIERlc2NyaXB0aW9uIGRyYWZ0IGFuZA0KQWN0b3JzIGRy YWZ0LCBhbmQgcHJvdmlkZSBhIGNvbWJpbmVkIGRyYWZ0Lg0KDQoNCg0KMy4gVGhlcmUgaGFzIG9u bHkgYmVlbiBvbmUgc3Vic3RhbnRpYWwgcmV2aWV3IGNvbW1lbnQgb24gdGhpcw0KYW5kIEkgY29u c2lkZXIgdGhhdCBjb21tZW50IHJlc29sdmVkIHdpdGggbm8gY2hhbmdlIGluIGN1cnJlbnQgdGVy bWlub2xvZ3kuDQoNCmh0dHA6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9hY2UvY3Vy cmVudC9tc2cwMTI0Mi5odG1sDQpodHRwOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIv YWNlL2N1cnJlbnQvbXNnMDEyNDMuaHRtbA0KaHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hp dmUvd2ViL2FjZS9jdXJyZW50L21zZzAxMjQ0Lmh0bWwNCmh0dHA6Ly93d3cuaWV0Zi5vcmcvbWFp bC1hcmNoaXZlL3dlYi9hY2UvY3VycmVudC9tc2cwMTI0NS5odG1sDQpodHRwOi8vd3d3LmlldGYu b3JnL21haWwtYXJjaGl2ZS93ZWIvYWNlL2N1cnJlbnQvbXNnMDEyNDYuaHRtbA0KDQoNCjQuIEZy b20gdGhlIHJldmlld3Mgb2YgdGhlIEFjdG9ycyBkcmFmdCB0aGVyZSBpcyBubyBzdXBwb3J0IHRv ICJtYWludGFpbiBhDQpjbGVhciBzZXBhcmF0aW9uIGJldHdlZW4gQWN0b3JzIGFuZCBPQXV0aCB0 ZXJtaW5vbG9neeKAnS4gVGhpcyBpcyBtYXliZSBhDQpwcm9ibGVtIHdpdGggc29tZSBzb2x1dGlv biBwcm9wb3NhbCwgc3VjaCBhcyBEQ0FGLCBidXQgeW91IGFyZSBmcmVlIHRvDQptYWtlIHRoYXQg c2VwYXJhdGlvbiBjbGVhciBieSBzZWxlY3Rpbmcgb3duIHRlcm1zIGluIHlvdXIgcHJvcG9zYWwu IElmIHlvdQ0KbmVlZCB0by4gWW91IGNhbiBhbHdheXMgbWFrZSB0aGUgZGlzdGluY3Rpb24gRENB RiBDbGllbnQgdnMgT0F1dGggQ2xpZW50DQpldGMuIE5vdGUgdGhhdCB0aGlzIGtpbmQgb2YgY29u ZnVzaW9uIGlzIGFscmVhZHkgcHJlc2VudCBzaW5jZSBEQ0FGIFNlcnZlcg0KbWF5IGJlIENvQVAg Q2xpZW50Lg0KDQoNClRoZXJlIGlzIG5vIG5lZWQgdG8gY2hhbmdlIHRoZSB0ZXJtaW5vbG9neS4g SGF2aW5nIGFuIGFnZW5kYSBpdGVtIGZpeGluZw0KbmFtaW5nIGNvbmZsaWN0cyBpbiBwcmltYXJp bHkgRENBRiBpcyBub3QgYSBjb25jZXJuIG9mIHRoaXMgaW50ZXJpbS4NCg0KV2UgKmNvdWxkKiBt YWtlIGEgY2xlYW4gc2xhdGUgdGVybWlub2xvZ3ksIEkgcHJvcG9zZWQgdGhhdCBpbiBKYW51YXJ5 IG9yDQpGZWJydWFyeSwgYnV0IEkgdGhpbmsgdGhlIHRpbWUgaGFzIHBhc3NlZCBiZXlvbmQgYWxs IHJlYXNvbmFibGUgbGltaXRzIHRvDQpkbyB0aGF0IG5vdy4gQW5kIHlvdSBoYXZlIG5vdCBzdWJt aXR0ZWQgYW55IGlucHV0IGZvciB0aGF0IHR5cGUgb2YNCmRpc2N1c3Npb24gc28gSSBwcm9wb3Nl IHdlIGRyb3AgaXQuDQoNCg0KR8O2cmFuDQoNCg== From nobody Wed Sep 30 03:59: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 B309A1B5CFE for ; Wed, 30 Sep 2015 03:59:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.349 X-Spam-Level: X-Spam-Status: No, score=0.349 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, 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 e39MCjuka6-L for ; Wed, 30 Sep 2015 03:59:32 -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 0789C1B5CFD for ; Wed, 30 Sep 2015 03:59:31 -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 t8UAxR10016362; Wed, 30 Sep 2015 12:59:27 +0200 (CEST) Received: from [IPv6:2001:638:708:30da:98b5:c05d:9032:4f6e] (unknown [IPv6:2001:638:708:30da:98b5:c05d:9032:4f6e]) (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 3nQvjW0V78z4pTX; Wed, 30 Sep 2015 12:59:27 +0200 (CEST) To: Ludwig Seitz , ace@ietf.org References: <560A9F74.6050004@tzi.de> <560AACEA.3090102@tzi.org> <06C1350B-F3BA-4783-8E03-432059567D7E@gmail.com> <560B9B66.9030302@tzi.org> <560BA6BA.6090805@sics.se> From: Stefanie Gerdes X-Enigmail-Draft-Status: N1110 Message-ID: <560BC08E.5090502@tzi.de> Date: Wed, 30 Sep 2015 12:59:26 +0200 User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <560BA6BA.6090805@sics.se> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Ace] Terminology (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: Wed, 30 Sep 2015 10:59:33 -0000 Hi Ludwig, On 09/30/2015 11:09 AM, Ludwig Seitz wrote: > On 2015-09-30 10:20, Carsten Bormann wrote: >> (Pulling the discussion out of a private exchange to the mailing list.) >> >>> I don抰 think it is about the definitions not being clear. It is just >>> the >>> names of the nodes, where in the current draft 5 out of 6 terms are >>> imported from the analogous setting in OAuth/UMA and the 6th, CAS, is >>> coined by Carsten. >> >> The definitions in the current WG Actors draft are clear enough for me. >> They are just using terms that mean something different in OAuth. >> >> RFC 6749 says: >> >> authorization server >> The server issuing access tokens to the client after successfully >> authenticating the resource owner and obtaining authorization. >> >> Nope, that's not at all the AS in the Actors draft. >> > > I believe you are making an academic distinction here. Of course there > are differences between how the AS is used in OAuth and how the > different proposals use it in ACE, but the similarities are still quite > striking. > > 1. The ACE AS issues access tokens to the client (via the CAS if there > is one). > > 2. The ACE AS at some point in time will authenticate the resource > owner, when he/she configures the authorization policies that govern how > authorization for that resource can be obtained. > > How is that fundamentally different from the OAuth AS? First of all, we have an authorization manager, i.e. a less-constrained device, that is responsible for the client (what is called CAS in the terminology). That is different from the OAuth model where there is no such actor. If we cling to the OAuth terminology, we are not even allowed to call the Server's authorization manager SAS. It is called AS. That makes things very awkward and incomprehensible. The constrained devices are not capable of managing complex authentication and authorization tasks on their own. They need their authorization managers for that. Owners will not necessarily be present at the time of access. Therefore, the authorization managers will need to represent the owner, manage their authorization policies and security associations, and generate simplified authentication and authorization information that the constrained devices can digest. AMs therefore are the link between the constrained and the less constrained world. I think this is different from what an OAuth authorization server does (We don't call a cow a sheep only because it also has four legs). Authorization Managers can be integrated with OAuth Authorization Servers. An example for that can be found in draft-gerdes-ace-dcaf-examples [1]. > > Also OAuth has usecases where the AS is used in a way that is even more > similar to the ACE proposals (cf. the client credentials grant). > >> I have not yet heard a convincing reason why appropriating terms from a >> different domain is helping us here. What does this do? >> >> 1 -- People coming from the OAuth world will feel at home immediately. >> But that is a treacherous comfort: They'll expect things to be the same >> in the IoT world. They aren't.**) IoT authorization is almost, but not >> entirely, unlike Browser Web authorization. > > I think you underestimate the OAuth people. I am sure those > participating in the ACE work are well aware that there are significant > differences (but also overlaps). > >> 2 -- People coming from the IoT world first have to learn the OAuth >> terminology. I teach this stuff, and I can tell you, that terminology >> is suboptimal for learners. When they are done with this, see 1. > > They will have to learn some authorization terminology, so why not use > an existing one instead of making up yet another? > >> Choosing terms that are adapted to what we are actually trying to do has >> none of these problems, and it also allows to choose terms that are easy >> to remember and have the right connotations***). > > Instead we have the much bigger problem that we force people to learn > yet another set of (totally new) terminology which will lead to even > more confusion when the web world needs to interact with the IoT world > and the terminology is not aligned. I'd rather have people learn a new terminology and really understand what it means. As we have seen, people are already confused by the CAS-AS-RqP-RO-Terminology. This is the chance to use a terminology that is easier to digest. Best regards, Steffi [1] https://tools.ietf.org/pdf/draft-gerdes-ace-dcaf-examples-00.pdf From nobody Wed Sep 30 03:59: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 A4F5D1B5D09 for ; Wed, 30 Sep 2015 03:59:49 -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 H4JJkcBxDiFL for ; Wed, 30 Sep 2015 03:59:48 -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 814011B5D0A for ; Wed, 30 Sep 2015 03:59: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 [IPv6:2001:638:708:30c9::b]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id t8UAxiWw017012; Wed, 30 Sep 2015 12:59:44 +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 3nQvjr0B0zz4pTk; Wed, 30 Sep 2015 12:59:44 +0200 (CEST) Message-ID: <560BC09E.4090209@tzi.org> Date: Wed, 30 Sep 2015 12:59:42 +0200 From: Carsten Bormann User-Agent: Postbox 4.0.5 (Macintosh/20150923) 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: "ace@ietf.org" Subject: [Ace] Interim 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: Wed, 30 Sep 2015 10:59:49 -0000 Hi Goeran, I'll leave the process issues to the chairs. As far as I can see, there is no official agenda yet for the Interim, but we said that we wanted to get the informational documents off the table. So I would expect the agenda to be approximately: -- Chairs' introduction -- "ACE use cases", Ludwig Seitz, Stefanie Gerdes, Goran Selander, Mehdi Mani, Sandeep Kumar, 2015-09-23, -- "An architecture for authorization in constrained environments", Stefanie Gerdes, Ludwig Seitz, Goran Selander, Carsten Bormann, 2015-09-29, -- AOB For both documents, I think we should discuss: -- remaining issues (identify and, if possible, resolve on the spot) -- who is going to do the work to resolve them, and when -- do we need any additional review Do we have anything else on the agenda? I was not proposing anything else. I was just trying to get the discussion going again on the list on one of the remaining issues. Gr眉脽e, Carsten From nobody Wed Sep 30 04:15: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 9E9B51B5D34 for ; Wed, 30 Sep 2015 04:15: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 v3PvKmG3-rRj for ; Wed, 30 Sep 2015 04:15: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 206E21B5D3A for ; Wed, 30 Sep 2015 04:15:19 -0700 (PDT) X-AuditID: c1b4fb25-f79a26d00000149a-39-560bc446d803 Received: from ESESSHC004.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 6A.C4.05274.644CB065; Wed, 30 Sep 2015 13:15:18 +0200 (CEST) Received: from ESESSMB303.ericsson.se ([169.254.3.186]) by ESESSHC004.ericsson.se ([153.88.183.30]) with mapi id 14.03.0248.002; Wed, 30 Sep 2015 13:15:17 +0200 From: =?utf-8?B?R8O2cmFuIFNlbGFuZGVy?= To: Carsten Bormann , "ace@ietf.org" Thread-Topic: Interim agenda Thread-Index: AQHQ+28emeJBdr+XFUiDIVmyng/70p5U67GA Date: Wed, 30 Sep 2015 11:15:17 +0000 Message-ID: References: <560BC09E.4090209@tzi.org> In-Reply-To: <560BC09E.4090209@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: <5CF899F74B38064786FCAF70D537F45D@ericsson.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpmkeLIzCtJLcpLzFFi42KZGfG3RtftCHeYwazvEhbfv/UwWxyZcpfV gcljyZKfTB7TFmUGMEVx2aSk5mSWpRbp2yVwZSz5eou5YJtAxZwbrSwNjA0CXYycHBICJhIr n3xnhrDFJC7cW8/WxcjFISRwlFHi0tqNTBDOEkaJf79msoBUsQm4SDxoeMQEYosIOEosuryW HcQWFpCW+PptDitEXEZi5boOdgjbSGL/7a9gvSwCqhIrp88Ei/MKWEjs+PmbDcQWElCTuDV/ P1gNp4C6xITvE8DmMwJd9P3UGjCbWUBc4taT+UwQlwpILNlzHupqUYmXj/+B7RUV0JNYeb2J DSKuJLH28HagmRxAvZoS63fpQ4yxlvi2ZA8jhK0oMaX7IdQ5ghInZz5hmcAoPgvJtlkI3bOQ dM9C0j0LSfcCRtZVjKLFqcVJuelGxnqpRZnJxcX5eXp5qSWbGIGxdnDLb9UdjJffOB5iFOBg VOLhVXDiDhNiTSwrrsw9xCjNwaIkztvM9CBUSCA9sSQ1OzW1ILUovqg0J7X4ECMTB6dUA2Mj /3nx8w6W3bVb1ymEy+vmPvzeEl3hk33V7BmTW9aSpe+nJL5sfKAnus5rSpLMqyNZizf96pn2 7eOfu88VW+LFdIMXqb0+ZsPV9mUVt8OtOvPvrqpyt2f9edf92e1JcbX7xYZOm7K3T9QlqwvL XvRcXL+sNuXVaeO7UvWVac77FF98eFa/+44SS3FGoqEWc1FxIgAjN7WplgIAAA== Archived-At: Subject: Re: [Ace] Interim 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: Wed, 30 Sep 2015 11:15:26 -0000 SGkgQ2Fyc3RlbiwNCg0KSXQgaXMgbm90IHVwIHRvIG1lIHRvIGFwcHJvdmUgdGhlIGFnZW5kYS4g SSBqdXN0IGZpbmQgaXQgcmVtYXJrYWJsZSB0aGF0DQppbiB0aGUgcHJvY2VzcyBvZiBoYW5kbGlu ZyByZXZpZXcgaW5wdXRzIHRvIHRoZSBhY3RvcnMgZHJhZnQsIGZvY3VzIGlzDQp0YWtlbiBhd2F5 IGZyb20gdGhlIGFjdHVhbCByZXZpZXdzLg0KDQpPbmUgY29tbWVudCBpbmxpbmU6DQoNCk9uIDIw MTUtMDktMzAgMTI6NTksICJDYXJzdGVuIEJvcm1hbm4iIDxjYWJvQHR6aS5vcmc+IHdyb3RlOg0K DQo+SGkgR29lcmFuLA0KPg0KPkknbGwgbGVhdmUgdGhlIHByb2Nlc3MgaXNzdWVzIHRvIHRoZSBj aGFpcnMuDQo+DQo+QXMgZmFyIGFzIEkgY2FuIHNlZSwgdGhlcmUgaXMgbm8gb2ZmaWNpYWwgYWdl bmRhIHlldCBmb3IgdGhlIEludGVyaW0sDQo+YnV0IHdlIHNhaWQgdGhhdCB3ZSB3YW50ZWQgdG8g Z2V0IHRoZSBpbmZvcm1hdGlvbmFsIGRvY3VtZW50cyBvZmYgdGhlDQo+dGFibGUuDQo+DQo+U28g SSB3b3VsZCBleHBlY3QgdGhlIGFnZW5kYSB0byBiZSBhcHByb3hpbWF0ZWx5Og0KPg0KPi0tIENo YWlycycgaW50cm9kdWN0aW9uDQo+DQo+LS0gIkFDRSB1c2UgY2FzZXMiLCBMdWR3aWcgU2VpdHos IFN0ZWZhbmllIEdlcmRlcywgR29yYW4gU2VsYW5kZXIsIE1laGRpDQo+ICBNYW5pLCBTYW5kZWVw IEt1bWFyLCAyMDE1LTA5LTIzLCA8ZHJhZnQtaWV0Zi1hY2UtdXNlY2FzZXMtMDYudHh0Pg0KPg0K Pi0tICJBbiBhcmNoaXRlY3R1cmUgZm9yIGF1dGhvcml6YXRpb24gaW4gY29uc3RyYWluZWQgZW52 aXJvbm1lbnRzIiwNCj4gIFN0ZWZhbmllIEdlcmRlcywgTHVkd2lnIFNlaXR6LCBHb3JhbiBTZWxh bmRlciwgQ2Fyc3RlbiBCb3JtYW5uLA0KPiAgMjAxNS0wOS0yOSwgPGRyYWZ0LWlldGYtYWNlLWFj dG9ycy0wMS50eHQ+DQo+DQo+LS0gQU9CDQo+DQo+Rm9yIGJvdGggZG9jdW1lbnRzLCBJIHRoaW5r IHdlIHNob3VsZCBkaXNjdXNzOg0KPi0tIHJlbWFpbmluZyBpc3N1ZXMgKGlkZW50aWZ5IGFuZCwg aWYgcG9zc2libGUsIHJlc29sdmUgb24gdGhlIHNwb3QpDQoNCkRvIHdlIGhhdmUgYSBsaXN0IG9m IHdoaWNoIHJldmlldyBjb21tZW50cyBhcmUgY292ZXJlZCBpbiAtMDEgYW5kIHdoaWNoDQphcmUg bm90PyBJIHRoaW5rIGNvbXBpbGluZyBzdWNoIGEgbGlzdCB3b3VsZCBiZSB3ZWxsIHNwZW50IHRp bWUgdW50aWwgdGhlDQptZWV0aW5nLg0KDQpHw7ZyYW4NCg0KPi0tIHdobyBpcyBnb2luZyB0byBk byB0aGUgd29yayB0byByZXNvbHZlIHRoZW0sIGFuZCB3aGVuDQo+LS0gZG8gd2UgbmVlZCBhbnkg YWRkaXRpb25hbCByZXZpZXcNCj4NCj5EbyB3ZSBoYXZlIGFueXRoaW5nIGVsc2Ugb24gdGhlIGFn ZW5kYT8gIEkgd2FzIG5vdCBwcm9wb3NpbmcgYW55dGhpbmcNCj5lbHNlLiAgSSB3YXMganVzdCB0 cnlpbmcgdG8gZ2V0IHRoZSBkaXNjdXNzaW9uIGdvaW5nIGFnYWluIG9uIHRoZSBsaXN0DQo+b24g b25lIG9mIHRoZSByZW1haW5pbmcgaXNzdWVzLg0KPg0KPkdyw7zDn2UsIENhcnN0ZW4NCg0K From nobody Wed Sep 30 04:19: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 64CB81B5D43 for ; Wed, 30 Sep 2015 04:19:51 -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 iv8jA9IVniXs for ; Wed, 30 Sep 2015 04:19: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 A8EC01B5D41 for ; Wed, 30 Sep 2015 04:19: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 [134.102.201.11]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id t8UBJiej003422; Wed, 30 Sep 2015 13:19:44 +0200 (CEST) Received: from [IPv6:2001:638:708:30da:98b5:c05d:9032:4f6e] (unknown [IPv6:2001:638:708:30da:98b5:c05d:9032:4f6e]) (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 3nQw8w4d5Pz4pf0; Wed, 30 Sep 2015 13:19:44 +0200 (CEST) To: =?UTF-8?Q?G=c3=b6ran_Selander?= , Carsten Bormann , "ace@ietf.org" References: <20150929130430.27260.42.idtracker@ietfa.amsl.com> <560A91C2.4030102@tzi.org> From: Stefanie Gerdes X-Enigmail-Draft-Status: N1110 Message-ID: <560BC550.2040900@tzi.de> Date: Wed, 30 Sep 2015 13:19:44 +0200 User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Ace] I-D Action: draft-ietf-ace-actors-01.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, 30 Sep 2015 11:19:51 -0000 Hi G枚ran, maybe it helps to include Jim's comment from his review again: "* I find following the actor abbreviations to be difficult to follow. It would be easier if the names were reflective of each other. I am not sure if you are grabbing the names from a different world in which case this probably cannot be done. So it would be easier with C <--> R, CAS <--> RAS, CO <--> RO. Trying to figure out that RqP belongs on the C side of the world is somewhat confusing for a first time reader. Similarly the fact that AS has a prefix for the C side but not the R side is difficult. As things stand one cannot discuss an AS as a standalone entity which is a generic CAS and RAS item and contrast it with the differences from being on one side or the other." I take this comment serious and would like us to resolve this issue. I don't know why you think that we need a different terminology for DCAF. And I don't know why you think that a DCAF client can be a CoAP server. The DCAF terminology is not the issue here. Giving a false color to things is not really useful. Steffi On 09/30/2015 11:23 AM, G枚ran Selander wrote: > Hi Carsten, > > Coming back to your proposed agenda item. > > On 2015-09-29 15:27, "Carsten Bormann" wrote: > >> >> -- maintain a clear separation between Actors and OAuth terminology >> >> In Hawaii, the in-room rough consensus was to replace some of the Actors >> terms with more or less equivalent OAuth terms, which has confused >> reviewers. With proposals on the table that use OAuth on the >> less-constrained level, this starts to be even more confusing. We can >> discuss the need for this separation some more tomorrow. > > > There are many things confusing here. > > 1. I thought we were done with terminology discussion since 6 months ago. > > 2. The discussion was in Dallas not in Hawaii. The current terminology has > been in use since 2015-03-25 > https://datatracker.ietf.org/doc/draft-gerdes-ace-actors/04 > > For those who were not present or don鈥檛 the discussion: This is about > names of nodes in the architecture. The issue was discussed at length > during the first three months this year and resolved in the Dallas F2F > meeting. Here are the minutes: > > https://www.ietf.org/proceedings/92/minutes/minutes-92-ace > > * Actors (Carsten Bormann, 20 mins) > - There was preference to reuse OAuth terminologies (e.g. Resource Server, > Authorization Server). > - Action: Design team is requested to merge Problem Description draft and > Actors draft, and provide a combined draft. > > > > 3. There has only been one substantial review comment on this > and I consider that comment resolved with no change in current terminology. > > http://www.ietf.org/mail-archive/web/ace/current/msg01242.html > http://www.ietf.org/mail-archive/web/ace/current/msg01243.html > http://www.ietf.org/mail-archive/web/ace/current/msg01244.html > http://www.ietf.org/mail-archive/web/ace/current/msg01245.html > http://www.ietf.org/mail-archive/web/ace/current/msg01246.html > > > 4. From the reviews of the Actors draft there is no support to "maintain a > clear separation between Actors and OAuth terminology鈥. This is maybe a > problem with some solution proposal, such as DCAF, but you are free to > make that separation clear by selecting own terms in your proposal. If you > need to. You can always make the distinction DCAF Client vs OAuth Client > etc. Note that this kind of confusion is already present since DCAF Server > may be CoAP Client. > > > There is no need to change the terminology. Having an agenda item fixing > naming conflicts in primarily DCAF is not a concern of this interim. > > We *could* make a clean slate terminology, I proposed that in January or > February, but I think the time has passed beyond all reasonable limits to > do that now. And you have not submitted any input for that type of > discussion so I propose we drop it. > > > G枚ran > > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace > > -- 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 Wed Sep 30 04: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 7789A1B5D46 for ; Wed, 30 Sep 2015 04:22:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_8BIT_HEADER=0.3, 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 PAVufFYRoyUN for ; Wed, 30 Sep 2015 04:22:44 -0700 (PDT) Received: from out4133-146.mail.aliyun.com (out4133-146.mail.aliyun.com [42.120.133.146]) by ietfa.amsl.com (Postfix) with ESMTP id A7CC21B5D44 for ; Wed, 30 Sep 2015 04:22:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alibaba-inc.com; s=default; t=1443612162; h=Date:Subject:From:To:Message-ID:Mime-version:Content-type; bh=ps6zMkh778eMrvWQXNh+R0428rwWFlWa0y/3/gPyMLY=; b=VcIdb6wvTzwThkHrY+qK+fvcOF07hAmtkyHRZDtL1ns0bxjde8b7pzMo7yGxP8sh0x868hjjAVBMrYDcTtT8LU1SG1d1s7yG4M3DRNQwsstIaXplZXwHG+OuNFwgksBAQjx+D8KS2gOQeoq+2jH9xHh6WWhM3+TY55Sodju2n3k= X-Alimail-AntiSpam: AC=PASS; BC=-1|-1; BR=01201311R201e4; FP=0|-1|-1|-1|0|-1|-1|-1; HT=e02c03284; MF=kepeng.lkp@alibaba-inc.com; NM=1; PH=DS; RN=3; SR=0; Received: from 10.1.153.174(mailfrom:kepeng.lkp@alibaba-inc.com ip:42.120.74.156) by smtp.aliyun-inc.com(127.0.0.1); Wed, 30 Sep 2015 19:22:37 +0800 User-Agent: Microsoft-MacOutlook/14.4.8.150116 Date: Wed, 30 Sep 2015 19:22:31 +0800 From: "Kepeng Li" To: Carsten Bormann , =?ISO-8859-1?B?R/ZyYW4=?= Selander Message-ID: Thread-Topic: [Ace] Interim agenda References: <560BC09E.4090209@tzi.org> In-Reply-To: <560BC09E.4090209@tzi.org> 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] Interim 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: Wed, 30 Sep 2015 11:22:45 -0000 >As far as I can see, there is no official agenda yet for the Interim In fact, I posted the agenda here: https://mailarchive.ietf.org/arch/msg/ace/2kvLOmVlrb8gcjX5chlwxOQUdcs The intial agenda is: 1. Re-charter; 2. Use cases; 3. Actors; 4. AOB.=20 It is a little bit simple, but hopefully it covers what we are going to talk about. Kind Regards Kepeng =E5=9C=A8 30/9/15 6:59 pm=EF=BC=8C "Carsten Bormann" =E5=86=99=E5=85=A5: >Hi Goeran, > >I'll leave the process issues to the chairs. > >As far as I can see, there is no official agenda yet for the Interim, >but we said that we wanted to get the informational documents off the >table. > >So I would expect the agenda to be approximately: > >-- Chairs' introduction > >-- "ACE use cases", Ludwig Seitz, Stefanie Gerdes, Goran Selander, Mehdi > Mani, Sandeep Kumar, 2015-09-23, > >-- "An architecture for authorization in constrained environments", > Stefanie Gerdes, Ludwig Seitz, Goran Selander, Carsten Bormann, > 2015-09-29, > >-- AOB > >For both documents, I think we should discuss: >-- remaining issues (identify and, if possible, resolve on the spot) >-- who is going to do the work to resolve them, and when >-- do we need any additional review > >Do we have anything else on the agenda? I was not proposing anything >else. I was just trying to get the discussion going again on the list >on one of the remaining issues. > >Gr=C3=BC=C3=9Fe, Carsten > >_______________________________________________ >Ace mailing list >Ace@ietf.org >https://www.ietf.org/mailman/listinfo/ace From nobody Wed Sep 30 04:31: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 9E7B61B5D67 for ; Wed, 30 Sep 2015 04:30:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.349 X-Spam-Level: X-Spam-Status: No, score=0.349 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, 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 AETvjgTQTEEN for ; Wed, 30 Sep 2015 04:30:59 -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 D03C61B5D6B for ; Wed, 30 Sep 2015 04:30:57 -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 t8UBUrYS003160; Wed, 30 Sep 2015 13:30:53 +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 3nQwPn40Mfz4q1Y; Wed, 30 Sep 2015 13:30:53 +0200 (CEST) Message-ID: <560BC7EC.9090106@tzi.org> Date: Wed, 30 Sep 2015 13:30:52 +0200 From: Carsten Bormann User-Agent: Postbox 4.0.5 (Macintosh/20150923) MIME-Version: 1.0 To: Stefanie Gerdes References: <20150929130430.27260.42.idtracker@ietfa.amsl.com> <560A91C2.4030102@tzi.org> <560BC550.2040900@tzi.de> In-Reply-To: <560BC550.2040900@tzi.de> X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: =?UTF-8?B?R8O2cmFuIFNlbGFuZGVy?= , "ace@ietf.org" Subject: Re: [Ace] I-D Action: draft-ietf-ace-actors-01.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, 30 Sep 2015 11:30:59 -0000 Stefanie Gerdes wrote: > Hi G枚ran, > > maybe it helps to include Jim's comment from his review again: > > "* I find following the actor abbreviations to be difficult to follow. > It would be easier if the names were reflective of each other. I am not > sure if you are grabbing the names from a different world in which case > this probably cannot be done. So it would be easier with C <--> R, > CAS <--> RAS, CO <--> RO. Trying to figure out that RqP belongs on the > C side of the world is somewhat confusing for a first time reader. > Similarly the fact that AS has a prefix for the C side but not > the R side is difficult. As things stand one cannot discuss an AS as a > standalone entity which is a generic CAS and RAS item and contrast it > with the differences from being on one side or the other." > > I take this comment serious and would like us to resolve this issue. > > I don't know why you think that we need a different terminology for > DCAF. And I don't know why you think that a DCAF client can be a CoAP > server. The DCAF terminology is not the issue here. Gute Antwort. > Giving a false color > to things is not really useful. Und der Ausrutscher. Sowas machen wir nicht! Gr眉脽e, Carsten From nobody Wed Sep 30 04:54: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 042C51A001B for ; Wed, 30 Sep 2015 04:54:13 -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 YulSKorcozsX for ; Wed, 30 Sep 2015 04:54:10 -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 C38EB1A0007 for ; Wed, 30 Sep 2015 04:54:09 -0700 (PDT) X-AuditID: c1b4fb3a-f79136d0000071e2-72-560bcd5fb7f4 Received: from ESESSHC009.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 7A.BD.29154.F5DCB065; Wed, 30 Sep 2015 13:54:07 +0200 (CEST) Received: from ESESSMB303.ericsson.se ([169.254.3.186]) by ESESSHC009.ericsson.se ([153.88.183.45]) with mapi id 14.03.0248.002; Wed, 30 Sep 2015 13:54:07 +0200 From: =?utf-8?B?R8O2cmFuIFNlbGFuZGVy?= To: Stefanie Gerdes , Carsten Bormann , "ace@ietf.org" Thread-Topic: [Ace] I-D Action: draft-ietf-ace-actors-01.txt Thread-Index: AQHQ+rdmEIjxTgYNzEyYvEGszNnsjJ5TXjgAgAFvv4D///7jAIAAKx8A Date: Wed, 30 Sep 2015 11:54:06 +0000 Message-ID: References: <20150929130430.27260.42.idtracker@ietfa.amsl.com> <560A91C2.4030102@tzi.org> <560BC550.2040900@tzi.de> In-Reply-To: <560BC550.2040900@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.148] Content-Type: text/plain; charset="utf-8" Content-ID: <1BC19C6D1100864FAD061A9954A1808C@ericsson.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupjkeLIzCtJLcpLzFFi42KZGfG3Rjf+LHeYwd2FRhbfv/UwWxyZcpfV YuPFu4wOzB5Llvxk8tj29iuzx7RFmQHMUVw2Kak5mWWpRfp2CVwZzz89YS1osay4f+ErUwPj CfMuRk4OCQETiRXHJ7FD2GISF+6tZ+ti5OIQEjjKKHFz2VpmCGcJo8TxuV+YQKrYBFwkHjQ8 ArNFBFIknn7rBLOFBawl2q9NZ4WI20i8nrWfBcJ2k7j85CJYnEVAVWLHi99sIDavgIVEx+VO drgFW84/ZARJcAqoSXz+2ArWwAh00vdTa8AWMAuIS9x6Mp8J4lQBiSV7zjND2KISLx//A6sX FdCTWHm9iQ0iriTRuOQJUJwDqFdTYv0ufYgx1hJLjp9nhbAVJaZ0P2SHuEdQ4uTMJywTGMVn Idk2C6F7FpLuWUi6ZyHpXsDIuopRtDi1uDg33chIL7UoM7m4OD9PLy+1ZBMjMAIPbvlttYPx 4HPHQ4wCHIxKPLwKTtxhQqyJZcWVuYcYpTlYlMR5m5kehAoJpCeWpGanphakFsUXleakFh9i ZOLglGpgNDh8ZNNqtw1lsRNDV75a/dDJ4d+khAld517G/qtf07JKPKTaz1P6u+j17DeTX9Q9 ij9f9rg1SNDCWVrEMHnP62/K97g6Jqy6wvJ826wlOz5+8rTiD9bjFlzcrtnktO2+l+13pZ9K 9nrcs3SOTm0sYubezXTzkODe66tfX5k1sf1j/7/7FT//rFZiKc5INNRiLipOBAC8foXmoQIA AA== Archived-At: Subject: Re: [Ace] I-D Action: draft-ietf-ace-actors-01.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, 30 Sep 2015 11:54:13 -0000 TGllYmUgU3RlZmZpIHVuZCBDYXJzdGVuLA0KDQoNCkkgZG9u4oCZdCBrbm93IGhvdyB3ZSBlbmQg dXAgbGlrZSB0aGlzIGFnYWluLiBJbmxpbmUuDQoNCk9uIDIwMTUtMDktMzAgMTM6MTksICJTdGVm YW5pZSBHZXJkZXMiIDxnZXJkZXNAdHppLmRlPiB3cm90ZToNCg0KPkhpIEfDtnJhbiwNCj4NCj5t YXliZSBpdCBoZWxwcyB0byBpbmNsdWRlIEppbSdzIGNvbW1lbnQgZnJvbSBoaXMgcmV2aWV3IGFn YWluOg0KPg0KPiIqICBJIGZpbmQgZm9sbG93aW5nIHRoZSBhY3RvciBhYmJyZXZpYXRpb25zIHRv IGJlIGRpZmZpY3VsdCB0byBmb2xsb3cuDQo+SXQgd291bGQgYmUgZWFzaWVyIGlmIHRoZSBuYW1l cyB3ZXJlIHJlZmxlY3RpdmUgb2YgZWFjaCBvdGhlci4gIEkgYW0gbm90DQo+c3VyZSBpZiB5b3Ug YXJlIGdyYWJiaW5nIHRoZSBuYW1lcyBmcm9tIGEgZGlmZmVyZW50IHdvcmxkIGluIHdoaWNoIGNh c2UNCj50aGlzIHByb2JhYmx5IGNhbm5vdCBiZSBkb25lLiBTbyBpdCB3b3VsZCBiZSBlYXNpZXIg d2l0aCAgIEMgPC0tPiBSLA0KPkNBUyA8LS0+IFJBUywgICBDTyA8LS0+IFJPLiBUcnlpbmcgdG8g ZmlndXJlIG91dCB0aGF0IFJxUCBiZWxvbmdzIG9uIHRoZQ0KPkMgc2lkZSBvZiB0aGUgd29ybGQg aXMgc29tZXdoYXQgY29uZnVzaW5nIGZvciBhIGZpcnN0IHRpbWUgcmVhZGVyLg0KPlNpbWlsYXJs eSB0aGUgZmFjdCB0aGF0IEFTIGhhcyBhIHByZWZpeCBmb3IgdGhlIEMgc2lkZSBidXQgbm90DQo+ dGhlIFIgc2lkZSBpcyBkaWZmaWN1bHQuICBBcyB0aGluZ3Mgc3RhbmQgb25lIGNhbm5vdCBkaXNj dXNzIGFuIEFTIGFzIGENCj5zdGFuZGFsb25lIGVudGl0eSB3aGljaCBpcyBhIGdlbmVyaWMgQ0FT IGFuZCBSQVMgaXRlbSBhbmQgY29udHJhc3QgaXQNCj53aXRoIHRoZSBkaWZmZXJlbmNlcyBmcm9t IGJlaW5nIG9uIG9uZSBzaWRlIG9yIHRoZSBvdGhlci4iDQo+DQo+SSB0YWtlIHRoaXMgY29tbWVu dCBzZXJpb3VzIGFuZCB3b3VsZCBsaWtlIHVzIHRvIHJlc29sdmUgdGhpcyBpc3N1ZS4NCg0KVGhp cyB3YXMgdGhlIGZpcnN0IGluIGEgc2VyaWVzIG9mIG1haWxzIHF1b3RlZCBiZWxvdyAodGhlIHF1 b3RlIGFib3ZlIGlzDQptaXNzaW5nIHRoaXMgcGFydDogIkkgYW0gbm90IHN1cmUgaWYgeW91IGFy ZSBncmFiYmluZyB0aGUgbmFtZXMgZnJvbSBhDQpkaWZmZXJlbnQgd29ybGQgaW4gd2hpY2ggY2Fz ZSB0aGlzIHByb2JhYmx5IGNhbm5vdCBiZSBkb25lLuKAnSkuDQpJIHRoaW5rIHdlIHNob3VsZCBh bHNvIGxvb2sgYXQgdGhlIGxhdGVyIG1haWxzIGluIHRoaXMgZXhjaGFuZ2UuDQoNCj4NCj5JIGRv bid0IGtub3cgd2h5IHlvdSB0aGluayB0aGF0IHdlIG5lZWQgYSBkaWZmZXJlbnQgdGVybWlub2xv Z3kgZm9yDQo+RENBRi4gQW5kIEkgZG9uJ3Qga25vdyB3aHkgeW91IHRoaW5rIHRoYXQgYSBEQ0FG IGNsaWVudCBjYW4gYmUgYSBDb0FQDQo+c2VydmVyLiBUaGUgRENBRiB0ZXJtaW5vbG9neSBpcyBu b3QgdGhlIGlzc3VlIGhlcmUuIEdpdmluZyBhIGZhbHNlIGNvbG9yDQo+dG8gdGhpbmdzIGlzIG5v dCByZWFsbHkgdXNlZnVsLg0KDQpJIHdyb3RlIERDQUYgc2VydmVyIGNhbiBiZSBDb0FQIGNsaWVu dC4gRm9yIGV4YW1wbGUsIGluIHRoaXMgY2FzZToNCg0KaHR0cHM6Ly90b29scy5pZXRmLm9yZy9o dG1sL2RyYWZ0LWdlcmRlcy1hY2UtZGNhZi1hdXRob3JpemUtMDMjc2VjdGlvbi0zLjMuDQoxDQoN CklmIHRoZSBzbGVlcHkgbm9kZSAoRENBRiBTZXJ2ZXIpIGluc3RlYWQgaW1wbGVtZW50cyBvbmx5 IENvQVAgY2xpZW50DQpmdW5jdGlvbmFsaXR5ICh3aGljaCB5b3UgdGF1Z2h0IG1lIHdhcyBhIHZh bGlkIGNhc2UgZm9yIHZlcnkgY29uc3RyYWluZWQNCm5vZGVzIGJhY2sgaW4gRmVicnVhcnktaXNo KSBhbmQgdXNlcyBQVVQgdG8gdGhlIGludGVybWVkaWFyeSBzZXJ2ZXIsDQppbnN0ZWFkIG9mIEdF VCByZXNwb25zZS4NCg0KDQpHw7ZyYW4NCg0KDQoNCj4NCj5TdGVmZmkNCj4NCj5PbiAwOS8zMC8y MDE1IDExOjIzIEFNLCBHw7ZyYW4gU2VsYW5kZXIgd3JvdGU6DQo+PiBIaSBDYXJzdGVuLA0KPj4g DQo+PiBDb21pbmcgYmFjayB0byB5b3VyIHByb3Bvc2VkIGFnZW5kYSBpdGVtLg0KPj4gDQo+PiBP biAyMDE1LTA5LTI5IDE1OjI3LCAiQ2Fyc3RlbiBCb3JtYW5uIiA8Y2Fib0B0emkub3JnPiB3cm90 ZToNCj4+IA0KPj4+DQo+Pj4gICAgLS0gbWFpbnRhaW4gYSBjbGVhciBzZXBhcmF0aW9uIGJldHdl ZW4gQWN0b3JzIGFuZCBPQXV0aCB0ZXJtaW5vbG9neQ0KPj4+DQo+Pj4gSW4gSGF3YWlpLCB0aGUg aW4tcm9vbSByb3VnaCBjb25zZW5zdXMgd2FzIHRvIHJlcGxhY2Ugc29tZSBvZiB0aGUNCj4+PkFj dG9ycw0KPj4+IHRlcm1zIHdpdGggbW9yZSBvciBsZXNzIGVxdWl2YWxlbnQgT0F1dGggdGVybXMs IHdoaWNoIGhhcyBjb25mdXNlZA0KPj4+IHJldmlld2Vycy4gIFdpdGggcHJvcG9zYWxzIG9uIHRo ZSB0YWJsZSB0aGF0IHVzZSBPQXV0aCBvbiB0aGUNCj4+PiBsZXNzLWNvbnN0cmFpbmVkIGxldmVs LCB0aGlzIHN0YXJ0cyB0byBiZSBldmVuIG1vcmUgY29uZnVzaW5nLiAgV2UgY2FuDQo+Pj4gZGlz Y3VzcyB0aGUgbmVlZCBmb3IgdGhpcyBzZXBhcmF0aW9uIHNvbWUgbW9yZSB0b21vcnJvdy4NCj4+ IA0KPj4gDQo+PiBUaGVyZSBhcmUgbWFueSB0aGluZ3MgY29uZnVzaW5nIGhlcmUuDQo+PiANCj4+ IDEuIEkgdGhvdWdodCB3ZSB3ZXJlIGRvbmUgd2l0aCB0ZXJtaW5vbG9neSBkaXNjdXNzaW9uIHNp bmNlIDYgbW9udGhzDQo+PmFnby4NCj4+IA0KPj4gMi4gVGhlIGRpc2N1c3Npb24gd2FzIGluIERh bGxhcyBub3QgaW4gSGF3YWlpLiBUaGUgY3VycmVudCB0ZXJtaW5vbG9neQ0KPj5oYXMNCj4+IGJl ZW4gaW4gdXNlIHNpbmNlIDIwMTUtMDMtMjUNCj4+IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5v cmcvZG9jL2RyYWZ0LWdlcmRlcy1hY2UtYWN0b3JzLzA0DQo+PiANCj4+IEZvciB0aG9zZSB3aG8g d2VyZSBub3QgcHJlc2VudCBvciBkb27igJl0IHRoZSBkaXNjdXNzaW9uOiBUaGlzIGlzIGFib3V0 DQo+PiBuYW1lcyBvZiBub2RlcyBpbiB0aGUgYXJjaGl0ZWN0dXJlLiBUaGUgaXNzdWUgd2FzIGRp c2N1c3NlZCBhdCBsZW5ndGgNCj4+IGR1cmluZyB0aGUgZmlyc3QgdGhyZWUgbW9udGhzIHRoaXMg eWVhciBhbmQgcmVzb2x2ZWQgaW4gdGhlIERhbGxhcyBGMkYNCj4+IG1lZXRpbmcuIEhlcmUgYXJl IHRoZSBtaW51dGVzOg0KPj4gDQo+PiBodHRwczovL3d3dy5pZXRmLm9yZy9wcm9jZWVkaW5ncy85 Mi9taW51dGVzL21pbnV0ZXMtOTItYWNlDQo+PiANCj4+ICogQWN0b3JzIChDYXJzdGVuIEJvcm1h bm4sIDIwIG1pbnMpDQo+PiAtIFRoZXJlIHdhcyBwcmVmZXJlbmNlIHRvIHJldXNlIE9BdXRoIHRl cm1pbm9sb2dpZXMgKGUuZy4gUmVzb3VyY2UNCj4+U2VydmVyLA0KPj4gQXV0aG9yaXphdGlvbiBT ZXJ2ZXIpLg0KPj4gLSBBY3Rpb246IERlc2lnbiB0ZWFtIGlzIHJlcXVlc3RlZCB0byBtZXJnZSBQ cm9ibGVtIERlc2NyaXB0aW9uIGRyYWZ0DQo+PmFuZA0KPj4gQWN0b3JzIGRyYWZ0LCBhbmQgcHJv dmlkZSBhIGNvbWJpbmVkIGRyYWZ0Lg0KPj4gDQo+PiANCj4+IA0KPj4gMy4gVGhlcmUgaGFzIG9u bHkgYmVlbiBvbmUgc3Vic3RhbnRpYWwgcmV2aWV3IGNvbW1lbnQgb24gdGhpcw0KPj4gYW5kIEkg Y29uc2lkZXIgdGhhdCBjb21tZW50IHJlc29sdmVkIHdpdGggbm8gY2hhbmdlIGluIGN1cnJlbnQN Cj4+dGVybWlub2xvZ3kuDQo+PiANCj4+IGh0dHA6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZl L3dlYi9hY2UvY3VycmVudC9tc2cwMTI0Mi5odG1sDQo+PiBodHRwOi8vd3d3LmlldGYub3JnL21h aWwtYXJjaGl2ZS93ZWIvYWNlL2N1cnJlbnQvbXNnMDEyNDMuaHRtbA0KPj4gaHR0cDovL3d3dy5p ZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL2FjZS9jdXJyZW50L21zZzAxMjQ0Lmh0bWwNCj4+IGh0 dHA6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9hY2UvY3VycmVudC9tc2cwMTI0NS5o dG1sDQo+PiBodHRwOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvYWNlL2N1cnJlbnQv bXNnMDEyNDYuaHRtbA0KPj4gDQo+PiANCj4+IDQuIEZyb20gdGhlIHJldmlld3Mgb2YgdGhlIEFj dG9ycyBkcmFmdCB0aGVyZSBpcyBubyBzdXBwb3J0IHRvDQo+PiJtYWludGFpbiBhDQo+PiBjbGVh ciBzZXBhcmF0aW9uIGJldHdlZW4gQWN0b3JzIGFuZCBPQXV0aCB0ZXJtaW5vbG9neeKAnS4gVGhp cyBpcyBtYXliZSBhDQo+PiBwcm9ibGVtIHdpdGggc29tZSBzb2x1dGlvbiBwcm9wb3NhbCwgc3Vj aCBhcyBEQ0FGLCBidXQgeW91IGFyZSBmcmVlIHRvDQo+PiBtYWtlIHRoYXQgc2VwYXJhdGlvbiBj bGVhciBieSBzZWxlY3Rpbmcgb3duIHRlcm1zIGluIHlvdXIgcHJvcG9zYWwuIElmDQo+PnlvdQ0K Pj4gbmVlZCB0by4gWW91IGNhbiBhbHdheXMgbWFrZSB0aGUgZGlzdGluY3Rpb24gRENBRiBDbGll bnQgdnMgT0F1dGggQ2xpZW50DQo+PiBldGMuIE5vdGUgdGhhdCB0aGlzIGtpbmQgb2YgY29uZnVz aW9uIGlzIGFscmVhZHkgcHJlc2VudCBzaW5jZSBEQ0FGDQo+PlNlcnZlcg0KPj4gbWF5IGJlIENv QVAgQ2xpZW50Lg0KPj4gDQo+PiANCj4+IFRoZXJlIGlzIG5vIG5lZWQgdG8gY2hhbmdlIHRoZSB0 ZXJtaW5vbG9neS4gSGF2aW5nIGFuIGFnZW5kYSBpdGVtIGZpeGluZw0KPj4gbmFtaW5nIGNvbmZs aWN0cyBpbiBwcmltYXJpbHkgRENBRiBpcyBub3QgYSBjb25jZXJuIG9mIHRoaXMgaW50ZXJpbS4N Cj4+IA0KPj4gV2UgKmNvdWxkKiBtYWtlIGEgY2xlYW4gc2xhdGUgdGVybWlub2xvZ3ksIEkgcHJv cG9zZWQgdGhhdCBpbiBKYW51YXJ5IG9yDQo+PiBGZWJydWFyeSwgYnV0IEkgdGhpbmsgdGhlIHRp bWUgaGFzIHBhc3NlZCBiZXlvbmQgYWxsIHJlYXNvbmFibGUgbGltaXRzDQo+PnRvDQo+PiBkbyB0 aGF0IG5vdy4gQW5kIHlvdSBoYXZlIG5vdCBzdWJtaXR0ZWQgYW55IGlucHV0IGZvciB0aGF0IHR5 cGUgb2YNCj4+IGRpc2N1c3Npb24gc28gSSBwcm9wb3NlIHdlIGRyb3AgaXQuDQo+PiANCj4+IA0K Pj4gR8O2cmFuDQo+PiANCj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fDQo+PiBBY2UgbWFpbGluZyBsaXN0DQo+PiBBY2VAaWV0Zi5vcmcNCj4+IGh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vYWNlDQo+PiANCj4+IA0KPg0KPi0tIA0K PlN0ZWZhbmllIEdlcmRlcwkJCVRlbDogKzQ5IDQyMSAyMTggNjM5MDYNCj5UWkkgVW5pdmVyc2l0 w6R0IEJyZW1lbgkJRS1NYWlsOiBnZXJkZXNAdHppLmRlDQo+QmlibGlvdGhla3N0ci4gMSwgTVpI IDUxNTANCj4yODM1OSBCcmVtZW4sIEdlcm1hbnkNCg0K From nobody Wed Sep 30 05:20: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 147B21A1BDC for ; Wed, 30 Sep 2015 05:20:58 -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 4VSIMuQ4xdfa for ; Wed, 30 Sep 2015 05:20: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 63A101A1B86 for ; Wed, 30 Sep 2015 05:20:56 -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 t8UCKquC029225; Wed, 30 Sep 2015 14:20:52 +0200 (CEST) Received: from aung.tzi.org (eduroam-pool3-024.wlan.uni-bremen.de [134.102.232.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 3nQxWR6msVz4pj3; Wed, 30 Sep 2015 14:20:51 +0200 (CEST) From: Olaf Bergmann To: =?utf-8?Q?G=C3=B6ran?= Selander References: <20150929130430.27260.42.idtracker@ietfa.amsl.com> <560A91C2.4030102@tzi.org> <560BC550.2040900@tzi.de> Date: Wed, 30 Sep 2015 14:20:51 +0200 In-Reply-To: (=?utf-8?Q?=22G?= =?utf-8?Q?=C3=B6ran?= Selander"'s message of "Wed, 30 Sep 2015 11:54:06 +0000") Message-ID: <87d1x0jdy4.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: Stefanie Gerdes , Carsten Bormann , "ace@ietf.org" Subject: Re: [Ace] I-D Action: draft-ietf-ace-actors-01.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, 30 Sep 2015 12:20:58 -0000 G=C3=B6ran Selander writes: > If the sleepy node (DCAF Server) instead implements only CoAP client > functionality (which you taught me was a valid case for very constrained > nodes back in February-ish) and uses PUT to the intermediary server, > instead of GET response. In this case you would expect the sleepy client to setup a secure context with the intermediary using DCAF. In that case, it is a CoAP client. But, if you instead contact the sleepy node from somewhere else (through the intermediary) to establish an observe relationship, it would still be the server (both CoAP and DCAF-wise). But if, for some reason---and that was what we have talked about back then---there is already a security association between a CoAP client and a CoAP server that has been initiated by the CoAP client, there may be hypothetic use cases where the application on the server side wants to send a CoAP request to the client side utilizing the existing security context. In that case the roles for CoAP client and server are reversed (because the request sending party is a CoAP client and the response sending party is a CoAP server). This is orthogonal to the role that the entities on the lhs and rhs of your picture had when the security context has been established. Maybe Figure 7 of draft-ietf-ace-actors-01 in Section 2.3 tries to express this. But I am not sure because I do not understand that picture. Gr=C3=BC=C3=9Fe Olaf From nobody Wed Sep 30 05:37: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 7A72E1A6FB6 for ; Wed, 30 Sep 2015 05:37:39 -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 8-w5uYx_2evS for ; Wed, 30 Sep 2015 05:37:38 -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 76B831A6FB4 for ; Wed, 30 Sep 2015 05:37:37 -0700 (PDT) X-AuditID: c1b4fb25-f79a26d00000149a-c9-560bd78f6fdb Received: from ESESSHC024.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id A5.98.05274.F87DB065; Wed, 30 Sep 2015 14:37:35 +0200 (CEST) Received: from ESESSMB303.ericsson.se ([169.254.3.186]) by ESESSHC024.ericsson.se ([153.88.183.90]) with mapi id 14.03.0248.002; Wed, 30 Sep 2015 14:37:35 +0200 From: =?utf-8?B?R8O2cmFuIFNlbGFuZGVy?= To: Olaf Bergmann Thread-Topic: [Ace] I-D Action: draft-ietf-ace-actors-01.txt Thread-Index: AQHQ+3pxEIjxTgYNzEyYvEGszNnsjJ5VApmA Date: Wed, 30 Sep 2015 12:37:34 +0000 Message-ID: References: <20150929130430.27260.42.idtracker@ietfa.amsl.com> <560A91C2.4030102@tzi.org> <560BC550.2040900@tzi.de> <87d1x0jdy4.fsf@aung.informatik.uni-bremen.de> In-Reply-To: <87d1x0jdy4.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.149] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprPIsWRmVeSWpSXmKPExsUyM+JvjW7/de4wg2Xb9Cy+f+thtmha3Mhk cWTKXVaLjRfvMjqweCxZ8pPJY9vbr8we0xZlBjBHcdmkpOZklqUW6dslcGWs+DqHpWCSaMXh aX+YGxjPiHQxcnJICJhInF2yhxnCFpO4cG89WxcjF4eQwFFGiZ+Nq9khnCWMEgtn/2MCqWIT cJF40PAIzBYRUJHY0P0MzGYWSJH4tfYCmC0sYC3Rfm06K0SNjcTrWftZIGwjia4Fa8HiLAKq EscvtoLV8wpYSLz+fhZqWROTxKVrDWAncQIN+v9oEVgRI9B530+tgVomLnHryXwmiLMFJJbs OQ/1gqjEy8f/wBaICuhJrLzexAYRV5JYe3g70BEcQL2aEut36UOMsZZY+ugtI4StKDGl+yE7 xD2CEidnPmGZwCgxC8m2WQjds5B0z0LSPQtJ9wJG1lWMosWpxUm56UbGeqlFmcnFxfl5enmp JZsYgTF6cMtv1R2Ml984HmIU4GBU4uFVcOIOE2JNLCuuzD3EKM3BoiTO28z0IFRIID2xJDU7 NbUgtSi+qDQntfgQIxMHp1QDY/PhOSu9npZZLBHSE+3qSs+OfOUnLuc2NUbw94HE2wq+wp+2 5rxb67T07oTeI99K9PxP/C9YmN39422d9NTic498Vpk9ipqtuGv2U9W1GZwCtktafRMn7mPw VuOXrDz8tfeuTemUa++Pbes/4GrB9+gpp+Gqe64NLDXXVVZcKE44m72i5JbEXyWW4oxEQy3m ouJEAG4s5YuyAgAA Archived-At: Cc: Stefanie Gerdes , Carsten Bormann , "ace@ietf.org" Subject: Re: [Ace] I-D Action: draft-ietf-ace-actors-01.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, 30 Sep 2015 12:37:39 -0000 SGkgT2xhZiwNCg0KSSB3YXMgYmFzaWNhbGx5IHRoaW5raW5nIGFib3V0IHB1Ymxpc2gtc3Vic2Ny aWJlIHdpdGggZW5kLXRvLWVuZCBzZWN1cml0eS4NCkkgbWF5IGhhdmUgbWlzdW5kZXJzdG9vZCwg YnV0IEkgdGhvdWdodCBpdCB3YXMgdGhhdCAgdXNlIGNhc2UgKG9yIHJhdGhlcg0KdGhlIENsaWVu dCBQdWxsIGF1dGhvcml6YXRpb24gc2NoZW1lKSB0aGF0ICJQaWdneWJhY2tlZCBQcm90ZWN0ZWQg Q29udGVudOKAnQ0Kd2FzIGFkZHJlc3NpbmcuDQoNCk9uZSBjb21tZW50IGlubGluZS4NCg0KT24g MjAxNS0wOS0zMCAxNDoyMCwgIk9sYWYgQmVyZ21hbm4iIDxiZXJnbWFubkB0emkub3JnPiB3cm90 ZToNCg0KPkfDtnJhbiBTZWxhbmRlciA8Z29yYW4uc2VsYW5kZXJAZXJpY3Nzb24uY29tPiB3cml0 ZXM6DQo+DQo+PiBJZiB0aGUgc2xlZXB5IG5vZGUgKERDQUYgU2VydmVyKSBpbnN0ZWFkIGltcGxl bWVudHMgb25seSBDb0FQIGNsaWVudA0KPj4gZnVuY3Rpb25hbGl0eSAod2hpY2ggeW91IHRhdWdo dCBtZSB3YXMgYSB2YWxpZCBjYXNlIGZvciB2ZXJ5IGNvbnN0cmFpbmVkDQo+PiBub2RlcyBiYWNr IGluIEZlYnJ1YXJ5LWlzaCkgYW5kIHVzZXMgUFVUIHRvIHRoZSBpbnRlcm1lZGlhcnkgc2VydmVy LA0KPj4gaW5zdGVhZCBvZiBHRVQgcmVzcG9uc2UuDQo+DQo+SW4gdGhpcyBjYXNlIHlvdSB3b3Vs ZCBleHBlY3QgdGhlIHNsZWVweSBjbGllbnQgdG8gc2V0dXAgYSBzZWN1cmUNCj5jb250ZXh0IHdp dGggdGhlIGludGVybWVkaWFyeSB1c2luZyBEQ0FGLiBJbiB0aGF0IGNhc2UsIGl0IGlzIGEgQ29B UA0KPmNsaWVudC4gQnV0LCBpZiB5b3UgaW5zdGVhZCBjb250YWN0IHRoZSBzbGVlcHkgbm9kZSBm cm9tIHNvbWV3aGVyZSBlbHNlDQo+KHRocm91Z2ggdGhlIGludGVybWVkaWFyeSkgdG8gZXN0YWJs aXNoIGFuIG9ic2VydmUgcmVsYXRpb25zaGlwLCBpdA0KPndvdWxkIHN0aWxsIGJlIHRoZSBzZXJ2 ZXIgKGJvdGggQ29BUCBhbmQgRENBRi13aXNlKS4NCj4NCj5CdXQgaWYsIGZvciBzb21lIHJlYXNv bi0tLWFuZCB0aGF0IHdhcyB3aGF0IHdlIGhhdmUgdGFsa2VkIGFib3V0IGJhY2sNCj50aGVuLS0t dGhlcmUgaXMgYWxyZWFkeSBhIHNlY3VyaXR5IGFzc29jaWF0aW9uIGJldHdlZW4gYSBDb0FQIGNs aWVudCBhbmQNCj5hIENvQVAgc2VydmVyIHRoYXQgaGFzIGJlZW4gaW5pdGlhdGVkIGJ5IHRoZSBD b0FQIGNsaWVudCwgdGhlcmUgbWF5IGJlDQo+aHlwb3RoZXRpYyB1c2UgY2FzZXMgd2hlcmUgdGhl IGFwcGxpY2F0aW9uIG9uIHRoZSBzZXJ2ZXIgc2lkZSB3YW50cyB0bw0KPnNlbmQgYSBDb0FQIHJl cXVlc3QgdG8gdGhlIGNsaWVudCBzaWRlIHV0aWxpemluZyB0aGUgZXhpc3Rpbmcgc2VjdXJpdHkN Cj5jb250ZXh0LiBJbiB0aGF0IGNhc2UgdGhlIHJvbGVzIGZvciBDb0FQIGNsaWVudCBhbmQgc2Vy dmVyIGFyZSByZXZlcnNlZA0KPihiZWNhdXNlIHRoZSByZXF1ZXN0IHNlbmRpbmcgcGFydHkgaXMg YSBDb0FQIGNsaWVudCBhbmQgdGhlIHJlc3BvbnNlDQo+c2VuZGluZyBwYXJ0eSBpcyBhIENvQVAg c2VydmVyKS4gVGhpcyBpcyBvcnRob2dvbmFsIHRvIHRoZSByb2xlIHRoYXQgdGhlDQo+ZW50aXRp ZXMgb24gdGhlIGxocyBhbmQgcmhzIG9mIHlvdXIgcGljdHVyZSBoYWQgd2hlbiB0aGUgc2VjdXJp dHkNCj5jb250ZXh0IGhhcyBiZWVuIGVzdGFibGlzaGVkLiBNYXliZSBGaWd1cmUgNyBvZiBkcmFm dC1pZXRmLWFjZS1hY3RvcnMtMDENCj5pbiBTZWN0aW9uIDIuMyB0cmllcyB0byBleHByZXNzIHRo aXMuIEJ1dCBJIGFtIG5vdCBzdXJlIGJlY2F1c2UgSSBkbyBub3QNCj51bmRlcnN0YW5kIHRoYXQg cGljdHVyZS4NCg0KSSB0aGluayB3ZSBoYXZlIG90aGVyIHJldmlldyBjb21tZW50cyBvbiB0aGF0 IGZpZ3VyZSBhcyB3ZWxsLiBMZXTigJlzDQpkaXNjdXNzIHRoYXQgaW4gdGhlIG1lZXRpbmcuDQoN CkfDtnJhbg0KDQoNCg0KPg0KPkdyw7zDn2UNCj5PbGFmDQoNCg== From nobody Wed Sep 30 05:45: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 37A4D1A6FE2 for ; Wed, 30 Sep 2015 05:45:27 -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 ktIMyrVaQG1Q for ; Wed, 30 Sep 2015 05:45:25 -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 D4BD01A6FE3 for ; Wed, 30 Sep 2015 05:45:24 -0700 (PDT) X-AuditID: c1b4fb2d-f79626d000004282-c0-560bd9622b57 Received: from ESESSHC004.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 7D.A8.17026.269DB065; Wed, 30 Sep 2015 14:45:23 +0200 (CEST) Received: from ESESSMB303.ericsson.se ([169.254.3.186]) by ESESSHC004.ericsson.se ([153.88.183.30]) with mapi id 14.03.0248.002; Wed, 30 Sep 2015 14:45:22 +0200 From: =?utf-8?B?R8O2cmFuIFNlbGFuZGVy?= To: Stefanie Gerdes , "Ace@ietf.org" Thread-Topic: [Ace] Fwd: New Version Notification for draft-gerdes-ace-tasks-00.txt Thread-Index: AQHQ+33eMaq4YngjLEmeSe14XRrSuA== Date: Wed, 30 Sep 2015 12:45:21 +0000 Message-ID: References: <20150929131917.3219.71402.idtracker@ietfa.amsl.com> <560A912C.7040505@tzi.de> In-Reply-To: <560A912C.7040505@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.150] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpmkeLIzCtJLcpLzFFi42KZGfG3Rjf5JneYwdpGDovv33qYLTZevMvo wOSxZMlPJo9tb78yBzBFcdmkpOZklqUW6dslcGV82vSCrWCDfsX+U23MDYxT9LoYOTkkBEwk ru6Zwgxhi0lcuLeerYuRi0NI4CijxLRLN9khnCWMEm9WX2ADqWITcJF40PCICcQWEXCSWLrt LwuILSwQInFr6x5miHioxNvXx9ggbD2JpjlnWEFsFgFViZ3/TgIN5eDgFbCQWDRNGSQsJBAj 8fjfbLByTgE1icbXz9lBbEagg76fWgO2illAXOLWk/lMEIcKSCzZcx7qaFGJl4//gY0XBVq1 8noTG0RcSWLF9kuMIKuYBTQl1u/ShxhjLbHu+gl2CFtRYkr3QzCbV0BQ4uTMJywTGMVnIdk2 C6F7FpLuWUi6ZyHpXsDIuopRtDi1uDg33chYL7UoM7m4OD9PLy+1ZBMjMNYObvmtu4Nx9WvH Q4wCHIxKPLwKTtxhQqyJZcWVuYcYpTlYlMR5W5gehAoJpCeWpGanphakFsUXleakFh9iZOLg lGpgZF5xQKfBa66R/1VjhwXd/7/y70zf9OLLtq7dZuq/D65fK9s2MSZhc1iuw+3gLQef529q mbr+tNL6tHALdRO1+1rib/ontec81upzrWCeMl2qekFo3J242159c30bM6f3BTxa87rSJYlD ZcXu7DQVXcXOhy0p+v+bnXeVzJGOOBDuxvulXeGwEktxRqKhFnNRcSIA8GFfyJYCAAA= Archived-At: Subject: Re: [Ace] Fwd: New Version Notification for draft-gerdes-ace-tasks-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: Wed, 30 Sep 2015 12:45:27 -0000 SGkgU3RlZmZpLA0KDQpJIGhhdmUgbG9va2VkIHRocm91Z2ggdGhlIGRyYWZ0IHF1aWNrbHkgYW5k IGhlcmUgYXJlIG15IGNvbW1lbnRzLg0KDQpJIHRoaW5rIGEgbGlzdCBvZiBwb3RlbnRpYWwgdGFz a3Mgb2YgYW4gYWN0b3Igb24gYSBoaWdoIGxldmVsIGNvdWxkIGJlDQp1c2VmdWwgdG8gaW5jbHVk ZSBpbiB0aGUgYWN0b3JzIGRyYWZ0LiBMdWR3aWcgYmVnYW4gY29tcGlsZSBzdWNoIGEgbGlzdCBp bg0KUHJhZ3VlLCBjb3VsZG7igJl0IGZpbmQgaXQgcmlnaHQgbm93LiBJIGRvbuKAmXQgdGhpbmsg dGhlcmUgaXMgYSBuZWVkIGZvciBhDQpzZXBhcmF0ZSBkb2N1bWVudCwgZm9yIHNldmVyYWwgcmVh c29uczoNCg0KLSBUaGlzIGRyYWZ0IGlzIGluIHBhcnRzIG92ZXJsYXBwaW5nIHdpdGggdGhlIGFj dG9ycyBkcmFmdCwgYW5kIG1vc3QgcGFydHMNCndoaWNoIGFyZSBub3Qgb3ZlcmxhcHBpbmcgYXJl IG5vdCBuZWVkZWQuDQoNCi0gU2VjdGlvbiAzLjMgY29udGFpbnMgYW4gYWJzdHJhY3QgZGlzY3Vz c2lvbiBhYm91dCDigJxhdHRyaWJ1dGVz4oCdLA0KImF0dHJpYnV0ZSBiaW5kaW5nIiwgImF0dHJp YnV0ZSBiaW5kaW5nIGF1dGhvcml0eSIsIOKAnGVuZG9yc2VtZW50DQppbmZvcm1hdGlvbiIsIOKA nHZlcmlmaWVy4oCdLGV0Yy4gIE1hbnkgbmV3IHRlcm1zLiBBcyBmYXIgYXMgSSB1bmRlcnN0YW5k LA0KdGhpcyBpcyBjb21wbGV0ZWx5DQpnZW5lcmljIGFuZCB0aHVzIGJlbG9uZyB0byBhIHRleHQg Ym9vay4gT3Igc2hvdWxkIGl0IGJlIGludGVycHJldGVkDQpsaXRlcmFsbHkgYXMgYXR0cmlidXRl cyBpbiBhbiBhY2Nlc3MgdG9rZW4/IE5vdGUgdGhlbiB0aGF0IGl0IGlzIG5vdA0KbmVjZXNzYXJ5 IHRvIGhhdmUgYWNjZXNzIHRva2VucyB0byBwZXJmb3JtIGF1dGhvcml6YXRpb24uDQoNCi0gU2Vj dGlvbiA0LjEgVGhlIGFjdHVhbCBkZXNjcmlwdGlvbiBvZiB0YXNrcyBpcyBub3QgY29ycmVjdCBp biBhbGwgY2FzZXMuDQpJdCBzYXlzIOKAnFMgcGVyZm9ybXMgdGhlIGZvbGxvd2luZyB0YXNrc+KA nSBhbmQgYXNzdW1lcyBhIGNlcnRhaW4NCmNvbW11bmljYXRpb24gbW9kZWwgd2hpY2ggZG9lcyBu b3QgYWx3YXlzIGFwcGx5LiBFLmcuICB0aGUgUlMgbmVlZCBub3QNCnJlY2VpdmUgYSByZXF1ZXN0 LiBXaXRoIHN1Y2ggY29uc2lkZXJhdGlvbnMgdGhlIGFwcGxpY2F0aW9uIG9mIHRoZSBjb250ZW50 DQppcyBsaW1pdGVkIGFuZCB3ZSBjb3VsZCBqdXN0IGFzIHdlbGwgc2V0dGxlIGZvciBzb21lIGhp Z2ggbGV2ZWwgZXhhbXBsZXMuDQoNCi0gVGhlcmUgYXJlIDEwIHBhZ2VzIG9mIGFwcGVuZGljZXMu IEkgZG9u4oCZdCB0aGluayBtYW55IHBlb3BsZSB3b3VsZCB1c2UNCnRoaXMgd2hlbiBpbXBsZW1l bnRpbmcgdGhlIEFDRSBzb2x1dGlvbi4gQW5kIGl0IHN1ZmZlcnMgZnJvbSB0aGUgc2FtZQ0KaXNz dWUgdGhhdCBpdCBhcHBsaWVzIHRvIGNlcnRhaW4gYXV0aG9yaXphdGlvbiBzY2hlbWVzLg0KDQoN CkkgZG9u4oCZdCBrbm93IHdoYXQgaXMgdGhlIG1lYW5pbmcgb2YgYW4g4oCcYWNjb21wYW55aW5n IGRvY3VtZW504oCdLiBEbyB5b3UNCnByb3Bvc2UgdGhpcyB0byBiZSBhZG9wdGVkIGJ5IHRoZSBX Rz8gSSB0aGluayBBQ0UgaGFzIGFscmVhZHkgc3RyZXRjaGVkDQp0aGUgbGltaXQgb24gdGhlIG51 bWJlciBvZiBpbmZvcm1hdGlvbmFsIGRyYWZ0cyB0aGF0IGl0IGNhbiBiZWFyLCBhbmQNCnNob3Vs ZCBub3QgY29tbWl0IG9yIGV2ZW4gcmVmZXJlbmNlIGFueSBkb2N1bWVudHMgdGhhdCBtYXkgYWZm ZWN0IHRoZSB0aW1lDQpsaW5lLg0KDQoNClJlZ2FyZHMsDQpHw7ZyYW4NCg0KDQoNCk9uIDIwMTUt MDktMjkgMTU6MjUsICJTdGVmYW5pZSBHZXJkZXMiIDxnZXJkZXNAdHppLmRlPiB3cm90ZToNCg0K PkhpIGFsbCwNCj4NCj5JIGp1c3Qgc3VibWl0dGVkIGEgbmV3IGRvY3VtZW50IGNvbnRhaW5pbmcg dGhlIGF1dGhlbnRpY2F0aW9uLSBhbmQNCj5hdXRob3JpemF0aW9uLXJlbGF0ZWQgdGFza3MgdGhh dCB0aGUgYWN0b3JzIGluIHRoZSBBQ0UgYXJjaGl0ZWN0dXJlIG5lZWQNCj50byBwZXJmb3JtLiBU aGlzIGRvY3VtZW50IGNhbiBiZSB1c2VkIGFzIGFuIGFjY29tcGFueWluZyBkb2N1bWVudCB0byB0 aGUNCj5hY3RvcnMgZHJhZnQuDQo+DQo+VGhlIHRhc2tzIHdlcmUgb3JpZ2luYWxseSBpbmNsdWRl ZCBpbiB0aGUgYWN0b3JzIGRyYWZ0IGJ1dCB3ZSBkZWNpZGVkIHRvDQo+cHV0IHRoZW0gaW50byBh IHNlcGFyYXRlIGRvY3VtZW50IHdoZW4gd2UgbWVyZ2VkIHRoZSBhY3RvcnMgZHJhZnQgYW5kDQo+ dGhlIHByb2JsZW0gZGVzY3JpcHRpb24gZHJhZnQuDQo+DQo+Q29tbWVudHMgYXJlIHdlbGNvbWUh DQo+DQo+QmVzdCByZWdhcmRzLA0KPlN0ZWZmaQ0KPg0KPg0KPi0tLS0tLS0tIEZvcndhcmRlZCBN ZXNzYWdlIC0tLS0tLS0tDQo+U3ViamVjdDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBk cmFmdC1nZXJkZXMtYWNlLXRhc2tzLTAwLnR4dA0KPkRhdGU6IFR1ZSwgMjkgU2VwIDIwMTUgMDY6 MTk6MTcgLTA3MDANCj5Gcm9tOiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcNCj5UbzogU3RlZmFu aWUgR2VyZGVzIDxnZXJkZXNAdHppLm9yZz4sIFN0ZWZhbmllIEdlcmRlcyA8Z2VyZGVzQHR6aS5v cmc+DQo+DQo+DQo+QSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LWdlcmRlcy1hY2UtdGFza3Mt MDAudHh0DQo+aGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBTdGVmYW5pZSBHZXJk ZXMgYW5kIHBvc3RlZCB0byB0aGUNCj5JRVRGIHJlcG9zaXRvcnkuDQo+DQo+TmFtZToJCWRyYWZ0 LWdlcmRlcy1hY2UtdGFza3MNCj5SZXZpc2lvbjoJMDANCj5UaXRsZToJCUF1dGhvcml6YXRpb24t UmVsYXRlZCBUYXNrcyBpbiBDb25zdHJhaW5lZCBFbnZpcm9ubWVudHMNCj5Eb2N1bWVudCBkYXRl OgkyMDE1LTA5LTI5DQo+R3JvdXA6CQlJbmRpdmlkdWFsIFN1Ym1pc3Npb24NCj5QYWdlczoJCTIw DQo+VVJMOg0KPmh0dHBzOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1nZXJk ZXMtYWNlLXRhc2tzLTAwLnR4dA0KPlN0YXR1czogICAgICAgICBodHRwczovL2RhdGF0cmFja2Vy LmlldGYub3JnL2RvYy9kcmFmdC1nZXJkZXMtYWNlLXRhc2tzLw0KPkh0bWxpemVkOiAgICAgICBo dHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtZ2VyZGVzLWFjZS10YXNrcy0wMA0KPg0K Pg0KPkFic3RyYWN0Og0KPiAgIENvbnN0cmFpbmVkIG5vZGVzIGFyZSBzbWFsbCBkZXZpY2VzIHdo aWNoIGFyZSBsaW1pdGVkIGluIHRlcm1zIG9mDQo+ICAgcHJvY2Vzc2luZyBwb3dlciwgbWVtb3J5 LCBub24tdm9sYXRpbGUgc3RvcmFnZSBhbmQgdHJhbnNtaXNzaW9uDQo+ICAgY2FwYWNpdHkuICBE dWUgdG8gdGhlc2UgY29uc3RyYWludHMsIGNvbW1vbmx5IHVzZWQgc2VjdXJpdHkgcHJvdG9jb2xz DQo+ICAgYXJlIG5vdCBlYXNpbHkgYXBwbGljYWJsZS4gIE5ldmVydGhlbGVzcywgYW4gYXV0aGVu dGljYXRpb24gYW5kDQo+ICAgYXV0aG9yaXphdGlvbiBzb2x1dGlvbiBpcyBuZWVkZWQgdG8gZW5z dXJlIHRoZSBzZWN1cml0eSBvZiB0aGVzZQ0KPiAgIGRldmljZXMuDQo+DQo+ICAgRHVlIHRvIHRo ZSBsaW1pdGF0aW9ucyBvZiB0aGUgY29uc3RyYWluZWQgbm9kZXMgaXQgaXMgZXNwZWNpYWxseQ0K PiAgIGltcG9ydGFudCB0byBkZXZlbG9wIGEgbGlnaHQtd2VpZ2h0IHNlY3VyaXR5IHNvbHV0aW9u IHdoaWNoIGlzDQo+ICAgYWRqdXN0ZWQgdG8gdGhlIHJlbGV2YW50IHNlY3VyaXR5IG9iamVjdGl2 ZXMgb2YgZWFjaCBwYXJ0aWNpcGF0aW5nDQo+ICAgcGFydHkgaW4gdGhpcyBlbnZpcm9ubWVudC4g IE5lY2Vzc2FyeSBzZWN1cml0eSBtZWFzdXJlcyBtdXN0IGJlDQo+ICAgaWRlbnRpZmllZCBhbmQg YXBwbGllZCB3aGVyZSBuZWVkZWQuDQo+DQo+ICAgSW4gdGhpcyBkb2N1bWVudCwgdGhlIHJlcXVp cmVkIHNlY3VyaXR5IHJlbGF0ZWQgdGFza3MgYXJlIGlkZW50aWZpZWQNCj4gICBhcyBndWlkYW5j ZSBmb3IgdGhlIGRldmVsb3BtZW50IG9mIGF1dGhlbnRpY2F0aW9uIGFuZCBhdXRob3JpemF0aW9u DQo+ICAgc29sdXRpb25zIGZvciBjb25zdHJhaW5lZCBlbnZpcm9ubWVudHMuDQo+DQo+DQo+DQo+ DQo+DQo+UGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZy b20gdGhlIHRpbWUgb2YNCj5zdWJtaXNzaW9uDQo+dW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24g YW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29scy5pZXRmLm9yZy4NCj4NCj5UaGUgSUVURiBT ZWNyZXRhcmlhdA0KPg0KPg0KPg0KPg0KPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQo+QWNlIG1haWxpbmcgbGlzdA0KPkFjZUBpZXRmLm9yZw0KPmh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vYWNlDQoNCg== From nobody Wed Sep 30 05:58: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 3E41E1A7004 for ; Wed, 30 Sep 2015 05:58:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.249 X-Spam-Level: X-Spam-Status: No, score=-1.249 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, 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 2ItE-X76VJTA for ; Wed, 30 Sep 2015 05:58:32 -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 C2BD61A7002 for ; Wed, 30 Sep 2015 05:58:31 -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 t8UCwRMf023711; Wed, 30 Sep 2015 14:58:27 +0200 (CEST) Received: from alma.local (unknown [IPv6:2002:8666:da7b:0:45c9:666:2ef2:378b]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3nQyLq0jlRz4p65; Wed, 30 Sep 2015 14:58:27 +0200 (CEST) Date: Wed, 30 Sep 2015 14:58:26 +0200 From: Carsten Bormann To: =?utf-8?Q?G=C3=B6ran_Selander?= , "=?utf-8?Q?ace=40ietf.org?=" Message-ID: In-Reply-To: References: <560BC09E.4090209@tzi.org> X-Mailer: Airmail (329) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="560bdc72_15378aaa_c441" Archived-At: Subject: Re: [Ace] Interim 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: Wed, 30 Sep 2015 12:58:33 -0000 --560bdc72_15378aaa_c441 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline We didn=E2=80=99t do a formal disposition of comments. -01 was just my attempt to translate the discussion the other authors had= in Prague into a new version. So here we are (in reverse order, from the mailing list as well as off-li= st comments): =E2=80=94 terminology (Jim, authors): not covered =E2=80=94 tasks (Jim): not covered, but maybe a pointer is enough =E2=80=94 avoid the term nonrepudiation (Jim): covered =C2=A0 =C2=A0 =E2=80=94> is =E2=80=9Cthird-party verifiability=E2=80=9D t= he term that expresses what we really mean=3F =E2=80=94 various editorial (Jim): covered =E2=80=94 store and forward (Jim): not covered, maybe add something to 2.= 3 =E2=80=94 structure of section 2 (Jim): not covered (maybe too much work = now) =E2=80=94 diagrams confusing about information flow (Jim): covered by add= itional explanation; diagrams unchanged =E2=80=94 intermittency (Jim): added a small note; is that enough=3F =E2=80=94 availability as a security objective (Jim): I think that is OK = as it is =E2=80=94 need more discussion about what is being authenticated (Jim): H= mm. The penchant of this WG for full-quoting makes it likely that I have miss= ed some comments. Some of the comments were on draft-gerdes-actors=E2=80=A6, in particular,= I don=E2=80=99t think we have fully incorporated Jim=E2=80=99s comments = from 2015-08-10 (we always get stuck at the comment about the terminology= :-). =C2=A0E.g., the ones about the information content of section 6, 7,= 8. =C2=A0Some of these comments may be based on the assumption that ever= y section in an architecture document needs to have *new* information =E2= =80=94 I=E2=80=99m however quite content with repeating some information = that is already in there, now presented from a different vantage point or= in a different organization. =C2=A0This can make it more likely that peo= ple actually take note of the information. =C2=A0Apart from that: =E2=80=94 We probably need to get rid of =E2=80=9Csecurity domain=E2=80=9D= and replace it by what we are actually trying to say (e.g., =E2=80=9Cund= er X=E2=80=99s control=E2=80=9D, =E2=80=9Cspeaking for X=E2=80=9D,...), b= ecause that term means too many different things and we are using it vari= ably in all those different meanings. Gr=C3=BC=C3=9Fe, Carsten On 30 Sep 2015 at 13:15:37, G=C3=B6ran Selander (goran.selander=40ericsso= n.com) wrote: Do we have a list of which review comments are covered in -01 and which=C2= =A0 are not=3F I think compiling such a list would be well spent time until t= he=C2=A0 meeting.=C2=A0 --560bdc72_15378aaa_c441 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline